Re: sparql describe - options?!

 > From: Leo Sauermann <leo@gnowsis.com>
 > Date: Tue, 15 Nov 2005 23:49:15 +0100
 >
 >
 > 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)

I have added an informative reference to the CBD submission into the query 
document and linked to it from the DESCRIBE section.

 > * Allow the passing of parameters to the query processor during
 > describe calls

The service description of a service would indicate what mechanisms it 
provided for descriptions and any additional parameters that might be used at 
a particular given service endpoint.

The working group has decided to postpone the Service Description issue for 
this working group on the grounds that designs aren't sufficiently mature yet 
and so would have a large impact on the Working Group schedule.

http://www.w3.org/2001/sw/DataAccess/issues#serviceDescription


If this message addresses the comments raised, please let us know.  (If you
respond with [CLOSED] in the subject line it will allow the issue tracking
scripts to close this issue.)

 Thanks,
 Andy

 >
 > =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 Monday, 9 January 2006 11:15:09 UTC