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

RE: Service discovery redux - endpoint-based mechanisms

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 11 Sep 2009 14:13:26 +0000
To: Steve Harris <steve.harris@garlik.com>
CC: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693CFE9634@GVW1118EXC.americas.hpqcorp.net>


> -----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 "/"?
	
	Andy
Received on Friday, 11 September 2009 14:32:44 GMT

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