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 13:01:25 +0000
To: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA362D0572E30@GVW1118EXC.americas.hpqcorp.net>


> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Steve Harris
> Sent: 17 April 2009 13:33
> To: SPARQL Working Group
> Subject: Re: Formalising DESCRIBEs; the result graph
> 
...
> >
> > 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 }
> 
> I'm somewhat of the opinion that nailing down DESCRIBE is not really
> ideal, but we don't use it much, so I'm open to having my mind changed.
> 
> If you really want
>     CONSTRUCT { <uri> ?p ?o } WHERE { <uri> ?p ?o }
> or
>     CONSTRUCT { <uri> ?a ?b . ?c ?d <uri> } WHERE { { <uri> ?a ?b }
> UNION { ?c ?d <uri> } }
> I'd have thought it would be better to write that explicitly?

Yes - my point was that a minimum DESCRIBE algorithm that works for RDF, without IFP handling, and works for bnode-heavy graphs looks to me (at the moment) like a flat description.  Which is a CONSTRUCT query.

To make it work for bnode-only/bnode-heavy data isn't easy to define.  A bnode closure of something from a FOAF file is a connected component of the graph and that might be very large (and unhelpful).  Maybe we just live with that.

The useful description is data-dependent so something in a service description and/or metadata in the result graph, then the requestor introspects on the data looks useful.
	
Feature:DefaultDescribeResult asks for an algorithm that is always implemented. So before agreeing to this feature, I'm looking for an existence proof that such a thing exists at all and that it requires machinery not already present.
 

I note that Feature:BlankNodeRefs means that a application can implement any algorithm itself over any data, without server help, albeit with extra round-trips.

	Andy

Received on Friday, 17 April 2009 13:02:34 UTC

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