Web APIs are a prominent source of machine-readable information. We hypothesize that harnessing the Semantic Web standards to enable automatic combination of Linked Data and non-RDF Web APIs data could trigger novel cross-fertilization scenarios. To achieve this goal, we define the SPARQL Micro-Service architecture. A SPARQL micro-service is a lightweight, task-specific SPARQL endpoint that provides access to a small, resource-centric, virtual graph, while dynamically assigning dereferenceable URIs to Web API resources that do not have URIs beforehand. The graph is delineated by the Web API service being wrapped, the arguments passed to this service, and the restricted types of RDF triples that this SPARQL micro-service is designed to spawn. In this context, we argue that full SPARQL expressiveness can be supported eficiently without jeopardizing servers availability. Eventually, we believe that an ecosystem of SPARQL micro-services could emerge from independent service providers, enabling Linked Data-based applications to glean pieces of data from a wealth of distributed, scalable and reliable services. We describe an experimentation where we dynamically augment biodiversity-related Linked Data with data from Flickr, MusicBrainz and the Macauley scientific media library.
Web APIs are a common means for Web portals and data producers
to enable HTTP-based, machine-processable access to their data.
They are a prominent source of information1 pertaining to topics
as diverse as entertainment, finance, social networks, government
or scientific information. Many of them follow a REST or
“RESTlike” architecture2 ensuring a relatively uniform access to resource
descriptions. In a similar perspective, Linked Data [
Verborgh et al. defined a framework to analyze and compare
diferent Linked Data query interfaces [
In this paper, we address the specific goal of combining Web APIs
data and Linked Data. We propose an additional type of Linked
Data Fragment interface called SPARQL Micro-Services, by
analogy with the popular micro-services architecture that structures
an application as a collection of lightweight, loosely-coupled
services designed for a specific task [
The rest of this article is organized as follows. Section 2 first reminds the micro-service architectural principles and sketches how these could apply to the development of Linked Data-based applications. Then, sections 3 and 4 define in more details the SPARQL micro-service architecture. In sections 5 and 6 we present 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. 2
The term micro-service refers to an architectural style, also called
ifne-grained SOA , where an application consists of a collection of
services that are loosely coupled, fine-grained (designed to fulfill
a single function) and independently deployable [
Micro-services have been increasingly adopted during the last six
to seven years, not only by major Web companies who inspired this
architecture, but also by many other companies that need to speed
up the development and deployment of their services. Like any
architecture style, the experience shows that micro-services have
pitfalls of their own6. In particular, figuring out the appropriate size
of a micro-service (its functional scope) is critical in many aspects.
Nevertheless, leveraging these principles may help in the design of
distributed, modular Linked Data-based applications structured as
a collection of lightweight, loosely-coupled services. These services
would typically be RDF stores, URI dereferencing services, SPARQL
endpoints, Linked Data Platform [
The SPARQL micro-service architecture is a proposition towards this goal. We think of SPARQL micro-services as independent software units being developed along with the arising of needs. A microservice development team focuses on one Web API at a time, defines how to wrap a few services, tests and publishes them. Instead of being constrained to use specific technologies within a monolithic application, the team picks the programming language(s), Semantic Web stack and other third-party technologies that it deems most appropriate for a specific service.
A SPARQL micro-service Sµ is a wrapper of a service Sw of a Web
API. It behaves as a regular SPARQL endpoint insofar as it
supports the SPARQL Query Language [
Additionally, Sµ accepts a possibly empty set Arдw of arguments that are specific to the service being wrapped. They are passed to Sµ as parameters on the HTTP query string; in turn, Sµ passes them on to Sw . Accordingly, while the URL of a regular SPARQL endpoint is typically of the form “http://hostname/sparql”, a SPARQL micro-service is invoked with additional parameters, like “http://hostname/sparql?param1=value1¶m2=value2”.
The semantics of a SPARQL micro-service difers 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 identify nor interprets URL parameters in any way. By contrast, a SPARQL micro-service is a configurable SPARQL endpoint whose set Arдw of arguments delineates the scope of the virtual graph that is being queried. Thence, each pair (Sµ , Arдw ) is a standard SPARQL endpoint. As we see it, the graph accessed through (Sµ , Arдw ) is typically resourcecentric and corresponds to a small fragment of the dataset served by the Web API.
Figure 2 illustrates the SPARQL micro-service architecture in the case of the implementation we describe further on in section 5. Sµ evaluates a SPARQL query against an RDF graph that it builds at run-time following Algorithm 1 (the algorithm’s steps are depicted on Figure 2). Note that how the transformation at step (3) is carried out is implementation-dependent. In the case of JSON-based Web APIs, our implementation first applies a JSON-LD profile to the Web API response and optionally executes a SPARQL INSERT query to yield additional triples. However, various other methods may be used at this point, involving e.g. diferent flavors of mapping, reasoning or rule processing.
Algorithm 1 Evaluation of a SPARQL query by a SPARQL microservice Sµ .
(1) Sµ receives a SPARQL query Q along with arguments Arдw . (2) Sµ invokes the Web API service Sw with the arguments in Arдw . The response is a fragment Fw of the dataset served by the Web API. (3) Sµ translates Fw into a Linked Data Fragment FLD and loads it into a triple store as a temporary graph G.
(4) Sµ evaluates Q against G and returns the result to the client. 3.2
Querying Web APIs is often a time-consuming task, as suggested by the measures we report in section 6. Thus, when possible, defining caching strategies may be necessary to achieve the performance expected by some applications. There typically exist many syntactical variants of the same SPARQL query. Such that classic HTTP proxy servers set up between SPARQL clients and servers fail to reach eficient cache reuse. By contrast, Web API queries allow a lesser syntactical variability. Therefore, in the context of SPARQL micro-services, enforcing a cache strategy on the Web API side should ensure better cache reuse. Typically, Web API queries could be used to index either the Web API responses or the temporary graphs produced from them.
Furthermore, some Web APIs provide data expiration information (such as the Expires, Cache-Control and/or Last-Modified HTTP headers) on which a caching system can rely to figure out a caching strategy. When no such information is provided, a SPARQL microservice may authoritatively decide on an appropriate expiration period depending on the type of service being wrapped. 3.3
A typical client’s SPARQL query may invoke several SPARQL microservices simultaneously using multiple SERVICE clauses. The failure of a non-critical micro-service (due e.g. to a network error or a Web API error) should not hinder processing the other ones and returning partial results. Hence, a client may use the SILENT keyword to ignore errors from a SPARQL micro-service, and possibly embed SERVICES clauses within OPTIONAL clauses to allow for the production of partial results (this is exemplified later on in Listing 4). { "photos ": { "page ": 1, "pages ": "22689" , "photo ": [ { "id ": "38427227466" , "title ": " Brooklyn Bridge sunset ", "owner ": "33634811 @N07 ", "ownername ": " Franck Michel ", "secret ": "100 fa110d0 ", "server ": "4542" , "farm ": 5 } } }
(top), and equivalent RDF triples in the Turtle syntax [
We now illustrate Algorithm 1 with an example based on Flickr’s
Web API8. Let Sw be the Flickr service that retrieves photos posted
in a specific group and having a specific tag 9. Arдw (the arguments
of Sw ) comprises two arguments, group_id and tags. A SPARQL
micro-service Sµ wraps Sw . In step 1, a client willing to retrieve the
URLs of photos matching some specific group and tags executes a
SPARQL query “SELECT ?img WHERE {?photo foaf:depiction ?img.}”
against Sµ . Using the SPARQL HTTP GET method [
\%20 foaf \%3 Adepiction \%20\%3 Fimg .\%7 D Interestingly enough, this is precisely the invocation that would be performed by the SERVICE clause in the following SPARQL query: SELECT ?img WHERE {
SERVICE <http :// hostname / flickr / getPhotosByGroupByTag ? \ group_id =35034350743 @N01 & tags =bridge > { ? photo foaf : depiction ?img. } }
In step 2, Sµ invokes Sw with the arguments of Arдw in addition to other arguments possibly required by the Web API (for the sake of clarity we have left over some technical arguments). Listing 1 (top) sketches a snippet of the response to this query: https :// api. flickr .com/ services / rest /? method = flickr . groups . pools . getPhotos & format = json & group_id =35034350743 @N01 &tags = bridge
Step 3 is implementation dependent. The prototype
implementation presented in section 5 draws on the method proposed by the
JSON-LD specification [
Finally, in step 4, Sµ evaluates the client’s SPARQL query against G and returns the response in one of the media types supported by the SPARQL client (following a regular content negotiation).
In this proposition, a design decision is to pass the arguments of Arдw to Sµ as HTTP query string parameters. Arguably, other 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 argument, e.g.: prefix api: <http :// sms.i3s. unice .fr/ schema /> SELECT ?img WHERE {
SERVICE <http :// hostname / flickr / getPhotosByGroupByTag > { ? photo foaf : depiction ?img; api: group_id "806927 @N20 "; api: tags " bridge ". }
} 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 there is no more variable part in the service endpoint URL. Several concerns should be pointed out however. (i) This solution requires that each SPARQL micro-service be defined along with its own bespoke terms, whereas we seek a solution wherein only terms of well-adopted vocabularies would be exposed. (ii) In this example, the group_id and tags arguments are meaningful for the end user. But some services may require more technical arguments that we typically do not want to define as ontological terms. (iii) Furthermore, this solution questions the nature of the subject to which the arguments are associated. Again, in this specific example, declaring the group_id and tags as properties of the photographic resource ?photo is an acceptable choice, but this would be inappropriate with internal or technical service parameters.
This issue can be solved by associating the arguments to a
separate resource depicting the service itself. This is exemplified in the
second alternative that, furthermore, defines a vocabulary to pass
the arguments in a uniform manner. Note that existing vocabularies
may be tapped for that matter, such as Hydra [
SERVICE <http :// hostname / flickr / getPhotosByGroupByTag > { ? photo foaf : depiction ?img.
[] a api: Service ; api: param [ api: name " group_id "; api: value "806927 @N20 " ]; api: param [ api: name " tags "; api: value ?tag ]. } }
].
A slight variation could state that the service URL itself is an instance of api:Service; the arguments would then configure an execution of this service with predicate api:execution, e.g.: <http :// hostname / flickr / getPhotosByGroupByTag > a api: Service ; api: execution [ api: param [ api: name " group_id "; api: value "806927 @N20 " ]; api: param [ api: name " tags "; api: value ?tag ].
While these alternatives avoid defining new predicates for each micro-service, the additional triples bear a somewhat artificial semantics: they provide the service with information as to how to process the other parts of the graph pattern, but they do not actually refer to nor describe the photographic resources that the graph pattern aims to match.
In a third alternative, the service arguments are passed as SPARQL variables with pre-defined names, e.g. ?group_id and ?tags in the example below: SELECT ?img WHERE {
SERVICE <http :// hostname / flickr / getPhotosByGroupByTag > { ? photo foaf : depiction ?img. } }
BIND ("806927 @N20 " AS ? group_id )
BIND (" bridge " AS ? tags ) Similarly to the previous alternative, variables ?group_id and ?tags are artificial insofar as they provide the service with information as to how to process the other parts of the graph pattern.
The solution proposed in this article is a trade-of meant to satisfy certain goals. Above, we have discussed some alternative solutions, and others may probably be figured out. We believe that further discussions should be engaged to assess the benefits and concerns of these alternatives with respect to the contexts and goals. 4
Web APIs often provide resource descriptions that rely on internal, proprietary identifiers. For instance, Listing 1 mentions the photo identifier “38427227466” that has no meaning beyond the scope of Flickr’s Web API. One may argue that the URL of this photo’s Web page could serve as a URI, but this would just approve a questionable practice that confuses a resource (a photographic work in this case) with an HTML representation thereof.
Therefore, bridging Web APIs and Linked Data not only requires
to enable SPARQL querying of Web APIs, but also to dynamically
create URIs that identify Web API resources. Furthermore,
according to Linked Data best practices [
Implementing URI dereferencing with SPARQL micro-services is straightforward. It only requires two things: (i) Decide on the domain name and URIs scheme. Following up on the example in section 3, we define the URI scheme of Flickr photo resources as “http://example.org/ld/flickr/photo/<photo_id>”. (ii) Set up a Web server to deal with this URI scheme. When the Web server receives a look-up for a URI that matches the scheme, it dynamically builds a query string to invoke the relevant SPARQL micro-service. Technically, the Web server acts as a reverse proxy: it queries the SPARQL micro-service and transparently proxies the response back to the client. Figure 3 sketches this architecture.
Let us assume the getPhotoById SPARQL micro-service retrieves photos by their identifier. If the Web server receives a look-up for the URI “http://example.org/ld/flickr/photo/38427227466”, it invokes the getPhotoById micro-service with the following query string: http :// hostname / flickr / getPhotosById ? photo_id =38427227466& query = DESCRIBE \%20\%3 Chttp \%3A\%2F\%2 Fexample .org \%2 Fld \ \%2 Fflickr \%2 Fphoto \%2 F38427227466 \%3E The value of argument “query” is the URL-encoded string for: DESCRIBE <http://example.org/ld/flickr/photo/38427227466>. The response to this query will be proxied back to the client in one of the negotiated media types.
Hence, by smartly designing SPARQL micro-services, we can build a consistent ecosystem where some micro-services respond to SPARQL queries by translating Web API internal identifiers into URIs, and some micro-services (possibly the same) are able to dereference these URIs.
To evaluate the architecture proposed in section 3, we have developed a prototype implementation in the PHP language, available on Github10 under the Apache 2.0 license. This prototype complies with the choices pictured in Figure 2: it assumes that Web APIs are able to provide a JSON response, and thence requires each SPARQL micro-service to provide a JSON-LD profile as a first mapping step towards RDF.
SPARQL queries. The processing of SPARQL queries is
implemented as depicted in Figure 2. First, a JSON-LD profile is applied
to the Web API JSON response. Following up on the example
introduced in section 3, Sµ applies to the API response the JSON-LD
profile below, that turns each JSON field name into an ad hoc RDF
predicate within namespace “http://sms.i3s.unice.fr/schema/” (note
that any arbitrary complex profile may be used at this point):
{"@context ": {"@vocab ": " http :// sms.i3s. unice .fr/ schema /"}}.
The resulting graph G, depicted in Listing 1 (bottom), is stored in
the Corese-KGRAM in-memory triple store [
Finally, Sµ evaluates the client’s SPARQL query against G and returns the response that, in the example, consists of a solution binding presented below in the SPARQL Results JSON format: { "head ": { " vars ": [ " img " ] }, "results ": { "bindings ": [ { " img ": { "type ": " uri ", "value ": " https :// farm5 . staticflickr . com /4542/ \
38427227466 _100fa110d0_z . jpg " } } ] } }
URIs dereferencing. In the URIs dereferencing solution portrayed in section 4, the Web server’s URL rewriting engine appends a SPARQL query to the SPARQL micro-service invocation. In our example, this query is simply “DESCRIBE <uri>”. Nevertheless, some use cases may require more complex CONSTRUCT queries to produce richer triples. Since the query must be URL-encoded, this method may become cumbersome and dificult to maintain. To avoid this issue, our implementation proposes a more flexible and maintainable alternative: each micro-service may provide a CONSTRUCT query that shall be used to produce the answer to the URI dereferencing query.
Deploying a new SPARQL micro-service. Within this prototype, deploying a new SPARQL micro-service simply consists of provisioning four files among which two are optional: • config.ini : a configuration file that declares the arguments expected by the micro-service and the Web API invocation query string. • profile.jsonld : the JSON-LD profile used to interpret the Web
API response as an RDF graph; • insert.sparql (optional): used to augment the graph with additional triples; • construct.sparql (optional): used to produce the response to
URI dereferencing queries.
In our experience, deploying a new SPARQL micro-service within our prototype is a matter of one or two hours in simple cases. The most time-consuming task lies in reading the Web API documentation. Thenceforth, a developer defines the API query string and the arguments passed to the SPARQL micro-service. Lastly, she writes the JSON-LD profile and the optional INSERT and CONSTRUCT queries that carry out the mappings toward domain vocabularies.
Our prototype consists of only 350 lines of code, in addition to the RDF and JSON-LD libraries that it relies on. If a Web API requires specific actions that cannot be described using the config.ini configuration file ( e.g. intermediate query, authentication process), the developer can customize a provided script, allowing for more lfexibility. The interested reader can look at an example in service macaulaylibrary/getAudioByTaxon.
Docker Deployment. In addition to the code available on Github, we have created two Docker images published on Docker hub11: one image runs the Corese-KGRAM RDF store and SPARQL endpoint, while the other provides an Apache Web server with the SPARQL 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 hosting several micro-services. Nevertheless, more in line with common micro-service practices, it would make sense to define one image per service, enabling the independent deployment of each service.
To evaluate the efectiveness and eficiency of our approach, we
carried out a series of tests related to the use case that initially
motivated this work, in the context of biodiversity. In a joint initiative
with the French National Museum of Natural History, we have
produced a dataset called TAXREF-LD, a Linked Data representation
of the French taxonomic register of living beings [
To dynamically enrich the description of a taxon in TAXREF-LD with data from various Web APIs, we developed three SPARQL micro-services based on the prototype presented in section 5 (the code is available along with the rest of the project code on Github): (1) flickr/getPhotosByGroupByTag , already described in section 3, is used to search the Encyclopedia of Life Flickr group13 for photos of a given taxon. Photos of this group are tagged with the scientific name of the taxon they represent, formatted as “taxonomy:binomial=<scientific name >”. (2) macaulaylibrary/getAudioByTaxon retrieves audio recordings for a given taxon name from the Macaulay Library14, a scientific media archive related to birds, amphibians, fishes and mammals. (3) musicbrainz/getSongByName searches the MusicBrainz music information encyclopedia15 for music tunes whose title match a given name with a minimum confidence of 90%.
We wrote several test queries that invoke TAXREF-LD’s SPARQL endpoint along with one, two or three of the SPARQL micro-services 11https://hub.docker.com/u/frmichel/ 12http://taxref.mnhn.fr/sparql 13https://www.flickr.com/groups/806927@N20 14https://www.macaulaylibrary.org/ 15https://musicbrainz.org/ prefix rdfs : <http :// www.w3.org /2000/01/ rdf - schema #> prefix owl: <http :// www.w3.org /2002/07/ owl#> prefix schema : <http :// schema .org/> SELECT ? species ? audioUrl WHERE {
SERVICE <https :// erebe -vm2.i3s. unice .fr :8890/ sparql > { ? genus a owl: Class ; rdfs : label " Delphinus ".
?s rdfs : subClassOf ? genus ; rdfs : label ? species . Listing 3: Dynamic construction of a SPARQL micro-service endpoint URL: the first SERVICE clause retrieves the species (sub-classes) of genus Delphinus. For each species, the second SERVICE clause invokes a SPARQL micro-service to retrieve associated audio recordings. prefix rdfs : <http :// www.w3.org /2000/01/ rdf - schema #> prefix owl: <http :// www.w3.org /2002/07/ owl#> prefix foaf : <http :// xmlns .com/ foaf /0.1/ > prefix schema : <http :// schema .org/> CONSTRUCT { ? species # from TAXREF -LD schema : subjectOf ? photo ; # from Flickr foaf : depiction ?img; # from Flickr schema : contentUrl ? audioUrl ; # from the Macaulay Library schema : subjectOf ? page . # from MusicBrainz } WHERE {
SERVICE <https :// erebe -vm2.i3s. unice .fr :8890/ sparql >
{ ? species a owl: Class ; rdfs : label " Delphinus delphis ". } OPTIONAL {
SERVICE SILENT <https :// erebe -vm2.i3s. unice .fr/sparql -ms/ flickr / getPhotosByGroupByTag ? group_id =806927 @N20 & tags = taxonomy : binomial = Delphinus + delphis > { ? photo foaf : depiction ?img. } } } }
} OPTIONAL {
SERVICE SILENT <https :// erebe -vm2.i3s. unice .fr/sparql -ms/ macaulaylibrary / getAudioByTaxon ? name = Delphinus + delphis > { [] schema : contentUrl ? audioUrl . } OPTIONAL {
SERVICE SILENT <https :// erebe -vm2.i3s. unice .fr/sparql -ms/ musicbrainz / getSongByName ? name = Delphinus + delphis > { [] schema : sameAs ? page . }
mentioned above. Each SPARQL micro-service is invoked within a dedicated SPARQL SERVICE clause. The micro-service endpoint URL is built either dynamically and bound to a SPARQL variable as exemplified in Listing 3, or statically as exemplified in Listing 4.
We used two diferent SPARQL engines to evaluate the test
queries: Corese-KGRAM [
The tests were performed on a Scientific Linux 6.9 server running on a virtual machine equipped with 16 CPU cores and 48 GB of 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 is accessible at URL “https://erebe-vm2.i3s.unice.fr:8890/sparql”.
The server also hosts the three SPARQL micro-services. They are accessed at URL “https://erebe-vm2.i3s.unice.fr/sparql-ms/<Web API>/<service name>”.
Query Q, in Listing 4, consists of a CONSTRUCT query form. It retrieves from TAXREF-LD the URI of the common dolphin species (Delphinus delphis) that it enriches with 15 photos retrieved from Flickr, 28 audio recordings from the Macaulay Library, and 1 music tune from MusicBrainz. Figure 4 portrays a snippet of the response to this query in the Turtle syntax, along with photos, audio recordings pictures and a MusicBrainz Web page.
Table 1 reports the execution time of query Q, averaged over iffteen runs against the Corese-KGRAM SPARQL engine. Column “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 INSERT query (to spawn the triples that JSON-LD cannot yield). Column “Triples in resp.” gives the number of triples that match query Q’s graph pattern. Strikingly, the Web API query execution is accountable for over 95.6% of the execution time. The overhead imposed by the SPARQL micro-service consistently ranges from 16ms to 30ms, accounting for 2% of the total time for Macauley library’s API to 4.35% for Flickr’s API.
The evaluation of query Q takes an average 2.93s ± 0.75. Let us underline that this time is tightly bound to the SPARQL engine’s evaluation strategy. The Corese-KGRAM engine evaluates each 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: not only it invokes the SERVICE clauses sequentially although they do not show any dependency, but more importantly it invokes each SERVICE clause once for each solution retrieved from previously evaluated SERVICE clauses. In our tests, it invoked the Flickr service 28 times, i.e. once for each solution of the Macauley library microservice, thus entailing a very poor evaluation time. At this point, it remains unclear whether this is the result of a specific evaluation strategy or a bug.
The response to query Q (Figure 4) contains URIs generated on
the fly using Flickr’s internal photo identifiers such as
“http://erebevm2.i3s.unice.fr/ld/flickr/photo/31173090936”. When looking them
up, an additional SPARQL micro-service dereferences them to an
RDF document describing the photo. Hence, we have come up with
a consistent set of SPARQL micro-services able to evaluate SPARQL
Abundant literature has been concerned with the integration of
disparate data sources since the early 1990’s [
In the Semantic Web community, works aiming to translate
heterogeneous data sources into RDF triples started very early17.
In [
Approaches specifically concerned with Web APIs are often ad
hoc solutions. For instance, Flickcurl18 is a hardwired wrapper for
17See the list hosted on W3C’s Web site: https://www.w3.org/wiki/ConverterToRdf
18http://librdf.org/flickcurl/
Flickr’s Web API services. Twarql [
With a similar rationale, Hydra [
SPARQL-Generate [
An approach very similar to SPARQL-Generate is proposed
in [
ODMTP [
Our implementation of SPARQL micro-services maps a Web API
response to RDF triples in two steps: the response is first
translated to JSON-LD, then a SPARQL INSERT or CONSTRUCT query
complements the process for cases where JSON-LD is not
expressive enough. Alternatively, we could rely on a mapping description
language such as RML [
Let us finally mention the Apache Marmotta project 19, a
comprehensive Linked Data application framework that implements the
Linked Data Platform W3C recommendation [
SPARQL Micro-Services are a lightweight type of Linked Data Fragment interface that enable combining Linked Data with data from non-RDF Web APIs. SPARQL querying and URI dereferencing are supported against a virtual graph delineated by the Web API service being wrapped, the arguments of this service and the types of RDF triples that this SPARQL micro-service can spawn.
Complying with the micro-service architecture principles, a SPARQL micro-service should typically be loosely coupled, finegrained (it provides access to a small graph centered on a specific resource such as a photograph, a tweet or the temperature of a room) and deployed independently of other services using e.g. light container technologies. Eventually, an ecosystem of SPARQL microservices could emerge from independent service providers, allowing Linked Data-based applications to glean pieces of data from a wealth of distributed, scalable and reliable services.
For such an ecosystem to arise however, two crucial issues shall be tackled. Firstly, to enable services discovery, SPARQL microservices should provide self-describing metadata such as the expected query string parameters, or the types of triples generated. Secondly, although we envision SPARQL micro-services as a way to access small fragments, it should be possible to retrieve such fragments by smaller pieces using a paging mechanism.
To tackle those issues, Verborgh et al. advocated that Linked
Data Fragments should provide self-describing, uniform interfaces
consisting of triples, metadata and hypermedia controls.
Hypermedia controls contain the information needed to interact further on
with a resource. In particular, they allow a client to navigate from
one fragment (or a page thereof) to another one [
Let us finally mention that, in this article, we have focused specifically on consuming Web APIs data with SPARQL. In a broader picture, the micro-service principles could be applied to other types of APIs, so as to enable Semantic Web applications to reach out to other data sources. Furthermore, many APIs provide read-write access, empowering users to interact with contents, other users, etc. 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.