2013-10-15

尺度水準とデータベースのキー、あるいはハッシュ・二分木・配列の使い分け

あたりまえっていえば、あたりまえなんだけど。

量的指標の尺度水準というものがある。実数でなにかを表わそうとするときの表現の仕方を分類したもので、扱いがこれにより異なる。定義はウィキぺを見てもらうとして、これらは記号に許される2項演算子のセットに根がある。
  • 名義尺度
    • 2つの値の比較が↑できない↓できる
  • 順番尺度
    • 2つの値の差を計算すること(減算)が↑できない↓できる
  • 間隔尺度
    • 2つの値の比を計算すること(除算)が↑できない↓できる
  • 比率尺度
データベースのキーというか、少量データのキーで他の(典型的には多量の)データをあらわすやり方にも、似たような階梯があらわれるんだけど、
  •  ハッシュが使える
    • 2つの値の比較が↑できない↓できる
  • 二分木が使える
    • 次の3つが仮定↑できない↓できる
      • 2つの値の差を計算できる
      • その間にいくつの他の値が入りうるか算出できる
      • 値の分布を最大値から最小値まで見たときに「空き地」がもったいないと思うほどは多くない
  • 配列にいれておける
てな感じになってしまう。

説明するまでもなく、配列モデルの適用条件が美しくない。なにかまったく違った整理をすれば美しい数理が見えてくるのかもしれないと数日考えていたが、とりあえず今の私にゃ無理だ。



2013-10-03

表題・概要の指針、つづき

(ちょっとまとまりが悪くなります。)

記入項目の再検討


前回みたように、内容は充実していたほうがいいが、適切な長さというものがある。また、一群の類似したデータには一貫した命名がなされることが望ましいので、つまりは分野ごとに一貫した命名法を作ってほしい。既にテーブルの上にある案はそのたたき台であり、いくらか取捨選択がなされるべきである。

案というのはこういうもの:
  • 表題はwhat, where, who, when から構成すべし
    • when は予報期間と有効期間を混同しているように思われる
    • 語順は厳密でない
    • 長さ制約については、内容を迅速に把握できるように、との一言がいちおうある。
    • それに対して、内容充実については、重複回避について言及していないが、 多義語を避けるべきとの言葉はある。
  • 概要は
    • 冒頭1文1パラがwhat
    • 中パラが詳細(内容、精度、作成組織など)
    • 末尾1文1パラがデータフォーマット
一見すると薄い思いつきのようにも見えるが、それなりに現実をふまえているのではあろう。
  • 安易に 5W1H といわず、why と how を省いている。強いていえば why はデータ作成の根拠となる国際計画にあたり、how は提供方法といえなくもないが、それは表題にあるべきではない、ということを暗黙にいっていることになる。計画間でデータ再活用を促進するための学際計画なんだし、提供方法自由度や流通範囲をデータに強く紐づけせず、拡大すべきだからである。
  • 残る4Wをすべて概要で繰り返すのではなく、what に力点を置き、おそらくそこから漏れたフォーマット情報を末尾に置かせるなど、工夫の形跡がある。
このうえアプリオリな原理で化粧することに今興味はない。むしろ、現実をちゃんと見ているかチェックしたほうがいいだろう。

運用メタデータの title に現れる語を抽出し、出現回数順でトップ150まで手作業で分類してみた
むろん主観的であることは免れないが、何か見落としはないかチェックするという意義はあるだろう。提案済みの4分類、それから ISO 19115 の構造とキーワード種別、さいごに Volume C1 の列との対比を考えるとこのようになる


要は、4Wのそれぞれについて、もっとも典型的な類型ではない語を追加する余地があるのと、GTSヘッダのようなデータ名略号については4Wでなくても追加を検討しうるということがいいたい。

ただ、RTH については書かない方がいいと思うんだけど。

指針案まとめ

まとめるとこういうことになると思う。

  1. 表題
    • 次の4項からなるとよい
      • What - データのカテゴリ
      • Where - 水平位置
      • When - 予報時間(あれば)
      • Who - データ管理者(発信センター)
    • データの種類によっては次のようなものを用いてもよい
      • What - データ作成プロセス、測器、物理量、水平解像度
      • Where - 鉛直位置
      • When - 一日の中の時間(観測時刻、初期値時刻、発信周期)、データの期間(有期の場合)
      • 他 - データ名略号
    • 長さ
      • 複数の異なるメタデータレコードが同じ表題を持たないように、表題に多くの項目を盛り込むことが望ましい。
      • しかし、通常は表示用途であることと、短時間で把握すべきことをかんがみて、概ね160字以下にすべき
      • 個々の項目は、意味不明にならない程度にコンパクトであることが望ましい。略語説明のカッコ書きや、「詳細はアブストラクト参照」などの冗長語は避ける。
    • 次のようなことは書かない方がいい
      • データフォーマット(アブストでよい)
      • ディストリビュータ(替わりうる)
  2. 概要
    • 次の3段落からなるとよい(それ以上であっても差し支えない)
      • 冒頭段落 - 表題の what を1行程度で説明したもの。略語を避ける。
      • 中間段落 - 表題のその他の事項を1000~2000字程度で説明する。
      • 末尾段落 - データフォーマットを1行程度で説明する。
    • 説明は、次のようなことが期待される
      • 盛り込めなかった項目の説明
      • 略語あるいは一般的でない術語の説明

2013-09-27

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

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

メタデータ構造について急いで詰めなければならない。 文書を確定する必要はないのだが、なにかプレゼンで見せられる程度の自信をもった詰めが必要。
どのタグ使うか迷うものについて:結論だけのべる。
  • 固有名の地名
    • 地点番号表(Volume A)が参照できるものについては、place keyword (ApMD2勧告)。ここで使うべき thesaurusName が決められている。
    • それ以外についても、整合性の観点から、place keyword とすべき。可能なら thesaurusName を記述することを勧告。
    • つまり、geographicIdentifier は避けて[9/30改訂]勧告されず place keyword にすべき。後で thesaurusName を追加するのが難しいからである。例外として、シソーラス抜きで固有名それぞれに identifier があるような体系ならば、これを使ってもよい。
  • データ所在URL
    • 連絡先を明示することが望ましいので、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 についてである。

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

ググると自分のブログばかり出て嫌になるが、
  • 2011年の自分
    • 海抜だけ考えた。
    • <gml:identifier codeSpace="urn:ogc:def:crs:EPSG::">5714</gml:identifier>
  • 9月9日の自分
    • 海抜、気圧、海水深[9/30補]が区別されれば大概の用は足りるということを考えた。
    • gml:identifier="urn:ogc:def:verticalDatumType:OGC:1.0:barometric"
  • NGDC
    • 海水深だけ考えているようである。
    • <gml:identifier codeSpace="OGP">urn:ogc:def:crs:EPSG::5715</gml:identifier> 
最近の議論との整合性からいくと、 identifier を http://codes.wmo.int/grib2/codeflag/4.5 以下にすべきではないか。

2013-09-25

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


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

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

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

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

何かを設計するとき、しばしば私は2つの主義を唱える:
  • オペレーショナリズム: 人工物は、まずその用途によって評価されるべきである。「意味」や、内在的構造の美しさなどを優先すべきでない。
  • 中庸: 単一の指標を際限なく片方に振りさえすればよい、というような指針は、しばしば暗黙の前提を忘れており、それが破れたところで酷い結果をもたらす。なんらかの指標で相矛盾する複数の要件を見出して、それらの間の妥協点を探すといった書き方に改めると、よりましになる。
具体的にあてはめていうと:
  • 用途: メタデータは、第一にデータ発見のために作られると考えられている(他の用途もあるが後の議論を覆すものでない)。それは2段階で行われる。
    • 検索: まずは keyword 欄が検索のために用意されているが、かならずしも全ての情報がキーワードに盛り込めない。表題や概要についてもフリーテキスト検索が求められている。
    • 検索結果の評価: 検索結果は人間に呈示され、人間が適切なものを選択する。このとき(キーワードなどではなく)まず表題が、次いでスペースが許せば(あるいは個別のレコードの画面で)概要が表示されることになるであろう。
    • これら2つの段階に共通することは、選択であるということ。つまり、テキストの意味を機械的に判断できなくても、異なる多数のレコードにしばしば同一または類似の表題・概要がつけられるようでは用をなさない、ということは機械的にいえる。
  • 中庸: テキスト(文字列)にとって自明に重要な量的指標は、長さ(字数)である。
    • 前項の議論も、情報が多いほうがよい、つまり、テキストは長いほうがよいという方向である。巷間でみられる散文的な指針も基本的には同様。
    • では無限に長いほうがよいか、というとそうではあるまい。表示しきれないほど長い表題や、読み切れないほど長い概要は、逆効果となる。
では、長さの限界について、具体的な共通認識はあるだろうか。人々に認識を問うのが本来かもしれないが、WIS は既に運用に入っているので、運用レコードについて調べてみるだけなら即日結果が得られる。

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



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

現時点では、次のような観察にとどめて置くのが安全だろう:
  • 95%のレコードが45文字以上である
  • 中央値は88文字
  • 95%のレコードが153文字以下である
  • 最大値は208文字
つまり、表題は長くても数行にとどめることが期待されているといえよう。伝統的な仮想端末は横80文字であるから、中央値が1行くらい、概ね2行におさまる程度となる。

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

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



今度はまったく違って、片方に裾野を引いた分布である。極めて短い例が多数ある、というか、実をいうと <abstract/> が空要素になっているレコードが12%も存在する。それは流石に推奨するわけにはゆかないけれど。
  • 中央値は280文字
  • 95%のレコードが1351文字以下である
  • 99%のレコードが1443文字以下である
  • 最大値は5312文字
他の議論をふまえると、もうちょっと長くてもいいかな、という気持ちを込めて、ざっくりまとめると、概ね1~2画面で見られるように、2000~3000文字以下にまとめている、と言えないだろうか。伝統的な仮想端末は縦25行であるから、改行がなければ2000文字が1画面である。

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

2013-09-09

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 の2項目(普通2005)に何を書くかわからないのではたととまる。
答は OGC 01-009 に書いてあって、上述 verticalDatumType:OGC:1.0:barometric ならば 2003 である。

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

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

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

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

2013-08-08

まとめ ― Ubuntu 12.04 で VIA VNT6656 USB Wifi Module を使えるようにした

ついに完動するに至ったのでまとめておきます。いちおう言っときますが無保証です。

1. 準備

Cコンパイラとかカーネルヘッダとかインストールしておいてください。

2. VIA ドライバのコンパイル

(1) ソースコードを取得

http://www.viaembedded.com/en/products/boards/1890/1/VNT6656_USB_Module_/_Dongle.html
にある VT6656_Linux_src_v1.21.03_x86_11_04.zip です。

$ unzip VT6656_Linux_src_v1.21.03_x86_11_04.zip
$ cd VT6656_Linux_src_v1.21.03_x86/
 

(2)  修正

そのままではコンパイルできないので直します。

--- VT6656_Linux_src_v1.21.03_x86/driver/Makefile    2009-09-07 09:53:36.0000
00000 +0900
+++ work-vt6656/driver/Makefile    2013-08-07 01:51:32.655889247 +0900
@@ -24,7 +24,7 @@
 endif

 # check kernel version
-KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]/2\.6/')
+KVER := $(shell uname -r | cut -c1-3 | sed 's/2\.[56]\|3\.2/2\.6/')
 KERVER2=$(shell uname -r | cut -d. -f2)

 ifeq ($(KVER), 2.6)

diff -ur VT6656_Linux_src_v1.21.03_x86/driver/main_usb.c work-vt6656/driver/main
_usb.c

--- VT6656_Linux_src_v1.21.03_x86/driver/main_usb.c    2011-08-03 11:53:08.0000
00000 +0900
+++ work-vt6656/driver/main_usb.c    2013-08-07 02:23:35.573424483 +0900
@@ -387,7 +387,9 @@
     .ndo_stop        = device_close,
     .ndo_get_stats        = device_get_stats,
     .ndo_start_xmit        = device_xmit,
+#ifdef HAVE_MULTICAST
     .ndo_set_multicast_list    = device_set_multi,
+#endif
     .ndo_do_ioctl        = device_ioctl,
 };
 #endif

[追記:KVER マクロは、将来の Linux の別バージョンでは修正が必要です。要は "2.6" という値になりさえすればいいので、カーネル 2.4 以前を使わないならば、 KVER := 2.6 で十分です。]

(3) ビルド・インストール

config.h は無いので作りました。
# touch /usr/src/linux-headers-3.2.0-51-generic-pae/include/linux/config.h
[追記: いきなりインストールが心配なら、 make install のかわりに非特権ユーザでただ make してみるとよいです。]
# make clean
# make install
このへんで一度 insmod とか試してみるんでしょう。

(4) 設定

[追記: これは、モジュールにネットワークインターフェイス名(今回は eth0 が既にあったので eth1 にしました)。を割り当て、ついで、ブート時に vntwusb が読みこまれるようにします] 
# cat /etc/modules.conf        <-- なければ作る
alias eth1 vntwusb
# cat /etc/modules             <-- これも
lp
vntwusb
[追記:これでリブートしてみるのがいいでしょう。リブートしたくなければ、特権ユーザで modprobe vntwusb とします]

あとは、Ubutuのドキュメントでもみてください。