- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 10 Dec 2012 19:03:58 +0000
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Eric Prud'hommeaux <eric@w3.org>
On 10/12/12 18:02, Wilde, Erik wrote: > hello eric. > > On 2012-12-10 08:47 , "Eric Prud'hommeaux" <eric@w3.org> wrote: >> Defining in terms of SPARQL doesn't demand implementation with SPARQL. >> Also, it's easy for people to experiment with and understand SPARQL by >> grabbing any of a number of free tools. > > you're just shifting things around here. of course there doesn't need to > run a SPARQL engine underneath every implementation, but if our query > language is close in complexity to SPARQL, then service implementers > without native SPARQL back-ends will have to implement the mapping, and > will get close to having to implement SPARQL. which we probably don't want > to place as a burden on every LDP implementation. I wasn't suggesting it would be close in complexity to SPARQL - I was suggesting that the meaning of LDP-QL is defined by reference to SPARQL. Reusing gets us all the error handling and corner cases. While ?q=rdfs:value%3Dfoo defined to be the same as SELECT ?item { ?item rdfs:value "foo" } is simple, it can quite easily get more complicated to define queries: ?q=rdfs:value%3C123 ## %3C is < if it is the same as SELECT ?item { ?item rdfs:value ?v. FILTER(?v < 123) } then it covers errors cases like what happens when ?v is a URI. And the result set formats (JSON, CSV, TSV) may be useful. Andy >> This makes it a bit more approachable than other formal definitions (e.g. >> the definition of a "parent/child" selection in XPath >> <http://www.w3.org/TR/xquery-semantics/#jd_uioi>, to take an entertaining >> extreme.) > > all depends on where you're coming from. it should be approachable for as > many people as possible, and not just people with a five-year background > in [SPARQL|XQuery]. > >> Of course, it may be that the definitions would use so little of SPARQL >> as to make the reference pointless, but we should at least treat SPARQL >> definitions as plan A. > > my suggestion would be to try really hard to avoid SPARQL being a > normative reference. illustrative in the implementation guide: yes. > > cheers, > > dret. >
Received on Monday, 10 December 2012 19:04:28 UTC