Beyond Classical SERVICE Clause in Federated SPARQL Queries:

Leveraging the Full Potential of URI Parameters

Olivier Corby, Catherine Faron, Fabien Gandon, Damien Graux and Franck Michel

Universit

e C

ote d’Azur, Inria, CNRS, I3S, Sophia Antipolis, France

Keywords:

Semantic Web, URI Parameters, Federated Querying, SPARQL, SPARQL Federated Query Services,

Extended SPARQL-based Services.

Abstract:

Semantic Web applications integrating very different software and data sources have to face the heterogeneity

of the quality and compliance to standards exhibited by each involved resource. In this paper we propose

a uniform way of adapting and customizing the behavior of both the client and the server components of

an HTTP exchange to cope with this diversity. We revisit the classical SERVICE clause in SPARQL federated

queries in order to parameterize the behavior of both the SPARQL client and the SPARQL service. We propose

mechanisms to identify and specify SPARQL federated query services and extended SPARQL-based services.

1 INTRODUCTION

Thanks to the W3C standards, the Web beneﬁts

from an unprecedented interoperability that pro-

pelled it beyond an “Information management pro-

posal” (Berners-Lee, 1989) to a universal “appli-

cation integration platform” (Fielding et al., 2017)

and toward a platform linking all forms of intelli-

gence (Berendt et al., 2021).

To parameterize the calls made between the appli-

cations on the Web, the RFC 3986 (Berners-Lee et al.,

2005) deﬁnes the query component of a URI as indi-

cated by the ﬁrst question mark (“?” character) and

terminated by a number sign (“#” character) or by the

end of the URI. However, the exact structure of the

query string is not standardized at the URI level. Al-

though methods used to compose a query string may

differ between websites, the original usage in HTML

forms popularized the use of query strings composed

of a series of ﬁeld-value pairs where the ﬁeld name

and value are separated by an equals sign (“=”) and

the pairs are separated by the ampersand sign (“&”) as

in this example with two parameters gname and fname

respectively set to “doe” and “john”.

https :// examp . le/ search ? g n a m e = d o e & f n a m e = john

The query string of a URI is essentially perceived

as a way to pass parameters to the server and to the

logic invoked in producing a response. But the po-

sition we take in that paper is that, because they are

at the frontier between the client and the servers of a

Web application, URI parameters can be used to in-

ﬂuence the behavior of both these components. In-

stead of resolving to adhoc hacks, we propose a uni-

form way, based on the URI query string, to adapt and

customize the behavior of the client and the server

components of an HTTP exchange. By relying on

the standard URI parameters, the approach remains

backward compatible as it is transparent for clients or

servers that do not implement them and simply ignore

them. Moreover, in the context of federated systems,

for instance, the same software component may en-

dorse the role of a client or a server in different in-

teractions and this uniform way of parameterizing be-

haviours works seamlessly in that case too.

In particular, we propose to exploit the full poten-

tial of the query string of a URI in the context of Se-

mantic Web applications (Gandon, 2018) where the

communication between clients and servers is based

on SPARQL, standing for SPARQL Protocol and

RDF Query Language (Harris and Seaborne, 2013).

It provides a fully declarative language for query and

update operations (Allemang et al., 2020). Therefore,

unlike with imperative programming languages, it is

not possible to embed any instruction to tune the be-

havior of the SPARQL query processor that is evalu-

ating a SERVICE clause, or to control the query plan

that it will come up with. Yet, we may want to cus-

tomize its behavior based on what we know about the

remote service (quotas, supported features, etc.).

In this article, we report our return on experience

on using URI parameters to parameterize the behavior

Corby, O., Faron, C., Gandon, F., Graux, D. and Michel, F.

Beyond Classical SERVICE Clause in Federated SPARQL Quer ies: Leveraging the Full Potential of URI Parameters.

DOI: 10.5220/0010660300003058

In Proceedings of the 17th International Conference on Web Information Systems and Technologies (WEBIST 2021), pages 65-76

ISBN: 978-989-758-536-4; ISSN: 2184-3252

of both SPARQL clients and services. Our proposal

is motivated by the fact that, although the W3C stan-

dards provide an excellent common ground for inter-

operability, in practice applications integrating very

different software and data sources have to face the

heterogeneity of the quality and compliance to stan-

dards exhibited by each involved resource. One ap-

plication of great interest is to cope with heterogene-

ity in the context of federated querying. In particu-

lar, in real-world scenarios, a SPARQL query proces-

sor evaluating a federated query must be able, on one

side, to parameterize the remote SPARQL services’

behaviors (for which it is the client) according to their

capabilities and speciﬁcity, and, on the other side, to

adapt its own behavior to the limitations and charac-

teristics of these remote services.

Nowadays, many national or international projects

are facing such a situation, in particular any project

targeting scientiﬁc data integration will have to ad-

dress this heterogeneity, for example: the Ger-

man DFG project FAIR Data Infrastructure for

Condensed-Matter Physics and the Chemical Physics

of Solids (FAIRmat

) aiming to integrate and make

accessible and reusable the enormous amount of data

on materials (basic and applied science and engi-

neering) produced in recent years; the French ANR

project Data to Knowledge in Agronomy and Bio-

diversity (D2KAB

) aiming to create a framework

to turn agronomy and biodiversity data into an inte-

grated, interoperable and open knowledge graph; the

European ERIC project Analysis and Experimenta-

tion on Ecosystems (AnaEE

) aiming to integrate all

the steps of the scientiﬁc experimental methods, mod-

elling and experimentation in order to understand the

impact of change drivers on terrestrial and aquatic

continental ecosystems across Europe; etc. A com-

mon challenge in the development of such research

infrastructures (RI) is to provide a unique entry point

to the databases provided by the project partners;

these are most of the time hugely heterogeneous, not

only regarding the data they store and their schemas,

but also regarding the servers chosen to store and

serve them and the practices adopted by the research

teams in charge of conﬁguring them and managing

their creation and maintenance.

Thus, the main research question of this article is:

do URI parameters provide an effective way to im-

prove and extend SPARQL-based interaction between

Web clients and services? It entails two speciﬁc sub-

questions : can URI parameters allow SPARQL-based

interactions that could not be done before? and can

https://www.fair-di.eu/fairmat/proposal

http://www.d2kab.org/

https://www.anaee.eu/

URI parameters make existing SPARQL-based inter-

actions more efﬁcient in time, space, etc.?

To answer these questions, this article is orga-

nized as follows: Section 2 discusses related work

on the parameterization of client/server exchanges in

the context of SPARQL services. Section 3 presents

the general principle of our approach to customize the

behavior of SPARQL services and clients. The three

next sections start from what is already possible to do

in terms of parameterization with the standards, and

gradually build on it to provide controls over the be-

haviors of both the client and the server components

of a SPARQL exchange. Section 7 presents some ex-

periments that we conducted to validate and demon-

strate our approach. Section 8 draws some conclu-

sions and gives directions for future work.

2 RELATED WORK

Nowadays, there are many SPARQL endpoints and

most of them suffer from partial coverage of the

SPARQL query language together with a lack of

availability for a great majority of them, as reported

by (Buil-Aranda et al., 2013). In addition, one recur-

ring problem when dealing with SPARQL endpoints

is the limitation of the server’s resources allocated to

each individual query, often leading to timeouts, er-

rors if the queries were too complex, or even incom-

plete results. To circumvent these limitations some

efforts have been made to set up alternative solutions

to the “traditional” SPARQL endpoints such as the

SaGe initiative by Minier et al. which relies on Web

preemption (Minier et al., 2019). Others like C. Buil-

Aranda et al. (Buil-Aranda et al., 2014) propose to

split the query into pieces so as to respect the vari-

ous quotas of the distant SPARQL server. Another

approach tackles the challenge the other way around

by providing speciﬁc interfaces, named Linked Data

Fragments (Hartig et al., 2017) to access the datasets

which can then be chosen by users depending on their

needs. For example, in the Triple Pattern Fragments

approach (Verborgh et al., 2016), the server only eval-

uates triple patterns. However, these fragment ap-

proaches generate a large number of subqueries and

substantial data transfer.

Unfortunately, all these methods are applied after

reaching these limitations. We aim at preventing these

situations. We propose to consider that a wide set of

URI parameters –to tune the server’s behavior– could

prevent these issues by providing SPARQL practition-

ers with the useful tools. Moreover, we also intro-

duce URI parameters to be interpreted by the client

too; which is, to the best of our knowledge, unprece-

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

dented. In particular, we focus our effort (and validate

it) on the parameterization of federated querying us-

ing the SPARQL SERVICE clause

Technically, SPARQL 1.1 Graph Store HTTP Pro-

tocol

deﬁnes a mean for updating and fetching RDF

graph content from a Graph Store over HTTP in the

REST style. For example the following:

DELETE / rdf - gr a ph - store ? graph =< graph_u r i > H T T P / 1.1

Ho s t : examp .le

would be the equivalent of the following SPARQL

1.1. Update operation:

DR O P GR A P H <graph_ u r i >

As a consequence, some SPARQL engines such as

GraphDB

, Fuseki

or BrightStarDB

rely on this to

let the SPARQL practitioners slightly tune the queries

with additional parameters. Typically, practitioners

are e.g. able to select the return format of a query

using output=xml to obtain RDF/XML. In addi-

tion, GraphDB also provides some additional features

for internal federation

which unfortunately does not

comply with the SPARQL 1.1 standard anymore, at

the time of writing of this article, in June 2021. Other

solutions like RDF4J

(Broekstra et al., 2002), Vir-

tuoso

(Erling and Mikhailov, 2010), Anzo

or also

BlazeGraph

extend the set of possible parameters.

For example, RDF4J allows the practitioner to add

timeout or limit; with explain, BlazeGraph en-

ables a mode where the query results are extended

with explanations of the query plan. When com-

pared to these approaches, we notice that, while these

SPARQL endpoint implementations support param-

eters, they remain speciﬁc to the server side and in

particular the idea of using them in the context of

SPARQL SERVICE clauses is not widespread yet.

Alternatively to using the SERVICE keyword to

access additional endpoints, one may use federated

SPARQL services which provide a uniﬁed access in-

terface to a set of autonomous data sources. Their

main objective is to transform a query posed on a fed-

eration of data sources into a query composed of the

union of subqueries over individual data sources of

the federation. In particular, Saleem et al. studied

SPARQL 1.1 Federated Query

Graph Store HTTP Protocol

GraphDB compliance with the Graph Store HTTP Proto-

col

Jena Fuseki endpoint conﬁguration

BrightStarDB conﬁguration

GraphDB internal federation

RDF4J repository queries

Virtuoso documentation

Anzo endpoint conﬁguration

BlazeGraph rest API

federated RDF query engines with web access inter-

faces (Saleem et al., 2016). So far, most of the ef-

forts have been tackling challenges such as source se-

lection or query planning and few implemented tools

provide the practitioners with a way to conﬁgure the

behaviour of the data sources’ endpoints. For ex-

ample, FedX (Schwarte et al., 2011) only provides

setMaxExecutionTime to deﬁne the maximum time

for the whole query.

Finally, regarding the technique we present about

uniﬁying several endpoints under the same banner

(see Section 6.1), it is worth mentioning that Comu-

nica (Taelman et al., 2018) does also provide a similar

concept of querying several-at-once. However, Co-

munica requires practitioners to enter all the wanted

sources’ URLs

from the beginning when our imple-

mentation allows the description of a set of endpoints

through the use of a dedicated vocabulary. In addi-

tion, Comunica does not set up a process to conﬁgure

the endpoints’ behaviors as we propose.

3 GENERAL PRINCIPLE

We start with a reminder of the terms of the SPARQL

1.1 Protocol

that describes a means for SPARQL

protocol clients to submit SPARQL protocol oper-

ations (either query or update operations) to a

SPARQL protocol service. For brevity, from now on

we will omit the protocol term, speaking simply of

SPARQL client, SPARQL operation and SPARQL ser-

vice. We will use the term SPARQL query to de-

note a SPARQL operation of type query. Further-

more, we will use the terms SPARQL endpoint and

SPARQL service interchangeably. In the rest of the

paper, we also use the term URL instead of URI be-

cause SPARQL endpoints are identiﬁed and accessed

using URLs.

A SPARQL client submits a SPARQL operation

over HTTP to a SPARQL service that handles the

operation and sends the response back to the client.

query operations may be submitted using either the

HTTP GET or POST method, whereas update oper-

ations must be submitted using the POST method.

When a SPARQL query is submitted using the GET

method, the URL includes, among other possible pa-

rameters, the URL-encoded SPARQL query param-

eter. For instance, the following URL conveys a

SPARQL query to a SPARQL service to get all its

triples

Comunica endpoint over multiple sources

https://www.w3.org/TR/sparql11-protocol/

For readability, the SPARQL query is not URL-encoded.

Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters

ht t p : // e. g/ spar q l ? query = s elect * w h e r e {? x ? p ? y}

We propose to use the standard mechanism of URL-

encoded query string parameters as a common means

to tune the behavior of SPARQL clients and servers

involved in an HTTP exchange. Newly deﬁned pa-

rameters may pertain to different aspects of the sub-

mitted SPARQL operation, such as query planning,

authentication, output format, or execution traces. For

instance, we can amend the previous example URL to

instruct the service to provide some execution traces:

ht t p : // e. g/ spar q l ?l o g _l e v e l

log _ l e ve l

log _ l e ve l = debug &

query = s e l e c t * where {? x ? p ? y}

This use of parameters in the URL of an HTTP

query is “natural” in the sense that the parameters

are interpreted by the service being invoked. We call

them “server-side” parameters and explore them in

Section 4. We propose to complement this approach

with a set of “client-side” parameters in the URL of

an HTTP query, meant to tune the behavior of the

SPARQL client that initiates the exchange. As far as

we know, this is the ﬁrst documented case of usage

of URL parameters for tuning SPARQL clients and it

is detailed in Section 5. The primary use case that

we foresee is when the SPARQL client is process-

ing a federated query. Within a federated SPARQL

query, the SERVICE keyword instructs the query pro-

cessor to invoke (a portion of) the SPARQL query

against a remote SPARQL endpoint identiﬁed by its

URL.

Our rationale here is to tune the behavior

of the SPARQL federated query processor that takes

the role of a SPARQL client with respect to the re-

mote SPARQL services it federates, by adding query

string parameters to the URL of the remote endpoint

in a SERVICE clause. For example, if we know that

a remote endpoint does not support the HTTP POST

method, we can instruct the federated query proces-

sor to use only the GET method to communicate with

it:

SERVI C E <htt p : // e. g/ sp a r q l ?m e t h o d

method

method =get >

{ SELEC T * W H E R E {? x ? p ? y} }

Other methods could be ﬁgured out to pass such pa-

rameters to the SPARQL federated query processor,

in the form of SPARQL extensions, for instance using

Java-like annotations (introduced with the ‘@’ char-

acter). Yet, this would make the SPARQL query in-

valid for processors that do not support this extension.

The main interest of using query string parameters in

the URL of the SERVICE clause of a SPARQL feder-

ated query is that the query remains syntactically fully

SPARQL-compliant.

Finally, in the continuation of this incremental

enrichment of the SPARQL 1.1 Protocol, we pro-

https://www.w3.org/TR/sparql11-federated-query/

pose to also leverage URL parameters as a means

to control the behavior of what we call “extended

SPARQL-based services”. Such services are invoked

with regular SPARQL query operations, but their be-

havior differs from regular SPARQL services in that

their output may be different from regular SPARQL

query results, or they may implement a custom ser-

vice logic fulﬁlling speciﬁc needs. Typically, a

SPARQL federated query processor can be such an

extended SPARQL-based service: it takes as an input

a SPARQL query, rewrites it into a federated query,

communicates with remote SPARQL services to eval-

uate the query, then returns the SPARQL results. Al-

though its interface complies with that of a SPARQL

service, it implements a different logic and therefore

may require additional parameters to properly tune

its behavior. Another example is that of a service

that evaluates an input SPARQL query, applies a cus-

tom transformation to the results (e.g. generates an

HTML page), and returns the result of this transfor-

mation instead of the SPARQL query results. For

instance, the following URL asks an extended and

named SPARQL-based service to get all its triples and

transforms the results in XML format into, by using

an XSLT transformation.

ht t p : // e. g/t r a n sf o r m

tra n s f or m

tra n s f or m / sp a r q l ? fo r m a t = text / x ml &

tra n s f or m

tra n s f or m =t r a n s fo

trans f o

trans f o .xsl

xs l

xs l &

query = s e l e c t * where {? x ? p ? y}

In the next three sections we will present in details

the three patterns of URL parameters for SPARQL:

• Parameters that modify the behavior of a

SPARQL service in Section 4;

• Parameters that modify the behavior of a

SPARQL client, focusing on the case of federated

querying using SERVICE clauses, in Section 5;

• Parameters that impact the behavior of a named

extended SPARQL-based service in Section 6.

The list of all the URL parameters presented in the

paper is given in Table 1. It is worth noticing 1) that

this is not a closed list and that other URL parame-

ters may be introduced following the same approach

to answer new needs, and that 2) the same parameter

can modify both the behavior of a service and the be-

havior of the client, for instance enforcing the format

in which a result will be serialized on one side and

parsed on the other side. This is notably the case every

time a parameter concerns some aspect of the commu-

nication (HTTP method, representation format, etc.).

As a result, such parameters will appear in both Sec-

tion 4 and Section 5 where their impact on the behav-

iors will be explained respectively for the service side

and the client side.

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

Table 1: Overview of URL parameters examples. Parame-

ters in bold are part of the SPARQL protocol.

Parameter Deﬁnition

default-graph-uri specify the default named graph

named-graph-uri specify the named graphs to use

format specify expected result format

access provide an access control key

log level require logs of the execution

method force the HTTP method to use

header add an HTTP header

limit maximum number of results

timeout maximum time for a response

binding specify variable binding method

binding focus variables to pass in bindings

binding skip variables not to pass in bindings

binding slice size of bindings for each call

mode generic behaviour customizing

accept subset of federated services to be used

reject subset of federated services not to be used

transform apply a transformation to the data

4 URL PARAMETERS FOR

SPARQL SERVICES

This ﬁrst family of URL parameters is certainly the

most natural, standard and common one. It aims at

modifying the behavior of the SPARQL service being

invoked: a SPARQL service receiving a parameter-

ized HTTP request should adapt its behavior and the

returned answer according to the query parameters.

Yet it can be noticed that, while many SPARQL end-

point implementations support parameters (Virtuoso,

BlazeGraph, etc.), the idea of using them in the con-

text of SPARQL SERVICE clauses is not widespread

yet. In this section, we ﬁrst want to establish the in-

terest of these parameters in the context of a SERVICE

clause and then propose several new parameters for

SPARQL query and update operations.

The default-graph-uri and the

named-graph-uri Parameters: provide

an immediate and standard example as they are

deﬁned in the SPARQL 1.1 Protocol to specify the

dataset to be used by a SPARQL service in solving a

query. In the context of a SERVICE clause, this ability

addresses an important limitation of the SPARQL

query language that does not support the declarative

speciﬁcation of the dataset for such a clause: FROM

and FROM NAMED are not supported at the SERVICE

clause level in SPARQL. Although this usage is

neither documented in the standards nor widespread

in online documentation, it is a perfect example

from the standards of the impact of being able to

parameterize the behavior of the invoked SPARQL

service directly through the URL query string.

The format Parameter: was introduced in our

implementation to enable us to specify the format of

the SPARQL query result expected from the SPARQL

service (the SPARQL update operation is not con-

cerned). The motivating scenario is that, in a perfect

Web, SPARQL services all support content negotia-

tion and provide correctly formatted results, but in the

World Wild Web, SPARQL services may have limita-

tions or bugs in their content negotiation or serializer

implementations. The value of a format parameter is

a media type

. If set, this parameter overrides values

provided by the optional HTTP Accept header, if any,

and thus bypasses any content negotiation process.

For instance, the following URL asks a SPARQL ser-

vice to provide all its triples in the JSON-LD format.

ht t p : // e. g/ spar q l ?f o r m a t

format

format = ap p l ic a t io n / ld + j s o n

& query = selec t * w h e r e {? x ? p ? y}

The access Parameter: introduced in our imple-

mentation enables us to enforce a key-based access

control policy on SPARQL services. The motivating

scenario is that, in a perfect Web, SPARQL services

should serve open data at will to all users, but in the

World Wild Web, some private or critical SPARQL

services need to limit their access to authorized users

for security and privacy concerns or to avoid satura-

tion. Typically, a SPARQL service running in pro-

tected mode will not process an HTTP query opera-

tion unless this request is parameterized with an au-

thentication key that was delivered by the SPARQL

service manager to the authorized users. For instance,

the following URL can be used by an authorized user

to submit a SPARQL query to a SPARQL service

while passing the authentication key a6h3fb58Fbd3:

ht t p : // e. g/ spar q l ?a c c e s s

access

access =a 6 h 3f b 5 8F b d 3

a6 h 3 f b5 8 F bd 3

& query = selec t * w h e r e {? x ? p ? y}

Note that other authentication and/or authorization

mechanisms may be required. For instance, Section 5

describes how a header parameter can pass a security

token via the standard Authorization HTTP header.

The log level Parameter: was introduced in

our implementation to enable us to instruct SPARQL

services to turn on the generation of execution traces.

The motivating scenario is that, in a perfect Web,

SPARQL services should always receive SPARQL

queries implementing the actual user need and serve

the expected data, but in the World Wild Web, some

unexpected or missing data may be delivered by a

SPARQL service, and like for any program, execu-

tion traces are highly valuable to understand abnor-

https://www.iana.org/assignments/media-types/

media-types.xhtml

Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters

mal behavior, detect bugs in the service or modify

the SPARQL query sent to it. An example URL con-

taining a log level=debug parameter is provided in

Section 3. The execution traces are produced in the

SPARQL service’s logging system. Another imple-

mentation could choose to provide the client with

such traces by means of the header’s link ﬁeld within

XML or JSON SPARQL results.

5 URL PARAMETERS FOR

SPARQL CLIENTS

In a perfect Web, all SPARQL services implement

the full set of SPARQL recommendations, have no

timeout nor limited number of results, and perfectly

comply with serialization speciﬁcations. In the World

Wild Web, a SPARQL service may support the HTTP

GET method but not the POST method, or may be able

to return a valid JSON document but an invalid XML

document. Furthermore, public SPARQL endpoints

often limit the maximum number of results with quo-

tas, such that a client would need to add the LIMIT

and OFFSET modiﬁers to its SPARQL query in order

to incrementally get a complete result set. This is even

more striking when federated querying. In the worst-

case scenario, to evaluate the SERVICE clauses in a

SPARQL federated query, the SPARQL query proces-

sor may need to adapt its behavior to the issues or lim-

itations of each one of the SPARQL remote services

that the query involves. Unfortunately, SPARQL does

not allow specifying such a ﬁne-tuning in a declara-

tive manner.

Therefore, in this section we consider the case

where URL parameters are not only meant for the

SPARQL service being invoked but also, or rather,

meant to modify the behavior of the SPARQL client

sending an HTTP request to a SPARQL service or re-

ceiving its response. More precisely, in our imple-

mentation we have introduced several query string pa-

rameters in the URL of the SERVICE clause, that are

interpreted by the SPARQL federated query processor

(the client) to tune its behavior – and that may also be

interpreted by the remote SPARQL service or simply

be ignored.

The method Parameter: speciﬁes the HTTP

method (GET or POST) to be used by the federated

query processor to submit a SPARQL query to a re-

mote SPARQL service. For instance, the URL in

the following SERVICE clause can be used to ask

the federated query processor (the client) to use the

HTTP POST method to submit its query to the remote

SPARQL service – and to pass the authentication key

a6h3fb58Fbd3. The remote SPARQL service may

use or ignore any of the parameters, in particular it

can ignore the method parameter but enforce the au-

thentication key:

SERVI C E <htt p : // e. g/ sp a r q l ?m e t h o d

method

method =po s t

po s t

po s t &

access = a6h3f b 5 8 F b d 3 >

{ ? x ?p ? y }

The format Parameter: speciﬁes the media type

of the query results returned by the SPARQL service.

It may be used when the SPARQL service does not

support content negotiation and returns results in a

ﬁxed format. It may also be the counterpart of the

server-side format parameter described in Section 4,

that skips the content negotiation process and forces

the SPARQL service to return results in the speciﬁed

media type. Accordingly, on the client side, this pa-

rameter instructs the SPARQL federated query pro-

cessor to select an appropriate parser for the results

of a remote service without considering any content

negotiation.

The log level Parameter: is the counterpart of

the server-side log level parameter presented in

Section 4. When federated querying, it instructs the

client SPARQL federated query processor to turn on

the generation of execution traces. This is particularly

handy when drafting a SPARQL federated query. In-

deed, how a federated query processor rewrites each

SERVICE clause, for instance by adding variable bind-

ings, is implementation-dependent. The log level

parameter can help query debugging by providing in-

sight into the strategy adopted by the federated query

processor when rewriting a certain SERVICE clause.

The header Parameter: speciﬁes an HTTP

header to be sent by the client SPARQL federated

query processor to a remote SPARQL service along

with the SPARQL operation. Each parameter value,

formatted as name:value, will be passed as a header

of the HTTP request. For instance, let us consider the

following SERVICE clause:

SERVI C E <htt p : // e. g/ sp a r q l ?

header

header = Au t ho r i za t i on : Basic Yv c G V u c 2 V z Y >

{ ? s ?p ? o }

In this example, the value of parameter header is

the HTTP Authorization request header with the

Basic type and YvcGVuc2VzY for the credentials

value. If the federated query processor uses the

HTTP POST method to send the query to the remote

SPARQL service, the HTTP request that it will send

will look like this:

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

PO S T / spar q l HTTP /1.1

Ho s t : e . g

Co n t ent - Type : a pp l i ca t i on / s p arql - query

Au t h o ri z at i o n : B a s i c Yv c G V uc 2 Vz Y W

SELECT * W H E R E { ?s ? p ?o }

The limit Parameter: speciﬁes a limit for the

number of results returned by one service call. It in-

structs the client SPARQL federated query processor

to add a LIMIT solution modiﬁer to the query it sub-

mits to the remote SPARQL service. For example, the

URL in the following SERVICE clause tells the query

processor to query the remote service for only its 100

ﬁrst results for the graph pattern in the clause.

SERVI C E <htt p : // e. g/ sp a r q l ?limit

limit

limit =100 > { ? s ?p ? o }

The timeout Parameter: speciﬁes a time quota

(in milliseconds) during which the client SPARQL

federated query processor will wait for the remote

SPARQL service to respond. Once this timeout

expires without receiving a response, the federated

query processor deems the query as failed. Example:

SERVI C E <htt p : // e. g/ sp a r q l ?t i m e o ut

timeo u t

timeo u t = 5000 > { ? s ?p ? o}

For simplicity, we consider the connect and read

timeouts at once, however they could be distinguished

by introducing two different timeout parameters.

Binding-related Parameters: The query plan and

strategy adopted by a SPARQL federated query pro-

cessor to evaluate a SPARQL federated query is

implementation-dependent. We introduced in our im-

plementation a set of binding-related, client-side URL

parameters to enable a SPARQL practitioner to lever-

age prior knowledge about a SPARQL service to help

the client SPARQL federated query processor to come

up with a more efﬁcient query plan.

The binding Parameter: speciﬁes the way the

client SPARQL federated query processor should

pass variable bindings to a remote SPARQL service.

Bindings coming from the evaluation of some graph

pattern in the federated query are passed to a re-

mote SPARQL service in case the graph pattern it

should evaluate shares in-scope

variables with the

previously evaluated ones. The method used by a

client SPARQL federated query processor to pass

variable bindings to a remote SPARQL service is

implementation-dependent. In a perfect Web, the

“natural” way to pass bindings would be to use a

VALUES block in the SERVICE clause. But, in the

https://www.w3.org/TR/sparql11-query/#variableScope

World Wild Web, some SPARQL services do not im-

plement the VALUES clause. Therefore, for the sake of

interoperability, by default our implementation uses

ﬁlters to pass bindings, and we deﬁned a binding pa-

rameter to choose among both possible ways. For in-

stance, let us consider the following federated query:

SELECT * W H E R E {

?s ? p ?o.

SERVI C E <htt p : // e. g/ sp a r q l ? > {? s ? q ? v. ?o ? q ?w }}

and the intermediate variable binding coming from

the evaluation of triple pattern ?s ?p ?o:

{( ? s, s 1 ), (? p , p1 ), ( ? o , o1 )}

Adding parameter binding=filter to the URL

of the SERVICE clause (the default behavior) will

cause the federated query processor to generate the

SPARQL code:

FILTER ( ? s = s1 && ? o = o 1 )

Conversely, adding parameter binding=values will

generate the SPARQL code:

VALUES ( ? s ?o ) { ( s 1 o1 ) }

The binding focus and binding skip Pa-

rameters: specify a subset of variables for which

variable bindings should or should not be passed to

the service. In the example below, the bindings con-

sider variable s and not variable o.

SELECT * W H E R E {

?s ? p ?o.

SERVI C E <htt p : // e. g/ sp a r q l ?b i nd i ng _ f oc u s

bi n d i ng _ fo c u s

bi n d i ng _ fo c u s = s >

{ ? s ?q ? o }

}

Alternatively, in the example below the bindings do

not consider s and consider o only.

SELECT * W H E R E {

?s ? p ?o.

SERVI C E <htt p : // e. g/ sp a r q l ?b i nd i n g_ s k ip

bi n d i ng _ s ki p

bi n d i ng _ s ki p =s >

{ ? s ?q ? o }

}

The binding slice Parameter. enables to

specify the number of distinct variable bindings sent

within one service call. The set of variable bindings

is split into subsets of size less than or equal to this

number. The service is called once for each such sub-

set of variable bindings. In our implementation, the

default value of binding slice is 20. But one could,

for instance, force one call per binding:

SELECT * W H E R E {

?s ? p ?o.

SERVI C E <htt p : // e. g/ sp a r q l ?b i nd i ng _ s li c e

bi n d i ng _ sl i c e

bi n d i ng _ sl i c e =1 >

{ ? s ?q ? o }

}

Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters

6 NAMED AND EXTENDED

SPARQL-BASED SERVICES

In this section, we generalize on the server-side pa-

rameters approach of Section 4. We now propose

to mint

URLs that identify and specify “extended

SPARQL-based services”, a kind of services invoked

with regular SPARQL query operations, but whose

behavior differs from that of regular SPARQL ser-

vices in that their output may be different from reg-

ular SPARQL query results, or they may implement

a custom service logic fulﬁlling speciﬁc needs. Their

URLs are minted to unambiguously name these ser-

vices. We put a speciﬁc stress on this naming con-

cern because what is at stake here is not just to ﬁg-

ure out the URL to access such a service. We mean

to use those URLs as URIs, free from any optional

query component, identifying these services as ﬁrst-

class resources, so that we can not only invoke these

services, but also annotate them in RDF descriptions,

and conﬁgure them with server-side URL parameters.

6.1 The Common Case of SPARQL

Federated Query Services

As federated querying over multiple sources is a very

common and important use case in applications such

as scientiﬁc data integration, this section makes a fo-

cus on SPARQL federated query services. In Sec-

tion 5 we considered the client role of a SPARQL

federated query processor communicating with re-

mote SPARQL services to evaluate a SPARQL fed-

erated query. Here we consider the service role of

a SPARQL federated query processor, serving its re-

sults to SPARQL clients that ignore everything about

the federation. We denote by “SPARQL federated

query service” a set of approaches implementing the

federation of several SPARQL services. These can

be seen as extended SPARQL-based services insofar

as they take as input a regular SPARQL query, but

implement a service logic that differs from that of a

regular SPARQL service.

We deﬁned a succinct vocabulary to declare in

RDF a SPARQL federated query service. For in-

stance the following RDF/Turtle conﬁguration de-

scribes the X SPARQL federated query service, iden-

tiﬁed by http://e.g/X/sparql, that federates three

SPARQL services.

prefix s t : < h t t p :// e. g/ sparql - te m p l a te />

< h t t p :// e. g ./ X/ sp a rql > a s t : F ed e r at i o n ;

Minting a URI is the act of establishing the association

between the URI and the resource it denotes (Allemang

et al., 2020).

st : d ef i n it i o n (

< h t t p :// a. b / b la z e gr a p h / Y / spar ql >

< h t t p s : // c. d/ fu s e k i / an no t a t io n / spa r ql >

< h t t p :// i. j / r ep o si t o ri e s / spar q l >

) .

Below we present two examples of alternative imple-

mentations of such SPARQL federated query services

that we developed and tested.

The ﬁrst one receives a SPARQL query and sends

it as is to the remote SPARQL services that it feder-

ates, performs the union of partial results and aggre-

gates, if any, and returns the results. The URLs of this

ﬁrst implementation continue to use the /sparql that

appears in the URL of standard SPARQL services to

suggest that they do not change the query itself.

The second implementation is what is commonly

referred to as a “federation engine”. It starts by ask-

ing remote SPARQL services which properties and

classes occur in their datasets and builds an index

from the results. Then, using this index, it rewrites

the SPARQL query it received with SERVICE clauses.

Each clause is targeting a SPARQL service that, ac-

cording to the index, may contain results for the triple

patterns it speciﬁes. To distinguish this second im-

plementation from the ﬁrst one, the endpoint URL is

minted with /federate in its name:

ht t p : // e. g/ X/fe d e r a te

fede r a t e

fede r a t e ?

query = s e l e c t * where { ? x ?p ? y }

Similarly to what we demonstrated in Section 4,

like for any SPARQL service, we can tune the behav-

ior of such a named SPARQL federated query service

by adding query string parameters to its URL:

The mode=provenance Parameter: enables to

track the provenance of each result. For instance, the

query below asks the D2KAB federated service to re-

trieve arboriculture sub-concepts from any of the fed-

erated endpoints.

SELECT DI S T IN C T * WHERE {

[] skos : pr ef L a b el " ar b o ri c ul t u re " @fr ;

sk o s : na r r ow e r + [ skos : p re f L a be l ? lb l ] .

}

We can submit it with the URL below, where the

URL-encoded query is ommitted for clarity:

ht t p : // cor e s e . inria . fr /d2kab / sparq l ?

mo d e

mo d e = pr ov e n a nc e & qu e r y = ...

Table 2 shows a short subset of the results re-

turned, where a pseudo-variable server is added to

output the provenance of the variable bindings.

The accept and reject Parameters: specify a

subset of the SPARQL services to be involved in the

evaluation of the query submitted to the SPARQL fed-

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

Table 2: Example query result when using the

mode=provenance parameter. Variable server provides

the URL of the service that yielded this variable binding.

server lbl

http://ontology.irstea.fr/bsv/sparql vigne de cuve

http://ontology.inrae.fr/frenchcropusage/sparql abricotier

erated query service. The value of these parameters is

a string pattern. The SPARQL federated query ser-

vice should skip the services in its federation whose

URL matches the pattern value of the reject param-

eter and/or consider those whose URL matches the

pattern value of the accept parameter. For instance,

assuming that the federation conﬁguration names the

endpoints of several DBpedia chapters, to answer the

SPARQL query encoded in the following URL, the X

SPARQL federated query service should consider any

DBpedia chapter except the French one.

ht t p : // e. g/ X/ sparq l ?ac c e p t

accept =dbp e d i a

dbped i a

dbped i a &r e j e c t

reject

reject =dbp e d i a

dbped i a

dbped i a .fr

& query = selec t * w h e r e {? x ? p ? y}

6.2 Extended SPARQL-based Services

for Application Integration

Generalizing on the previous example of SPARQL

federated query services and data integration, we now

report on a number of other extended services we ex-

perimented with in the more general context of Web

application integration. The approach remains the

same but is no longer focused on the problem of query

federation: we mint URLs to unambiguously name a

new service, to annotate it in RDF descriptions, to call

it and to conﬁgure it with URL parameters.

RDF Transformation Services. The transform

parameter enables us to turn a SPARQL service into

an RDF transformation service. In an ideal Web, ev-

eryone would be using the same transformation and

rendering techniques and pipelines. In the World Wild

Web, the loose coupling of applications and the va-

riety of formats and presentation solutions requires

ﬂexible transformation means. A parameterized RDF

transformation service returns the result of a transfor-

mation that could come from any existing approach

such as XSLT (Kay, 2021), FRESNEL (Pietriga et al.,

2006) or STTL (Corby et al., 2015). For instance, the

following parameterized service outputs the transfor-

mation of the query results into an HTML page.

ht t p : // e. g/ X/ sparq l ?t r a n sf o r m

tra n s f or m

tra n s f or m = st :r df 2 h t m l

rdf2 h t m l

& query = selec t * w h e r e {? x ? p ? y}

Another example is the generation of widgets exploit-

ing dimensions of the data (time, location, etc.), for

instance, a map with plots when the SPARQL query

results contain longitude and latitude values.

SPARQL Query Result Annotation Services. The

mode=link parameter together with the transform

parameter enable us to turn a SPARQL service into a

SPARQL query result annotation service. The result

of the transformation is stored in a document on the

server, a URL is provided for this document and is re-

turned as the value of the link element in the head of

the SPARQL query result. For example, the follow-

ing parameterized service will generate a map with

location longitude and latitude, and a link mode that

adds the URL of the generated map in the head of the

SPARQL query result.

ht t p : // e. g/ X/ sparq l ?t r a n sf o r m

tra n s f or m

tra n s f or m =st

st :m ap

ma p

ma p &mo d e

mo d e

mo d e =link

li n k

& query = selec t * w h e r e {? x ? p ? y}

It is possible to generate several annotations by spec-

ifying several transformations, in which case the ser-

vice generates several link elements.

SPIN Services. The mode=spin parameter enables

to turn a SPARQL service into a SPARQL2SPIN ser-

vice that generates the SPIN format (Knublauch et al.,

2011) of the SPARQL query sent to it. For example,

the following parameterized service

ht t p : // e. g/ X/ sparq l ?mode

mo d e

mo d e =spin

sp i n

& query = selec t * w h e r e {? x ? p ? y}

will output the following RDF/Turtle SPIN graph:

@pref i x s p : < http :// s pinr d f . org / s p #> .

[a sp : S elect ;

sp : s t a r true ;

sp : w h e r e ([ sp : obje c t [ sp : v a r N a me " y "] ;

sp : p re d i c at e [ sp : v a r N ame " p" ] ;

sp : s ubj e c t [ sp : v a r Name " x"]])] .

SHACL Services. In a perfect Web, the data

sources we consume would be complete and would

meet the level of quality we need. In the World Wild

Web, data sources do not always match our criteria

and we need means to check if the constraints we

have are met. The mode=shacl parameter used in

combination with the uri parameter enables to turn

a SPARQL service into a SHACL service that evalu-

ate the shapes in the SHACL document, the URL of

which is given as value of parameter uri, on the RDF

graph it serves. Moreover, the query passed as param-

eter in the URL is executed on the SHACL validation

report graph. For example, the following parameter-

ized service will output the conformity boolean value.

ht t p : // e. g/ X/ sparq l ?mode

mo d e

mo d e =s h a c l

shacl

shacl &uri

ur i

ur i =shape

shape

shape .rdf

rd f

& query = selec t * w h e r e {? re p ort sh : c o nfo r m s ?b }

Service Deﬁnition. Specifying a list of parameter

values to deﬁne extended SPARQL-based services

may be cumbersome for some developers and one

Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters

may want to synthesize a speciﬁc list of parameter

values within a speciﬁc mode. For this purpose, we

deﬁned a small vocabulary to enable the user to de-

ﬁne in RDF new modes as the combination of several

parameters that can be used to parameterize a service

just like any predeﬁned mode. For example, the fol-

lowing RDF description deﬁnes a map mode as the

combination of the st:map transformation that gen-

erates a map with location longitude and latitude, and

a link mode that adds the URL of the generated map

in the head of the SPARQL query result.

[] st :mode " map " ;

st : p a r a m ((" mod e " " li n k " )(" t r a ns f o r m " st : m a p )) .

Developers can then use such deﬁned modes to deﬁne

an extended service. For example, the following pa-

rameterized service is equivalent to the example ser-

vice illustrating the annotation services.

ht t p : // e. g/ X/ sparq l ?mode

mo d e

mo d e =map

ma p

& query = selec t * w h e r e {? x ? p ? y}

A generic mode, named “*”, enables us to specify

parameters that are shared by all the SPARQL-based

services offered at a given SPARQL service. For ex-

ample, the following RDF description states that all

the services will run in debug mode.

[] st :mode " *" ;

st : p a r a m ((" mod e " " de b u g " ) ) .

Services can also be described to associate them a

parameter setting, so that the URL that should be used

to invoke them will not have any query string param-

eter. For example, the following RDF description de-

ﬁnes a service as parameterized by the (user-deﬁned)

map mode:

< h t t p :// e. g / map /spa r ql > s t : p a r a m ((" mo d e " " map ") ) .

Once deﬁned like this it can be invoked without any

other parameter than the standard query one:

ht t p : // e. g/m a p

ma p

ma p / sparq l ? query = s elect * w h e r e {? x ? p ? y}

7 EXPERIMENTS & EVALUATION

The URL query string parameters presented in the

previous sections have been implemented in the

Corese Semantic Web factory.

In this section, we

demonstrate their interest in the context of two exam-

ple queries that originate from on-going scientiﬁc data

integration projects. In particular, we show the impact

of this parameterization against baseline queries solv-

ing the same issues in standard conditions.

https://project.inria.fr/corese/

7.1 Binding Variables: FILTER / VALUES

The following query searches the URIs of some spa-

tial entities in a local dataset, and tries to fetch addi-

tional information about each of them from Wikidata

using a SERVICE clause.

SELECT ? e ? la b e l WH E R E {

[] d c t : spa t i a l ? e.

SERVI C E <https :/ / q u e r y . wi k id a t a . org /spa rql > {

?e rdfs : l a b e l ? label .

FILTER ( la n g (? l a b e l ) = " en ")

}}

When a SPARQL engine evaluates this query, a possi-

ble strategy is to ﬁrst retrieve the values of variable e

(91 distinct values in our case), then pass them to the

SERVICE clause as variable bindings. The SPARQL

federated query recommendation does not specify the

way to pass such bindings. A possible way is to pass

them using a ﬁlter, i.e. the following query is submit-

ted to Wikidata:

SELECT * W H E R E {

?e rdfs : l a b e l ? label .

FILTER ( la n g (? l a b e l ) = " en ")

FILTER ((? e= wd : Q6730 ) || (? e= w d : Q 1 2 5 8 9 ) || ...)

}}

Unfortunately, Wikidata systematically times out

when evaluating such a query.

However, we can

work around this issue using the binding URL pa-

rameter described in Section 5. When we add it to the

Wikidata URL as depicted below,

< h t t p s : // query . wi k i d a ta . o r g / s parql ?bi n d i n g

bindi n g

bindi n g =val u es

va lues

va lues >

we instruct our SPARQL engine to use a VALUES

block instead of a FILTER. The rewritten query sent

to Wikidata now completes in less than one second:

SELECT * W H E R E {

VALUES ( ? ent i t y ) { ( wd :Q6730 ) ( w d : Q 1 2 5 8 9 ) ... }

?e rdfs : l a b e l ? label .

FILTER ( la n g (? l a b e l ) = " en ")

}}

7.2 Slicing Variables Bindings

In the same on-going projects, we identiﬁed a second

use case that involves the following SPARQL feder-

ated query to match resources from two RDF sources

using their names:

SELECT * W H E R E {

SERVI C E <htt p : // e1 .g / spar ql > {

[] sch e m a : name ? name .

}

SERVI C E <htt p : // e2 .g / s p a r q l ?b ind i n g

bindi n g

bindi n g = val u es > {

The query only completes when there is one single value

for ?e in the FILTER clause. With two or more values,

Wikidata times out.

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies

SELECT di s t in c t ? name ? f u l l nam e WH E R E {

VALUES ? na m e { un d e f }

[] rdfs : la b e l ? fu l l n a me .

FILTER ( st r s t ar t s (? fu l l n a me , ? nam e ))

}} }

In the ﬁrst SERVICE clause, variable ?name is

matched with 166 values. In the second SERVICE

clause, variable ?fullname is matched with over

600,000 values. The second SERVICE clause can-

not retrieve values for the ?name variable which

is only used in the FILTER. Therefore, our imple-

mentation will start with the evaluation of the ﬁrst

SERVICE clause, and then pass the values of vari-

able ?name as bindings to the second SERVICE clause.

Furthermore, building on the experience of the use

case described in Section 7.1, we added the param-

eter binding=values to perform the binding using a

VALUES block rather than a FILTER.

The join between the two SERVICE clauses must

be done on the ?name variable. Note however that,

in the second SERVICE clause, ?name is not directly

used as the term of a triple pattern but instead used

in a string comparison (strstarts). This makes the

query optimization much harder and, consequently,

during our experimentations, the Virtuoso OS server

at http://e2.g/sparql took in the order of 45 min-

utes to return the results.

We made further experiments to assess the num-

ber of values that can be passed in the VALUES block

while keeping the query processing time below one

minute. With one value, Virtuoso consistently took

between 4s and 8s to respond. With two values, it took

between 2min 30s and 3min. The more values, the

longer it took to respond. Therefore, we added param-

eter binding slice=1 to pass the values of variable

?name one by one. The URL of the second SERVICE

clause is as follows:

< h t t p :// e2 . g/ sp a r q l ?b i n d ing

bindi n g

bindi n g = va l u e s &b in d i ng _ sl i c e

bi n d i ng _ sl i c e

bi n d i ng _ sl i c e =1 >

The whole query processing completed in approx-

imately 21 minutes, which is roughly half of the

time it took to process the query without the

binding slice. The improvement may be deemed

modest. It is however important to remind that with

a public SPARQL endpoint, where the time quota is

typically in the order of one minute, the initial query

would never complete, whereas, with our method, it

will take time but will complete eventually.

Without the URL query string parameters intro-

duced in this paper and demonstrated in this section,

it is hardly possible to obtain the results solely within

SPARQL. Instead, the SPARQL practitioner would

have to code a hack in another language to circum-

vent the limitations. As a comparison, we devel-

oped a Python application to achieve the same goal.

Based on the SPARQLWrapper library, the program

evaluates the ﬁrst SERVICE clause, stores the tem-

porary results in a DataFrame, and submits the sec-

ond SERVICE clause one value at a time. This does

exactly the same that what we achieve declaratively

with just one parameter: binding slice. While the

SPARQL query is 10 lines long, the Python program

is approximately 100 lines long. Besides, both solu-

tions complete in a similar time since they submit the

same number of queries.

Ultimately, this example also shows that beyond

the federated querying use cases we used to demon-

strate the interest of URL parameters in SPARQL,

this technique is also a way to provide customized

proxies masking the limitations and speciﬁcities of

SPARQL service implementations and supporting the

loose-coupling that make the Web an attractive appli-

cation integration platform (Fielding et al., 2017).

8 CONCLUSION

In a perfect Web, following standards would be

enough. In the World Wild Web, the ability to tune,

customize, parameterize the applications may make

the difference between a running application and a

frozen one. In this paper, we proposed a uniform way

of adapting and customizing the behavior of both the

client and the server components of an HTTP exchange

to cope with the heterogeneity of implementations we

ﬁnd in Web applications. More speciﬁcally we de-

signed and experimented the use of URL parameters

to parameterize the behaviors of both the SPARQL

client and the SPARQL service, in particular in the

context of SERVICE clauses used in SPARQL feder-

ated queries. We believe that this method has the po-

tential to make federated querying in SPARQL more

ﬂexible, actionable, and suited to World Wild Web

contexts, far beyond the examples that are generally

demonstrated in ideal, controlled environments.

Another interesting general use case we did not

develop here is the debugging of federated queries

in the case where the query result is empty. It

may be interesting to provide parameters such as

mode=explain to obtain additional data such as in-

termediate query results that can be provided using

linked results (mode=link). Hence, URL parameters

could be used to tune a debugger.

In our future work, we also intend to study the

relation of the extension we proposed with other parts

of the SPARQL standard such as the SPARQL Service

Description that “provides a mechanism by which a

client or end user can discover information about the

SPARQL service” (Williams, 2013).

Beyond Classical SERVICE Clause in Federated SPARQL Queries: Leveraging the Full Potential of URI Parameters

In the longer term, the annotation technique in-

troduced by the mode=link parameter holds the huge

potential to turn what are essentially one-off queries

into entry points of a hypermedia network of queries.

For instance, by providing links to reformulated or re-

laxed queries, expanded queries, suggested follow-up

queries, etc., we would allow non SPARQL clients

with classical Web client capabilities to still navigate

and discover the content of endpoints as a classical

Web hypermedia space just by applying the “follow

your nose” principle.

ACKNOWLEDGEMENTS

This work was partially supported by the French Na-

tional Research Agency under grant ANR-18-CE23-

0017 (D2KAB project).

REFERENCES

Allemang, D., Hendler, J. A., and Gandon, F. (2020). Se-

mantic Web for the Working Ontologist. ACM Books.

Berendt, B., Gandon, F., Halford, S., Hall, W., Hendler,

J., Kinder-Kurlanda, K. E., Ntoutsi, E., and Staab, S.

(2021). Web Futures: Inclusive, Intelligent, Sustain-

able The 2020 Manifesto for Web Science. Dagstuhl

Manifestos.

Berners-Lee, T., Fielding, R. T., and Masinter, L. (2005).

Uniform resource identiﬁer (URI): Generic syntax.

STD 66, RFC Editor. http://www.rfc-editor.org/rfc/

rfc3986.txt.

Berners-Lee, T. J. (1989). Information management: A pro-

posal. Technical report, CERN.

Broekstra, J., Kampman, A., and Van Harmelen, F. (2002).

Sesame: A generic architecture for storing and query-

ing RDF and RDF schema. In International semantic

web conference, pages 54–68. Springer.

Buil-Aranda, C., Hogan, A., Umbrich, J., and Vandenbuss-

che, P.-Y. (2013). SPARQL web-querying infrastruc-

ture: Ready for action? In International Semantic

Web Conference, pages 277–293. Springer.

Buil-Aranda, C., Polleres, A., and Umbrich, J. (2014).

Strategies for executing federated queries in SPARQL

1.1. In International Semantic Web Conference, pages

390–405. Springer.

Corby, O., Faron-Zucker, C., and Gandon, F. (2015). A

Generic RDF Transformation Software and its Appli-

cation to an Online Translation Service for Common

Languages of Linked Data. In Proc. 14th Interna-

tional Semantic Web Conference, ISWC, Bethlehem,

Pennsylvania, USA.

Erling, O. and Mikhailov, I. (2010). Virtuoso: RDF support

in a native RDBMS. In Semantic Web Information

Management, pages 501–519. Springer.

Fielding, R. T., Taylor, R. N., Erenkrantz, J. R., Gor-

lick, M. M., Whitehead, J., Khare, R., and Oreizy,

P. (2017). Reﬂections on the rest architectural style

and” principled design of the modern web architec-

ture”(impact paper award). In Proceedings of the 2017

11th Joint Meeting on Foundations of Software Engi-

neering, pages 4–14.

Gandon, F. (2018). A Survey of the First 20 Years of Re-

search on Semantic Web and Linked Data. Revue des

Sciences et Technologies de l’Information - S

erie ISI :

Ing

enierie des Syst

emes d’Information.

Harris, S. and Seaborne, A. (2013). SPARQL

1.1 Query Language. Recommendation, W3C.

http://www.w3.org/TR/sparql11-query/.

Hartig, O., Letter, I., and P

erez, J. (2017). A formal frame-

work for comparing linked data fragments. In In-

ternational semantic web conference, pages 364–382.

Springer.

Kay, M. (2021). XSL transformations (XSLT) ver-

sion 2.0 (second edition). W3C recommendation,

W3C. https://www.w3.org/TR/2021/REC-xslt20-

20210330/.

Knublauch, H., Hendler, J. A., and Idehen, K. (2011).

SPIN-overview and motivation. W3C member sub-

mission, W3C. https://www.w3.org/Submission/spin-

overview/.

Minier, T., Skaf-Molli, H., and Molli, P. (2019). SaGe: Web

preemption for public SPARQL query services. In The

World Wide Web Conference, pages 1268–1278.

Pietriga, E., Bizer, C., Karger, D., and Lee, R. (2006). Fres-

nel: A browser-independent presentation vocabulary

for rdf. In International Semantic Web Conference,

pages 158–171. Springer.

Saleem, M., Khan, Y., Hasnain, A., Ermilov, I., and

Ngonga Ngomo, A.-C. (2016). A ﬁne-grained eval-

uation of SPARQL endpoint federation systems. Se-

mantic Web, 7(5):493–518.

Schwarte, A., Haase, P., Hose, K., Schenkel, R., and

Schmidt, M. (2011). Fedx: Optimization techniques

for federated query processing on linked data. In In-

ternational semantic web conference, pages 601–616.

Springer.

Taelman, R., Van Herwegen, J., Vander Sande, M., and Ver-

borgh, R. (2018). Comunica: a modular SPARQL

query engine for the Web. In International Semantic

Web Conference, pages 239–255. Springer.

Verborgh, R., Vander Sande, M., Hartig, O., Van Herwe-

gen, J., De Vocht, L., De Meester, B., Haesendonck,

G., and Colpaert, P. (2016). Triple Pattern Fragments:

a low-cost knowledge graph interface for the Web.

Journal of Web Semantics, 37:184–206.

Williams, G. (2013). SPARQL 1.1 service de-

scription. W3C recommendation, W3C.

https://www.w3.org/TR/2013/REC-sparql11-service-

description-20130321/.

WEBIST 2021 - 17th International Conference on Web Information Systems and Technologies