Re: Discovering service descriptions

On 10 Aug 2009, at 15:04, Jacek Kopecky wrote:
> 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.

That falls foul of the problem where a SPARQL query answering system  
has multiple endpoints, or where it's not sure what endpoint URIs are  
used to access it. This is pretty common with people using reverse  
proxies in front of eg. Jetty services.

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

Agreed. At a first glance it seems like it might not have quite the  
right intention, as the RFC says "Responses to this method are not  
cacheable". Which wouldn't fit the kind of use-cases I had in mind.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Monday, 10 August 2009 15:52:34 UTC