- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Mon, 23 Mar 2009 18:34:48 -0400
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
I'll present the service descriptions feature tomorrow on the call, but wanted to briefly send some thoughts to the list beforehand. For reference, the feature page is here: http://www.w3.org/2009/sparql/wiki/Feature:ServiceDescriptions I think service descriptions are very important to the extensibility of any SPARQL updates, but see it as being able to be broken into several parts, with varying levels of importance (and probably ability to get concensus). Here's how I see a potential split (in decreasing order of importance): 1. At the most basic level, I think we should mint URIs for every new feature and functions added to SPARQL (and possibly to those present in SPARQL2008), allowing sensible things to be said about conformance of implementations to the spec(s). 2. With standard URIs for features and functions, the next step would be to standardize a vocabulary for describing SPARQL implementations/ endpoints. voiD[1] is a good starting point here, but is more targetted at datasets, not directly at SPARQL implementations. That being said, it can be used to describe things like the SPARQL endpoint URL and total number of triples, resources, subjects, and objects. Two other sources to draw from are DARQ[2] (with terms for describing supported predicates, selectivities, and triple count) and SADDLE[3] (closer to this proposal's intention on describing a SPARQL endpoint, but not implemented widely). Having such a vocabulary would provide an agreed upon format in which to describe the SPARQL conformance of an endpoint, as well as any other features that might be important for clients to know: extension functions, syntax extensions, supported entailment regimes, etc. 3. With a service description vocabulary, the final step would be to define a way to retrieve an actual service description from an endpoint. This could be addressed at the SPARQL protocol level (for example, adding a new operation or parameter to the HTTP binding interface), by introducing new SPARQL syntax or conventions (a new query form, or a pre-arranged URI that could be DESCRIBEd), or some out-of-band mechanism (referenced in HTTP response headers, for example). I'm not sure which of these would be best, but I lean toward preferring protocol extensions as it seems like it might be easiest to spec, implement, and reach consensus on. cheers, gregory williams [1] http://semanticweb.org/wiki/VoiD [2] http://darq.sourceforge.net/ [2] http://www.w3.org/2001/sw/DataAccess/proto-wd/saddle.html
Received on Monday, 23 March 2009 22:35:26 UTC