RE: Discovering service descriptions

Hi all, 

On Mon, 2009-08-10 at 13:47 +0000, Seaborne, Andy wrote:
> > Option 1 - HTTP-Header
> 
> OK.
> 
> Extra round trip in some situations.  But "ASK {}" is usually cheap
> and it opens the connection so next time it's ready.
> 
> Variation: location is another SPARQL endpoint loaded with the
> description ready to be queried.  Descriptions might get quite large
> when including lots of detail about the data available.

Variation on variation: the original SPARQL endpoint should have the
location as a named graph, ready to be queried. The location header
would give us access to the file or to the graph name.

> Variant (a bit of a cross between 2 and 3): add a new request parameter to ask for the service description (including content negotiation).  Sort of like (2) but moves the handling firmly into the service code.
> 
> http://example/service?servicedescription
> 
> Not keen but can live with.  Option 7 seems better.

Many Web Services stacks do that, so it's an already well-known pattern.
Its standardization in SPARQL might strengthen it. 

Also, this option seems to be part of the protocol, and as such it might
be coordinated with the issue about how to do update through the
protocol.

> >  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.
> 
> I can live with option 2.

I would like to see option 2 investigated, because if successful, this
pattern would IMHO give life to the underused OPTIONS method.



And another option: none of the above (0?)

All the options above for discovery of the service description hinge on
the client either a) knowing the service endpoint, or b) having access
to a SPARQL engine other than through a network protocol:

a) how does the client learn about the service endpoint? This is the way
the client might learn about the service description as well; in fact,
the client may even just learn the service description URI and the
description will point to the service endpoint.

b) if the endpoint is accessible through a local API, the API can easily
have a method like getServiceDescription() or queryServiceDescription().
I'm not sure if the group is standardizing an API, is it?

In other words, the feature may be seen as a bit backwards - first the
client knows about a service and then it wants to discover the service
description?


Has this been considered and tabled already?

Jacek

Received on Monday, 10 August 2009 14:05:33 UTC