- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 10 Dec 2012 16:02:23 +0000
- 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