- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Mon, 10 Dec 2012 10:45:59 -0500
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Roger Menday <roger.menday@uk.fujitsu.com>
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. > 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. cheers, dret.
Received on Monday, 10 December 2012 15:46:54 UTC