RE: Formalising DESCRIBEs; the result graph



> -----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?

Agree.

> 
> 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.

 Andy

> 
> Lee

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