- 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>
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, Markus [1] http://www.markus-lanthaler.com/hydra/ -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 7 May 2013 19:49:41 UTC