Hi Holger, What we currently use in our system is more along the lines of the "executeBefore" property. We call this property "successor". For rules, as you say, it could be associated with the rule queries themselves and allow chaining of individual rule queries. Any specific class would only have the first rule associated with it, but the executor would would follow the chain to determine the full rule ordering. I don't know SPARQLMotion too well, but would this be analogous to specifying a SPARQLMotion chain instead of an individual query as a SPIN rule?
In our system too, it's more than just a matter of execution order. We also have to determine IF we are going to fire certain rules based on the current mode of the system. E.g. we only fire importRule's when in "Import" mode, and only fire exportRule's when in Export mode. We implement this by, as you say, creating subproperties so that the rules can be grouped according to the mode in which they are to execute. These modes are built (i.e. hardcoded) into our engine, so it can easily determine which rules to execute. Another possibility for rules would be to allow adding an "if" property to each rule that links to an ASK query. The executor would first execute the ASK query to determine if the rule itself would be executed. This way runtime checks could be made (e.g. system mode) to determine if individual rules are to be executed. Finally, I forgot to mention we'd still like to have the ability for Functions to return multiple values in its return variable as opposed to just a single value which I think it is limited to right now (unless you added this capability already and I missed it). The more I write, the more I get the feeling that what I'm suggesting is pretty much summed up in the last sentence of the first paragraph (SPARQLMotion Rules built into SPIN). This may be stepping on some code you'd rather not incorporate into SPIN though. > -----Original Message----- > From: Holger Knublauch [mailto:[email protected]] > Sent: Tuesday, August 11, 2009 5:49 PM > To: [email protected] > Subject: [tbc-users] Re: ANN: TopBraid SPIN API 1.0.2 > > > Hi Jeff, > > this is actually an interesting idea. A generic solution > would be to assign some numeric value to the sub-properties, > e.g. triples > > my:importRule spin:weight 10 . > my:exportRule spin:weight 20 . > > where rules using properties with smaller weight would be > executed before the others. Using a sub-property of spin:rule > would provide a natural grouping of rules into categories. > Alternative to a numeric value would be an explicit > spin:executeBefore to relate two rule properties. > > Would this be sufficient for your use case, and which > solution sounds cleaner? > > Thanks, > Holger > > > On Aug 11, 2009, at 1:10 PM, Schmitz, Jeffrey A wrote: > > > > > We certainly have added our own subclasses to spin:rule to control > > rule execution, but I think they may be too specific to our > > application to add them to the general spin model. > > > > Perhaps some kind of directional flow sub-properties (e.g. > importRule, > > exportRule) that could be used directly or could themselves > be further > > be subclassed would be helpful. But perhaps even that wouldn't be > > general enough. > > > > It's not too hard to add and mechanize such concepts locally, but > > perhaps you don't want too much fragmentation so the > standard SPIN API > > can do more of the work? > > > > > >> -----Original Message----- > >> From: Holger Knublauch [mailto:[email protected]] > >> Sent: Tuesday, August 11, 2009 2:53 PM > >> To: [email protected] > >> Subject: [tbc-users] ANN: TopBraid SPIN API 1.0.2 > >> > >> > >> There is a new version of the SPIN API available from > >> > >> http://www.topquadrant.com/topbraid/spin/api/ > >> > >> New features include support for Jena 2.6 and for the ARQ keywords > >> NOT EXISTS and SERVICE. Note that the current release of > TBC (3.1.1) > >> does not yet support these two keywords in its SPIN RDF syntax. > >> > >> BTW I would appreciate input on how to improve SPIN. For > example if > >> you have requirements for additional properties to control the > >> execution of rules. > >> > >> Cheers, > >> Holger > >> > >> > >>> > >> > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
