SPARQL Micro-Services: Lightweight Integration of Web APIs and Linked Data Franck Michel Catherine Faron-Zucker Fabien Gandon University Côte d’Azur, University Côte d’Azur, University Côte d’Azur, CNRS, Inria, I3S, France Inria, CNRS, I3S, France Inria, CNRS, I3S, France franck.michel@cnrs.fr faron@i3s.unice.fr fabien.gandon@inria.fr ABSTRACT that these be accessible through standard interfaces ranging from Web APIs are a prominent source of machine-readable informa- sheer RDF dumps to full-fledged SPARQL endpoints. Here too, large tion. We hypothesize that harnessing the Semantic Web standards amounts of data about all sorts of topics are openly available3 . to enable automatic combination of Linked Data and non-RDF We hypothesize that harnessing the Semantic Web standards Web APIs data could trigger novel cross-fertilization scenarios. To to enable automatic combination of disparate resources represen- achieve this goal, we define the SPARQL Micro-Service architecture. tations coming from both Linked Data interfaces and Web APIs A SPARQL micro-service is a lightweight, task-specific SPARQL could trigger novel cross-fertilization scenarios. Major initiatives endpoint that provides access to a small, resource-centric, virtual such as Google’s Knowledge Graph4 or Facebook’s Open Graph5 graph, while dynamically assigning dereferenceable URIs to Web leverage these two worlds (alongside other types of data sources) API resources that do not have URIs beforehand. The graph is de- to come up with vast knowledge graphs. Strikingly enough though, lineated by the Web API service being wrapped, the arguments standard approaches still lack in this domain, as several issues must passed to this service, and the restricted types of RDF triples that be overcome: this SPARQL micro-service is designed to spawn. In this context, we • Vocabularies: Web APIs typically produce resource descrip- argue that full SPARQL expressiveness can be supported efficiently tions using negotiated media types such as JSON or XML, without jeopardizing servers availability. Eventually, we believe that however often rely on proprietary vocabularies. These that an ecosystem of SPARQL micro-services could emerge from vocabularies are commonly documented in Web pages meant independent service providers, enabling Linked Data-based appli- for application developers, but they are hardly machine- cations to glean pieces of data from a wealth of distributed, scalable readable. Conversely, Linked Data best practices [10] advo- and reliable services. We describe an experimentation where we cate the use of common, well adopted vocabularies described dynamically augment biodiversity-related Linked Data with data in machine-readable format. Consequently, consuming Web from Flickr, MusicBrainz and the Macauley scientific media library. API data as RDF triples often leads to the development of wrappers implementing bespoke vocabulary alignment. KEYWORDS • Parsimony: Web APIs commonly consist of many different Web API, SPARQL, micro-service, Data Integration, Linked Data, services (search by name/tag/group, organize content, inter- JSON-LD act with contacts, etc.). Providing a Linked Data interface for all of these services may require a significant effort, although ACM Reference Format: a tiny fraction of them may fulfill the needs of most use cases. Franck Michel, Catherine Faron-Zucker, and Fabien Gandon. 2018. SPARQL Therefore, a more parsimonious, on-demand approach may Micro-Services: Lightweight Integration of Web APIs and Linked Data. In Proceedings of Linked Data on the Web. ACM, New York, NY, USA, 10 pages. be more relevant. • Trades-offs: each type of Linked Data interface has its own 1 INTRODUCTION benefits and concerns. RDF dumps allow in-house consump- tion but do not fit in when data change at a high pace; Web APIs are a common means for Web portals and data producers URI dereferencing provides subject-centric documents hence to enable HTTP-based, machine-processable access to their data. lacking query expressiveness; SPARQL [8] is more expres- They are a prominent source of information1 pertaining to topics sive but puts the query processing cost solely on the server, as diverse as entertainment, finance, social networks, government and it has been shown that allowing clients to run arbitrary or scientific information. Many of them follow a REST or “REST- SPARQL queries against public endpoints leads to unsatisfac- like” architecture2 ensuring a relatively uniform access to resource tory availability [2]. Besides, on-the-fly SPARQL querying of descriptions. In a similar perspective, Linked Data [9] seek the non-RDF legacy data proves to be difficult, as attested by the publication of machine-readable data on the Web, but go one step many works on SPARQL-based access to relational [20, 25] beyond. Connecting related RDF datasets brings about the ability to or NoSQL [18, 22] databases. query and make sense of distributed knowledge graphs, provided Verborgh et al. defined a framework to analyze and compare 1 19,000+ Web APIs are registered on ProgrammableWeb.com as of January 2018. different Linked Data query interfaces [28]: a response to a query 2 REST-like refers to loosely-defined architectures complying with some REST princi- ples but relaxing others. 3 Almost 10,000 knowledge graphs are inventoried by LODStats as of January 2018 (http://lodstats.aksw.org/). Linked Data on the Web, April 2018, Lyon, France 4 https://goo.gl/BqMC21 . 5 http://ogp.me/ Linked Data on the Web, April 2018, Lyon, France Franck Michel, Catherine Faron-Zucker, and Fabien Gandon Figure 1: Granularity of different types of Linked Data Fragments returned by different Linked Data query interfaces against such an interface is called a Linked Data Fragment (LDF). Dif- 2 MICRO-SERVICE AND LINKED ferent LDF types can be sorted by the granularity of their querying DATA-BASED APPLICATIONS mechanism, as depicted on Figure 1: on the left hand-side, querying The term micro-service refers to an architectural style, also called consists of a mere download operation and clients bear the full cost fine-grained SOA, where an application consists of a collection of of evaluating queries against RDF dumps; on the right hand-side, services that are loosely coupled, fine-grained (designed to fulfill SPARQL enables expressing specific queries but endpoints fully a single function) and independently deployable [23]. There is no bear the evaluation cost. Between these two extremes lies a spec- standard definition of micro-services at this point, however a con- trum of intermediate approaches: a Linked Data document results sensus is emerging about commonly agreed upon principles [5, 30]. from a URI dereferencing; a Triple Pattern Fragment [28] (TPF) re- Compared to traditional monolithic applications, the micro-service sults from evaluating a single triple pattern against an RDF dataset. architectural style improves modularity by making applications eas- TPFs succeed in balancing the query evaluation cost between the ier to develop, maintain and test. Development teams are typically client and the server, thereby enabling better server availability geared towards continuous refactoring, delivery and deployment of and efficiency than full-fledged SPARQL endpoints. Still, we can the services they are responsible for, independently of other teams. think of solutions wherein servers can compute more expressive More complex services are achieved by composition on top of these queries (more than just a triple pattern) without jeopardizing their fine-grained services. sustainability. Micro-services have been increasingly adopted during the last six In this paper, we address the specific goal of combining Web APIs to seven years, not only by major Web companies who inspired this data and Linked Data. We propose an additional type of Linked architecture, but also by many other companies that need to speed Data Fragment interface called SPARQL Micro-Services, by anal- up the development and deployment of their services. Like any ogy with the popular micro-services architecture that structures architecture style, the experience shows that micro-services have an application as a collection of lightweight, loosely-coupled ser- pitfalls of their own6 . In particular, figuring out the appropriate size vices designed for a specific task [23]. A SPARQL micro-service is a of a micro-service (its functional scope) is critical in many aspects. lightweight method to query a Web API using SPARQL. It provides Nevertheless, leveraging these principles may help in the design of access to a small, resource-centric, virtual graph, while dynamically distributed, modular Linked Data-based applications structured as assigning dereferenceable URIs to Web API resources that do not a collection of lightweight, loosely-coupled services. These services have URIs beforehand. This graph corresponds to a fragment of would typically be RDF stores, URI dereferencing services, SPARQL the whole dataset served by the Web API, delineated by (i) the Web endpoints, Linked Data Platform [26] compliant services, etc. Light- API service that is bridged by this SPARQL micro-service; (ii) the weight container technologies, such as the popular Docker7 , could arguments passed to this Web API service; and (iii) the restricted underpin the quick and elastic deployment of such Linked Data- types of RDF triples that this SPARQL micro-service is designed based applications, enabling on-demand scaling up or down by to spawn. Since a query is evaluated against a somewhat limited simply starting or stopping instances of these services. graph, its processing cost can be kept low. Hence, unlike Triple The SPARQL micro-service architecture is a proposition towards Pattern Fragments, SPARQL micro-services allow full SPARQL ex- this goal. We think of SPARQL micro-services as independent soft- pressiveness without risking server overloading. They are depicted ware units being developed along with the arising of needs. A micro- on Figure 1, half-way between TPF and SPARQL. service development team focuses on one Web API at a time, defines The rest of this article is organized as follows. Section 2 first how to wrap a few services, tests and publishes them. Instead of reminds the micro-service architectural principles and sketches being constrained to use specific technologies within a monolithic how these could apply to the development of Linked Data-based application, the team picks the programming language(s), Semantic applications. Then, sections 3 and 4 define in more details the Web stack and other third-party technologies that it deems most SPARQL micro-service architecture. In sections 5 and 6 we present appropriate for a specific service. our implementation and the experimentation we have conducted. Related works are discussed in section 7 while the last section sums up our approach and suggests future leads. 6 https://www.infoq.com/news/2014/08/failing-microservices 7 https://www.docker.com. SPARQL Micro-Services Linked Data on the Web, April 2018, Lyon, France Figure 2: Example implementation of a SPARQL micro-service. A JSON-LD profile interprets the Web API JSON response as a temporary graph G stored in the local RDF triple store. An INSERT query optionally augments G with RDF triples that JSON-LD cannot yield. Lastly, the client’s query is evaluated against G. 3 THE SPARQL MICRO-SERVICE Algorithm 1 Evaluation of a SPARQL query by a SPARQL micro- ARCHITECTURE service S µ . 3.1 Definition (1) S µ receives a SPARQL query Q along with arguments Arдw . (2) S µ invokes the Web API service Sw with the arguments in A SPARQL micro-service S µ is a wrapper of a service Sw of a Web Arдw . The response is a fragment Fw of the dataset served API. It behaves as a regular SPARQL endpoint insofar as it sup- by the Web API. ports the SPARQL Query Language [8] (including all query forms: (3) S µ translates Fw into a Linked Data Fragment F LD and loads SELECT, ASK, CONSTRUCT, DESCRIBE) and the SPARQL Proto- it into a triple store as a temporary graph G. col [6]. It is thus invoked over HTTP/HTTPS by passing a SPARQL (4) S µ evaluates Q against G and returns the result to the client. query (argument query in the GET or URL-encoded POST meth- ods, or HTTP payload in the direct POST method) and optional default and named graph URIs (arguments default-graph-uri and named-graph-uri). 3.2 Caching Strategy Additionally, S µ accepts a possibly empty set Arдw of argu- Querying Web APIs is often a time-consuming task, as suggested by ments that are specific to the service being wrapped. They are the measures we report in section 6. Thus, when possible, defining passed to S µ as parameters on the HTTP query string; in turn, S µ caching strategies may be necessary to achieve the performance passes them on to Sw . Accordingly, while the URL of a regular expected by some applications. There typically exist many syntac- SPARQL endpoint is typically of the form “http://hostname/sparql”, tical variants of the same SPARQL query. Such that classic HTTP a SPARQL micro-service is invoked with additional parameters, proxy servers set up between SPARQL clients and servers fail to like “http://hostname/sparql?param1=value1¶m2=value2”. reach efficient cache reuse. By contrast, Web API queries allow a The semantics of a SPARQL micro-service differs from that of a lesser syntactical variability. Therefore, in the context of SPARQL standard SPARQL endpoint insofar as the SPARQL protocol treats micro-services, enforcing a cache strategy on the Web API side a service URL as a black box, i.e. it does not identify nor interprets should ensure better cache reuse. Typically, Web API queries could URL parameters in any way. By contrast, a SPARQL micro-service be used to index either the Web API responses or the temporary is a configurable SPARQL endpoint whose set Arдw of arguments graphs produced from them. delineates the scope of the virtual graph that is being queried. Furthermore, some Web APIs provide data expiration informa- Thence, each pair (S µ , Arдw ) is a standard SPARQL endpoint. As we tion (such as the Expires, Cache-Control and/or Last-Modified HTTP see it, the graph accessed through (S µ , Arдw ) is typically resource- headers) on which a caching system can rely to figure out a caching centric and corresponds to a small fragment of the dataset served strategy. When no such information is provided, a SPARQL micro- by the Web API. service may authoritatively decide on an appropriate expiration Figure 2 illustrates the SPARQL micro-service architecture in the period depending on the type of service being wrapped. case of the implementation we describe further on in section 5. S µ evaluates a SPARQL query against an RDF graph that it builds at 3.3 Errors Management run-time following Algorithm 1 (the algorithm’s steps are depicted A typical client’s SPARQL query may invoke several SPARQL micro- on Figure 2). Note that how the transformation at step (3) is carried services simultaneously using multiple SERVICE clauses. The fail- out is implementation-dependent. In the case of JSON-based Web ure of a non-critical micro-service (due e.g. to a network error or a APIs, our implementation first applies a JSON-LD profile to the Web Web API error) should not hinder processing the other ones and API response and optionally executes a SPARQL INSERT query returning partial results. Hence, a client may use the SILENT key- to yield additional triples. However, various other methods may word to ignore errors from a SPARQL micro-service, and possibly be used at this point, involving e.g. different flavors of mapping, embed SERVICES clauses within OPTIONAL clauses to allow for reasoning or rule processing. the production of partial results (this is exemplified later on in Listing 4). Linked Data on the Web, April 2018, Lyon, France Franck Michel, Catherine Faron-Zucker, and Fabien Gandon photos ": { { "photos 3.5 Discussion page ": 1, "pages "page pages ": "22689" , photo ": [ "photo In this proposition, a design decision is to pass the arguments of Arдw to S µ as HTTP query string parameters. Arguably, other id ": "38427227466" , "title { "id title ": " Brooklyn Bridge sunset ", owner ": "33634811 @N07 ", "ownername "owner ownername ": " Franck Michel ", secret server ": "4542" , "farm "secret ": "100 fa110d0 ", "server farm ": 5 } solutions may be adopted. Below we discuss the respective benefits ] } } and drawbacks of some alternatives we identified. A first alternative consists in defining one predicate for each prefix api : < http :// sms . i3s . unice . fr / schema /> photos [ [] api :photos argument, e.g.: page "1"; api :pages api :page pages "22689"; photo [ api :photo prefix api : < http :// sms . i3s . unice . fr / schema /> id "38427227466"; api :title api :id title " Brooklyn Bridge sunset "; SELECT ? img WHERE { owner "33634811 @N07 "; api :ownername api :owner ownername " Franck Michel "; SERVICE < http :// hostname / flickr / getPhotosByGroupByTag > secret "100 fa110d0 "; api :server api :secret server "4542"; api :farm farm "5". { ? photo foaf : depiction ? img ; ] ]. api : group_id "806927 @N20 "; api : tags " bridge ". Listing 1: Snippet from an example Flickr Web API response } (top), and equivalent RDF triples in the Turtle syntax [1] pro- } duced by applying a simple JSON-LD profile (bottom). At a first sight, making the arguments explicit can seem compelling as they can be used in other triples of the graph pattern. Besides, such a SPARQL micro-service is a standard SPARQL endpoint since 3.4 Example there is no more variable part in the service endpoint URL. Several concerns should be pointed out however. (i) This solution requires We now illustrate Algorithm 1 with an example based on Flickr’s that each SPARQL micro-service be defined along with its own Web API8 . Let Sw be the Flickr service that retrieves photos posted bespoke terms, whereas we seek a solution wherein only terms of in a specific group and having a specific tag9 . Arдw (the arguments well-adopted vocabularies would be exposed. (ii) In this example, of Sw ) comprises two arguments, group_id and tags. A SPARQL the group_id and tags arguments are meaningful for the end user. micro-service S µ wraps Sw . In step 1, a client willing to retrieve the But some services may require more technical arguments that we URLs of photos matching some specific group and tags executes a typically do not want to define as ontological terms. (iii) Further- SPARQL query “SELECT ?img WHERE {?photo foaf:depiction ?img.}” more, this solution questions the nature of the subject to which the against S µ . Using the SPARQL HTTP GET method [6], S µ is invoked arguments are associated. Again, in this specific example, declaring as follows: the group_id and tags as properties of the photographic resource http :// hostname / flickr / getPhotosByGroupByTag ? tags = bridge & ?photo is an acceptable choice, but this would be inappropriate group_id =35034350743 @N01 &tags query = SELECT \%20\%3 Fimg \%20 WHERE \%20\%7 B \%3 Fphoto \ with internal or technical service parameters. \%20 foaf \%3 Adepiction \%20\%3 Fimg .\%7 D This issue can be solved by associating the arguments to a sepa- rate resource depicting the service itself. This is exemplified in the Interestingly enough, this is precisely the invocation that would be second alternative that, furthermore, defines a vocabulary to pass performed by the SERVICE clause in the following SPARQL query: the arguments in a uniform manner. Note that existing vocabularies SELECT ? img WHERE { may be tapped for that matter, such as Hydra [14] or the HTTP SERVICE < http :// hostname / flickr / getPhotosByGroupByTag ? \ group_id =35034350743 @N01 & tags = bridge > Vocabulary in RDF [12]. In the example below, additional triple { ? photo foaf : depiction ? img . } patterns define an instance of the hypothetical api:Service class, } that takes arguments declared with the api:param predicate. In step 2, S µ invokes Sw with the arguments of Arдw in addition prefix api : < http :// sms . i3s . unice . fr / schema /> SELECT ? img WHERE { to other arguments possibly required by the Web API (for the sake SERVICE < http :// hostname / flickr / getPhotosByGroupByTag > of clarity we have left over some technical arguments). Listing 1 { ? photo foaf : depiction ? img . (top) sketches a snippet of the response to this query: [] a api : Service ; https :// api . flickr . com / services / rest /? api : param [ api : name " group_id "; api : value "806927 @N20 " ]; method = flickr . groups . pools . getPhotos & format = json & api : param [ api : name " tags "; api : value ? tag ]. group_id =35034350743 @N01 &tags tags = bridge } } Step 3 is implementation dependent. The prototype implementa- tion presented in section 5 draws on the method proposed by the A slight variation could state that the service URL itself is an in- JSON-LD specification [27] to interpret regular JSON content as a stance of api:Service; the arguments would then configure an serialized RDF graph. The resulting graph G is stored into a triple execution of this service with predicate api:execution, e.g.: < http :// hostname / flickr / getPhotosByGroupByTag > store, and an optional SPARQL INSERT query yields additional a api : Service ; triples using relevant domain vocabularies. api : execution [ Finally, in step 4, S µ evaluates the client’s SPARQL query against api : param [ api : name " group_id "; api : value "806927 @N20 " ]; G and returns the response in one of the media types supported by ]. api : param [ api : name " tags "; api : value ? tag ]. the SPARQL client (following a regular content negotiation). While these alternatives avoid defining new predicates for each 8 https://www.flickr.com/services/api/ micro-service, the additional triples bear a somewhat artificial se- 9 https://www.flickr.com/services/api/flickr.groups.pools.getPhotos.html mantics: they provide the service with information as to how to SPARQL Micro-Services Linked Data on the Web, April 2018, Lyon, France Figure 3: URI dereferencing: a Web server rewrites a URI look-up query into a query to the relevant SPARQL micro-service. process the other parts of the graph pattern, but they do not actu- it queries the SPARQL micro-service and transparently proxies the ally refer to nor describe the photographic resources that the graph response back to the client. Figure 3 sketches this architecture. pattern aims to match. Let us assume the getPhotoById SPARQL micro-service retrieves In a third alternative, the service arguments are passed as SPARQL photos by their identifier. If the Web server receives a look-up for the variables with pre-defined names, e.g. ?group_id and ?tags in the URI “http://example.org/ld/flickr/photo/38427227466”, it invokes example below: the getPhotoById micro-service with the following query string: http :// hostname / flickr / getPhotosById ? SELECT ? img WHERE { photo_id =38427227466& SERVICE < http :// hostname / flickr / getPhotosByGroupByTag > query = DESCRIBE \%20\%3 Chttp \%3 A \%2 F \%2 Fexample . org \%2 Fld \ { ? photo foaf : depiction ? img . \%2 Fflickr \%2 Fphoto \%2 F38427227466 \%3 E BIND ("806927 @N20 " AS ? group_id ) The value of argument “query” is the URL-encoded string for: BIND (" bridge " AS ? tags ) } DESCRIBE . } The response to this query will be proxied back to the client in one of the negotiated media types. Similarly to the previous alternative, variables ?group_id and ?tags Hence, by smartly designing SPARQL micro-services, we can are artificial insofar as they provide the service with information build a consistent ecosystem where some micro-services respond as to how to process the other parts of the graph pattern. to SPARQL queries by translating Web API internal identifiers The solution proposed in this article is a trade-off meant to satisfy into URIs, and some micro-services (possibly the same) are able to certain goals. Above, we have discussed some alternative solutions, dereference these URIs. and others may probably be figured out. We believe that further discussions should be engaged to assess the benefits and concerns 5 IMPLEMENTATION of these alternatives with respect to the contexts and goals. To evaluate the architecture proposed in section 3, we have devel- oped a prototype implementation in the PHP language, available 4 ASSIGNING URIS TO WEB API RESOURCES on Github10 under the Apache 2.0 license. This prototype complies Web APIs often provide resource descriptions that rely on internal, with the choices pictured in Figure 2: it assumes that Web APIs are proprietary identifiers. For instance, Listing 1 mentions the photo able to provide a JSON response, and thence requires each SPARQL identifier “38427227466” that has no meaning beyond the scope of micro-service to provide a JSON-LD profile as a first mapping step Flickr’s Web API. One may argue that the URL of this photo’s Web towards RDF. page could serve as a URI, but this would just approve a questionable SPARQL queries. The processing of SPARQL queries is imple- practice that confuses a resource (a photographic work in this case) mented as depicted in Figure 2. First, a JSON-LD profile is applied with an HTML representation thereof. to the Web API JSON response. Following up on the example in- Therefore, bridging Web APIs and Linked Data not only requires troduced in section 3, S µ applies to the API response the JSON-LD to enable SPARQL querying of Web APIs, but also to dynamically profile below, that turns each JSON field name into an ad hoc RDF create URIs that identify Web API resources. Furthermore, accord- predicate within namespace “http://sms.i3s.unice.fr/schema/” (note ing to Linked Data best practices [10], it should be possible to look that any arbitrary complex profile may be used at this point): up these URIs in order to retrieve a description of the resources @context ": {"@vocab {"@context @vocab ": " http :// sms . i3s . unice . fr / schema /"}}. in a negotiated media type. Conventionally, dereferencing a URI returns a set of RDF triples where the URI is either in the subject or The resulting graph G, depicted in Listing 1 (bottom), is stored in object positions. This is typically achieved through a CONSTRUCT the Corese-KGRAM in-memory triple store [3]. It exhibits propri- or DESCRIBE SPARQL query form. etary, technical predicates such as servers and farms identifiers, that Implementing URI dereferencing with SPARQL micro-services are likely irrelevant for a Linked Data representation. The Flickr is straightforward. It only requires two things: API documentation describes how to reconstruct photos and user (i) Decide on the domain name and URIs scheme. Following up on pages URLs from these fields, but this involves the concatenation of the example in section 3, we define the URI scheme of Flickr photo values from distinct fields, that JSON-LD is typically not expressive resources as “http://example.org/ld/flickr/photo/”. enough to describe. Therefore, in a second step, S µ executes the (ii) Set up a Web server to deal with this URI scheme. When the INSERT query shown in Listing 2 to augment G with triples based Web server receives a look-up for a URI that matches the scheme, on well-adopted or domain-specific vocabularies (Schema.org, foaf it dynamically builds a query string to invoke the relevant SPARQL and Dublin Core in our example). micro-service. Technically, the Web server acts as a reverse proxy: 10 https://github.com/frmichel/sparql-micro-service Linked Data on the Web, April 2018, Lyon, France Franck Michel, Catherine Faron-Zucker, and Fabien Gandon prefix api : < http :// sms . i3s . unice . fr / schema /> the JSON-LD profile and the optional INSERT and CONSTRUCT prefix foaf : < http :// xmlns . com / foaf /0.1/ > prefix schema : < http :// schema . org /> queries that carry out the mappings toward domain vocabularies. prefix dce : < http :// purl . org / dc / elements /1.1/ > Our prototype consists of only 350 lines of code, in addition INSERT { to the RDF and JSON-LD libraries that it relies on. If a Web API ? photoUri a schema : Photograph ; requires specific actions that cannot be described using the config.ini foaf : depiction ? img ; schema : author ? authorUrl ; dce : creator ? authorName ; configuration file (e.g. intermediate query, authentication process), dce : title ? title . } WHERE { the developer can customize a provided script, allowing for more ? photo api : id ? id ; api : secret ? secret ; flexibility. The interested reader can look at an example in service api : server ? server ; api : farm ? farm ; api : title ? title ; macaulaylibrary/getAudioByTaxon. api : owner ? owner ; api : ownername ? authorName . Docker Deployment. In addition to the code available on Github, IRI (concat BIND (IRI concat (" http :// example . org / ld / flickr / photo /" , ? id )) we have created two Docker images published on Docker hub11 : one AS ? photoUri ) image runs the Corese-KGRAM RDF store and SPARQL endpoint, IRI (concat BIND (IRI concat (" https :// flickr . com / photos /" , ? owner )) AS ? authorUrl ) while the other provides an Apache Web server with the SPARQL IRI (concat BIND (IRI concat (" https :// farm ", ? farm , ". staticflickr . com /" , ? server , "/" , ?id , "_", ? secret , " _z . jpg ")) AS ? img ) micro-services described in section 6. They can be deployed by } running a single command, as instructed in the Github README. Note that, for the sake of simplicity, we have defined a single image Listing 2: Insertion of RDF triples based on well-adopted vo- hosting several micro-services. Nevertheless, more in line with cabularies (Schema.org, FOAF, Dublin Core). common micro-service practices, it would make sense to define one image per service, enabling the independent deployment of each service. Finally, S µ evaluates the client’s SPARQL query against G and returns the response that, in the example, consists of a solution 6 EXPERIMENTATION binding presented below in the SPARQL Results JSON format: To evaluate the effectiveness and efficiency of our approach, we head ": { " vars ": [ " img " ] }, "results { "head results ": { bindings ": [ "bindings carried out a series of tests related to the use case that initially mo- { " img ": { tivated this work, in the context of biodiversity. In a joint initiative type ": " uri ", "type with the French National Museum of Natural History, we have pro- value ": " https :// farm5 . staticflickr . com /4542/ \ "value 38427227466 _100fa110d0_z . jpg " } duced a dataset called TAXREF-LD, a Linked Data representation } ] } } of the French taxonomic register of living beings [19]. TAXREF-LD URIs dereferencing. In the URIs dereferencing solution por- models over 236.000 taxa as OWL classes while the scientific names trayed in section 4, the Web server’s URL rewriting engine appends used to refer to taxa are modeled as SKOS concepts. It is accessible a SPARQL query to the SPARQL micro-service invocation. In our through a public SPARQL endpoint12 , and all taxa and scientific example, this query is simply “DESCRIBE ”. Nevertheless, names URIs are dereferenceable. some use cases may require more complex CONSTRUCT queries To dynamically enrich the description of a taxon in TAXREF-LD to produce richer triples. Since the query must be URL-encoded, with data from various Web APIs, we developed three SPARQL this method may become cumbersome and difficult to maintain. micro-services based on the prototype presented in section 5 (the To avoid this issue, our implementation proposes a more flexible code is available along with the rest of the project code on Github): and maintainable alternative: each micro-service may provide a (1) flickr/getPhotosByGroupByTag, already described in section CONSTRUCT query that shall be used to produce the answer to 3, is used to search the Encyclopedia of Life Flickr group13 for the URI dereferencing query. photos of a given taxon. Photos of this group are tagged with Deploying a new SPARQL micro-service. Within this proto- the scientific name of the taxon they represent, formatted as type, deploying a new SPARQL micro-service simply consists of “taxonomy:binomial=”. provisioning four files among which two are optional: (2) macaulaylibrary/getAudioByTaxon retrieves audio record- ings for a given taxon name from the Macaulay Library14 , a • config.ini: a configuration file that declares the arguments scientific media archive related to birds, amphibians, fishes expected by the micro-service and the Web API invocation and mammals. query string. (3) musicbrainz/getSongByName searches the MusicBrainz mu- • profile.jsonld: the JSON-LD profile used to interpret the Web sic information encyclopedia15 for music tunes whose title API response as an RDF graph; match a given name with a minimum confidence of 90%. • insert.sparql (optional): used to augment the graph with ad- ditional triples; • construct.sparql (optional): used to produce the response to 6.1 Test Setting URI dereferencing queries. We wrote several test queries that invoke TAXREF-LD’s SPARQL endpoint along with one, two or three of the SPARQL micro-services In our experience, deploying a new SPARQL micro-service within 11 https://hub.docker.com/u/frmichel/ our prototype is a matter of one or two hours in simple cases. The 12 http://taxref.mnhn.fr/sparql most time-consuming task lies in reading the Web API documenta- 13 https://www.flickr.com/groups/806927@N20 tion. Thenceforth, a developer defines the API query string and the 14 https://www.macaulaylibrary.org/ arguments passed to the SPARQL micro-service. Lastly, she writes 15 https://musicbrainz.org/ SPARQL Micro-Services Linked Data on the Web, April 2018, Lyon, France prefix rdfs : < http :// www . w3 . org /2000/01/ rdf - schema #> contrast, only queries with static service URLs as in Listing 4 could prefix owl : < http :// www . w3 . org /2002/07/ owl #> prefix schema : < http :// schema . org /> be executed on Virtuoso. Indeed, Virtuoso cannot evaluate a SER- VICE clause wherein the service endpoint is given by a variable. SELECT ? species ? audioUrl WHERE { Note that this feature is not in the normative part of the SPARQL SERVICE < https :// erebe - vm2 . i3s . unice . fr :8890/ sparql > { 1.1 Federated Query recommendation [24], although it is part of ? genus a owl : Class ; rdfs : label " Delphinus ". ?s rdfs : subClassOf ? genus ; rdfs : label ? species . the SPARQL 1.1 grammar. Hence, an implementation may choose } to address this feature or not, but the semantics is not formally SERVICE ? sms { [] schema : contentUrl ? audioUrl . } defined. # Construction of the SPARQL micro - service endpoint URL The tests were performed on a Scientific Linux 6.9 server running IRI (concat BIND (IRI concat ( on a virtual machine equipped with 16 CPU cores and 48 GB of " https :// erebe - vm2 . i3s . unice . fr / sparql - ms / macaulaylibrary / getAudioByTaxon ? name =" , encode_for_uri (? species ))) as ? sms ) RAM. The server hosts a copy of TAXREF-LD’s dataset (9.6 million } triples) on a Virtuoso OS Edition server 7.20. Its SPARQL endpoint Listing 3: Dynamic construction of a SPARQL micro-service is accessible at URL “https://erebe-vm2.i3s.unice.fr:8890/sparql”. endpoint URL: the first SERVICE clause retrieves the species The server also hosts the three SPARQL micro-services. They are (sub-classes) of genus Delphinus. For each species, the sec- accessed at URL “https://erebe-vm2.i3s.unice.fr/sparql-ms//”. trieve associated audio recordings. 6.2 Test Results prefix rdfs : < http :// www . w3 . org /2000/01/ rdf - schema #> Query Q, in Listing 4, consists of a CONSTRUCT query form. It prefix owl : < http :// www . w3 . org /2002/07/ owl #> retrieves from TAXREF-LD the URI of the common dolphin species prefix foaf : < http :// xmlns . com / foaf /0.1/ > prefix schema : < http :// schema . org /> (Delphinus delphis) that it enriches with 15 photos retrieved from Flickr, 28 audio recordings from the Macaulay Library, and 1 music CONSTRUCT { ? species # from TAXREF - LD tune from MusicBrainz. Figure 4 portrays a snippet of the response schema : subjectOf ? photo ; # from Flickr to this query in the Turtle syntax, along with photos, audio record- foaf : depiction ? img ; # from Flickr schema : contentUrl ? audioUrl ; # from the Macaulay Library ings pictures and a MusicBrainz Web page. schema : subjectOf ? page . } WHERE { # from MusicBrainz Table 1 reports the execution time of query Q, averaged over fifteen runs against the Corese-KGRAM SPARQL engine. Column SERVICE < https :// erebe - vm2 . i3s . unice . fr :8890/ sparql > { ? species a owl : Class ; rdfs : label " Delphinus delphis ". } “Triples in temp. graph” gives the number of triples generated (i) by applying the JSON-LD profile to the API response, and (ii) the OPTIONAL { SERVICE SILENT < https :// erebe - vm2 . i3s . unice . fr / sparql - ms / optional INSERT query (to spawn the triples that JSON-LD cannot flickr / getPhotosByGroupByTag ? group_id =806927 @N20 yield). Column “Triples in resp.” gives the number of triples that & tags = taxonomy : binomial = Delphinus + delphis > { ? photo foaf : depiction ? img . } match query Q’s graph pattern. Strikingly, the Web API query exe- } cution is accountable for over 95.6% of the execution time. The over- OPTIONAL { head imposed by the SPARQL micro-service consistently ranges SERVICE SILENT < https :// erebe - vm2 . i3s . unice . fr / sparql - ms / macaulaylibrary / getAudioByTaxon ? name = Delphinus + delphis > from 16ms to 30ms, accounting for 2% of the total time for Macauley { [] schema : contentUrl ? audioUrl . } library’s API to 4.35% for Flickr’s API. } The evaluation of query Q takes an average 2.93s ± 0.75. Let us OPTIONAL { underline that this time is tightly bound to the SPARQL engine’s SERVICE SILENT < https :// erebe - vm2 . i3s . unice . fr / sparql - ms / musicbrainz / getSongByName ? name = Delphinus + delphis > evaluation strategy. The Corese-KGRAM engine evaluates each { [] schema : sameAs ? page . } SERVICE clause sequentially, although they may be evaluated in } } parallel since there is no dependency between them. By contrast, the Virtuoso SPARQL engine seems to adopt a far worse strategy: Listing 4: SPARQL query Q enriches the Linked Data repre- not only it invokes the SERVICE clauses sequentially although they sentation of taxon Delphinus delphis using SPARQL micro- do not show any dependency, but more importantly it invokes each services to retrieve data from Flickr, the Macaulay Library SERVICE clause once for each solution retrieved from previously and MusicBrainz. evaluated SERVICE clauses. In our tests, it invoked the Flickr service 28 times, i.e. once for each solution of the Macauley library micro- service, thus entailing a very poor evaluation time. At this point, it mentioned above. Each SPARQL micro-service is invoked within a remains unclear whether this is the result of a specific evaluation dedicated SPARQL SERVICE clause. The micro-service endpoint strategy or a bug. URL is built either dynamically and bound to a SPARQL variable as The response to query Q (Figure 4) contains URIs generated on exemplified in Listing 3, or statically as exemplified in Listing 4. the fly using Flickr’s internal photo identifiers such as “http://erebe- We used two different SPARQL engines to evaluate the test vm2.i3s.unice.fr/ld/flickr/photo/31173090936”. When looking them queries: Corese-KGRAM [3] and Virtuoso OS Edition16 . The queries up, an additional SPARQL micro-service dereferences them to an in Listings 3 and 4 were properly executed on Corese-KGRAM. By RDF document describing the photo. Hence, we have come up with 16 Virtuoso OS Edition: http://vos.openlinksw.com/owiki/wiki/VOS/ a consistent set of SPARQL micro-services able to evaluate SPARQL Linked Data on the Web, April 2018, Lyon, France Franck Michel, Catherine Faron-Zucker, and Fabien Gandon Figure 4: Snippet of the response to query Q (Listing 4) along with snapshots of the images, audio recordings and Web page whose URLs are part of the response. Triples SPARQL Triples Web API Overhead Web API in temp. µ-service Overhead in resp. exec. time (percentage) graph exec. time Flickr 261 15 0.54 ± 0.40 0.56 ± 0.40 0.020 ± 0.002 4.35% ± 1.34 Macauley Lib. 989 28 1.52 ± 0.40 1.55 ± 0.40 0.030 ± 0.001 2.02% ± 0.40 MusicBrainz 42 1 0.62 ± 0.38 0.64 ± 0.38 0.016 ± 0.001 3.16% ± 1.29 Table 1: Query execution time (in seconds) against a Web API and a SPARQL micro-service that wraps this Web API. The last column is the overhead (in %) imposed by the SPARQL micro-service compared to a direct Web API query. queries and/or dereference URIs, built upon a Web API that has no Flickr’s Web API services. Twarql [16] wraps Twitter’s Web API to SPARQL interface nor resource URIs in the first place. enable filtering and analysis of streaming tweets. It encodes tweets content in RDF using common vocabularies and enables SPARQL 7 RELATED WORKS querying. Yet, this approach is very specific to the Twitter and Abundant literature has been concerned with the integration of micropost content in general. disparate data sources since the early 1990’s [29]. Classically, wrap- With a similar rationale, Hydra [14] is a vocabulary aimed to pers implement the mediation from the models of multiple data describe Web APIs in a machine-readable format. It puts a specific sources towards a target vocabulary or ontology. A query federa- focuses on the generation of hypermedia controls so as to enable the tion engine handles a user query, determining which data sources generation of truly RESTful interfaces. Hydra, used in conjunction might have relevant information for the query, deciding on a query with JSON-LD, forms a basis to build hypermedia-driven Linked plan and recombining the partial results obtained from the multiple Data interfaces [13]. This basis can be harnessed to turn existing sources. Our work is concerned with the wrapping of Web APIs Web APIs into RESTful Linked Data interfaces whose documenta- into SPARQL endpoints, but the federation of such wrapped data tion can be interpreted at run time by a generic Hydra client. Our sources is out of the scope of this paper. Yet, existing federated incentive with SPARQL micro-services is to provide client appli- query technologies could be adapted to rewrite parts of a client’s cations with the whole expressiveness of SPARQL, which would SPARQL query into SERVICE clauses, thereby querying relevant be more difficult to achieve using a Hydra-described REST inter- SPARQL micro-services as illustrated in Listing 4. face. This however remains an interesting lead. For instance, the In the Semantic Web community, works aiming to translate Triple Pattern Fragment specification [28] leverages Hydra to de- heterogeneous data sources into RDF triples started very early17 . scribe hypermedia controls by means of IRI templates containing In [7] for instance, a triple store contains semantic descriptions that triple patterns. In the last section, we suggest the definition of a are used to semantically annotate Web services, explaining how Graph Pattern Fragment micro-service that would comply with the to invoke them and what kind of information can be obtained by Triple Pattern Fragment hypermedia controls but that would accept invoking them. regular graph patterns instead of only triple patterns. Approaches specifically concerned with Web APIs are often ad SPARQL-Generate [15] extends SPARQL 1.1 to enable querying hoc solutions. For instance, Flickcurl18 is a hardwired wrapper for RDF graphs along with non-RDF documents. A SPARQL-Generate 17 See the list hosted on W3C’s Web site: https://www.w3.org/wiki/ConverterToRdf query relies on several extension functions to fetch and parse doc- 18 http://librdf.org/flickcurl/ uments in different data formats, and defines the shape of RDF SPARQL Micro-Services Linked Data on the Web, April 2018, Lyon, France triples to be produced thenceforward. As such, it could be used SPARQL micro-services as simple as writing a SPARQL query and to query a Web API in a way similar to that of a SPARQL micro- a configuration file. service. Two main differences can be observed though. (i) SPARQL- Generate is an extension of SPARQL, hence, by definition, it is not 8 CONCLUSION AND PERSPECTIVES supported by engines strictly complying with the SPARQL stan- dard. By contrast, our vision is that multiple service providers could SPARQL Micro-Services are a lightweight type of Linked Data publish independent SPARQL micro-services, thereby building up Fragment interface that enable combining Linked Data with data an ecosystem of services all complying with standard SPARQL. (ii) from non-RDF Web APIs. SPARQL querying and URI dereferencing SPARQL-Generate offers the advantage that querying remote data are supported against a virtual graph delineated by the Web API sources is performed within a single language. On the one hand, service being wrapped, the arguments of this service and the types this only requires skills with Semantic Web technologies. On the of RDF triples that this SPARQL micro-service can spawn. other hand, this entails that a significant part of the whole process Complying with the micro-service architecture principles, a is left to the SPARQL client: querying the data source providing SPARQL micro-service should typically be loosely coupled, fine- appropriate arguments, and translating its proprietary vocabulary grained (it provides access to a small graph centered on a specific into RDF triples aligned on common vocabularies. Consequently, resource such as a photograph, a tweet or the temperature of a as illustrated by authors’ examples, the additional syntactic sugar room) and deployed independently of other services using e.g. light required can make queries considerably cumbersome and difficult container technologies. Eventually, an ecosystem of SPARQL micro- to maintain. We take a different option where this complexity is services could emerge from independent service providers, allow- hidden from the client and handled by the SPARQL micro-service ing Linked Data-based applications to glean pieces of data from a developer. wealth of distributed, scalable and reliable services. An approach very similar to SPARQL-Generate is proposed For such an ecosystem to arise however, two crucial issues shall in [11]. It is based on the BIND_API clause, an extension of the be tackled. Firstly, to enable services discovery, SPARQL micro- SPARQL BIND clause, that binds a set of variables with values services should provide self-describing metadata such as the ex- extracted from a Web API response. It suffers the same pitfalls as pected query string parameters, or the types of triples generated. SPARQL-Generate with respect to our goals: the use of non standard Secondly, although we envision SPARQL micro-services as a way SPARQL and the cumbersome syntactic sugar left to the SPARQL to access small fragments, it should be possible to retrieve such client. fragments by smaller pieces using a paging mechanism. ODMTP [21], On-Demand Mapping using Triple Patterns, is an To tackle those issues, Verborgh et al. advocated that Linked attempt to query non-RDF datasets as Triple Pattern Fragments. Data Fragments should provide self-describing, uniform interfaces The authors have implemented a prototype to query Twitter’s Web consisting of triples, metadata and hypermedia controls. Hyperme- API, that can process triple pattern queries over the whole Twit- dia controls contain the information needed to interact further on ter’s dataset. Conversely, SPARQL micro-services support arbitrary with a resource. In particular, they allow a client to navigate from SPARQL queries over restricted fragments of the Web API dataset. one fragment (or a page thereof) to another one [28]. Triple Pattern Besides, unlike SPARQL micro-services, ODMTP cannot assign Fragments implement this strategy through the generation of meta- dereferenceable URIs to Web API resources. Nevertheless, ODMTP data and control information as RDF triples returned alongside the offers the TPF’s paging mechanism that SPARQL micro-services triples matching the triple pattern. This solution is effective but it should regard as a valuable extension within future works (see the imposes a restriction: the TPF interface can only return triples (or discussion in section 8). quads more generally). By contrast, SPARQL micro-services fully Our implementation of SPARQL micro-services maps a Web API comply with SPARQL, in which the CONSTRUCT and DESCRIBE response to RDF triples in two steps: the response is first trans- query forms return triples whereas the ASK and SELECT query lated to JSON-LD, then a SPARQL INSERT or CONSTRUCT query forms return solutions formatted as variable bindings. The derefer- complements the process for cases where JSON-LD is not expres- enceable URIs dynamically assigned to Web API resources can be sive enough. Alternatively, we could rely on a mapping description thought of as hypermedia controls. But how to provide additional language such as RML [4] and xR2RML [17], but they require the metadata or control information within responses to SELECT or developer to learn the mapping language. By contrast, in our propo- ASK query forms? We can think of two solutions to solve this issue. sition we strove to rely only on existing standards. Firstly, extend the format of SPARQL query results with additional Let us finally mention the Apache Marmotta project19 , a compre- specific bindings. A second alternative could be to restrict SPARQL hensive Linked Data application framework that implements the micro-services to support only CONSTRUCT and DESCRIBE query Linked Data Platform W3C recommendation [26]. Among others, forms. This would spawn some sort of Graph Pattern Fragment it provides client modules that wrap the Web APIs of several Web interface, i.e. a generalized TPF interface that accepts regular graph portals such as Vimeo, Youtube and Facebook. Hence, it should be patterns instead of only triple patterns, but still complies with the relatively easy to implement SPARQL micro-services on top of Mar- TPF metadata and hypermedia controls specification. motta. However, the examples show that the Web API wrapping Let us finally mention that, in this article, we have focused specif- and the mapping towards RDF triples are mostly hard-coded within ically on consuming Web APIs data with SPARQL. In a broader the client libraries. Our point is to make the deployment of new picture, the micro-service principles could be applied to other types of APIs, so as to enable Semantic Web applications to reach out 19 http://marmotta.apache.org/ to other data sources. Furthermore, many APIs provide read-write Linked Data on the Web, April 2018, Lyon, France Franck Michel, Catherine Faron-Zucker, and Fabien Gandon access, empowering users to interact with contents, other users, [22] Marie-Laure Mugnier, Marie-Christine Rousset, and Federico Ulliana. 2016. etc. Hence, an interesting perspective would be to think of SPARQL Ontology-Mediated Queries for NOSQL Databases. In Proceedings of the 30th Conference on Artificial Intelligence (AAAI). micro-services as a way to support distributed SPARQL Update [23] Sam Newman. 2015. Building Microservices. O’Reilly Media. over Web APIs, thus eventually contributing to build an actual [24] Eric Prud’hommeaux and Carlos Buil-Aranda. 2013. SPARQL 1.1 Feder- ated Query. W3C Recommendation (2013). https://www.w3.org/TR/2013/ read-write Web of Data. REC-sparql11-federated-query-20130321/ [25] Dimitrios-Emmanuel Spanos, Periklis Stavrou, and Nikolas Mitrou. 2012. Bringing Relational Databases into the Semantic Web: A Survey. Semantic Web Journal 3, REFERENCES 2 (2012), 169–209. [1] David Beckett, Tim Berners-Lee, Eric Prud’hommeaux, and Gavin Carothers. [26] Steve Speicher, John Arwe, and Ashok Malhotra. 2015. Linked Data Platform 1.0. 2014. RDF 1.1 Turtle: Terse RDF Triple Language. W3C Recommendation (2014). W3C Recommendation (2015). https://www.w3.org/TR/2015/REC-ldp-20150226/ https://www.w3.org/TR/2014/REC-turtle-20140225/ [27] Manu Sporny, Dave Longly, Gregg Kellog, Markus Lanthaler, and Niklas Lind- [2] Carlos Buil-Aranda, Aidan Hogan, Jürgen Umbrich, and Pierre-Yves Vanden- ström. 2014. JSON-LD 1.0. A JSON-based Serialization for Linked Data. W3C bussche. 2013. SPARQL Web-Querying Infrastructure: Ready for Action?. In Recommendation (2014). https://www.w3.org/TR/2014/REC-json-ld-20140116/ Proceedings of the 12th International Semantic Web Conference. Springer, 277–293. [28] Ruben Verborgh, Miel Vander Sande, Olaf Hartig, Joachim Van Herwegen, Lau- [3] Olivier Corby and Catherine Faron Faron-Zucker. 2010. The KGRAM Abstract rens De Vocht, Ben De Meester, Gerald Haesendonck, and Pieter Colpaert. 2016. Machine for Knowledge Graph Querying. In Proceedings of the International Triple Pattern Fragments: a Low-cost Knowledge Graph Interface for the Web. Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT). IEEE, Web Semantics: Science, Services and Agents on the World Wide Web 37–38 (2016), 338–341. 184–206. [4] Anastasia Dimou, Miel Vander Sande, Jason Slepicka, Pedro Szekely, Erik Man- [29] Gio Wiederhold. 1992. Mediators in the Architecture of Future Information nens, Craig Knoblock, and Rik Van de Walle. 2014. Mapping Hierarchical Sources Systems. IEEE Computer 25, 3 (March 1992), 38–49. into RDF Using the RML Mapping Language. In Proceedings of the International [30] Olaf Zimmermann. 2016. Microservices Tenets: Agile Approach to Service De- Conference on Semantic Computing (ICSC). IEEE, 151–158. velopment and Deployment. Computer Science-Research and Development 32, 3 [5] Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara, (2016), 301–310. Fabrizio Montesi, Ruslan Mustafin, and Larisa Safina. 2017. Microservices: yester- day, today, and tomorrow. In Present and Ulterior Software Engineering. Springer, 195–216. [6] Lee Feigenbaum, Gregory Todd Williams, Kendall Grant Clark, and Elias Torres. 2013. SPARQL 1.1 Protocol. W3C Recommendation (2013). http://www.w3.org/ TR/2013/REC-sparql11-protocol-20130321/ [7] Fabien L. Gandon and Norman M. Sadeh. 2004. Semantic Web Technologies to Reconcile Privacy and Context Awareness. Journal of Web Semantics 1, 3 (2004), 241–260. [8] Steve Harris and Andy Seaborne. 2013. SPARQL 1.1 Query Language. W3C Recom- mendation (2013). http://www.w3.org/TR/2013/REC-sparql11-query-20130321/ [9] Tom Heath and Christian Bizer. 2011. Linked Data: Evolving the Web into a Global Data Space (1st ed.). Morgan & Claypool. [10] Bernadette Hyland, Ghislain Atemezing, and Boris Villazón-Terrazas. 2014. Best Practices for Publishing Linked Data. W3C Working Group Note (2014). https: //www.w3.org/TR/2014/NOTE-ld-bp-20140109/ [11] Matías Jünemann, Juan L. Reutter, Adrián Soto, and Domagoj Vrgoc. 2016. In- corporating API Data into SPARQL Query Answers. In Proceedings of the 15th International Semantic Web Conference (Posters and Demos). [12] Johannes Koch, Carlos A Velasco, and Philip Ackermann. 2017. HTTP Vocabu- lary in RDF 1.0. W3C Recommendation (2017). https://www.w3.org/TR/2017/ NOTE-HTTP-in-RDF10-20170202/ [13] Markus Lanthaler. 2013. Creating 3rd Generation Web APIs with Hydra. In WWW’13 Companion Proceedings of the 22nd International Conference on World Wide Web. ACM, 35–38. https://doi.org/10.1145/2487788.2487799 [14] Markus Lanthaler and Christian Gütl. 2013. Hydra: A Vocabulary for Hypermedia- Driven Web APIs. In Proceedings of the 6th Workshop on Linked Data on the Web (LDOW2013). CEUR-WS. [15] Maxime Lefrançois, Antoine Zimmermann, and Noorani Bakerally. 2017. A SPARQL extension for generating RDF from heterogeneous formats. In Proceed- ings of the 14th Extended Semantic Web Conference (ESWC). Springer, 35–50. [16] Pablo N. Mendes, Alexandre Passant, and Pavan Kapanipathi. 2010. Twarql: Tapping into the Wisdom of the Crowd. In Proceedings of the 6th International Conference on Semantic Systems. ACM. [17] Franck Michel, Loïc Djimenou, Catherine Faron-Zucker, and Johan Montagnat. 2015. Translation of Relational and Non-Relational Databases into RDF with xR2RML. In Proceeding of the 11th international conference on Web Information Systems and Technologies (WebIST). 443–454. [18] Franck Michel, Catherine Faron-Zucker, and Johan Montagnat. 2016. A Generic Mapping-Based Query Translation from SPARQL to Various Target Database Query Languages. In Proceeding of the 12th International Conference on Web Information Systems and Technologies (WebIST), Vol. 2. 147–158. [19] Franck Michel, Olivier Gargominy, Sandrine Tercerie, and Catherine Faron- Zucker. 2017. A Model to Represent Nomenclatural and Taxonomic Information as Linked Data. Application to the French Taxonomic Register, TAXREF. In Pro- ceedings of the 2nd International Workshop on Semantics for Biodiversity (S4BioDiv) co-located with ISWC 2017, Vol. 1933. CEUR. [20] Franck Michel, Johan Montagnat, and Catherine Faron-Zucker. 2014. A survey of RDB to RDF translation approaches and tools. Research report ISRN I3S/RR 2013-04-FR (2014). http://hal.archives-ouvertes.fr/hal-00903568 [21] Benjamin Moreau, Patricia Serrano-Alvarado, Emmanuel Desmontils, and David Thoumas. 2017. Querying non-RDF Datasets using Triple Patterns. In Proceedings of the 16th International Semantic Web Conference (Posters and Demos).