Keywords

1 Introduction

Web APIs are commonly used to enable HTTP-based, machine-processable access to all sorts of data. Similarly, Linked Data (LD) seek the publication of machine-readable data on the Web while connecting related resources across datasets. Several approaches have been proposed to bridge these two worlds, based on bespoke wrappers, SPARQL extensions or RESTful APIs. Until now however, several challenges hinder the definition of standard approaches to enable automatic reconciliation of LD and Web APIs. Firstly, Web APIs usually rely on proprietary vocabularies documented in Web pages meant for developers but hardly machine-readable. Secondly, on-the-fly SPARQL querying of non-RDF data sources proves to be difficult, as attested by the many works on SPARQL-based access to legacy databases.

The SPARQL Micro-Service architecture aims to address this issue. The term micro-service refers to an increasingly popular architectural style where an application consists of a collection of lightweight, loosely-coupled, fine-grained services that are deployed independently [2]. They improve applications modularity thereby speeding up the development, testing and deployment process. Leveraging these principles may help in the design of modular LD-based applications structured as a collection of services such as RDF stores, SPARQL endpoints, SPARQL micro-services or other services based on LD REST APIs for instance. A SPARQL micro-service is a lightweight method to query a Web API using SPARQL. It provides access to a small RDF graph describing the targeted resources from the data available at the API, while dynamically assigning dereferenceable URIs to Web API resources that do not have URIs beforehand.

2 SPARQL Micro-services Principles

A SPARQL micro-service \(S_{\mu }\) is a wrapper of a Web API service \(S_w\). It complies with the SPARQL Query Language and protocol, and accepts a set \(Arg_w\) of arguments that are specific to \(S_w\). These arguments are passed to \(S_{\mu }\) as parameters on the HTTP query string, e.g. “http://hostname/sparql?param=value”. \(S_{\mu }\) evaluates a SPARQL query Q against an RDF graph that it builds at run-time as follows: it invokes the Web API service \(S_w\) with the arguments in \(Arg_w\), translates the response into RDF triples (in an implementation-dependent manner), evaluates Q against these triples and returns the result to the client.

The semantics of a SPARQL micro-service differs from that of a standard SPARQL endpoint insofar as the SPARQL protocol treats a service URL as a black box, i.e. it does not interpret URL parameters. By contrast, a SPARQL micro-service is a configurable SPARQL endpoint whose arguments delineate the virtual graph being queried. Thence, each pair (\(S_{\mu }\), \(Arg_w\)) is a standard SPARQL endpoint. Arguably, other options may be adopted to pass the arguments to \(S_{\mu }\), that we discuss in details in [1].

Furthermore, bridging Web APIs and LD requires to create stable, dereferenceable URIs for Web API resources that are generally identified by mere proprietary identifiers. This is implemented quite easily with SPARQL micro-services: once a stable URI scheme is decided, a Web server is set up to handle look-ups for URIs matching that scheme: for each look-up, it invokes a suitable SPARQL micro-service along with an appropriate CONSTRUCT or DESCRIBE query form. Hence, by smartly designing services, we can come up with a consistent ecosystem where some micro-services respond to SPARQL queries while translating Web API identifiers into URIs that, in turn, are made dereferenceable by other micro-services.

3 Implementation and Experimentation

To evaluate this architecture, we have developed a prototype implementationFootnote 1 depicted in Fig. 1, that handles JSON-based Web APIs. It maps a Web API response to RDF triples in two steps. First, the response is translated to JSON-LD by applying a JSON-LD profile. The resulting graph G is stored in an in-memory triple store. Then, for mapping cases that JSON-LD cannot describe (involving e.g. string manipulations), a SPARQL INSERT query augments G with triples based on well-adopted or domain vocabularies. Lastly, \(S_{\mu }\) evaluates the client’s SPARQL query against G and returns the response following a regular content negotiation.

Listing 1.1 exemplifies the use of SPARQL micro-services in a biodiversity-related use case. The query retrieves the URI of a resource representing the common dolphin (species Delphinus delphis) from a taxonomic register. Then, it invokes SPARQL micro-services to retrieve additional data from three Web APIs: photos from the Flickr photography social networkFootnote 2, audio recordings from the Macaulay LibraryFootnote 3 and music tunes from MusicBrainzFootnote 4. Figure 2 portrays a snippet of the response to this query in the Turtle syntax, along with photos, audio recordings pictures and a MusicBrainz Web page.

Fig. 1.
figure 1

Example SPARQL micro-service implementation for JSON-based Web APIs.

Full size image
figure a
Fig. 2.
figure 2

Snippet of the response to query Q (Listing 1.1) along with snapshots of the images, audio recordings and Web page whose URLs are part of the response.

Full size image

4 Future Works

For an ecosystem of SPARQL micro-services to emerge from independent service providers, two crucial issues shall be tackled. Firstly, to enable services discovery, SPARQL micro-services should provide self-describing metadata such as the query string parameters or the types of triples generated. In this respect, the smartAPI metadata specification may be leveraged [4]. Secondly, it should be possible to retrieve fragments by smaller pieces using a paging mechanism. To tackle those issues, Triple Patterns Fragments (TPF) expose a self-describing, uniform interface consisting of metadata and hypermedia controls [3]. A perspective would be to extend this approach to the case of SPARQL micro-services, stemming some sort of Graph Pattern Fragment interface, i.e. a generalized TPF interface able to process regular graph patterns instead of only triple patterns, but still complying with the TPF metadata and hypermedia controls specification. Let us finally mention that we have focused specifically on consuming Web APIs data with SPARQL, although the principles presented in this work could apply to other types of APIs. Furthermore, many APIs empower users not only to read but more importantly to interact with data. Hence, an interesting perspective would be to think of SPARQL micro-services as a way to support distributed SPARQL Update over Web APIs, thus eventually contributing to build an actual read-write Web of Data.