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.


Reply via email to