Federated SPARQL queries give uni ed answers from multiple and distributed SPARQL endpoints. A good example may be the collection of stops from di erent transport companies in the same city to create a route planning application. The performance of the evaluation of these types of queries is usually poor, a fact that makes di cult their use in real-life applications that need good performance requirements. In this paper we present a preliminary analysis on the improvement that can be achieved by using the GRAPH clause in federated SPARQL queries. The main goal is to reduce the search space of such queries by setting the NAMED GRAPH to the graph pattern where the corresponding patterns should be evaluated. We perform a preliminary comparison between a federated query and a rewriting that uses systematically the GRAPH clause. These experiments show that the inclusion of the GRAPH clause may only improve performance of query evaluation between 5% and 10%. These early ndings suggest that, although the GRAPH clause may indeed play a role in speeding up federated SPARQL queries, hurdles are yet to be overcome when using the GRAPH clause as named graphs are semantically ambiguous.
In recent years several public SPARQL endpoints have been made available on
the Web containing billions of RDF triples that can be queried [
While these queries are useful for this purpose, their main disadvantage is their low performance, hence their use on real applications is limited. Other approaches are being currently applied, like getting the data from APIs, doing a manual data merge or joining data at the client side. Even so, federated queries are still an interesting approach to query RDF data sources exposed via SPARQL endpoints. Finding ways to improve their performance is one of the current research topics in the eld.
A SPARQL endpoint is conceptualized as shown in Figure 1: one defaultgraph and from 0 to N NAMED GRAPHS. Each of these NAMED GRAPHS contains a set of triples and has a unique identi er (URI). In a SPARQL query it is possible to indicate the graph where a particular part of a query (e.g. a pattern) will be evaluated completely or partially, by using the GRAPH clause with the graph URI. We hypothesize that using this feature in a systematic form may reduce the search space when evaluating federated SPARQL queries. The goal of this paper is to add evidence to this claim.
The paper is organized as follows: Section 2 presents some of the related work on the conceptualization of SPARQL endpoints and federated queries. Section 3 describes our proposal about systematically using the GRAPH clause in federated queries. Section 4 shows a preliminary evaluation and presents some conclusions and future areas of work to be explored. 2
In this section we describe related work on two topics. On the one hand, the SPARQL endpoint conceptualizations; on the other hand, several optimizations that have been proposed in the area of federated SPARQL queries.
The SPARQL endpoint conceptualization is not an easy task. Hernandez
and Gutierrez [
There are several works in the literature on federated SPARQL queries that
try to optimize the performance of query evaluation [
Using GRAPH clauses in federated SPARQL queries In this section we propose an approach to improve federated query evaluation by systematically using the GRAPH clause to rewrite a query into a semantically equivalent one.
When the GRAPH clause is used in a SPARQL query, only triples saved
into that GRAPH clause will occur in the resulting SPARQL bindings. We want
to compare the performance between a federated SPARQL and a semantically
equivalent query that makes use of the GRAPH clause to direct the evaluation.
The de nition of what is a graph pattern and its semantics and syntax can be
found in [
In Figure 2 we show graphically what does this approach mean for examples using the DBpedia SPARQL endpoint3. When evaluating a query with a graph pattern (?s <dbo:person> ?o), the data returned will belong to the graph <http://dbpedia.org>. Similarly, a pattern of the form (?s <wikidata:P646c> ?o) retrieves data only from graph <http://wikidata.org> in the same SPARQL endpoint. Thus would be interesting to be able to explicit this information in the query to be issued, so that the server can have more information and optimize the retrieval.
An example of how this transformation from a standard query into on which uses the GRAPH clause with this purpose is shown in the queries 1.1 and 1.2 below. The expectation is that the search space of a federated SPARQL query will be reduced and hence performance of query evaluation will improve. 3 https://dbpedia.org/sparql
Listing 1.1. Federated query SELECT WHERE f
SERVICE <S1> f GP1 g SERVICE <S2> f GP2 g
SERVICE <S3> f GP3 g g Listing 1.2. Federated query with the GRAPH clause SELECT FROM NAMED <S1 G2> FROM NAMED <S2 G3> FROM NAMED <S3 G1> WHERE f
SERVICE <S1> f
GRAPH <S1 G2> fGP1g g SERVICE <S2> f
GRAPH <S2 G3> fGP2g g SERVICE <S2> f
GRAPH <S3 G1> fGP3g g g 4
The results obtained after the experimentation re ect that a federated query that includes the GRAPH clause does not improve relevantly the performance of a federated query, as one could hypothesize. We only got an improvement in the queries evaluation time between 5% and 10%. The reason of this is that the conceptual information that a SPARQL endpoint provides about its graphs is not the same as the physical storage organization. If a query over a public SPARQL endpoint is made to list all the graphs of that SPARQL endpoint 4 https://dbpedia.org/sparql 5 https://kb.3cixty.com/sparql 6 http://data.linkedmdb.org/sparql 7 https://github.com/dachafra/federated-graph-queries and their related triples (an example of DBpedia8 is provided) conceptually the information that the user receives is that this number of triples are stored into those graphs. The reality, however, is that usually all the triples are stored in the same place and thus it does not make relevant di erence the approach we are proposing. As re ected on Virtuoso documentation9, it currently puts the triples in a single table with the graph URI as a key part although they are already working on an improvement to store triples in their graphs. Testing our approach with this future improvement of Virtuoso (or other triple store that includes this feature) could prove that including the GRAPH clause in federated SPARQL queries improves their performance. 4.1
Conclusion: The role of the GRAPH clause in SPARQL After this short experiment one could ask: What is the role of the GRAPH clause in SPARQL? We know that it is useful from a semantic point of view, that is, when a graph pattern matches triples that are saved in multiple graphs and the user only wants the triples from one of them. But we have identi ed issues that are not evident when using a GRAPH clause: (i) semantic ambiguity; (ii) o ers a view of how the data is conceptually ordered but not physically; (iii) is a SPARQL clause that seems to not allow any type of optimization.
One of the important problems related with the graphs of a SPARQL endpoint is the correctness of their characterization. When an open data portal or a controlled vocabulary is developed, the format of the URIs is highly structured. Also, only by analysing the URI itself, one usually can get some interesting information about what type of data they are storing10;11. If this feature were taken into account at the moment of building the graphs of a SPARQL endpoint, it might be useful for the users to have an idea of what type of triples are loaded in each graph. In summary, the role of the GRAPH clause needs to be clari ed in order to be really useful as a construct of the language.
The problems presented generate di erent lines for future research, such as
creating a federated benchmark that includes the SERVICE and GRAPH clauses
and do the evaluation in a controlled environment, applying our approach to
other triple stores or carrying out semantic equivalence between open data portal
and a SPARQL endpoint. It would also be very useful to develop a way for
automatically linking unique graph patterns with their pertained graphs in a
SPARQL endpoint using an index or other current solutions like Loupe[