W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2013

RE: Query languages LDPath / JSON-LD Framing

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Tue, 7 May 2013 21:49:11 +0200
To: "'Andreas Kuckartz'" <A.Kuckartz@ping.de>
Cc: <public-linked-json@w3.org>
Message-ID: <02c101ce4b5b$f31e9d20$d95bd760$@lanthaler@gmx.net>
On Tuesday, May 07, 2013 4:53 PM, Andreas Kuckartz wrote:
> Markus Lanthaler:
> > could you please elaborate what you mean by query language? Do you
> want to query remote data or local data?
> Remote data: this is for the oparl.de standard.

I knew it :-)

> >> 1. easy to implement (even for legacy software),
> >> 2. useful in a RESTful JSON-LD context and
> >> 3. future proof.
> >
> > So I assume you want to query some remote JSON-LD data, is that
> correct?
> Correct.
> > Do you have the data in a triple store?
> That normally will not be the case: relational databases will mostly be
> used.
> > If you do, you might also wanna look at
> http://lmatteis.github.io/restpark/ which generated some buzz recently.
> It defines a minimal API to query a triple store.
> The description of Restpark is interesting:
> "Having a lightweight alternative to SPARQL which developers could
> implement themselves on top of their existing storage solution (MySQL,
> MongoDB, etc.) using the language they want (PHP, Java, Node.js), would
> lower the entry barrier for Semantic Web data understanding and
> retrieval."
> In the oparl.de use case there is a limited number of "predicates" so
> it
> might be feasible to create such an API for a relational database.

What you are trying to do is defining a (RESTful) interface to query an API. Typically, APIs define the available query parameters using a URI template. Some APIs embed forms (similar to HTML pages) for things like this.

I'm working on an approach called Hydra [1] (as you know). It allows you to define URI templates and bind the variables to properties (predicates). So it's similar to a form and should provide the functionality you are looking for. Unfortunately I haven't found the time yet to document it properly. You could use it as follows in your APIs home document (using prefixes):

  "@context": {
    "@vocab": "http://purl.org/hydra/core#",
    "oparl": "http://oparl.de/vocab#",
  ... other data ...
  "oparl:search": {
    "template": "http://example.com/search{?user,state}",
    "mappings": [
      { "variable": "user", "property": "oparl:user" },
      { "variable": "state", "property": "oparl:state" }

The advantage is that a client doesn't need to know anything beforehand. It can discover the interface at runtime which brings you quite a lot of flexibility.

Do you know what queries you need to support? Or do you need to query the data by arbitrary criterions?

Hope this helps,

[1] http://www.markus-lanthaler.com/hydra/

Markus Lanthaler
Received on Tuesday, 7 May 2013 19:49:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:37 UTC