本記事は生成AIと共同で執筆しています。記事中の固有名詞・数値・技術仕様は公開情報をもとに可能な範囲で照合していますが、誤りが含まれる可能性があります。正確な情報は末尾の一次情報をご確認ください。本記事はデータ形式・アーキテクチャの技術的な側面に主眼を置いています。

デジタルヒューマニティーズの代表的な大型プロジェクトを紹介するシリーズの4本目（最終回）です。関連記事：Venice Time Machine / Sailing Letters / Stanford ORBIS

まず「ガゼッティア」とは何か

Gazetteer（ガゼッティア） は、日本語でいう「地名辞典」「地名索引」です。地名を引くと、その場所の座標・別名・場所の種別（都市・港・州など）が分かる、いわば場所の索引データベースです。

World Historical Gazetteer（WHG） は、これを「世界史のスケールで、かつ時間情報を含めて」構築し、さらに世界中の歴史データセットを地名を介して連携させる基盤にしようとするプロジェクトです。米国ピッツバーグ大学の世界史センター（World History Center）が運営し、歴史家ルース・モスターン（Ruth Mostern）がプロジェクトを率いています。2017年に全米人文科学基金（NEH）の助成を得て開発が始まり、V1（2017〜）、V2（2021〜）を経て、現在は Version 3（2024年〜） が稼働しています。

本記事では、WHG が解こうとしている技術的な課題と、その中核にあるデータ形式を中心に見ていきます。

解こうとしている技術課題：地名の名寄せ

WHG が取り組むのは、突き詰めると「地名の名寄せ（reconciliation）」という技術課題です。

地名は時代とともに変わります。たとえば 江戸 → 東京（1868年）、コンスタンティノープル → イスタンブル（公式改称1930年）、シャム → タイ（1939年）、セイロン → スリランカ（1972年）。人間なら同一の場所と分かりますが、コンピュータは別々の文字列としか認識しません。

さらに、世界中の研究者が作る歴史データベースは、同じ場所を Edo / 江戸 / Yedo のようにバラバラの名前・IDで記録しています。これでは複数のデータベースを結合して分析できません。

WHG はこの問題を、「それぞれのデータの地名を、共通の典拠と結びつける」ことで解決します。

仕組み：共通典拠への名寄せ

利用者が自分のデータセットの地名を WHG にアップロードすると、WHG はそれを既存の地名典拠と照合（reconcile）します。照合先の中心が、世界的に使われる2つの典拠です。

  • Wikidata（構造化された知識ベース）
  • GeoNames（地名データベース）

WHG の Version 3 では、この照合用インデックスが GeoNames 約1,000万件＋Wikidata 約360万件＝計約1,360万件規模で構築されています。名寄せが成立すると、

  • その地名の別名（東京 / Edo / Yedo …）が自動でひもづく
  • 緯度・経度などの座標が補完される
  • 同じ場所を参照する他のデータセットと接続される

こうして、これまで孤立していた歴史データベースが、共通の「場所」を介して相互につながるようになります。WHG は 2024年のVersion 3時点で70以上の公開データセット／コレクションを連結しており、その数は増え続けています。

中核技術：Linked Places Format（LPF）

WHG が技術コミュニティで重要視される最大の理由が、Linked Places Format（LPF） というデータ形式を主導して策定したことです。

地図データの世界では GeoJSON という標準形式が広く使われています。しかし GeoJSON は「点の座標」を記述するのは得意でも、「いつの時代の場所か」という時間情報を扱うのが苦手でした。

LPF は、この弱点を補うために設計されました。技術的には、

  • 正しい GeoJSON であると同時に、GeoJSON-T（GeoJSON に時間属性を加える拡張仕様）の実装である
  • 「この地名は何年から何年まで使われた」「この場所はこの期間どの領域に属した」といった時間つきの地理情報を表現できる
  • 別名（toponyms）、典拠への外部リンク（Wikidata/GeoNames等のID）、場所種別なども構造化して持てる

さらに、表形式で簡単に地名レコードを作れる簡易版 LP-TSV（Linked Places Delimited） も用意されています。複雑な JSON を書かなくても、表計算ソフト感覚で地名データを用意してアップロードできる、という実務的な配慮です。

「みんなが同じ形式でデータを作れば、データ同士が自動でつながる」——この標準化こそが、WHG の本質的な貢献です。

アーキテクチャ

WHG のバックエンドは、次の構成で実装されています。

  • PostgreSQL（リレーショナルデータベース）：地名レコードの正規の格納先
  • Elasticsearch（検索エンジン）：高速な地名検索・名寄せのためのインデックス
  • Django（Python製Webフレームワーク）：上記2つを束ね、アップロード・照合・公開のワークフローを管理

「正規データはRDB、検索はElasticsearchのインデックス」という、検索を多用するシステムでよく採られる構成です。

なぜこれが重要なのか

WHG の意義は、それ単体で何かを派手に「見せる」ことよりも、他のプロジェクトをつなぐハブ（結節点）になる点にあります。

  • 相互運用性：バラバラに作られた歴史データを、共通の場所を介して接続できる
  • 時間つきの地名管理：「いつの、どこ」を正確に扱える（歴史研究には本質的）
  • オープンな標準と典拠：LPF という公開形式と、Wikidata/GeoNames という世界的典拠に接続

このシリーズで紹介してきた他のプロジェクト——Venice Time Machine、Sailing Letters、ORBIS——も、最終的に「どの場所の話なのか」を共通基準でそろえなければ互いに連携できません。WHG はその共通インフラを担おうとしています。

限界・注意点

  • 網羅性の限界：世界史の全地名の収録は原理的に不可能で、収録は連携データセットに依存する
  • 名寄せの難しさ：「この地名とあの地名は本当に同一か」の判断は自明でなく、専門知識を要する
  • 品質のばらつき：連携データセットごとに精度・粒度が異なる

まとめ

World Historical Gazetteer は派手な可視化のプロジェクトではありません。しかし「時間つきの地名という共通言語で、世界中の歴史データをつなぐ」という、デジタルヒューマニティーズの基盤として年々重要性を増す仕事を担っています。

その技術的な核心は、LPF（GeoJSON-T の実装）という公開データ形式と、Wikidata/GeoNames への名寄せにあります。データを「つなぐ」前に、まず「場所」を共通の基準でそろえる——WHG はその世界史の住所録を作る、縁の下の力持ちです。

参考リンク