Re: volunteers request for features to be discussed next Telecon

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