Der Wikidata-Knowledge-Graph erklärt: Objekte, SPARQL und Einsatz im Unternehmen

Der Wikidata-Knowledge-Graph ist der größte offen lizenzierte strukturierte Datensatz im Web: 122.983.051 Objekte, entstanden aus mehr als 2,5 Milliarden Bearbeitungen durch eine Gemeinschaft von rund 41.000 aktiven Mitwirkenden. Er steht hinter Antworten, die Sie mit großer Sicherheit schon gesehen haben, ohne es zu wissen — in Google-Infoboxen, in Siri, in Alexa.

Er ist außerdem das beste verfügbare Referenzmodell für alle, die einen eigenen Knowledge-Graph aufbauen wollen. Wikidata hat öffentlich und im großen Maßstab die meisten Probleme gelöst, auf die eine Organisation stößt, wenn sie ihr Wissen maschinenlesbar machen will: Dinge eindeutig identifizieren, die Herkunft eines Fakts festhalten, Aussagen behandeln, die nur zeitweise gelten, und das Ganze abfragbar halten.

Dieser Leitfaden erklärt, was der Wikidata-Knowledge-Graph ist, wie Objekte und Aussagen strukturiert sind, wie man ihn mit SPARQL abfragt — einschließlich der Graph-Aufteilung von 2025, die viele bestehende Abfragen zerstört hat — und was das alles für einen Enterprise-Knowledge-Graph bedeutet. Wir haben Wikibase für die Europäische Kommission ausgerollt; das ist also Gelände, das wir im Produktivbetrieb und nicht in der Theorie kennen.

Was ist ein Knowledge-Graph?

Ein Knowledge-Graph speichert Informationen als Netz von Dingen und den Beziehungen zwischen ihnen — nicht als Zeilen in Tabellen. Die Grundeinheit ist ein Tripel: Subjekt, Prädikat, Objekt.

Douglas Adams  —[ausgebildet an]→  St John's College
Douglas Adams  —[Geburtsdatum]→  1952-03-11
Douglas Adams  —[bedeutendes Werk]→  Per Anhalter durch die Galaxis

Verketten Sie genug davon, und Sie beantworten Fragen, die keine einzelne Tabelle vorgesehen hat — „welche in Cambridge ausgebildeten Autoren schrieben Science-Fiction, die für das Radio adaptiert wurde?“ — weil die Beziehungen selbst Daten sind, die man durchlaufen kann.

Knowledge-Graph und relationale Datenbank

Ein relationales Schema wird um die erwarteten Fragen herum entworfen. Eine wirklich neue Art von Beziehung hinzuzufügen bedeutet meist, Tabellen zu ändern und Abfragen neu zu schreiben. In einem Graphen ist eine neue Beziehung nur eine weitere Kante; nichts anderes muss sich ändern.

Diese Flexibilität ist der ganze Sinn. Deshalb passen Knowledge-Graphs zu unordentlichem, sich wandelndem, heterogenem Wissen — genau der Art, die die meisten Organisationen tatsächlich haben — und deshalb harmonieren sie so gut mit KI, worauf wir unten zurückkommen.

Was ist Wikidata?

Wikidata ist das Schwesterprojekt von Wikipedia für strukturierte Daten. Wo Wikipedia Prosa für Menschen enthält, enthält Wikidata Fakten für Maschinen — einmal, zentral und sprachunabhängig, wiederverwendbar durch alle Wikipedia-Ausgaben und jede externe Anwendung.

Die Größenordnung

Laut der Statistikseite von Wikidata:

• 122.983.051 Objekte — Personen, Orte, Arten, chemische Verbindungen, Werke, Ereignisse, Organisationen
• 2.533.498.484 Bearbeitungen seit dem Start
• 40.907 aktive Nutzer, die das Projekt pflegen

Zwei Dinge erklären diese Entwicklung, und beide sind es wert, übernommen zu werden. Das erste ist die Editoren-Gemeinschaft. Das zweite ist die Software darunter: Wikibase.

Wie ein Wikidata-Objekt aufgebaut ist

Jedes Objekt erhält eine opake Kennung, die mit Q beginnt, jede Eigenschaft eine mit P. Douglas Adams ist Q42; „ist ein(e)“ ist P31.

Opake Kennungen wirken unfreundlich und sind tatsächlich die wichtigste Entwurfsentscheidung des ganzen Projekts. Q42 trägt keine Sprache, keine Schreibweise, keine Annahme darüber, wie das Ding heißt. Bezeichnungen in über 300 Sprachen hängen an der Kennung; die Kennung selbst muss sich nie ändern.

Q42  (Bezeichnungen: Douglas Adams / Douglas Adams / ダグラス・アダムズ ...)
  P31  ist ein(e)          →  Q5  (Mensch)
  P106 Tätigkeit           →  Q214917 (Dramatiker)
  P569 Geburtsdatum        →  1952-03-11
         ├─ Qualifikator  P1326 spätestes Datum  →  ...
         └─ Referenz      P248 angegeben in     →  Q36578

Drei Eigenschaften dieser Form zählen weit mehr, als es zunächst scheint:

• Aussagen, keine Felder. Ein Objekt kann mehrere konkurrierende Werte für dieselbe Eigenschaft tragen, jeder mit einem Rang.
• Qualifikatoren. Kontext zu einer Aussage — gültig ab, gültig bis, für welche Jurisdiktion. Die meisten realen Fakten gelten nur unter Bedingungen.
• Referenzen. Woher die Behauptung stammt. Das unterscheidet einen prüfbaren Knowledge-Graph von einem Haufen Behauptungen.

Wenn Sie einen Enterprise-Knowledge-Graph bauen und Qualifikatoren und Referenzen weglassen, bauen Sie sie binnen eines Jahres nach. Jede Organisation muss irgendwann „wahr zu welchem Zeitpunkt?“ und „wer sagt das?“ beantworten.

Wer Wikidata tatsächlich nutzt

Suchmaschinen befüllen damit ihre Entitäts-Infoboxen. Sprachassistenten beziehen daraus faktische Antworten. Bibliotheken, Museen und Forschungseinrichtungen nutzen es als gemeinsame Normdatei, damit ihr Katalog und der einer anderen Institution sich darauf verständigen, welches „Paris“ gemeint ist. Wikidata ist zum faktischen Kennungs-Knotenpunkt des offenen Datenwebs geworden.

Wikibase: die Software hinter Wikidata

Wikidata ist eine Website. Wikibase ist die Open-Source-Softwaresuite, auf der sie läuft, gepflegt von Wikimedia Deutschland — und Sie können sie selbst betreiben.

Wikidata und Wikibase

Die Unterscheidung verwirrt, deshalb klar gesagt:

• Wikidata ist ein konkreter, öffentlicher, von einer Gemeinschaft gepflegter Knowledge-Graph.
• Wikibase ist die Software, um Knowledge-Graphs dieser Art zu bauen — auch private.

Wikibase liefert dasselbe Modell aus Objekt/Eigenschaft/Aussage/Qualifikator/Referenz, dieselben mehrsprachigen Bezeichnungen, dieselbe Versionsgeschichte und einen SPARQL-Endpunkt über Ihre eigenen Daten. Bibliotheken, Kulturinstitutionen, Forschungskonsortien und öffentliche Verwaltungen setzen es ein, gerade weil das Modell bereits bei 123 Millionen Objekten erprobt ist.

Föderation: Daten dort lassen, wo sie hingehören

Wikibase unterstützt Föderation — Ihre Instanz kann Wikidata-Kennungen referenzieren, ohne Wikidata-Inhalte zu kopieren. Sie beschreiben Ihre eigenen Entitäten in Ihrer Instanz und verweisen auf Q142, wenn Sie Frankreich meinen, statt dauerhaft eine eigene Länderliste zu pflegen.

Für alle mit Datensouveränitätspflichten ist das die entscheidende Eigenschaft: gemeinsames Vokabular, lokale Kontrolle. Ihre sensiblen Daten verlassen Ihre Infrastruktur nie und bleiben dennoch interoperabel. Es ist dasselbe Prinzip wie in was ist Private AI, angewandt auf strukturierte Daten. Siehe auch unseren Beitrag zu Wikidata als lokalem Dienst.

Den Wikidata-Knowledge-Graph mit SPARQL abfragen

Ein Graph ist nur so nützlich wie Ihre Fähigkeit, ihn zu befragen. Wikidata stellt einen öffentlichen SPARQL-Endpunkt unter query.wikidata.org bereit.

Eine erste Abfrage

Die zehn größten Städte Frankreichs, Bezeichnungen auf Französisch:

SELECT ?city ?cityLabel ?population WHERE {
  ?city wdt:P31/wdt:P279* wd:Q515 ;   # ist ein(e) (Unterklasse von) Stadt
         wdt:P17   wd:Q142 ;                # Land: Frankreich
         wdt:P1082 ?population .            # Bevoelkerung
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en" . }
}
ORDER BY DESC(?population)
LIMIT 10

Beachten Sie wdt:P31/wdt:P279*. Dieser Eigenschaftspfad bedeutet „Instanz von etwas, das transitiv eine Unterklasse von Stadt ist“ — so erfassen Sie Gemeinden, Kommunen und Metropolen, ohne sie aufzuzählen. Genau solches Durchlaufen kauft man ein, wenn man sich für einen Graphen entscheidet.

Die Aufteilung von 2025 — und warum Ihre alten Abfragen brachen

Das ist der Teil, den die meisten Tutorials noch nicht aufgeholt haben. Am 9. Mai 2025 wurde der Wikidata Query Service in zwei Graphen aufgeteilt, weil die Daten zu wissenschaftlichen Artikeln (WikiCite) auf mehr als die Hälfte aller Tripel angewachsen waren und Blazegraph nicht mehr auf das Ganze skalieren konnte.

• Hauptgraph — query.wikidata.org — alles außer wissenschaftlichen Artikeln.
• Wissenschaftsgraph — query-scholarly.wikidata.org — wissenschaftliche Artikel und zugehörige Entitäten.

Ein vollständiger Übergangs-Endpunkt existierte bis Dezember 2025 und ist inzwischen abgeschaltet. Jede Abfrage, die beide Seiten braucht, muss daher explizit SPARQL-Föderation verwenden:

SELECT ?work ?workLabel WHERE {
  # aus dem Haupt-Endpunkt in den Wissenschaftsgraphen greifen
  SERVICE <https://query-scholarly.wikidata.org/sparql> {
    ?work wdt:P50 wd:Q42 .            # Autor: Douglas Adams
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "de" . }
}

Die praktische Lehre reicht weit über Wikidata hinaus: Ein Graph, der weiter wächst, erzwingt irgendwann Architekturentscheidungen zu Partitionierung und Föderation. Planen Sie dafür, bevor es dringend wird.

Die Wikidata-API

SPARQL dient Fragen nach Mustern. Wenn Sie bereits wissen, welche Entität Sie wollen, sind die REST- und Action-APIs einfacher und günstiger — Q42 abrufen, Bezeichnungen und Aussagen lesen, fertig. Grobe Regel: API zum Nachschlagen, SPARQL zum Entdecken. Beide sind kostenlos und ratenbegrenzt, cachen Sie im Produktivbetrieb also konsequent.

Von Wikidata zum Enterprise-Knowledge-Graph

Die meisten Organisationen haben dasselbe Grundproblem, das Wikidata lösen wollte: dieselbe Entität — ein Kunde, ein Produkt, eine Vorschrift, ein Standort — in einem Dutzend Systemen unterschiedlich beschrieben, ohne gemeinsame Kennung und ohne Herkunftsnachweis.

Warum Organisationen einen aufbauen

• Eine Identität pro Ding. Eine stabile interne Kennung, die Umbenennungen und Reorganisationen übersteht.
• Fragen über Silos hinweg. CRM, ERP und Dokumentation verbinden, ohne pro Frage ein Warehouse-Projekt.
• Herkunft von Anfang an. Jeder Fakt trägt seine Quelle — das macht ihn prüfbar.
• Grounding für KI. Ein kuratierter Graph ist ein viel besseres Substrat für einen Assistenten als ein Ordner voller PDFs.

Vier Lehren, die Wikidata schon bezahlt hat

1. Opake Kennungen verwenden. Alles Menschenlesbare wird falsch, sobald etwas umbenannt wird.
2. Aussagen modellieren, keine Felder. Konkurrierende Werte mit Rängen zulassen; die Realität ist selten eindeutig.
3. Referenzen früh verpflichtend machen. Herkunft nachträglich auf Millionen Fakten aufzusetzen ist brutal.
4. Mit Partitionierung rechnen. Die Aufteilung von 2025 ist, wie Erfolg im großen Maßstab aussieht.

Knowledge-Graphs und LLMs: warum sie zusammenpassen

Sprachmodelle sind stark bei Sprache und unzuverlässig beim Abruf. Knowledge-Graphs sind das Gegenteil: präzise, strukturiert, überprüfbar und unfähig zum Gespräch. Beides zusammen deckt jeweils die Schwäche des anderen ab.

Grounding: der Graph liefert die Fakten

Anstatt das Modell erinnern zu lassen, ruft man die relevanten Fakten aus dem Graphen ab und lässt es daraus antworten, mit angehängter Quelle. Dieser Wechsel — vom Erinnern zum Lesen — ist der größte Hebel für KI-Zuverlässigkeit, wie wir in wie zuverlässig ist ChatGPT darlegen. Ein Graph verstärkt das noch, weil ein abgerufenes Tripel eindeutig ist, wo ein abgerufener Absatz es nicht ist.

Von natürlicher Sprache zu SPARQL

Die andere Richtung ist genauso nützlich: das Modell schreibt die Abfrage. Ein Nutzer stellt seine Frage in Alltagssprache, das System erzeugt SPARQL, führt es gegen den Graphen aus und antwortet aus echten Ergebnissen. Der Nutzer muss weder P31 noch Q515 kennen, und die Antwort wird berechnet statt erinnert.

Genau dieses Problem sollte QAnswer ursprünglich lösen — und darum behandeln unsere KI-Assistenten und APIs strukturierte Quellen gleichrangig mit Dokumenten.

Unsere Arbeit mit Wikidata und Wikibase

Wir kommentieren dieses Thema nicht nur. Wir haben eine Wikibase-Instanz für die Europäische Kommission ausgerollt und verschiedene Datenquellen darin zusammengeführt — daraus entstand ein öffentlicher EU-Knowledge-Graph über europäische Linked Open Data.

Außerdem haben wir WikidataComplete gebaut: Es nutzt KI, um Wikidata neue Aussagen aus unstrukturiertem Text vorzuschlagen, und legt jede einzelne einem menschlichen Editor zur Freigabe vor — KI findet Faktkandidaten, die Gemeinschaft entscheidet. Und wir verbinden Assistenten direkt mit MediaWiki- und Wikibase-Instanzen, sodass das eigene Wiki einer Organisation zur Quelle wird, aus der ein Assistent mit Quellenangabe antworten kann.

Wenn Sie sehen möchten, wie ein Graph plus Assistent auf Ihren eigenen Inhalten aussieht: dieselbe Maschinerie steht über unsere Integrationen bereit — On-Premise oder in einer Private Cloud, was im öffentlichen Sektor und in regulierten Umgebungen meist die Anforderung ist, die alles Weitere entscheidet. Siehe Datensouveränität.

Häufige Fragen

Was ist der Wikidata-Knowledge-Graph?

Ein freier, gemeinschaftlich bearbeiteter Knowledge-Graph mit 122.983.051 Objekten, der Fakten als strukturierte Aussagen mit Qualifikatoren und Referenzen speichert statt als Prosa. Er ist per SPARQL abfragbar und wird weltweit von Suchmaschinen, Sprachassistenten und Kulturinstitutionen wiederverwendet.

Wie groß ist Wikidata?

122.983.051 Objekte, entstanden aus über 2,53 Milliarden Bearbeitungen von etwa 40.900 aktiven Nutzern, laut der Statistikseite von Wikidata. Allein die Daten zu wissenschaftlichen Artikeln wuchsen auf mehr als die Hälfte aller Tripel — das erzwang 2025 die Aufteilung des Abfragedienstes.

Was ist der Unterschied zwischen Wikidata und Wikibase?

Wikidata ist ein öffentlicher Knowledge-Graph. Wikibase ist die Open-Source-Software, auf der er läuft und die jeder einsetzen kann, um einen eigenen aufzubauen — öffentlich oder vollständig privat.

Ist Wikidata ein Knowledge-Graph oder eine Datenbank?

In gewisser Weise beides: Es liegt in einer Datenbank und ist als Graph modelliert. Zum Knowledge-Graph macht es die Form — Entitäten, verbunden durch typisierte Beziehungen, mit Herkunft an den Aussagen — nicht die Speichertechnologie.

Wie frage ich Wikidata ab?

Für musterbasierte Fragen SPARQL unter query.wikidata.org, für bereits bekannte Entitäten die REST- und Action-APIs. Seit Mai 2025 brauchen Abfragen über Haupt- und Wissenschaftsgraph hinweg SPARQL-Föderation.

Warum wurde der Wikidata Query Service in zwei Graphen aufgeteilt?

Die Daten zu wissenschaftlichen Artikeln waren über die Hälfte aller Tripel hinausgewachsen und das Blazegraph-Backend konnte nicht mehr auf den vollen Datensatz skalieren. Seit dem 9. Mai 2025 wird der Hauptgraph unter query.wikidata.org und der Wissenschaftsgraph unter query-scholarly.wikidata.org ausgeliefert; der vollständige Übergangs-Endpunkt wurde Ende 2025 abgeschaltet.

Kann ich einen privaten Knowledge-Graph wie Wikidata aufbauen?

Ja — genau dafür ist Wikibase gedacht. Sie erhalten dasselbe Datenmodell und einen SPARQL-Endpunkt über Ihre eigenen Inhalte, können für gemeinsame Konzepte mit Wikidata-Kennungen föderieren und alles in Ihrer eigenen Infrastruktur betreiben.

Wie verbessern Knowledge-Graphs KI-Antworten?

Sie geben dem Modell überprüfbare Fakten, statt es erinnern zu lassen. Abgerufene Tripel sind eindeutig und tragen ihre Herkunft, Antworten lassen sich also auf eine Quelle zurückführen — und das Modell kann SPARQL erzeugen, damit Nutzer den Graphen in Alltagssprache abfragen.

Wo anfangen

Der Wikidata-Knowledge-Graph lohnt in zweifacher Hinsicht: als größter offener strukturierter Datensatz, auf dem man kostenlos aufbauen kann, und als funktionierendes Referenzdesign für einen eigenen Graphen. Die Disziplin bei Kennungen, das Aussagenmodell, das Beharren auf Referenzen — das sind die Teile, die man kopieren sollte.

Und sobald der Graph existiert, ist ein KI-Assistent darauf kein plausibel klingender Textgenerator mehr, sondern etwas, das aus Fakten antwortet, auf die Sie zeigen können.

‍

Bauen Sie mit QAnswer einen KI-Assistenten über Ihrem eigenen Wissen — Dokumente, Wikis oder Knowledge-Graphs. Entdecken Sie unsere KI-Assistenten, unsere MediaWiki-Integration und die vollständige Liste unserer Integrationen.

Mehr Informationen unter www.qanswer.ai

Arbeiten Sie an einem Knowledge-Graph-Projekt? Kontaktieren Sie uns oder schreiben Sie an info@the-qa-company.com