OGC Approves "Semantic annotations in OGC standards" Best practice document

OGC プレスリリースのお知らせがきた。
https://groups.google.com/a/wmo.int/d/topic/cbs-ipet-mdrd/ficIoIDiB6s/discussion

モノはこちら： 08-167r2
https://portal.opengeospatial.org/files/?artifact_id=47857

ISO 19139 との関係では、たとえば GEMET のようにシソーラス
http://www.eionet.europa.eu/gemet/inspire_themes?langcode=en
だけではなく概念
http://www.eionet.europa.eu/gemet/concept?ns=1&cp=4612
に URI がある場合には Anchor を使って各語句に URL を annotate するのが望ましいという。

（重箱の隅…で済むといいなあ） codeList の中のテキストノード値

先日のエントリ（２）
http://toyoda-eizi-ja.blogspot.com/2013/02/wmo_18.html

で

「本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。 」

とさらっと逃げていますが、本当は

　　… codeListValue="eng">English</　…

みたいなのが正しいかもしれないという議論があります。INSPIRE Implementation
Rule http://inspire.jrc.ec.europa.eu/index.cfm/pageid/101 §2.2.7 は

1) Most interoperable: the element value repeats the codeListValue, 2) Most
compliant: the element value is the name of the codeListValue expressed in
the default language of the Metadata

てなことをいっていて、ISOの規定通りに実装している人が少ない、ということのようです。

WMO地理メタデータ（３というほどではないが）リファレンス書きかけ

一日あきましたが、前項の続き。

2回かけてUMLとXMLの対応関係（バインディングといったけどISO的にはエンコーディングというほうが正しいのかも）の話で終始していて、中身の話をしてません。つまり、ドメイン知識ぜんぜんつかっていない。地理学会公式アカにRTされて、これで終わるわけにはいかんでしょう。

で、各項目について語ろうとすると、トップダウン的アプローチと逐条解説的アプローチがあると思うのですが、 どっちにしても全体像と各要素の近傍の構造を見えるようにしておかないと話ができないなあ、とおもうわけです。

…すんませんカッコつけすぎました。あたしの脳内マップが心もとないので確認するというのが本当のところ…

で、リファレンスをちょっと作ってみました。
http://redmine.toyoda-eizi.net/projects/wcmp/wiki/MD_Metadata
とりあえず、WMOプロファイル１．３の範囲は辛うじてカバーです。ただ、codeList がまだなので、実は半分なんですが。

WMO地理メタデータ解説 （２）バインディングの続き

http://toyoda-eizi-ja.blogspot.com/2013/02/wmo.html の続き。

XML要素名の命名規則、あまり抽象的に書きすぎたのはよくなかったのでもう一度。
実例持ってない人は http://goo.gl/ZPuyi の view source でもみてください。

ISO 19139 にしたがうXML文書のルート要素は gmd:MD_Metadata です。大文字で始まるのはクラスを表わしています。クラスわかんなかったらデータ型の名前と思ってください。MD_Metadata型。その中に gmd:fileIdentifier だの gmd:language だのといった要素が並んでいます。

まず、gmd:fileIdentifier は一番単純な例で、この項目は文字列型です（ええと、項目は、UML的には属性というのが正しいんですが、XMLの属性と紛らわしいので、私は日本では項目といって逃げています）。なので中に gco:CharacterString という要素があって、その中に値が入ります。

<gmd:fileIdentifier><gco:CharacterString>urn:x-wmo:md:int.wmo.wis::SMDL01EDZW</gco:CharacterString></gmd:fileIdentifier>

わざわざ型名を表わす CharacterString を書くのは面倒ですが、XPath でいえば
string(/中略/gmd:fileIdentifier) としてしまえばその中のテキストノードが取得できますから、読む手間はあってもなくてもあまり変わりません。

次の類型が、gmd:language 列挙型（C や Java の enum）です。任意の文字列値じゃなくて、メタデータレコード（この XML 文書）の外で誰かが決めたリストに制約されるということで
すね。この場合、どのリストを使ったかをＵＲＬで指示するようになっています。一見
LinkedData かと思われるのですが、URL で指示されるのは語句じゃなくて複数の語句を連ねたリストです。
<gmd:language>
<gmd:LanguageCodecodeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/gmxCodelists.xml#LanguageCode"codeListValue="eng">eng</gmd:LanguageCode></gmd:language>
本当は、codeListValue 属性が機械可読な語句で、内部のテキストノード
gmd:LanguageCode/text() は多言語化ができるらしいのですが、WMO では結局英語をデフォルト言語にしろといっているので両方同じ文字列を入れろということになります。

さいごに、値が文字列１つじゃなくて、さらに内部に項目がたくさんあるのはクラスといいます（C なら構造型といったところ）。下の例だと　gmd:contact 要素は
CI_ResponsibleParty クラスで、その中には organisationName やら positionName
といった項目が含まれるわけです。

<gmd:contact>
<gmd:CI_ResponsibleParty>
<gmd:organisationName><gco:CharacterString>Deutscher Wetterdienst</gco:CharacterString></gmd:organisationName>
<gmd:positionName><gco:CharacterString>RTH Focal Point</gco:CharacterString></gmd:positionName>
...
</gmd:CI_ResponsibleParty>
</gmd:contact>

あるクラスのなかに他のクラスの項目が入るといったことがありえて、全体でいうとけっこう複雑です。その関係をあらわした図が UML です。

どのくらい複雑かというとですね、ISO 19115 そのものの UML は ISO から規格票を買っていただく必要があって困るのですが、WMO プロファイルバージョン 1.1 はかなりそれに近いのでご
らんいただけばいいと思います。
http://wis.wmo.int/2010/metadata/version_1-1/WMOCoreVer1.1_UML20100318.pdf

いかがです？　覚えなくていいですよ。ごく控えめに言って、これをそのまま非専門家に使いこなしてもらうことは期待できません。

要はいろいろ欲張るから肥大化するので、本当に必要なところはどこですかというのを煮詰めていった結果が今回発行されたバージョン 1.3 の Part 1 p.20 にある UML です。
http://wis.wmo.int/2012/metadata/WMO_Core_Metadata_Profile_v1.3_Specification_Part_1_v1.0FINALcorrected.pdf#page=20

…ながくなったのでこの辺で。
（飽きるまで続きます）

WMO地理メタデータプロファイルについて解説めいたこと（ちょっと追補あり）

英語版のブログとツイッターに最低限のアナウンス http://dlvr.it/2y1zVP をして、それなりに見ていただいている方もいるようなのだけど、多分どこから理解したものか途方に暮れると思うので、というと恩着せがましいけれど、現状の覚えとしても少々書いておいたほうがいいと思う。

まず、正式名称は WMO Core Metadata Profile という。そもそもプロファイルprofileというのは地理メタデータ標準 ISO 19115 が汎用であるのに対してWMOあるいは気象水文の応用に特化
したものであるという意味である[追記：ISO地理情報標準シリーズでの通則はISO 19106で規定されている、らしい]。それじゃ core profile とは何であるかというと、WMOといってもいささか分野が広くて中に無数のコミュニティを包含していて、それぞれにプロファイルを形成することが可能ではあるが、その共通部分たるべきもの、ということだと説明している。[ISO 19115 の中にも core profile というものがあったが、意味的に ISO の必須要素との関係が不明確であり、また][訂正：似たような概念として ISO 19115:2003 では core metadata elements あるいは core metadata componentsというものを決めていて、すべてのプロファイルはこれを含まねばならない(下図参照）としていたのだが、必須でないものをプロファイルに含めねばならないという意義が不明確ということと、]内容的にもどうだかということで削除される方向と聞いている。

[追記：

]

次に、UML と XML の関係。少なくとも現行の ISO 19115 は UML であって XML はそのエンコーディング方法の一つと言う位置づけで ISO/TS 19139 という別文書になっている。そのこと自体を
論じるのはおいておいて、でも、UML クラスが XML 要素に対応するといったように用語が二重になってしまっていることはわずらわしいが付き合わざるをえない。

面白い技法と思うのは、UML クラス名に対応する XML 要素（大文字始まり）の中に、そのクラス中の属性名に対応する XML 要素（小文字始まり）が入って、その中にはその要素のク
ラスに対応する XML 要素が入る、と言う交互構造である。

・属性名はなるべく直感的に選ばれ、酷いときは重複することもあるけれど、クラス名を明示すれば微視的に特定することができる。
・クラスの特殊化、属性追加は XML スキーマの継承で行われているけれど、それは大文字のクラス名が変わるだけで、小文字部分は変わらないので、継承によって変わらない指示のしかたは
identificationInfo/*/citation/*/date のように /*/ が多用されることになる

（ちょっとちゅうだん）

「配列を値としてもつ連想配列」の入力方法

承前：　（http://toyoda-eizi-ja.blogspot.jp/2013/02/blog-post.html の続き）

1レコードがキーバリューで、バリューが単なるスカラーでなくて配列にしたいということはあるが、入力方法が課題。

エクセルを使い続けるとすると、
1セルにマルチラインを押し込む（Ａｌｔ＋Ｅｎｔｅｒってちょっとトリッキーだよね）か、
プライマリーキーがない行は「継続行」とするか。

「配列を値としてもつ連想配列」の応用範囲の広さ

またぞろメタデータの仕事をやらねばならない季節がやってきた。

最終製品は ISO 19115 なのだが、コテコテのオブジェクト指向は本当に嫌だ（どうせ誰も理解してくれない）というのと、エクセル表をメールで送るといった紙文化（ビットにアトムのふりをさせる処理）と戦うよりは利用しないと話が進まないということから、エクセルでなんとかしたいということをずっとやっている。

しかし１レコードが単なるキーバリューではちょっとものたりない。

以前こんなスキーマをつくった。
http://www.gisc.kishou.go.jp/xsd/jmd0.1/jmd.rnc

名前だけを決めて、順序と数は問わないという構造は、
ＯＡＩ−ＰＭＨ用ダブリンコアスキーマ
http://www.openarchives.org/OAI/2.0/oai_dc.xsd
にならったのだが、この構造、結構応用範囲が広いと感じている。

ＲＦＣ８２２とかＣＧＩとかもそうだし。