ここ最近オープンサイエンスの流れをうけて研究データのオープン化とか研究データ論文とかがにわかに話題になっているのですが,まずは自分がやってみないとということで,手始めに人工知能学会全国大会の原稿用に作ったデータセットにDOIふるというのをやってみました.なんでもDOIをふってくれるサイトとしてはfigshareとかがありますが,今回はZenodoを使ってみることにしました.理由はGitHub連携が面白そうだったからです.

ZenodoのSign UpはGitHubORCIDのアカウント持っていれば簡単にできます.私の場合はGitHubアカウントで登録して後からORCIDにも連携しました.

利用の仕方は,直接アップロードするか,Dropboxと連携するか,GitHubと連携するかになっています.一回毎に2GBまでOKだそうです.対象種類に制限はなくて,論文,ポスター,画像,ビデオ,ソフトウェア等何でも可能です.

今回作成したGitHubのレポジトリは,fumi/dbpedia-japanese-usecasesになります.DBpedia Japaneseを利活用しているアプリケーション,データセット,研究のリストという内容のデータをTSVで作成しました.

Zenodo側でGitHubレポジトリの連携をするのが以下の画面です.GitHub連携すると保有するレポジトリの全リストが取得されるので,連携したいレポジトリを明示的にOnにすれば良いです.Zenodo

その後に,連携したGitHubのレポジトリのほうで,”Releases”をクリックします.

GItHubのリリース
GItHubのリリース

次画面で”Draft a new release”をクリックすると,GitHub上でのリリースを行うフォームになるので,バージョン番号とコメント付けて”Publish release”をします.そうすると,Zetoro側が自動で新リリースの内容を取得してDOIを振ります.リリースした中身は,Zenodoのメニューの”My uploads”から辿ることが可能です.Zenodo

連携がうまく行っていれば先程リリースしたバージョンのリンクが含まれているはずですのでクリックします.次にしなければならないのが,データについての項目の編集です.”Edit”ボタンを押すと編集ができます.GitHubからの連携だとカテゴリが”Software”になっているので,データセットに変更する必要があります.他の項目は,AuthorやLicense,Keywordsという定番のものからFunding, Publicationなど研究関係の様々な項目が設定できるようになっています.Zenodo上でコミュニティを作るということもできるようです.変更が終わったら”Submit”すれば完了です.

編集画面
編集画面

編集が終わった後のView画面が以下です.

ZenodoのView
ZenodoのView

右のDOIバッジをクリックするとMarkdownやらHTMLやらでの埋め込みコードが取得できます.わりとすごいのがCite asのプルダウンメニューで殆どの論文誌や学会のrefをカバーしているところです.また,BibTexやEndNoteなどの形式のExportもできます.

使っていて不便だった点は,リリースをする毎に新しいDOIが発行されるのですが,同じもののバージョン違いのDOIに何の関連もないことと,項目内容の引き継ぎがないので毎回項目を再入力しないといけないことです.これが地味に面倒.また,別の問題としては,リリースをしないとDOIが発行されないので,READMEにDOIバッジをはっている場合,前のDOIバッジのREADMEが含まれたままリリースされることになることです.これは些細な話ではありますがリリースファイルをダウンロードすると一貫性がなくて不思議なきもちになります.

総じて連携は簡単で,とりあえずなんでもDOIをはっていくには便利そうなのでしばらく使おうとおもいます.

これは SPARQL Advent Calendar 2015 9日目の記事です.

以前Wikidata Linked Dataという記事を書いた通り,Wikidata のデータ提供部分はLinked Dataです.これまでもサードパーティがそのRDFで勝手SPARQLエンドポイントを立てていたりしたのですが,今年9月にWikimediaが公式にWikidata Query ServiceというSPARQLエンドポイントをβ公開しました.今回はこれを使ってみようとおもいます.

サンプル例にアメリカ歴代大統領というのがあったので,試しに歴代の内閣総理大臣を開始年でソートするクエリを書いてみました(SPARQL例へのリンク).

PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wd: <http://www.wikidata.org/entity/> 
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX psv: <http://www.wikidata.org/prop/statement/value/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
PREFIX pqv: <http://www.wikidata.org/prop/qualifier/value/>

SELECT ?primeMinister ?primeMinisterLabel ?startTime
WHERE {
   ?primeMinister p:P39 ?positionStatement .
   ?positionStatement ps:P39 wd:Q274948 ; 
                      pq:P580 ?startTime .
  
   SERVICE wikibase:label {
      bd:serviceParam wikibase:language "ja,en" .
   }
 }
ORDER BY ?startTime

結果は45件で,データとしてはかなり欠けています.明治・大正時代の人が全然いませんし,近年をみても麻生太郎と鳩山由紀夫が入っていません.皆で日本に関するデータを整備していく必要があります.

Wikidataのデータは多言語化前提になっていて,全てのリソースにIDベースのIRIが振られていて,そのIRIに対して多言語によるラベルを付与するというモデルになっています.そのため,リソースによってラベルがある言語がバラバラになるので,言語指定のフォールバックができる仕組みをSPARQLを拡張して用意しています.上記のクエリのSERVICE wikibase:label { ... }の部分がそれです.bd:serviceParam wikibase:language "言語名"の言語名の部分に複数の言語を指定すると,その順番でラベルを使用します.例えば”ja,en”であれば日本語が主で,日本語がない場合は英語を取得します.指定した言語がない場合はリソースのIRIになります.SELECTで指定する変数として,実際にラベルを取得したい変数の最後に”Label”を付けたものを指定することで,自動的にラベルを取得できます.上記例では,?president 変数のラベルとして?presidentLabelを指定しています.

この自動ラベル変換機能は一々言語毎にFILTERをするといった複雑なことをしなくて済むので便利ですが,いくつか制約があります.まず,OPTIONALで使っている変数は現在エラーになるようです(これはバグかもしれません).また,ラベルの中身に応じてフィルターしたいときのように,クエリ内で変数を参照したいときには使えません.その場合は,SERVICE句の中で直接rdfs:labelでラベル変数を指定すれば良いです.但し,自動変換機能と併用することはできないので,必要なラベルを全て指定する必要があります.

Wikidataまだまだこれからですが,色んなエンティティを結びつけるデータとしてどんどん整理されつつあるので,揃ってくればかなり期待できるサービスだとおもいます.

参考:

有志でSPARQLについての解説本をインプレスR&Dさんより出版しました.すでに電子書籍は本日付で発売となっています (Kindle版, Kobo版, iBooks版, Google Play版).何故かGoogle Playはいきなり1割引しているようです...紙の本は後日Amazon.co.jpのプリント・オン・デマンド発売される予定です.

これはCivic Tech Advent Calendar 2014の19日目の記事です.

最近,Open Parkというプロジェクトを勝手にはじめてみました.直接のきっかけは,公園の禁止事項がどんどん増えているのを見て,そもそも地域の公園情報が全然共有されていないと感じたことでした.単純にボールを使って遊びたいと思っても,できる公園を探すのが大変です.大きい運動公園くらいになると検索サイトがあったりするのですが,住宅街の中の公園は殆ど何もなく,多くの場合は現地の掲示板や看板にのみ許可や禁止が書かれています.内容は法律や条例で禁止されているものからマナーまで様々です.最初は自治体がこの手の情報を全て管理しているのかと想像していたのですが,実はそうではなく愛護会のように地域住民のボランティアで成り立っている部分がかなりあることがわかりました.そこで,地域の公園データを収集・公開・共有できる場所が必要なのではないかと考えました.

公園看板
公園看板

とりあえず試作してみようということで,主に横浜市金沢区のオープンデータを利用して,Open Park Yokohamaというのを作ってみました.横浜市金沢区を最初の例として選んだ理由は,公園関連のデータが既にいくつか公開されていたためです.

現在Open Park Yokohamaでできることは,地図から公園を探すのと遊具の種類で探すことだけです.各公園のページでは,公園の基本データと,公園にある遊具や看板写真等を載せています.写真については手始めに30ヶ所程度の公園を撮影してきましたが,金沢区全域で190の公園があるので1/6程しかカバーしていません.

寺前さざなみ公園
寺前さざなみ公園

技術的な話としては,データは主に共通語彙基盤のコア語彙2.10Schema.orgをベースに設計をしてあります.一応現在のデータ用のSPARQLエンドポイントも出していますが,今後データ設計は変える予定ですのでお試し程度ということで.Linked Data対応等のAPI充実化はする予定です.

今取り組んでいるのは,公園写真を増やすことと,それらの写真から禁止事項や許可事項をデータ化して禁止・許可事項データを作ることです.やってみると結構大変で,公園毎に表現がバラバラだったり曖昧だったりします.顕著な例としては上の看板にある「危険な球技」や「危険なあそび」というのです.公園毎に「危険な球技」として列挙されている球技が異なりますし,そもそも「危険な球技」が何かがわからないので判断に困ります.これが,数を集めるとわかったりするのではないかと期待しています.全国でやってみると地域ごとの傾向があったりするかもしれません.

将来的には市民を巻き込んで発展していく仕組みが必要だと考えています.例えば横浜全体でやろうとすると公園が2000近くあるそうなので,スマートフォンで写真をアップロードしてもらったり,データを入力してもらったりして効率よく収集する仕組みがあるといいでしょう.OpenStreetMapで公園データを充実させて利用するというのもありえます.うまく全国で集められるようになると面白いなとおもっています.

オープンデータ活用コンテスト___未来とメトロ___東京メトロ 10th anniversary

以下はFacebook上での議論をまとめたものです.

東京メトロさんは以前から”オープンデータ”を行うという宣伝をしていたのですが,昨日やっと概要が公開されました.企業がオープンデータを出してその活用コンテストも行うというのは大変素晴らしいことで,何より多くの人が興味を持ちやすいデータですので是非応援したいし,できれば何かアプリを作りたいなとも思っています.

しかし,現在の応募規約について様々な疑問がでており,これはオープンデータではなく単なるAPIコンテストになっているのではないかという懸念があります.ちなみにこの規約のページは何故かPCのブラウザからは404 Not Foundですが,スマフォのブラウザからは見られるようになっています (PCからもヘッダ変えると見られます)

上から順番に見ていきますが,まず,“応募作品は、応募者が考案・開発したものであり、全ての著作権を有しているものに限ります。”とありますが,オープンデータを活用するのが前提である以上,データの部分の著作権は応募者が有していないことが殆どであるかとおもいます.ソフトウェア部分の著作権について述べていると解釈するのであればわかります.(追記: ソフトウェア部分もオープンソースのライブラリ等使ったら駄目ということですかね.)

次に“オープンフリーで利用できる他データの組み合わせは可能とします。(例、twitter API、yahoo API、など)”とありますが,オープンフリーの定義がわかりません.例として挙げられているtwitter APIやyahoo APIは少なくともオープンデータではありませんので,オープンフリーが何を指すのか明らかにして頂かないと応募者はわからないのではないでしょうか.

3つ目として,これが一番重要ですが,“応募者は、データ等を本コンテストへの応募作品の開発及び本コンテストの応募以外の目的で使用してはならないものとします。”とあります.オープンデータと謳うのであれば,このような目的外利用の制限はおかしいです.“応募者は、データ等及び本コンテストへの応募作品を、有償か無償かに係らず商業目的には利用できないものとします。”というのも同様です.

繰り返しますが,試み自体は大変素晴らしいことですので,東京メトロさんには是非オープンデータという単語を誤用せずに正しく理解した上でコンテストを行なって頂ければと切に願います.

OS Linked Dataの行政区画は,Office for National Statistics(日本の統計局か統計センター?)のONS linked data portalにつながっています.例えばBoundary-Line Linked Dataの記事で取り上げた Haggerston のデータには,以下のリンクがあります.

<http://data.ordnancesurvey.co.uk/id/7000000000011110> <http://www.w3.org/2002/07/owl#sameAs> <http://statistics.data.gov.uk/id/statistical-geography/E05000239> .

ONS linked dataでは,統計上の区画を全てstatistical-geographyクラスのインスタンスとしています.これはOS Linked Dataとは異なる設計です.ここでは,OS Linked Dataから見て,HaggerstonとONS linked dataにおけるHaggerstonが同じである(owl:sameAs)というリンクをしています.以下の図は前回の図からONS linked data portalへのリンクを追加したものです.

OS Linked DataとONS linked data
OS Linked DataとONS linked data

基本的にはONS linked data portal上にも各行政区画に相当するstatistical-geographyが記述されており,その包含関係も記述されています.一つ面白いのはLondonです.Londonには行政区画としてのLondonとEuropean RegionとしてのLondonが記述されており,OS Linked DataのLondonからのowl:sameAsリンクはEuropean RegionとしてのLondonにされていますが,ONS linked data portal上での行政区画の包含関係は行政区画としてのLondonを使うようになっています.これは意図して行っているのかが不明でもしかしたらミスかもしれませんが,意図しているのであれば明示的に役割によってLondonをURIで区別して利用している例だと言えます.

以前のOS Linked Dataについての記事.

郵便番号EC2A 4JEのデータを見ると,その郵便番号がある行政区画へのリンクがあります.

EC2A 4JEの行政区画
EC2A 4JEの行政区画

Ward: Haggerstonを見てみると,行政区画についてのデータとその境界線の表示をしてくれます.

Haggerston
Haggerston
% curl -LH 'Accept: text/turtle' http://data.ordnancesurvey.co.uk/id/7000000000011110
.......
<http://data.ordnancesurvey.co.uk/id/7000000000011110>
        a           <http://data.ordnancesurvey.co.uk/ontology/admingeo/LondonBoroughWard> ;
        rdfs:label  "Haggerston" ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/gssCode>
                "E05000239" ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/hasAreaCode>
                "LBW" ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/hasUnitID>
                "11110" ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/inCounty>
                <http://data.ordnancesurvey.co.uk/id/7000000000041441> ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/inDistrict>
                <http://data.ordnancesurvey.co.uk/id/7000000000011199> ;
        <http://data.ordnancesurvey.co.uk/ontology/admingeo/inEuropeanRegion>
                <http://data.ordnancesurvey.co.uk/id/7000000000041428> ;
        <http://data.ordnancesurvey.co.uk/ontology/geometry/extent>
                <http://data.ordnancesurvey.co.uk/id/geometry/11110-241> ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/easting>
                533455.5 ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/northing>
                "182927"^^<http://www.w3.org/2001/XMLSchema#decimal> ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/touches>
                <http://data.ordnancesurvey.co.uk/id/7000000000011193> , <http://data.ordnancesurvey.co.uk/id/7000000000041879> , <http://data.ordnancesurvey.co.uk/id/7000000000010856> , <http://data.ordnancesurvey.co.uk/id/7000000000010854> , <http://data.ordnancesurvey.co.uk/id/7000000000010855> , <http://data.ordnancesurvey.co.uk/id/7000000000011112> , <http://data.ordnancesurvey.co.uk/id/7000000000011196> , <http://data.ordnancesurvey.co.uk/id/7000000000011111> ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/within>
                <http://data.ordnancesurvey.co.uk/id/7000000000011199> ;
        <http://www.georss.org/georss/point>
                "51.529489 -0.07749" ;
        <http://www.w3.org/2002/07/owl#sameAs>
                <http://statistics.data.gov.uk/id/statistical-geography/E05000239> ;
        <http://www.w3.org/2003/01/geo/wgs84_pos#lat>
                51.529489 ;
        <http://www.w3.org/2003/01/geo/wgs84_pos#long>
                -0.07749 ;
        <http://www.w3.org/2004/02/skos/core#prefLabel>
                "Haggerston" .

データで使われている語彙のURIが長いので以下のprefixで省略して書きます.

@prefix geometry: <http://data.ordnancesurvey.co.uk/ontology/geometry/>
@prefix spatialrelations: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/>
@prefix admingeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/>

境界線データはgeometry:extentの<http://data.ordnancesurvey.co.uk/id/geometry/11110-241>に含まれています.GMLが直接埋め込んである形になっています.

% curl -LH 'Accept: text/turtle' http://data.ordnancesurvey.co.uk/id/geometry/11110-241
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://data.ordnancesurvey.co.uk/id/geometry/11110-241>
        a       <http://data.ordnancesurvey.co.uk/ontology/geometry/AbstractGeometry> ;
        <http://data.ordnancesurvey.co.uk/ontology/geometry/asGML>
                "<gml:Polygon xmlns:gml=\"http://www.opengis.net/gml\" srsName=\"http://www.opengis.net/def/crs/EPSG/0/27700\"><gml:exterior><gml:LinearRing><gml:posList srsDimension=\"2\">533259.9 183282.5 533263 183333.5 533338.9 183342.6 533438.8 183351.7 533469 183358.5 533470.5 183413 533472.6 183487.2 533475.4 183547.4 533479.4 183742 533478.1 183844.1 533479.6 183921.1 533557.9 183928.4 533667 183934.9 533714.4 183937.9 533735.2 183943.8 533719.7 183956 533700.9 183973.5 533684.8 183989 533663.3 184013.4 533693 184012.1 533723.7 184009.8 533736.6 184009.2 533779.7 184006.5 533807.9 184004.5 533827.5 184002.8 533882.3 183999.2 533882.4 184005.2 533930.4 184003.1 533928.4 183932.1 533925.2 183860.9 533928.2 183828.2 533937.5 183695.1 533942.4 183648.7 534044 183636.2 534094.3 183632.5 534105.3 183632.1 534116.1 183631.6 534164.2 183631.8 534223.2 183630.1 534330.8 183632.6 534431.4 183629.5 534479.5 183624.7 534466.7 183600.3 534458.1 183577.8 534454.7 183565.6 534456.6 183526 534463.6 183481.6 534466.6 183466.6 534477.6 183432.5 534486 183413 534496.6 183388.5 534502.3 183372.8 534472.2 183365 534431.7 183352.2 534313.1 183329.2 534303.3 183359.6 534301.1 183364.2 534286.4 183332.5 534269.8 183279.2 534252.2 183229.3 534234.1 183171.7 534225.6 183140.6 534156.8 183129.2 534109.3 183122.7 534019.3 183113.4 533976.4 183111.8 533933.7 183108 533885.2 183101.7 533857.5 183097.1 533837.3 183091.4 533813.9 183086.7 533778.1 183069.1 533768.9 183064 533753.4 183055 533710.8 183028.4 533692.3 183013.8 533683.8 183005.7 533670.1 182990.9 533651.6 182965.8 533633.1 182923.5 533608.1 182854.9 533597.6 182831.7 533587.2 182813.2 533584.2 182808.4 533560.1 182777.7 533539.3 182749.6 533503 182707.2 533478.3 182683.6 533543.8 182668.6 533541.7 182638 533530.1 182597.5 533523.8 182583.7 533523.8 182571 533524 182557.9 533525.4 182539.7 533532.1 182466.3 533543.3 182350.4 533579.8 182355.2 533590.8 182303.7 533595.6 182273.9 533595.3 182262.5 533593.2 182228.3 533590.5 182212.8 533589.1 182204.9 533587.6 182196.7 533578.1 182158.2 533574.1 182138.8 533568.8 182118.9 533567.3 182113.4 533549.2 182097.4 533530.3 182119.1 533501.9 182107.5 533447.5 182086.9 533426 182076.5 533411.9 182041.6 533410.7 182037.9 533320.2 182053.4 533250.9 182075.9 533230.5 182082.5 533215.8 182024.1 533198.6 181978 533184.6 181948.2 533182.4 181945.4 533167.5 181925.3 533146.8 181897.9 533119.2 181869.8 533078.9 181840.5 532946.1 181894.9 532955.7 181928 532965.8 181968.7 532978.1 182037.3 532989.2 182089.3 532993.7 182136 532998.2 182237.5 532999.2 182259.8 533004.7 182293.3 532983.6 182292.4 532941.1 182294.3 532941.6 182350.2 532918.3 182359 532920.4 182368.1 532929.3 182396.8 532944.9 182436.9 532963.7 182460.8 532942.7 182547.9 532938.5 182560.8 532968.5 182570.5 533030.4 182589.1 533033.1 182616.6 533034.4 182629.4 533033.9 182758.8 533098.2 182759.6 533130.9 182761.2 533172.8 182761.8 533179.8 182763.4 533188.1 182763.8 533220.3 182765.5 533225.7 182770.9 533274.9 182774.5 533279.2 182853.1 533280.3 182885 533279.7 182897.7 533277.3 182923.3 533263.6 182979.3 533261.1 182990.3 533259.6 183009.1 533259.8 183032.7 533261.9 183069.2 533260.6 183164.1 533260.9 183204 533259.9 183282.5</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>"^^rdf:XMLLiteral ;
        <http://data.ordnancesurvey.co.uk/ontology/geometry/hectares>
                124.25 .
.......

行政区画には隣接関係と包含関係があります.隣接関係は spatialrelations:touchesというプロパティです.包含関係は郵便番号と同様にspatialrelations:within, spatialrelations:containsプロパティが使われていますが,admingeo:county, admingeo:districtあるいはadmingeo:inCounty, admingeo:inDistrictのように直接の上下以外も明示的に個記述されています.

Administrative Region
Administrative Region

OS Linked Dataの続きです.今回はCode-Point Open Linked Dataについて.Code-Pointはイギリスの郵便番号(Postcode)に関するデータですが,基本的な項目をCode-Point Openでオープンデータとして公開しています.詳細なデータを使うには別途メンバーシップ契約が必要です(How to buy, 実際の手続きはやったことないので不明).Code-Point Open Linked DataはCode-Point Openの部分についてLinked Dataにしています.

フォームでは郵便番号文字列の検索ができます.例えば”EC2A”で検索すると,EC2Aを含んだ郵便番号が返ってきます.

EC2Aの検索結果
EC2Aの検索結果

地名と同様に,郵便番号もURIで識別されます.EC2AのURIはhttp://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2Aです.Webブラウザで見ると以下のようになります.

EC2A
http://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2A

text/turtleを要求すると以下のような結果が返ってきます.

% curl -LH 'Accept: text/turtle' http://data.ordnancesurvey.co.uk/id/pozstcodedistrict/EC2A
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix dct:   <http://purl.org/dc/terms/> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://data.ordnancesurvey.co.uk/ontology/postcode/PostcodeDistrict>
        rdfs:label  "Postcode District"^^<http://www.w3.org/2001/XMLSchema#string> .

<http://data.ordnancesurvey.co.uk/id/postcodearea/EC>
        rdfs:label  "EC" .

<http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A3>
        rdfs:label  "EC2A 3" .

<http://data.ordnancesurvey.co.uk/doc/postcodedistrict/EC2A>
        a                  foaf:Document ;
        rdfs:seeAlso       <http://sameas.org/rdf?uri=http://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2A> ;
        dct:title          "Description of http://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2A" ;
        foaf:primaryTopic  <http://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2A> .

<http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A1>
        rdfs:label  "EC2A 1" .

<http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A4>
        rdfs:label  "EC2A 4" .

<http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A2>
        rdfs:label  "EC2A 2" .

<http://data.ordnancesurvey.co.uk/id/postcodedistrict/EC2A>
        a           <http://data.ordnancesurvey.co.uk/ontology/postcode/PostcodeDistrict> ;
        rdfs:label  "EC2A" ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/contains>
                <http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A4> , <http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A3> , <http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A2> , <http://data.ordnancesurvey.co.uk/id/postcodesector/EC2A1> ;
        <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/within>
                <http://data.ordnancesurvey.co.uk/id/postcodearea/EC> .

ここで面白いのは,イギリスの郵便番号の記法には体系があって,その包含関係がデータとして記述されています.具体的にはhttp://data.ordnancesurvey.co.uk/ontology/spatialrelations/withinhttp://data.ordnancesurvey.co.uk/ontology/spatialrelations/containsという二つのプロパティを使ってその関係を記述しています.地域によって桁数等は異なりますが,全体として必ず4階層になるようになっています.以下はOpen Data Instituteの郵便番号である EC2A 4DJ の例です.左の青丸が郵便番号のリソースで,右の茶丸は属するクラスです.図を簡略化するためにURIは省いてあります.

Postcode Model
Postcode Model

一番下のPostcodeUnitが実際に使われている郵便番号に相当します.http://data.ordnancesurvey.co.uk/id/postcodeunit/EC2A4JEを見ると,PostcodeUnitのデータには行政区や統計上の区分との関係が記述されるようになっています.これは別エントリで書きます.

EC2A 4JE
http://data.ordnancesurvey.co.uk/id/postcodeunit/EC2A4JE