- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 10 Aug 2009 16:39:43 +0100
- 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 UTC