Re: Formalising DESCRIBEs; the result graph

On 17 Apr 2009, at 16:19, Kjetil Kjernsmo wrote:

> On Friday 17 April 2009 15:01:25 Seaborne, Andy wrote:
>>> 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?
>
> We don't feel that way, simply by looking at the query, it is harder  
> to write,
> and harder to understand. With DESCRIBE, you simply say "give me  
> something
> about these resources", you don't need to write out the triples.
>
> I think it is important for SPARQL to be accepted on the web scale,  
> that we
> have a lot of shorthands that make queries easier to write and  
> results easier
> to use, and this is one particularly nice way to do that, I feel.

Fair enough, but see below.

>> 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.
>
> Mmmm, ok, I didn't think about that. We use very little bnodes, so I  
> never had
> to worry about that. But yeah, I'd rather live with that...

We've done a lot of work with FOAF, and that situation would be / 
really/ unhelpful. The bNode closure of many parts of the FOAF world  
is hundreds of millions of triples.

>> 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 guess that's fair to ask. What I envision would be something like  
> CBD + some
> metadata like rdfs:label. For our purpose, given that we use very  
> little
> blank nodes and no reification, a simple SPO (i.e. just the  
> predicates and
> objects of the DESCRIBEd subject) + rdfs:label would suffice, but I  
> suppose
> it should be a little more general than that. But if I say SPO +  
> optional
> rdfs:labels of the predicates, is it sufficiently intuitive that  
> such a thing
> will exist to be acceptable? That wouldn't be too hard to implement  
> either,
> would it?

That does seem quite specific to your particular use-case. I've only  
used DESCRIBE once or twice, but I've not used it for this purpose,  
just for extracting graph fragments for further processing.

I'm sympathetic to your concerns that the CONSTRUCT version of how  
you'd like DESCRIBE to behave has more bytes in it, but defining that  
as the default behaviour for DESCRIBE, or even naming it as a first  
class citizen seems a bit odd also.

- Steve

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

Received on Friday, 17 April 2009 15:58:06 UTC