Holger, Thanks again for helping me out!
In the example you provided, the output does not include the triples that were sent in from the INSERT. I need to be able to: 1. Build some request-scoped triples 2. Run inferences within the request scope 3. Query the request-scoped triples (both inserted and inferred) to generate SWON 4. Throw away all of the new triples (both inserted and inferred) that belong to the current request. I thought that using ui:tempGraph was the correct way to do this. If I can't use ui:tempGraph, what is the correct approach? Do I need to reference ui:tempGraph in my spin rules so that the triples show up in the right context? On Tuesday, March 7, 2017 at 10:33:19 PM UTC-5, Holger Knublauch wrote: > > Hi Russell, > > I believe the issue is that the SWP below uses a ui:setContext which > basically makes the inferred triples invisible to the downstream processes. > The correct order is illustrated in the attached example, which runs > inferences over kennedysSPIN and prints JSON in the format that you have > proposed. (Note that I also took out the ?s in the GRAPH ui:tempGraph > because it was not finding any matches in the kennedys example.) But the > big picture is that sml:ApplyTopSPIN will run inferences on the current > query graph (the surrounding context) and the children of it are the > inferred triples. > > HTH > Holger > > > On 8/03/2017 8:45, Russell Morrisey wrote: > > Holger, > > We are proceeding with TBL, using federated query to solve the volume > issue. > > I reviewed your SM script. In my use case, I really don't want the > inferred triples to be saved off to a file. What I think I want to do is > invoke the *sml:ApplyTopSPIN* function in a SWP endpoint. > > I tried this approach, but could not get it to work. Can you help me > figure out what I'm doing wrong? > > Here is my prototype SWP endpoint. > Currently, the query is returning no results. If I move the query's "?s ?p > ?o" inside the GRAPH block, I can see the inserted triples, but no inferred > triples are showing up. > > <ui:group> > <sml:ApplyTopSPIN sml:replace="true"> > <ui:setPrefix ui:namespace="http://www.w3.org/2000/01/rdf-schema#"; > <http://www.w3.org/2000/01/rdf-schema#> ui:prefix="rdfs"/> > <ui:setPrefix ui:namespace= > "http://knowledge.cscglobal.com/question-answer/1.0/api/schema/"; > <http://knowledge.cscglobal.com/question-answer/1.0/api/schema/> > ui:prefix="qnaApi"/> > <ui:setPrefix ui:namespace= > "http://knowledge.cscglobal.com/question-answer/1.0/api/data/"; > <http://knowledge.cscglobal.com/question-answer/1.0/api/data/> > ui:prefix="qnaData"/> > <ui:setContext ui:queryGraph="{= ui:graphWithImports(< > http://knowledge.cscglobal.com/question-answer/1.0/api/rules>) }" > ui:silentTransactions="true"> > <ui:update ui:updateQuery="{! > INSERT { > GRAPH ui:tempGraph { > ?qnaRequest a qnaApi:QuestionKnowledgeRequest . > ?qnaRequest qnaApi:orderTypeCode > "TCC" . > ?qnaRequest qnaApi:stateName > "Delaware" . > } . > } > WHERE { > BIND > (spif:buildUniqueURI("qnaData:{?1}", spif:generateUUID()) AS > ?qnaRequest) . > } }"/> > <swon:Object> > <swon:Value arg:name="order"> > <swon:Object> > <swon:Value arg:name="foo" arg:value="bar"/> > <swon:Value arg:name="services"> > <swon:Array> > <ui:forEach ui:resultSet="{# > SELECT ?s ?p ?o > WHERE { > GRAPH ui:tempGraph { > ?s a > qnaApi:QuestionKnowledgeRequest . > } . > ?s ?p ?o . > } > LIMIT 10 }" ui:separator=","> > <ui:br/> > <swon:Object> > <swon:Value arg:name="s" > arg:value="{= ?s }"/> > <swon:Value arg:name="p" > arg:value="{= ?p }"/> > <swon:Value arg:name="o" > arg:value="{= ?o }"/> > </swon:Object> > </ui:forEach> > </swon:Array> > </swon:Value> > </swon:Object> > </swon:Value> > </swon:Object> > </ui:setContext> > </sml:ApplyTopSPIN> > </ui:group> > > Thanks! > > > On Sunday, February 19, 2017 at 5:46:26 PM UTC-5, Holger Knublauch wrote: >> >> Ok, if there is a TBL server in the mix then we can rely on SPARQLMotion >> (or SWP) to perform inferencing. This could theoretically happen on the fly >> for each request, e.g. by calling a SPARQLMotion script with parameters. >> But this would have the server re-apply the inferences for each individual >> request, and may not be performant. So one possible work flow would be to >> have a small SM script that applies inferences and produces a new named >> graph (e.g. TTL file or TDB), and then query that new named graph with the >> usual SPARQL end point. You would call this script before you want to query >> or periodically if the data changes. >> >> I have attached an SM file that you can put into your TBL workspace (e.g. >> via project upload). An example call using TBC-ME would be >> >> >> http://localhost:8083/tbl/sparqlmotion?id=createInfGraph:CreateInfGraph&graphName=http://topbraid.org/examples/kennedysSPIN >> >> The script looks like: >> >> >> >> The produces a stand-alone graph with all inferences which you can then >> query using the SPARQL end point, e.g. >> >> SELECT * >> WHERE { >> GRAPH <http://topbraid.org/examples/kennedysSPIN-withSPIN> >> <http://topbraid.org/examples/kennedysSPIN-withSPIN> { >> ?subject a <http://topbraid.org/examples/kennedys#Person> >> <http://topbraid.org/examples/kennedys#Person> . >> } >> } ORDER BY ?subject >> >> HTH >> Holger >> >> >> On 18/02/2017 6:05, Russell Morrisey wrote: >> >> Holger, >> >> Thanks for your reply. >> >> The current (prototype) version of the app calls out to the SPARQL REST >> endpoint in TopBraid Live: >> http://localhost:8083/tbl/sparql >> >> If there is a better way I should do this, please point me to the right >> approach. >> >> I don't know how to tell the sparql endpoint that it should execute SPIN >> rules. The SPIN rule declaration is stored in the ontology as part of the >> Class definition. Here is the Class definition, including the rule >> declaration: >> >> spinTest:SpinTest >> rdf:type owl:Class ; >> spin:rule [ >> rdf:type sp:Construct ; >> sp:templates ( >> [ >> sp:object "spin:rule OK" ; >> sp:predicate spinTest:testResult ; >> sp:subject [ >> sp:varName "test" ; >> ] ; >> ] >> ) ; >> sp:where ( >> [ >> sp:object spinTest:SpinTest ; >> sp:predicate rdf:type ; >> sp:subject [ >> sp:varName "test" ; >> ] ; >> ] >> ) ; >> ] ; >> rdfs:label "Spin test" ; >> rdfs:subClassOf owl:Thing ; >> . >> >> I have tested out this rule using "Run Inferences" in Composer, but I >> don't understand how to apply it on the server. >> >> Thanks >> >> >> On Thursday, February 16, 2017 at 11:40:58 PM UTC-5, Holger Knublauch >> wrote: >> >>> Hi Russell, >>> >>> in your question you indicate that you have a Java app, so I assume this >>> code runs outside of the TBL server. Assuming you want to perform the >>> inferences in your code using the SPIN API, I guess there is no difference >>> between TBL or any 3rd party triple store - you can for example use the >>> SPARQL end point to retrieve the original triples. Everything else is under >>> full control of your application. >>> >>> Is this the scenario you are describing? >>> >>> Thanks, >>> Holger >>> >>> >>> On 17/02/2017 8:59, Russell Morrisey wrote: >>> >>> I have an ontology with a *spin:rule* that I've built and tested in >>> TopBraid Composer. >>> >>> I'd like to build an app that has the following flow: >>> >>> 1. Load some graph data from a triple store >>> 2. Assert some triples from the client into a temporary graph >>> (preferably a session-scoped graph) >>> 3. Run my spin:rules and store the new triples in the temporary graph >>> 4. Query the temporary graph and send the results back to the caller. >>> >>> My app is a Java app which does not use SWP. >>> >>> How can I apply spin:rules this way when my ontology is deployed in >>> TopBraid Live? >>> How can I apply spin:rules this way when my ontology is in a 3rd-party >>> triple store? >>> Which 3rd-party triple stores support this? >>> >>> I am working on figuring out the answers to these questions. Any help >>> would be appreciated. >>> >>> -- >>> You received this message because you are subscribed to the Google Group >>> "TopBraid Suite Users", the topics of which include the TopBraid Suite >>> family of products and its base technologies such as SPARQLMotion, SPARQL >>> Web Pages and SPIN. >>> To post to this group, send email to [email protected] >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Group >> "TopBraid Suite Users", the topics of which include the TopBraid Suite >> family of products and its base technologies such as SPARQLMotion, SPARQL >> Web Pages and SPIN. >> To post to this group, send email to [email protected] >> --- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- > You received this message because you are subscribed to the Google Group > "TopBraid Suite Users", the topics of which include the TopBraid Suite > family of products and its base technologies such as SPARQLMotion, SPARQL > Web Pages and SPIN. > To post to this group, send email to [email protected] > <javascript:> > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include the TopBraid Suite family of products and its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
