W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

RE: Formalising DESCRIBEs; the result graph

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 17 Apr 2009 10:35:45 +0000
To: Lee Feigenbaum <lee@thefigtrees.net>, Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
CC: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA362D0572DAB@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Lee Feigenbaum
> Sent: 17 April 2009 06:44
> To: Kjetil Kjernsmo
> Cc: public-rdf-dawg@w3.org
> Subject: Re: Formalising DESCRIBEs; the result graph
> Kjetil Kjernsmo wrote:
> >
> > Anyway, the specification of the result graph is something that we do
> > not have very strong opinions about. What we do feel strongly about is
> > that there is a such a result graph that all endpoints should
> > implement, and that DESCRIBE is formally specified.
> >
> Kjetil,
> My gut feeling on this is that it's not a major interoperability concern
> since DESCRIBE is a) not a normative part of SPARQL and b) designed to
> be implementation-specific (i.e. DESCRIBE queries are not expected to be
> portable from implementation to implementation).
> I do think that describe-implementation-strategy would be a good thing
> to include within an endpoint's service description (should the WG
> choose to pursue service descriptions). URIs could be minted (both by
> the WG and/or by the community) for things like CBD, MSG, and other
> constructs. What do you think of this approach?


> Does anyone else have a strong feeling about defining a default
> implementation of DESCRIBE and/or allowing the query to select a
> specific implementation a la
> http://www.w3.org/2009/sparql/wiki/Feature:ControlOfDescribeQueries ?

Allowing the specification of the algorithm is a good possibility.

A default one seems to be tricky.

Some potential requirements for a default/standard/common/noted implementation:

1/ Works on plain RDF.  No assuming that inverse functional properties are understood as IFPs, for example.
2/ Works with FOAF that uses bNodes for people.

This combination of requirements is a bit painful.  The lowest common denominator is then all triples with a given subject (or maybe subject+object).  Which is CONSTRUCT { <uri> ?p ?o } WHERE { <uri> ?p ?o }

Maybe it should be characterised not as the "default" implementation but as a minimum of the graph returned.  Same for a descriptions in the service description - minimum (and hence absence of triples can be used as information), and not exactly the results.

I like the ideal that results contain metadata about the results as to what they contain.


> Lee

Received on Friday, 17 April 2009 10:36:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:54 UTC