Thanks for the confirmation. On Mon, Feb 22, 2010 at 8:28 AM, Scott Henninger <[email protected] > wrote:
> Tim; SPIN applies rules to classes and their subclasses. If you need > to run rules defined in different classes in a sequence - one set of > rules after another - then create a SPARQLMotion script with an > ApplyTopSPIN module for each rule set. Specify the set with a sub- > property of spin:rule and use the sml:predicate property in > ApplyTopSPIN to state which rule set to run. E.g. the following would > run the same example rule set across all class definitions: > :ApplyTopSPIN_1 sml:predicate spin:rs1 . > :ApplyTopSPIN_1 sm:next :ApplyTopSPIN_2 . > ... > :ApplyTopSPIN_2 sml:predicate spin:rs2 . > > Rules would then be defined in spin:rs1 and spin:rs2 for class > definitions. > > -- Scott > > On Feb 22, 7:11 am, Tim Darr <[email protected]> wrote: > > What is the scope of the rule sequencing? Is it the class to which the > rule > > is attached, or is it global? > > > > For example, if I have two unrelated classes A and B, and two rules ruleA > > (attached to class A) and ruleB (attached to class B) and specify that > ruleB > > is the nextRuleProperty of ruleA, will ruleA always precede ruleB? > > > > I have implemented something like this and it appears that the sequencing > is > > not working as expected ... > > > > On Fri, Feb 19, 2010 at 4:37 PM, Scott Henninger < > [email protected] > > > > > > > > > wrote: > > > Andrew; Rules in SPIN can be ordered by using spin:nextRuleProperty > > > with groups of rules. The steps to do this are as follows: > > > 1. Create sub-properties of spin:rule (e.g. spin:rs1, spin:rs2) > > > 2. Order spin:nextRuleProperty, e.g. the following would set rule to > > > run a rs1, rs2, rule: > > > spin:rs1 spin:nextRuleProperty spin:rs2 > > > spin:rs2 spin:nextRuleProperty spin:rule > > > 3. add rules to the properties as needed > > > > > This may do what you need. Are you saying that in the end you want > > > labels for A, B, and C. Or just C? If it's just C, then you can take > > > your rules for generating labels for A and B an place them in SPIN > > > functions. Then just create a rule for C that would look something > > > like: > > > > > CONSTRUCT > > > { ?this rdfs:label ?label > > > } > > > WHERE > > > { LET (?alabel := :getLabelForA()) > > > LET (?blabel := :getLabelForB()) > > > LET (?label := smf:buildString("{?alabel}--{?blabel}")) > > > } > > > > > or, in more compact form: > > > LET (?label := smf:buildString("{?1}--{? > > > 2}", :getLabelForA(), :getLabelForB())) > > > > > <I know the inference engine loops over until there are no new > > > triples.> > > > > > You can set the engine to run a single pass only in Configure > > > Inferencing. > > > -- Scott > > > > > On Feb 19, 1:46 pm, AndrewB <[email protected]> wrote: > > > > I know this goes against how a ontology runs but is there a way to > > > > force priorty on spin rules. > > > > > > Example(Bad). I have 3 classes ABC A and B have a spin rule to > > > > generate there label > > > > > > C generates its label out of A's and B's Label. > > > > > > So when I run i get a version of C's label with A and B having no > > > > label > > > > and version with A and B having a label. > > > > > > Although both are correct, i really only care about the longer C > > > > label. So either i say run these rules first somehow. Or I filter > > > > out the shorter of 2 labels when their are 2. But then I would > > > > probably hit a infinite loop. > > > > > > I can do this with sparql motion but I'm trying to avoid it. > > > > > > I know the inference engine loops over until there are no new > triples. > > > > > > Thanks for any help. you can provide > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "TopBraid Composer Users" group. > > > To post to this group, send email to > > > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<topbraid-composer-users%[email protected]> > <topbraid-composer-users%[email protected]<topbraid-composer-users%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/topbraid-composer-users?hl=en. > > > > -- > > Tim Darr > > [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Composer Users" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<topbraid-composer-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/topbraid-composer-users?hl=en. > > -- Tim Darr [email protected] -- You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en.
