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.

The quoted text on CONSTRUCT is Steve, not me.

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

I suggest putting all abbreviations etc under Feature:SurfaceSyntax and keeping Feature:ControlOfDescribeQueries / Feature:DefaultDescribeResult for mechanisms that can't be written another way.

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

Isn't CBD in the of bNodes the same as 
"CONSTRUCT { <s> ?p ?o } WHERE { <s> ?p ?o }" + reifications?  There are also the alternative forms as well.

http://www.w3.org/Submission/CBD/#definition

http://www.w3.org/Submission/CBD/#alternatives


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

To see if I can make this concrete:
Something like:

CONSTRUCT 
{ <s> ?p ?o . ?p rdfs:label ?label } 
WHERE 
{ <s> ?p ?o OPTIONAL { ?p rdfs:label ? label } }

Using the fact that undefined variables only remove the triple they are, not the entire template for that set of bindings.

Also, web-architecture point, isn't it better to GET on the property URI to find the details of the property from the vocabulary, not the data using it?  OK - vocabularies aren't always online but there is no more reason for the labels to be in the data, copied from the vocabulary, as there is for the vocabulary to be online.

 Andy

> 
> 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 16:11:57 UTC