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. .gregReceived on Friday, 25 September 2009 04:08:49 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 October 2009 14:42:15 GMT