Slides from talk at the DBpedia Community Meeting in Leipzig, 2014

1. Live DBpedia querying
with high availability
Ruben Verborgh

2. “If DBpedia goes down, nobody complains.
If the BBC Linked Data Platform goes down,
that’s a problem for live applications.”
Don’t we want live applications
on top of DBpedia?
It’s a vicious cycle:
no apps because downtime,
downtime acceptable because no apps.

3. Despite all traffic it receives,
DBpedia has an uptime of around 95%,
making it one of the more reliable endpoints.
DBpedia is unavailable
for 1.5 days each month.

4. Public endpoints like DBpedia
are hosted voluntarily,
as-is and free of charge.
Since DBpedia is hosted for free,
we should not complain too hard
when it is unavailable.

5. The majority of the information
on the Web is hosted voluntarily,
as-is and free of charge.
Wouldn’t we complain
if that information was unavailable
for 1.5 days a month?

6. There’s a difference!
DBpedia offers a SPARQL interface,
which is much more expensive than HTTP.

7. Exactly.
If DBpedia offers information
as-is and free of charge,
why choose such an expensive interface?
Why does it commit itself to
such a strong engagement?
(The BBC doesn’t do it!)

8. Why offer to answer complex queries
if you cannot reliably answer simple ones?

9. SELECT * { ?s ?p ?o } LIMIT 1

10. What other interfaces
to RDF are available?
low server demand high server demand
data
dump
SPARQL
endpoint
derefer-encing
Triple Pattern
Fragments

12. A triple pattern fragments interface
is much less powerful than SPARQL.
So also much less demanding,
like other HTTP interfaces.
Servers of triple pattern fragments
have very high availability.

13. How do we handle complex queries?
Clients execute them!
SELECT ?person ?city WHERE {
?person a dbpedia-owl:Artist.
dbpedia-owl:birthPlace ?city.
?city foaf:name "York"@en.
}
2–3 seconds

14. data processing
server

15. data processing
server client

16. Server CPU usage remains low.
1 10 100
100
50
0
clients
Fig. 3.3: Query timeouts
10 100
100
50
0
clients
Fig. 3.5: Server processor usage per core
100
1 client 100 clients

17. 1 10 100
0
clients
Fig. 3.2: Server network traffic
1 10 100
20
10
0
clients
Fig. 3.4: Cache network traffic
8
6
Cache reuse becomes very high.
1 client 100 clients

18. Don’t build intelligent servers,
because scaling them is expensive.
Build servers that
enable clients to be intelligent.

19. By offering a much simpler interface,
DBpedia can be available like all sites.
This lets us build Web applications
on top of live DBpedia data.
Let’s make simple things work reliably,
then worry about the complex.

20. Live DBpedia querying
with high availability
Ruben Verborgh