You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Rob Vesse <rv...@yarcdata.com> on 2012/08/31 01:40:14 UTC
FROM and GRAPH interaction
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?
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.
Cheers,
Rob
Re: FROM and GRAPH interaction
Posted by Rob Vesse <rv...@yarcdata.com>.
On 8/31/12 11:10 AM, "Andy Seaborne" <an...@apache.org> wrote:
>On 31/08/12 18:54, Rob Vesse wrote:
>> Thanks for the clarifications
>>
>> Can the working group please fix this ASAP?
>
>It is going to.
>
>(NB the message was Aug 21, 10 days ago, and it's vacation season)
Unfortunately our deadline is fast coming up, what I can likely do in the
meantime is fix in our copy of the test suite
>
>> Or do I have to send yet another formal comment moaning about the dodgy
>> state of the 1.1 test suite
>
>Suite works for me except where noted.
>
>You could send a patch or join the WG and help!
I am not adverse to joining the WG
However the thought of ever going near CVS ever again fills me with abject
horror, having moved to SVN and now on to Mercurial why anyone still puts
anything in CVS is beyond me
Rob
>
> Andy
>
>>
>> Rob
>
Re: FROM and GRAPH interaction
Posted by Andy Seaborne <an...@apache.org>.
On 31/08/12 18:54, Rob Vesse wrote:
> Thanks for the clarifications
>
> Can the working group please fix this ASAP?
It is going to.
(NB the message was Aug 21, 10 days ago, and it's vacation season)
> Or do I have to send yet another formal comment moaning about the dodgy
> state of the 1.1 test suite
Suite works for me except where noted.
You could send a patch or join the WG and help!
Andy
>
> Rob
Re: FROM and GRAPH interaction
Posted by Rob Vesse <rv...@yarcdata.com>.
Thanks for the clarifications
Can the working group please fix this ASAP?
Or do I have to send yet another formal comment moaning about the dodgy
state of the 1.1 test suite
Rob
On 8/31/12 10:43 AM, "Andy Seaborne" <an...@apache.org> wrote:
>On 31/08/12 16:53, Rob Vesse wrote:
>> Well actually the use case that prompted this debate and my
>>interpretation
>> is actually one of the DAWG 1.1 tests so it may turn out that the test
>>is
>> actually wrongly defined currently.
>>
>> The test in question is delete/delete-using-02.ru which is as follows:
>
>ah ...
>
>>
>> PREFIX : <http://example.org/>
>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>>
>> DELETE
>> {
>> ?s ?p ?o .
>> }
>> USING <http://example.org/g3>
>> WHERE
>> {
>> GRAPH <http://example.org/g2>
>> {
>> :a foaf:knows ?s .
>> ?s ?p ?o
>> }
>> }
>>
>>
>> So if your interpretation is correct (and I will assume it is) then this
>> update should have no effect because the WHERE clause should yield no
>> results, yet the manifest points to expected results which suggest we
>> should be deleting data. The Update spec says USING and USING NAMED
>> behave exactly the same as FROM and FROM NAMED so this test seems at odd
>> with that statement.
>>
>> Is this test just plain incorrect?
>
>yes.
>
>http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0135.html
>
>and I'm not the only one.
>
>>
>> If this test is incorrect (which I'm beginning to suspect it is) we can
>>do
>> away with the debate and take your interpretation of the spec to be
>> correct which makes life a whole lot easier for us because currently we
>> implement your interpretation of the spec and not having to change our
>> implementation is easier. (Of course I then have to go fix dotNetRDF
>> because I originally implemented your interpretation and later changed
>>it
>> because of a debate with another developer over this same test)
>>
>> Cheers,
>>
>> Rob
>
Re: FROM and GRAPH interaction
Posted by Andy Seaborne <an...@apache.org>.
On 31/08/12 16:53, Rob Vesse wrote:
> Well actually the use case that prompted this debate and my interpretation
> is actually one of the DAWG 1.1 tests so it may turn out that the test is
> actually wrongly defined currently.
>
> The test in question is delete/delete-using-02.ru which is as follows:
ah ...
>
> PREFIX : <http://example.org/>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>
> DELETE
> {
> ?s ?p ?o .
> }
> USING <http://example.org/g3>
> WHERE
> {
> GRAPH <http://example.org/g2>
> {
> :a foaf:knows ?s .
> ?s ?p ?o
> }
> }
>
>
> So if your interpretation is correct (and I will assume it is) then this
> update should have no effect because the WHERE clause should yield no
> results, yet the manifest points to expected results which suggest we
> should be deleting data. The Update spec says USING and USING NAMED
> behave exactly the same as FROM and FROM NAMED so this test seems at odd
> with that statement.
>
> Is this test just plain incorrect?
yes.
http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0135.html
and I'm not the only one.
>
> If this test is incorrect (which I'm beginning to suspect it is) we can do
> away with the debate and take your interpretation of the spec to be
> correct which makes life a whole lot easier for us because currently we
> implement your interpretation of the spec and not having to change our
> implementation is easier. (Of course I then have to go fix dotNetRDF
> because I originally implemented your interpretation and later changed it
> because of a debate with another developer over this same test)
>
> Cheers,
>
> Rob
Re: FROM and GRAPH interaction
Posted by Rob Vesse <rv...@yarcdata.com>.
Well actually the use case that prompted this debate and my interpretation
is actually one of the DAWG 1.1 tests so it may turn out that the test is
actually wrongly defined currently.
The test in question is delete/delete-using-02.ru which is as follows:
PREFIX : <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
DELETE
{
?s ?p ?o .
}
USING <http://example.org/g3>
WHERE
{
GRAPH <http://example.org/g2>
{
:a foaf:knows ?s .
?s ?p ?o
}
}
So if your interpretation is correct (and I will assume it is) then this
update should have no effect because the WHERE clause should yield no
results, yet the manifest points to expected results which suggest we
should be deleting data. The Update spec says USING and USING NAMED
behave exactly the same as FROM and FROM NAMED so this test seems at odd
with that statement.
Is this test just plain incorrect?
If this test is incorrect (which I'm beginning to suspect it is) we can do
away with the debate and take your interpretation of the spec to be
correct which makes life a whole lot easier for us because currently we
implement your interpretation of the spec and not having to change our
implementation is easier. (Of course I then have to go fix dotNetRDF
because I originally implemented your interpretation and later changed it
because of a debate with another developer over this same test)
Cheers,
Rob
On 8/31/12 3:11 AM, "Andy Seaborne" <an...@apache.org> wrote:
>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
Re: FROM and GRAPH interaction
Posted by Andy Seaborne <an...@apache.org>.
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
Re: FROM and GRAPH interaction
Posted by Rob Vesse <rv...@yarcdata.com>.
Code I'm using to test, substitute "data" for the SPARQL Update I showed
and "query" for the query I showed:
Dataset ds = DatasetFactory.createMem();
GraphStore gs = GraphStoreFactory.create(ds);
UpdateRequest up = UpdateFactory.create(data);
UpdateProcessor processor = UpdateExecutionFactory.create(up, gs);
processor.execute();
//Parse the query
Query q = QueryFactory.create(query);
//Render the dataset appropriately, ARQ doesn't do this for us
automatically
Dataset ds2 = DynamicDatasets.dynamicDataset(q.getDatasetDescription(),
ds, false);
//Then execute the query
QueryExecution exec = QueryExecutionFactory.create(q, ds2);
ResultSet results = exec.execSelect();
//Write out the results etc
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.
Rob
On 8/30/12 4:40 PM, "Rob Vesse" <rv...@cray.com> 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?
>
>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.
>
>Cheers,
>
>Rob
>
>