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

Re: service description vocabulary

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Thu, 24 Sep 2009 23:47:22 -0400
Message-ID: <4ABC3D4A.2090104@thefigtrees.net>
To: Gregory Williams <greg@evilfunhouse.com>
CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Gregory Williams wrote:
> Beyond what's currently listed in the vocab section of the service 
> description page[1], I think we need a way to describe the dataset 
> provided by the endpoint. This goes beyond what things like voiD provide 
> which is a way to describe a single graph. Therefore, I'd like to 
> suggest something like this:
> 
> <endpoint> sd:datasetDescription [
>     sd:defaultGraph <void-dataset-for-default-graph> ;
>     sd:namedGraph [
>         sd:graphName <graph-name> ;
>         sd:graphDescription <void-dataset-for-named-graph> ;
>     ] .
> ] .
> 
> The lack of naming symmetry between sd:defaultGraph (for default graphs) 
> and sd:graphDescription (for named graphs) could probably be made better 
> (maybe sd:defaultGraphDescription?), but this modeling allows each graph 
> in the dataset to be described as well as things to be said about the 
> entire dataset.

I'm not sure this makes sense - the RDF dataset (default graph + named 
graphs) is an artifact of a specific query, not of the endpoint itself. 
An endpoint isn't required to have any notion of a default graph--I know 
that mine, at least don't. (We've got a quad store from which graphs can 
be plucked and either merged into a default graph for a query or 
included as individual named graphs for a query.)

> Additionally, I was hoping to get feedback on whether people think the 
> vocab should distinguish between language extensions and supported 
> features? Is this a meaningful distinction? For example, an extension 
> that modifies the SPARQL syntax (e.g. to support the BINDINGS keyword) 
> versus a feature describing the algorithm used to generate DESCRIBE 
> results. The former clearly extends SPARQL, but the latter works within 
> the existing constraints of SPARQL. Thoughts?

I don't think we need to differentiate - I tend to think a single 
mechanism for supported features combined with URIs for standard 
features is sufficient, and will give the community sufficient room to 
define URIs and extra parameters for extension features... But I haven't 
thought it through too well.

Lee

> thanks,
> .greg
> 
> [1] http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions
> 
> 
> 
Received on Friday, 25 September 2009 03:48:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:28 GMT