[論文レビュー] Creating and Querying Personalized Versions of Wikidata on a Laptop

Hans Chalupsky, Pedro Szekely+3 more|arXiv (Cornell University)|Aug 6, 2021

Semantic Web and Ontologies参考文献 4被引用数 6

ひとこと要約

本論文では、KGTKツールキット内に統合された軽量なクエリ言語およびプロセッサ、Kypherを紹介する。Kypherを用いることで、標準的なラップトップで、ユーザーがカスタマイズしたクエラブルなバージョンのWikidataを構築できる。コンactなタブ区切りのKGTKデータモデルと最適化されたSQLiteストレージを採用することで、Kypherは公開されているSPARQLエンドポイントよりも最大10倍速く、複雑で大規模な知識グラフクエリを実行でき、高価なインfrastrucureを必要とせずにWikidataの高度な分析を可能にする。

ABSTRACT

Application developers today have three choices for exploiting the knowledge present in Wikidata: they can download the Wikidata dumps in JSON or RDF format, they can use the Wikidata API to get data about individual entities, or they can use the Wikidata SPARQL endpoint. None of these methods can support complex, yet common, query use cases, such as retrieval of large amounts of data or aggregations over large fractions of Wikidata. This paper introduces KGTK Kypher, a query language and processor that allows users to create personalized variants of Wikidata on a laptop. We present several use cases that illustrate the types of analyses that Kypher enables users to run on the full Wikidata KG on a laptop, combining data from external resources such as DBpedia. The Kypher queries for these use cases run much faster on a laptop than the equivalent SPARQL queries on a Wikidata clone running on a powerful server with 24h time-out limits.

研究の動機と目的

• SPARQLエンドポイントの5分間のタイムアウト制限や、大規模なサーバー基盤が必要なRDFロードといった、既存のWikidataアクセス方法の制限を解消すること。
• 研究者や開発者が、高価なサーバーやクラウドインfrastrucureを必要とせず、個人用ラップトップでリソース集約型の知識グラフ分析を実行できるようにすること。
• DBpediaなどの外部データセットを統合することで、ユーザーがカスタマイズされた拡張知識グラフを構築できるようにすることで、Wikidataへのアクセスを民主化すること。
• Kypherが、たとえ低スペックのハードウェアでも、分析ワークロードにおいて公開SPARQLエンドポイントを上回るクエリパフォーマンスを発揮することを実証すること。

提案手法

• RDFに比べてデータの肥大化を抑えることができる、タブ区切りのエッジ形式（head, edge-label, tail, edge-id）を用いたKGTK知識グラフとしてWikidataを表現すること。
• KGTKのインポートおよび変換パイプラインを用いて、WikidataおよびDBpediaのデータをローカルのSQLiteデータベースに読み込み、効率的なクエリを可能にすること。
• KGTKのハイパーリレーショナルモデルに特化したCypherのサブセットとしてKypherを実装し、大規模なグラフサブセットにおけるパターンマッチングと集計処理をサポートすること。
• コンパクトなストレージ（SPARQLの718GB対比142GB）、焦点を当てたインデックス作成、更新のオーバーヘッドがない読み取り専用実行により、クエリパフォーマンスを最適化すること。
• Jupyterノートブックを用いてKypherクエリを実行・ベンチマークし、繰り返し実行を高速化するための事前構築済みインデックスを活用すること。
• 制御された条件下で、ラップトップ上のKypherのパフォーマンスを、ローカルにクローンされたWikidata上のSPARQLクエリおよび公開Wikidata SPARQLエンドポイントのSPARQLクエリと比較すること。

実験結果

リサーチクエスチョン

• RQ1 Kypherは、公開SPARQLエンドポイントの5分間のタイムアウト制限を超える複雑で大規模なWikidataクエリを実行可能か？
• RQ2 DBpediaなどの外部ソースと組み合わせた、パーソナライズされた拡張知識グラフを、ラップトップ上で効率的に構築・クエリ可能か？
• RQ3 Kypherのパフォーマンスは、全Wikidataサブセットに対する分析クエリを実行する際、SPARQLエンドポイントと比べてどの程度優れているか？
• RQ4 KGTKおよびKypherにおけるどのようなアーキテクチャ的選択が、低リソース環境でも優れたパフォーマンスを実現しているか？

主な発見

• Kypherは、32GBのラップトップ上で、全Wikidataに対する複雑なクエリを2時間未塔で完了した。一方、24時間のサーバー上で同等のSPARQLクエリはタイムアウトで完了しなかった。
• Kypherを含むJupyterノートブックの初回実行は349分（5.8時間）を要したが、データとインデックスを事前ロードした2回目の実行では164分（2.7時間）にまで短縮され、初期セットアップ後のパフォーマンス向上が顕著に確認された。
• 同じクエリに対して、Kypherは公開Wikidata SPARQLエンドポイントよりも5倍のパフォーマンス向上を達成した。一部のユースケースでは、ラップトップ上で数分で完了するのに対し、サーバー上では数時間かかっていた。
• コンパクトなKGTKデータモデルにより、ストレージサイズはSPARQLの718GBからKypherの142GBにまで削減され、I/Oの局所性とキャッシュ効率が向上した。
• P279starのようなグラフスライスの専用インデックス化により、一般のトリプルストアよりも再利用が速く、クエリ実行がより効率的になった。
• Kypherの読み取り専用設計により、トランザクション更新のオーバーヘッドが排除され、分析ワークロードにおいて一般のSPARQLエンドポイントよりも高速に動作した。