Re: Querying only the default graph from the data store

On 07/09/12 12:44, Barry Bishop wrote:
>
> Suppose you run a development team that builds an application that
> interacts with some public sparql endpoint, say http://xyz.org/sparql -
> then one day xyz.org start to have scalability problems and decide to
> upgrade their RDF database to some expensive new thing. Both old and new
> RDF databases are fully compliant with W3C, but after they upgrade your
> application is completely broken only because the two database
> implementations construct their RDF dataset differently when no FROM
> clauses are given. I am sure you wouldn't find it so natural in this case.
>
> There are some workarounds as you say, but not in all cases. When you
> are using someone else's database and don't get to decide how they
> partition their data in to separate graphs, then you can be completely
> stuck. As fabulous as the query language is (and I do think it is
> tremendous achievement), this ambiguity over constructing a dataset when
> there are no FROMs is a bit of a hole.

I'd describe this situation a little differently.  It's the relationship 
of graph store to dataset that is key here.  Providing controls in the 
query may be too late in the process.

If you import a dump that only mentions named graphs into a database, 
and then queries see triples in the default graph not mentioned in the 
dump then I'd characterise it as the engine as doing a transformation of 
the data and the dataset being queried is different.  It may be a useful 
transformation, it may not - that's going to influence which engine to use.

If
   SELECT * { { ?s ?p ?o } UNION { GRAPH ?g {?s ?p ?o}} }
returns different answers, then it is a different dataset.

It's the same if the engine canonicalises literals or URIs or applies 
RDFS inference.  The dataset is a different value.

If the dataset is the current value of the graph store then there isn't 
much wiggle room.

Test case:

PREFIX : <http://example/>
CLEAR ALL ;
INSERT DATA {
  :s1 :p1 :o1
  GRAPH :g { :s2 :p2 :o2 . :s3 :p3 :o3 . }
}

then
SELECT * { ?s ?p ?o }

how many triples? err, 1, 2 or 3 are all possible from the descriptions 
of stores.  But if the dataset at the endpoint is claimed to be:

:s1 :p1 :o1 .
:s2 :p2 :o2 :g .
:s3 :p3 :o3 :g .

then the query isn't ambiguous.

	Andy

Received on Sunday, 9 September 2012 11:30:01 UTC