Hi Paul,
Thank you very much for your enlightening explanation. I now understand
why it could not work.
But how could I achieve the aim of getting the right bits out of the
remote dataset? In the use case which is analogous to the example given
here there are just a dozen labels in the VALUES clause (which could be
transformed to a UNION statement). They select about 5000 uris out of a
unrestricted set of about 1 million In another use case I would ask for
about 100,000 uris out of 10,000,000 in the remote dataset. So fetching
all the data and applying the restriction locally is not an option.
The in my naive eyes most logical statement
CONSTRUCT { $book dc:title $title }
WHERE {
SERVICE <http://sparql.org/books/sparql>
{ SELECT ?book ?title
WHERE { $book dc:title $title }
VALUES ?book {
<http://example.org/book/book1>
<http://example.org/book/book2>
}
}
}
which I had tried first gave me an Error 500: Server Error. In the
server log, I found
19:41:35 WARN Fuseki :: [81] RC = 500 : null
Not implemented
at
com.hp.hpl.jena.sparql.graph.NodeTransformOp.transform(NodeTransformOp.j
ava:154)
at
com.hp.hpl.jena.sparql.algebra.op.OpTable.apply(OpTable.java:63)
at
com.hp.hpl.jena.sparql.algebra.Transformer$ApplyTransformVisitor.visit0(
Transformer.java:270)
...
- so perhaps - hopefully - the syntax above will be implemented
eventually?
VALUES/ex-BINDINGS is one of my favorite SPARQL 1.1 statements, because
it allows restrictions with possibly long lists of values collected
out-of-band. I was happy that in the current Fuseki implementation it is
evaluated quite efficiently. My feeling is that it should be possible to
pass a VALUES clause explicitly as a part of a SERVICE subclause.
Not sure, what you intended with appending a VALUES clause silently.
Does this refer to prior bindings within the main clause? This would
make a lot of sense, but perhaps it could be better achieved with some
explicit syntax under the users responsibility. In any case, an implicit
VALUES clause should not interfere with an explicit one given by the
user.
Cheers, Joachim
> -----Original Message-----
> From: gea...@gmail.com [mailto:gea...@gmail.com] On Behalf Of
> Paul Gearon
> Sent: Friday, July 06, 2012 6:46 PM
> To: users@jena.apache.org
> Subject: Re: Fuseki VALUES in combination with GROUP BY,
> SERVICE and CONSTRUCT/INSERT
>
> Hi,
>
> It's the level at which the VALUES are being applied. They
> happen after the SERVICE has returned. To see this, try
> pulling out the sections of your query and use SELECT.
>
> Starting with the sub query inside the SERVICE:
>
> SELECT ?book (COUNT(?title) AS ?dummy)
> WHERE { $book dc:title $title }
> GROUP BY $book
>
> This provides a count of "1" for all 7 book.
>
> If you apply the VALUES here:
>
> SELECT ?book (COUNT(?title) AS ?dummy)
> WHERE { $book dc:title $title }
> GROUP BY $book
> VALUES ?title {
> "Harry Potter and the Chamber of Secrets"
> "Harry Potter and the Philosopher's Stone"
> }
>
> Then it gets restricted to a count of "1" for the two specified books.
>
> However, when the VALUES are applied outside of the SERVICE
> you see all 7 books come back. So this shows that the VALUES
> did not get applied until the end of the SERVICE request. Of
> course, once the SERVICE request has returned, there are no
> bindings for ?title, so these values have no effect. The same
> can be seen if you apply VALUES at the end of a local query:
>
> SELECT ?book ?dummy {
> SELECT ?book (COUNT(?title) AS ?dummy)
> WHERE { $book dc:title $title }
> GROUP BY $book
> }
> VALUES ?title {
> "Harry Potter and the Chamber of Secrets"
> "Harry Potter and the Philosopher's Stone"
> }
>
> The subquery binds ?book and ?dummy and returns, at which
> point the results are merged with the bindings for ?title.
> Since ?title isn't in the final result, this gets projected
> out, and the values have no final effect.
>
> Also, your final query using the "federated query without the
> aggregation may have been misleading you:
>
> CONSTRUCT { $book dc:title ?title }
> WHERE {
> SERVICE <http://sparql.org/books/sparql>
> { SELECT ?book ?title
> WHERE { $book dc:title $title }
> }
> VALUES ?title {
> "Harry Potter and the Chamber of Secrets"
> "Harry Potter and the Philosopher's Stone"
> }
> }
>
> The SERVICE section is actually returning all 7 books,
> including the binding for ?title. You subsequently apply the
> VALUES, and this reduces the bindings to just those 2
> cases.If you remove the ?title from the inner SELECT you see
> all 7 books next to each of the 2 titles again (for a total
> of 14 results).
>
> I need to look at the Federated query document more
> carefully, but I was expecting that an important use case for
> VALUES was to help reduce network transfers, meaning that
> when SERVICE blocks are sent over the network the engine will
> silently append a VALUES clause to the query.
> If ARQ is doing the correct thing here (and I suspect that it
> is), then this makes these behind-the-scene optimizations
> harder since the engine will only be able to append VALUES
> bindings if they only bind variables that are being projected
> by the query in the subselect.
>
>
> Regards,
> Paul Gearon
>
> On Fri, Jul 6, 2012 at 9:40 AM, Neubert Joachim
> <j.neub...@zbw.eu> wrote:
> > I try to query a current (rev 1356848) Fuseki endpoint with
> a list of
> > VALUES and to update another one with aggregated results.
> It did not
> > work as expected, and I could reproduce the behaviour with the
> > standard books endpoint and an a (somehow contrieved) query:
> >
> > When I execute the following statement
> >
> > CONSTRUCT { $book dc:description ?dummy }
> > WHERE {
> > SERVICE <http://sparql.org/books/sparql>
> > { SELECT ?book (COUNT(?title) AS ?dummy)
> > WHERE { $book dc:title $title }
> > GROUP BY $book
> > }
> > VALUES ?title {
> > "Harry Potter and the Chamber of Secrets"
> > "Harry Potter and the Philosopher's Stone"
> > }
> > }
> >
> > I'd expect two triples to be produced -
> >
> > <http://example.org/book/book1> dc:description 1 .
> > <http://example.org/book/book2> dc:description 1 .
> >
> > However, I get 7 triples, for book1 - book7.
> >
> > A direct query against http://sparql.org/books/sparql
> >
> > CONSTRUCT { ?book dc:description ?dummy }
> > WHERE {
> > SELECT ?book (COUNT(?title) AS ?dummy)
> > WHERE { $book dc:title $title }
> > GROUP BY $book
> > VALUES ?title {
> > "Harry Potter and the Chamber of Secrets"
> > "Harry Potter and the Philosopher's Stone"
> > }
> > }
> >
> > works as expected. And so does a federated query without the
> > aggregation:
> >
> > CONSTRUCT { $book dc:title ?title }
> > WHERE {
> > SERVICE <http://sparql.org/books/sparql>
> > { SELECT ?book ?title
> > WHERE { $book dc:title $title }
> > }
> > VALUES ?title {
> > "Harry Potter and the Chamber of Secrets"
> > "Harry Potter and the Philosopher's Stone"
> > }
> > }
> >
> > Am I missing something?
> >
> > Cheers, Joachim
>
