Googleデータセットサーチの構成とオープンデータエコシステムの育成(1/2)

１．Googleデータセットサーチの仕組みとオープンデータエコシステムの育成(1/2)まとめ

・Google Dataset Searchの仕組みの解説
・schema.orgのオープンで標準的な記述ルールを使用している
・Googleナレッジグラフの各項目とも一致するか比較されている

２．Googleデータセットサーチの仕組み

以下、ai.googleblog.comより「Building Google Dataset Search and Fostering an Open Data Ecosystem」の意訳です。2/2はこちら

今月初めに、研究者が自分の仕事に役立つデータセットを見つけやすくするためのツールであるGoogle Dataset Searchの提供を開始しました。私達はGoogle Dataset Searchを「データのためのGoogle Scholar」と呼んでいますが、Web上の何千ものリポジトリにある何百万ものデータセットのメタデータを検索する検索エンジンです。

注）Google ScholarはGoogleが提供する論文専用の検索エンジン

この記事では、データセット検索がどのような仕組みで構築されているのか、オープンなデータエコシステムを育成するために役立つと思われる概略を説明し、データセット検索の開始以来頻繁に受け取った質問「私のデータセットがGoogle Dataset Searchで検索できないのは何故ですか？」について答えます。

概要
Google Data Searchは、schema.orgのオープンで標準的な記述ルールを使用してサイトに構造化したメタデータを追加してくれている大小のデータセットプロバイダに依存しています。

メタデータでは、各データセットの特性（名前や説明、空間的および時間的カバレッジ、出所情報など）を指定できます。データセット検索はこのメタデータを使用し、Googleで利用できる他のリソースとリンクさせます。そして、メタデータからこの豊富な言語資料への索引(インデックス)を作成します。このインデックスにより、ユーザーの検索語(クエリ)への回答を素早く、そして最も関連が高いデータセットを表示させることができるのです。

データプロバイダが提供するschema.orgの構造化メタデータを使用する
Googleの検索ボットがWebページを処理するとき、そのページ内にDatasetが存在する事がschema.orgの定義を使って記述されていたら、ボットはそのページにデータセットが存在する事がわかります。そして、ページ上のデータセット情報を検索用に保存するレコードを作成する処理を行います。schema.orgを使用することで、ページの作成者はデータセットの情報をHTMLに埋め込むことができ、ページの外観に影響を与えずに、構造化されたデータセットの情報を全て検索エンジンに明らかにすることができます。

しかし、schema.orgの定義やガイドラインがどれほど正確であっても、ネット上のデータセットには必然的に不完全、もしくは間違っている、または完全に欠落しているメタデータが存在するでしょう。さらに、いくつかのフィールドの定義はあいまいかもしれません。そのデータセットは「パブリッシャ」が提供しているものと見なすべきなのか「プロバイダ」が提供しているものとみなすべきなのかなど。あるデータセットの作り方について記述した論文と使い方について記述した論文をどのように区別する方法があるでしょう？実際、これらの質問の多くは、しばしば積極的な学問的議論を生み出します。

このように様々な差異は存在しますが、データセット検索は、統一された使いやすい操作感を提供する必要があります。したがって、複数のフィールドから取得した値、たとえば、「出版者（パブリッシャー）」と「作成者（クリエーター）」などを表示するために、場合によっては、より一般的なフィールド名「提供元」などを使用する場合があります。

他のケースでは、一部のフィールドは使用することができません。特定のフィールドがデータセットプロバイダによってさまざまな方法で誤って解釈されている場合は、そのフィールドを現在は取り扱わず、コミュニティと協力してガイドラインを明確にしていきます。

個々の決断を下す際「データを発見するために最も役立つ事は何ですか？」という質問に繰り返し立ち戻りました。この質問は、難しいケースでも常に私たちの助けになり、この質問に焦点を当てることで、最初に感じたよりも問題をスムーズに解決できる事もありました。

データセットの複製を結びつける
データセット、特に人気のあるデータセットが複数のサイトに保管されていることは非常に一般的です。 2つのデータセットが相互の複製（レプリカ）であるかどうかを判断するために、さまざまな信号を確認します。

たとえば、schema.orgにはsameAsを使用して明示的にレプリカを指定する方法があります。これは、異なるレプリカをリンクし、データセットの標準ソースを指定する最良の方法です。

他には、
・2つの異なるデータセットが同じページをcanonicalタグで指定する
・同じデジタルオブジェクト識別子（DOI）を有する
・データセットをダウンロードするためのリンクが共有されている
・他のメタデータフィールドに大きな重複記述がある
などが信号です。

データセットが完全に異なっていれば、これらの信号は現れないため、これらは2つのデータセットが同じであることを強く示唆します。

Googleナレッジグラフとの調整

Googleナレッジグラフとは著名人などを検索した際に右側に現れる関連情報が一括で表示されるボックスの事

Google’s Knowledge Graphは、多くの概念をまとめて記述し、それぞれをリンクする強力なプラットフォームです。そして、データセットのメタデータと共通な項目（データセットを提供する組織、データがカバレッジする範囲、資金提供機関など）を含みます。そのため、私達はデータセット検索のメタデータに記載されている情報とナレッジグラフの項目を照合しようと試みます。

私たちは、2つの主な理由から、この照合を精度良く行うことができます。まず、私達はナレッジ・グラフ内のアイテムのタイプと、メタデータ・フィールドで期待できるエンティティのタイプを知っています。したがって、特定のメタデータフィールドの値と一致するナレッジ・グラフ内のエンティティのタイプを限定することができます。たとえば、データセットの「プロバイダ」は、ナレッジグラフの「組織」エンティティと一致するかもしれませんが、「場所」と一致する必要はありません。

第2に、Webページそれ自身の文脈が、選択肢の数を減らすのに役立ちます。これは、同じ頭字語を共有する組織を区別するのに特に便利です。例えば、CAMRAという頭字語は「Chilbolton Advanced Meteorological Radar(チルボルトン先進気象レーダー)」または「Campaign for Real Ale(本当のビールのためのキャンペーン)」の両方を表現する事ができます。 Webページの内容を確認すると、ページ上に「雲」、「蒸気」、「水」などの用語が表示された場合、CAMRAが実際はChilbolton Advanced Meteorological Radarであることをより簡単に判断できます。

こういったタイプの調整により、ユーザーの検索利便性を向上させる可能性が広がります。たとえば、データセット検索ではデータセットが掲載されているページと同じ言語でメタデータが記述されていると推測することで結果をローカライズ(地域毎に最適化)する事ができます。さらに、検索語を、同義語、スペルミス、頭字語などに拡張して検索させるためにナレッジグラフの関係するエンティティを使用することができます。