Re: sparql describe - options?! [OK?]

Forgot the [OK?] on the subject line for the scripts.

 Andy

Seaborne, Andy wrote:
>  > 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 14:19:50 UTC