Service Descriptions (was: volunteers request for features to be discussed next Telecon)

Am Montag, den 23.03.2009, 18:34 -0400 schrieb Gregory Williams:
> 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.

I would favor including the description in a named graph. If we decide
to include
http://www.w3.org/2009/sparql/wiki/Feature:Query_response_linking , this
graph could be linked from query responses without the need to predefine
a name for it. In order to retrieve it, any query would do, e.g. a
DESCRIBE of the SPARQL endpoint. The query result would link to the
service description, which could then be retrieved as a whole or queried
for further details without having to retrieve it completely. The latter
may become important, when a lot of extensions are supported.

Best regards,
Simon

-- 
Simon Schenk | ISWeb | Uni Koblenz-Landau
http://isweb.uni-koblenz.de
http://www.uni-koblenz.de/~sschenk