- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Wed, 21 Dec 2005 11:22:44 -0500 (EST)
- To: andy.seaborne@hp.com
- Cc: public-rdf-dawg-comments@w3.org
From: "Seaborne, Andy" <andy.seaborne@hp.com> Subject: Re: some initial comments on SPARQL Query Language for RDF revision 1.596 of 19 December 2005 Date: Wed, 21 Dec 2005 16:14:59 +0000 > Peter, [...] > > I just read over the first few sections of SPARQL Query Language for RDF > > revision 1.596 of 19 December 2005, and I have a few concerns: [...] > > 2/ The definitions put much more of a burden on the RDF graph-generating > > process. I think that this needs to be addressed much more fully. In > > particular, I think that it would be useful to explain that some systems store > > a particular RDF graph that is not related to an input RDF graph by any > > relationship sanctioned by the RDF recommendations. Directly querying such RDF > > graphs could result in pecular answers. As well, I think that it would be > > useful to indicate that if querying results approximating RDF entailment or > > RDFS entailment are desired, then the RDF graph that is being queried will be, > > of ncecessity, not explicitly stored anywhere. > > I don't understand the points here. Could you provide an example of the > burden and the peculiar answers that might be obtained? See below. > Is this related to > your previous comment on lean graphs? Not really. > The document does not cover how a system might store a graph (if it stores it > at all - it might be partially calculated on demand) although we have to > recognize any implementation matters that arise. This is the point I think is not appropriately covered in the document. Most systems that I have heard of do not actually store the RDF graph that they "commit to". Consider, for example, a system that advertises that it supports RDFS semantics. There is no way that such a system can store all the RDFS consequences of a set of input triples. However, such systems are also likely (from what I have heard) to augment the set of input triples with some inferences. So querying the explicitly stored graph is likely to produce strange answers. I think, then, that the system *should* respond to SPARQL queries to the "virtual" closure of the RDF graph that it actually stores. However, I think that it is entirely possible that some systems will actually process queries against their stored RDF graph. This does abide by the SPARQL requirements, but I think that many users will actually have different expectations. I thus think that the SPARQL documents should more fully describe such situations and the behaviour of such systems. > Andy [...] peter
Received on Wednesday, 21 December 2005 16:23:30 UTC