Re: service description vocabulary

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

Ah, so you're suggesting this as a way for an endpoint to tell the world 
what it does in the absence of FROM, FROM NAMED, and protocol graph 
parameters? That makes perfect sense to me.

(I had (mis-)interpreted it as a way to characterize the overall set of 
graphs that the endpoint is capable of including in a query's RDF dataset.)

Lee

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

Received on Friday, 25 September 2009 04:10:22 UTC