DBpedia is a knowledge graph built by extracting structured data out of Wikipedia and republishing it as RDF with dereferenceable URIs and a public SPARQL endpoint. It began in 2007 as a research project at Freie Universität Berlin, the University of Leipzig and OpenLink Software, and it was the original hub of the linked open data cloud. Nobody edits DBpedia directly: the data changes when Wikipedia changes, which is the single fact that explains most of its strengths and all of its quirks.

Where the data comes from

Wikipedia articles carry infoboxes, the tables of key-value facts in the top right corner of a page. The DBpedia extraction framework parses those infoboxes, along with article titles, abstracts, categories, internal links, external links, coordinates and images, and turns each fact into a triple. An article at en.wikipedia.org/wiki/Marie_Curie becomes a resource at http://dbpedia.org/resource/Marie_Curie, and its infobox rows become statements about that resource.

Extraction is not translation. An infobox is written for human readers, so its values are inconsistent: a birth date may be a template, a plain string or a footnoted range, and a “location” row may hold a city, a country or both. DBpedia handles this in two layers.

The raw infobox extraction produces one property per infobox key, in the http://dbpedia.org/property/ namespace, conventionally abbreviated dbp:. These properties are numerous, untyped and messy, because they mirror whatever editors wrote.

The mapping-based extraction uses community-maintained mappings that say which infobox templates and keys correspond to which ontology class and property. Its output lands in http://dbpedia.org/ontology/, abbreviated dbo:, and is typed and consistent. A query should reach for dbo: first and fall back to dbp: only when the mapped property has no coverage for the case at hand.

Releases come in several shapes. Periodic snapshot releases are the citable, stable datasets; the DBpedia Databus distributes the files; DBpedia Live tracked Wikipedia edits continuously; and language chapters publish extractions of other Wikipedia editions with their own endpoints. Because the pipeline depends on Wikipedia’s markup, coverage and freshness both vary by release and by language edition, and a fact absent from DBpedia is often a fact that was never in an infobox rather than a fact that is untrue.

The DBpedia ontology and its three namespaces

Three prefixes carry almost all DBpedia work, and confusing them is the usual first mistake.

Prefix	Namespace	Holds
dbr:	http://dbpedia.org/resource/	The things: dbr:Marie_Curie, dbr:Florida
dbo:	http://dbpedia.org/ontology/	Ontology classes and mapped properties: dbo:University, dbo:birthPlace
dbp:	http://dbpedia.org/property/	Raw, unmapped infobox properties

The DBpedia ontology itself is a hand-built cross-domain ontology with a shallow class hierarchy rooted at owl:Thing: dbo:Person, dbo:Place, dbo:Organisation, dbo:Work, dbo:Species and their subclasses such as dbo:University, dbo:Settlement and dbo:Film. Unlike Wikidata, class membership is asserted with rdf:type and the hierarchy is small enough that a direct type test usually works, so the transitive subclass path that Wikidata queries need is rarely necessary here.

Resources also carry owl:sameAs links to the corresponding Wikidata item, to other DBpedia language chapters and to external datasets. Those links are what make DBpedia useful as a crosswalk, and they are a textbook case of the fourth linked data principle.

Querying the public endpoint

The endpoint is https://dbpedia.org/sparql, with a query form in a browser at the same address. It runs on Virtuoso rather than Blazegraph, which changes three things compared with the Wikidata Query Service.

Declare every prefix. Nothing beyond the SPARQL defaults can be relied on, so dbo:, dbr:, dbp:, rdfs:, owl: and foaf: all need a PREFIX line. A query copied from a Wikidata example will fail here for that reason alone.

Expect a row cap, and expect to wait. Virtuoso applies a maximum result set size and a query timeout, and a query that exceeds either returns a truncated or partial result. Put an explicit LIMIT on anything broad and page with OFFSET over a stable ORDER BY. The public endpoint is also shared and unpredictable under load: a bound-subject lookup returns in a second or two, while the class-wide queries below have taken anywhere from ten seconds to over a minute. Anything that has to be fast, or has to run on a schedule, belongs on a local copy loaded from the DBpedia dumps rather than on the public endpoint.

Do not rely on dbo:abstract, and do not assume rdfs:comment either. Neither is served for every resource. The public endpoint returns no dbo:abstract and no rdfs:comment at all for dbr:University_of_Florida, for example, but it does return 24 language variants of dbo:description. Ask for dbo:description first, wrap any textual property in OPTIONAL with a language filter, and check what a resource actually carries before building a query around it.

Virtuoso also offers a non-standard full-text predicate, bif:contains, which is faster than a FILTER over string functions on large result sets. It is a Virtuoso extension rather than SPARQL, so a query using it is not portable.

What one resource says about itself. Bound subject, so the query is a few index lookups. The filter keeps only ontology classes and discards the Wikidata, YAGO and schema.org types that DBpedia also asserts.

PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX dbr:  <http://dbpedia.org/resource/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?class ?description WHERE {
  dbr:University_of_Florida a ?class .
  FILTER (STRSTARTS(STR(?class), "http://dbpedia.org/ontology/"))
  OPTIONAL {
    dbr:University_of_Florida dbo:description ?description .
    FILTER (LANG(?description) = "en")
  }
}
LIMIT 50

The result is one row: dbo:University. That is worth noting, because it is the whole difference between DBpedia’s typing and Wikidata’s. DBpedia asserts the mapped ontology class and the endpoint does not materialize its superclasses, so a single a dbo:University pattern is enough here, where the equivalent Wikidata query needs wdt:P31/wdt:P279*. The tradeoff is that DBpedia’s class assignment is only as good as the infobox mapping that produced it.

Instances of a class in a place, across both namespaces. This is the query that shows why dbp: still matters: mapping coverage for a given infobox key is never complete, so a UNION across the mapped and raw properties returns more than either alone.

PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX dbp:  <http://dbpedia.org/property/>
PREFIX dbr:  <http://dbpedia.org/resource/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?uni ?name WHERE {
  ?uni a dbo:University .
  { ?uni dbo:state dbr:Florida } UNION { ?uni dbp:state dbr:Florida }
  OPTIONAL {
    ?uni rdfs:label ?name .
    FILTER (LANG(?name) = "en")
  }
}
ORDER BY ?name
LIMIT 200

Filtering labels within a bounded class. CONTAINS and REGEX are standard but they scan, so they need a selective pattern in front of them. ?uni a dbo:University supplies the anchor.

PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?uni ?name WHERE {
  ?uni a dbo:University ;
       rdfs:label ?name .
  FILTER (LANG(?name) = "en" && CONTAINS(?name, "Polytechnic"))
}
ORDER BY ?name
LIMIT 100

DISTINCT is not decoration. The public endpoint serves some triples from more than one graph, so the same resource and label pair comes back twice without it. CONTAINS is also case-sensitive and matches substrings anywhere in the label, so “Polytechnic” finds “Faridpur Government Polytechnic Institute” but not “polytechnic”.

Crosswalking to Wikidata. One owl:sameAs pattern with a filter on the target namespace converts a DBpedia resource into a Q-ID, which is how a DBpedia result set gets joined to Wikidata statements.

PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>

SELECT ?wikidata WHERE {
  dbr:Marie_Curie owl:sameAs ?wikidata .
  FILTER (STRSTARTS(STR(?wikidata), "http://www.wikidata.org/entity/"))
}

Calling the endpoint from a script. Virtuoso accepts a format parameter as well as the Accept header, and the two agree in the call below so either path returns JSON.

curl -s -G "https://dbpedia.org/sparql" \
  -H "Accept: application/sparql-results+json" \
  --data-urlencode "format=application/sparql-results+json" \
  --data-urlencode 'query=PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?person WHERE { ?person dbo:birthPlace dbr:Warsaw } LIMIT 10'

Individual resources are also dereferenceable, so curl -L -H "Accept: text/turtle" http://dbpedia.org/resource/Marie_Curie returns every triple about her without any SPARQL at all. That is the closest thing DBpedia has to a per-entity REST API.

DBpedia Spotlight

DBpedia Spotlight is a separate open-source service that performs entity linking against DBpedia. Given a block of text, it spots mentions of things and returns the DBpedia resource each mention refers to, which is the step that turns unstructured prose into graph references.

curl -s -G "https://api.dbpedia-spotlight.org/en/annotate" \
  -H "Accept: application/json" \
  --data-urlencode "text=Marie Curie won the Nobel Prize in Physics while working in Paris." \
  --data-urlencode "confidence=0.5"

The JSON response includes a list of spotted resources, each with the linked URI, the matched surface form, its character offset in the input, a support figure showing how many pages link to the resource, its types, and a similarity score. Raising confidence returns fewer and safer links; lowering it returns more and noisier ones. Because Spotlight resolves to DBpedia URIs and DBpedia carries owl:sameAs to Wikidata, a Spotlight annotation is one hop away from a Q-ID.

Spotlight can be self-hosted with a language model per language, which is the usual choice for production, since the public demonstration service carries no availability guarantee.

DBpedia compared with Wikidata

	DBpedia	Wikidata
Origin of data	Extracted from Wikipedia infoboxes and article text	Edited directly by people and bots
Fixing an error	Edit the Wikipedia article or the mapping	Edit the item
Identifiers	Readable, title-derived URIs	Opaque Q-IDs
Class membership	rdf:type against a shallow ontology	wdt:P31 plus a deep wdt:P279 hierarchy
Statement context	Flat triples	Qualifiers, references and ranks
Licence	CC BY-SA	CC0
Backend	Virtuoso	Blazegraph

Neither replaces the other. DBpedia’s readable URIs and flat triples make it pleasant to query and easy to demonstrate, and its abstracts and internal-link graph carry information Wikidata does not model at all. Wikidata’s referenced, qualified statements and its stable identifiers make it the better source of record, which is why it displaced DBpedia as the centre of the linked data cloud. Where a project needs both, owl:sameAs is the join.

For developers

Two practices prevent most surprises. Pin to a snapshot release when reproducibility matters, because the public endpoint moves and a query run twice can return different rows. And treat dbp: values as strings that happen to look structured: the same infobox key can yield an IRI in one article and a plain literal in another, so parse defensively or filter on isIRI().

For heavy or repeated work, download the relevant extraction files from the Databus and load them into a local store rather than querying the shared endpoint in a loop. Only load the subsets you need; the full extraction is large, and most projects need a handful of files. On the query side, keep the selective pattern first, anchor every property path, and remember that Virtuoso will truncate rather than fail, so a result set at exactly the row cap is a warning and not an answer. Wider construction advice sits at building a knowledge graph in Python and the language itself at RDF.

For SEOs

DBpedia is worth knowing for two reasons, and neither is a ranking factor. First, it is a machine-readable view of what Wikipedia’s infoboxes say about an entity, which makes it a fast way to audit that record. Query an organization’s resource and the result shows which facts are extractable, which are missing, and which are wrong; when something is wrong, the fix is in the Wikipedia article or the mapping, never in DBpedia. Second, it is a usable sameAs and reconciliation target: a DBpedia URI identifies the same entity as the Wikipedia article and links onward to the Wikidata Q-ID, which is the identifier most worth carrying in markup. See the sameAs schema for the markup and what an entity is.

What DBpedia is not is a route into the Google Knowledge Graph. Google builds its own graph and reconciles it against many sources; no documented mechanism lets a DBpedia resource influence it. Anyone treating DBpedia presence as an entity SEO deliverable is selling a side effect of having a Wikipedia article.

Related pages

• Wikidata
• Wikidata Query Service
• SPARQL
• Linked data
• Entity linking, NER and extraction
• Knowledge graph examples

FAQ

What is DBpedia?

DBpedia is a knowledge graph created by extracting structured data from Wikipedia, mainly from infoboxes, and publishing it as RDF with dereferenceable URIs and a public SPARQL endpoint at dbpedia.org/sparql. You can’t edit it directly; its content changes when the underlying Wikipedia articles or the community extraction mappings change.

What is the difference between DBpedia and Wikidata?

DBpedia is extracted automatically from Wikipedia, so it inherits Wikipedia’s content and its inconsistencies, and it uses readable title-based URIs. Wikidata is edited directly, uses opaque Q-IDs, and records qualifiers, references, and ranks on each statement. Wikidata is the better source of record; DBpedia is often easier to query and links to Wikidata with owl:sameAs.

What is the difference between dbo: and dbp: in DBpedia?

The dbo: namespace holds the DBpedia ontology: typed classes and properties produced by community mappings, which are consistent and should be preferred. The dbp: namespace holds raw infobox properties, one per infobox key, untyped and inconsistent. Mapping coverage is incomplete, so a query sometimes needs a UNION across both namespaces to be complete.

What is DBpedia Spotlight used for?

DBpedia Spotlight is an entity linking service. Given a block of text, it finds mentions of things and returns the DBpedia resource each mention refers to, with a confidence setting that trades recall against precision. It is used to annotate documents, build entity indexes over a content archive, and as a first step toward Wikidata Q-IDs via owl:sameAs.

Sources and further reading

• DBpedia: https://www.dbpedia.org/
• DBpedia public SPARQL endpoint: https://dbpedia.org/sparql
• DBpedia ontology and mappings wiki: https://mappings.dbpedia.org/
• DBpedia Spotlight: https://www.dbpedia-spotlight.org/
• DBpedia Databus: https://databus.dbpedia.org/
• W3C, SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/