RE: Discovering service descriptions



> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@sti2.at]
> Sent: 10 August 2009 15:05
> To: Seaborne, Andy
> Cc: Lee Feigenbaum; SPARQL Working Group
> Subject: 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

I agree that this is just one way round where the endpoint is know and the description is to be obtained.

I can envisage learning about endpoint from elsewhere.  A rather useful case would be an aggregation of know services so an application can go and find a suitable endpoint for the data it needs.  I'd hope this because an important usage as it's about client code discovering places to go rather than being hardcoded.

I don't think it requires any standardization at this point in time.  I'd see it as emerging, like search engines have emerged.

 Andy

Received on Monday, 10 August 2009 14:22:24 UTC