Re: query your API

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

+1
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.
> >
> 

-- 
-ericP

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