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

Re: service description vocabulary

From: Gregory Williams <greg@evilfunhouse.com>
Date: Fri, 25 Sep 2009 00:08:09 -0400
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <5D03FD4E-1243-446C-AF7C-E641E8DD1895@evilfunhouse.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
On Sep 24, 2009, at 11:47 PM, Lee Feigenbaum wrote:

> Gregory Williams wrote:
>> 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.)

Isn't the dataset an artifact of a specific query only if the query  
(or protocol request) specifies a dataset? It may not be useful for  
your implementation, but how would you provide a dataset description  
for an endpoint that does provides a default dataset without a  
construct like I suggest?

>> 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.

OK. That's my inclination as well, but thought it was worthwhile to at  
least bring it up.

Received on Friday, 25 September 2009 04:08:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC