On 31/08/12 00:40, Rob Vesse wrote:
Hey Andy
Me and one of my colleagues are once again having a debate about the
interpretation of SPARQL datasets which you may be able to clear up.
Assuming the following dataset created with a SPARQL Update:
INSERT DATA
{
<ex:default> <ex:default> <ex:default> .
GRAPH <ex:from> { <ex:from> <ex:from> <ex:from> }
GRAPH <ex:named> { <ex:named> <ex:named> <ex:named> }
GRAPH <ex:other> { <ex:other> <ex:other> <ex:other> }
}
Now given the query:
SELECT * FROM <ex:from> { GRAPH <ex:named> { ?s ?p ?o } }
What should be the result?
No rows IMO
I was expected to see a single row with the triple from <ex:named>
but ARQ gives back no results.
... :-)
Maybe this is just a case of me mis-interpreting the SPARQL spec but
I'd like to get an answer from a definitive source. My
interpretation is that if you have a FROM without any FROM NAMED you
are setting the default graph explicitly but leaving the named graphs
to be all named graphs in the store.
The dataset description is supposed to be complete so no FROM NAMED
means no named graphs. No FROM means empty default graph.
Think of it as picking graphs out of a big pool and consider "GRAPH ?g".
The big pool might be the whole web just as much as it might be the
local dataset.
The except so far has been that no FROM and union-graph-mode makes the
default graph the union of chosen graphs.
This is both convenience and also reflects many systems where there is
only a union for the default graph and it is always there. It's FROM
<urn:x-arq:UnionGraph> (if that works, which I think does).
Do you have use cases?
To some extent, we can make the system do the right thing where "right"
can be "expected".
Other systems that rely heavily on this local selection are (I believe)
Anzo and 4Store.
I was actually in the process of writing up some unit tests that
cover a whole bunch of different cases for these kind of interactions
to help some of our devs out which was when I ran into this case
where my interpretation of the spec and ARQ's differs. If you can
clarify what the interpretation is I can fix the tests/ARQ as
appropriate and then check these in.
The current tests are in
AbstractTestDynamicDataset
We do have some room for manoeuvre here
I've been wanting to get datasets/graphs sorted out a bit: it started as
wanting to have a generic graph-over-dataset which was not tied to the
storage but it has grown to a more root-and-branch look at datasets.
Some stuff work-in-progress:
https://svn.apache.org/repos/asf/jena/Scratch/AFS/Dev/trunk/src/main/java/projects/viewgraph/
Andy
