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] 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] <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
<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
<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
<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.
--
-- 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.