=Paper=
{{Paper
|id=Vol-2073/article-01
|storemode=property
|title=None
|pdfUrl=https://ceur-ws.org/Vol-2073/article-01.pdf
|volume=Vol-2073
|dblpUrl=https://dblp.org/rec/conf/www/MichelFG18
}}
==None==
https://ceur-ws.org/Vol-2073/article-01.pdf
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).