Service discovery redux - endpoint-based mechanisms

(Eric or anyone else, please feel free to push for query-based options, 
but I'm not including them in this message.

Here are the proposed service discovery mechanisms that are based on 
SPARQL endpoints. I've tried to include arguments for/against them where 
I've picked them up in the discussion so far. Please augment/correct as 
necessary.

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. Argument for: The response of any query issued against an 
endpoint will include a pointer to the service description. Headers are 
easy to include and consume. Argument against: This requires 2 requests 
to get the service description.


Option 2 - HTTP OPTIONS

Return a service description in response to an HTTP request on the 
endpoint that uses the HTTP OPTIONS verb. Argument for: Potentially 
revives the underutilized OPTIONS verb in an appropriate way. Argument 
against: OPTIONS is not commonly used and may be tough to implement in 
certain environments (e.g. XHR?) Also, OPTIONS may not have the proper 
cache semantics for service descriptions.


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 
.) Argument for: Allows for endpoints that today return HTML query forms 
in response to a regular GET on the endpoint URI. Argument against: May 
be an abuse of content negotiation to return something which is not 
strictly an alternative representation of what would be shown in the 
HTML version. Content negotiation is not always easy to get right.


Option 8 - New protocol operation (?serviceDescription)

A request to a URI such as /endpoint/sparql?serviceDescription returns 
the service description. Argument for: Simple extension of SPARQL 
protocol that maps nicely to non-HTTP instantiations of the protocol. 
Easy to implement and invoke. A well-known pattern from Web Services 
stacks. Argument against: ?? Not sure, other than Steve is ok with it 
but not thrilled. :-)


Note, any of these could be combined with Orri's "compromise" proposal, 
in which the service description itself could optionally point to a 
graph that can be queried that contains the service description info.


Lee

Received on Thursday, 13 August 2009 02:39:51 UTC