Re: Service discovery redux - endpoint-based mechanisms

Hi,

On 13 Aug 2009, at 03:38, Lee Feigenbaum wrote:

> [...]

> 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.
>

Indeed, while I find that's an elegant solution, proper content- 
negotiation is often a pain to implement, see the various recent  
threads on the LOD-list (eg [1]).
When reading this e-mail, I was wondering if RDFa annotation of the  
endpoint form could be an additional option. Yet some endpoints does  
not provide forms and simply return an error when no query is specified.
>
> 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. :-)

In that case, and wrt Orri's proposal below, would it mean that for  
any endpoint, the graph that contains the Service Description it  
always /endpoint/sparql?serviceDescription
That would be pretty nice to provide a uniform way to name the Service  
Description graph.

>
>
> 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.

I would also favor that - more than a compromise I think that's an  
elegant way not only to retrieve the service description but to query  
it, e.g. to e sure that there's at least N instances of class X into  
the store before running some kind of queries.

Best,

Alex.

[1] http://lists.w3.org/Archives/Public/public-lod/2009Jul/0165.html

>
>
> Lee
>
>
>

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Received on Thursday, 13 August 2009 18:53:12 UTC