Re: Discovering service descriptions

On 11 Aug 2009, at 06:03, Gregory Williams wrote:

> On Aug 10, 2009, at 9:47 AM, 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.
>
> I currently implement the HTTP-header approach, and it seems to work  
> reasonably well (but I think I'd rather implement it in the query  
> engine -- details below).
>
>>> Option 2 - HTTP OPTIONS
>>
>> OK.  Similar comments to the above.
>>
>> Does this include content negotiation taking place?
>
> I'm still worried about HTTP OPTIONS not having a lot of support in  
> some client libraries. It also (I believe) make it difficult to get  
> at a service description with a web browser for visual inspection.  
> Do any browsers provide a way to make OPTIONS requests (I know curl  
> allows this)?

Certainly Firefox and Safari do. I don't have any others to test on,  
but a quick google suggests that IE and Chrome support it too. See http://www.w3.org/TR/XMLHttpRequest/

>>> Option 4 - DESCRIBE <sparql.endpoint.url>
>>
>> Don't want.  It's in the query.
>>
>> As well as affecting the info in the store, the service description  
>> is a property of the service, and not of the query engine.  A  
>> service associates the data to be queried with the query engine.  
>> The query engine might well be used across several service  
>> endpoints so would have to have more information than currently to  
>> handle in-query forms.  Making the mechanism part of the query  
>> engine(and query language) feels to me like a mismatch that will  
>> lead to trouble.
>
> Aren't there parts of the current proposed service descriptions that  
> belong to the query engine, not the protocol? Are supported  
> extension functions or entailment regimes part of the protocol, or  
> the underlying engine? Clearly things like a link to a description  
> of the dataset don't belong to the query engine, but I'm not as sure  
> about all of the service description data (I'm open to being  
> convinced). I'm sympathetic to the desire to keep the protocol and  
> query engine independent, but think I currently prefer the "DESCRIBE  
> ENDPOINT" approach (option 6) over the other options at this point,  
> with conneg (Option 7) a close second.
>
> Could someone provide a concise explanation of why the currently  
> proposed service description terms all belong at the protocol level?  
> (I'm honestly interested in this, but having a hard time thinking  
> about the entire SD as being either/or.)

Well, what if the endpoints offer some security/permissions regime of  
their own? Not really an uncommon situation. Then the endpoint would  
have to tell the query engine what security model it was being  
accessed under, so that the query engine could pretend to have some  
particular behaviour on behalf of the endpoint. A bit of a strange  
situation, and not something I want to implement myself.

On the other hand, the endpoint can (by definition) already ask  
queries of the backend, and is more likely to have some comprehension  
of its security model, so it's in a reasonable place to be able to  
answer any questions about the combination.

Also, DESCRIBE ENDPOINT assumes that there's only one endpoint. Which  
is often not the case, and will increasingly not be the case when we  
have update endpoints.

- 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 06:02:17 UTC