W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: Service discovery redux - endpoint-based mechanisms

From: Steve Harris <steve.harris@garlik.com>
Date: Sat, 12 Sep 2009 12:39:16 +0100
Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-Id: <B30B3348-3821-4A20-8AB5-51320A60D05F@garlik.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
On 11 Sep 2009, at 15:13, Seaborne, Andy wrote:
>> -----Original Message-----
>> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
>> request@w3.org] On Behalf Of Steve Harris
>> Sent: 14 August 2009 16:58
>> To: Lee Feigenbaum
>> Cc: public-rdf-dawg@w3.org Group
>> Subject: Re: Service discovery redux - endpoint-based mechanisms
>>
>> On 14 Aug 2009, at 14:34, Lee Feigenbaum wrote:
>>
>>> Steve Harris wrote:
>>>
>>>>> 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. :-)
>>>> There is an annoyance with it, which only just occurred to me.
>>>> There's no really easy way to reference the actual endpoint with a
>>>> relative URI, which is sadly necessary in many situations.
>>>> You can use </endpoint/sparql>, in the example above, but that
>>>> won't work in the general case if the endpoint is being reverse
>>>> proxied.
>>>
>>> Steve,
>>>
>>> I'm feeling a bit dense today, but don't totally understand what
>>> you're saying here. Mind giving an example?
>>
>> Sorry, the message was a bit terse.
>>
>> Imagine you have a SPARQL server running on
>> http://localhost:8080/sparql/
>> , internally to a server, firewalled, and you want to reflect that
>> externally as https://machine.example.com/myapp/sparql/ using a
>> reverse proxy (this might sound a bit odd, but I know of at least
>> three companies that are doing exactly this).
>>
>> If the service description if fetched from the exact endpoint URI,  
>> and
>> the description looks like:
>>
>> <> a sparql:Endpoint ;
>>    sparql:has sparql:featureA ;
>>    ...
>>
>> Then it will all work fine, from both the native endpoint and via the
>> proxy.
>>
>> However, if the description of http://localhost:8080/sparql/ lives at
>> http://localhost:8080/sparql/?serviceDescription
>> , then you can't use <>, so you have to write something like:
>>
>> </sparql> a sparql:Endpoint ;
>>    sparql:has sparql:featureA ;
>>    ...
>>
>> And that will give you an incorrect and unhelpful answer if you
>> request it as
>> https://machine.example.com/myapp/sparql/?serviceDescription
>>
>> - Steve
>
> Wouldn't <./> work for all cases where the service URL ends in "/"?

Yes, good point, but that doesn't help if the URI doesn't end in a /.

- 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 Saturday, 12 September 2009 11:39:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:08:26 GMT