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?
10. What other interfaces
to RDF are available?
low server demand high server demand
data
dump
SPARQL
endpoint
derefer-encing
Triple Pattern
Fragments
11.
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
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.