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
