Hi Jeff,
yes I am not a RETE expert either, so it may be wisest to not jump to
conclusions in either direction, esp since the current SPIN spec is still
aligned with the W3C member submission - any change now would spawn off a
TopBraid-specific version of the language which we need to do with care.
Meanwhile, what about the alternative:
- In TBC, use SPARQLMotion (sml:ApplyTopSPIN with two different rule predicates)
- In the SPIN API, call SPINInferences twice, with different rule property
This gives you full control over the ordering in which groups of rules are
fired.
Since your proposal is about grouping rules by sub-properties of spin:rule,
both approaches above would meet your immediate needs, and you can add any new
spin property for the ordering and grouping at a later stage?
Regards,
Holger
On Dec 22, 2011, at 1:02 PM, Jeff Schmitz wrote:
> Hi Holger,
> I won't pretend to be even a novice on the RETE algorithm, but if
> there are truly no issues with rule execution order decisions during
> iteration affecting the "ultimate truth" of the system, then what you
> say makes sense. However, at first blush I don't understand how any
> rule execution algorithm can really be order agnostic, and if such
> rule ordering can alter the "ultimate truth" in some scenarios, then
> perhaps it should be in the core SPIN language, if only to allow the
> user of the rule execution engine to decide what is the correct
> "ultimate truth" (and not Holger :-)).
>
> I did notice that on the wikipedia page for RETE (which is pretty much
> the extant of my scholarly knowledge of the subject) they have
> sections on conflict resolution and production execution, in which
> iteration and rule execution order seems to still play prominently in
> discussion of the algorithm. e.g.
>
> "The engine continues to fire production instances, and to enter new
> match-resolve-act cycles, until no further production instances exist
> on the agenda. At this point the rule engine is deemed to have
> completed its work, and halts." and
>
> "the firing of activated production instances is not a feature of the
> Rete algorithm. However, it is a central feature of engines that use
> Rete networks. Some of the optimisations offered by Rete networks are
> only useful in scenarios where the engine performs multiple match-
> resolve-act cycles."
>
> and especially this...
>
> "Once all the current matches have been found, and corresponding
> production instances have been activated on the agenda, the engine
> determines an order in which the production instances may be "fired".
> This is termed conflict resolution, and the list of activated
> production instances is termed the conflict set. The order may be
> based on rule priority (salience), rule order, the time at which facts
> contained in each instance were asserted to the working memory, the
> complexity of each production, or some other criteria. Many engines
> allow rule developers to select between different conflict resolution
> strategies or to chain a selection of multiple strategies."
>
>
> On Dec 20, 5:35 pm, Holger Knublauch <hol...@topquadrant.com> wrote:
>> Hi Jeff,
>>
>> thanks for the use case. I am confident that your use case is valid. What we
>> need to discuss is whether such a feature should be part of SPIN (core) or
>> not. I have two reasons that would speak against adding such a property:
>>
>> 1) I believe you can already use SPARQLMotion to achieve what you want -
>> just chain together two instances of sml:ApplyTopSPIN with a different
>> sub-property of spin:rule each as sml:predicate.
>>
>> 2) Although the property spin:rulePropertyMaxIterationCount is part of the
>> core SPIN language, I don't think we should further strengthen the notion of
>> "iteration" in the language. SPIN is in theory executable with a
>> non-iterative engine that fires rules as needed using a RETE engine. While
>> TopSPIN currently doesn't implement this, it is certainly doable in the
>> future or for other engine implementations. I believe a spin:nextRuleSet
>> property could be regarded as a hint, but it might change the semantics
>> quite a bit if ignored. So how would RETE engines handle such an attribute?
>>
>> Does this make sense to you?
>>
>> Thanks,
>> Holger
>>
>> On Dec 21, 2011, at 5:54 AM, Schmitz, Jeffrey A wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Was perusing the old e-mails for a similar topic to the one below, I wanted
>>> to point out a case where I think order of execution does matter, and
>>> suggest a new option for controlling the order of execution of spin rules.
>>
>>> SHORT VERSION:
>>
>>> As it is right now, I believe the iterations of rules specified by
>>> different spin:rule subproperties are interleaved, even if you use the
>>> spin:nextRuleProperty property between the different spin:rule
>>> subproperties. E.g. Say you've setup the following spin rule subproperties:
>>
>>> 1. owl-rl-rule
>>> 2. owl-rl-dependent-rule
>>
>>> the order of execution of properties of the above kinds would be
>>
>>> 1. owl-rl-rules (iteration 1)
>>> 2. owl-rl-dependent-rules (interation 1)
>>> 3. owl-rl-rules (iteration 2)
>>> 4. owl-rl-dependent-rules (interation 2)
>>
>>> It would be nice if there were also a way that you could specify
>>> (spin:nextRuleSet?) that all iterations of rules of one spin:rule
>>> subproperty be executed before rules of a different spin:rule subproperty.
>>> Then the ordering would instead be:
>>
>>> 1. owl-rl-rules (iteration 1)
>>> 2. owl-rl-rules (iteration 2)
>>> 3. owl-rl-dependent-rules (interation 1)
>>> 4. owl-rl-dependent-rules (interation 2)
>>
>>> LONG VERSION:
>>
>>> Say you have a client database, and you want to look for possible duplicate
>>> entries. First you setup 2 subproperties of spin:rule:
>>
>>> 1. owl-rl-rule
>>> 2. owl-rl-dependent-rule
>>
>>> Then you come up with a owl-rl-dependent-rule that looks for client
>>> resources that have similar names and puts a "possibleMatch" property
>>> between them. Also say that you have attached the owlrl eq-ref rule to
>>> owl:Thing in your model using the owl-rl-rule property, and that you want
>>> to use that inference to "not" generate the possibleMatch property from a
>>> client resource to itself, so to your "similar names" rule you add:
>>
>>> NOT EXISTS {
>>> ?this owl:sameAs ?compCust .
>>> } .
>>
>>> Now, if the eq-ref rule runs first, then everything will be ok. However,
>>> if the "similar names" rule runs first, on the first interation the
>>> owl:sameAs properties will not have been generated yet by the eq-ref rule,
>>> thus you would get possibleMatch properties inferred from all clients to
>>> itself. In this case, you should be able to use the spin:nextRuleProperty
>>> to get around this, but I believe there are cases where this won't help
>>> you, as I will outline next.
>>
>>> As it is right now, I believe the iterations of rules specified by
>>> different spin:rule subproperties are interleaved, even if you use the
>>> spin:nextRuleProperty property between the different spin:rule
>>> subproperties. E.g. the order of execution of the properties above would be
>>
>>> 1. eq-ref (iteration 1)
>>> 2. "similar names" rule (interation 1)
>>> 3. eq-ref (iteration 2)
>>> 4. "similar names" rule (interation 2)
>>
>>> Continuing with these thoughts, it would be nice if there were a way that
>>> you could specify that all iterations of rules specified by one spin:rule
>>> subproperty be executed before rules specified by a different spin:rule
>>> subproperty.
>>> But what if in the example above you've also setup a owl-rl prp-inf on the
>>> inverse functional property of ssn. This is a rule that takes more than
>>> one interation to fully assign owl:sameAs in your model. In this case,
>>> even using nextRuleProperty won't help you since iteration 1 of the
>>> "similar names" rule will run before iteration 2 of prp-if, so in cases
>>> where two clients have the same SSN, and thus are for all intents and
>>> purposes the same client, you would still get a "possibleMatch" property
>>> inferred.
>>
>>> 1. prp-inf (iteration 1)
>>> 2. prp-inf (iteration 2)
>>> 3. "similar names" rule (interation 1)
>>> 4. "similar names" rule (interation 2)
>>
>>> jeff
>>
>>>> -----Original Message-----
>>>> From: topbraid-users@googlegroups.com [mailto:topbraid-
>>>> us...@googlegroups.com] On Behalf Of Scott Henninger
>>>> Sent: Tuesday, April 26, 2011 9:40 AM
>>>> To: TopBraid Suite Users
>>>> Subject: [topbraid-users] Re: Controlling the Execution Order of Rules
>>
>>>> Aziza; In the end the order of execution doesn't matter, except
>>>> perhaps for performance reasons (then use the rule ordering properties
>>>> described inhttp://spinrdf.org/spin.html#spin-rules-order). SPIN
>>>> will execute the set of rules until no new triples are created. This
>>>> means that if rule1 creates a triple that is used by rule2, then rule2
>>>> will execute on the new triple either in the current iteration or the
>>>> next iteration. Therefore the ordering of rule1 and rule2 doesn't
>>>> matter.
>>
>>>> For cases where the number of iterations need to be controlled, this
>>>> can be accomplished either with TopSPIN attributes or with the
>>>> spin:rulePropertyMaxIterationCount property.
>>
>>>> It's still unclear what the concern is. Is it ensuring forward-
>>>> chaining of rules or rule ordering for optimization strategies? For
>>>> either case, the execution properties for SPIN rules are very flexible
>>>> and can be designed to run the rules to meet your specific criteria.
>>>> We'd be happy to help out with more specific requirements.
>>
>>>> -- Scott
>>
>>>> On Apr 26, 12:54 am, actress <aziza.mamadolim...@gmail.com> wrote:
>>>>> If there is no ordering how SPIN fires the rules - this is my
>>>>> concern.
>>>>> We just want to clarify if there are a lot of rules ready to fire
>>>>> without any control execution how would SPIN decide which one to
>>>>> choose?
>>>>> Aziza
>>
>>>>> On Apr 26, 12:48 pm, Scott Henninger <shennin...@topquadrant.com>
>>>>> wrote:
>>
>>>>>> Hello Aziza; SPIN rules will execute all rules from the spin:rule
>>>> and
>>>>>> subproperties of spin:rule. There is no inherent ordering of these
>>>>>> rules. What kind of ordering is you colleague expecting?
>>
>>>>>> -- Scott
>>
>>>>>> On Apr 25, 11:35 pm, aziza <aziza.mamadolim...@gmail.com> wrote:
>>
>>>>>>> Inhttp://spinrdf.org/spin.html#spin-rules-libraryyou'resayingthat
>>>>>>> by default all rules may be executed in a "random order" provided
>>>> they
>>>>>>> are not controlled by execution engine. But some of my collegue
>>>>>>> disagree with this statement, particularly with "random order
>>>> rule
>>>>>>> execution by default".Can you give an argument for supporting
>>>> your
>>>>>>> statement?
>>>>>>> --Thanks,Aziza- Hide quoted text -
>>
>>>>>> - Show quoted text -
>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Group "TopBraid Suite Users", the topics of which include TopBraid
>>>> Composer,
>>>> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
>>>> To post to this group, send email to
>>>> topbraid-users@googlegroups.com
>>>> To unsubscribe from this group, send email to
>>>> topbraid-users+unsubscr...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/topbraid-users?hl=en
>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
>>> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
>>> To post to this group, send email to
>>> topbraid-users@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> topbraid-users+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/topbraid-users?hl=en
>
> --
> You received this message because you are subscribed to the Google
> Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
> To post to this group, send email to
> topbraid-users@googlegroups.com
> To unsubscribe from this group, send email to
> topbraid-users+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
topbraid-users@googlegroups.com
To unsubscribe from this group, send email to
topbraid-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
