自作のWebアプリ、 ザ・地域統計パワーバトル が、LODチャレンジ2018において、グランプリにあたる最優秀賞をいただきました。また、併せて日立株式会社様より Inspire the LOD賞を頂きました。
さらに、自作のオントロジー、ＯＷＬ ｄｅ ラーメンオントロジー は、オントロノミー合同会社様から オントロジー賞を頂きました。
自作アプリ等の公表の場を与えてくださるだけでも本当にありがたいことで、それに加えて賞までいただけるのは感謝しきれないくらいです。関係者様ありがとうございます。
僕がデータの利活用やプログラミングに取り組み始めたのは３年ほど前で、それ以前はさほど興味を持っていませんでした。
以前は、休日は大好きな魚釣りに行くことが多かったのですが、一日家を空けて魚を釣って楽しんで帰ってくると、家族から白い目で見られることが多く、やむ無く封印することになりました。
冬はスノーボードに行くのを楽しみにしていましたが、行くたびに時間とお金と体力を使い果たしすぎるために、これもやむ無く封印しています。
そこで目を付けたのがオープンデータ利活用です。
１．家にいながらスキマ時間でできるので家族サービスの支障にならない。
２．ＰＣひとつでできるのでお金がかからず、家計にやさしい。
３．社会貢献にもなる。
４．お父さん意外とすごい人だったんだ、って娘に褒められる。
長く続けていけたらなぁ、と思っています。
2018年11月11日日曜日
2018年9月11日火曜日
IMIツール Ver 1.0.0
共通語彙を利活用するためのツールである IMIツール は、先日まで検証版だったが、このたび待望の正式版 Ver 1.0.0 がリリースされた。
さっそく使ってみる。
とりあえず、検証版で作ったDMDを読み込ませる。
む、エラーだ (-_-)
まあ、仕様が変わったのだろう。しようがない…。
オヤジギャグはさておき、気を取り直して、一からDMDを作り直す。
手持ちのエクセル表を読み込ませて、適切なクラス・プロパティをブラウザ上で選んでいく。
応用語彙を、IMI語彙記法を用いて追加する。
この辺りの操作感は検証版と同じだ。
さて、DMDが無事完成し、RDF出力だ。
果たして検証版のダメな点は直っているのだろうか。
１ JSON-LD ⇒ 検証版から据え置き。不具合解消なし。
２ RDF-XML ⇒ 検証版から据え置き。不具合解消なし。
３ Turtle ⇒ 検証版から据え置き。不具合解消なし。
４ 主語の扱い ⇒ 検証版から据え置き。不具合解消なし。
…ぶっちゃけこれでは使い物にならないっす。
技術委員さん、このRDFちゃんとチェックしてます？ほんとにいいのこれで？？
経産省やＩＰＡは、共通語彙基盤を本気で流行らせたい気が無いのだろうか… (-_-)
１千万くれたら僕が最高のツールを作ります。
（ウソです）
さっそく使ってみる。
とりあえず、検証版で作ったDMDを読み込ませる。
む、エラーだ (-_-)
まあ、仕様が変わったのだろう。しようがない…。
オヤジギャグはさておき、気を取り直して、一からDMDを作り直す。
手持ちのエクセル表を読み込ませて、適切なクラス・プロパティをブラウザ上で選んでいく。
応用語彙を、IMI語彙記法を用いて追加する。
この辺りの操作感は検証版と同じだ。
さて、DMDが無事完成し、RDF出力だ。
果たして検証版のダメな点は直っているのだろうか。
１ JSON-LD ⇒ 検証版から据え置き。不具合解消なし。
２ RDF-XML ⇒ 検証版から据え置き。不具合解消なし。
３ Turtle ⇒ 検証版から据え置き。不具合解消なし。
４ 主語の扱い ⇒ 検証版から据え置き。不具合解消なし。
…ぶっちゃけこれでは使い物にならないっす。
技術委員さん、このRDFちゃんとチェックしてます？ほんとにいいのこれで？？
経産省やＩＰＡは、共通語彙基盤を本気で流行らせたい気が無いのだろうか… (-_-)
１千万くれたら僕が最高のツールを作ります。
（ウソです）
2018年8月11日土曜日
統計LODのSPARQLクエリ解説（小地域編）
このたび、Webアプリ 「ザ・地域統計パワーバトル」 を公開した。
このアプリは「シビックパワーバトル」に着想を得て開発したものだ。
バトル自体は興味を引くためのジョークだが、地域と地域を比較したり、また日本（全国値）と比較することで、自分の住んでいる地域の特徴を知り、どのような問題点を持つか把握することが可能となる。地域分析ツールという観点で遊んでいただけたら幸いだ。
さて、このアプリは、e-StatのWeb APIからデータを取得し表示させている。
都道府県と市区町村のデータは REST API から、町丁・字の「小地域」のデータは、統計LOD のSPARQL APIから取得している。
都道府県と市区町村のデータは、SPARQL APIからも取得することが可能だが、実行速度のより高速なREST APIを利用している。
小地域データは現在、SPARQL APIからのみの提供だ。
本稿では、統計LODの小地域データを扱うためのSPARQLクエリを紹介する。クエリをコピペして、統計LODのエンドポイントでお試しあれ。
１ 平成27年国勢調査の対象自治体の一覧
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX sacs: <http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic: <http://imi.go.jp/ns/core/rdf#>
select distinct ?code ?pref ?area
where {
?s sdmx-dimension:refArea ?code ;
qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200521/d0003148521>.
?code sacs:prefectureLabel ?pref ;
ic:表記 ?area ;
}order by ?code
このクエリで、平成27年国勢調査の対象自治体の「期間付き標準地域コード」を取得することができる。（重いので乱発しないこと！）
２ 京都市左京区に含まれる小地域の一覧
PREFIX smallArea: <http://data.e-stat.go.jp/lod/terms/smallArea/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX sac: <http://data.e-stat.go.jp/lod/sac/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select *
where {
?s a smallArea:SmallAreaCode ;
dcterms:isPartOf sac:C26103-19700401 ;
rdfs:label ?name .
} order by ?s
上記の sac:C26103-19700401 は平成27年国勢調査時点の、京都市左京区の期間付き標準地域コードである。この部分を変えることで他の市区町村の情報を得ることができる。
３ 京都市左京区聖護院山王町の情報
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
select *
where {
sa-g00200521-2015:S26103018006 ?p ?o .
}
４ 京都市左京区聖護院山王町のポリゴン
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
select ?polygon
where {
sa-g00200521-2015:S26103018006 geo:hasGeometry [ geo:asWKT ?polygon ] .
}
小地域のポリゴンを取得することもできる。当アプリではこのクエリは使っていないが、オープンストリートマップなどで領域を表示させるのも面白いと思う。
５ 京都市左京区聖護院山王町の年齢別・男女別人口
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
select ?age ?sex ?population
where {
?s sdmx-dimension:refArea sa-g00200521-2015:S26103018006 ;
qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200521/ds012015003>;
cd-dimension:age ?age;
cd-dimension:sex ?sex;
estat-measure:population ?population.
}order by ?sex ?age
このクエリで、いわゆる「人口ピラミッド」に必要な情報を得ることができる。
６ 京都市左京区聖護院山王町の年齢別・男女別人口、外国人人口、世帯数、配偶関係、労働力状態
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
PREFIX g00200521-dimension-2015: <http://data.e-stat.go.jp/lod/ontology/g00200521/dimension/2015/>
PREFIX g00200521-dimension-2010: <http://data.e-stat.go.jp/lod/ontology/g00200521/dimension/2010/>
select ?dataset ?sex ?age ?maritalStatus ?labourForce ?population ?households ?avrage
where {
?s sdmx-dimension:refArea sa-g00200521-2015:S26103018006 ;
qb:dataSet ?dataset .
OPTIONAL{
?s cd-dimension:age ?age;
cd-dimension:sex ?sex;
estat-measure:population ?population.
}
OPTIONAL{
?s estat-measure:households ?households .
}
OPTIONAL{
?s cd-dimension:sex ?sex;
estat-measure:population ?population.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
estat-measure:age ?avrage.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
g00200521-dimension-2015:maritalStatus ?maritalStatus;
estat-measure:population ?population.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
g00200521-dimension-2010:labourForce ?labourForce;
estat-measure:population ?population.
}
}order by ?dataset ?sex ?age ?maritalStatus ?labourForce
「ザ・地域統計パワーバトル」では、実際にこのクエリを使ってデータを取得している。
OPTIONAL句で各種データを並列させているところがポイント。
短いクエリを連発するのが良いのか、このような重いクエリにするのが良いのか悩んだが、プログラムが複雑化するのを避けるために、今回は重いクエリ一発で、情報を一気に取得する方法を採用した。
統計LODの実行速度が倍くらいになってくれたらなぁ…。
統計局さん、統計センターさん、日立さん、よろしくお願いします。
おかげさまで快適になりました。
関係者のみなさま、ありがとうございます！！！
このアプリは「シビックパワーバトル」に着想を得て開発したものだ。
バトル自体は興味を引くためのジョークだが、地域と地域を比較したり、また日本（全国値）と比較することで、自分の住んでいる地域の特徴を知り、どのような問題点を持つか把握することが可能となる。地域分析ツールという観点で遊んでいただけたら幸いだ。
さて、このアプリは、e-StatのWeb APIからデータを取得し表示させている。
都道府県と市区町村のデータは REST API から、町丁・字の「小地域」のデータは、統計LOD のSPARQL APIから取得している。
都道府県と市区町村のデータは、SPARQL APIからも取得することが可能だが、実行速度のより高速なREST APIを利用している。
小地域データは現在、SPARQL APIからのみの提供だ。
本稿では、統計LODの小地域データを扱うためのSPARQLクエリを紹介する。クエリをコピペして、統計LODのエンドポイントでお試しあれ。
１ 平成27年国勢調査の対象自治体の一覧
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX sacs: <http://data.e-stat.go.jp/lod/terms/sacs#>
PREFIX ic: <http://imi.go.jp/ns/core/rdf#>
select distinct ?code ?pref ?area
where {
?s sdmx-dimension:refArea ?code ;
qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200521/d0003148521>.
?code sacs:prefectureLabel ?pref ;
ic:表記 ?area ;
}order by ?code
このクエリで、平成27年国勢調査の対象自治体の「期間付き標準地域コード」を取得することができる。（重いので乱発しないこと！）
２ 京都市左京区に含まれる小地域の一覧
PREFIX smallArea: <http://data.e-stat.go.jp/lod/terms/smallArea/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX sac: <http://data.e-stat.go.jp/lod/sac/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select *
where {
?s a smallArea:SmallAreaCode ;
dcterms:isPartOf sac:C26103-19700401 ;
rdfs:label ?name .
} order by ?s
上記の sac:C26103-19700401 は平成27年国勢調査時点の、京都市左京区の期間付き標準地域コードである。この部分を変えることで他の市区町村の情報を得ることができる。
３ 京都市左京区聖護院山王町の情報
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
select *
where {
sa-g00200521-2015:S26103018006 ?p ?o .
}
４ 京都市左京区聖護院山王町のポリゴン
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
select ?polygon
where {
sa-g00200521-2015:S26103018006 geo:hasGeometry [ geo:asWKT ?polygon ] .
}
小地域のポリゴンを取得することもできる。当アプリではこのクエリは使っていないが、オープンストリートマップなどで領域を表示させるのも面白いと思う。
５ 京都市左京区聖護院山王町の年齢別・男女別人口
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
select ?age ?sex ?population
where {
?s sdmx-dimension:refArea sa-g00200521-2015:S26103018006 ;
qb:dataSet <http://data.e-stat.go.jp/lod/dataset/g00200521/ds012015003>;
cd-dimension:age ?age;
cd-dimension:sex ?sex;
estat-measure:population ?population.
}order by ?sex ?age
このクエリで、いわゆる「人口ピラミッド」に必要な情報を得ることができる。
６ 京都市左京区聖護院山王町の年齢別・男女別人口、外国人人口、世帯数、配偶関係、労働力状態
PREFIX sdmx-dimension: <http://purl.org/linked-data/sdmx/2009/dimension#>
PREFIX sa-g00200521-2015: <http://data.e-stat.go.jp/lod/smallArea/g00200521/2015/>
PREFIX qb: <http://purl.org/linked-data/cube#>
PREFIX cd-dimension: <http://data.e-stat.go.jp/lod/ontology/crossDomain/dimension/>
PREFIX estat-measure: <http://data.e-stat.go.jp/lod/ontology/measure/>
PREFIX g00200521-dimension-2015: <http://data.e-stat.go.jp/lod/ontology/g00200521/dimension/2015/>
PREFIX g00200521-dimension-2010: <http://data.e-stat.go.jp/lod/ontology/g00200521/dimension/2010/>
select ?dataset ?sex ?age ?maritalStatus ?labourForce ?population ?households ?avrage
where {
?s sdmx-dimension:refArea sa-g00200521-2015:S26103018006 ;
qb:dataSet ?dataset .
OPTIONAL{
?s cd-dimension:age ?age;
cd-dimension:sex ?sex;
estat-measure:population ?population.
}
OPTIONAL{
?s estat-measure:households ?households .
}
OPTIONAL{
?s cd-dimension:sex ?sex;
estat-measure:population ?population.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
estat-measure:age ?avrage.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
g00200521-dimension-2015:maritalStatus ?maritalStatus;
estat-measure:population ?population.
}
OPTIONAL{
?s cd-dimension:sex ?sex;
g00200521-dimension-2010:labourForce ?labourForce;
estat-measure:population ?population.
}
}order by ?dataset ?sex ?age ?maritalStatus ?labourForce
「ザ・地域統計パワーバトル」では、実際にこのクエリを使ってデータを取得している。
OPTIONAL句で各種データを並列させているところがポイント。
短いクエリを連発するのが良いのか、このような重いクエリにするのが良いのか悩んだが、プログラムが複雑化するのを避けるために、今回は重いクエリ一発で、情報を一気に取得する方法を採用した。
おかげさまで快適になりました。
関係者のみなさま、ありがとうございます！！！
2018年6月25日月曜日
（各論）IMIツールの「データ形式変換」機能について
作成したDMDを、元データ（エクセル表など）と一緒に、IMIツール「データ形式変換」に読み込ませると、簡単に共通語彙対応データ（JSON-LD、RDF/XML、Turtle）が出力できる。
ここでは、データ形式変換 から出力された各データについて、私見を紹介する。
１ JSON-LD形式 ⇒ (^^)
（例）共通語彙基盤「妖精」（JSON-LD形式）
データの階層構造もきれいに収まっており、視認性もよくGOOD！
一点疑問に思うのは、URIを示す表現が以下のようになっていること。
"ic:参照先": {
"@value": "http://example.com/xxx/aaa.html",
"@type": "xsd:anyURI"
}
JSON-LDでは、次のように、目的語がURIの場合は @id を使うのが一般的な記法だと思う。
"ic:参照先": {
"@id": "http://example.com/xxx/aaa.html"
}
２ RDF/XML形式 ⇒ (-_-)
（例）共通語彙基盤「妖精」（RDF/XML形式）
JSON-LD同様、データの階層構造はきれいに収まっているが、出力されるテキストに、改行コードやインデントスペースが全く入っていないのがつらすぎる。
ブラウザに読み込ませたら構造が分かるが、そのままの状態ではテキストエディターでの編集は困難。
また、JSON-LD同様、URIを示す表現に疑問符。
<ic:画像 rdf:datatype="xsd:anyURI">http://example.com/xxx.jpg</ic:画像>
rdf:resource を使って以下のように記述するのが一般的。
<ic:画像 rdf:resource="http://example.com/xxx.jpg"/>
３ Turtle形式 ⇒ (-"-)
（例）共通語彙基盤「妖精」（Turtle形式）
ブランクノード表現が多用されており読みにくい。
形式的には一応Turtleの要件を満たしているが、これではN-Triplesとほとんど一緒。
Turtleの優れているところは人間が読みやすい点。これではダメだ。
また、冒頭で名前空間接頭辞の宣言をしているにも関わらず、データ内で接頭辞を使っていないところもダメダメな感じ。
あと、上述の２形式と同様、URIの扱いに疑問符。
"http://example.com/xxx/aaa.html"^^xsd:anyURI
スタンダードなのはこちら。
<http://example.com/xxx/aaa.html>
ちなみに私はRDFタートルズの一員である。
個人的な思いとしても、もっとTurtle生成プログラムを作りこんでいただきたいところだ。最低でもこのくらいにはしてほしいなぁ。
４ 主語の扱い
すべての出力データに関して、共通の問題点は 主語（subject） がないところ。
RDFはご存じのとおり主語・述語・目的語のトリプル構造となっており、文法的には、主語には URI 又は ブランクノード を使うこととされている。
「中間ノード」の主語に対し、ブランクノードを利用するのは何ら問題ない。
一方で、ある事物を示す「おおもとの主語」に対しては、ブランクノードではなくURIを付与するのが普通だ。
しかしながら、IMIツールから出力されるRDFは、おおもとの主語もブランクノードになってしまっている。
おおもとの主語にURIが設定されていないと、RDFとしては扱いづらく、トリプルストアに入れ込んだときも扱いが困難となる。
私は、何とかして主語を設定しようと、IMIツールの設定項目をいろいろ試したり、IMI語彙記法でいろいろと書き込んでみたが、上手くいかなかった。
（他に方法があるのかもしれないが…）
IPAさんにお願いしたいのは、IMIツールのGUI上に、主語の名前空間URIの設定項目を作り、そこに入力したURIに、データ内のいずれかの列のデータをくっつけたものを、主語URIとして出力できるようにすること。
５ まとめ
目につく不具合はいくつかあるものの、一旦DMDを作ってしまえば、様々な形式のRDFが簡単に出力できるのは非常に便利。
上記で挙げた不具合をすべて解消し、(^^♪ になった 正式版IMIツール の早期リリースを望みます。よろしくお願いします m(__)m
ここでは、データ形式変換 から出力された各データについて、私見を紹介する。
１ JSON-LD形式 ⇒ (^^)
（例）共通語彙基盤「妖精」（JSON-LD形式）
データの階層構造もきれいに収まっており、視認性もよくGOOD！
一点疑問に思うのは、URIを示す表現が以下のようになっていること。
"ic:参照先": {
"@value": "http://example.com/xxx/aaa.html",
"@type": "xsd:anyURI"
}
JSON-LDでは、次のように、目的語がURIの場合は @id を使うのが一般的な記法だと思う。
"ic:参照先": {
"@id": "http://example.com/xxx/aaa.html"
}
２ RDF/XML形式 ⇒ (-_-)
（例）共通語彙基盤「妖精」（RDF/XML形式）
JSON-LD同様、データの階層構造はきれいに収まっているが、出力されるテキストに、改行コードやインデントスペースが全く入っていないのがつらすぎる。
ブラウザに読み込ませたら構造が分かるが、そのままの状態ではテキストエディターでの編集は困難。
また、JSON-LD同様、URIを示す表現に疑問符。
<ic:画像 rdf:datatype="xsd:anyURI">http://example.com/xxx.jpg</ic:画像>
rdf:resource を使って以下のように記述するのが一般的。
<ic:画像 rdf:resource="http://example.com/xxx.jpg"/>
３ Turtle形式 ⇒ (-"-)
（例）共通語彙基盤「妖精」（Turtle形式）
ブランクノード表現が多用されており読みにくい。
形式的には一応Turtleの要件を満たしているが、これではN-Triplesとほとんど一緒。
Turtleの優れているところは人間が読みやすい点。これではダメだ。
また、冒頭で名前空間接頭辞の宣言をしているにも関わらず、データ内で接頭辞を使っていないところもダメダメな感じ。
あと、上述の２形式と同様、URIの扱いに疑問符。
"http://example.com/xxx/aaa.html"^^xsd:anyURI
スタンダードなのはこちら。
<http://example.com/xxx/aaa.html>
ちなみに私はRDFタートルズの一員である。
個人的な思いとしても、もっとTurtle生成プログラムを作りこんでいただきたいところだ。最低でもこのくらいにはしてほしいなぁ。
４ 主語の扱い
すべての出力データに関して、共通の問題点は 主語（subject） がないところ。
RDFはご存じのとおり主語・述語・目的語のトリプル構造となっており、文法的には、主語には URI 又は ブランクノード を使うこととされている。
「中間ノード」の主語に対し、ブランクノードを利用するのは何ら問題ない。
一方で、ある事物を示す「おおもとの主語」に対しては、ブランクノードではなくURIを付与するのが普通だ。
しかしながら、IMIツールから出力されるRDFは、おおもとの主語もブランクノードになってしまっている。
おおもとの主語にURIが設定されていないと、RDFとしては扱いづらく、トリプルストアに入れ込んだときも扱いが困難となる。
私は、何とかして主語を設定しようと、IMIツールの設定項目をいろいろ試したり、IMI語彙記法でいろいろと書き込んでみたが、上手くいかなかった。
（他に方法があるのかもしれないが…）
IPAさんにお願いしたいのは、IMIツールのGUI上に、主語の名前空間URIの設定項目を作り、そこに入力したURIに、データ内のいずれかの列のデータをくっつけたものを、主語URIとして出力できるようにすること。
５ まとめ
目につく不具合はいくつかあるものの、一旦DMDを作ってしまえば、様々な形式のRDFが簡単に出力できるのは非常に便利。
上記で挙げた不具合をすべて解消し、(^^♪ になった 正式版IMIツール の早期リリースを望みます。よろしくお願いします m(__)m
（各論）IMIツールの「DMD作成支援」機能について
共通語彙対応データを作るには、まず DMD（Data Model Description ／ データモデル記述）を作る必要がある。
DMDは、特定のデータを共通語彙対応にするための「設計図」のようなもの。
一旦DMDを作ってしまえば、元データ（エクセル表など）と一緒に、IMIツール に読み込ませるだけで、簡単に共通語彙対応のRDFデータ（JSON-LD、RDF/XML、Turtle）ができる、という仕組みだ。
良い点は、IMIツールを使えば、ほぼマウス操作のみで割と簡単にDMDが作れるところ。
また、一旦DMDを作ってしまえば、何度でも使い回しができ、そのDMDを配布すれば誰でも同じように使えるところ。優れたDMDを作れば、それが全国津々浦々に広まる可能性を秘めている。
悪い点は、構造化項目明記法により、データ構造が非常に複雑になるため、IMIツール以外の方法（手作業など）で作るのが現実的でないところ。
さて、ここで、IMIツールの DMD作成支援 を実際にに使ってみて感じた点を、以下に紹介させていただく。
良いと感じたところは、GUIがなかなか良くできていて、クラス（型）やプロパティの設定を、マウス操作のみで直観的に行うことができるところだ。
一方、難しいと思った点は 応用語彙 の追加だ。
「徳川将軍一覧」のデータを例にあげると、将軍は「人」なので、ルートとなるクラスは ic:人型 にする、と、誰しも考えるところだろう。
そして、コア語彙だけでは表現できない、徳川将軍固有の項目については、応用語彙として追加したい、と考える。
そこで私は、ルートである ic:人型クラスに、応用語彙のプロパティを追加しようと頑張ったのだが、どうしてもできない。
しばらく悩んで理解したのは、コア語彙クラスには、そのクラスが持つコア語彙プロパティしかセットできない、ということ。
言い換えると、応用語彙のプロパティを追加したい場合は、ic:人型クラスを継承した独自定義のクラスを作って、そいつをルートクラスとしなければならない、ということだ。
理解すれば簡単なことだが、理解するまでかなり悩んだので、もうちょっと分かりやすくしてほしい点の一つとして挙げておく。
新しいクラスを作ったり、応用語彙を追加するには、IMI語彙記法 を用いて、その内容を記述する必要がある。その記載例は次の通り。
# 人型クラスを継承した「将軍型クラス」を新規作成する
class ex:将軍型 {@ic:人型};
# 「官位」を示すプロパティを作る
property ex:官位 {@xsd:string} ;
# 将軍型クラスのプロパティとして「官位」を設定する。
set ex:将軍型 > ex:官位;
それほど難しくはないのだが、IMIの固有の記法であるため、やはりある程度の勉強や試行錯誤が必要となる。
これもGUIでできるようになるのが理想的だが、どうしてもできなければ、記載例をもっと豊富に提示していただきたいところだ。
「DMD作成支援」では、応用語彙の追加が最も難しい。
さらに使いやすくなるよう、正式版リリース時にはぜひ改善していただきたい。
DMDは、特定のデータを共通語彙対応にするための「設計図」のようなもの。
一旦DMDを作ってしまえば、元データ（エクセル表など）と一緒に、IMIツール に読み込ませるだけで、簡単に共通語彙対応のRDFデータ（JSON-LD、RDF/XML、Turtle）ができる、という仕組みだ。
良い点は、IMIツールを使えば、ほぼマウス操作のみで割と簡単にDMDが作れるところ。
また、一旦DMDを作ってしまえば、何度でも使い回しができ、そのDMDを配布すれば誰でも同じように使えるところ。優れたDMDを作れば、それが全国津々浦々に広まる可能性を秘めている。
悪い点は、構造化項目明記法により、データ構造が非常に複雑になるため、IMIツール以外の方法（手作業など）で作るのが現実的でないところ。
さて、ここで、IMIツールの DMD作成支援 を実際にに使ってみて感じた点を、以下に紹介させていただく。
良いと感じたところは、GUIがなかなか良くできていて、クラス（型）やプロパティの設定を、マウス操作のみで直観的に行うことができるところだ。
一方、難しいと思った点は 応用語彙 の追加だ。
「徳川将軍一覧」のデータを例にあげると、将軍は「人」なので、ルートとなるクラスは ic:人型 にする、と、誰しも考えるところだろう。
そして、コア語彙だけでは表現できない、徳川将軍固有の項目については、応用語彙として追加したい、と考える。
そこで私は、ルートである ic:人型クラスに、応用語彙のプロパティを追加しようと頑張ったのだが、どうしてもできない。
しばらく悩んで理解したのは、コア語彙クラスには、そのクラスが持つコア語彙プロパティしかセットできない、ということ。
言い換えると、応用語彙のプロパティを追加したい場合は、ic:人型クラスを継承した独自定義のクラスを作って、そいつをルートクラスとしなければならない、ということだ。
理解すれば簡単なことだが、理解するまでかなり悩んだので、もうちょっと分かりやすくしてほしい点の一つとして挙げておく。
新しいクラスを作ったり、応用語彙を追加するには、IMI語彙記法 を用いて、その内容を記述する必要がある。その記載例は次の通り。
# 人型クラスを継承した「将軍型クラス」を新規作成する
class ex:将軍型 {@ic:人型};
# 「官位」を示すプロパティを作る
property ex:官位 {@xsd:string} ;
# 将軍型クラスのプロパティとして「官位」を設定する。
set ex:将軍型 > ex:官位;
それほど難しくはないのだが、IMIの固有の記法であるため、やはりある程度の勉強や試行錯誤が必要となる。
これもGUIでできるようになるのが理想的だが、どうしてもできなければ、記載例をもっと豊富に提示していただきたいところだ。
「DMD作成支援」では、応用語彙の追加が最も難しい。
さらに使いやすくなるよう、正式版リリース時にはぜひ改善していただきたい。
2018年6月24日日曜日
（総論）共通語彙基盤の活用に関する考察
共通語彙基盤の活用を検討する際、誰しもまず悩むのは、「手持ちの表形式のデータを、どのように共通語彙基盤対応とするか」、という点に尽きるのではないだろうか。
例えば、次のような表形式のデータがあるとする。
上記の表データを、汎用性を考慮せず、単純にＲＤＦに変換すると次のようになる。（Turtle形式）
@prefix shogun: <http://example.org/shogun_schema#> .
:001 shogun:名前 "徳川 家康" ;
shogun:年齢 75 .
:002 shogun:名前 "徳川 秀忠" ;
shogun:年齢 54 .
:003 shogun:名前 "徳川 家光" ;
shogun:年齢 48 .
上記で使っている shogun:名前 や shogun:年齢 は、私が適当に定義した語彙であり、こういった語彙は「独自定義語彙」などと呼ばれている。
独自定義語彙は、政府組織や権威のある学術機関がきっちり定義したものであれば再利用性が生じるが、そうでなければ、作成者限りの「狭い語彙」とみなされる。
上記のような、すべてが「狭い語彙」のＲＤＦの価値は無に等しく、元データのエクセル表のほうがよっぽど汎用的で分かりやすい。
次に、世界標準の語彙を使って書き直したＲＤＦを示す。
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:001 foaf:name "徳川 家康" ;
foaf:age 75 .
:002 foaf:name "徳川 秀忠" ;
foaf:age 54 .
:003 foaf:name "徳川 家光" ;
foaf:age 48 .
上記であれば、誰もが納得の「開かれた」ＲＤＦであることが一目瞭然だ。
しかしながら、作成者のセンスによっては、次のように書かれることもあろう。
@prefix schema: <http://schema.org/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:001 schema:familyName "徳川" ;
schema:givenName "家康" ;
foaf:age 75 .
:002 schema:familyName "徳川" ;
schema:givenName "秀忠" ;
foaf:age 54 .
:003 schema:familyName "徳川" ;
schema:givenName "家光" ;
foaf:age 48 .
これはこれで、世界標準のＲＤＦとしてきちんと成立している。
じゃあ、どっちが正しいの、と聞かれると、どっちも正しい、としか言いようがない。
（日本語）これはラーメンです。
（英語） This is a ramen.
（フランス語） C'est un ramen.
（日本語・大阪弁）これはラーメンやねん。
（日本語・博多弁）これはラーメンばい。
上記がどれも正しいのと一緒。使っている言語や方言が違うだけだ。
これらを踏まえた上で、さて、共通語彙基盤はどこを目指しているのか。
我々ユーザーは、どう理解し、どう活用したらいいのか。
ＩＭＩのホームページには次の記載がある。
『国・地方公共団体等が公開するデータの標準化を通じて、データの作成、流通、交換を容易にし促進するための基盤で、データに「価値」を生み出すことを目指しています。』
ここ数年で、国や自治体のオープンデータ事業はかなり進み、官が保有している膨大なデータが、二次利用可能な形で、徐々に公開されるようになってきた。
その一方で、その提供されるデータ群は、省庁や自治体ごとに形式がバラバラで、使い勝手が良いとは言い難い。
これらのまとまりのないデータを標準化し、ユーザーが使いやすいものにするためのアプローチの一つが「政府推奨データセット」であり、もう一つがこの共通語彙基盤だ。
徳川将軍のデータに戻って、その二つの役割分担を考えてみる。
【政府推奨データセット】
⇒ 徳川将軍データセットに必要な項目は「名前」及び「年齢」であると決める。
【共通語彙基盤】
⇒ 徳川将軍データセットにおける「名前」及び「年齢」という各項目が、具体的に何を示しているかを明確にする。
もう少し具体的にいうと、共通語彙基盤を用いて、例えば「ものごとの名前」を表現するときは、その対象の性質により表現方法が変わる。
（人の名前の場合） 人型>氏名型>ic:氏名>ic:姓名 ⇒ 徳川家康
（組織の名称の場合） 組織型>名称型>ic:表記 ⇒ 加賀藩
（イベントの名称の場合）イベント型>名称型>ic:表記 ⇒ 大政奉還
このような形で、対象項目が何を示しているかをきっちり指し示し、曖昧さを排除した表現とするのが、共通語彙基盤の役割であろう。
【共通語彙基盤の適用例】
@prefix ic: <http://imi.go.jp/ns/core/rdf#> .
:001 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 家康"^^xsd:string ] ;
ic:年齢 [ ic:数値 "75"^^xsd:integer ] .
:002 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 秀忠"^^xsd:string ] ;
ic:年齢 [ ic:数値 "54"^^xsd:integer ] .
:003 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 家光"^^xsd:string ] ;
ic:年齢 [ ic:数値 "48"^^xsd:integer ] .
曖昧さや多様性といったものは必ずしも悪いものではなく、それがあるからこそ発展があり、新しい知見が生み出されていく。
しかし、曖昧さや多様性が障害となる分野もある。コンピューターのプログラムや、法律などがそれにあたる。
もし刑法に「悪いやつには、罰を与える」と書いてあったら、何をしたらどんな罰を受けるのか全く分からないし、戦前の治安維持法のような運用も可能となる。
そのような曖昧さを回避し、「ものを盗んだ人には、懲役３年の刑罰を与える」と具体的に示すのが、共通語彙基盤の本質的な意義だろう。
法の執行者であり、公共性や中立性が求められる公務の分野においては、共通語彙基盤の思想は比較的馴染みやすい。公的機関が共通語彙基盤を利用する土壌は少しずつ整ってきており、次は実践が必要な段階だ。
そのためには、ＩＰＡは、共通語彙基盤の技術情報や活用ツールの充実だけでなく、背景にある思想の周知や、利用者のメリットの広報に、これまで以上にリソースを割くべきだろう。
共通語彙基盤の魅力を存分に語ることができる「ＩＭＩ伝道師」を育成して、日本各地を巡ってもらうのもいいかもしれないなぁ。
例えば、次のような表形式のデータがあるとする。
| 名前 | 年齢(享年) |
|---|---|
| 徳川 家康 |
７５
|
| 徳川 秀忠 |
５４
|
| 徳川 家光 |
４８
|
上記の表データを、汎用性を考慮せず、単純にＲＤＦに変換すると次のようになる。（Turtle形式）
@prefix shogun: <http://example.org/shogun_schema#> .
:001 shogun:名前 "徳川 家康" ;
shogun:年齢 75 .
:002 shogun:名前 "徳川 秀忠" ;
shogun:年齢 54 .
:003 shogun:名前 "徳川 家光" ;
shogun:年齢 48 .
上記で使っている shogun:名前 や shogun:年齢 は、私が適当に定義した語彙であり、こういった語彙は「独自定義語彙」などと呼ばれている。
独自定義語彙は、政府組織や権威のある学術機関がきっちり定義したものであれば再利用性が生じるが、そうでなければ、作成者限りの「狭い語彙」とみなされる。
上記のような、すべてが「狭い語彙」のＲＤＦの価値は無に等しく、元データのエクセル表のほうがよっぽど汎用的で分かりやすい。
次に、世界標準の語彙を使って書き直したＲＤＦを示す。
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:001 foaf:name "徳川 家康" ;
foaf:age 75 .
:002 foaf:name "徳川 秀忠" ;
foaf:age 54 .
:003 foaf:name "徳川 家光" ;
foaf:age 48 .
上記であれば、誰もが納得の「開かれた」ＲＤＦであることが一目瞭然だ。
しかしながら、作成者のセンスによっては、次のように書かれることもあろう。
@prefix schema: <http://schema.org/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
:001 schema:familyName "徳川" ;
schema:givenName "家康" ;
foaf:age 75 .
:002 schema:familyName "徳川" ;
schema:givenName "秀忠" ;
foaf:age 54 .
:003 schema:familyName "徳川" ;
schema:givenName "家光" ;
foaf:age 48 .
これはこれで、世界標準のＲＤＦとしてきちんと成立している。
じゃあ、どっちが正しいの、と聞かれると、どっちも正しい、としか言いようがない。
（日本語）これはラーメンです。
（英語） This is a ramen.
（フランス語） C'est un ramen.
（日本語・大阪弁）これはラーメンやねん。
（日本語・博多弁）これはラーメンばい。
上記がどれも正しいのと一緒。使っている言語や方言が違うだけだ。
これらを踏まえた上で、さて、共通語彙基盤はどこを目指しているのか。
我々ユーザーは、どう理解し、どう活用したらいいのか。
ＩＭＩのホームページには次の記載がある。
『国・地方公共団体等が公開するデータの標準化を通じて、データの作成、流通、交換を容易にし促進するための基盤で、データに「価値」を生み出すことを目指しています。』
ここ数年で、国や自治体のオープンデータ事業はかなり進み、官が保有している膨大なデータが、二次利用可能な形で、徐々に公開されるようになってきた。
その一方で、その提供されるデータ群は、省庁や自治体ごとに形式がバラバラで、使い勝手が良いとは言い難い。
これらのまとまりのないデータを標準化し、ユーザーが使いやすいものにするためのアプローチの一つが「政府推奨データセット」であり、もう一つがこの共通語彙基盤だ。
徳川将軍のデータに戻って、その二つの役割分担を考えてみる。
【政府推奨データセット】
⇒ 徳川将軍データセットに必要な項目は「名前」及び「年齢」であると決める。
【共通語彙基盤】
⇒ 徳川将軍データセットにおける「名前」及び「年齢」という各項目が、具体的に何を示しているかを明確にする。
もう少し具体的にいうと、共通語彙基盤を用いて、例えば「ものごとの名前」を表現するときは、その対象の性質により表現方法が変わる。
（人の名前の場合） 人型>氏名型>ic:氏名>ic:姓名 ⇒ 徳川家康
（組織の名称の場合） 組織型>名称型>ic:表記 ⇒ 加賀藩
（イベントの名称の場合）イベント型>名称型>ic:表記 ⇒ 大政奉還
このような形で、対象項目が何を示しているかをきっちり指し示し、曖昧さを排除した表現とするのが、共通語彙基盤の役割であろう。
【共通語彙基盤の適用例】
@prefix ic: <http://imi.go.jp/ns/core/rdf#> .
:001 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 家康"^^xsd:string ] ;
ic:年齢 [ ic:数値 "75"^^xsd:integer ] .
:002 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 秀忠"^^xsd:string ] ;
ic:年齢 [ ic:数値 "54"^^xsd:integer ] .
:003 a ic:人型 ;
ic:氏名 [ ic:姓名 "徳川 家光"^^xsd:string ] ;
ic:年齢 [ ic:数値 "48"^^xsd:integer ] .
曖昧さや多様性といったものは必ずしも悪いものではなく、それがあるからこそ発展があり、新しい知見が生み出されていく。
しかし、曖昧さや多様性が障害となる分野もある。コンピューターのプログラムや、法律などがそれにあたる。
もし刑法に「悪いやつには、罰を与える」と書いてあったら、何をしたらどんな罰を受けるのか全く分からないし、戦前の治安維持法のような運用も可能となる。
そのような曖昧さを回避し、「ものを盗んだ人には、懲役３年の刑罰を与える」と具体的に示すのが、共通語彙基盤の本質的な意義だろう。
法の執行者であり、公共性や中立性が求められる公務の分野においては、共通語彙基盤の思想は比較的馴染みやすい。公的機関が共通語彙基盤を利用する土壌は少しずつ整ってきており、次は実践が必要な段階だ。
そのためには、ＩＰＡは、共通語彙基盤の技術情報や活用ツールの充実だけでなく、背景にある思想の周知や、利用者のメリットの広報に、これまで以上にリソースを割くべきだろう。
共通語彙基盤の魅力を存分に語ることができる「ＩＭＩ伝道師」を育成して、日本各地を巡ってもらうのもいいかもしれないなぁ。
2018年6月3日日曜日
ＩＭＩ意見交換会
６月１日、ＩＰＡのＩＭＩ意見交換会で講演させていただいた。
何をしゃべろうか悩んだが、やはり共通語彙基盤ネタがウケるだろうと考え、共通語彙基盤と Linked Open Data という超壮大なテーマを、超コンパクトにまとめてしゃべってきた。
しゃべったのは、「共通語彙基盤って、ぶっちゃけ難しすぎるよね」みたいな、身も蓋もない内容。
お気を悪くされた関係者もいたと思う。すいませんでした。
しかし今回の意見交換会、ＩＰＡの本気が感じられる素晴らしい会で、参加してほんとに良かったと感じている。データをめぐる最新の動向を知る良い機会ともなり、非常に勉強になった。
意外だったのは、拙作の共通語彙基盤ラーメンデータセットがニッチに人気があったこと。鯖江の福野さんの一日一創ブログでも紹介していただいた。
福野さんの、共通語彙基盤に対する感性はさすがに鋭く、ユーザーとして、また技術者としての様々な見解は、非常に共感できるものだった。
全角日本語の語彙は、グローバル社会の中で受け入れられるのは難しいのではないかという問題提起、Schema.orgとの互換性、などなど。
多様性と信頼の共存、まさにそれが必要だろう。
みんなの幸せのための共通語彙基盤の発展に、私も、少しでも力添えができたらと考えている。
何をしゃべろうか悩んだが、やはり共通語彙基盤ネタがウケるだろうと考え、共通語彙基盤と Linked Open Data という超壮大なテーマを、超コンパクトにまとめてしゃべってきた。
しゃべったのは、「共通語彙基盤って、ぶっちゃけ難しすぎるよね」みたいな、身も蓋もない内容。
お気を悪くされた関係者もいたと思う。すいませんでした。
しかし今回の意見交換会、ＩＰＡの本気が感じられる素晴らしい会で、参加してほんとに良かったと感じている。データをめぐる最新の動向を知る良い機会ともなり、非常に勉強になった。
意外だったのは、拙作の共通語彙基盤ラーメンデータセットがニッチに人気があったこと。鯖江の福野さんの一日一創ブログでも紹介していただいた。
福野さんの、共通語彙基盤に対する感性はさすがに鋭く、ユーザーとして、また技術者としての様々な見解は、非常に共感できるものだった。
全角日本語の語彙は、グローバル社会の中で受け入れられるのは難しいのではないかという問題提起、Schema.orgとの互換性、などなど。
多様性と信頼の共存、まさにそれが必要だろう。
みんなの幸せのための共通語彙基盤の発展に、私も、少しでも力添えができたらと考えている。
2018年4月30日月曜日
ドメインをとった
このたび、mirko.jp のドメインを取得し、公共オープンデータ利活用研究室 mirko のホームページに割り当てた。
https://www.mirko.jp/
公共オープンデータ利活用研究室 mirko は、ネットオウルのレンタルサーバーで運営している。
ネットオウルは、地元の京都市の会社なので、個人的に応援しているという理由もある。
これまでは、ネットオウルの「ミニバード」というサービスのサブドメインに、僕のニックネーム mirko を割り当てて mirko.minibird.jp としていた。
上記のURLに特に不満はなかったのだが、やっぱり、ずっと使える永続的なURLがいいなと思い、ネットオウルから独自ドメインの取得申請を行った。
何の苦労もなく、５分で手続き完了。
浸透するまで半日ほど待ち、リダイレクトかけて、グーグル検索のサイト引っ越しをちょいちょいと。はい完成。簡単なもんだ。
ドメイン取得で思い出すのは、今から２０数年前、まだＷＥＢ黎明期だったころ、仲介業者を介さず、苦労して自力でドメインをとったこと。
とったドメインは pospe.com 。
当時、ポストペット（通称ポスペ）というメーラーが大流行していて、私はそれをマニアックに解析するという、「ポストペットマニアックス」というサイトを、そのドメインで運営していた。若かりし頃の黒歴史の一つだ。
そのポストペットマニアックス、結構人気もあって、２年ほど楽しく遊んでいたのだが、当時、お金が全然無くなっちゃって、生活のため、やむ無く pospe.com をドメイン屋に売り払った。
まだポストペット人気が高い時期だったので、僕のポスペコムは８万円くらいで売れたように記憶している。おかげで、何とか生き延びることができた。
（今の時代なら広告収入でウハウハ生活ができたのになぁ…）
そのポスペコム、今はどうなってるんだろうと覗いてみたら、こんなだった。
http://www.pospe.com/
兵どもが夢の跡かな（笑）
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 にした。
検索でもっと上位に来るブログサービスも色々ありそうだが、僕のブログはただの独り言日記みたいなものなので、あまり読まれなくてもいいし、何より広告が無いのがイイ！
グーグルなので、親サイト自体がつぶれて、サービスが停止されることもまずないだろうし。
（グーグルがブログサービスを突然やめちゃう可能性はあるが…）
ワードプレスを使って自分で作ろうとも思ったが、最近忙しくて、めんどくさくなって諦めてしまった…
時間ができて、ワードプレスのほうが良さそうなら、そのうち乗り換えるかも。
登録:
投稿 (Atom)