The Triple Pattern Fragments (TPF) interface demonstrates how it is possible to publish Linked Data at low-cost while preserving data availability. But, data providers hosting TPF servers are not able to analyze the SPARQL queries they execute because they only receive and evaluate subqueries with one triple pattern. Understanding the executed SPARQL queries is important for data providers for prefetching, benchmarking, auditing, etc. We propose SWEEP, a streaming web service that deduces Basic Graph Patterns (BGPs) of SPARQL queries from a TPF server log. We show that SWEEP is capable of extracting BGPs of SPARQL queries evaluated by a DBpedia's TPF server.
The Triple Pattern Fragments (TPF) interface demonstrates how it is possible to
publish Linked Data at low-cost while preserving data availability [
Understanding the executed SPARQL queries is fundamental for data
providers. Mining logs of SPARQL endpoints allows to detect recurrent patterns in
queries for prefetching [
[
In this demonstration, we present SWEEP, a streaming web service that is able to extract BGPs from logs of TPF servers in real-time. From the stream of single triple pattern queries of a TPF server, SWEEP is capable of extracting BGPs. This allows data providers running TPF servers to better know how their data are used. The demonstration highlights the performances of SWEEP in terms of precision and recall.
In Figure 1, two clients, c1 and c2, execute concurrently queries Q1 and Q2 over the DBpedia’s TPF server. Q1 asks for movies starring Brad Pitt and Q2 for movies starring Natalie Portman.1 Both queries have one BGP composed of several triple patterns (tpn).
c1(173.28.19.114) : Query Q1 SELECT ?movie ?title ?name WHERE { ?movie dbpedia-owl:starring ?actor . ?actor rdfs:label "Brad Pitt"@en . ?movie rdfs:label ?title . ?movie dbpedia-owl:director ?director . ?director rdfs:label ?name FILTER LANGMATCHES(LANG(?title), "EN") FILTER LANGMATCHES(LANG(?name), "EN") } ?predicate = rdfs : label & ?object = “Brad P itt”@en . . .
(tp1) (tp2) (tp3) (tp4) (tp5)
c2(173.28.19.114) : Query Q2 SELECT ?titleEng ?title WHERE { ?movie dbpprop : starring ?actor . ?actor rdfs : label ”Natalie P ortman”@en . ?movie rdfs : label ?titleEng . ?movie rdfs : label ?title FILTER LANGMATCHES(LANG(?titleEng), "EN") FILTER (!LANGMATCHES(LANG(?title), "EN")) (tp01) (tp02) (tp03) (tp04)
} ?predicate = rdfs : label & ?object = “Natalie P ortman”@en . . .
DBpedia’s TPF server
The TPF client decomposes the SPARQL queries into a sequence of triple pattern queries partially presented in Table 1. The odd-numbered lines represent received triple pattern queries and the even-numbered ones represent sent triples after evaluation on the RDF graph. Lines 1 and 3, correspond to triple pattern queries for tp2 and tp1 of Q1.2 We can observe that the object in Line 3, comes from a mapping seen in Line 2. This injection of a mapping obtained from a previous triple pattern query, is clearly a bind join from tp2 towards tp1.
As the TPF server only sees triple pattern queries, the original queries are unknown to the data provider. In this work, we address the following research question: Can we extract BGPs from a TPF server log?
The main challenge is to distinguish similar queries, that is queries whose
triple patterns are the same for the TPF server as tp1 vs tp01. In our example,
we aim to extract two BGPs from the TPF server log, one corresponding to
Q1, BGP[
SWEEP uses a TPF server log, as the one of Table 1, composed of an unlimited ordered sequence of execution traces organized by IP-address. It considers a fixed-size window sliding over the TPF server log. Window size can depend on the memory available for the streamed log or on the average of known values used as timeout by TPF clients.
We consider a set G of deduced BPGs. Each time a triple pattern query (tpqi) arrives, SWEEP creates a new BP Gj 2 G or updates an existing one.
Suppose G is empty and SWEEP receives tpq1 ={?s p2 toto} where ?s produces 2 mappings: {c1, c2}. As G is empty, SWEEP creates BGP1 containing tpq1 with the current time as timestamp, BGP1.ts = time().
Then, if tpq2 ={c1 p1 ?o} arrives, as c1 appears in mappings of a BGPj 2 G, SWEEP detects a bind join. This implies updating BGP1 with the join {?s p2 toto . ?s p1 ?o}. If tpq3 = {c2 p1 ?o} arrives, as it is already represented in BGP1, nothing is done.
If BGP1 is out the window, i.e., time() BGP1.ts > window, then it must no longer be updated; it is delivered and removed from the stream.
We run SWEEP with queries proposed by the TPF web client (http:// client.linkeddatafragments.org/). From 21 queries executed, we obtained 100% of precision and 87% of recall of deduced BGPs when compared to the BGPs of corresponding original queries. SWEEP succeeds in this case because these queries are note very similar. Different precision and recall would be produced with a more challenging set of queries. 4
SWEEP demonstrates how it is possible to deduce the BGPs executed by a TPF server. This allows data providers to have a better understanding of the usage of their data.
With SWEEP it would be possible to detect whether clients are executing federated queries over multiple datasets hosted by one TPF server. And if multiple data providers agree on streaming their logs to a shared SWEEP service, they would be able to detect federated queries executed over multiple TPF servers.