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

Re: query your API

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 10 Dec 2012 11:47:07 -0500
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Cc: public-ldp-wg@w3.org
Message-ID: <20121210164705.GC25523@w3.org>
* Andy Seaborne <andy.seaborne@epimorphics.com> [2012-12-10 16:02+0000]
> On 10/12/12 15:45, Wilde, Erik wrote:
> >hello andy.
> >
> >On 10 Dec 2012, at 07:29, "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote:
> >>>we had some agreement that we cannot depend on LDP being implemented on
> >>>top of a SPARQL-capable back-end. which means that any generic SPARQL
> >>>capabilities are not possible. instead, we need LDP-specific query
> >>>capabilities, specifying queries of the LDP model.
> >>Yes, to not depend on SPARQL.
> >>But another query language seems to make LDP a system that is costly to
> >>integrate into a wider app situation.  Would it be more than "find
> >>resources such that ..."?  If so, there is a whole infratsructure (e.g.
> >>results formats) that may need defining.
> >
> >most services don't define their own full-fledged query languages.
> typically they define simple filtering, maybe supporting AND/OR when
> they're fancy, and then they reuse the existing format for listing
> filtered collection contents. paging then can be reused as well.
> Ack.
> >>At least, define it by a mapping to SPARQL rather than define a
> >>independent QL.
> >
> >a mapping to SPARQL could be part of the implementation hints for people who are implementing on SPARQL back-ends, but that would be strictly informative.
> Either the formal definition of the LDP-QL is different to SPARQL's,
> so isn't mappable, or it's the same, and referring to another spec
> saves time.

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

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.

> (incomplete unencoding)
> ?q=rdfs:value%3Dfoo
> ==>
> SELECT ?item { ?item rdfs:value "foo" }
> (aside - this also illustrates the perennial problem of short names
> / URIs-in-URIs :: see LinkedDataAPI)
> >cheers,
> >
> >dret.
> >

Received on Monday, 10 December 2012 16:47:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC