- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Thu, 24 Sep 2009 23:47:22 -0400
- 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 UTC