Holger,

I think I actually looked into the QueryExecution option you mention. The 
problem is, that often the final Query (with bound variables) needs to be 
executed remotely, and in Jena this is done using a different 
QueryEngineHTTP class, which does not support setInitialBindings(). I've 
even written to the Jena list about this:
http://mail-archives.apache.org/mod_mbox/jena-users/201201.mbox/%[email protected]%3E

So as far as I remember, I was happy to find TemplateCall.getQueryString() 
as it allowed me to do both things: to bind arguments to SPIN template, and 
to execute the resulting query on a remote endpoint. The only thing missing 
was the support of the spin:text syntax :)

Do you see some other way around this?

Martynas

2013 m. kovas 19 d., antradienis 02:01:47 UTC+2, Holger Knublauch rašė:
>
> On 3/19/2013 9:39, [email protected] <javascript:> wrote: 
> > Hey Holger, 
> > 
> > thanks for the explanation. I'm using SPIN API in the implementation 
> > of Graphity Linked Data platform which has the following processing 
> model: 
> > - request URI is matched against resource templates (classes) in a 
> > sitemap ontology like this one: 
> > 
> https://raw.github.com/Graphity/graphity-ldp/rf-input-mode/src/main/resources/org/graphity/platform/ontology/sitemap.ttl
>  
> > - each of the template classes has a DESCRIBE/CONSTRUCT spin:Template 
> > attached to it via spin:constraint. Common SPIN Templates are grouped 
> > in a separate ontology: 
> > 
> https://raw.github.com/Graphity/graphity-ldp/rf-input-mode/src/main/resources/org/graphity/platform/vocabulary/gp.ttl
>  
> > Each of the templates also indicate the source RDF dataset of the 
> > resource, which normally has a SPARQL endpoint. 
> > - SPARQL query string is generated from the TemplateCall, the request 
> > URI is bound to ?this variable afterwards, and the query is executed 
> > on the endpoint of the dataset of the resource 
> > - the result RDF is returned as the response (if the resource matched 
> > no template or the query result is empty, 404 is returned) 
> > 
> > Having an RDFNode of the spin:constraint object, I'm converting it to 
> > TemplateCall using SPINFactory.asTemplateCall() and run 
> > getQueryString() to generate the SPARQL query string. Around line #400 
> > here: 
> > 
> https://github.com/Graphity/graphity-ldp/blob/rf-input-mode/src/main/java/org/graphity/platform/model/ResourceBase.java
>  
> > Afterwards I'm binding ?this variable to a URI value using simple 
> > string replacement. 
> > 
> > If there is a better alternative to generate SPARQL query strings from 
> > TemplateCall (and maybe bind variable(s) to URIs at the same time), I 
> > will be happy to refactor my code. 
>
> I have spent some time refactoring yesterday to get rid of most usages 
> of TemplateCall.getQueryString() and I believe I will deprecate or 
> delete it altogether. The alternative in your case is to create a 
> QueryExecution instead of a Query. In that QueryExecution you would use 
> qexec.setInitialBindings() to tell it about the argument values of the 
> template call (and also ?this in your case - the text replacement in the 
> query string looks fragile). I have added a convenience method to 
> TemplateCallImpl: 
>
>      @Override 
>      public QuerySolution getInitialBinding() { 
>          QuerySolutionMap map = new QuerySolutionMap(); 
>          Map<String,RDFNode> input = getArgumentsMapByVarNames(); 
>          for(String varName : input.keySet()) { 
>              RDFNode value = input.get(varName); 
>              map.add(varName, value); 
>          } 
>          return map; 
>      } 
>
> This produces the QuerySolutionMap which you can pass to 
> qexec.setInitialBindings(). You then just need the "static" query string 
> from the template's body - which is the same for all instances of the 
> template calls. In order to get the ARQ Query object itself, something 
> like the following should work 
>
> ARQFactory.get().createQuery((org.topbraid.spin.model.Query)template.getBody());
>  
>
>
> HTH 
> Holger 
>
>

-- 
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary 
Network (EVN), TopBraid Composer, TopBraid Live,
TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages 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 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/groups/opt_out.


Reply via email to