DEIM Forum 2023 2a-6-1

エンティティリンキング機能を有する
知識ベースと外部情報源の統合利用手法
大森 雄基†

北川 博之††

天笠俊之†††† 筑波大学大学院 システム情報工学研究群 〒 305–8577 茨城県つくば市天王台 1 丁目 1–1†† 筑波大学 国際統合睡眠医科学研究機構 〒 305–8577 茨城県つくば市天王台 1 丁目 1–1††† 筑波大学 計算科学研究センター 〒 305–8577 茨城県つくば市天王台 1 丁目 1–1
E-mail: †omori.yuki.sm@alumni.tsukuba.ac.jp, ††kitagawa@cs.tsukuba.ac.jp, †††amagasa@cs.tsukuba.ac.jp
あらまし

知識ベースとは，主語・述語・目的語の組の集合である RDF 形式で人間の持つ知識を集積したものであり，様々な知識処理における重要な情報源として活用が進められつつある．しかし，気象情報や運行情報などの即時性が重要な情報や，詳細で専門的な知識など，知識ベース以外の情報源も多く，知識ベースと外部情報源の統合利用
により多様な応用に対応することが期待される．一方で，外部情報源の入出力形式は多様であり，その出力結果に知識ベースのエンティティを選出する問題も存在するため，知識ベースと外部情報源の統合利用は一般に極めて煩雑となる．本研究では，SPARQL の Magic Properties を利用することで外部情報源を知識ベースと一体として活用できる統合利用環境のアーキテクチャを示す．またその際に重要となる，外部情報源が出力する情報に適切な知識ベースのエンティティを選出するエンティティリンキングについても議論する．
キーワード 知識グラフ, SPARQL, データ統合技術, エンティティリンキング, 問合せ処理
セスし，外部情報源をあたかも知識ベースと一体であるかのよ

1 はじめに近年，人類の保有する知識の増大ともに，これらの知識を構造化して保持する RDF 形式の知識ベースと，これに対する問合せ言語である SPARQL の利用環境が構築され，様々な知識処理における重要な情報源として活用が進められつつある．しかし，知識の全てが知識ベースに集積されているわけではな
い．例えば，気象情報や交通機関の運行情報といった即時性が重要な情報は静的な集積という形式はそぐわない．また，専門的な知識などを提供する知識ベース以外の情報源も多い．このため，これらの情報を有効活用するためには，知識ベースと非知識ベースの外部情報源の連携利用が重要となっている．
しかしながら，外部情報源は，問合せとその返り値に独自の形式を持つことが多く，この形式に対応して情報を解釈する必要がある．このため，知識ベースと外部情報源の連携には，外部情報源の多様な形式に対応しつつ，知識ベースと外部情報源の両方の結果を突き合わせるなど，極めて手間のかかる作業が必要となる．また，外部情報源からの得られるオブジェクトが，知識ベース中のどのエンティティにあたるかは，そのままでは不明であり，これを人手で判別するのも極めて大変な作業となる．例えば，外部情報源として地図情報を利用して特定の駅から近い教会を検索し，知識ベースの情報を利用して教派を絞り込みをする場合，地図上のオブジェクトと知識ベース上のエン
ティティの対応を一つ一つ検討し，集約する必要がある．このような問題に対応するには，知識ベースと外部情報源に対して，統合的に問合せが出来ることが重要となる．
これを受けて本研究では，図 1 のように，外部情報源にアクうに扱える統合利用環境のアーキテクチャを提案する．
本研究のアーキテクチャは以下の 2 点である．

(1) Magic Properties を利用して外部情報源にアクセスし，取得した値を問合せ結果に組み込む．Magic Properties とは，知識ベース検索に対する問合せ言語 SPARQL において，様々な応用に対応した知識利用のために設定可能な独自の述語 [1] である．これは，もともとは SPARQL 問合せ中に応用に応じた計算手続きを組み込むための機能 [2] であるが，本研究では外部情報源へのアクセスに転用する．

(2) 外部情報源から得られるオブジェクトに対して，知識ベー
ス中の適切なエンティティを選択する，エンティティリンキン
グの機能を有する．
なお，これ以降，Magic Properties を利用して外部情報源にアクセスする関数を呼び出す述語を，External Source Predicate(ESP) と呼ぶ．また，既存の知識ベース中の述語を Knowledge
Base Predicate (KBP) と呼ぶ．
本提案手法により，例えば外部情報源である地図情報源を用
いて，「つくば市の設立日と隣接する都市」を探す処理は，ESP<udp:m:AdminDivNext>を用いて以下のような SPARQL 問合せで記述できる．

SELECT DISTINCT * WHERE {?x rdfs:label "Tsukuba"@en .
?x rdf:type dbo:City .
?x dbp:establishedDate ?date .
?x <udp:m:AdminDivNext> ?y.}このとき エンティティ ?x から
udp:m:AdminDivNext?x −−−−−−−−−−−→?yン [4] という技術がある．
フェデレーションは複数のエンドポイントに問合せを行う．
統計情報を使うもの [5] [6] [7]，RDF のデータセットに関するス
キーマ定義である VoID [8] を使うもの [9]，ASK クエリを使う
もの [9] [10]，複数の方式を組み合わせるもの [11] などがある．
本研究では知識ベースだけではなく，SPARQL で問合せできない外部情報源も利用するため，これに合わせたアーキテク
チャを設計する．

2. 2 メディエータ
意味的な情報を利用して異種情報源を統合するため，外部情報源に知識ベースに利用されるオントロジーを与える方式がある [12]．各外部情報源を取り込むために，様々な変換規則の置き方が提案されている [12]．
本研究は，たとえ同名であっても異なるエンティティを識別する問題を取り扱う必要があるため，オントロジーに対応する変換規則を定めただけでは問題を解決できない．このため，エ
図1

本研究が提案するアーキテクチャ

ンティティリンキングを応用して外部情報源のオブジェクトと知識ベース上のエンティティの対応関係をとる．

を 満 た す エ ン ティティ ?y を 探 す 処 理 は ，ESP で あ る

udp:m:AdminDivNext が外部情報源の地図情報源に問合せて

2. 3 エンティティリンキング

地図上でエンティティ ?x が対応するポリゴンが隣接するポリゴ

エンティティリンキングとは，自然言語中の現実の物事を指ンをもつオブジェクトを検索し，そのオブジェクトを知識ベー

し示す語句に対して，知識ベース中の同一の物事を指すエン

ス中のエンティティ ?y にエンティティリンキングすることでティティを割り当てる行為である [13]．文章中からエンティティ

実現する．

を割り当てるべき語句 (mention) を特定する Mention Detec-

本研究の貢献は以下の通りである．

tion と，mention に該当する可能性のあるエンティティを選出

1. Magic Properties を利用した ESP が外部情報源にアクする Candidate Selection，そこからエンティティを絞り込むセスする関数を呼び出すことによって，エンティティ間の述語の拡張を行うアーキテクチャの提案と実装．

Linking Decision の段階に分けられる [14]．
Linking Decision に候補エンティティ同士の関連性を用いる

2. 外部情報源から得られるオブジェクトに対応する知識方法としては，TAGME [15] がある．これは，Wikipedia のア

ベース中のエンティティを探さなければならないという問題をンカーリンクの行先の重複度を利用してエンティティ間の関連

認識し，外部情報源から得られるオブジェクトに対する複数の，の強さを計算する．また，DoSeR [16] はエンティティ間の関係

エンティティリンキング手法の設計．

をページランクで計算する．また，エンティティに付属する文書

3. プロトタイプをシステムと複数の問合せを用いた作成し，複数のエンティティリンキング手法の精度評価を利用した手法も存在する [17] [18]．また，エンティティ同士およびエンティティと語句の参照関係からエンティティと単語の埋

本論文の以降の部分は以下の構成である．第 2 章では関連研め込みを学習する手法も存在する [19]．一方，近年はニューラル

究を説明する．第 3 章では，この研究に関わる前提知識についネットワークを用いた手法も盛んであり [14]，Yamada ら [20]て述べる．第 4 章では，提案手法のアーキテクチャについて説は，BERT を用いて単語とエンティティを同時に入力とするこ

明する．第 5 章では，本研究のエンティティリンキングの要件とによるリンキングを行っている．

と，複数のエンティティリンキング手法について述べる．第 6

本研究では自然言語ではなく，外部情報源から得られるオブ

章では，実験について述べる．第 7 章では，本研究のまとめをジェクトを知識ベースに統合するという問題を扱うため，これ述べる．

に合わせてエンティティリンキング法を設計する．

2 関連研究3 前提知識2. 1 フェデレーション

3. 1 RDF

RDF 形式の知識ベースは，複数のデータセット間で共通の語

RDF とは，主語・述語・目的語のタプルとして，情報を記彙を使ったり，相互にリンクしているために，複数のエンドポイ

述したもの [21] [22] で，意味的な情報を記述することにも用い

ントに統合的に問合せをする需要がある．問合せ側がエンドポられる．主語には，現実の概念に対応する概念を IRI 1 としてイントを指定する SERVICE 句を用いる手法 [3] や，SPARQLを用いて複数の知識ベースを統合的に検索するフェデレーショ

1：URI を Unicode 文字で拡張したもの．

示したエンティティを持つ．目的語には，エンティティの IRI
もしくは 数値や文字列などのリテラルを持つ．また，述語は，主語と目的語の関係を示す IRI を持つ．
例えば，Dbpedia 上で『筑波大学はつくば市にある。』を示
す RDF 記述は以下のようになる．
dbo:city

dbr:University of Tsukuba −−−−−→ dbr:Tsukuba
3. 2 SPARQLRDF 形式の知識ベースの検索には，問合せ言語 SPARQL が通常用いられる．SPARQL 問合せは，RDF 記述に対応した知識グラフに対するパタンマッチングを行い，目的とする情報を取得する [23]．問合せの結果は変数に対応するタプルの集合であり，各変数を列名とする表として表記できる．

図2

生年月日から年齢を計算する Magic Property の例

4 提案アーキテクチャ
4. 1 拡張知識ベースの定義

例として，以下の問合せを示す．

SELECT DISTINCT * WHERE{?x rdfs:label

Jeffrey Ullman"@en . }WHERE 以下は Where 句と呼ばれ，RDF に対するマッチングのパターンを示すグラフパターンを定めている．このパターンの最も基本的な部品は，上記に述べた RDF に対応する主語・述語・目的語である．主語は IRI もしくは空ノード，変数が入る．また目的語は IRI・空ノード・リテラル，そして変数をとる．また，述語は IRI と変数が入る．主語・述語・目的語の組を Triple Pattern と呼び，RDF のトリプルの不明部分を変数に変えたものに相当する．Triple Pattern の集合を，BasicGraph Pattern (BGP) と呼び，WHERE 句の基本的な中身となる．以上の問合せを実行すると，Jeﬀrey Ullman を指し示す
エンティティが変数 ?x の列に得られる．

3. 3 Magic Properties

図 3 ESP を利用したクエリ例をグラフとして示したもの．左側が問合せのグラフ．右側が対応する知識ベース中の部分グラフと，

ESP による拡張を表す．

本研究では，知識ベース中のエンティティ間の関係を，外部情報源から取得した関係を示す述語 External Source Predicate(ESP) で拡張する．
図 3 は，ESP が知識グラフを拡張することを示した図である．知識ベース中には，dbr:Tsukuba や dbr:Ushiku など

SPARQL 処理系には独自のユーザ定義述語を設定する機能が様々なエンティティやリテラルが，知識ベースの述語である

ある [1] [24]．この機能は，知識ベースに対する様々な応用に知Knowledge Base Predicate (KBP) で接続されている．このと識利用する際，SPARQL 問合せ中に応用に応じた計算手続きをき，知識グラフを拡張するための外部情報源の例として，例え組み込むためのものである [2]．これを利用するには，少なくとば，Openstreetmap (OSM) を利用することを考える．OSM

もユーザ定義の述語に対して，主語が決まった場合の目的語のは，オープンライセンスの地図アプリケーションであり，地図算出方法，またはその逆が必要である．例えば図 2 は，既存のとしての閲覧が可能であるのみならず，地図上の地物が xml

トリプルから生年月日を取得し，年齢を計算するユーザ定義述

形式でまとめられている．OSM の地物には，その座標やポリ語を作る例である．udp:Age は年齢を指す Magic Property で

ゴン・地物間の関係を示すデータと，属性を定めるための Tagある．これがクエリ中に述語として記述された場合，年齢を計が存在している．このため，OSM 上でつくば市と牛久市が隣算するユーザ定義関数を呼び出す．ユーザ定義関数は，udp:Age

接しているという情報も取得が可能である．これを利用して，の主語に当たる dbr:Jeffly Ulkman を受け取り，OSM 上で自治体のポリゴンが隣接していることを示す KBP

dbo:birthDate

dbr:Jeffly Ulkman −−−−−−−−→ 1945-11-23

である udp:AdminDivNext で dbr:Tsukuba と dbr:Ushiku をというトリプルを取得することで，生年月日を取得し，現在の接続する．以上のようにして，外部情報源を用いて知識ベース

日付から 77 歳と計算できる．これを目的語の値として返す．

を拡張することが可能である．

本研究では，この機能を用いて，外部情報源にアクセスして情報を取得し，知識ベースから得られる情報と統合する．

4. 2 全体のアーキテクチャ
提案手法のアーキテクチャの概要は図 1 に示した通りである．
ユーザは，通常の SPARQL 問合せに本アーキテクチャが提供する ESP を加えることで，通常の SPARQL で知識ベースを検索したときと同様に，前節で示した拡張知識ベースがあたかも存在するかのように問合せることが出来る．このため，知識ベースと外部情報源を統合的に検索可能である．

第 1 章で示した問合せ例では，<udp:m:AdminDivNext> が報源へアクセスに用いるキーを生成，(2) そのキーを用いて外知識ベース中には存在しない述語である ESP となっている．

部情報源にアクセス，(3) 問合せ結果として得られたオブジェ

すなわち，知識ベース中にはこの述語に対応するトリプルはクトに対応する知識ベース中のエンティティを探し出して目的

実在せず，主語に対応するエンティティから目的語に対応す語のエンティティとする必要がある．図 4 は (1),(2),(3) の概要

るエンティティを求めるのは外部情報源を呼び出すことによっ図である．各 ESP における (1)(2) の処理は以下に示すように，て行われる．このとき，知識ベース DBpedia と OSM を用い

ユーザが定義，登録するものとする．よって，ESP の登録時にて『つくば市の設立日と隣接する都市を探したい』という問は以下の事が必要となる．

合せを考える．このとき，つくば市の設立日は KBP である

dbp:establishedDate を用いて知識ベースから取得できる．
一方で，OSM 上で外接する地物が隣接する自治体であること
は ESP である udp:m:AdminDivNext を用いて取得する．したがって，この問合せは以下のように既述可能である．

SELECT DISTINCT * WHERE {?x rdfs:label "Tsukuba"@en .
?x rdf:type dbo:City .
?x dbp:establishedDate ?date .
?x <udp:m:AdminDivNext> ?y.}

図 4 ESP 処理の概要図．外部情報源へアクセスする関数 Access()

ESP は，主語の「つくば市」エンティティから，OSM へ問合せと，ESP の IRI の登録だけは必須である．また，主語エンティる関数を呼び出し，返ってきた自治体名を知識ベース DBpedia

ティから外部情報源アクセス時の生成する関数 Key() も登録す

上のエンティティと照らし合わせて該当するエンティティを返さなければならない．このとき，ESP によって，DBpedia 上には存在しないトリプル
udp:m:AdminDivNext

dbr : Tsukuba −−−−−−−−−−−→ dbr : Ushiku,I barakiが与えられる．
なお，本論文の以下では，議論の簡単化のため，この例のように ESP の目的語はエンティティであるものと仮定するが，それ以外の場合への拡張は容易である．
このアーキテクチャを実現するため，4 つの課題が存在する．

a ) ESP の登録方法
ESP を登録するにあたり，外部情報源の多様性に対応しつつ，ユーザの負担を最小化しなければならない．

る必要があるが，特定の述語の値を利用する場合はその述語を指定するだけでよい．

a ) ESP の IRI
ESP の IRI を 登 録 す る ．例 え ば ESP の IRI と し て
udp:m:AdminDivNext を登録し，問合せ中にこの ESP がある場合，以下に示す問合せ処理では，以下の c) に示す外部情報
源アクセス関数を呼び出す．

b ) エンティティx から外部情報源アクセス時のキーを生成する関数 Key()
上記の (1) の処理を行う関数（プログラムコード）を登録する．エンテイティの名称や座標等を取得し，外部情報源検索のキーとすることが考えられる．上記の例では，主語エンb ) 拡張した SPARQL 問合せの実行

ティティx =dbr:Tsukuba から，rdfs:label を取得すること

ESP によって拡張した知識ベースに対しての SPARQL 問合で Key(x) = {”Tsukuba”} を得る．このように，単純に主語

せのアルゴリズムを開発する必要がある．当然，問合せ中には

エンティティに対して特定の述語の目的語を Key(x) の値とす

ESP が複数含まれ得るため，これを想定したアルゴリズムをる場合には，述語を指定するだけでよい．

設計しなければならない．

c ) 外部情報源のオブジェクトとエンティティの対応c ) 外部情報源アクセス関数 Access()b) で定義した Key(x) により得られるキー keyx を用いて外ESP が得た外部情報源に対する問合せ結果のオブジェクト

部情報源をアクセスする関数（プログラムコード）を登録すと，知識ベース中のエンティティの対応は必ずしも自明ではな

る．すなわち，Access(Key(x)) は，主語エンティティx から

い．例えば，外部情報源が”Fuchū”という文字列を返した場合，

ESP の目的語を外部情報源アクセスにより取得する操作に対応

東京都の府中市を指していたとしても，同名の地名は広島のな

し，R = Access(Key(x)) とすると，R は ESP の目的語のエ

ど全国にあるため，同名のエンティティは多数存在する．ここンティティに対応する外部情報源が出力するオブジェクトの集から，dbr:Fuchū, Tokyo を選ばなければならない．また，略合である．上記の例では，keyx = ”Tsukuba” に対して，OSM

称・別名など，エンティティの名前と外部情報源の示した文字に問合せて隣接する自治体名の集合である R = { ”Tsuchiura”,

列が必ず一致するとは限らない．このため，ESP が得た外部情”Ushiku”... } を返す関数である．

報源から得られるオブジェクトに対応する知識ベース中のエン
ティティを識別するのは容易ではない．

以上 3 項目を登録すれば，本アーキテクチャは問合せにおいて ESP の利用が可能となる．R = Access(Key(x)) のオブジェ
クトと知識ベース上のエンティティとのマッチング Entity() に

4. 3 ESP の登録方法
アーキテクチャにおいて，(1) 主語エンティティから外部情

ついては，アーキテクチャが提供する．この詳細は 4. 5 節と第5 章で述べる．

4. 4 拡張した SPARQL 問合せの実行
本研究における拡張 SPARQL 問合せは，従来の SPARQL
問合せに ESP を加えたものである．SPARQL の Where 句を表す BPG においても ESP を加えたものを取り扱う．BPG は下の点に留意しなければならない．

•

ESP の Key(), Access() を実行する際には，必ず主語のエンティティ x が特定されている必要がある．

•

ESP の Access() や Entity() を実行する際には，外部

Triple Patterns の集合である．Triple Pattern は 主語, 述語,

情報源に対するアクセスとエンティティリンキングが行われる

目的語から構成される．BPG はラベル付き有向グラフである．

ため，待ち時間や少なくない計算時間が発生する．このため，

BPG は変数，エンティティ，リテラルを頂点とする．また，辺

ESP の関数の実行回数はできるだけ少なくなることが望ましい．
•

は KBP で構成される．
ここで，問合せから ESP を除外した時に，残るそれぞれの連結部分グラフを Segment と呼ぶ．図 5 は，ESP を含む

SPARQL 問合せが，ESP を除外することで Segment に分割さ

ESP の Key(), Access() ならびに Entity() を実行後には，ESP に関わるトリプルが判明しているために，KBP と同等の扱いをしてもよい．
以上を留意した問合せ処理の手順は以下による．

Step 1. Triple Pattern を含む Segment について全て知識れることを示した図である．

ベースに問合せを行い，その結果を中間結果表の集合とする．

Step 2. 各 ESP の主語側の中間結果表に基づき，ESP の主語にあたる異なるエンティティの個数を数え，その数がもっとも少ない ESP を選択する．最小の ESP が複数ある場合
は，ランダムに 1 個選択する．

Step 3. 主語側の中間結果表から主語エンティティの集合を抽出し，各エンティティを主語として順次 ESP を評価する．
すなわち，Key(), Access(), Entity() を実行する．結果を
図5

問合せ ESP を除いた時に非連結になる部分を Segment とする．

Segment は，変数，KBP を辺とする．また，Segment 同士
は ESP で接続されている．つまり，各 ESP は主語側と 目的
語側にそれぞれ Segment を持つ．
図 5 に Segment の例を示した．Segment A は，2 つの変数，

中間結果表へ自然結合する．

Step 4. 全ての ESP の処理が終わったかを確認し，未処理のESP が存在する場合は 2 へ戻る．
Step 5. Step 4 までで得られた中間結果表から問合せの最終結果を出力する．

1 つのエンティティを頂点 とし，3 つの KBP を辺として持つ．

ここで，Step 3 についてより詳しく説明する．Step3 では，

ESP 1 は 主語側も目的語側も Segment A 内の頂点であり，

外部情報源にアクセスを行うことで，ESP に対応する主語・目

Segment A 自身を接続している．Segment B は変数を 1 つだ

的語の組の表を得る．この ESP のアクセス結果は繋がりのあけを頂点として持つ．また，ESP 2 は 主語側に Segment A のる中間結果表と join することが可能となる．この点を考慮に変数，目的語側 に B の変数を持つため，主語側を Segment A

入れた Step 3 の詳細を以下に示す．また処理の概要を図??に，目的語側を B として接続していることになる．同様に，ESP示す．

3 は 主語側を Segment A ，目的語側を C として両 Segment

Step 3-1. 中間結果表から主語エンティティ集合を取得すを接続している．ESP 4 は主語側を Segment B ，目的語側を C として接続している．

Segment 内部は通常の SPARQL クエリと同等の BPG であるため，直接知識ベースに対応する SPAQL 問合せを発行してその結果を得ることが可能である．ただし，各 Segment に対する問合せ結果を表す表は，変数のみでなくエンティティを表す
頂点に対応する列も持つものとし，列名と中身の値はそのエンる．ESP の主語が変数の場合は，エンティティ集合を取得する．また，主語がエンティティの場合は，そのエンティティを取得する．

Step 3-2. 主語エンティティ x を外部情報源に対するキー
Key(x) に変換する．
Step 3-3. 外部情報源にアクセスし，目的語に対応するオブ
ジェクトの集合 R = Access(Key(x)) を取得する．

ティティの IRI とする．例えば，Segment A が，変数 ?x, ?y ，

Step 3-4. 各外部情報源オブジェクト r ∈ R について，適

エンティティ E を持つとき，Segment A の問合せ結果は ?x,

切なエンティティy = Entity(r) を割り当てる．ただし，?y, E を列名とする表として表記する．

適切なエンテイティが発見できない場合は，存在しない

ESP の主語エンティティを x とすると，ユーザが登録しと判定する．この Step の詳細は次の節に述べる．

た Key()，Access() を用いて，外部情報源のアクセス結果，

Step 3-5. 主語側および目的語側の中間結果表を自然結合しAccess(Key(x)) が得られる．また，この要素オブジェクトをr ∈ R に対して，4. 5 に示すエンティティリンキングにより，
ESP の目的語エンティティを y = Entity(r) を得る．
これらの処理を含む問合せアルゴリズムを設計する上では以て，中間結果表の集合を更新する．

4. 5 外部情報源のオブジェクトとエンティティの対応
R = Access(Key(x)) は，対応する外部情報源オブジェク
トの集合であるため，それぞれの r ∈ R に対して知識ベース

中のエンティティを探し出して，ESP の目的語エンティティ

y = Entity(r) として返す必要がある．また，対応するエン

致，もしくは辞書側の先頭の 1,2 単語を除いた先頭一致を行う．
例えば，Wikipedia 中の語句 ”University of Tsukuba” から，ティティが知識ベース中に無い場合，存在しないと判定する必

https://en.wikipedia.org/wiki/University_of_Tsukuba

要がある．

へ飛ぶアンカーリンクが存在する．このとき，対応する DB-

pedia の IRI は dbr:University_of_Tsukuba となる．このた

これは以下の手順による．

Step 3-4-1. 外部情報源オブジェクト r ∈ R に対する候補′

め，辞書には

エンティティ集合 C = CS(m) を選出する．この”University of Tsukuba” → dbr:University_of_Tsukuba

Step を Candidate Selection と呼ぶ．

と登録する．当然，表などで，”Tsukuba”と略されることもあ

Step 3-4-2. もし，ESP の目的語側がエンティティである

るため，か，Triple Pattern に含まれる変数の場合，目的語”Tsukuba” → dbr:University_of_Tsukuba

側の中間結果表から ESP の目的語となり得るエも 登 録 さ れ る ．ま た ，つ く ば 市 を 示 す dbr:Tsukuba

ンティティの集合（Allow set と呼ぶ） A を取得し，も，”Tsukuba”のアンカーリンクで参照されるため，′

C = C ∩A とする．また，目的語側が Triple Pattern”Tsukuba” → dbr:Tsukuba も登録される．

に含まれない変数の場合は，C = C ′ とする．

も し ，外 部 情 報 源 が r = ”University of Tsukuba”と いStep 3-4-3. 主語エンティティx と候補エンティティc ∈ C

う 文 字 列 で あった と き ，DictCS は ，辞 書 を”University ofとの関連から，各外部情報源オブジェクトに対する

Tsukuba”，”of Tsukuba”，”Tsukuba”で検索する．このため，

割当エンティティy = LD(C, x) を出力する．あるい

dbr:University_of_Tsukuba，dbr:Tsukuba

は，割当るべきエンティティは存在しないと判定すが候補エンティティ集合として返される．

る．この Step を Linking Decision と呼ぶ．
本研究では 2 種類の Candidate Selection CS()，2 種類のLinking Decision LD() を用いる．この詳細は第 5 章 に示す．

外部情報源から取得した文字列 r が，b ) LabelCS
rdfs:label 中の単語列に対して，単語単位で部分一致する
エンティティを候補とする．

5 エンティティリンキング
外部情報源から取得する r ∈ R は外部情報源中のオブジェク
トであるため，これが知識ベース上のどのエンティティにあたるかを判定する必要がある．本研究では，外部情報源から得られる外部情報源オブジェクト r は文字列であると仮定する．
第 4. 5 節で説明した通り，外部情報源の文字列とエンティ
ティの対応関係をとるアルゴリズムは 3Step からなる．このう
ち，Step 3-4-1 の Candidate Selection (CS) と，Step 3-4-3 のLinking Decision (LD) について，それぞれ 2 つの手法を提案
する．

5. 1 Candidate Selection (CS)
知識ベース中の全てのエンティティに対して割当エンティティに該当するかを確認することは，計算コスト上望ましくない．
そこで，外部情報源から取得した文字列 r ∈ R から文字列を使ったマッチングを行い，候補エンティティの集合 C ′ = CS(r)を得る．以下，2 つのアルゴリズムを用意した．

a ) DictCS
事前に用意した語句と候補エンティティとの対応辞書を用いる．この辞書の構築には，Wikipedia から辞書を構築する手法
を含む研究 [13] [25] [26] を参考に，英語版 Wikipedia から収集した記事名とアンカーリンク情報を利用する．アンカーリンク
は，Wikipedia の文書中の語句から Wikipedia ページへ飛ぶ
リンクであり，語句と Wikipedia ページの対応関係が得られる．知識ベース DBpedia のエンティティと Wikipedia ページ
は一対一対応となっており，Wikipedia ページの文字列変換でDBpedia エンティティの IRI を得られる．辞書検索時に先頭一

例えば，外部情報源が r = ”Tsukuba”という文字列であったとき，
rdfs:label

dbr:University of Tsukuba −−−−−−→ University of Tsukuba
rdfs:label

dbr:Tsukuba −−−−−−→ ”Tsukuba”
が合致する．しかし，
rdfs:label

dbr:Tsukubamirai −−−−−−→ ”Tsukubamirai”
は単語としては一致しないために，候補としない．

5. 2 Linking Decision (LD)
候補エンティティ集合 C から，割当エンティティy = LD(C, x)を返す．あるいは該当無しと判定する．
候補エンティティ集合 C のうち，外部情報源の返した値 r に対応するエンティティ y ∈ C は，ESP と共に新たなトリプルを構成する．このため，ESP の主語エンティティ x とは，何らかの関係があると期待される．このため，LD では主語エン
ティティ x と 候補エンティティ c ∈ C の関係を知識ベース上から取得し，もっとも関係が強いエンティティを返す．この考えのもと，以下の 2 つのアルゴリズムを示す．

a ) GraphVoteLD
この方法は，TAGME [15] を参考にした方法である．2 つのエンティティ t, c の関連度 rel(t, c) を定義する．まず，t,c に相当する Wikipedia ページをそれぞれ wt , wc とする．次に，wt ,wc からアンカーリンクをたどって到達できるページの集合を
Wt , Wc とする．このとき，rel(t, c) = |Wt ∩ Wc | とする．つまり，wt , wc から共通にたどれるページの数として rel(t, c) を定義する．
また，主語エンティティx から知識ベース上で任意のをたどって得られる目的語エンティティの集合に，x 自身を加えたもの

エンティティを返す．一般的に地理的なエンティティであってを文脈エンティティ集合 ctx(x) とする．
全ての候補エンティティc に対して，x の文脈エンティティ

も，DBpedia 中の全てのエンティティに座標情報がついている

集合 t ∈ ctx(x) との関連度 rel(t, c) を計算し，合計が最大であ∑るものを y とする．すなわち，y = arg max
rel(t, c) とわけではないので，距離を扱う際には地図サービスに問合せるct∈ctx(x)する．ただし，この合計が閾値以下のとき該当する y は無しとする．

ことが望ましい．この ESP によって，知識ベースを拡張する．
この環境のもと，異なる性質の BPG をもつ８つの拡張

SPARQL 問合せを実行し，その結果の妥当性を検証した．8 つの問合せの正解は著者が作成した．提案手法の問合せ結果と正b ) AbstractCosSimLD
主語エンティティx の dbo:abstract の値，および c ∈ C の

dbo:abstract の値の単語集合の Cosine 類似度を計算し，最大であるものを y とする．

解データの表を，行の集合として扱い，Recall, Precision, F1を算出した．

6. 2 ベースライン手法
提案手法と同等の機能を有する既存の手法は存在しないが，

6 実

験

6. 1 実 験 環 境
本研究のアーキテクチャは，外部情報源から取得したオブジェクト r に対し，エンティティリンキングを用いて該当する
知識ベース中のエンティティ y を選ぶという構造上，問合せ

エンティティリンキングの性能比較のため，外部情報源の返した文字列 r を英語版 wikipedia で検索した場合の結果得られるエンテイティを ESP の目的語とする手法（enWikiSearchと呼ぶ）をベースライン手法とした．この実装には，Pythonの”wikipedia”パッケージを利用した．

に対する実行結果は曖昧性を持つこととなる．このため，エン

6. 3 実 験 結 果

ティティリンキングを組み込んだアルゴリズムが，問合せに対

表1

call (R), Precision (P), F1．”-”はエンティティを選出しなかっしてどの程度正確な問合せ実行を行うのかを検証する．また，併せて実際に 4. 4 に示したアルゴリズムで問合せを実行できるかも検証するため，アーキテクチャのプロトタイプを作成し，ESP を登録したうえで，問合せを実行する実験を行った．
実験に使用する知識ベースは英語版 DBpedia の 2020 年 6 月のスナップショットである．これは英語版 Wikipedia を RDF
形式に変換したものである [27]．また，外部情報源には地図サー
ビス OpenStreetMap (OSM) を用いる．

ESP は，OSM の検索サービスである Nominatim と Overpass を，OSM node の英語名を基に検索し，エンティティ
リンキングを行って目的語のエンティティを返す．例えば，

udp:m:AdminDivNext の主語エンティティ x = dbr:Tsukuba
から，rdfs:label をたどって文字列 ”Tsukuba” = Key(x) を得る．”Tsukuba”をキーとして Nominatim と Overpass に問合せると，つくば市と境界線を共有する OSM オブジェクトの情報を含んだ xml が返ってくるため，ここから隣接自治体名の文字列の集合を抜き出して外部情報源の返す値 R = Access(Key(x))とする ．この値の一つである ”Ushiku” = r ∈ R に対して，
エンティティリンキングを行うことで，dbr:Ushiku, Ibaraki= y = Entity(r) を得る．これにより，
udp:m:AdminDivNext

dbr:Tsukuba −−−−−−−−−−−→ Ushiku, Ibarakiというトリプルを構築し，知識ベースを拡張する．
本研究では以下 4 つの ESP を用意した．

a ) <udp:m:AdminDivNext>

各問合せと，各 CS, LD 及びベースライン (Wikipedia) の Reたことを表す．平均の計算からは除外する．

CS
LD

DictCS
LabelCS
Graph
Abstract
Graph
Abstract
enWikiSearch
VoteLD
CosSimLD
VoteLD
CosSimLD
R
P
F1 R P F1 RP
F1RP F1 R P F1
Q1 1.0 1.0 1.0 0.89 1.0 0.94 1.0 1.0 1.0 0.89 1.0 0.94 0.33 0.33 0.33
Q2 1.0 1.0 1.0 0.89 1.0 0.94 1.0 1.0 1.0 0.89 1.0 0.94 0.33 1.0 0.5
Q3 0.67 0.29 0.4 0.67 0.13 0.22 0.67 0.33 0.44 0.67 0.2 0.31 Q4 0.75 1.0 0.86 0.75 0.75 0.75 0.75 1.0 0.86 0.75 1.0 0.86 Q5 0.86 0.86 0.86 0.86 0.4 0.55 0.43 0.75 0.55 0.43 0.38 0.4
Q6 1.0 0.67 0.8 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 0.5 1.0 0.67
Q7 0.93 0.46 0.62 0.64 0.53 0.58 0.93 0.72 0.81 0.64 0.64 0.64 Q8 0.93 0.65 0.76 0.64 0.5 0.56 0.93 0.62 0.74 0.64 0.53 0.58 Avl. 0.89 0.74 0.79 0.79 0.66 0.69 0.84 0.80 0.80 0.74 0.72 0.71 0.39 0.78 0.50

実験結果を Table 1 に示す．実験結果の評価は，正解の各問合せの結果と，統合環境の問合せ結果を行の集合と見なし，Recall, Precision, F1 を算出したものである．なお，Recall,
Precision, F1 が空欄の部分は，統合環境が，全ての r ∈ R について，エンティティが無いと判定したことを示す．
提案手法は，全ての問合せについて，ベースライン手法を上回った．また，Query1, 2 では LD に GraphVoteLD を用いた場合が全て正解となった．また，Query5, 8 以外は，LabelCS,

GraphVoteLD とした場合の性能が最も良く，Query8 についても僅差であった．しかし，Query5 では半分以上の行を見つけることが出来なかった．

6. 4 考察

前述の通り，全ての CS と LD の組み合わせでベースライン

主語のエンティティに隣接する行政区画のエンティティを目手法を上回っている．ベースライン手法の enWikiSearch 方式的語とする．隣接自治体の情報は DBpedia では多くないため，は英語版 Wikipedia の検索ウィンドウで検索したものを自動化

この ESP の導入によって知識ベースを拡張する．

した場合に相当するが，結果は入力キーワードのみに依存するb ) <udp:m:Dist1km>, <udp:m:Dist5km>, <udp:m:Dist10km> ため，キーワードが多義的であった場合に正しいエンティティ
座標付きエンティティに対し，その座標から 1km, 5km 10kmを選出できない．一方で，エンティティリンキングを組み込ん以内にある OSM node を検索し，その英語名を基に目的語のだ提案手法は，グラフ関係や Abstract 文書との比較から，ある程度正しいエンティティを選ぶことが出来る．ただし，Query3の dbo:abstract 中にある概要文書は，下に示した通り，100

では，Precision が極めて低い．Query3 は，「つくば市の代表点

語以下であり，人口・人口密度・面積といった記述で埋まって（市役所）から 5km の駅」を問合せるものである．これに対し，いる．このような傾向から，AbstractCosSimLD が有効に働かOpenstreetmap は 361 件の node の名前を返したが， このう

なかった場面があったと考えられる．逆に，トリプル数が少な

ち駅は 4 件である．このため，偶然無関係な建物と名前が一致

いが概要文書はある程度書かれている事が期待されるエンティ

した駅が紛れてしまったことにより，不正解の行が数多く発生

ティを対象とする場合には，概要文書を利用する方式が有効にした．このことから，外部情報源が最終的な問合せ結果に対応なる可能性がある．

しないオブジェクトを大量に返した場合は，性能が低下すると

dbr:Tsukubamirai, Ibaraki の概要文書考えられる．

Tsukubamirai (つくばみらい市, Tsukubamirai-shi) is a city
located in Ibaraki Prefecture, Japan. As of 1 October 2020,

表 2 CS の性能比較．全ての候補エンティティを返し，LD を行わない場合の結果．

CS

DictCS
Recall Precision
Q1 1.00
0.16
Q2 1.00
1.00
Q3 1.00
0.04
Q4 1.00
0.80
Q5 0.86
0.17
Q6 1.00
0.40
Q7 0.930.23
Q8 0.93
0.22

F1
0.28
1.00
0.08
0.89
0.29
0.57
0.37
0.35

LabelCS
Recall Precision
1.00
0.13
1.00
1.00
0.67
0.04
0.75
1.00
0.43
0.13
1.00
1.00
0.93
0.72
0.93
0.62

the city had an estimated population of 51,035 in 20,030
households and a population density of 645 persons per km².

F1
0.22
1.00
0.08
0.86
0.20
1.00
0.81
0.74

Candidate Selection (CS) を軸に見ていくと，多くの組み合わせで LabelCS 方式が上回っている．また，Precision だけを見ても上回る場合が多い．DictCS 方式は辞書の作成時にWikipedia 中のアンカーリンク元の文字列を利用しているため，表記ゆれや略称等に対応しやすい．一方で，LabelCS 方式
は，rdfs:label の文字列を用いた辞書であるため，略称等は含まない場合が多い．このため，一般的に言えば，LabelCS 方式よりも DictCS の方が多くのエンティティを選出できると考えられ，Recall も向上できると期待できる．表 2 は，CS のみを行い，LD を行わずに全ての候補エンティティを結果として出力した場合の Recall, Precision, F1 を示したものである．ただし，目的語側 の中間結果表の制約は受けるものとする．表2 より，DictCS が発見した正解のエンティティは LabelCS に比べ多いものの，半数以上の問合せで同数であった．一方で，DictCS は LabelCS に比べ間違ったエンティティを含んでしまう傾向がある．また，Query5 では LabelCS は正解のエンティ
ティを半分以上発見できなかった一方，DictCS は多くの正解のエンティティを発見した．本実験では，外部情報源に OSM

node の英語名を利用しているという性質上，略語の利用は少ないと考えられる．略語や表記ゆれの探索による候補エンティ
ティの増加は，有効なエンティティの選出に寄与せず，表 2 のように Query5 以外ではむしろ不要なエンティティを増加させた．このため，DictCS は性能を下げた可能性がある．

Linking Decision (LD) を 軸 に 見 て い く と ，概 ねGraphVoteLD 方式の性能が高い．今回扱ったエンティティ
は，都市名・駅名が多い．このため，知識ベース上のトリプルはある程度の数があるものの，概要文書は貧弱である場合が少な
くない．例えば，GraphVoteLD でリンキングに成功した例の一つでは，つくばみらい市 (dbr:Tsukubamirai,_Ibaraki) を主語とするトリプルは 236 個存在する．しかし，知識ベース中The percentage of the population aged over 65 was 26.3%.
The total area of the city is 79.16 square kilometres (30.56
sq mi).

7 ま と めRDF 形式の知識ベースは，静的に意味的情報を保持しており，SPARQL で問合せできる．一方，非知識ベースの外部情報源は，問合せとその返り値に独自の形式を持つことが多い．
このため本研究では，知識ベースと非知識ベース外部情報源の統合利用アーキテクチャを提案した．このアーキテクチャは，

SPARQL における Magic Properties を利用し，外部情報源にアクセスする関数を呼び出すことで，外部情報源の情報を取り入れ，エンティティ間の関係を拡張可能である．また，外部情報源から取得したオブジェクトと知識ベース上のエンティティの対応を求めることが容易でないという問題に対して，エンティ
ティリンキングを自動的に行う機能を提供する．また，提案
アーキテクチャのプロトタイプを実装し，実際に拡張 SPARQL
問合せを実行することで，アーキテクチャの有効性を確認した．
また複数のエンティティリンキングを実行し，エンティティリ
ンキングの必要性と性質の違いを明らかにした．一方，外部情報源が返した値の大部分が最終的な問合せ結果に適合しない場
合は，性能が下がるという問題を発見した．
今後の課題は，より多様な外部情報源と ESP を用いた検証，
より高度なエンティティリンキング方式の設計，ユーザ定義のエンティティリンキング方式の組み込み等である．また，知識ベースに存在しないエンティティを取り込む知識グラフの拡張も重要な課題である．

謝辞

本研究の一部は，JSPS 科研費 (JP19H04114, JP22K19802,

JP22H03694),

JST CREST (JP-MJCR22M2),NEDO(JPNP20006), AMED (JP21zf0127005) による.
文

献[1] 3.3 Magic Properties, SPIN - Modeling Vocabulary, W3C
Member Submission 22 February 2011.
https://www.w3.org/Submission/spin-modeling/spin-magic.
[2] Feature:JavaScriptFunctions. W3C.
https://www.w3.org/2009/sparql/wiki

June 2007. Association for Computational Linguistics.
/Feature:JavaScriptFunctions.
[26] Razvan Bunescu and Marius Paşca. Using encyclopedic[3] Carlos Buil-Aranda et al. Semantics and Optimization ofknowledge for named entity disambiguation. In 11th Conthe SPARQL 1.1 Federation Extension. In The Semanic
ference of the European Chapter of the Association for
Web: Research and Applications, 2011.
Computational Linguistics, pp. 9–16, Trento, Italy, April[4] Muhammad Saleem et al. A ﬁne-grained evaluation of
2006. Association for Computational Linguistics.
SPARQL endpoint federation systems. Semantic Web,[27] Jens Lehmann et al. DBpedia - A large-scale, multilingual
2016.
knowledge base extracted from Wikipedia. Semantic Web,[5] Bastian Quilitz and Ulf Leser. Querying Distributed RDF
2015.
Data Sources with SPARQL. In The Semantic Web: Research and Applications, 2008.
[6] Steven Lynden et al. ADERIS: An Adaptive Query Processor for Joining Federated SPARQL Endpoints. In On theMove to Meaningful Internet Systems: OTM 2011, 2011.
[7] Muhammad Saleem et al. CostFed: Cost-Based Query Optimization for SPARQL Endpoint Federation. Procedia Computer Science, 2018.
[8] Describing linked datasets with the void vocabulary, w3cinterest group note 03 march 2011.
https://www.w3.org/tr/2011/note-void-20110303/.
[9] Olaf Görlitz and Steﬀen Staab. SPLENDID: SPARQL
Endpoint Federation Exploiting VOID Descriptions. In
COLD’11, 2011.
[10] Andreas Schwarte et al. FedX: Optimization Techniques
for Federated Query Processing on Linked Data. In The
Semantic Web – ISWC 2011, 2011.
[11] Muhammad Saleem et al. HiBISCuS: Hypergraph-Based
Source Selection for SPARQL Endpoint Federation. In The
Semantic Web: Trends and Challenges, 2014.
[12] Fajar Ekaputra et al. Ontology-based data integrationin multi-disciplinary engineering environments: A review.
Open Journal of Information Systems, 2017.
[13] Wei Shen et al. Entity Linking with a Knowledge Base:
Issues, Techniques, and Solutions. IEEE TKDE, 2015.
[14] Özge Sevgili et al. Neural entity linking: A survey of models
based on deep learning. Semantic Web, No. Preprint, 2022.
[15] Paolo Ferragina and Ugo Scaiella. TAGME: On-the-Fly Annotation of Short Text Fragments (by Wikipedia Entities).
In CIKM ’10, CIKM ’10, 2010.
[16] Stefan Zwicklbauer et al. DoSeR - A Knowledge-BaseAgnostic Framework for Entity Disambiguation Using Semantic Embeddings. In The Semantic Web. Latest Advances and New Domains, 2016.
[17] Ledell Wu et al. Scalable Zero-shot Entity Linking withDense Entity Retrieval. In EMNLP 2020, November 2020.
[18] Lajanugen Logeswaran et al. Zero-Shot Entity Linking by
Reading Entity Descriptions. In ACL 2019, July 2019.
[19] Ikuya Yamada et al. Joint Learning of the Embedding ofWords and Entities for Named Entity Disambiguation. In
Proceedings of the 20th SIGNLL Conference on Computational Natural Language Learning, August 2016.
[20] Ikuya Yamada et al. Global Entity Disambiguation with
BERT. In NAACL 2022, July 2022.
[21] RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014.
https://www.w3.org/TR/rdf11-concepts/.
[22] Farzaneh Mahdisoltani et al. YAGO3: A Knowledge Basefrom Multilingual Wikipedias. In Conference on Innovative
Data Systems Research, 2015.
[23] SPARQL 1.1 Query Language, W3C Recommendation 21
March 2013.
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/.
[24] Apache Jena - ARQ - Writing Property Functions.
https://jena.apache.org/documentation/query/writing propfuncs.html.
[25] Silviu Cucerzan. Large-scale named entity disambiguation
based on Wikipedia data. In Proceedings of the 2007 Joint
Conference on Empirical Methods in Natural Language
Processing and Computational Natural Language Learning(EMNLP-CoNLL), pp. 708–716, Prague, Czech Republic,