ウェブサイトやSNS等に存在する大規模自然言語テキストから、「どこ」を表す地名情報を取り出し、地名ごとの情報に統合・再編成して示すことは、実世界をセンシングするための基本的な処理である。また、Linked Open Data (LOD)等のグローバルな情報空間の発達に伴い、自然言語テキストのような非構造化データをLinked Open Dataのような構造化データに接続する方法に関する研究も盛んになりつつある。しかし、地名を軸として非構造化データを構造化データに接続するには、研究領域を越えた問題解決が求められる。例えば、空間情報として地名を扱うには地理情報処理（geographic information processing / Geo)、テキスト中に出現する地名を認識するには自然言語処理(natural language processing / NLP)、そして地名を意味的に接続するにはリンクト・オープン・データ（Linked Open Data / LOD)の知見が必要である。そこで本研究は、これら3つの領域の知見を統合することで、以下の機能を実現する。
このような機能を実現するため、本研究では、1) 地名の共有を担うGeoNLPデータ、2) 地名の解析を担うGeoNLPソフトウェア、3) 地名の流通を担うGeoNLPサービス、という3つのコンポーネントを研究する。そして、コンポーネントの組み合わせに基づく地名情報処理基盤として、GeoとNLPを統合したGeoNLP、そしてGeoとLODを統合したGeoLODなどを構築する。
地名とは、位置に関する属性を伴う固有表現である。この定義の中で、位置に注目するなら、これは地理情報処理の問題である。代表点の緯度経度の管理だけではなく、地理的広がりや地図へのマッピングなどを扱う必要がある。次に表現に注目するなら、これは自然言語処理の問題である。自然言語テキストから地名に相当する部分を切り出し、その指示対象（実世界の対応物）を確定するといった、固有表現認識の問題を扱う必要がある。最後に固有性に注目するなら、これはセマンティックウェブの問題である。地名語の固有IDを基にLinked Dataというグローバルな情報空間と接続し、異種の情報を統合する技術が必要である。GeoNLPの目的は、これら複数の領域にまたがる問題を一体的に扱える実用的な地名情報処理(Toponym Information Processing / TPM)の基盤を構築することにある。上記の3つの領域に合わせて、地理情報処理を扱うGeoNLPデータ、自然言語処理を扱うGeoNLPソフトウェア、セマンティックウェブを扱うGeoNLPサービスという3つのコンポーネントを構築する。
Wikipedia等のウェブサイトから巨大な固有表現リソースが獲得可能となるにつれ、これを活用して自然言語テキストのような非構造化データをLinked Dataのような構造化データに接続する方法に対する関心が高まっている。中でも代表的なのは、DBpediaを用いた固有表現認識ソフトウェアDBpedia Spotlightに関する研究である。Wikipediaという世界規模の多言語リソースを活用することで、固有表現の辞書をユーザ参加型で自然に拡張できる仕組みを実現し、ベクトル空間モデルを用いて周囲の文脈を評価するという方法で同綴語の曖昧性を解消する。
しかし地名情報基盤として見た場合、この仕組みには特筆性(Notability)の問題がある。すなわち、Wikipediaの編集方針により、記事の見出し語に使える言葉が、「百科事典の記事として言及するにふさわしい価値」のある概念に限定されるという問題である。例えば、災害時における実世界センシングへの利用を考えた場合、この方針には問題がある。なぜなら、地名語の特筆性が短期間に大きく変化したり、詳細レベルの地名語の特筆性が人や状況によって異なったりするからである。そこでGeoNLPでは、特筆すべき記事を列挙する百科事典型ではなく、事実をフラットに列挙するデータベース型のアプローチに沿って、地名語辞書を整備することとする。この場合、特筆性に関する判断は、辞書側ではなくアプリケーション側で行うことになる。
自然言語処理の分野でも、自然言語テキストから地名を抽出する研究は多い。地名の曖昧性解消の方法としては、距離と有名度を用いる方法や、直前に出現した曖昧性の解消された地名語を用いる方法などが提案されており、これらの基準を数個のヒューリスティクスに分類・整理することもできる。LocoStickerはテキストの主題となる地名を抽出する機能を有するが、テキスト中に出現するすべての地名をタグ付け（ジオタギング）する機能は有しない。Yahoo!のBOSS Geoサービスは、住所のジオコーディング(PlaceFinder)と地名の抽出(PlaceSpotter)機能を提供し、地名にWOEIDというユニークIDを付与する点でGeoNLPと類似するが、クローズドなシステムであるため利用者が改善を加える余地がないという問題がある。
以上、自然言語テキストから地名を抽出するという問題に関する研究は多いものの、日本語テキストにジオタギングできる実用的なオープンシステムは見当たらない。これを実現するためのプラットフォームを構築することが、GeoNLPの研究を進める主要な動機である。
データからソフトウェアまでを含む多数のコンポーネントを接続するプラットフォームを構築するという意味では、GeoNLPの関連研究として、自然言語処理の分野におけるGATE (General Architecture for Text Engineering)やUIMA (Unstructured Information Management Architecture)なども挙げておきたい。例えばGATEでは、多数のコンポーネントをLanguage Resource (LR)、Processing Resource (PR)、Visualization Resource (VR)の3種に分けており、LRはGeoNLPデータに、PRはGeoNLPソフトウェアに、VRはGeoNLPサービスにおおむね対応すると言える。またUIMAでは、コンポーネントの接続を自動化するKachakoなどの研究も進んでおり、自然言語処理を部品としたアプリケーションの構築を容易にしたいという点ではGeoNLPと共通する方向性がある。しかし、地名情報処理に特化している点、LODへの接続などの自然言語処理の枠外となる研究テーマも扱う点に、GeoNLPの大きな特徴がある。
GeoNLPデータは、地名語の共有を担うコンポーネントである。まず地名語辞書のスキーマについて紹介した後、地名語辞書を共有するためのポータルの設計を述べる。
地名語辞書は地名語のエントリの集合であり、地名語辞書ごとにメタデータ項目のリストをスキーマとして定義する。メタデータは2つの観点から整理する。まず情報の種類の観点から、識別子、表記情報、関係情報、属性情報、連結情報の5種類に分類する。
通常の地名語辞書と比べると、LODに有用な複数の識別子と固有表現認識に有用な関係情報を含む点が特徴である。
次に情報の必須度の観点から、サーバ生成、必須、推奨、拡張の4種類に分類する。
地名語辞書エントリのスキーマを表1に示す。地名語の入力に必要な負担を最小とするため、識別子以外の必須項目は原型と固有名クラスに限定した。また代表点緯度と代表点経度は原則として入力するが、不明な場合は空欄も可とした。スキーマで定義した項目名は予約語として扱うが、予約語と重複しない項目名は任意に追加できる。追加した項目は原則として拡張項目となり、GeoNLPが実装で利用しない場合は透過的に扱う。
なお地名語辞書のフォーマットはCSV(Comma-Separated Values)形式とし、項目名はCSVファイルの先頭行（ヘッダ行）から判断することで、項目の並び順を自由に設定できるようにする。
| 項目名 | 日本語名 | 情報の種類 | 必須種別 | 型、値の範囲 | 注 |
|---|---|---|---|---|---|
| geolod_id | GeoLOD ID | 識別子 | ServerGenerated | 6文字以上の文字列 | |
| entry_id | エントリID | 識別子 | Required | 1文字以上の文字列 | |
| body | 原型 | 表記情報 | Required | 1〜255文字の文字列 | |
| prefix | 接頭辞 | 関係情報 | Recommended | 0〜255文字の文字列 | 複数可 |
| suffix | 接尾辞 | 関係情報 | Recommended | 0〜255文字の文字列 | 複数可 |
| body_kana | 読み | 表記情報 | Recommended | 0〜255文字の文字列 | |
| prefix_kana | 接頭辞読み | 表記情報 | Optional | 0〜255文字の文字列 | 複数可 |
| suffix_kana | 接尾辞読み | 表記情報 | Optional | 0〜255文字の文字列 | 複数可 |
| ne_class | 固有名クラス | 関係情報 | Required | GeoNLP階層を参照 | 不明な場合は’Place’ |
| hypernym | 上位語 | 関係情報 | Recommended | 0〜255文字の文字列 | 複数可 |
| latitude | 代表点緯度 | 属性情報 | Recommended | 数値または空 | 原則として入力 |
| longitude | 代表点経度 | 属性情報 | Recommended | 数値または空 | 原則として入力 |
| description | 説明 | 属性情報 | Optional | 文字列 | |
| variant | 異表記 | 属性情報 | Optional | 文字列 | |
| source | 出典 | 属性情報 | Optional | 文字列 | URL可 |
| valid_from | 有効期間（開始） | 属性情報 | Optional | 日付文字列または空 | |
| valid_to | 有効期間（終了） | 属性情報 | Optional | 日付文字列または空 | |
| preferred_id | 優先ID | 連結情報 | Optional | 優先すべきGeoLOD ID | 複数可 |
| inverse_preferred_id | 優先参照ID | 連結情報 | Optional | 優先として参照されているGeoLOD ID | 複数可 |
| variant_id | 異表記ID | 連結情報 | Optional | 異表記のGeoLOD ID | 複数可 |
| inverse_variant_id | 異表記参照ID | 連結情報 | Optional | 異表記として参照されているGeoLOD ID | 複数可 |
| before_id | 前ID | 連結情報 | Optional | 同じ場所だが時間的に前のGeoLOD ID | 複数可 |
| inverse_before_id | 前参照ID | 連結情報 | Optional | 同じ場所だが時間的に前として参照されているGeoLOD ID | 複数可 |
| after_id | 後ID | 連結情報 | Optional | 同じ場所だが時間的に後のGeoLOD ID | 複数可 |
| inverse_after_id | 後参照ID | 連結情報 | Optional | 同じ場所だが時間的に後として参照されているGeoLOD ID | 複数可 |
地名語辞書に登録した地名語をLODに接続するためには、地名語に対してGeoLODシステム内でユニークなIDを付与しなければならない。GeoNLPの基本方針は、辞書制作者が独自に制作した複数の地名語辞書を組み合わせて利用する、というものである。しかし、この方針を前提とすると、地名語辞書内でユニークなIDを与えても、システム全体でユニークなIDとなる保証はないという問題が生じる。
この問題の解決策としてよく用いられる方法は、項目内の文字列を連結した文字列をキーとし、それをハッシュ関数に与えて固定長のIDを生成するなど、項目内容を変換することでIDを生成する方法である。もし項目内の文字列にユニーク性があれば、この方法でもIDを生成できる。しかし、この方法は項目内容の修正に弱く、内容の微修正を越えて永続性のあるIDを生成する目的には適していない。
そこで2段階のID生成法を用いる。まず辞書制作者は、地名語辞書内でユニークなIDとしてentry_idを地名語に付与する。このIDは永続性のある任意の文字列でよい。次に、地名語辞書のIDとして辞書ごとにdictionary_idを付与する。GeoNLPではGeoLODを地名語辞書リポジトリとして利用するため、GeoLODが地名語辞書に対してユニークなIDを付与する。こうすることで、dictionary_idとentry_idの組はGeoLOD内でユニークなキーとなるため、これを固定長のIDに変換するとGeoLOD内でユニークなIDであるGeoLOD IDを生成できる。そこでGeoNLPでは、これを地名語のIDとしてシステム内で利用するとともに、LODとして公開する際にはこのIDから地名語URI (Uniform Resource Identifier)を生成する。
関係情報はGeoNLPソフトウェアにおける固有表現認識に活用する。GeoNLPでは固有表現認識を固有表現抽出と固有表現解決（曖昧性解消）の2段階に分けており、各段階で地名語辞書の関係情報を活用する。
まず固有表現抽出では、関係情報の中で「接頭辞」や「接尾辞」の項目を活用する。接頭辞や接尾辞を原型と分離して登録することで、省略などの表記揺れにも対応可能となる。例えば「東京都」という地名語を、原型の「東京」と接尾辞の「都」に分離して登録することで、「都」が省略された「東京」として出現した場合にも対応できる。
次に固有表現解決では、関係情報の中で「上位語」と「地名クラス」の項目を活用する。上位語は、地名語を包含する固有名を指定する項目であり、市区町村名を包含する都道府県名を記述する例などが典型的である。地名クラスは、地名語がインスタンスとなるクラスを指定する項目であり、「鉄道駅」クラスに対する「東京駅」などが相当する。
これらの関係情報は、複数の地名語の共起を評価する処理で利用する。例えば、テキスト中に「港区」と「中央区」が共起すれば、それらは「東京都」という共通の上位語をもつ東京都の地名である可能性が高いが、「港区」と「福島区」が共起すれば、それらは大阪市の地名である可能性が高い。また、「東京」と「大阪」の場合、両方とも都道府県の地名か、両方とも鉄道駅かなど、地名クラスを共有する地名語の組み合わせの評価を高くする。もちろん、接頭辞や接尾辞によって手がかりが得られれば、これらの共起の評価基準も変化する。例えば「東京都から大阪へ」というテキストでは両方を都道府県とし、「東京駅から大阪へ」というテキストでは両方を鉄道駅とする。
上位語と地名クラスの違いは、part-of階層とis-a階層の違いである。前者はpart-of関係における固有名と固有名の関係を指定する一方、後者はis-a関係におけるクラスとインスタンスの関係を指定する。
こうした階層をどう構築するかは大きな問題である。地名語にも適用できる階層としては、情報検索の研究から生まれた固有表現階層や、ウェブページへのアノテーションから生まれたschema.orgなどがある。本研究でも当初は既存の階層の採用を検討していたが、実際に地名語辞書の制作に利用してみると、自然地名などの大きな概念が抜け落ちている、概念として粒度が揃っていない、などの問題が明らかとなった。さらに、schema.org（英語）のように言語が異なる階層では、日本語概念のマッピング先の決定が実用的に困難な場合があった。
そこで、互換性よりも利便性を重視した独自の地名階層を構築することとした。参考にした体系は、国土地理院「数値地図25000（地名・公共施設）」の注記テーブル・分類コード、および総務省統計局「平成18年事業所・企業統計調査」の「産業分類一覧」などである。一般の辞書制作者が使いこなせない複雑な階層は避けるべきという観点から、階層で利用する概念は日本語に限定し、地名語として幅広い範囲をあらかじめ網羅した。また、あくまで地名分類ではなく固有表現認識の支援を目的とし、実用に必要な最低限の詳細度に抑えた階層とした。
ただし現段階では、地名語辞書に指定した上位語や地名クラスはリテラルとして扱い、文字列比較（完全一致、部分一致、あるいは文字列間距離）を利用して関連性を評価している。言い替えれば、上位語や地名クラスの階層上での概念間距離を活用した処理は実現していない。その理由は2つある。第一に、階層中の概念をURIなどで特定して地名語辞書に指定する方法は、一般の辞書制作者にとってハードルが高いこと、第二に、辞書制作者が上位語や地名クラスを任意に拡張した場合、それらを階層に取り込むことが困難であること、である。これらの問題については、将来的に地名語辞書作成支援エディタなどを開発する中で同時に解決することを考えている。
GeoLOD地名管理システムは、地名語辞書のアップロードとダウンロードを基本機能とするウェブサイトである。
アップロードでは、アカウント登録した辞書制作者が、地名語辞書のCSVファイルをアップロードするか、CSVファイルのアクセス可能URLを指定する。アップロード中には、項目に対する簡単な検証（緯度経度の不正な値など）を行い、エラーがあればその地名語は無効とする。アップロードが完了すると、地名語辞書のメタデータをウェブインタフェースから入力する。これらの作業を終えると、地名語辞書はサイト管理者による承認プロセスに入り、管理者が承認すれば公開、管理者が差し戻すと再度のアップロードが必要になる。管理者が承認後、辞書は誰でもダウンロード可能な形でポータルに公開する。
ダウンロードでは、地名語辞書の本体であるCSVファイルと地名語辞書のメタデータであるJSONファイルをZIP形式でアーカイブしたファイルがダウンロードできる。メタデータのスキーマにはDublin Core Metadata Element SetやDCMI Metadata Termsの語彙を参照した。
ここで辞書のライセンスについては、辞書制作者がアップロード時に設定する必要がある。GeoNLPでは一般的なオープンデータライセンス、具体的には、Creative Commons (creativecommons.org)のCC0、CC-BY、CC-BY-SAおよびOpen Data Commons (opendatacommons.org)のPDDL、ODC-BY、ODbLの計6個を標準ライセンスとして用意した。これ以外に独自ライセンスを設定する必要があれば定義も可能な仕組みではあるが、制限が少ないオープンデータのライセンスを付与することを推奨している。
またGeoNLPでは、アップロードした辞書の編集・削除は、編集者による上書きアップロードのみを許可している。例えばWiki形式のように誰でも編集可能な設計としなかったのは、論争を呼ぶような地名に対しても責任者を明確にするためであるが、これにより辞書制作者が対応しない限り誤りを修正できないという副作用も生じてしまう。そこで、地名に関するコメントをポータルから辞書制作者に送付する機能を提供し、辞書制作者の修正と再アップロードを促すこととする。
なお、このようなデータ共有ポータルはオープンデータの推進に不可欠の情報基盤と認識されており、中でもOpen Knowledge Foundationが開発するCKANは、複数の政府サイトに採用されるなど普及が進んでいる。本研究でも当初はCKANバージョン1の採用を検討していたが、アップロードされたデータの承認プロセスに関するワークフロー処理、地名語ごとのID付与処理に関する大幅な改修が必要であり、改修を加えると本体の更新に追従することが困難との問題が明らかとなった。そこで、独自のポータルサイトを構築することとした。
GeoNLPソフトウェアは、地名語の解析を担うコンポーネントである。まずアルゴリズムの概要を示した後、オープンソース化について議論する。
GeoNLPソフトウェアは、自然言語テキストから「どこ」「いつ」「だれ」といった基本的な情報を抽出して特定する固有表現認識の問題の中で、特に地名を対象とする問題を解くためのものである。そのアルゴリズムは、概念的には抽出段階と解決（曖昧性解消）段階の2段階に分けて考えることができる。
GeoNLPは辞書ベースの固有表現認識器である。前段の固有表現抽出では、形態素解析を用いてテキストを形態素に分割し、形態素ごとに地名語辞書を検索して該当する地名語リストを出力する。ここで形態素解析ソフトウェアとしては、性能の高さと動作実績の豊富さを考慮してMeCabを選択した。また、地名語を含むユーザー辞書とMeCabの標準辞書とを併合した解析を実現するため、地名語ごとの適切なコストを自動調整する仕組みを考案した。そして、形態素への分割後に接頭辞や接尾辞、その他の典型的な修飾語との連続性を検査し、地名語の可能性がある形態素列の中で最長のものを地名語の候補リストとして出力する。出力形式は形態素解析の標準的な出力形式を踏襲するが、地名語だけは「地名語」品詞として出力し、そこに地名語の候補となるGeoNLP IDのリストを並べる。これを「拡張形態素解析」と呼ぶ。
地名語候補が複数ある場合は、固有表現解決（曖昧性解消）によって最適な候補を選ぶ必要がある。ここで技術的に解決すべき問題は以下の2点である。
第一に、地名と非地名との曖昧性解消(Geo/Non-Geo Disambiguation)の問題である。これは、「川崎と横浜」というテキストに対して、川崎市と横浜市の話なのか、川崎さんと横浜さんの話なのかなどを推定する問題である。地名の中には、地形や用途に関する一般名詞が固有性を帯びて地名に変化したもの、住民の名前など人名の固有名が地名化したもの（またはその逆）などがあるため、地名と非地名の重なりは大きい。現状では、一般名詞については除去することが難しいが、人名に対しては固有の接尾辞や姓名の連続といったヒューリスティクスを手掛かりに、ある程度は除去することも可能である。
第二に、地名の指示対象の曖昧性解消（Geo/Geo Disambiguation)である。これは、「第一小学校」という地名語に相当する場所が日本全国に200か所以上存在するなど、同綴地名語が多数存在する場合に指示対象を一意に特定する問題である。現状では関係情報を活用し、地名クラスが同一かどうか、上位語が同一かどうかを評価すると同時に、地名語の曖昧性解消でよく知られたヒューリスティクスとして地名語の代表点間の最短距離が小さい組み合わせを高く評価する評価関数なども取り入れ、これらの評価関数の加重和を総合的な評価関数として最適な候補を選ぶ。
大規模自然言語テキストの処理では精度と速度のバランスが重要であり、精度に優れても実行コストが高いアルゴリズムでは、データを処理しきれない状況が発生する。GeoNLPでは災害時の準リアルタイム処理での利用を念頭に置き、速度に重きを置いてアルゴリズムを選択する。例えばGeoNLPの以前のバージョンを東日本大震災発生後1週間の全ツイート約1億8000万件を対象に適用した実験では、112コア×40時間で全件処理が可能なことを示した。つまり1週間分のツイートを1週間よりも短い時間で処理できたことになり、これは準リアルタイム処理の可能性を示す結果である。なお、現在のバージョンは2012年11月当時のバージョンよりは3倍程度高速化していると考えられるが、数値的な検証はできていない。
またGeoNLPに独自の機能として、アドレスジオコーダーとの連携による住所固有表現の認識がある。具体的には、住所の可能性がある文字列をアドレスジオコーダーに問い合わせ、住所と判定された場合はその文字列を住所と判定し、そうでない場合は地名語としての処理を進める。またテキスト中に出現する地名語と組み合わせた住所の曖昧性解消は、アドレスジオコーダー単体では実現できなかったGeoNLPに特有の機能である。
最後に、GeoNLPソフトウェアの特徴として、オープンソースライセンスの採用による以下の利点を挙げておきたい。第一に、 利用者はソフトウェアをダウンロードして自前のサーバ（あるいは端末）で実行できるため、解析テキストを外部に流出させずに解析できる。第二に、 外部には公開できないクローズドな地名語辞書をオープンな地名語辞書と併合し、自分専用の形態素解析用ユーザ辞書を構築すれば、両者を組み合わせて解析できる。ただし、地名語辞書共有ポータルにアップロードしないと地名語にGeoNLP IDを付与できないため、クローズドな辞書に含まれる地名語をLODの世界に接続することはできない。第三に、多人数の知恵を集約した、コミュニティベースのソフトウェア開発への可能性が開かれている。
GeoNLPサービスは地名語の統合を担うコンポーネントである。まずウェブサービスの概要を説明し、次にLODへの展開についてまとめる。
GeoLODでは、地名語の統合を促進するための機能として、地名検索機能を一般利用者向けに提供すると同時に、テキストジオタギング（GeoNLP）デモではGeoNLP地名解析機能をを提供する。
地名検索は、地名語辞書共有ポータルで共有されるすべての地名語を対象として、検索キーと部分一致する地名語をGoogle Maps地図上に表示する可視化サービスである。これにより、自分が必要とする地名語がすでにポータルに登録済みかを確認できる。
地名解析は、任意の自然言語テキストを入力すると、GeoNLPソフトウェアが認識した地名語をGoogle Maps地図上に表示する可視化サービスである。さらに、地名解析と同等の機能は機械アクセス用のAPIとして提供しており、利用者は登録を行ってAPIキーを取得することにより、自前サーバへのインストールなしにGeoNLPを体験できる。ただし、APIには辞書の選択や利用回数などに制限があるため、本格的な利用が必要な場合は自前サーバへのインストールによるローカル環境での実行を推奨している。
APIではJSON-RPC形式でリクエストとレスポンスを記述し、地名語に関する部分についてはGeoJSON形式を採用した。GeoJSON形式の利点は、この形式に対応するソフトウェアを用いれば地理的な可視化が容易であり、地名語をポリゴン等の幾何図形で代表させるように拡張できるという点にある。GeoJSON形式のレスポンスには地名語のGeoNLP IDを付与しており、GeoLODにこのIDを付与することで、地名語の属性情報などが取得可能となっている。また住所の場合は、住所を構成要素に分解して各要素にGeoNLP IDを付与するため、住所の各要素に対してもGeoLODを経由して地名語に関する情報を取得できる。
GeoNLPでは地名語間のリンクとして、サイト内リンク(intralinking)とサイト間リンク(interlinking)の両者を扱う必要がある。まずサイト内リンクとは、GeoNLPにアップロードされた複数の地名語辞書を越えて、地名語間の関係を表すためのリンクである。GeoNLPでは辞書制作者が独自に地名語辞書を制作するため、地名語辞書を越えた関連性を辞書制作者自身が管理することは困難である。ゆえに、GeoNLPがシステム内の地名語間の関係を自動的に管理するメカニズムが、将来的には必要になると考えている。一方、サイト間リンク（インターリンキング）はGeoNLPの地名語を外部の情報空間に接続し、地名語に関する情報を外部から取得可能とすることが目的である。
インターリンキングの構築については、サイトの選定およびリンク先の決定の2つの問題がある。第一に、サイトの選定については、LODのハブとなっているサイトを選定することが望ましい。地名に関してはGeoNamesが著名であるが、海外地名が中心で日本語表記の日本地名は充実度が低いという問題がある。またLinkedGeoDataも一つの候補であるが、データ元となるOpenStreetMapは地名データよりも道路データの収集に力を入れている。そこでリンク先のサイトとして、地名も含めてLOD全体のハブとなっているDBpedia、特に地名語辞書が日本語であることからDBpedia日本語版を選定することとした。
第二に、リンク先の決定については、リンク作業を自動化するツールSilkなど、多くの先行研究がある。この部分の処理は、固有表現認識と同様、概念的にはリンク先候補の生成と曖昧性解消という2段階の処理を考えることができる。例えば、都道府県のように曖昧性が存在しない場合、リンク先候補の生成と曖昧性解消は自明の処理となり、地名語辞書の表記とDBPedia日本語版の表記の間の変換規則さえ既知であれば直接的にリンク先を決定できる。しかし一般の地名語では上記の2段階の処理が必要となるため、本研究では地名語の属性情報などを用いた簡単なアルゴリズムを考案した。
GeoNLPの地名語辞書はCSVファイルで管理するため、地名語辞書ストアとしては関係データベースシステムを用いるのが自然な選択である。そこで、これをLODとして公開するためのツールとして、関係データベースを仮想的なRDFグラフとみなして扱えるツールD2RQを利用した。D2RQマッピング言語を用いて、地名語エントリを管理するテーブルと地名語インターリンクを管理するテーブルをJOINし、主語と目的語の間に適切な述語を付与した。この結果はGeoLODとして公開している。
ここで問題となるのが、インターリンキングに用いる述語の選択である。GeoLODでは、頻繁に用いられるowl:sameAsではなく、rdfs:seeAlsoを用いることとした。その理由は、owl:sameAsで結ばれる概念はすべて同一概念となるため、類似だが同一ではない概念が誤って連結される危険性が高い点にある。Ordnance Surveyは、綴りが同じでも役割が違う地名がowl:sameAsで結ばれると誤った関係が推論される危険があることを論じ、owl:sameAsの代わりにrdfs:seeAlsoの利用を提案している。そこでGeoLODでも、自動的なインターリンキングにおけるowl:sameAsの安易な利用を避け、rdfs:seeAlsoを利用することとした。将来的にはSKOSや、owl:sameAsの代替案を検討するSimilarity Ontologyなどの利用も検討したいと考えている。
地名に関する実践的な情報基盤の基本部分として、地名情報処理基盤GeoNLPの構築と、テキストという非構造化データから地名語を抽出してLODに接続するためのプロセスについて述べた。これをより実用的なプラットフォームに成長させる際の問題点は、以下の2点である。
第一に、GeoNLPソフトウェアの高精度化、特に曖昧性解消の改善である。現在は地名語の共起のみを扱っているが、DBpedia Spotlightが用いているようにベクトル空間モデルあるいは他のモデルによって、地名語以外との共起も考慮することは一つの解決策である。また地名語と非地名語の分類についても、機械学習などを用いて精度を改善する方向性が考えられ、これらが技術的には最も挑戦的な問題である。
第二に、GeoNLPを取り巻くエコシステムの形成である。地名語辞書の構築にはコストがかかり、十分なインセンティブがなければリソースは充実しない。GeoNLPでは地名語辞書の増強が解析精度の向上につながるという好循環を支えに全体を発展させていく構想を持っているが、オープンガバメントの文脈ではデータの提供が社会の役に立つことを示すというのも、好循環を支える一つの鍵となるだろう。我々はもともと大規模災害データへの適用に関心を持っているが、GeoNLPを社会実装が可能なレベルまでどう成長させていくかは、社会的に挑戦的な課題である。
GeoNLPプロジェクトの詳細についてはGeoNLPニュースもご覧下さい。
本プロジェクトは以下の支援を受けています。
また過去には以下の支援を受けました。
Copyright 2011-2024, 北本 朝展, National Institute of Informatics.