0.25
0.5
0.75
1.25
1.5
1.75
2
Opportunistic Linked Data Querying through Approximate Membership Metadata
Published on Nov 10, 20151647 Views
Between uri dereferencing and the sparql protocol lies a largely unexplored axis of possible interfaces to Linked Data, each with its own combination of trade-offs. One of these interfaces is Triple
Related categories
Chapter list
Opportunistic Linked Data Querying through Approximate Membership Metadata00:00
Confucius, 431 BC00:03
Teach a client to SPARQL, and it’ll query happily ever after.00:09
Querying through Approximate Membership Metadata00:26
Linked Data Fragments: a uniform view on publishing Linked Data00:54
Interface Offered by the Server00:55
Interaction between client & server01:24
Linked Data Fragments - 101:52
Linked Data Fragments - 202:02
Each type of Linked Data Fragment - 102:10
Each type of Linked Data Fragment - 202:27
Each type of Linked Data Fragment - 302:46
Exploring the axis: selector and metadata03:04
Exploring the axis03:12
T riple Pattern Fragments03:19
DBpedia - Linked Data Fragments - 103:39
DBpedia - Linked Data Fragments - 203:43
DBpedia - Linked Data Fragments - 303:51
DBpedia - Linked Data Fragments - 403:55
Triple pattern fragment servers - 104:01
Triple pattern fragment servers - 204:09
How can intelligent clients solve SPARQL queries over fragments? - 104:13
How can intelligent clients solve SPARQL queries over fragments? - 204:19
How can intelligent clients solve SPARQL queries over fragments? - 304:25
The client splits the query into the available fragments04:32
The client gets the fragments and inspects their metadata - 104:39
The client gets the fragments and inspects their metadata - 204:42
The metadata enables the client to choose the right starting point - 1 04:46
The metadata enables the client to choose the right starting point - 204:54
For some patterns, many requests are of type “is this triple in the dataset?”05:06
Advancing in selector and/or metadata dimensions - 105:54
Advancing in selector and/or metadata dimensions - 206:25
Advancing in selector and/or metadata dimensions - 306:43
Approximate Membership Metadata06:57
Append TPF response with a compact representation of all possible mappings - 106:58
Append TPF response with a compact representation of all possible mappings - 207:15
Append TPF response with a compact representation of all possible mappings - 307:24
The questions that we asks ourselves07:44
Bloom Filter - 108:01
Bloom Filter - 208:09
Bloom Filter - 308:13
Bloom Filter - 408:18
Bloom Filter - 508:47
Bloom Filter - 608:53
Bloom Filter - 708:57
Bloom Filter - 808:59
Bloom Filter - 909:04
Server enables clients to avoid membership requests09:16
Client filters non-members locally with one extra (cached) request - 109:40
Client filters non-members locally with one extra (cached) request - 209:58
Client filters non-members locally with one extra (cached) request - 410:03
We evaluated for request count, server cost and speedup in a Web setting - 110:11
We evaluated for request count, server cost and speedup in a Web setting - 210:42
> 50% of the queries has fewer requests11:05
Queries with relatively many HTTP req. (45,000+ / query) benefit greatly11:54
No queries have reduction in execution time, a third even has increase12:42
Server remains low-cost, as impact is very acceptable (< 6%)13:24
Opportunistic Querying13:43
During execution, a result candidate could already be correct (1 - p)13:49
Can we be opportunistic here, and temporarily allow imprecise results?13:59
Execution Time14:08
Can we reduce the time to 100% recall?14:28
Temporarily allowing <100% precision can reduce 100% recall time with 1/314:33
Conclusion15:02
Approximate Membership Metadata is a nuanced debate - 115:03
Approximate Membership Metadata is a nuanced debate - 215:22
Approximate Membership Metadata is a nuanced debate - 315:37
No one size fits all, explore the axis15:44
Find metrics that fit your use-case16:46
Thank you16:52