Re: sparql describe - options?!

I would certainly support the use of CBDs being recommended for use
by SPARQL engines, as a default form of description. Of course,
there are many different forms of description, and certain forms are
more optimal for certain kinds of applications than others, thus it is
not reasonable for SPARQL to mandate any particular, single form of
description. However, in cases where implementors are unsure of
what form of description to return, it would be very useful
and reasonable for SPARQL to suggest the use of CBDs as a
default, broadly useful form of description, unless otherwise
warranted.

Even where implementations might offer various forms of description,
providing CBDs as either a default or selectable form of description
offers alot of value insofar as portability of URIQA and CBD based
solutions are concerned, allowing SPARQL servers to be more easily
and effectively utilized in such environments.

Extensive use of CBDs, both by Gnowsis, as well as in Forum Nokia's
own semantic web publication infrastructure, have shown this
form of description to be highly effective for a broad range of
applications, and suggest that a CBD would serve as a resonable
default form of description if no other critera would suggest another.

I would be happy to work with the DAWG to include coverage
of CBDs as a recommended, albeit optional, form of description
in SPARQL; even in a non-normative appendix of the recommendation.
The existing W3C Member Submission for CBDs would offer a good
starting point.

Regards,

Patrick Stickler
patrick.stickler@nokia.com


On Nov 15, 2005, at 16:49, ext Leo Sauermann wrote:

> 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 23:26:48 UTC