Re : Option 8 (was: Re: Service discovery redux - endpoint-based mechanisms)

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

If I understood correctly, the URI identifying the endpoint does not 
necessarily need to be the URL of the endpoint, ie. cf. [1]

Greg suggests in [1] the vocabulary providing a separate predicate

   sd:url

to point to the actual URL (in the case of your example probably the 
public one https://machine.example.com/myapp/sparql/), so is that really 
an issue?

In other words, would the relative URL be really needed?

Axel


1. http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0051.html

Steve Harris wrote:
> 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
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Wednesday, 19 August 2009 10:38:16 UTC