When a FILTER Makes the Difference in Continuously Answering SPARQL Queries on Streaming and Quasi-Static Linked Data

Abstract

Abstract. We are witnessing a growing interest for Web applications that i) require to continuously combine highly dynamic data stream with background data and ii) have reactivity as key performance indicator. The Semantic Web community showed that RDF Stream Processing (RSP) is an adequate framework to develop this type of applications. However, when the background data is distributed over the Web, even RSP engines risk losing reactiveness due to the time necessary to access the background data. State-of-the-art RSP engines remain reactive using a local replica of the background data, but such a replica progressively become stale if not updated to reflect the changes in the remote background data. For this reason, recently, the RSP community investigated maintenance policies (collectively named Acqua) that guarantee reactiveness while maximising the freshness of the replica. Acqua's policies apply to queries that join a basic graph pattern in a window clause with another basic graph pattern in a service clause. In this paper, we extend the class of queries considered in Acqua adding a FILTER clause that selects mapping in the background data. We propose a new maintenance policy (namely, the Filter Update Policy) and we show how to combine it with Acqua policies. A set of experimental evaluations empirically proves the ability of the proposed polices to guarantee reactiveness while keeping the replica fresher than with the Acqua policies.

Using Rank Aggregation in Continuously Answering SPARQL Queries on Streaming and Quasi-static Linked Data

“…The operating system is Mac OS X 10.12.3 and Java 1.8.0.91 is installed on the machine. We carry out our experiments by extending the experimental setting of ACQUA.F [19] that in turn extends those presented in ACQUA [5].…”

“…ACQUA.F [19] extends the class of queries investigated by ACQUA optimizing algebraic expression SE of the following form:…”

“…In order to nd an update policy which is less sensible to selectivity and gives better results, [19] proposed a combination of the Filter Update Policy with ACQUA policies, namely the WBM.F policy and the baseline LRU.F and RND.F policies. In the maintenance process of the combined approach, rst, the proposer generates the candidate set C, then the Filtering Distance of each mapping is computed and, if the value is greater than a given Filtering Distance Threshold F DT (i.e., it falls out of a given band), the mapping is eliminated from the candidate set.…”

“…In order to investigate our hypotheses, we use the metric introduced in ACQUA.F [19]. We set up an Oracle that, at each iteration i, certainly provides correct answers Ans(Oracle i ) and we compare its answers with the possibly erroneous ones of the query Ans(Q i ).…”

“…In 2016, Zahmatkesh et al [19] extended ACQUA to optimize the class of queries that include the ltering of the intermediate results obtained from the federated SPARQL endpoint. The intuition is simple, it is useless to refresh data items that are not likely to pass the lter condition; it is better to focus on a band around the condition.…”