W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2005

Re: some initial comments on SPARQL Query Language for RDF revision 1.596 of 19 December 2005

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 21 Dec 2005 11:22:44 -0500 (EST)
Message-Id: <20051221.112244.31842665.pfps@research.bell-labs.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT