OSMとウィキデータで何が起きているのか詳しく知りたい方には、まず下記OSMウィキ記事の一読をオススメする。
ゆるやかな連携
OSM保守派には割と毛嫌いされがちなWikidata連携だがwライセンスに対するスタンスや、そもそもの発祥や対象とする範囲が異なるため、無闇に連携するのはやはり無理がある。ざっくりいえばOSMの対象は現在の地理的なオブジェクト、wikipediaは特筆性のある多様なオブジェクト、Wikidataはより広い範囲の階層構造を持つ多様なオブジェクト、をそれぞれ対象範囲としている。連携方法としては、インポートはハードルが多すぎるのでリンクによるゆるやかな連携(federate)に落ち着くのではないだろうか。OSMには永続的なIDが無いためIDどうしを直接的に紐付けるのではなく、OSMと概念的に一致するウィキペディア記事やウィキデータ項目があればOSMタグとしてそれぞれ記事名や項目番号(Q番号)を記述するやり方だ。
wikipedia=ja:記事名
wikidata=Q番号
operator:wikidata=Q番号
ところで、こうやって連携した結果、何が嬉しいのだろうか？相互にリンクを張るといったこと以外に何ができるのだろうか。あえて嫌味な言い方をするとやはり井の中の蛙ではなく大海を見てみようよ、ということだろうと思う。Tim-BL卿の5つ星の世界観だ。
まずOSMの内側から見れば、例えばcuisineタグつまり世界中の料理のカテゴリや名前をOSM内で改めて定義するのはナンセンスで、ウィキデータにある階層化された膨大な量の料理の項目にリンクを張れば良いと思う。ただ、ウィキデータ自体がまだとっ散らかった状態で、概念の粒度、階層構造の適正化、過不足といった調整事項も多い。にもかかわらずOSMという閉じた世界でなく、Wikidataに足を伸ばしてそちらでデータを整備して、OSMからリンクしなおす、といったことができれば全体的なメリットが大きいと思われるのだが、そういったことがやれないものだろうかということを考えている。
他方、外側から見れば、全く別のデータベースから地図のデータベースにシームレスにジャンプインして地理的な情報を取得したり、表示できるということだ。利便性の面からはデータは極力少ないステップで機械的に辿れたほうが良いに決まっている。
データ品質向上のきっかけとしての連携
OSM側から見てwikidataタグやwikipediaタグを付けようとすることは相互の関係性を整理することでもある。そうすると概念的に欠けているもの、冗長なもの、分割出来るものなどが見えてきてデータ構造が正しく把握でき、結果として質が上がる場合がある。この点が現時点での最大のメリットではないだろうか。以下にいくつか具体例を挙げてみる。
例1 戸田橋
普通の感覚で橋といえばひとつの対象物を思い浮かべると思うが、OSMでは道路に「bridge=yes」タグを付加して橋をオマケ的に表すことが多いので、上り/下りの車線を分けた道路マッピングをすると同じ橋が2つ存在することになる。OSMでは橋の書き方は大きく3つあり、上記のように道路と橋を兼ねたウェイ、道路とは別の独立したエリア、オブジェクトの組み合わせとしてのリレーション、という3種類の表現ができる。
もちろん、OSMの文脈ではいずれも間違いではないのだが、ウィキペディアやウィキデータとリンクさせようとするとどちらにwikidata/wikipediaタグを付加するか、あるいは両方に付けるべきか迷ってしまう。
このような場合は橋をエリアで描く方法をオススメする。橋はひとつのオブジェクトになり、そこにwikidata/wikipediaタグを付加すると整合性が取れ、橋の名前としてのnameタグも付加できる。なお、元のウェイ上の「bridge=yes」は残しておいて良いと思う。
戸田橋には手を入れていないが、沼津の御成橋をエリアで描いてウィキデータやウィキペディアともリンクしたマッピング例はこんな感じ：
例2 戸定邸（重要文化財）
最後の将軍徳川慶喜の実弟昭武の別邸であったところ。敷地全体は公園となっており、旧邸は保存され、一部の建物が資料館となっている。
さて、「戸定邸」とは地理的にはどこを指すのだろうか。整理するとこんな感じ：
- 敷地全体：戸定が丘歴史公園
- 建物：戸定歴史館（博物館）、戸定邸（戸定館）－重要文化財指定
- 庭園：旧徳川昭武庭園（戸定邸庭園）－名勝指定
ざっと修正した結果は以下の通り：
-
wikidata
戸定邸(Q11496314)が博物館になっていたので歴史的家屋に変更。
博物館は別項目(Q60059496)として新規追加。
庭園は旧徳川昭武庭園(Q60059829)として新規追加。
公園は戸定が丘歴史公園 (Q60059561)として新規追加。 -
OSM
戸定歴史館のwikidataタグをQ11496314からQ60059496に変更。
敷地全体の公園名を「戸定邸」から「戸定が丘歴史公園」に変更しQ60059561にリンク。
戸定邸自体の建物を新規追加して「戸定邸」の名前を公園名からこちらに移動し、Q11496314、ja:戸定邸にそれぞれリンク。
庭園を新規追加し、Q60059829にリンク。 -
wikipedia
ja:戸定邸に上記がひとくくりで記載されている。オブジェクトごとに分割もできるのだろうが、この程度のボリュームであればまとまっていたほうが読みやすい。
このように相互に見比べることでそれぞれのコンテンツを改善したり充実させることができる。私自身はCategory:日本の建築物一覧やCategory:ウィキデータにない座標といったリストを見ながら、ヒマを見てこうしたことをやっている。
WikibaseによるOSMタグのメタデータの構造化
こちらはOSMデータそのものではなく、OSMウィキにあるタグの説明記事などについて、その書誌情報/メタデータ（OSMウィキのタグ説明ページ右側にある「説明」「適用できる要素」「状態」など、ウィキペディアのinfoboxに相当する部分）をウィキデータと同じくWikibaseというソフトウェアを利用して構造化するもので、OSMウィキの裏側でデプロイされ、データ整備も既にかなり進んでいる。
＜amenity=restaurantの例＞
タグのページ右側の「説明」欄にある鉛筆アイコンをクリックすると下記のようなWikibaseのデータ項目画面に遷移する。ここに各国語によるタグの定義が構造化データとして格納されており、必要に応じて内容を更新できる。現時点ではほとんどbotがOSMウィキやtaginfoより自動生成したものだ。
そのメリットはタグに関するメタデータがソフトウェアなどから利用しやすい形式になったことで、Wiki記法のマークアップからOSMのエディタなどが面倒なパースをしなくてもAPIやSPARQLクエリーでハンドリングできる。
OSMerにとっても特定のタグについて国別の適用対象の差異を表現できたりと、より間違いの少ないマッピングの支援にもつながりそうだ。
最終的にはinfoboxに相当する部分をWikibaseの内容で置き換えて一元管理するのが美しい姿だが、現時点では反対意見もあり、OSMウィキの直接的な書き換えにはまだ紆余曲折がありそうではある。