Wikidata:Datenzugriff

Wikidata für Entwickler: Datenzugriff

---

Wikidata enthält derzeit über 110 Millionen Datensätze und über 1,3 Millionen Lexeme, und diese Zahlen werden weiter wachsen. Es gibt viele Methoden, um auf all diese Daten zuzugreifen – dieses Dokument stellt sie vor und hilft potenziellen Nutzern, die beste Methode für ihre Bedürfnisse zu wählen.

Es ist wichtig, eine Zugriffsmethode zu wählen, die Dir die benötigten Daten auf dem schnellsten und effizientesten Weg liefert, ohne Wikidata unnötig zu belasten; diese Seite soll Dir dabei helfen.

Wikidata bietet eine große Bandbreite an allgemeinen Daten über alles unter der Sonne. Die Daten sind unter CC0, "No rights reserved", für Public Domain lizenziert.

Änderungen an APIs und anderen Methoden des Zugriffs auf Wikidata unterliegen der Stable Interface Policy. Für Datenquellen auf dieser Seite wird nicht garantiert, dass sie stabile Schnittstellen sind.

Dieses Dokument befasst sich mit dem Zugriff auf Daten von außerhalb der Wikimedia-Projekte. Wenn Du Daten aus Wikidata in einem anderen Wikimedia-Projekt präsentieren musst, wo Du Parser-Funktionen, Lua und/oder andere interne Methoden verwenden kannst, lies bitte Wie man Daten in Wikimedia-Projekten verwendet.

Wir bieten die Daten in Wikidata frei und ohne Verpflichtung zur Namensnennung unter CC-0 an. Im Gegenzug würden wir es sehr begrüßen, wenn Du in Deinem Projekt Wikidata als Ursprung Deiner Daten erwähnst. Damit trägst Du dazu bei, dass Wikidata noch lange Zeit aktuelle und qualitativ hochwertige Daten zur Verfügung stellen kann. Wir fördern auch die besten Projekte, die die Daten von Wikidata nutzen.

Einige Beispiele für die Nennung von Wikidata: "Powered by Wikidata", "Powered by Wikidata data", "Powered by the magic of Wikidata", "Using Wikidata data", "With data from Wikidata", "Data from Wikidata", "Source: Wikidata", "Including data from Wikidata" usw. Du kannst auch eine unserer vorgefertigten Dateien verwenden.

• 
• 
• 

Du darfst das oben gezeigte Wikidata-Logo verwenden, solltest damit aber in keiner Weise eine Unterstützung durch Wikidata oder die Wikimedia Foundation implizieren.

Bitte biete Deinen Benutzern eine Möglichkeit, Probleme in den Daten zu melden, und finde einen Weg, diese an die Wikidata-Redaktion weiterzuleiten, zum Beispiel über den Mismatch Finder. Bitte teile den Ort, an dem Du diese Probleme sammelst, im Projekt-Chat mit.

Beachte beim Zugriff auf die Daten von Wikidata die folgenden besten Praktiken:

• Befolge die User-Agent-Richtlinie - sende einen guten User-Agent-Header.
• Befolge die Roboterregeln: Sende 1 $ und stelle nicht zu viele Anfragen auf einmal.
• Wenn Du eine Antwort 429 Too Many Requests erhalten, stelle das Senden weiterer Anfragen für eine Weile ein (siehe Antwortkopf Retry-After)
• Wenn verfügbar (z. B. mit dem Wikidata Query Service), stelle das niedrigste Timeout ein, die für Deine Daten sinnvoll ist.
• Wenn Du die MediaWiki-Aktions-API verwendest, mache großzügig Gebrauch von dem Parameter maxlag und beachte die übrigen Richtlinien, die in API:Etikette beschrieben sind.

Wikidata bietet einen Elasticsearch-Index für die traditionelle Suche in seinen Daten: Special:Search

Verwende die Suche, wenn Du nach einem Textstring suchen musst oder wenn du die Namen der gesuchten Entitäten kennst, aber nicht die genauen Entitäten selbst. Sie eignet sich auch für Fälle, in denen Du Deine Suche auf der Grundlage einiger sehr einfacher Beziehungen in den Daten spezifizieren kannst.

Verwende die Suche nicht, wenn die Beziehungen in Deinen Daten besser als komplex zu bezeichnen sind.

Du kannst Deine Suche mit diesen zusätzlichen, Wikidata-spezifischen Schlüsselwörtern noch leistungsfähiger machen: haswbstatement, inlabel, wbstatementquantity, hasdescription, haslabel. Diese Suchfunktionalität ist auf der Seite der CirrusSearch-Erweiterung dokumentiert. Sie hat auch eine eigene [API-Aktion].

Die Linked Data-Schnittstelle ermöglicht den Zugriff auf einzelne Entitäten über URI: http://www.wikidata.org/entity/Q???. Solche URIs werden als Konzept-URIs bezeichnet. Beachte, dass Konzept-URIs HTTP und nicht HTTPS verwenden.

Nutze die Linked Data-Schnittstelle, wenn du einzelne, vollständige Entitäten benötigst, die dir bereits bekannt sind.

Verwende sie nicht, wenn du dir nicht sicher bist, welche Entitäten du brauchst - versuche es zuerst mit einer Suche oder Abfrage. Sie ist auch nicht für die Abfrage großer Datenmengen geeignet.

Jeder Datensatz und jede Eigenschaft hat einen dauerhaften URI, der sich aus dem Wikidata-Konzept-Namensraum und der ID des Datensatzes oder der Eigenschaft (z. B. Q42, P31) sowie aus konkreten Daten zusammensetzt, auf die über den URL des Datensatzes oder der Eigenschaft zugegriffen werden kann.

Der Namespace für Wikidatas Daten über Entitäten ist https://wikidata.org/wiki/Special:EntityData

Wenn du die ID einer Entität an dieses Präfix anhängst (du kannst auch kurz /entity/ verwenden), entsteht die abstrakte (formatneutrale) Form der Daten-URL der Entität. Wenn du auf eine Ressource im Special:EntityData-Namensraum zugreifst, wendet die Spezialseite content negotiation an, um das Ausgabeformat zu bestimmen. Wenn du die Ressource in einem Browser öffnest, siehst du eine HTML-Seite mit Daten über die Entität, da Webbrowser HTML bevorzugen. Ein Linked-Data-Client würde die Entitätsdaten jedoch in einem Format wie JSON oder RDF erhalten - was auch immer der Client in seinem HTTP-Accept:-Header angibt.

Nimm zum Beispiel diese Konzept-URI für Douglas Adams - das ist ein Verweis auf die reale Person, nicht auf die konkrete Beschreibung von Wikidata:

http://www.wikidata.org/entity/Q42

Als Mensch mit Augen und einem Browser wirst du wahrscheinlich auf Daten über Douglas Adams zugreifen wollen, indem du die Konzept-URI als URL verwendest. Dadurch wird ein HTTP-Redirect ausgelöst und der Client zu der Daten-URL weitergeleitet, die Wikidatas Daten über Douglas Adams enthält: https://www.wikidata.org/wiki/Special:EntityData/Q42.

Um Content Negotiation zu umgehen (z.B. zum Betrachten von Nicht-HTML-Inhalt in einem Webbrowser), kannst du auf einzelne Datensätze in einem bestimmten Formate zugreifen, indem du die Daten-URL mit einem Erweiterungsanhang für das gewünschte Datenformat versiehst, wie .json, .rdf, .ttl, .nt oder .jsonld. Beispielsweise führt https://www.wikidata.org/wiki/Special:EntityData/Q42.json zu einem JSON-Export für das Datenobjekt Q42.

Standardmäßig enthält das von der Schnittstelle für verlinkte Daten ausgegebene RDF-Beschreibungen und andere Entitäten, auf die es verweist und ist in sich geschlossen. Nutze ?flavor=dump, um solche Informationen auszuschließen.

Indem du &flavor an die URL anhängst, kannst du genau steuern, welche Art von Daten zurückgegeben wird.

• ?flavor=dump: Schließt Beschreibungen von Entitäten aus, auf die in den Daten Bezug genommen wird.
• ?flavor=simple: Bietet nur wahrheitsgemäße Aussagen (am besten bewertete Aussagen ohne Qualifikatoren oder Referenzen), zusammen mit Sitelinks und Versionsinformationen.
• ?flavor=full (default): Mit dem Argument "full" werden alle Daten zurückgegeben. (Du musst dies nicht angeben, da es die Standardeinstellung ist).

Wenn du einen genaueren Einblick in die einzelnen Optionen haben möchtest, kannst du einen Blick in den Quellcode werfen.

Du kannst bestimmte Revisionen einer Entität mit dem Abfrageparameter revision abfragen: https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=112.

Die folgenden URL-Formate werden von der Benutzeroberfläche bzw. vom Query Service Updater verwendet. Wenn du also eines dieser URL-Formate verwendest, ist die Chance groß, dass du schnellere (gecachte) Antworten erhältst:

• https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=1600533266 (JSON)
• https://www.wikidata.org/wiki/Special:EntityData/Q42.ttl?flavor=dump&revision=1600533266 (RDF, ohne Beschreibungen von anderen Entitäten)

Der Wikidata Query Service (WDQS) ist der eigene SPARQL-Endpunkt von Wikidata. Er liefert die Ergebnisse von Abfragen, die in der SPARQL-Abfragesprache gemacht wurden: https://query.wikidata.org

Verwende WDQS, wenn du nur die Merkmale deiner gewünschten Daten kennst.

Verwende WDQS nicht für eine Text- oder Fuzzy-Suche - FILTER(REGEX(...)) ist ein Antipattern. (Verwende in solchen Fällen search).

WDQS ist auch nicht geeignet, wenn deine gewünschten Daten wahrscheinlich sehr groß sind, also einen beträchtlichen Anteil aller Wikidata-Daten ausmachen. (Ziehe in solchen Fällen einen dump in Betracht.)

Du kannst die Daten in Wikidata über unseren SPARQL-Endpunkt, den Wikidata Query Service, abfragen. Der Dienst kann sowohl als interaktives Webinterface als auch programmatisch genutzt werden, indem du GET oder POST Anfragen an https://query.wikidata.org/sparql stellst.

Der Abfragedienst eignet sich am besten, wenn die gewünschte Ergebnismenge eng eingegrenzt ist, d.h. wenn du eine Abfrage hast, bei der du dir ziemlich sicher bist, dass sie die resultierende Datenmenge bereits genau beschreibt. Wenn deine Vorstellung von der Ergebnismenge weniger genau definiert ist, ähnelt die Arbeit, die du mit dem Abfragedienst verrichtest, eher einer Suche; häufig musst du zuerst diese Art von suchbezogener Arbeit erledigen, um deine Abfrage zu verfeinern. Siehe den Abschnitt Suche.

Der Linked Data Fragments (LDF)-Endpunkt ist eine experimentellere Methode, um auf die Daten von Wikidata zuzugreifen, indem Muster in Triples angegeben werden: https://query.wikidata.org/bigdata/ldf. Die Berechnung erfolgt hauptsächlich auf der Client-Seite.

Verwende den LDF-Endpunkt, wenn du die Daten, nach denen du suchst, mithilfe von Triple-Mustern definieren kannst und wenn deine Ergebnismenge wahrscheinlich ziemlich groß ist. Der Endpunkt ist gut geeignet, wenn du über viel Rechenleistung verfügst.

Da er noch experimentell ist, solltest du den LDF-Endpunkt nicht verwenden, wenn du einen absolut stabilen Endpunkt oder eine vollständige Ergebnismenge brauchst. Und wie bereits erwähnt, solltest du ihn nur verwenden, wenn du über ausreichend Rechenleistung verfügst, denn der LDF-Endpunkt verlagert die Berechnungen auf die Client-Seite.

Wenn du nur Teilinformationen dazu hast, wonach du suchst, z. B. wenn du nur zwei von drei Komponenten deines Tripels/deiner Tripel hast, kannst du die Schnittstelle Linked Data Fragments bei https://query.wikidata.org/bigdata/ldf verwenden. Weitere Informationen findest du im Benutzerhandbuch und auf den Community-Seiten.

Die Wikibase REST API ist eine OpenAPI-basierte Schnittstelle, die es Nutzern ermöglicht, mit Wikibase-Instanzen - darunter natürlich auch Wikidata - zu interagieren, Artikel und Aussagen abzurufen und zu bearbeiten: Wikidata REST API

Die Wikibase REST API befindet sich noch in der Entwicklung, aber für Wikidata soll sie die Action API funktional ersetzen, da es sich um eine spezielle Schnittstelle handelt, die nur für Wikibase/Wikidata entwickelt wurde.

Die Anwendungsfälle für die Action API gelten auch für die Wikibase REST API. Verwende sie, wenn deine Arbeit Folgendes beinhaltet:

• Wikidata bearbeiten
• Direkte Daten über Entitäten selbst erhalten

Verwende die Wikibase REST API nicht, wenn deine Ergebnismenge wahrscheinlich sehr groß ist. (Ziehe in solchen Fällen einen dump in Betracht.)

Es ist besser, die Wikibase REST API nicht zu verwenden, wenn du das Ergebnis deiner API-Anfrage weiter eingrenzen musst. In solchen Fällen ist es besser, deine Arbeit als Suche (für Elasticsearch) oder als Abfrage (für WDQS) zu formulieren.

Die Wikibase REST API hat eine OpenAPI Dokumentation, die Swagger verwendet. Du kannst auch die Entwicklerdokumentation einsehen.

Die Wikidata-API ist MediaWikis eigene Action-API, die um einige Wikibase-spezifische Aktionen erweitert wurde: https://wikidata.org/w/api.php

Nutze die API, wenn deine Arbeit dies erfordert:

• Wikidata bearbeiten
• Daten über die Entitäten selbst abrufen, z. B. ihre Änderungshistorie
• Abruf aller Daten einer Entität im JSON-Format, in kleinen Gruppen von Entitäten (bis zu 50 Entitäten pro Anfrage).

Verwende die API nicht, wenn deine Ergebnismenge wahrscheinlich sehr groß ist. (Ziehe in solchen Fällen einen dump in Betracht.)

Die API ist auch schlecht für Situationen geeignet, in denen du den aktuellen Status von Entitäten in JSON abfragen möchtest. (Für solche Fälle solltest du die Linked Data Interface verwenden, die wahrscheinlich schnellere Antworten liefert).

Schließlich ist es wahrscheinlich keine gute Idee, die API zu verwenden, wenn du das Ergebnis deiner API-Anfrage weiter eingrenzen musst. In solchen Fällen ist es besser, deine Arbeit als search (für Elasticsearch) oder als query (für WDQS) zu formulieren.

Die MediaWiki Action API, die für Wikidata verwendet wird, ist sorgfältig dokumentiert auf der API-Seite von Wikidata. Du kannst sie in der API Sandbox erforschen und damit experimentieren.

Es gibt mehrere Wikibase-spezifische Endpunkte. Hier sind einige Beispielanfragen: * Suche mit wbsearchentities nachNew York, NY mit limit=1 ergibt: New York City (Q60). Dieser Endpunkt ist sehr wertvoll, weil er schnell ist und als Quelle für Inferenzen in Tools und Anwendungen verwendet werden kann. Für die meisten gut beschriebenen Artikel in Wikidata funktioniert dieser Endpunkt erstaunlich gut.

Du kannst auch mit einem Bot auf die API zugreifen. Mehr über Bots erfährst du unter Wikidata:Bots.

Der Stream Letzte Änderungen bietet einen kontinuierlichen Strom von Änderungen in allen Wikimedia-Wikis, einschließlich Wikidata: https://stream.wikimedia.org

Nutze den Stream Letzte Änderungen, wenn du für dein Projekt in Echtzeit auf Änderungen reagieren musst oder wenn du alle aktuellen Änderungen von Wikidata benötigst - zum Beispiel, wenn du deinen eigenen Abfragedienst betreibst.

Der Stream Letzte Änderungen enthält alle Aktualisierungen von allen Wikis, die das server-sent events-Protokoll verwenden. Du musst die Aktualisierungen von Wikidata auf der Client-Seite herausfiltern.

Du findest das Webinterface bei stream.wikimedia.org und kannst alles darüber auf der EventStreams-Seite lesen.

Wikidata-Dumps sind vollständige Exporte aller Entitäten in Wikidata: https://dumps.wikimedia.org

Verwende einen Dump, wenn deine Ergebnismenge wahrscheinlich sehr groß sein wird. Ein Dump ist auch wichtig, wenn du deinen eigenen Abfragedienst einrichtest.

Verwende keinen Dump, wenn du aktuelle Daten brauchst: Die Dumps brauchen sehr lange, um exportiert zu werden und noch länger, um mit deinem eigenen Abfragedienst synchronisiert zu werden. Dumps sind auch ungeeignet, wenn du nur eine begrenzte Bandbreite, Speicherplatz und/oder Rechenleistung zur Verfügung hast.

Wenn du viele Datensätze durchsuchen musst oder wenn deine Ergebnismenge wahrscheinlich sehr groß ist, solltest du mit einem Datenbank-Dump arbeiten: (Link zum letzten vollständigen Dump).

Ausführliche Dokumentation zu allen Wikimedia-Dumps findest du auf der Seite "Datendumps" auf Meta und zu Wikidata-Dumps im Besonderen auf der Seite Datenbank-Download. Siehe auch Flavored dumps oben.

• JsonDumpReader ist eine PHP-Bibliothek zum Lesen von Dumps.
• Unter [1] findest du eine Go-Bibliothek zur Verarbeitung von Wikipedia- und Wikidata-Dumps.
• Du kannst wdumper verwenden, um teilweise benutzerdefinierte RDF-Dumps zu erhalten.

Es ist keine kleine Aufgabe, einen Wikidata-Dump zu beschaffen und die oben genannten Werkzeuge für die Arbeit damit zu implementieren, aber du kannst noch einen Schritt weiter gehen. Wenn du die Kapazitäten und Ressourcen dafür hast, kannst du deine eigene Instanz des Wikidata Query Service hosten und sie so oft abfragen, wie du willst, ohne mit anderen in Konflikt zu geraten.

Um deinen eigenen Abfragedienst einzurichten, befolge diese Anleitung des Abfragedienst-Teams, zu der auch die Beschaffung einer eigenen lokalen Kopie der Daten gehört. Nützliche Informationen findest du auch in Adam Shorlands Blogpost zu diesem Thema.