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 16:02:23 +0000
Message-ID: <50C6078F.701@epimorphics.com>
To: public-ldp-wg@w3.org


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.

(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:02:57 UTC

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