WikiData Sparqlを使用して抽象要素を効率的にクエリする

Question

"human"（Q5）などの抽象要素のサブクラスのインスタンスを名前でフェッチするクエリを作成しようとしていますが、グラフにトラバースするノードが多すぎます。

1. これを照会する方法はありますか？私が思いつくのは、Wikidata API search entities endpointを要素名で使用し、Sparqlクエリで必要な結果をフィルタリングして、グラフ全体ではなくクエリのドメインを最小限に抑えることです。
2. Wikidata Sparqlはベータ版であるため、この方法を運用環境で使用することについて少し気になります。知識ベースグラフのユースケースをフリーズから移行するためのベストプラクティスは？ FreebaseからWikidataへのデータ移行に関する更新はありますか？

最後に、廃止予定のFreebaseサービスの代わりに成熟した代替手段はありますか？

Answer 1

どのエンドポイントに対して照会していますか？実動サービスに対してSLA（ベータか否定）のない共有の公開エンドポイントに対して照会することは、非常に危険な命題です。

Wikidataは完全なデータベースダンプを提供しており、あなたが好きなインフラストラクチャに合わせて、サブセット化してロードすることができます。これにより、パフォーマンス、品質、およびその他の重要なメトリックを完全に制御することができます。

Freebaseから移行する限り、移行パスはありません。トレインがオンだったトラックは終了しています（少なくともGoogle以外の外部のユーザーの場合）。それは単に非難されただけではなく、ずっと前に完全に閉鎖されました。データのほんの一部はWikidataにインポートされました（そしてそれらは共通の先祖Wikipediaのために共通の束を共有していました）が、MQLのJSONクエリベースの例、Freebase Search、Freebase Suggest、Google規模のパフォーマンスや可用性などが利用可能です（まだ？）Wikidata。

データが重要な場合は、ニーズに合ったインフラストラクチャを使用して自己ホストする必要があります。