Re: Formalising DESCRIBEs; the result graph

On 17 Apr 2009, at 11:35, Seaborne, Andy wrote:
>> 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
>> ?
> 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 }

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

Maybe it's worth resurrecting the CONSTRUCT * syntactic sugar  
    CONSTRUCT * WHERE { { <uri> ?a ?b } UNION { ?c ?d <uri> } }
is certainly easier on the eye, if not the brain.

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

Me too.

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  

Received on Friday, 17 April 2009 12:33:10 UTC