メタデータ暫定構造ガイドラインと、gml:VerticalCRS の例いろいろ

（先に考えたいことがあるので予定を変更してお送りしております。表題・概要の続きは後日とさせてくださいごめんなさい）

メタデータ構造について急いで詰めなければならない。 文書を確定する必要はないのだが、なにかプレゼンで見せられる程度の自信をもった詰めが必要。
どのタグ使うか迷うものについて：結論だけのべる。

• 固有名の地名
• 地点番号表（Volume A）が参照できるものについては、place keyword (ApMD2勧告)。ここで使うべき thesaurusName が決められている。
• それ以外についても、整合性の観点から、place keyword とすべき。可能なら thesaurusName を記述することを勧告。
• つまり、geographicIdentifier は避けて[9/30改訂]勧告されず place keyword にすべき。後で thesaurusName を追加するのが難しいからである。例外として、シソーラス抜きで固有名それぞれに identifier があるような体系ならば、これを使ってもよい。
• データ所在ＵＲＬ
• 連絡先を明示することが望ましいので、distributionInfo/*/distributor/*/distributorTransferOptions を勧告。
• いいかえれば、distributionInfo/*/transferOptions や datasetURI は非勧告であるが、データが製造直専売される場合は transferOption でもまあいいだろう。
• datasetURI は複数指定不可なので、避ける（discouraged）。
• データ形式
• distributionFormat を勧告する。
• distributorFormat は避けるべき。
• resourceFormat も避けるべき[9/30改訂]は勧告しないが、避けるべきとまでは言わない。来てしまうことに備えるべき。
• いずれにしても、formatDistributor は避ける。特に distributorFormat内は駄目（strongly discouraged）。
• 連絡先
• identificationInfo/*/pointOfContact[*/role=originator] は勧告。データ作成者としてクレジットされる者。
• identificationInfo/*/citation/*/citedResponsibleParty は前項と異なる理由がないから、避けるべき。サイテーションに組織名を書くことが期待される場合、organizationName などのコンパクトな内容で十分。
• 上述のように distributor は勧告される。データ作成者と同一であっても勧告される。
• thesaurusName の中に citedResponsibleParty を書く場合も、組織名などコンパクトな内容で十分。
• individualName に役職名を書くのは駄目。
• いずれ、code.wmo.int レジストリを xlink するような提案をする。

もうひとつ、書き下していて気になるのが、gml:VerticalCRS についてである。

要は、なんら確立された書法がない。

ググると自分のブログばかり出て嫌になるが、

• ２０１１年の自分
• 海抜だけ考えた。
• <gml:identifier codeSpace="urn:ogc:def:crs:EPSG::">5714</gml:identifier>
• ９月９日の自分
• 海抜、気圧、海水深[9/30補]が区別されれば大概の用は足りるということを考えた。
• gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"
• ＮＧＤＣ
• 海水深だけ考えているようである。

• <gml:identifier codeSpace="OGP">urn:ogc:def:crs:EPSG::5715</gml:identifier> 

最近の議論との整合性からいくと、 identifier を http://codes.wmo.int/grib2/codeflag/4.5 以下にすべきではないか。

データカタログ書誌情報（メタデータ・レコード）における良い表題・概要の記述指針、または良いテキストという言葉をどう消化するか

データカタログの書誌情報（メタデータ・レコード）には、通例２つのフリーテキストの必須要素がある。ISO 19115 でいえば title, abstract であり、ダブリンコアでいえば title, description である。

これらは機械でなく人間が読むための文字列であり、どう書くかは現状では常識にゆだねられている。自由文について、XMLスキーマのバリデータのような簡単な仕掛けで機械的に不適切な記述を検出することはできない。

だからといってこれらを野放しにして、まちまちの書法（スタイル）が用いられたり、極端にいえば "dummy", "tbd", "data 123" でさえ許容するならば、メタデータ作製は容易になるかもしれないが、データカタログの品質は著しく劣化してしまう。個人や少人数ならば暗黙知に頼ることも許されようが、WIS のような組織的取り組みにおいては、なんらかの明示的な指針・ガイドラインが求められる。

しかし、良いテキストという言葉は実に曖昧模糊・感覚的に聞こえる。安易に指針を書くと、あまりに抽象的で用をなさないか、または具体例に頼るならば射程が狭くなりかねない。それを超えて、真に学際的な基盤として、メタデータ作者の助けになることができるのだろうか。私の考える力が問われている。

何かを設計するとき、しばしば私は２つの主義を唱える：

• オペレーショナリズム：　人工物は、まずその用途によって評価されるべきである。「意味」や、内在的構造の美しさなどを優先すべきでない。
• 中庸：　単一の指標を際限なく片方に振りさえすればよい、というような指針は、しばしば暗黙の前提を忘れており、それが破れたところで酷い結果をもたらす。なんらかの指標で相矛盾する複数の要件を見出して、それらの間の妥協点を探すといった書き方に改めると、よりましになる。

具体的にあてはめていうと：

• 用途：　メタデータは、第一にデータ発見のために作られると考えられている（他の用途もあるが後の議論を覆すものでない）。それは２段階で行われる。
• 検索：　まずは keyword 欄が検索のために用意されているが、かならずしも全ての情報がキーワードに盛り込めない。表題や概要についてもフリーテキスト検索が求められている。
• 検索結果の評価：　検索結果は人間に呈示され、人間が適切なものを選択する。このとき（キーワードなどではなく）まず表題が、次いでスペースが許せば（あるいは個別のレコードの画面で）概要が表示されることになるであろう。
• これら２つの段階に共通することは、選択であるということ。つまり、テキストの意味を機械的に判断できなくても、異なる多数のレコードにしばしば同一または類似の表題・概要がつけられるようでは用をなさない、ということは機械的にいえる。
• 中庸：　テキスト（文字列）にとって自明に重要な量的指標は、長さ（字数）である。
• 前項の議論も、情報が多いほうがよい、つまり、テキストは長いほうがよいという方向である。巷間でみられる散文的な指針も基本的には同様。
• では無限に長いほうがよいか、というとそうではあるまい。表示しきれないほど長い表題や、読み切れないほど長い概要は、逆効果となる。

では、長さの限界について、具体的な共通認識はあるだろうか。人々に認識を問うのが本来かもしれないが、WIS は既に運用に入っているので、運用レコードについて調べてみるだけなら即日結果が得られる。

まず表題の長さのヒストグラムはこうである。（横軸は対数目盛）



際立った２峰性の分布であるが、これは、メタデータレコードを生成するソフトウェアの数がまだ少数だからであろう。文字数が１１０～１１９の時だけ特別に不都合となる理由はない。

現時点では、次のような観察にとどめて置くのが安全だろう：

• ９５％のレコードが４５文字以上である
• 中央値は８８文字
• ９５％のレコードが１５３文字以下である
• 最大値は２０８文字

つまり、表題は長くても数行にとどめることが期待されているといえよう。伝統的な仮想端末は横８０文字であるから、中央値が１行くらい、概ね２行におさまる程度となる。

もうちょっと言うと、あまりに短い表題（たとえば４０文字以下）や、あまりに長い表題（たとえば１６０文字以上）を頻繁に生じるような命名法は、良いとはいえないだろう。

ついで、概要の長さのヒストグラムはこうである。



今度はまったく違って、片方に裾野を引いた分布である。極めて短い例が多数ある、というか、実をいうと <abstract/> が空要素になっているレコードが１２％も存在する。それは流石に推奨するわけにはゆかないけれど。

• 中央値は２８０文字
• ９５％のレコードが１３５１文字以下である
• ９９％のレコードが１４４３文字以下である
• 最大値は５３１２文字

他の議論をふまえると、もうちょっと長くてもいいかな、という気持ちを込めて、ざっくりまとめると、概ね１～２画面で見られるように、２０００～３０００文字以下にまとめている、と言えないだろうか。伝統的な仮想端末は縦２５行であるから、改行がなければ２０００文字が１画面である。

長くなったのでここでいったん切る。

gmd:VerticalCRS/gml:verticalCRS/gml:identifier には何を書いたものやら（OGC資料探索）

緊急とは思わないのだが、頭の体操。
ISO地理メタデータ標準19115において鉛直位置を数値的に表現しようとするなら、それは gmd:identificationInfo/*/gmd:extent たらざるを得ない。

さてそこで座標の種別をどう表現するか。上述 extent には
gmd:verticalElement/*/gmd:VerticalCRS というのがあって、要は gml:identifier
ひとつみたいなものなのであるが、それはなんでしょうと。

OGC 07-092r2 に verticalDatumType の表というものがあって、筆頭が
urn:ogc:def:verticalDatumType:OGC:1.0:geoidal
urn:ogc:def:verticalDatumType:OGC:1.0:depth
urn:ogc:def:verticalDatumType:OGC:1.0:barometric
と続く。

これはあくまで datum Type であって、それを使った datum を作らないといけない。


では、オープンなレジストリに WKT でも書いて登録すればいいのか…というと、WKT
の VERT_DATUM の２項目（普通2005）に何を書くかわからないのではたととまる。
答は OGC 01-009 に書いてあって、上述 verticalDatumType:OGC:1.0:barometric ならば 2003 である。

と、そこまで調べて spatialreference.org に行ったら新規登録を受け付けていない....

ここではたと原点に立ち返って考えると、気象界の利用者というのは実は datum が何だってどうでもいい。実用上何を区別したいのかというと気圧座標と標高と海面下水深が区別できればそれでいいのである。ならば

gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"

としてしまっても、いいのではないか。本当は駄目だけど、混乱が減るし。