Re: grlc turns your Linked Data queries into Linked Data APIs

Hi Pieter,

Thanks for your comments! Very useful pointers.

On 26 January 2017 at 16:13, Pieter Colpaert <pieter.colpaert@ugent.be>
wrote:

> Nice work! With The DataTank [1] we also released a similar feature back
> in 2012 that takes SPARQL templates at its input, and describes its output
> using DCAT-AP, the right HTTP headers for e.g., caching, and supports
> content negotiation. Next to also BASIL, also LimeDS [2] provides similar
> functionality, as a data adapter connecting various interfaces using a
> visual interface.
>

Really good to know these two. I think they share a good deal of their goal
with that of grlc (i.e. easing access to Linked Data via APIs), albeit the
method might differ (we essentially make queries de-referenceable, and wrap
APIs around those in a distributed fashion).


> I like these kinds of frameworks as they bridge the gap between publishing
> data as interoperable as possible – for maximum reuse – and front-end
> developers that want an app on top of a number of triples. They form an
> abstraction layer which can be used by front-end developers to quickly
> create a UI on top of data without having the take into account an open
> world assumption. Such frameworks are great tools for digital signage
> providers [3] and similar type of reuse that needs simple views, to take
> away some of the processing from a low-end device.
>

Yes, we took that inspiration from other projects like OpenPHACTS. We did
not want to create the next blackbox system though, so keeping queries and
API generation workflows decoupled was a priority. Consumer applications
might need plain SPARQL queries *and* their equivalent APIs simultaneously
available (like these queries [1], which are used in this app [2] and this
API [3]).


> To that extent, I would find it interesting if in the same way we could
> create an abstraction framework for more complex user agents. E.g., user
> agents that combine different data sources by crawling Linked Data using
> LDQL [4], the Linked Data Fragments client [5] or for the Linked
> Connections client for public transit route planning[6]. While when the
> caches of these type of user agents are cold, an end-user might have to
> wait some time for an answer, when the caches are hot – not unthinkable
> when all your end-users are asking very similar questions – results are
> probably going to be very fast.
>

This is a very interesting line of work we have already started to
experiment with. grlc already supports mixing access to SPARQL endpoints
and Linked Data Fragments servers (among others) in the same API. LDQL
would be an interesting addition, but that implies stream processing, and
efficient caching, of course.

Thanks again,
Albert

[1] https://github.com/CEDAR-project/Queries
[2] http://www.nlgis.nl/site?year=1982&code=TEGM
[3] http://grlc.io/api/CEDAR-project/Queries/


> Kind regards,
>
> Pieter
>
> [1] https://github.com/tdt/core
>
> [2] http://limeds.be/
>
> [3] Back in 2012, I introduced The DataTank at this company and it did
> this trick well: https://flatturtle.com
>
> [4] http://olafhartig.de/files/HartigPerezLDQL_JWSPreprint.pdf
>
> [5] http://client.linkeddatafragments.org/
>
> [6] http://linkedconnections.org
>
> On 26-01-17 13:58, Albert Meroño Peñuela wrote:
>
>> Hi all,
>>
>> Just letting you know that there is a public instance of grlc available
>> at [1]. No more hard-coded queries in your Linked Data consuming
>> applications!
>>
>> grlc [5], inspired by tools like BASIL [4], is a small server that
>> converts your SPARQL queries into Linked Data APIs, automatically and on
>> the fly. To do this, it assumes that your SPARQL queries are publicly
>> available in a GitHub (or similar) repository. For example, queries stored
>> in https://github.com/CLARIAH/wp4-queries have their equivalent API at
>> http://grlc.io/api/CLARIAH/wp4-queries/api-docs
>> (notice the user and repository names in the URIs). You can call API
>> endpoints by e.g. http://grlc.io/api/CLARIAH/wp4-queries/datasets
>>
>> Full details are described in this paper [2].
>>
>> The latest additions include a docker-based deployment, parameter
>> enumerations, result pagination, and compatibility with #LD servers, RDF
>> dumps, and HTML+RDFa pages (besides SPARQL endpoints).
>>
>> We would be pleased to hear from your experiences on using grlc: bugs,
>> performance, use cases, feature requests, etc. grlc's issue tracker can be
>> found at [3].
>>
>> Thanks,
>> Albert
>>
>> [1] http://grlc.io
>> [2] https://www.albertmeronyo.org/wp-content/uploads/2016/04/SAL
>> AD2016_paper_4.pdf
>> [3] https://github.com/CLARIAH/grlc/issues
>> [4] http://basil.kmi.open.ac.uk/app/#/collection
>> [5] https://github.com/CLARIAH/grlc
>>
>
> --
> +32486747122
>
>
>