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 in http://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
