― 多次元数値データと可視化情報の統合データスキーマの開発を目指して ―
2001 年 (最終履歴は 2001/09/27) に gtool4 プロジェクト全体の現状と将来の展望に書かれたもので、 過去の遺産としてここに残してあります。 現在開発中の gt4f90io というツールはこの思想を実現するための ツールの一つとして位置づけることができるのかもしれません。
ただし現在、可視化や解析のツール作成に関しては Dennou Ruby プロジェクト が主導となるなど、gtool4 プロジェクトの今後の 展望は以下で述べられていることとは少し異なってきている かもしれません。
「量的変化はついには質的変化を惹起する」
ヘーゲルの言葉らしい
私たち gtool4 の開発者グループは主に地球流体科学関係者、つまり気象・海 洋・惑星大気・地球の核やマントルなどの研究者からなっています。私たちが gtool4 を開発するのは、データの嵐と呼ばれる現象にまつわる諸問題の解決 としていくつかの方法論を提示し実験していくためです。
私たちは日ごろ多量のデータを交換して仕事をしています。たとえば他人が観 測したデータ、理論的な計算の結果得られたデータ、それらを用いて遠くの計 算機センターで計算したデータなどです。
計算機の能力向上や観測手段の開発に伴って、私たちが扱うデータは年々巨大 化しています。10年前ならスーパーコンピュータでも取り扱うことさえままな らなかったような巨大なファイルをノートパソコンで作成したり保存したりで きるようになりました。巨大化だけではなく、取り扱うデータの種類や計算の 複雑さも激増しています。
データの量の増大により、メタデータ管理の重要性が増してきました。メタデー タとはデータ自身を意味あらしめるために必要なデータの総称で、たとえば物 理量名称、単位、格子配置、取得法、各種パラメタなどです。データを多数の 作業者で共有する場合、あるいは記憶に頼れない長期間にわたった作業におい てはメタデータを保持する方法の如何が作業の速度や信頼性を左右します。
メタデータを紛失したり、個人の記憶に依存するような事態を避けるためには、 データ自身がメタデータを保持するようにすべきです。このような考慮にたっ たデータ形式は自己記述的（★概念創案者について調べるべき）と呼ばれてい ます。
自己記述的データ形式を設計するにあたっては、メタデータの項目リストを決 めなければなりません。この項目リストはデータベースにおいてはデータベー ススキーマと呼ばれています。gtool4 の目標のひとつは、地球流体科学界に おけるデータベーススキーマに相当するものの標準を利用者自身によって確立 することにあります。
もうひとつの gtool4 の特徴は、数値データと可視化表現を同じプラットフォー ムで自己記述化しようとする新しい試みです。データ形式の拡張としてとらえ ると、絵も描けるデータ形式といったところです。
数値データを可視化した結果ではなく、方法を保存しておきたいということが あります。このようなニーズに対して従来は、可視化エンジンを簡易な言語の インタプリタとして実装して、描画手続を順に記したスクリプトとして保存す るようなアプローチが取られてきました。この方法は新しい可視化手順を生産 する過程では有効ですが、インタプリタ処理系がない環境では再現不能である とか、スクリプトとデータがばらばらになってしまうといった問題があり、保 存や配布には向きません。
gtool4 では可視化オブジェクトを数値データの一種として格納できるような 枠組みを開発中です。この方法によりデータが言語から独立になり、分散オブ ジェクト環境への適応も容易になるものと期待されます。
gtool4 は以下の3つのソフトウェアパッケージに強い影響を受けています。 GTOOL3 からは理念的影響を受け、DCL と NetCDF はサブルーチンとして利用 しています。
GTOOL3 は地球流体電脳倶楽部で従来から用いられているファイル形式、入出 力ライブラリ、ならびにファイル操作ツール群の名称です。gtool4 は GTOOL3 の経験と反省に立って設計されていますが、コードやデータ形式は継承してい ません。
GTOOL3 から引き継がれた特徴:
GTOOL3 の反省に立って新しく gtool4 で導入した特徴:
データ形式は当面 netCDF 形式によることにしました。機種依存の物理表現を 吸収してくれる上に、メタデータ表現のために利用できる属性という機構が用 意されているからです。したがって、処理系は netCDF ライブラリを必要とし ます。
残念ながらファイル形式を netCDF にできない状況も存在しますから、今後 gtool4 ではいくつかのファイル形式に対応しようと企画しています。
将来的に取り扱うファイル形式が多くなっていくと、すべての形式の入出力ラ イブラリをリンクするのは現実的でなくなってゆくので、分散データベース化 を検討すべきでしょう。NetCDF はそのときの通信形式として有用かもしれま せん。
gtool4 の可視化の基礎となっているのは DCL です。
DCL は線画と多角形塗りつぶしから構成される2次元的可視化表現をサポート します。ライブラリは GKS サブセットから日付の座標軸・等高線などの高水 準ロジックまでの幅広い構成となっています。描画デバイスとしては以下のも のがサポートされています。
gtool4 ではこのほかにも DCL から若干の機種依存ルーチンを使っています。 しかし、この機種依存性は慎重に1モジュールにまとめられていますから、グ ラフィックスを利用しないアプリケーションは容易に DCL のない環境に移植 できます。
現在のところ、データ形式ないしはスキーマの考察は gtool4 NetCDF 規約と いう形式でなされています。これは NetCDF 形式を利用することを前提として、 主に属性の利用法について規定したものです。
この規約には、概念スキーマすなわちメタデータにはどのような事項が記録さ れるべきかの考察と、内部スキーマすなわちメタデータの各事項をいかにして NetCDF 形式で格納するかの規定が含まれています。
概念スキーマはさらに、数値データ表現と、可視化表現情報に大別されます。
数値データ表現規定を開発するサイは、従来の数値データ形式（netCDF 規約 を含む）で表現されてきたものの概念的和集合を抽出するように作業しました。 具体的には GTOOL3, GrADS データセット, そして COARDS, GDC などの netCDF 規約が考慮されています。
可視化表現情報の規定では DCL を利用して伝統的な論文で用いられる図形表 現を再現するのに必要な情報を抽出しました。
概念スキーマと内部スキーマが混在している現在の gtool4 NetCDF 規約の記 述形式は望ましいものではありません。
概念スキーマは我々の数値データに関する慣習的操作体系ないしは知識体系を 記号化明確化したものです。したがって、ファイル形式（内部スキーマ）がど のようなものであっても共通であるべきものです。ファイル形式に依存しない 属性リストとして概念スキーマを記述し、ファイル形式ごとの属性表現規則は 内部スキーマとしてまとめることによって、規定の簡潔さを保持しつつファイ ル形式間の可搬性を確保できると期待できます。
概念スキーマ開発については2つの事項が保留となっています。そのひとつが 物理量の単位をいかに演算するかです。
NetCDF ユーザーズガイドでは udunits ライブラリが受理する単位を用いるこ とが推奨されています。udunits のマニュアルは単位の表現方法を規定してい ます。ライブラリは文字列表現と（C の構造体による）内部表現との相互変換 と、加減乗除演算を実装しています。
現在のところ udunits を Windows に移植できていないため、加減乗除演算が udunits の実装どおりでよいかに関する検討は実施されていません。udunits の可搬性を見切って Fortran 90 で独自に互換品を実装しようというアイデア もあったのですが、まだ実行されていません。
概念スキーマ開発に関する最大の保留課題は情報の履歴管理です。
NetCDF ユーザーズガイドでは history 属性にファイルの履歴を示す文字列値 を書き込むことを推奨しています。history 属性の構造は線形で、ファイルが 作られてから改変を経るごとに追加されていくような構造になっています。
gtool4 NetCDF 規約の作業グループは GTOOL3 の経験から、2項演算子などに ついては線形の履歴を当てはめるのが無意味であることを認識していました。 また、長すぎる文字型属性値は特に Fortran での取り扱いが困難です。その ため、作業グループでは木構造の履歴を表現する方法を開発することだけを決 定しましたが、まだ試案は作成されていません。
データを読みとって書き出す演算において、次元の意味づけを 正しく保持するようなメカニズムは作れるだろうか？
簡単のため出力変数を一つとします。すると演算は入力変数の 数によって単項演算、二項演算、三項演算... と分類されます。
単項演算子については大した問題はありません。 足し算みたいな要素毎の操作ならばもとの次元セットをコピーすればよいし、 平均のように次元を減少するものについても残った次元セットをコピーすれば いいでしょう。つまり、要請は簡単で、演算の過程で常に次元セットを覚えて いればよいのです。ま、メタデータを紛失しない義務くらいは要請してもいいでしょう。
二項演算子になるととたんに悩ましくなります。 要素毎操作に限定して考えることにすると、次元数が一致しなくてはいけない くらいは自明ですが、両者の次元リストの対応をどのようにとるかというところが 工夫のしどころというか悩ましいところというか....
堀ノ内さんはメタデータに頼らず、次元の宣言順序と次元長（格子数）だけか ら対応が決まるアルゴリズムを提案しました。おそらく ruby の NumArray ク ラスにもその考えが活かされているか、その予定なのでしょう？この方法は簡 明で、実装も容易でしょうが、健介さんの指摘された問題がまさにあてはまっ てしまいます。
私はメタデータに頼って意味づけによる対応を作る方向を模索しました。
たとえば GrADS のスクリプトによる四則演算が便利なのは、 すべての次元が経度／緯度／高度／時間のいずれか として表現されなければならないという制約があるために、 意味による対応づけによる演算が実装できているからです。 同じ機能を、時空間に限定しないあらゆる配列添字について拡張すること こそが、我々がなすべきことではないでしょうか。
現在検討しているのは以下の2本だてです。
これらは選択されるべきだし、意味による対応作戦は メタデータの誤りなどで失敗しうるので、意味による対応が失敗したら外延的対応を 試みるというのもありかもしれません。
実装は可視化構造の Fortran による表現を作成した。
自己記述性によるメタデータ管理の省力化を検証するためには、今後各種デー タ処理におけるメタデータの自動処理実験が必要である。
