[RIF][UCR] Human Oriented Business Rules Review

This addresses my ACTION item originating  from the Jan 31 phone call.

I have now had a chance to go through the Human Oriented Business Rules 
section a bit more carefully.  My remarks below are intended more as 
reflection and suggestion rather than absolutes. Hopefully it will help to 
have one more persons take on what has been written.

In order to review the Human Oriented Business Rules 
(http://www.w3.org/2005/rules/wg/wiki/Interchange_of_Human-oriented_Business_Rules) 
, I want to lay out some general observations.

The Human Oriented Business Rules are a good example of a limiting case 
for RIF.  It is the extreme case where RIF is acting strictly as a 
transport layer with no attempt to map the rules to a common language, we 
absolutely must accommodate them in the following sense.  It amounts to 
the most basic of implementations - communicating rules between two 
systems that already speak the same language. 

1.  At a very minimum (in the absence of all other considerations), RIF 
should support the  "encapsulation" of a  message and pass it on unaltered 
to the consumer (identified as to source, and possibly with a status and 
or identifier)

2.  RIF's responsibilities surrounding delivery of such a message is 

        a) to identify (probably by URI) the  underlying vocabulary and 
source, and 
                b) to deliver the message unaltered.
        c) perhaps include a key or identifier and a status  (complete, 
response to id xxx, etc. , type = (boolean outcome?) )

It is entirely up to the sender / receiver to make sense of the messages 
and to decide what to do with them. 

3.  In an XML based environment you would probably have two containers ( 
one for CDATA, and one  for encapulating XML based messages) but we can 
address such detail later.

----

Where the difficulty lies is in identifying a core vocabulary for general 
use and in mapping Human Oriented Rules onto some sort of core vocabulary 
and structure. 
 
With this in mind, we can begin.

1.  Abstract.

        I generally agree with the points raised here, except for 
clarification of scope.  This needs to be refined by making it clear that 
sending a message and tagging it as  speaking "RULE-Language -XYZ" 
(whatever that is ...) is definitely always in scope. These are "Atomic" 
operations.

        Processing is always out of scope - We are simply delivering the 
message.  Processing is out of scope for Machine oriented business 
languages as well.
 
        The interesting questions are around determining if there is any 
sort of raw vocabulary and relationships beyond (pass through messages) 
that can/should be in scope.    We expect that vocabulary to be pretty 
much out of scope, but should keep our eyes open for opportunities. 

        The discussion correctly identifies places where we have a hope of 
making progress.  I suspect many of these may end up being out of scop or 
at least left to phase 2 but we should look at them and pick off the easy 
ones.  This long list of things that is in scope is really just a long 
list of things where Human Oriented rules may arise - independent of how 
much structure the rules might have. 

        The places where we can move beyond just ATOMIC rules may be in 
providing sets or collections of Human oriented rules - and/or some model 
of flow control and testability without much more than tests with boolean 
outcomes and atomic rules.

        For example, you may need to have the Car Rental Agent complete a 
human based test and send back a message indicating that the Rental was 
completed, or disallowed.


2.  Status

        The status section nicely outlines some existing strategies to 
adding some structure on top of the Atoms I discuss above, and clearly 
indicates a strong need to support this kind of interchange.   I would not 
make any changes.  This is where we will get real examples and candidate 
models from.

3.  Related Use Cases

        Looks good.

7.  Requirements on RIF

        I would regard developing the natural language aspects discussed 
here as out of scope.  They are important, of course, but their work will 
be best facilitated by having a well defined RIF structure to map onto. 
The Natural Language Tools are produces and consumers of RIF, rather than 
RIF itsself.    Our goal here is to provide the infrastructure that 
provides target internal representation.

8.3  Alternate Sequences

8.3.1  Natural Language rules exchange.
 
        Sequence.     1.   Parse natural language into RIF.    2. Transmit 
RIF      3.  recieve RIF    4.  construct a human readable description.


Stan Devitt
Agfa Healthcare