作成した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
2018年6月25日月曜日
（各論）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との互換性、などなど。
多様性と信頼の共存、まさにそれが必要だろう。
みんなの幸せのための共通語彙基盤の発展に、私も、少しでも力添えができたらと考えている。
登録:
投稿 (Atom)