このたび、mirko.jp のドメインを取得し、公共オープンデータ利活用研究室 mirko のホームページに割り当てた。
https://www.mirko.jp/
公共オープンデータ利活用研究室 mirko は、ネットオウルのレンタルサーバーで運営している。
ネットオウルは、地元の京都市の会社なので、個人的に応援しているという理由もある。
これまでは、ネットオウルの「ミニバード」というサービスのサブドメインに、僕のニックネーム mirko を割り当てて mirko.minibird.jp としていた。
上記のURLに特に不満はなかったのだが、やっぱり、ずっと使える永続的なURLがいいなと思い、ネットオウルから独自ドメインの取得申請を行った。
何の苦労もなく、５分で手続き完了。
浸透するまで半日ほど待ち、リダイレクトかけて、グーグル検索のサイト引っ越しをちょいちょいと。はい完成。簡単なもんだ。
ドメイン取得で思い出すのは、今から２０数年前、まだＷＥＢ黎明期だったころ、仲介業者を介さず、苦労して自力でドメインをとったこと。
とったドメインは pospe.com 。
当時、ポストペット（通称ポスペ）というメーラーが大流行していて、私はそれをマニアックに解析するという、「ポストペットマニアックス」というサイトを、そのドメインで運営していた。若かりし頃の黒歴史の一つだ。
そのポストペットマニアックス、結構人気もあって、２年ほど楽しく遊んでいたのだが、当時、お金が全然無くなっちゃって、生活のため、やむ無く pospe.com をドメイン屋に売り払った。
まだポストペット人気が高い時期だったので、僕のポスペコムは８万円くらいで売れたように記憶している。おかげで、何とか生き延びることができた。
（今の時代なら広告収入でウハウハ生活ができたのになぁ…）
そのポスペコム、今はどうなってるんだろうと覗いてみたら、こんなだった。
http://www.pospe.com/
兵どもが夢の跡かな（笑）
2018年4月28日土曜日
統計LODの家計調査データセット
先日の、統計LODのデータセット追加リリースで、家計調査 が追加された。
家計調査は、政府が消費者物価指数をつくるときの資料にしたり、景気動向を知る指標としたり、様々な（真面目な）目的で使われている。
その家計調査、僕らのような一般の統計ユーザーが面白いと思う点は、食べ物の品目ごとに、都市別で、世帯当たりの支出金額や消費数量が調査されているところ。
「京都人はパンが好き」とか、「餃子日本一はどこか？」の元ネタだ。
ただし、家計調査は標本調査であり、しかも都市別となると標本数がかなり少ないので、統計としての定量的な信頼性はイマイチだ。
まあ、それをきちんと踏まえた上で、政府がお墨付きを与えたトリビアネタ との位置づけでどんどん使えば、政府統計の普及啓発にも一役買うことができる、ということだ。
さっそく、スパークルをたたいてデータセットを覗いてみる。
まずは「調査年月」を調べるクエリ。
2005年9月以降の毎月のデータがあることがわかる。
ちなみに、家計調査は「家計調査年報」という形で、１年間の合計値や平均値が公表されているが、統計LODには年報データは無いようでガッカリ。
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX g00200561-dimension: <http://data.e-stat.go.jp/lod/ontology/g00200561/dimension/2015/>
PREFIX g00200561-code: <http://data.e-stat.go.jp/lod/ontology/g00200561/code/2015/>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
SELECT DISTINCT ?yearmonth
WHERE {
?s qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200561/d0003103532> ;
g00200561-dimension:ieClassification g00200561-code:ieClassification-1_1_2 ;
cd-dimension:timePeriod ?yearmonth .
} ORDER BY DESC(?yearmonth)
次は、2017年7月のパンへの支出金額を、対象自治体ごとに調べるクエリだ。
都道府県庁所在市 ＋ その他の政令市 ＋ 全国値 の、計５３の観測値が表示される。
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX g00200561-dimension: <http://data.e-stat.go.jp/lod/ontology/g00200561/dimension/2015/>
PREFIX g00200561-code: <http://data.e-stat.go.jp/lod/ontology/g00200561/code/2015/>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
PREFIX ic: <http://imi.go.jp/ns/core/rdf#>
select ?citycode ?cityname ?o
where {
?s qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200561/d0003103532> ;
g00200561-dimension:ieClassification g00200561-code:ieClassification-1_1_2 ;
cd-dimension:timePeriod "2017-07"^^xsd:gYearMonth ;
sdmx-dimension:refArea ?citycode ;
estat-measure:moneyAmount ?o .
?citycode ic:表記 ?cityname .
} ORDER BY ASC(?citycode)
これらのクエリをアプリに組み込んで、面白いものができないかなーと現在検討中。
家計調査データセットについて、総務省統計局へお願いしたいのは、次の２点。
ひとつ目は「年報」のデータも入れてほしいこと。
ふたつ目は、支出金額だけでなく「消費数量」のデータも欲しいこと。
よろしくお願いします m(__)m
家計調査は、政府が消費者物価指数をつくるときの資料にしたり、景気動向を知る指標としたり、様々な（真面目な）目的で使われている。
その家計調査、僕らのような一般の統計ユーザーが面白いと思う点は、食べ物の品目ごとに、都市別で、世帯当たりの支出金額や消費数量が調査されているところ。
「京都人はパンが好き」とか、「餃子日本一はどこか？」の元ネタだ。
ただし、家計調査は標本調査であり、しかも都市別となると標本数がかなり少ないので、統計としての定量的な信頼性はイマイチだ。
まあ、それをきちんと踏まえた上で、政府がお墨付きを与えたトリビアネタ との位置づけでどんどん使えば、政府統計の普及啓発にも一役買うことができる、ということだ。
さっそく、スパークルをたたいてデータセットを覗いてみる。
まずは「調査年月」を調べるクエリ。
2005年9月以降の毎月のデータがあることがわかる。
ちなみに、家計調査は「家計調査年報」という形で、１年間の合計値や平均値が公表されているが、統計LODには年報データは無いようでガッカリ。
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX g00200561-dimension: <http://data.e-stat.go.jp/lod/ontology/g00200561/dimension/2015/>
PREFIX g00200561-code: <http://data.e-stat.go.jp/lod/ontology/g00200561/code/2015/>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
SELECT DISTINCT ?yearmonth
WHERE {
?s qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200561/d0003103532> ;
g00200561-dimension:ieClassification g00200561-code:ieClassification-1_1_2 ;
cd-dimension:timePeriod ?yearmonth .
} ORDER BY DESC(?yearmonth)
次は、2017年7月のパンへの支出金額を、対象自治体ごとに調べるクエリだ。
都道府県庁所在市 ＋ その他の政令市 ＋ 全国値 の、計５３の観測値が表示される。
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX g00200561-dimension: <http://data.e-stat.go.jp/lod/ontology/g00200561/dimension/2015/>
PREFIX g00200561-code: <http://data.e-stat.go.jp/lod/ontology/g00200561/code/2015/>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
PREFIX ic: <http://imi.go.jp/ns/core/rdf#>
select ?citycode ?cityname ?o
where {
?s qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200561/d0003103532> ;
g00200561-dimension:ieClassification g00200561-code:ieClassification-1_1_2 ;
cd-dimension:timePeriod "2017-07"^^xsd:gYearMonth ;
sdmx-dimension:refArea ?citycode ;
estat-measure:moneyAmount ?o .
?citycode ic:表記 ?cityname .
} ORDER BY ASC(?citycode)
これらのクエリをアプリに組み込んで、面白いものができないかなーと現在検討中。
家計調査データセットについて、総務省統計局へお願いしたいのは、次の２点。
ひとつ目は「年報」のデータも入れてほしいこと。
ふたつ目は、支出金額だけでなく「消費数量」のデータも欲しいこと。
よろしくお願いします m(__)m
2018年4月27日金曜日
ブログを作ってみた。
理由は、自治体なんでもランキング with 統計LOD の おまけコラム を、ブログに移したほうが合理的かなー、と思ったから。
ブログも、今時はいろんなサービスがよりどりみどりで迷ってしまう。
FC2とかアメブロとかはてなブログとか…
悩んだ結果、僕はグーグルのブログサービス Blogger にした。
検索でもっと上位に来るブログサービスも色々ありそうだが、僕のブログはただの独り言日記みたいなものなので、あまり読まれなくてもいいし、何より広告が無いのがイイ！
グーグルなので、親サイト自体がつぶれて、サービスが停止されることもまずないだろうし。
（グーグルがブログサービスを突然やめちゃう可能性はあるが…）
ワードプレスを使って自分で作ろうとも思ったが、最近忙しくて、めんどくさくなって諦めてしまった…
時間ができて、ワードプレスのほうが良さそうなら、そのうち乗り換えるかも。
ブログも、今時はいろんなサービスがよりどりみどりで迷ってしまう。
FC2とかアメブロとかはてなブログとか…
悩んだ結果、僕はグーグルのブログサービス Blogger にした。
検索でもっと上位に来るブログサービスも色々ありそうだが、僕のブログはただの独り言日記みたいなものなので、あまり読まれなくてもいいし、何より広告が無いのがイイ！
グーグルなので、親サイト自体がつぶれて、サービスが停止されることもまずないだろうし。
（グーグルがブログサービスを突然やめちゃう可能性はあるが…）
ワードプレスを使って自分で作ろうとも思ったが、最近忙しくて、めんどくさくなって諦めてしまった…
時間ができて、ワードプレスのほうが良さそうなら、そのうち乗り換えるかも。
2018年4月23日月曜日
「Ｓ」をめぐる、ＩＰＡと統計局のすれ違い (2018.4.15)
2018年4月13日、統計LODのデータが拡充された。
このWEBアプリで使っている「社会・人口統計体系」のデータも、今回たくさん追加されたので、さっそくプログラムを修正し、追加されたデータも取得できるようにした。
市区町村レベルのデータが大幅に増えたので、一度お試しあれ。
（データが増えた分、前よりさらに重くなったような気がするのは、きっと気のせいだろう…）
さて、統計LODでは、今回、データの拡充と同時に、共通語彙基盤の名前空間URIを、旧URIから新URIに置き換える修正を実施した。
私が以前から要望していたことを実現していただき、感謝の意をお伝えしたい。
私はさっそく、この修正に合わせ、「自治体なんでもランキング with 統計LOD」で使っているSPARQLクエリ内の、共通語彙基盤URIを書き換えることにした。
「ん？ ……！」
調べてみると、統計LODで使われている名前空間URIは次のようになっている。
http://imi.go.jp/ns/core/rdf# （ここ参照）
一方、IPAが使ってくれ、と言っているURIは次のものだ。
https://imi.go.jp/ns/core/rdf# （ここ参照）
…あー、恐れていたことが起きてしまった！
IPAからしたら、ちゃんとリダイレクトかけてるから別にいーじゃん、という考えが根っこにあるのかもしれないが、私のようなオープンデータ作成者や、アプリケーション開発者にとっては、決して看過できない大問題だ。
なぜなら、http://imi.go.jp/ns/core/rdf# と https://imi.go.jp/ns/core/rdf# は、全く別の文字列だから。
データとデータがつながる Linked Data の特性を生かすための「フェデレーテッドクエリ」も、これでは全く真価を発揮できず、つながるものもつながらない。スパークラーの皆さんなら、きっと共感していただけるかと思う。
このIPAと統計LODとの交通事故における「過失割合」を考えると、私は８：２でIPAが悪いと思う。
（統計LOD側の不注意も少しはあるが…）
共通語彙基盤における、RDF用名前空間はまず次のURIからスタートした。
http://imi.ipa.go.jp/ns/core/rdf#
その後、次のURIに変更された。
http://imi.go.jp/ns/core/rdf#
最初のものはIPAドメインのサブドメインとしてIMIが設定されていたが、名前空間URIの不変性を担保するために、IPAドメインとは切り離し、IMI独自ドメインとして設定するのが望ましいということだろう。その意図はよく分かる。
その後、今度は以下のURIに変更された。
https://imi.go.jp/ns/core/rdf#
最近は猫も杓子もSSLで、SSLにあらずんばWEBにあらず、という勢いだ。
IPAは我が国の情報処理を司る大本営。SSL対応とするのは当たり前と言えば当たり前。
大切なのは、結果として３種類できてしまった名前空間URIを、ユーザーに対しどのように周知徹底し、最新のURIにいかに導いていくかだ。
IPAはそこを大事にしなければならないというのに、最新のコア語彙バージョン2.4.1のページで提示されているRDFスキーマやJSON-LDコンテキストを見ると、驚くべきことに、いまだに「s」がついていない。（2018年4月15日現在）
これでは、統計LODサイドが勘違いするのもむべなるかな。はっきり言ってこれはIPAの怠慢だと言わざるを得ない。起こるべくして起きた事故だ。
共通語彙の目的は、みんなが使う語彙の共通化。共通語彙基盤はみんなのハブ空港。
共通化どころか、自らの手で基準を乱立させ、周知徹底もせず、リダイレクトをかけるだけで満足しているようなデリカシーのない共通語彙からは、ユーザーはどんどん離れていくのが目に見えている。
共通語彙基盤を本気で流行らせたいのなら、もっとちゃんとしてください！頼みますよ！！
このWEBアプリで使っている「社会・人口統計体系」のデータも、今回たくさん追加されたので、さっそくプログラムを修正し、追加されたデータも取得できるようにした。
市区町村レベルのデータが大幅に増えたので、一度お試しあれ。
（データが増えた分、前よりさらに重くなったような気がするのは、きっと気のせいだろう…）
さて、統計LODでは、今回、データの拡充と同時に、共通語彙基盤の名前空間URIを、旧URIから新URIに置き換える修正を実施した。
私が以前から要望していたことを実現していただき、感謝の意をお伝えしたい。
私はさっそく、この修正に合わせ、「自治体なんでもランキング with 統計LOD」で使っているSPARQLクエリ内の、共通語彙基盤URIを書き換えることにした。
「ん？ ……！」
調べてみると、統計LODで使われている名前空間URIは次のようになっている。
http://imi.go.jp/ns/core/rdf# （ここ参照）
一方、IPAが使ってくれ、と言っているURIは次のものだ。
https://imi.go.jp/ns/core/rdf# （ここ参照）
…あー、恐れていたことが起きてしまった！
IPAからしたら、ちゃんとリダイレクトかけてるから別にいーじゃん、という考えが根っこにあるのかもしれないが、私のようなオープンデータ作成者や、アプリケーション開発者にとっては、決して看過できない大問題だ。
なぜなら、http://imi.go.jp/ns/core/rdf# と https://imi.go.jp/ns/core/rdf# は、全く別の文字列だから。
データとデータがつながる Linked Data の特性を生かすための「フェデレーテッドクエリ」も、これでは全く真価を発揮できず、つながるものもつながらない。スパークラーの皆さんなら、きっと共感していただけるかと思う。
このIPAと統計LODとの交通事故における「過失割合」を考えると、私は８：２でIPAが悪いと思う。
（統計LOD側の不注意も少しはあるが…）
共通語彙基盤における、RDF用名前空間はまず次のURIからスタートした。
http://imi.ipa.go.jp/ns/core/rdf#
その後、次のURIに変更された。
http://imi.go.jp/ns/core/rdf#
最初のものはIPAドメインのサブドメインとしてIMIが設定されていたが、名前空間URIの不変性を担保するために、IPAドメインとは切り離し、IMI独自ドメインとして設定するのが望ましいということだろう。その意図はよく分かる。
その後、今度は以下のURIに変更された。
https://imi.go.jp/ns/core/rdf#
最近は猫も杓子もSSLで、SSLにあらずんばWEBにあらず、という勢いだ。
IPAは我が国の情報処理を司る大本営。SSL対応とするのは当たり前と言えば当たり前。
大切なのは、結果として３種類できてしまった名前空間URIを、ユーザーに対しどのように周知徹底し、最新のURIにいかに導いていくかだ。
IPAはそこを大事にしなければならないというのに、最新のコア語彙バージョン2.4.1のページで提示されているRDFスキーマやJSON-LDコンテキストを見ると、驚くべきことに、いまだに「s」がついていない。（2018年4月15日現在）
これでは、統計LODサイドが勘違いするのもむべなるかな。はっきり言ってこれはIPAの怠慢だと言わざるを得ない。起こるべくして起きた事故だ。
共通語彙の目的は、みんなが使う語彙の共通化。共通語彙基盤はみんなのハブ空港。
共通化どころか、自らの手で基準を乱立させ、周知徹底もせず、リダイレクトをかけるだけで満足しているようなデリカシーのない共通語彙からは、ユーザーはどんどん離れていくのが目に見えている。
共通語彙基盤を本気で流行らせたいのなら、もっとちゃんとしてください！頼みますよ！！
東京南多摩５市賞に寄せて － 自治体の真の実力比較 － (2018.3.3)
LODチャレンジ2017の他の方の受賞作品を見ようと思い、受賞作品発表のプレスリリースを見ていたら、当アプリが東京南多摩５市賞を受賞していることを知ってビックリ！
多摩５市の特産品まで頂けるとのこと。本当にありがとうございます m(__)m
私は愛知県出身で京都在住。多摩５市には縁もゆかりもなく、今まで生きてきた。 しかし、多摩５市に頂いたこのサプライズの恩返しをしなくては、と思い、急遽『多摩５市ボタン』を追加した。 こういう小回りが利く点が、個人の趣味でやっている良いところかも。
さて、次のグラフをご覧いただきたい。
これは多摩５市の人口総数を比較したグラフだ。 トップの八王子市と最下位の稲城市では、６倍以上の差がある。
「自治体なんでもランキング with 統計LOD」には欠点があり、八王子市と稲城市のように、そもそも自治体の規模が違う場合、その自治体の「真の実力」を比較することができない。
例えば、自治体の将来を担う１５歳未満の子供がどれだけいるか。 総数で見た場合は、次のグラフのように、分母がでかい八王子市が多いに決まっている。
真の実力を測るには、１５歳未満の子供の「割合」が重要だ。 そこで、「人口1000人当たりの値」で表示するボタンも作成した。 そのボタンを用い、１５歳未満の子供のグラフを作成すると、なんと稲城市がトップに躍り出た。稲城市は若年層の割合が高いようだ。
次のグラフは昼間人口の夜間人口に対する比率を示したものだ。
「夜間人口」とは、そこに居住している人口のこと。一方「昼間人口」とは、夜間人口から通勤・通学者を差し引きした人口のことだ。 このグラフを見ると、稲城市は昼間人口が少ない（＝夜間人口が多い）ことから、２３区などのベッドタウンになっており、子育て世帯が多いことが推測できる。子供が多い理由はこのあたりにあるのだろう。
視点を変えて、1000人当たりの市町村税収納済額（≒税収）を見てみよう。
多摩市がダントツで、稲城市、日野市と続くことが分かる。
以上、総数だけでは分からない自治体の実力と、地域分析の手法を少しだけ紹介させていただいた。 なお、このアプリの人口1000人当たりの計算は、すべて2015年の国勢調査人口により割り出したものであるため、各統計の調査年次により、正しい値と乖離する場合があることをご了承いただきたい。
多摩５市のことを全く知らなかった私が、LODチャレンジをきっかけに、５市と繋がりを持つことができ、とても嬉しく思っている。八王子市、町田市、日野市、多摩市、稲城市の関係者の皆様に、感謝の意をお伝え申し上げたい。
多摩５市の特産品まで頂けるとのこと。本当にありがとうございます m(__)m
私は愛知県出身で京都在住。多摩５市には縁もゆかりもなく、今まで生きてきた。 しかし、多摩５市に頂いたこのサプライズの恩返しをしなくては、と思い、急遽『多摩５市ボタン』を追加した。 こういう小回りが利く点が、個人の趣味でやっている良いところかも。
さて、次のグラフをご覧いただきたい。
これは多摩５市の人口総数を比較したグラフだ。 トップの八王子市と最下位の稲城市では、６倍以上の差がある。
「自治体なんでもランキング with 統計LOD」には欠点があり、八王子市と稲城市のように、そもそも自治体の規模が違う場合、その自治体の「真の実力」を比較することができない。
例えば、自治体の将来を担う１５歳未満の子供がどれだけいるか。 総数で見た場合は、次のグラフのように、分母がでかい八王子市が多いに決まっている。
真の実力を測るには、１５歳未満の子供の「割合」が重要だ。 そこで、「人口1000人当たりの値」で表示するボタンも作成した。 そのボタンを用い、１５歳未満の子供のグラフを作成すると、なんと稲城市がトップに躍り出た。稲城市は若年層の割合が高いようだ。
次のグラフは昼間人口の夜間人口に対する比率を示したものだ。
「夜間人口」とは、そこに居住している人口のこと。一方「昼間人口」とは、夜間人口から通勤・通学者を差し引きした人口のことだ。 このグラフを見ると、稲城市は昼間人口が少ない（＝夜間人口が多い）ことから、２３区などのベッドタウンになっており、子育て世帯が多いことが推測できる。子供が多い理由はこのあたりにあるのだろう。
視点を変えて、1000人当たりの市町村税収納済額（≒税収）を見てみよう。
多摩市がダントツで、稲城市、日野市と続くことが分かる。
以上、総数だけでは分からない自治体の実力と、地域分析の手法を少しだけ紹介させていただいた。 なお、このアプリの人口1000人当たりの計算は、すべて2015年の国勢調査人口により割り出したものであるため、各統計の調査年次により、正しい値と乖離する場合があることをご了承いただきたい。
多摩５市のことを全く知らなかった私が、LODチャレンジをきっかけに、５市と繋がりを持つことができ、とても嬉しく思っている。八王子市、町田市、日野市、多摩市、稲城市の関係者の皆様に、感謝の意をお伝え申し上げたい。
統計LODのSPARQLクエリ研究 (2017.12.28)
自治体なんでもランキング with 統計LOD に必要な情報を、一挙に入手するクエリは以下の通り。
統計LOD の SPARQL Endpoint はこちら。クエリをコピペして一度お試しあれ。
なお、アプリ上では、統計指標（述語 g00200502-dimension:indicator に対する 目的語）については、ドロップダウンリストで選択したものをセットするが、ここでは便宜的に「g00200502-code:indicator-A1101」（人口総数）にしている。
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:Prefecture ;
ic:表記 ?pref .
} ORDER BY DESC(?year) DESC(?observation)
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?city ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:DesignatedCity ;
ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY DESC(?year) DESC(?observation)
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?city ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialWard .} UNION
{ ?areacode sacs:administrativeClass sacs:Town .} UNION
{ ?areacode sacs:administrativeClass sacs:Village .}
?areacode ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY DESC(?year) DESC(?observation)
また、統計調査というものの性質上致し方ないことであるが、統計の種類により調査年が異なるのも利活用を難しくする一つの要因だ。最新年の情報のみ欲しい場合でも、一旦、すべての調査年の値を入手し、必要な年の値のみ抽出する必要がある。
最大のネックは、クエリが長くて処理が重すぎること。特に、全市区町村分を取得するクエリは、下手すると何分も待たされ、途中で寝てしまう。サーバに負荷をかけすぎて、他の利用者に迷惑をかけることにもなってしまう。
そこで、考えたのが以下のクエリ。（これは都道府県バージョン）
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
select ?year
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
sdmx-dimension:refArea sac:C01000-19700401 ;
cd-dimension:timePeriod ?year .
} ORDER BY DESC(?year)
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod "（一段目で取得した調査年をセット）"^^xsd:gYear ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:Prefecture ;
ic:表記 ?pref .
} ORDER BY DESC(?observation)
上記のようにすると、二段階になり、一見遅くなるように思うが、全ての調査年を走査する必要がなくなるため、負荷が軽減され、結果として高速化される。しかしながら、これでもまだ重く、特に「全市区町村分」は途中で固まることもあり実用的ではない。
どの部分がボトルネックとなっているか調べた結果、『標準自治体コードをもとに、自治体名（市区町村、都道府県）を取得する部分』がかなり重いことが分かった。データセットを跨ぐと重くなるのだろうか。
（都道府県）
?areacode ic:表記 ?pref .
（市区町村）
?areacode ic:表記 ?city ;
sacs:prefectureLabel ?pref .
上記の問題を解消するため、クエリをもう一段階分割し、三段構成とすることとした。
そのクエリは以下のとおり。（これは全市区町村バージョン）
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?areacode ?pref ?city
where {
?areacode a sacs:StandardAreaCode ;
ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY ?areacode
ホームページを開くと、上記【一段目】のクエリを自動的にエンドポイントへ送信し、全ての自治体の標準自治体コードと、対応する市区町村名、その上位自治体である都道府県名を取得し、クライアントＰＣのメモリにオブジェクトとして格納しておく。
このクエリはやや重いが、取得したオブジェクトは、ページを閉じたり、別のページに遷移するまではメモリに保持されるため、一度の取得で何度も使いまわしが可能だ。
メモリへの格納後、次に「札幌市」の調査年を取得、最後に観測値を取得する。
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
select ?year
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
sdmx-dimension:refArea sac:C01100-19731201 ;
cd-dimension:timePeriod ?year .
} ORDER BY DESC(?year)
PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
select ?areacode ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod "（二段目で取得した調査年をセット）"^^xsd:gYear ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialWard .} UNION
{ ?areacode sacs:administrativeClass sacs:Town .} UNION
{ ?areacode sacs:administrativeClass sacs:Village .}
} ORDER BY DESC(?observation)
上記クエリの結果がコールバックされたら、三段目で取得した「?areacode」と、一段目で取得済みの、メモリに格納してある標準自治体コード等の情報を Javascript でマッチングさせ、ブラウザ上に表示させる。
ブラウザ内でのマッチング作業に少し時間がかかるが、SPARQLサーバー上で行うよりもずっと高速だ。
Fusekiサーバー内でどのような処理が行われているか詳しいことは分からないが、重いクエリ一発で処理を行うより、軽いクエリを複数回組み合わせたほうが、結果として素早く処理が完了できるようだ。統計LODを利用したアプリケーション開発を考えておられる方には、このように細かくクエリを分割する手法をお勧めしたい。
余談だが、今回の統計LODリニューアル後のデータは、共通語彙基盤の語彙が多く使われており、その使いどころも、IPAの解説に近い形に手直しをされた。これは素晴らしい取組だと思う。その一方で、使われている共通語彙の名前空間URIが未だに「旧」であるところがイケてない（こちら参照）。速やかに新URIに修正していただきたいところだ。
統計LOD の SPARQL Endpoint はこちら。クエリをコピペして一度お試しあれ。
なお、アプリ上では、統計指標（述語 g00200502-dimension:indicator に対する 目的語）については、ドロップダウンリストで選択したものをセットするが、ここでは便宜的に「g00200502-code:indicator-A1101」（人口総数）にしている。
【都道府県】
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:Prefecture ;
ic:表記 ?pref .
} ORDER BY DESC(?year) DESC(?observation)
【政令指定都市】
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?city ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:DesignatedCity ;
ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY DESC(?year) DESC(?observation)
【全ての市町村及び東京特別区】
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?city ?year ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod ?year ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialWard .} UNION
{ ?areacode sacs:administrativeClass sacs:Town .} UNION
{ ?areacode sacs:administrativeClass sacs:Village .}
?areacode ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY DESC(?year) DESC(?observation)
全市区町村分を取得するクエリは、複数の自治体種別をUNIONで繋げているのがスマートでないが、これは統計LODの自治体情報のオントロジー構造の問題によるものであり、現状ではこうする他に手がない。次の「おまけコラム」で、その問題点について詳しく述べたので、改善していただけるとありがたい。
また、統計調査というものの性質上致し方ないことであるが、統計の種類により調査年が異なるのも利活用を難しくする一つの要因だ。最新年の情報のみ欲しい場合でも、一旦、すべての調査年の値を入手し、必要な年の値のみ抽出する必要がある。
最大のネックは、クエリが長くて処理が重すぎること。特に、全市区町村分を取得するクエリは、下手すると何分も待たされ、途中で寝てしまう。サーバに負荷をかけすぎて、他の利用者に迷惑をかけることにもなってしまう。
そこで、考えたのが以下のクエリ。（これは都道府県バージョン）
【一段目】都道府県のうち、北海道の調査年を取得
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
select ?year
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
sdmx-dimension:refArea sac:C01000-19700401 ;
cd-dimension:timePeriod ?year .
} ORDER BY DESC(?year)
【二段目】都道府県の名称と統計調査の観測値を取得
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?pref ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod "（一段目で取得した調査年をセット）"^^xsd:gYear ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
?areacode sacs:administrativeClass sacs:Prefecture ;
ic:表記 ?pref .
} ORDER BY DESC(?observation)
上記のようにすると、二段階になり、一見遅くなるように思うが、全ての調査年を走査する必要がなくなるため、負荷が軽減され、結果として高速化される。しかしながら、これでもまだ重く、特に「全市区町村分」は途中で固まることもあり実用的ではない。
どの部分がボトルネックとなっているか調べた結果、『標準自治体コードをもとに、自治体名（市区町村、都道府県）を取得する部分』がかなり重いことが分かった。データセットを跨ぐと重くなるのだろうか。
（都道府県）
?areacode ic:表記 ?pref .
（市区町村）
?areacode ic:表記 ?city ;
sacs:prefectureLabel ?pref .
上記の問題を解消するため、クエリをもう一段階分割し、三段構成とすることとした。
そのクエリは以下のとおり。（これは全市区町村バージョン）
【一段目】全自治体の標準自治体コードと、市区町村名称及び都道府県名称を取得
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>PREFIX ic:<http://imi.go.jp/ns/core/rdf#>
select ?areacode ?pref ?city
where {
?areacode a sacs:StandardAreaCode ;
ic:表記 ?city ;
sacs:prefectureLabel ?pref .
} ORDER BY ?areacode
ホームページを開くと、上記【一段目】のクエリを自動的にエンドポイントへ送信し、全ての自治体の標準自治体コードと、対応する市区町村名、その上位自治体である都道府県名を取得し、クライアントＰＣのメモリにオブジェクトとして格納しておく。
このクエリはやや重いが、取得したオブジェクトは、ページを閉じたり、別のページに遷移するまではメモリに保持されるため、一度の取得で何度も使いまわしが可能だ。
メモリへの格納後、次に「札幌市」の調査年を取得、最後に観測値を取得する。
【二段目】市区町村のうち、札幌市の調査年の取得
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sac:<http://data.e-stat.go.jp/lod/sac/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
select ?year
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
sdmx-dimension:refArea sac:C01100-19731201 ;
cd-dimension:timePeriod ?year .
} ORDER BY DESC(?year)
【三段目】全市区町村の統計調査の観測値を取得
PREFIX g00200502-dimension:<http://data.e-stat.go.jp/lod/ontology/g00200502/dimension/>PREFIX g00200502-code:<http://data.e-stat.go.jp/lod/ontology/g00200502/code/>
PREFIX cd-dimension:<http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
PREFIX sdmx-measure:<http://purl.org/linked-data/sdmx/2009/measure#>
PREFIX sdmx-dimension:<http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
select ?areacode ?observation
where {
?s g00200502-dimension:indicator g00200502-code:indicator-A1101 ;
cd-dimension:timePeriod "（二段目で取得した調査年をセット）"^^xsd:gYear ;
sdmx-measure:obsValue ?observation ;
sdmx-dimension:refArea ?areacode .
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialWard .} UNION
{ ?areacode sacs:administrativeClass sacs:Town .} UNION
{ ?areacode sacs:administrativeClass sacs:Village .}
} ORDER BY DESC(?observation)
上記クエリの結果がコールバックされたら、三段目で取得した「?areacode」と、一段目で取得済みの、メモリに格納してある標準自治体コード等の情報を Javascript でマッチングさせ、ブラウザ上に表示させる。
ブラウザ内でのマッチング作業に少し時間がかかるが、SPARQLサーバー上で行うよりもずっと高速だ。
Fusekiサーバー内でどのような処理が行われているか詳しいことは分からないが、重いクエリ一発で処理を行うより、軽いクエリを複数回組み合わせたほうが、結果として素早く処理が完了できるようだ。統計LODを利用したアプリケーション開発を考えておられる方には、このように細かくクエリを分割する手法をお勧めしたい。
余談だが、今回の統計LODリニューアル後のデータは、共通語彙基盤の語彙が多く使われており、その使いどころも、IPAの解説に近い形に手直しをされた。これは素晴らしい取組だと思う。その一方で、使われている共通語彙の名前空間URIが未だに「旧」であるところがイケてない（こちら参照）。速やかに新URIに修正していただきたいところだ。
統計LODの地方自治体オントロジーについての考察 (2017.12.28)
統計LODにおける地方自治体定義のオントロジーは、下図のような構成になっている。
このWEBアプリの「全市区町村」検索で必要な情報は、背景が黄色の部分だ。
上図の「第三階層」は、市区町村クラスに属するグループであるが、市・東京23区・町・村に加え、「政令指定都市の行政区」も同格に扱うこととされている。
一般的に「市区町村」と言った場合、そこに政令指定都市の行政区を含めるかどうかは議論の分かれるところであるが、行政区は東京特別区とは異なり地方公共団体そのものではないので、クラス分類基準の同一性という観点で捉えると「含めない」のが正解だろう。
また、政令指定都市が属する第四階層より、行政区が属する階層のほうが浅い位置にあるのも違和感を覚える。
第三階層の「市」と、第四階層の「政令指定都市」「中核市」「特例市」との関係も、私の感覚では、不適当と感じられる。
現行の統計LODにおける、「市」のクラスとインスタンスの関係を図に表すと、以下の通りとなる。
普通の市と、政令市・中核市・特例市が異なるクラス階層に属しているのは、オントロジー構成的にみても望ましくない上、実際にSPARQL検索を行う際にも不便だ。
現行では、政令市等を含めたすべての「市」を取得したい場合、以下のように UNION で繋げる必要があり、これではスマートでない。
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
select ?areacode
where {
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .}
}
または
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?areacode
where {
{ ?bigCity rdfs:subClassOf sacs:City .
?areacode sacs:administrativeClass ?bigCity . } UNION
{ ?areacode sacs:administrativeClass sacs:City .}
}
私としては、下図のような構成が望ましいと考える。この構成であれば、インスタンス集合のパーティション性を満たし、かつ、スマートで高速なクエリが使えるため、利便性も高い。
SPARQLサーバーのレスポンスを向上させるには、機器の物理的な増強だけでなく、このようなオントロジーの見直しからもアプローチすべきだろう。
（クエリ）
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?areacode
where {
?allCity rdfs:subClassOf sacs:City .
?areacode sacs:administrativeClass ?allCity .
}
私は、統計LODの地方自治体オントロジーについて、オントロジーとして望ましい状態に修正し、同時にSPARQL検索の利便性も向上させるため、下図《 案１ 》又は《 案２ 》が良いと考えている。統計局及び統計センターの関係者の方、ご検討願います。
粗探しのような要望ばかり述べてしまったが、今回のリニューアルにより、データセットが拡充され、使い勝手もずいぶん良くなったことは間違いなく、私のようなマニアには嬉しい限りだ。
統計LODのさらなる発展と、地方自治体の統計データLOD化の波及を願い、微力ながら私も応援していきたい。
このWEBアプリの「全市区町村」検索で必要な情報は、背景が黄色の部分だ。
上図の「第三階層」は、市区町村クラスに属するグループであるが、市・東京23区・町・村に加え、「政令指定都市の行政区」も同格に扱うこととされている。
一般的に「市区町村」と言った場合、そこに政令指定都市の行政区を含めるかどうかは議論の分かれるところであるが、行政区は東京特別区とは異なり地方公共団体そのものではないので、クラス分類基準の同一性という観点で捉えると「含めない」のが正解だろう。
また、政令指定都市が属する第四階層より、行政区が属する階層のほうが浅い位置にあるのも違和感を覚える。
第三階層の「市」と、第四階層の「政令指定都市」「中核市」「特例市」との関係も、私の感覚では、不適当と感じられる。
現行の統計LODにおける、「市」のクラスとインスタンスの関係を図に表すと、以下の通りとなる。
普通の市と、政令市・中核市・特例市が異なるクラス階層に属しているのは、オントロジー構成的にみても望ましくない上、実際にSPARQL検索を行う際にも不便だ。
現行では、政令市等を含めたすべての「市」を取得したい場合、以下のように UNION で繋げる必要があり、これではスマートでない。
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
select ?areacode
where {
{ ?areacode sacs:administrativeClass sacs:City .} UNION
{ ?areacode sacs:administrativeClass sacs:DesignatedCity .} UNION
{ ?areacode sacs:administrativeClass sacs:CoreCity .} UNION
{ ?areacode sacs:administrativeClass sacs:SpecialCity .}
}
または
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?areacode
where {
{ ?bigCity rdfs:subClassOf sacs:City .
?areacode sacs:administrativeClass ?bigCity . } UNION
{ ?areacode sacs:administrativeClass sacs:City .}
}
私としては、下図のような構成が望ましいと考える。この構成であれば、インスタンス集合のパーティション性を満たし、かつ、スマートで高速なクエリが使えるため、利便性も高い。
SPARQLサーバーのレスポンスを向上させるには、機器の物理的な増強だけでなく、このようなオントロジーの見直しからもアプローチすべきだろう。
（クエリ）
PREFIX sacs:<http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?areacode
where {
?allCity rdfs:subClassOf sacs:City .
?areacode sacs:administrativeClass ?allCity .
}
私は、統計LODの地方自治体オントロジーについて、オントロジーとして望ましい状態に修正し、同時にSPARQL検索の利便性も向上させるため、下図《 案１ 》又は《 案２ 》が良いと考えている。統計局及び統計センターの関係者の方、ご検討願います。
粗探しのような要望ばかり述べてしまったが、今回のリニューアルにより、データセットが拡充され、使い勝手もずいぶん良くなったことは間違いなく、私のようなマニアには嬉しい限りだ。
統計LODのさらなる発展と、地方自治体の統計データLOD化の波及を願い、微力ながら私も応援していきたい。
登録:
投稿 (Atom)