W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: Discovering service descriptions

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 10 Aug 2009 16:39:43 +0100
Message-Id: <E6A03441-F159-47AF-88EF-E8BAD23E7691@garlik.com>
To: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 10 Aug 2009, at 14:47, 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.

It could also required of the endpoint when requests have no query=  
parameter. May as well go for option 7 at that point though.

> Variation: location is another SPARQL endpoint loaded with the  
> description ready to be queried.  Descriptions might get quite large  
> when including lots of detail about the data available.

Don't really like that - it requires that the endpoint itself be a  
SPARQL processor, which isn't necessarily the case.

>> Option 2 - HTTP OPTIONS
>
> OK.  Similar comments to the above.
>
> Does this include content negotiation taking place?
>
>> Option 3 - Well-known location
>
> Don't want.  Don't like enforcing naming issues like this.

+1

>> Option 4 - DESCRIBE <sparql.endpoint.url>
>
> Don't want.  It's in the query.

+1

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

+1

>> Option 5 - Query
>
> Don't want.  It's in the query.
>
>> Option 6 - DESCRIBE_ENDPOINT
>
> Don't want.  It's in the query.
>
>> Option 7 - Conneg
>
> OK.

Also has the advantage that it's independent of SPARQL, and the SPARQL  
protocol. Doesn't matter so much to this WG, but for people who  
support multiple query languages, or people developing SemWeb query  
languages in the future, that's important.

> ----
>
> Variant (a bit of a cross between 2 and 3): add a new request  
> parameter to ask for the service description (including content  
> negotiation).  Sort of like (2) but moves the handling firmly into  
> the service code.
>
> http://example/service?servicedescription
>
> Not keen but can live with.  Option 7 seems better.

- 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 Monday, 10 August 2009 15:40:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT