W3C home > Mailing lists > Public > public-rif-wg@w3.org > August 2010

Re: [PRD] Rule instances, refraction and Modify [Was: Re: Fwd: Clips behavior]

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Tue, 03 Aug 2010 15:22:59 -0700
Message-ID: <4C5896C3.6020806@oracle.com>
To: Mark Proctor <mproctor@redhat.com>
CC: Christian De Sainte Marie <csma@fr.ibm.com>, Neal Wyse <neal.wyse@oracle.com>, RIF WG <public-rif-wg@w3.org>
Hi Mark,

Thanks for the feedback. Because these email discussions are rather old, 
several revs of the spec ago, I'd urge you to comment on how well the 
spec turned out. The intent was to allow many PR engines/tools to 
approximate the spec with enough fidelity to pass a number of common and 
useful testcases (and thus be interoperable, at least within the space 
defined by those testcases). Do you have any concerns about the existing 
testcases? Or do you have other testcases (with a RIF translation) in 
mind that one or more PR engines probably wouldn't be able to pass?

Mark Proctor wrote:
>  On 19/01/2010 16:45, Gary Hallmark wrote:
>> CLIPS I think does not have "slot specific" modify but Jess, OBR, 
>> Drools (I think), ILOG (I think) all have it.
> Clips deftemplates does not, for Clips COOL it is the only way that 
> those objects can work. Jess allows slot-specific to be configured per 
> field.
>
> Drools, JRules and OPSJ do not have slot specific (please correct me 
> if I'm wrong).
>> I am not in favor of treating modify as 
>> retract-all-slots/reassert-all-slots because in our experience this 
>> semantics makes too many common business rules loop and is very hard 
>> to use.
> I agree. Refraction addresses this to some degree, but it's a bit of a 
> sledge hammer; "slot-specific" is more fine grained and elegant. 
> However the two are not mutually exclusive.
>
> Whether a modify is a retract+assert of the entire fact,  a 
> retract+assert of triples representing those change, a single 
> propagation of the entire fact or a single propagation of the triples 
> representing those changes is I believe an implementation detail.
>
> As mentioned previously I think refraction should be an optional part 
> of the spec. With OPS5 implementing it (the grand daddy of PRDS) and 
> OPSJ and JRules I think there is enough justification that this is not 
> an esoteric feature.
>
> I would like to see some variation of slot-specific included in the 
> spec, but I'll leave out the details for what this should look like 
> for another discussion. But I believe it, like refraction,  should be 
> optional behaviour and again independant of how the modify is actually 
> implemented.
>
> As long as we have a modification action that includes the list of 
> changes in the spec, slot specific can be easily added at a later date.
>
> Mark
>>
>> We need to consider some test cases to be sure we are all talking 
>> about the same thing. Here is a variation of a no-loop test. I think 
>> this should never loop (we should not pick a semantics that causes 
>> this to loop):
>>
>> Document(
>> Prefix(ex <http://example.org/example#>)
>> Prefix(func <http://www.w3.org/2007/rif-builtin-function#>)
>> Prefix(pred <http://www.w3.org/2007/rif-builtin-predicate#>)
>>
>> Group (
>> Forall ?X ?C1
>> If
>> And( ?X[ex:count1 -> ?C1] pred:numeric-greater-than(?C1 0) )
>> Then Do (
>> (?C2 (?X[ex:count2 -> ?C2]))
>> Modify (?X[ex:count2-> func:numeric-subtract(?C2 1)])
>> )
>> )
>>
>> ex:foo[ex:count1 -> 10 ex:count2->10]
>>
>> )
>> )
>>
>> The above entails
>> ex:foo[ex:count1 -> 10 ex:count2->9]
>> but does NOT entail
>> ex:foo[ex:count1 -> 10 ex:count2->8]
>>
>> Christian De Sainte Marie wrote:
>>>
>>> All,
>>>
>>> csma wrote on 18/01/2010 15:43:48:
>>> >
>>> > [...]
>>> >
>>> > I started modifying the spec tentatively along these lines, in case
>>> > we would agree that the proposed changes are needed, and that they
>>> > are correct.
>>>
>>> I finished the tentative modifications for point 1 (taking 
>>> intermediate states into account) and 3 (taking the matched facts 
>>> into account in the characterisation of a rule instance).
>>>
>>> I reversed to the published version before doing the modification 
>>> (thus rolling back some other tentative modifications I had made in 
>>> between). To find the modifications, you have to compare with 
>>> Sandro's version from October 1 [1]. Notice that I re-ordered the 
>>> definitions somewhat, to improve readibility (that is, there are 
>>> less modifications, really, than the comparison shows :-)
>>>
>>> [1] 
>>> http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=11952&oldid=11437 
>>> <http://www.w3.org/2005/rules/wiki/index.php?title=PRD&diff=11952&oldid=11437> 
>>>
>>>
>>> I did do any modification wrt the Modify issue, yet (since one 
>>> possibility is to, simply, remove it :-)
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>> IBM
>>> 9 rue de Verdun
>>> 94253 - Gentilly cedex - FRANCE
>>> Tel. +33 1 49 08 35 00
>>> Fax +33 1 49 08 35 10
>>>
>>>
>>> Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
>>> Compagnie IBM France
>>> Siege Social : 17 avenue de l'Europe, 92275 Bois-Colombes Cedex
>>> RCS Nanterre 552 118 465
>>> Forme Sociale : S.A.S.
>>> Capital Social : 611.451.766,20 
>>> SIREN/SIRET : 552 118 465 03644
>>>
>>
>
>
Received on Tuesday, 3 August 2010 22:25:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 August 2010 22:25:40 GMT