Wikidata:データへのアクセス
ウィキデータは現在、1億を超える項目と650,000を超える語彙素を保持しており、その数は増え続けています。それらの全データにアクセスすることができる多数の手段があります -- この文書ではそれらを提示し、将来の利用者がそのニーズに最適な手段を選択する手助けをします。
最も素早く、効率的な方法で必要なデータを入手しつつ、ウィキデータに不必要な負荷をかけないアクセス手段を選択することが重要です。このページはまさに、その手助けをするためにあります。
始める前に
ウィキデータのデータを利用する
ウィキデータは、世界中のあらゆる物事について全般的なデータを幅広く提供しています。全データはCC0でライセンスされ、「著作権を放棄」し、パブリック・ドメインとなっています。
ウィキデータへのアクセスに使用するAPIやその他の手段は、 安定したインターフェイスの方針に従います。このページのデータソースは安定インターフェースであると保証されていません。
ウィキメディアのプロジェクト群
この文書はウィキメディア・プロジェクトの外からのデータアクセスに関するものです。ウィキデータから他のウィキメディア・プロジェクトにデータを提供する必要がある場合には、パーサー関数、Lua 及びその他の内部限定の手段を使うことができますので、ウィキメディア・プロジェクトでのデータ利用法を参照してください。
データの最善手法
ウィキデータはCC-0の下、自由にそして帰属表示の必要なしに利用できるようデータを提供しています。見返りとして、あなたのプロジェクトでデータの入手元としてウィキデータに言及していただければ大変ありがたいです。そうすることで、ウィキデータは長期にわたって維持され高品質で最新のデータを提供し続けることができます。また、我々はウィキデータを使った素晴らしいプロジェクトを宣伝します。
ウィキデータに帰属する例: "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"など。また、既製のファイルの1つを使用することも可能です。
上に示したウィキデータのロゴを使っていただいてかまいませんが、それによっていかなる方法であってもウィキデータまたはウィキメディア財団によるエンドースメント（承認）をほのめかさないでください。
データの問題を報告する手段をあなたのユーザーに提供し、例えばMismatch Finderを通して、ウィキデータの編集者コミュニティにそれをフィードバックする方法を見つけてください。プロジェクトチャットにこれらの問題を収集した場所を共有してください。
アクセスの最善手法
ウィキデータにアクセスするときは、以下のベストプラクティスに従ってください。
- User-Agentポリシーに従ってください。優れたUser-Agentヘッダーを送信します。
- ロボットポリシーに従ってください：
Accept-Encoding: gzip,deflateを送信し、一度にあまりにも多くのリクエストをしないでください。 - 429 Too Many Requests 応答を受け取った場合は、しばらくの間、それ以上のリクエストの送信を停止します（Retry-After 応答ヘッダーを参照）
- 利用可能な場合（ウィキデータクエリサービスなど）、データにとって意味のある最低タイムアウトを設定します。
- MediaWiki Action APIを使用する場合は、
maxlagパラメータをリベラルに使用し、API:Etiquetteに記載されている残りのガイドラインを参照してください。
検索
それは何？
ウィキデータはそのデータの至るところを昔ながらの方法で検索するために、Elasticsearchインデックスを提供しています：Special:Search
どんなときに使う？
文字列を探す必要があるとき、あるいは探しているエンティティの名前を知っているが正確なエンティティそのものを知らないときに使います。非常に単純なデータの関係性に基づいて検索を指定することができる場合にも適しています。
データの関係性を複雑に記述した方がよい場合には、検索を使用しないでください。
詳細
以下のようなウィキデータ専用の追加のキーワードで、検索をより強力なものとすることができます：haswbstatement、inlabel、wbstatementquantity、hasdescription、haslabel。この検索機能はCirrusSearch拡張機能のページで文書化されています。それ自身の APIアクションも持っています。
リンクトデータインターフェイス（URI）
それは何？
リンクトデータインターフェイスは、URIを介して個々のエンティティへのアクセスを提供します: http://www.wikidata.org/entity/Q???
どんなときに使う？
すでに知っている個々の完全なエンティティを取得する必要がある場合は、リンクトデータインターフェイスを使用して下さい。
必要なエンティティが分からない場合は使用しないで下さい。まず、検索またはクエリを試して下さい。また、大量のデータを要求するのにも適していません。
詳細
各項目やプロパティは、ウィキデータの概念名前空間とその項目やプロパティのID（例えば、Q42、P31）からなる永続的なURIを持ち、同様にその項目やプロパティのデータURLによってアクセス可能な具体的なデータを持ちます。
エンティティに関するウィキデータのデータに対する名前空間は https://wikidata.org/wiki/Special:EntityData です。
このプレフィックス（短縮して/entity/とすることができます）にエンティティのIDを追加すると、そのエンティティの抽象（フォーマット中立な）形式のデータURLを作ることができます。Special:EntityData名前空間にあるリソースにアクセスするとき、Specialページは出力形式を決定するためコンテントネゴシエーションを適用します。ブラウザでリソースを開いた場合、そのエンティティに関するデータを含むHTMLページが表示されます。これはWebブラウザにとってHTMLが好ましいからです。しかしながら、リンクトデータクライアントはそのエンティティのデータをJSONやRDFといった -- 何であれクライアントがHTTP Accept: ヘッダで指定した形式で受け取るでしょう。
- 例えば、ダグラス・アダムスのためにこの「コンセプトURI」を取ります。これは、ウィキデータの具体的な説明ではなく、現実世界の人物への参照です。
http://www.wikidata.org/entity/Q42
- 目とブラウザを持つ人間としては、コンセプトURIをURLとして使用することで、ダグラス・アダムス「に関する」データにアクセスしたいと思うでしょう。そうすることで、HTTPリダイレクトがトリガーされ、ダグラス・アダムス「に関する」ウィキデータのデータを含む以下のデータURLにクライアントが転送されます: https://www.wikidata.org/wiki/Special:EntityData/Q42 。
コンテンツネゴシエーションを迂回する必要がある場合、例えば非HTMLコンテンツをWebブラウザで表示させるために、データURLに.json、.rdf、.ttl、.ntあるいは.jsonldといった対応する形式を指定する拡張子を付与することで、エンティティデータの形式を指定することができます。例えば、https://www.wikidata.org/wiki/Special:EntityData/Q42.json はQ42の項目をJSON形式で与えます。
冗長でないRDF出力
既定では、リンクトデータ・インターフェースから返されるRDFはそれ自体で完全であることが意図されているので、参照している他のエンティティの記述も含まれています。そのような情報を除外したいならば、クエリパラメータ?flavor=dumpをリクエストするURLに付け加えることができます。
URLに&flavorを追加することで、返されるデータの種類を正確に制御できます。
?flavor=dump: データで言及されているエンティティの説明は除外されます。?flavor=simple: 真らしい文（修飾子や出典なしで最善ランクの文）のみを、サイトリンクおよびバージョン情報と共に提供します。?flavor=full(default): 「Full」の引数は全てのデータを返します。（デフォルトなので、これを指定する必要はありません。）
各オプションが何を伴うかを正確に把握したい場合は、ソースコードを覗くことができます。
版とキャッシュ
revisionクエリパラメータでエンティティの特定の版をリクエストできます：https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=112。
以下のURL形式は、ユーザーインターフェイスとクエリサービスアップデータによってそれぞれ使用されるため、同じURL形式のいずれかを使用すると、より高速な（キャッシュされた）応答が得られる可能性が高いです。
- 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、他のエンティティの説明なし)
ウィキデータクエリサービス
それは何？
ウィキデータクエリサービス（WDQS）は、ウィキデータ独自のSPARQLエンドポイントです。SPARQLクエリ言語で行われたクエリの結果を返します: https://query.wikidata.org
どんなときに使う？
目的のデータの特性しか知らない場合は、WDQSを使用してください。
テキスト検索やファジー検索の実行にWDQSを使用しないでください。FILTER(REGEX(...))はアンチパターンです。（そのような場合は検索を使用してください。）
WDQSは、希望するデータがウィキデータの全データのかなりの割合を占める大きさになりそうな場合にも適していません。（そのような場合は、ダンプを使用することを検討してください。）
詳細
SPARQLエンドポイントであるウィキデータクエリサービスを通じてウィキデータ内のデータにクエリすることができます。このサービスは対話型ウェブインターフェイスとして利用することも、https://query.wikidata.org/sparqlへのGETまたはPOSTリクエストをサブミットすることでプログラムで利用することもできます。
クエリサービスは、意図した結果セットが狭い範囲に限られている場合に最もよく使用されます。つまり、クエリを用意したときには、既に結果のデータセットを正確に特定していると確信しています。結果セットのアイデアがあまり明確に定義されていない場合、クエリサービスに対して行う作業の種類は検索に似ています。多くの場合、クエリの体裁を整えるために、まずはこの種の検索関連の作業を行う必要があります。検索セクションを参照してください。
Linked Data Fragments エンドポイント
それは何？
Linked Data Fragments（LDF）エンドポイントは、トリプルに含まれるパターンを指定することで、ウィキデータのデータにアクセスするより実験的な方法です：https://query.wikidata.org/bigdata/ldf。計算は主にクライアント側で行われます。
どんなときに使う？
トリプルパターンを使用して探しているデータを定義できる場合や、結果セットがかなり大きい可能性が高い場合は、LDFエンドポイントを使用して下さい。エンドポイントは、あなたが自由に使える重要な計算能力を持っているときに使用するのに良いです。
実験的であるため、絶対に安定したエンドポイントや厳密に完全な結果セットが必要な場合は、LDFエンドポイントを使用しないで下さい。前述のように、LDFエンドポイントはクライアント側に計算をオフロードするため、十分な計算能力がある場合にのみ使用して下さい。
詳細
トリプルの3つのコンポーネントのうち2つがある場合など、探しているものに関する部分的な情報がある場合は、https://query.wikidata.org/bigdata/ldfのLinked Data Fragmentsインターフェイスを使用して探しているものを見つけることができます。詳細については、利用者マニュアルとコミュニティページを参照して下さい。
Wikibase REST API
それは何？
Wikibase REST APIとは、Wikibaseインスタンス（もちろんウィキデータも含む）上の項目や文を操作、取得、編集できるようにするOpenAPIベースのインターフェースです。 Wikidata REST API
どんなときに使う？
Wikibase REST APIはまだ開発中ですが、ウィキデータに関しては、Wikibase/Wikidata専用に作成されたインターフェイスであるため、 機能的に操作APIと置き換えることを目的としています。
操作APIの使用事例は、Wikibase REST APIにも適用されます。次のような場合に使用します。
- ウィキデータの編集
- エンティティ自体に関する直接データの取得
結果セットが大規模になりそうな場合はWikibase REST APIを使用しないでください。(そのような場合はダンプの使用を検討してください。)
APIリクエストの結果をさらに絞り込む必要がある場合は、Wikibase REST APIを使用しない方が良いでしょう。そのような場合は、検索（Elasticsearch）またはクエリ（WDQS）の使用を考えてください。
詳細
Wikibase REST APIには、Swaggerを使用したOpenAPIドキュメントがあります。また、開発者向けドキュメントも閲覧できます。
MediaWiki 操作 API
それは何？
ウィキデータAPIは、MediaWiki独自のアクションAPIであり、幾つかのウィキベース固有のアクションを含むように拡張されています: https://wikidata.org/w/api.php
どんなときに使う？
作業に以下が含まれる場合は、APIを使用してください。
- ウィキデータの編集
- 編集履歴のようなエンティティ自体に関するデータの取得
- エンティティのデータのすべてをJSON形式で、エンティティの小グループ（リクエストごとに最大50のエンティティ）で取得。
結果セットが大きくなりそうな場合は、APIを使用しないでください。（そのような場合は、ダンプを使用することを検討してください。）
APIは、JSONでエンティティの現在の状態を要求したい状況にも適していません。（そのような場合、より迅速な応答を提供する可能性がより高いリンクトデータインターフェイスを使用することを検討してください。）
最後に、APIリクエストの結果をさらに絞り込む必要がある場合に、APIを使用するのは恐らく悪い考えです。このような場合は、作業を検索（Elasticsearch用）またはクエリ（WDQS用）としてフレーム化する方が良いです。
詳細
ウィキデータに使用されるMediaWikiアクションAPIは、ウィキデータのAPIページで細心の注意を払って文書化されています。APIサンドボックスを使用して探索及び実験できます。
ボット
ボットを使ってAPIにアクセスすることもできます。ボットについて詳細は Wikidata:Bots を参照してください。
最近の更新のオプション
それは何？
ウィキメディアの最近の更新イベントストリームは、ウィキデータを含むすべてのウィキメディア・ウィキの変更の連続的なストリームを提供します：https://stream.wikimedia.org
どんなときに使う？
プロジェクトがリアルタイムで変更に反応する必要がある場合や、独自のクエリサービスを実行する場合など、Wikidataからの全ての最新の変更が必要な場合は、最近の変更ストリームを使用します。
詳細
最近の変更ストリームには、server-sent eventsプロトコルを使用して、全てのWikiからの全ての更新が含まれています。ウィキデータの更新をクライアント側でフィルタリングする必要があります。
ウェブインターフェイスをstream.wikimedia.orgで見つけて、EventStreamsページで全て読むことができます。
ダンプ
それは何？
ウィキデータダンプは、ウィキデータ内の全てのエンティティの完全なエクスポートです: https://dumps.wikimedia.org
どんなときに使う？
結果セットが非常に大きくなりそうな場合は、ダンプを使用してください。また、独自のクエリサービスを設定する際にも、ダンプは重要です。
現在のデータが必要な場合はダンプを使用しないでください。ダンプはエクスポートに非常に時間がかかり、独自のクエリサービスに同期するのにさらに時間がかかります。ダンプは、利用可能な帯域幅、ストレージ空き容量、および計算能力に大きな制限がある場合にも適していません。
詳細
トラバースする必要があるレコードが多い場合、または結果セットが非常に大きい可能性が高い場合は、データベースダンプの操作を検討する時が来ました:（最新の完全なダンプへのリンク）。
全てのウィキメディアダンプに関する詳細なドキュメントメタの「データダンプ」ページで、特にウィキデータダンプに関する詳細なドキュメントは、データベースダウンロードページにあります。上記のFlavored dumpsも参照して下さい。
ツール
- JsonDumpReaderは、ダンプを読むためのPHPライブラリです
- [1]にウィキペディアとウィキデータダンプを処理するためのGoライブラリがあります。
- wdumperを使用して、部分的なカスタムRDFダンプを取得できます。
SPARQLクエリサービス
ウィキデータダンプを調達し、それを操作するための上記のツールを実装することは小さな作業ではありませんが、さらに一歩を踏み出すことができます。これを行う能力とリソースがある場合は、ウィキデータクエリサービスの独自のインスタンスをホストし、他の人との競合から好きなだけクエリすることができます。
独自のクエリサービスを設定するには、クエリサービスチームのこれらの手順に従って下さい。これには、データのローカルコピーの取得が含まれます。また、このトピックに関するアダム・ショーランドのブログ記事でも役立つ情報を見つけることができます。