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 -~----------~----~----~----~------~----~------~--~---
