Re: Formalising DESCRIBEs; the result graph

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. 

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

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

Kind regards 

Kjetil Kjernsmo
-- 
Senior Knowledge Engineer
Mobile: +47 986 48 234
Email: kjetil.kjernsmo@computas.com   
Web: http://www.computas.com/

|  SHARE YOUR KNOWLEDGE  |

Computas AS  PO Box 482, N-1327 Lysaker | Phone:+47 6783 1000 | Fax:+47 6783 
1001

Received on Friday, 17 April 2009 15:19:36 UTC