Challenges of Source Selection in the WoD

Abstract

Federated querying, the idea to execute queries over several distributed knowledge bases, lies at the core of the semantic web vision. To accommodate this vision, SPARQL provides the SERVICE keyword that allows one to allocate sub-queries to servers. In many cases, however, data may be available from multiple sources resulting in a combinatorially growing number of alternative allocations of subqueries to sources. Running a federated query on all possible sources might not be very lucrative from a user's point of view if extensive execution times or fees are involved in accessing the sources' data. To address this shortcoming, federated join-cardinality approximation techniques have been proposed to narrow down the number of possible allocations to a few most promising (or results-yielding) ones. In this paper, we analyze the usefulness of cardinality approximation for source selection. We compare both the runtime and accuracy of Bloom Filters empirically and elaborate on their suitability and limitations for different kind of queries. As we show, the performance of cardinality approximations of federated SPARQL queries degenerates when applied to queries with multiple joins of low selectivity. We generalize our results analytically to any estimation technique exhibiting false positives. These findings argue for a renewed effort to find novel join-cardinality approximation techniques or a change of paradigm in query execution to settings, where such estimations play a less important role.

FedMark: A Marketplace for Federated Data on the Web

“…In particular, the marketplace would have to estimate how many triples have to be accessed to calculate the price of a specific allocation prior to query execution. However, as we have shown in [15], such estimations can be very unreliable. A high discrepancy between estimated price and actual price can be very devastating for such a marketplace.…”

“…This decision, in turn, depends on how much the bought data can contribute to a specific query. As we showed in [15], it is very difficult to decide before query execution how much a certain source can contribute to a query answer. However, after query execution it is too late to decide against the inclusion of some sources, as the data is already bought.…”

Monetization Strategies for the Web of Data

“…Hence, a customer might either waste money on triples which do not join or miss a part of the query answer because some triples were not bought. As we have shown in [8], join estimation techniques are suffering a lot from false-positive matches in the WoD setting and hence, we cannot expect that a customer would be able to use such techniques to buy exactly those triples which are needed to form a specific query answer. Only a query execution can reveal the true contribution and value of the publishers' triples.…”

Services for connecting and integrating big number of linked datasets

“…Afterwards, the federated query processing contains the following steps: "Query Parsing, Data Source Selection, Query Optimization and Query Execution". Query Parsing is the process of parsing and transforming a given query expressed by using SPARQL query language into a query execution tree [186], while Data Source Selection is used for finding the relevant datasets (i.e., SPARQL endpoints) for a triple (or a set of triples) pattern of a given SPARQL query [108]. By having selected the datasets for a given query, Query Optimization process starts for placing the triple patterns into groups, and it is used for determining in an efficient way the order of joins and triple patterns.…”

“…As regards Catalog/index-free approaches, FedX [223] system sends one SPARQL ASK query per triple pattern to the federated datasets' endpoints for detecting relevant datasets, e.g., for a triple pattern {?s foaf:name ?name}, it send the following query to each dataset D i : "ASK {?s foaf:name ?name}", which returns true if D i contains triples with this property. Finally, for decreasing the execution time of source selection task, query approximation techniques have been proposed [108].…”