W3C home > Mailing lists > Public > public-ldp-wg@w3.org > December 2012

Re: query your API

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Mon, 10 Dec 2012 19:03:58 +0000
Message-ID: <50C6321E.3000401@epimorphics.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:26 UTC