Holger,
from the perspective of my use case, the remote query execution is not
different from a local one. But this has to do with differences inside
Jena's implementation -- you can find Andy's answer in my previous email.
The SERVICE option is indeed hacky and fails on two points:
- it adds complexity and reduces readability. My code is already generating
DESCRIBE by wrapping SELECT as subquery, SERVICE would make this even more
complex. I'm also planning to provide user interface for query string
input, to be attached as sp:text, so readability is important.
- it is useful to have queries that are equivalent independently of where
they are going to be executed: on a local Model, or on a remote endpoint.
SERVICE breaks this.
The string replacement approach is also ugly, I agree.
Can you at least keep the TemplateCall.getQueryString() method? For me it
would be more important to have it working as it is than to have sp:text
syntax working (although the combination of the two would be great).
Maybe we can find some middle ground? I'll think about this, but obviously
you know the inner workings of SPIN better than me.
Martynas
2013 m. kovas 20 d., trečiadienis 01:27:27 UTC+2, Holger Knublauch rašė:
>
> I may be confused but how is a remote query execution different from
> using SERVICE inside of the WHERE clause? AFAIK the latter would support
> bindings as it's executed by the algebra. A hacky work-around would then be
> to create a query
>
> SELECT *
> WHERE {
> {
> BIND (... AS ?arg1) .
> ... for all other arguments
> }
> SERVICE <url> {
> original where clause of template
> }
> }
>
> I do have an algorithm in our SPARQLMotion code that does hard-binding by
> doing string substitutions, but I wouldn't consider this safe (e.g. it
> would fail if someone has a string such as "Hello ?arg1" and it would
> definitely fail if you have bound(?arg1) and ?arg1 gets substituted with a
> constant. It would also substitute the variables in the SELECT head, making
> this whole approach rather ugly.
>
> So, would the above work for you?
>
> Thanks,
> Holger
>
>
> On 3/19/2013 18:32, [email protected] <javascript:> wrote:
>
> 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] 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] <javascript:>
> To unsubscribe from this group, send email to
> [email protected] <javascript:>
> 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] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
--
-- 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.
