Re: Formalising DESCRIBEs; the result graph

Lee,

To address the last thing first:

On Friday 17 April 2009 07:44:05 you wrote:
> and/or allowing the query to select a
> specific implementation a la
> http://www.w3.org/2009/sparql/wiki/Feature:ControlOfDescribeQueries ?

I've come to the conclusion that this is not the important feature for us, we 
don't need to let the query author control it. So, what we are asking is 
actually a different feature. 

Therefore, I have submitted a feature at:
http://www.w3.org/2009/sparql/wiki/Feature:DefaultDescribeResult

> My gut feeling on this is that it's not a major interoperability concern
> since DESCRIBE is a) not a normative part of SPARQL and b) designed to
> be implementation-specific (i.e. DESCRIBE queries are not expected to be
> portable from implementation to implementation).

Actually, we tend to think of these things as shortcomings of the current 
spec, and things that need to be rectified. 

We have found DESCRIBE queries to be very useful, in fact the most useful 
query form, but it is stuck in a grey zone as long as it is not normatively 
defined. We think that this group should rectify that problem.

We think that it is a good idea to allow each implementation to implement 
their own result set algorithm. Also, I acknowledge that it will not make 
sense to require someone who creates a custom endpoint for a specific 
application to implement a very elaborate result set. However, we think that 
this proposal will give us best of both worlds, both flexibility and 
portability.

We feel very strongly that a elaborate "default result" created with the key 
guideline that it should be "give me all you know about this resource, with 
some data that helps me present it to a human user", would be a key enabler 
of new uses of SPARQL. It quite simply would give you very simple  queries 
that give you the things you need to present meaningful data to a human user. 

This is not possible with SELECT and CONSTRUCT, since it requires the query 
author to bind a variable to get a result. This complicates the query and 
requires the query author to know more about the data, which is information 
that may not even be known at the time of writing the query. This is one of 
the things that make DESCRIBE so powerful.

By specifying a default result set that should be implemented, we win enhanced 
interoperability, as it becomes easier to use "the right tool for the job" 
(FWIW, my current project uses Jena, Virtuoso and Redland in different parts 
of the code base, so this is a big deal), and to migrate back and forth 
between them, and such system are those that I hope will implement this. 

> I do think that describe-implementation-strategy would be a good thing
> to include within an endpoint's service description (should the WG
> choose to pursue service descriptions). URIs could be minted (both by
> the WG and/or by the community) for things like CBD, MSG, and other
> constructs. What do you think of this approach?

It would work for Feature:ControlOfDescribeQueries, but as stated above, it 
does not address our issue.

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 12:37:19 UTC