- From: Pieter Colpaert <pieter.colpaert@ugent.be>
- Date: Thu, 26 Jan 2017 16:13:12 +0100
- To: public-lod@w3.org
Hi Albert, 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. 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. 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. 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/SALAD2016_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
Received on Thursday, 26 January 2017 15:13:47 UTC