Another possibility for the rule executor stuff is to use the weights. Might make the engine's job a lot easier, but it does seem a bit kludgy to me.
Jeff Work: 314-232-1997 Cell: 636-448-5990 > -----Original Message----- > From: Schmitz, Jeffrey A > Sent: Friday, August 14, 2009 10:27 AM > To: [email protected] > Subject: [tbc-users] Re: ANN: TopBraid SPIN API 1.0.2 > > > See notes below > > Jeff > > > > > -----Original Message----- > > From: Holger Knublauch [mailto:[email protected]] > > Sent: Thursday, August 13, 2009 12:08 PM > > To: [email protected] > > Subject: [tbc-users] Re: ANN: TopBraid SPIN API 1.0.2 > > > > > > Thanks for the detailed response, Jeff. There seem to be a few > > different requirements: > > > > 1) The ability to specify the rule order per rule (similar to > > SPARQLMotion) > > Possible solution: a new property spin:next which links two > > rules/ template calls. > > Issues: the rule metadata would currently be hard to > see (in the > > UI), so I would need > > to create some form infrastructure such as a warning icon > > indicating that there is > > more in the nested form. It will also make sense to have > > context menu items to > > set those values on the form. > Agreed. Another issue is how this would work with rules that > are associated with different classes in a model, but that > you would still like to be executed in a specific order. I > really like being able to attach the rules to the classes > they are most associated with, but there would also need to > be the "next" link to enforce order amongst all the rules > that exist in a model. This could get VERY tricky for the > engine I would think for a lot of reasons. It almost > requires a higher level rule sequencer of some sort to be > associated with the whole model. The rules would still be > associated with specific classes, but to get executed would > require them to be linked into the "rule executor" list. > Maybe this list gets built automatically when rules are added > so things would pretty much work as they do today if you > require no order, but the list would be editable by the user? > I'm sure I haven't thought it all through but maybe there is > something there. > > > > > 2) The ability to specify the rule order per group (using > > sub- properties of spin:rule) > > Possible solution: a new property spin:nextProperty > which links > > two properties. > > For example, > > my:importRule rdfs:subPropertyOf spin:rule ; > > spin:nextProperty > spin:rule . > > would make sure that all importRules are executed > before the > > other spin:rules. > > Issues: none really, so I think this might be a good > start as it > > requires least > > infrastructure. > Interesting. Not something we've run into needing since our > engine is aware of the subproperties, so sequencing that does > occur is hardcoded in the engine and not configurable, but > for general purpose like SPIN, yes, it would need to be > configurable doing something like you say. > > > > 3) SPIN Functions that return multiple values - this is a separate > > topic - i.e. support for > > user-defined magic predicate (property functions) in > SPIN. This > > is straight forward > > to do, but quite some work. I'll put it on my list though. I > > wish SPARQL had some > > more explicit way of handling such multi-valued > functions, for > > example a > > FOR (?x := my:function(?a, ?b)) . > > similar to LET. This would make it clearer that we > are talking > > about a real function > > and avoids the ugliness of passing in multiple > arguments using > > an rdf:List structure. > Yes, this would really take SPIN Functions to another level I > think and allow creation of much more reusable SPARQL snippets. > > > > > Holger > > > > > > > > On Aug 12, 2009, at 8:45 AM, Schmitz, Jeffrey A wrote: > > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
