W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Formalising DESCRIBEs; the result graph

From: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>
Date: Mon, 16 Mar 2009 10:37:09 +0100
To: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-Id: <200903161037.09194.Kjetil.Kjernsmo@computas.com>
All,

We've been happy users of DESCRIBE queries in two commercial projects 
now, I we want to continue using them. We do feel, however, that it 
needs a bit of elaboration. What we are requesting is mostly a clearer spec, 
nit necessarily a new feature. We are somewhat confused about the effect 
named graphs have on DESCRIBEs, but I will address that in a separate email.

We feel that it was a good thing that the DAWG did not specify the 
result graph in SPARQL 1.0. We also feel that DESCRIBE still should not 
specify a single result graph.

For an example of why we came to this conclusion, we think that an 
endpoint for a weather service would reasonably return something 
different for 

DESCRIBE <http://sws.geonames.org/3146631/>

than a pure Geonames endpoint. The former may return something like 
<http://sws.geonames.org/3146631/> a gn:Feature ;
        gn:name "Lysaker" ;
        w:latest_forecast <http://example.org/forecast/2009/03/14> .
 <http://example.org/forecast/2009/03/14> w:Forecast ;
        w:text "Cloudy" .

Whereas the pure Geonames endpoint may only want to return properties of 
the gn:Feature.

Nevertheless, we think that we should specify a "default 
implementation". We have found that this is important to be able to 
migrate with little cost between database systems, which is an 
important aspect of a standard.

We think that we should develop a default result set that every SPARQL 
implementation should support, but allow it to be overridden by server 
administrator. Furthermore, when specifying it, we should keep in mind 
that the DESCRIBE is most useful as a "give me all you know about 
http://example.org/foo"-type query. The DESCRIBE should therefore 
return enough information to allow an agent to present this information 
to a human.

The Concise Bounded Description http://www.w3.org/Submission/CBD/, which 
was some of the input to DAWG in the previous round, is a useful 
starting point (except, perhaps the reification stuff). It doesn't 
really help in presenting the data to human, however. It may be an idea 
to include rdfs:labels, if they exist for classes and properties, for 
example, as this is useful when presenting to a human user.

Anyway, the specification of the result graph is something that we do 
not have very strong opinions about. What we do feel strongly about is 
that there is a such a result graph that all endpoints should 
implement, and that DESCRIBE is formally specified.

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 Monday, 16 March 2009 09:37:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT