Re: Discovering service descriptions

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)?

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

.greg

Received on Tuesday, 11 August 2009 05:04:06 UTC