W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2005

sparql describe - options?!

From: Leo Sauermann <leo@gnowsis.com>
Date: Tue, 15 Nov 2005 23:49:15 +0100
Message-ID: <437A65EB.5010604@gnowsis.com>
To: public-rdf-dawg-comments@w3.org, Patrick.Stickler@nokia.com

Hello SPARQL,

I have some input regarding the definition of DESCRIBE
I have two inputs to make, explaination below:
* Include Concise Bounded Descriptions as a "suggested" way the Query 
Processor handles calls to Describe (not authorative, the query 
processor MAY use CBD Semantics to gather the graph for describe)
* Allow the passing of parameters to the query processor during describe 
calls

=Background info=

here is the current def from
http://www.w3.org/TR/rdf-sparql-query/#describe
"The query pattern is used to create a result set. The | DESCRIBE| form 
takes each of the resources identified in a solution, together with any 
resources directly named by IRI, and assembles a single RDF graph by 
taking a "description" from the target knowledge base. The description 
is determined by the query processor implementation and should provide a 
useful description of the resource, where the meaning of "useful" is 
determined by the information publisher."

At the moment the definition of description is taken on the server side, 
by the query processor. We know from implementations, that Patrick 
Stickler's URIQA protocol defines Concise Bounded Descriptions with a 
similar intent, but with a concrete definition

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

In our gnowsis project, a Semantic Desktop, the concept of CBDs proved 
very useful for practical implementation of a larger system. Also, in 
creation of adapters to extract information from heterogenous 
datasources, CBDs are useful.
Hence, I would suggest to include the definition of CBDs so that 
implementers MAY use this semantic, and also that clients MAY hope that 
CBDs are returned. This would also give implementors a better definition 
of what they MAY do in their implementations, allowing to quick-start 
with existing code or at least an exact decision what is good here (and 
year-long experience).

A notion of CBD and URIQA is, that the user can pass parameters to the 
query processor to ask for certain properties via passed parameters.
http://sw.nokia.com/uriqa/URIQA.html#parameters
These parameters include parameters like
* format
* naming
* inference
* reifications
etc.

We want to change some parts of our gnowsis software to URIQA, but 
cannot use the Describe syntax as a CBD replacement at the moment, 
because we cannot pass parameters through the query engine. One use case 
is crawling: When collecting data from a server to store it into a RDF 
database (using several URIQA/CBD calls) we pass parameters to indicate 
this use. The query engine should return then minimal graphs, that are 
connected to each other. Which is not important now, but we need to pass 
a parameter "crawling=true" through the engine, to our query engine 
implementation.
Hence, even If the semantics of DESCRIBE is not clear, we would like to 
use it, but to pass name/value pairs through the engine so that we can 
refine the semantics of DESCRIBE a little.

Passing parameters would allow us, to continue the CBD and URIQA system 
here and connect it to SPARQL, and also to continue our code base.

Patrick Stickler can also comment on these requirements, we have chatted 
about this during the ISWC.

greetings,
hope that this email is useful input and helps us all,
Leo Sauermann
Received on Tuesday, 15 November 2005 22:49:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT