Wikidata:データへのアクセス

From Wikidata
Jump to navigation Jump to search
This page is a translated version of the page Wikidata:Data access and the translation is 90% complete.

ウィキデータは現在、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

どんなときに使う?

文字列を探す必要があるとき、あるいは探しているエンティティの名前を知っているが正確なエンティティそのものを知らないときに使います。非常に単純なデータの関係性に基づいて検索を指定することができる場合にも適しています。

データの関係性を複雑に記述した方がよい場合には、検索を使用しないでください。

詳細

以下のようなウィキデータ専用の追加のキーワードで、検索をより強力なものとすることができます:haswbstatementinlabelwbstatementquantityhasdescriptionhaslabel。この検索機能はCirrusSearch拡張機能のページで文書化されています。それ自身の APIアクションも持っています。

リンクトデータインターフェイス(URI)

それは何?

リンクトデータインターフェイスは、URIを介して個々のエンティティへのアクセスを提供します: http://www.wikidata.org/entity/Q???

どんなときに使う?

すでに知っている個々の完全なエンティティを取得する必要がある場合は、リンクトデータインターフェイスを使用して下さい。

必要なエンティティが分からない場合は使用しないで下さい。まず、検索またはクエリを試して下さい。また、大量のデータを要求するのにも適していません。

詳細

Q42を見てみましょう

各項目やプロパティは、ウィキデータの概念名前空間とその項目やプロパティのID(例えば、Q42P31)からなる永続的な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形式のいずれかを使用すると、より高速な(キャッシュされた)応答が得られる可能性が高いです。

ウィキデータクエリサービス

それは何?

ウィキデータクエリサービス(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/ldfLinked Data Fragmentsインターフェイスを使用して探しているものを見つけることができます。詳細については、利用者マニュアルコミュニティページを参照して下さい。

Wikibase REST API

What is it?

The Wikibase REST API is an OpenAPI-based interface that allows users to interact with, retrieve and edit items and statements on Wikibase instances -- including of course Wikidata: Wikidata REST API

When to use it?

The Wikibase REST API is still under development, but for Wikidata it's intended to functionally replace the Action API (see above) as it's a dedicated interface made just for Wikibase/Wikidata.

The use cases for the Action API (see above) apply to the Wikibase REST API as well. Use it when your work involves:

  • Editing Wikidata
  • Getting direct data about entities themselves

Don't use the Wikibase REST API when your result set is likely to be large. (Consider using a dump in such cases.)

It's better not to use the Wikibase REST API when you'll need to further narrow the result of your API request. In such cases it's better to frame your work as a search (for Elasticsearch) or a query (for WDQS).

Details

The Wikibase REST API has OpenAPI documentation using Swagger. You can also review the developer documentation.

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クエリサービス

ウィキデータダンプを調達し、それを操作するための上記のツールを実装することは小さな作業ではありませんが、さらに一歩を踏み出すことができます。これを行う能力とリソースがある場合は、ウィキデータクエリサービスの独自のインスタンスをホストし、他の人との競合から好きなだけクエリすることができます。

独自のクエリサービスを設定するには、クエリサービスチームのこれらの手順に従って下さい。これには、データのローカルコピーの取得が含まれます。また、このトピックに関するアダム・ショーランドのブログ記事でも役立つ情報を見つけることができます。