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