Re: Discovering service descriptions

On 11 Aug 2009, at 15:00, Kendall Clark wrote:

> On Tue, Aug 11, 2009 at 9:45 AM, Chimezie Ogbuji<ogbujic@ccf.org>  
> wrote:
>> I think allocating a URI to the endpoint and using it for things  
>> such as
>> discovery (even within a query) is a good practice even in an API
>> environment.  It also *feels* very intuitiv
>
> +1.
>
> Especially since the endpoint URI is often -- at least in my
> experience -- the only thing I know about. So having some standard
> operation to perform with the endpoint URI as a parameter, the result
> of which returns a service description in RDF (or OWL) is the most
> appealing option for my organization.
>
> As for which operation (protocol level, query level), we tend to
> indifference. However, we mildly prefer:
>
> 1. DESCRIBE <serviceURI> in QL -- Lee's Option 4, IIRC (this one is
> especially nice since, in REST style, the representation returned by
> this query can just *point* to the service description via some
> specified predicate, rather than itself *being* the service
> description, in case existing services are already doing something
> different.)

Sure, it's tempting, but it brings with it all sorts of horrible  
corner cases.

If the endpoint is an aggregator, it's not likely that any of the  
backing stores know about the aggregator endpoint to any meaningful  
extent, so the endpoint itself will have to parse the SPARQL syntax to  
figure out if it's a request of this type and intercept it if so.  
That's pretty ugly.

Another is where you have multiple endpoints accessing one store, say http://public.example/ 
  and http://private.example/. Again the endpoint needs to somehow  
intercept the query, or update the store telling it what the  
endpoint's security model is.

Yet another problem is when you have an endpoint protected by a SSL  
proxy externally. I know several people do this. Internally the  
endpoint might be http://10.0.1.23/sparql/ but externally it might be http://example.com/data/sparql 
. However because there's a proxy/gateway in the way, there's no  
reasonable way for the store to know what endpoint(s) it's being  
accessed from, so again the endpoint will have to intercept such  
requests and rewrite to what the server is expecting, which may well  
render the RDF meaningless.

There are many such pitfalls.

It seems that asking the store is querying at the wrong level. It  
doesn't have all the information, and information needs to flow in the  
opposite direction to what you'd expect to enable it to answer the  
query. In my systems there's no way for the store to ask a query of  
the endpoint, and most of our live systems have multiple endpoints, so  
we simply couldn't support this in any real-world systems.

- 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 Tuesday, 11 August 2009 15:29:00 UTC