RE: Discovering service descriptions



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Gregory Williams
> Sent: 11 August 2009 06:03
> To: SPARQL Working Group
> Subject: 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
> 

I don’t disagree.  The features span several aspects and we are going to have to find a pragmatic balance.  Looking from the callers point of view, all that matters is the service capabilities, whether its service, dataset or query engine providing the capability.

Features of the query engine can be obtained by the service (internally) asking the engine.  It seems a bit over-specified to spend WG time of the service-QE connection at this point.  My sense is that the QE features are likely to be quite static, so not doing it purely standardised automatically is acceptable. 

For completeness, we could separate the different aspects of service description:
  Service
  Dataset
  Query Engine
With mechanisms that go straight to the right place.  But from the callers point of view, it's the service that matters so that is unhelpful to clients.

 Andy

Received on Tuesday, 11 August 2009 10:56:01 UTC