Discovering service descriptions

(This is somewhat related to 
http://www.w3.org/2009/sparql/track/issues/31 .)

We have a significant open question of how people/software can find 
SPARQL endpoint service descriptions.

On our June 30 teleconference, we discussed 6 options for discovering 
service descriptions - 
http://www.w3.org/2009/sparql/meeting/2009-06-30#Finding_service_descriptions 
.

Since, there's also been some discussion on our mailing list around 
DESCRIBE_ENDPOINT - 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0444.html 
- and also more recently some discussion on our -comments list: 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Jul/0004.html 
and subsequent.

This mail is an attempt to summarize the options I've seen put forth & 
to characterize them a bit. I'm hoping people will reply with strong 
support or strong opposition to options, to inform discussion at next 
week's teleconference.

I'm going to give the options both names & numbers :)

Option 1 - HTTP-Header

Any GET or HEAD request on an endpoint would use an HTTP response header 
to provide a URL at which a service description for that endpoint can be 
found.


Option 2 - HTTP OPTIONS

Return a service description in response to an HTTP request on the 
endpoint that uses the HTTP OPTIONS verb.


Option 3 - Well-known location

A service description can be downloaded from a well-known URL relative 
either to the SPARQL endpoint URL.


Option 4 - DESCRIBE <sparql.endpoint.url>

A service description is returned in response to a DESCRIBE query issued 
for the URI of the endpoint itself. DESCRIBE <> is closely related to this.


Option 5 - Query

Recommend that SPARQL endpoints SHOULD answer regular SPARQL queries 
about the endpoint URI using the service description vocabulary/ies.


Option 6 - DESCRIBE_ENDPOINT

Add a new SPARQL query type specifically to return service descriptions. 
 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Aug/0001.html 
suggests two new query types - DESCRIBE_SERVICE and DESCRIBE_DATASET.


Option 7 - Conneg

An HTTP GET request on a SPARQL endpoint without any query parameters 
and specifying an RDF serialization in the Accept: header would return a 
service description for the endpoint. (Suggested in 
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2009Jul/0005.html 
.)


 From what I've heard in conversations so far, I think that 2 - HTTP 
OPTIONS, 3 - Well-known location, and 5 - Query all lack strong support 
from anyone. Please correct me if I'm wrong.

Of the remaining options, 1 - HTTP Header and 7 - Conneg both are 
"protocol-level" operations. They each seem to be somewhat specific to 
HTTP, though I'm guessing there'd be a moral equivalent for things like 
SOAP. They definitely lend themselves easily enough to equivalents via 
an API (myEngine.getServiceDescription() ? :-) ).

The other options, DESCRIBE <endpoint> and DESCRIBE_ENDPOINT, are 
"query-level" operations. Some people have expressed concerns that 
DESCRIBE <endpoint> (or its cousin, DESCRIBE <>) constrains what 
information the store can actually contain, and it also seems to me that 
it requires that the endpoint actually have a URI in the first place, 
and that the caller know that URI (not necessarily the case in an API 
environment, though there are non-standard ways to get at service 
descriptions in those cases, as above, I guess).

Any thoughts / opinions?

Lee

Received on Thursday, 6 August 2009 10:38:59 UTC