Alison; Ah, didn't realize you were using INSERT. This also explains your infinite loop. See below.
First. let's be clear that SPIN is build on SPARQL, including SPARQL 1.1 as it stands today. DELETE is a SPARQL 1.1 Update operation. For more on SPARQL Update syntax, please see http://www.w3.org/TR/sparql11-update/. Next let's get some terminology straight. An asserted triple is a triple defined in a file or data store. When loaded into memory the asserted graph is the set of all triples defined from the source. Asserting a new triple and saving will result in the newly asserted triple being saved. An inferred triple is a triple that is defined in the inferred graph. The inferred graph is separate from the asserted graph. Composer will display the union of asserted and inferred triples (note that anything with a violet background is an inferred triple). The inferred graph, the set of inferred triples, is never saved to memory. (Unless the user chooses to save the inferred graph or assert the triples in the graph.) To do a data modification, note that an INSERT/DELETE combination is needed. For example, using our kennedys model the following rule defined on kennedys:Peron will modify all names from "Firstname Lastname" to "Lastname, Firstname". Note that it deletes the old value and inserts the new one: DELETE { ?this kennedys:name ?oldName . } INSERT { ?this kennedys:name ?newName . } WHERE { ?this kennedys:name ?oldName . BIND (spif:indexOf(?oldName, " ") AS ?spaceIndex) . BIND (fn:substring(?oldName, 0, ?spaceIndex) AS ?fname) . BIND (fn:substring(?oldName, (?spaceIndex + 2), fn:string-length(? oldName)) AS ?lname) . BIND (fn:concat(?lname, ", ", ?fname) AS ?newName) . } Note that this rule defines an infinite loop. Since the INSERT asserts new data, the rule will always find new data to execute on. So the first pass may see "Joe Smith" and convert to "Smith, Joe". The second pass will see "Smith, Joe" and convert to "Joe, Smith," etc. The recommendation I'd make is to reserve spin:rule as a CONSTRUCT- only rule that can be executed as a forward-chaining rule set. This means it will execute until no more new triples are created. For any SPARQL Update query, I'd suggest creating a subproperty of spin:rule and setting the spin:rulePropertyMaxIterationCount to 1. An INSERT/DELETE should only be executed once, and I can't think of many exceptions to that rule. -- Scott On Sep 9, 8:52 am, Alison Callahan <[email protected]> wrote: > Thanks, Scott. I was indeed using an INSERT statement in a spin:rule ... > this leads me to another question: Is there an equivalent to a SPARQL DELETE > which would remove a triple from an inferred graph? (I realize that I can > use CONSTRUCT instead of INSERT, but I don't know if there is a similar > alternative for DELETE). > > Alison > . > On Thu, Sep 8, 2011 at 5:57 PM, Scott Henninger > <[email protected]>wrote: > > > Aloson; SPIN rules by itself will not assert triples unless you use > > INSERT in the query. Once the INSERT has been executed, the triple is > > asserted permanently. That is the desired effect for SPARQL INSERT. > > > Using CONSTRUCT is a far more common use case for SPIN. A SPIN rule > > using CONSTRUCT will add triples to the inferred graph only. No > > triples are asserted and you cannot save the inferences unless you > > assert them first. Re-setting inferences should remove all inferred > > triples. If you have an example otherwise, we'd like to hear more > > details so we can reproduce. > > > -- Scott > > > On Sep 8, 4:44 pm, Alison Callahan <[email protected]> wrote: > > > Hello all, > > > > I am using TopBraid Composer 3.5.1, Maestro edition in Ubuntu 11.04. > > > > I have noticed that even after I reset inferences, triples that were > > created > > > by a spin:rule that I had previously deleted are still asserted after I > > > re-run TopSPIN. Is there a setting that I need to change to prevent > > triples > > > created by spin:rules from being permanently saved even after I reset > > > inferences? > > > > Thanks, > > > > Alison > > > -- > > 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 > > [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-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 [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-users?hl=en
