Re: RIF UCR Update 2

Hi Adrian P,
Many thanks for the updates! I believe that UCR looks very good.

Adrian Paschke wrote:
> Hi Gary, Igor, Chris, Harold, Adrian G., Dave, All,
>
> Thanks for your feedback and comments on the UCR use cases.
>
> For our further discussion about an abridge presentation syntax / short cuts and the different representation options you have in BLD and PRD, I have formalized use case 1 using relations, slots, frames and production rules:
>
> http://www.w3.org/2005/rules/wiki/UCR#Negotiating_eBusiness_Contracts_Across_Rule_Platforms
>
> Open discussion points for me to proceed with the formalization of other use cases are, e.g.:
>
> - abridged presentation syntax / short cuts and mapping to “full” presentation syntax
>   
All syntaxes should be allowed. This gives choices to potential users. 
However, it is an issue of mapping between them. These mappings should 
be provided.
> - mixing of frames, slots and relations allowed or not?
>   
Why not? Is a rule representation language. It has to be rich in syntax 
to capture many representation cases. Different processors will decide 
what they implement.
> - typed variables such as ?deliverydate^^xs:dateTime supported or not?
>   
I am pro. A typed variable will be processed simpler in a RIF processor 
rather than an untyped one.
> - User-defined types such as, e.g. 18.7^^xsstl:Percentage
>   
This is difficult to be processed by RIF. I guess the users of RIF 
should use only "standard datatypes" (i.e. RIF processable ). Otherwise 
a mapping to a RIF datatype should be provided.
> - Use of built-ins which are not in DTB, e.g. “fn:days-from-duration”
>   
In some cases (for example in Drools) developers may use operations that 
are defined in the vocabulary class (for example 
calculateNecessaryFoodCalories()  in a Patient class). Is difficult for 
RIF to implement this. However in RIF representation, this function 
should be called the same as supported ones, but the RIF language must 
indicate that this function requires an external processor for its 
implementation.
> - Adrian
>
>
>
>   
All the best,
Adrian G

Received on Monday, 26 May 2008 11:51:23 UTC