#################################################################
Date: Tue, 11 Jul 2006 19:44:01 +0900
From: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
To: davis-ml@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

堀之内です。

さて、本題です。

webブラウザーで使えるデータのアーカイブ、検索、解析、可視化 ツールに何を求めるかのアイディア調査です。こんなことができれば いいなというのをお寄せください。その前に、考えてる大枠を 書きます：

この枠組みですと、データを探すステージと、探したものを料理する ステージとに分けて考えると良いと思います。ショッピング用web サイトのアナロジーで言えば、欲しい商品を探してカートに入れる までと、カートの一覧表示からcheckoutまでといったとこ。

それぞれについての意見を募集します。「こんな機能が欲しい」 という他に、より具体的に「これこれのデータを扱おうと 思うと、一連の流れとしてこんな風にできると良い」という ＊シナリオ＊ を出していただくのも歓迎です。シナリ オから逆に、望まれる機能や気をつけるべきこと がわかりますので、思いっきり具体的なベタなので いいです。文章でもいいですが、イメージを絵にしたもの を交えて手書きでかいたものの画像やPDFでもいいです。

以下はシナリオでなく、思いつく機能を抽象的に列挙してみた ものです。（RD形式で書いてますので、=, ==, === の順に小見出し になります。） 個人的なメモ書きをそのままなので、わかりにくい かもしれませんが。

思いつく機能列挙

データベース利用機能案

どうやって、データを探したいか

検索結果の表示の仕方

検索結果の選択

発展：サイト横断検索

データ表示・解析機能案

解析可視化メニューの表示

可視化・解析基本可視化メニュー

#################################################################
Date: Mon, 24 Jul 2006 16:32:22 +0900 (JST)
To: davis-ml@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤
From: Yasuhiro Morikawa <morikawa@xxxxxxxxxxx>

森川です

北大の方で, 林, 石渡, 小高, 杉山, 佐々木, 森川あたりで会話した 内容をまとめてみました.

「シナリオ」というほどまとまったものになっていないかもしれませんが, 現 実的に出来そうなこと, やってみたいことは何なのか? という観点からの考察 してみた結果です.

SIGEN ファイルとnetCDF ファイルの同時検索

モデル出力データおよび関連情報の現状は

やって嬉しいと思われることは

SIGEN ファイルの中身・netCDF ファイル中の変数と大域属性 を一回で検索できるようになること.

これならば, ある実験の特定の変数がどこに格納されている かを探すこれまでのやり方

データを格納しているサーバに login, cd してディレクトリツリーの
中をおりていき, less で SIGEN ファイルを確認, ncdump (あるいは
gplist)  で netCDF ファイル中の変数を確認

の手間が軽減できる.

気になっていること・ちょっと考えたことは

上記が簡単にできるのであれば, 更にその先としては

以下のような事も考えても良いかもしれない.

ただし,

画像形式データに関して

やって嬉しいと思われることは

rails やデータベースに直結しかつ実現可能と思われるシナリオは 結局出てこなかった.

北大組で議論をした際, 以下のような話題は出た.

図を並べた web ページの細かな修正が簡単にできると嬉しい

過去の davis ミーティングで何度か紹介されたように, モデルの 出力結果の整理するために, 現状では dcmodel-thum.rb で html を 半自動生成している. dennou にログインして, あるディレクトリまで移動し, コマンド ラインでdcmodel-thum.rb を起動し HTML を出力する という方法である.

現状では, 細かい修正のために 再度サーバにログインして当該ディレクトリまで行って... とする のはかったるい, という不満がある. なので, dcmodel-thum.rb で出力された HTML を Web 上から改変できるよう になると嬉しいかもしれないという意見がでた.

しかし,

データベースを用いた画像の検索に関して

モデル出力結果のたくさんの図をデータベースで早く賢く 検索できるようになると嬉しいだろうが, 使いものになる システムが作れるかどうかはかなり疑問である.

#################################################################
Date: Tue, 25 Jul 2006 00:48:26 +0900
From: Masaki Ishiwatari <momoko@xxxxxxxxxxx>
To: davis-ml@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

石渡です

At Mon, 24 Jul 2006 18:00:59 +0900, Takeshi Horinouchi wrote: > 数値実験の SIGEN ファイルは、どういうふうに作ってるか見たいです。 > いくつか例を流してもらえませんか。

私が作っていた SIGEN ファイルをそのまま下に張り付けてみます. あれだけ SIGEN ファイルと言っておきながら, 実際に作っている のはわずかです. 下の例に関して言うと, それぞれ, 20 個とか 10 個とかディレクトリが並んでいる中で 1 ディレクトリのみに 対して作っていた SIGEN ファイルです.

実験設定はディレクトリ名(SIGEN ファイル名もですが)で 私(=作った本人)にはわかり, (自分にとって)何か忘れてはいけ ないことがある時に SIGEN ファイルを作る, というのが私の 現状です.

同一人物が作ったにも拘らず, SIGEN ファイル名(=ディレクトリ名) の命名ルールも中身の書き方・内容もバラバラですね... しかし 現状はこんなもんです.

ちなみに, 下の例における SIGEN ファイルの名前の付け方は 次のようになってます N06_D0.5_A0.5-0.0 の場合

N : モデルで使用されているスキームの種類を表す(実際には放射スキーム)
06: そのスキームに与えるとあるパラメータの値
D : これまたスキームの種類を表す(実際には熱輸送スキーム)
0.5 : そのスキームに与えるパラメータの値
A0.5-0.0 : モデル与える Albedo という量 2 つの値

S1250_from_S1260f_Tf263_L16_f の場合

S1250: パラメータ S に 1250 という値を与えた
from_S1260f : 初期値は S1260f 実験の結果だ
Tf263 : パラメータ Tf に 263 という値を与えた
L16 : 鉛直方向の層の数は 16 だ
f : 実験の通し番号. 6 番目ということ.

------------------------------------------------------------ 例1 : N06_D0.5_A0.5-0.0.SIGEN Subject: EBM 実験結果 Maintainer: 石渡 正樹 Update: 2005/01/03 Note: 論文で使ったデータ

履歴

2005/01/03 石渡正樹 SIGEN ファイル作成
2006/03/01 石渡正樹 更新

------------------------------------------------------------ 例2: S1250_from_S1260f_Tf263_L16_f.SIGEN Subject: S=1250 の結果. 50000日〜60000日 Maintainer: 石渡 正樹 Update: 2006/01/19 Note: 一番氷が広がった場合.

履歴

2006/01/19 石渡正樹
#################################################################
Date: Tue, 25 Jul 2006 15:35:28 +0900
From: "Seiya Nishizawa" <seiya@xxxxxxxxxxx>
To: "Takeshi Horinouchi" <horinout@xxxxxxxxxxx>
Cc: davis-jst@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

手書きイメージスキャン

西澤です。

今ボーと考えているものをスケッチにしてみました。 堀之内さんの考えているものと、あまり変らないかも知れません。 なかなかアイデアというのは考えても出てこないもので、 ある日突然ひらめいたりするんですよね。

#################################################################
Date: Fri, 28 Jul 2006 13:46:37 +0900
From: "Seiya Nishizawa" <seiya@xxxxxxxxxxx>
To: davis-jst@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

西澤です。

できたらいいな提案 追加案です。

ブラウザだけですべてができるサーバーについてですが、 ユーザー管理機能がほしいなと思います。

基本的にはアカウントが無くても使えますが、 ログインすると、以下をサーバーの各ユーザー領域に登録できるようになります。

1. データ、画像

- 自分の実験データなど

2. 解析スクリプト

- 標準では用意されていない解析用

3. 解析した後の変数や、描画した図

1. 2. は、直接サーバーのしかるべきところにファイルを置くこともできて、 その場合は、しかるべくコマンドでデータベースに登録

登録する際に、以下の選択 1. 非公開

- 自分しか見ることも使うこともできない

2. 説明だけ公開

- 検索には引っ掛かるが、解析や描画ができない

3. 完全公開

さらに、非公開だけれども、 この人には見せてもよい とか グループみたいなのがあって、そのグループには見せてもよい とか ができる。

ユーザー管理は、OSのユーザー管理を使えれば楽かな？ 専用サーバーじゃなければ難しいでしょうが。 アップロードしたファイルも所有者をその人にすればよいし、 パスワード管理もおまかせできる。 グループもすでにあるし。など (よく知りませんが、PAM ってのが使えるのかな？ rubyバインディングもあるみたいですし)

簡単に登録できると、 HDの容量の問題が出てくると思いますが、 そこは quota とか、個々の良識でなんとか。

なんてことを考えています。

#################################################################
Date: Fri, 28 Jul 2006 17:33:58 +0900
From: Masuo NAKANO <masuo@xxxxxxxxxxx>
To: davis-ml@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

なかのです。 ＃みなさんのアイディアとだいぶかぶってますが、、、

北大組のみなさんがいっているように、僕も自分のデータ管理ぐらいだったら、何もwebベースでなくてもよいかなぁと思ってます。 CUIベースの検索だとDebian のapt みたいなのがあればいいなぁと思います。 ただ開発と維持管理コストを考えるとwebオンリーがよいのかもしれません。

以下自分のメモです。

扱うデータ

惑星の上のデータ

　 これらのものは google map なり google earth などと仲良くできる？

　

いろんな形のデータ（箱・線・面・球殻・円柱...etc.）

観測データについてはデータの出どころ、測器のスペックなどは決まっているのでデータが何者であるかを記述するのは楽。 モデル出力はなんらかの説明ファイルが必要であろう(SIGEN, README??)

画像

メタデータ作成

メタデータ流通

データ検索

#################################################################
Date: Fri, 28 Jul 2006 18:56:42 +0900
From: "Seiya Nishizawa" <seiya@xxxxxxxxxxx>
To: "Takeshi Horinouchi" <horinout@xxxxxxxxxxx>
Subject: Re: 情報爆発IT基盤
Cc: davis-jst@xxxxxxxxxxx

西澤です。

06/07/28 に Takeshi Horinouchi<horinout@xxxxxxxxxxx> さんは書きました:

> > ブラウザだけですべてができるサーバーについてですが、 > > ユーザー管理機能がほしいなと思います。 > > > > 基本的にはアカウントが無くても使えますが、 > > ログインすると、以下をサーバーの各ユーザー領域に登録できるようになります。 > > > > 1. データ、画像 > > - 自分の実験データなど > > 2. 解析スクリプト > > - 標準では用意されていない解析用 > > 3. 解析した後の変数や、描画した図 > > > > 1. 2. は、直接サーバーのしかるべきところにファイルを置くこともできて、 > > その場合は、しかるべくコマンドでデータベースに登録 > > よさげですね。 > > さらにブレーンストーミングを膨らますということで、 > どういう風に登録／整理／閲覧できると > いいかというイメージも教えてください。スクリプトは、 > 日付とか、もとのデータとの関連とかで検索できるように > するんですかね。解析後の変数や描画した図はどうでしょう。 > 沢山になってもあまり管理の手間がいらないとか、シリーズで > 簡単にうまく並べられたりするといいような気はしますが。

スクリプトは検索される対称にはいれないと考えていました。 (管理自体はデータベースを使うかも知れませんが)。 登録しておくと、解析の画面で選択肢に付け加わるということでよいと思います。

描画した絵は、絵を保存するのではなく、データと、 描画に必要なパラメータ(もしくはRubyスクリプト)を保存しておいて、 表示が必要なときは絵を作り直すというのがよいかなと思っています。 その描画に必要なデータとRubyスクリプトは、ダウンロード可能にしたいです (検索後、その画像を表示した際に表示される説明のところにダウンロードするためのボタンがついていればよいと思います)。

解析後の変数は、元ファイルとRubyスクリプトではなく、 ファイルに落としてしまった方がよいと思います。 解析には結構時間かかる可能性があるので。

それらには、登録時に、元ファイル等の情報がデフォルトでつく他、 登録する人が、自由にキーワードを追加できるといいと思います。 それを元に検索すれば、 シリーズまとめて探し出せると思います。 検索後に、一括ならべて表示とかできる ってのはいいですね。

登録は、 1. ユーザーログインページがあって、そこから何を登録するのか選択して登録フォームにいく (スクリプト と データファイル 2. それぞれ適切な場所(解析スクリプトなら選択リストの横、変数なら変数アイコンをクリックしたときにでる？、図なら描画して絵がでた所)から登録フォームにとぶ 3. サーバーにログインして、しかるべき所、にしかるべく置いて、登録用コマンドの実行 くらいを用意しておけばよいと思います。

登録すべき情報は、 データファイルや、解析後の変数、描画した図は、 他のものと同じように検索する必要があるので、 メインのデータベーステーブルの取り決めにのっとった情報＋α(それぞれ固有の情報決めておく)＋登録者が自由に設定できるキーワード みたいにするんでしょうね 検索するときは、NCEPやひまわり画像とかが入っているメインのデータベーステーブル (データと画像のテーブルは別かも知れませんが) と個人が登録したテーブルのどちらに入っているかは関係なく、 同じように検索結果画面にでるようになっているのがよいと思います。 ユーザーには、同じデータベーステーブルに登録しているのと同じように見える、 というか、管理上の問題がなければ同じテーブルに登録できるものを考えています。

たとえば、ある台風シュミレーション実験をし、 そのデータを登録し、このシステムでOLRの図を書いて、 その図を登録する。 その後、実験設定日のその領域を検索すると、 ひまわり画像とその実験結果の図が両方検索されてでてくる。

メインのデータベーステーブルを作る際にちゃんと考えて作る必要がありますが。

なんかだらだらと書き連ねて、 日本語になっていなかったりと、 伝わりづらいとおもいます。 また、イメージが絵にならないので紙にしませんでした。 実際会って、あーだこーだと言った方が伝わると思います。 これを読んで、なんとなくこんなことを考えているのかも、 というのが伝われば幸いです。

#################################################################
From: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
To: "Seiya Nishizawa" <seiya@xxxxxxxxxxx>
Subject: Re: 情報爆発IT基盤
Cc: horinout@xxxxxxxxxxx,
 davis-jst@xxxxxxxxxxx

手書きイメージスキャン

堀之内です。

> 西澤です。 > > 今ボーと考えているものをスケッチにしてみました。 > 堀之内さんの考えているものと、あまり変らないかも知れません。 > なかなかアイデアというのは考えても出てこないもので、 > ある日突然ひらめいたりするんですよね。

考えてることは似てると思いますが、データを収めたディレクトリー 階層をつくる場合を考えてみました。どの道データはディレクトリー 階層に納めるでしょうし、データが少ないうちは検索の必要も あまりないでしょう。SIGEN ファイルをあるディレクトリーに置く場合、 基本的にはそこ以下全部に当てはまることを書くんだと思います。 なので、サブディレクトリーや数値データは、親ディレクトリーの 属性を基本的に継承するという考えです。

添付したのは、データの選択・検索画面イメージです。 きたなくてごめんなさい。

このスケッチを書いてから、データベースに関する要件を考えてみました。 走り書きで整理されてませんが、下につけます。

(メモ： db_requirement.txt 最終更新 2006/07/28)

データベースへの要求事項

#################################################################
From: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
To: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
Subject: Re: 情報爆発IT基盤
Cc: horinout@xxxxxxxxxxx,
 "Seiya Nishizawa" <seiya@xxxxxxxxxxx>,
 davis-jst@xxxxxxxxxxx

手書きイメージスキャン

堀之内です。

西澤君のにもあった時空間情報に関する選択のイメージです。 かなり細かい版。最も簡単なのとしては、時間（期間）で 探せるだけにしても結構役に立つのではないかと思います。

これとは別に、見つかったデータの部分領域を指定する こともできる必要がありますが、かなりの部分が オーバーラップします。

ちなみに live access server も参考にしてます: http://ferret.wrc.noaa.gov/Ferret/LAS/ 実際のサーバー例として上記のページからリンクされている

http://ferret.pmel.noaa.gov/NVODS/servlets/dataset
http://las.pfeg.noaa.gov/las/

があります。 両者のトップの構成がかなり違うあたりが "The Live Access Server (LAS) is a highly configurable Web server..." という所以かと。LAS での緯度経度時間の指定は、 データの検索のためでなく部分領域の指定のためです。

#################################################################
Date: Fri, 28 Jul 2006 21:53:48 +0900
From: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
To: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
Subject: Re: 情報爆発IT基盤
Cc: horinout@xxxxxxxxxxx,
 "Seiya Nishizawa" <seiya@xxxxxxxxxxx>,
 davis-jst@xxxxxxxxxxx

手書きイメージスキャン

堀之内です。

今度は描画ページのイメージです。要は web 版 gave です。 配置とかスタイルは思いつきのいい加減なものです （実装の楽さとか考えてません。そういうことは後で 考えて修正すればいいので）。平均を取ったりの データ操作メニューは別途あって、結果は上の変数一覧 に加わってくものとします。 相変わらずきたなくてすみません。

#################################################################
Date: Tue, 01 Aug 2006 23:41:39 +0900
From: Masaki Ishiwatari <momoko@xxxxxxxxxxx>
To: davis-jst@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

情報爆発関係者の皆様 : 石渡です

At Tue, 11 Jul 2006 20:52:11 +0900, momoko wrote: > 以下, 了解です. > 白状すると, まだ手着かずです. 調査開始します.

更に白状すると未完成です.

ですが, もう直前でもありますし現状を送っておきます. なぐり書きメモの域を出ておりませんが, 当日の議論の もとにして下さい.

我々の最低限標準語彙

既存の枠組

Dublin Core

THREDDS

SPASE

GIS 標準

#################################################################
Date: Wed, 2 Aug 2006 01:01:19 +0900
From: Masuo NAKANO <masuo@xxxxxxxxxxx>
To: davis-jst@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

なかのです。

> ===Dublin Core --snip-- > > * DCMES(15 の要素タイプ) --snip-- > * 使い方(というのも何だが): HTML へ埋め込む方法 > Dublin Core: メタデータを記述するボキャブラリ の例で良かろう.

ぼくもたまたま今日いろいろみていたのですが、 http://www.unidata.ucar.edu/staff/russ/bs/metadata/ なるものをみつけました。 気象モデル出力の例なのでピンとくるかもしれません。 A Dublin Core Exampleの節からリンクが張られてますが

HTML3

http://www.unidata.ucar.edu/staff/russ/bs/metadata/ruc-dc-3.html

HTML4

http://www.unidata.ucar.edu/staff/russ/bs/metadata/ruc-dc-4.html

RDF

http://www.unidata.ucar.edu/staff/russ/bs/metadata/ruc-rdf.html

での記述例が示されてます。

#################################################################
Date: Wed, 02 Aug 2006 01:27:40 +0900
From: Masaki Ishiwatari <momoko@xxxxxxxxxxx>
To: davis-ml@xxxxxxxxxxx
Subject: Re: 情報爆発IT基盤

石渡です

At Tue, 25 Jul 2006 00:48:26 +0900, momoko wrote: > > 数値実験の SIGEN ファイルは、どういうふうに作ってるか見たいです。 > > いくつか例を流してもらえませんか。 > > 私が作っていた SIGEN ファイルをそのまま下に張り付けてみます. > …

これまた遅くなってすいません. 森川君の SIGEN ファイルも もらいましたのでこのメールの下にコピーしておきます.

なお, SIGEN ファイルとはなんぞや? という説明を全然して いなくてすいません. SIGEN ファイルは dennou サーバの /GFD_Dennou_Club/ 領域以下のディレクトリ・ファイル管理 に使っている形式です. 例えば, 

http://dennou-k.gfd-dennou.org/arch/davis/SIGEN.htm

では, davis というディレクトリに格納されているサブディレ クトリおよびファイルの一覧とその説明が並んでいます. この HTML ファイルは各ディレクトリ・ファイルに対して作成した SIGEN ファイルをもとに mksigen という perl script で自動 生成したものです. mksigen は毎日 cron で起動します. mksigen は現在は気象庁におられる豊田英司さんの作品です.

これが本来の SIGEN ファイルの目的で, データや図に関しても そのまま流用しているわけです. 普段 dennou サーバに各種資源 を置く時に作成している SIGEN ファイルと全く同じものを使う ことに我々的なメリットがあります. つまり扱う書式は 1 つで 良い.

===== 「本来の」 SIGEN ファイルの例 : i-explosion.SIGEN ===== Subject: 情報爆発IT基盤プロジェクト関連資源 Maintainer: 堀之内 武 Update: 2006/07/11

履歴

2006/07/11 堀之内 武  新規作成

===== mksigen スクリプトの man ページから抜粋 =====

説明

     地球流体電脳倶楽部の資源にはすべて説明ファイルをつけます。その
     ファイル名は資源本体 (ファイルまたはディレクトリ) の名前に 
     .SIGEN という接尾 辞をつけたものです。ファイルの字句的形式はイ
     ンターネットの電子メールに類似しています。

     ここでは有効なフィールド名について説明します。これ以外のフィー
     ルドは無視されます。

フィールド

   必須
     Subject:
            資源の題名をあらわします。

     Maintainer:
            資源提供者をあらわします。

     Update:
            資源が更新された日付をあらわします。 Subject: や Maintainer: は
            この時点で妥当なものでなければなりません。

   あってもなくてもよいもの
     Prune: このフィールドが存在し、かつ値が空でも "0" でもない場合 (ただ し
            "1"  を用いることを推奨します)、 mksigen(8) は対応する資源本体が
            ディレクトリであってもその内部の資源を探索しません。

     Description:
            資源に関するより詳細な説明です。

     Note:  資源の取扱などに対する注意を記入します。

テキストフィールドの扱い
     Description: フィールドと Note: フィールドに書かれた文字列は基本的に は
     そのまま SIGEN.htm に出力されます。 HTML ではクォートしなければならない
     <, >, ", & もそのまま出力されますので注意してください。

     例外として relative:relative_url で始まる語と <URL:url> の形式の文字 列
     が ハイパーリンクに変換されます。前者は資源ファイルのあるディレクトリ (
     資源がディレクトリの場合そのディレクトリも探索されます) からの相対  URL
     と 解釈されます。もしファイルが見付からない場合はリンクは張られません。
     後者は自動的にハイパーリンクに変換されるので相対パスを書く場合には注 意
     してください。また <URL:file:path> のようにファイルプロトコルの参照をし
     ても http 経由では見られないので、 http に乗らないものだけをファイル プ
     ロトコルで参照してください。

例
     あるディレクトリの説明ファイル:
            Subject: 地球流体理論マニュアル
            Maintainer: 林 祥介
            Update: 1998/03/16
            Note: 目次は relative:index.htm である
            Prune: 0
            Description: 資源に関する詳細な説明です.

===== 森川君の SIGEN ファイル: 2005-02-14_morikawa.SIGEN ===== Subject: Held and Suarez (1994) 実験結果 Maintainer: 森川 靖大 Description: Held and Suarez (1994) 実験の目次. および実験結果.

実験結果の詳細は, 
解像度 T42L20. 1250 日積分. 初期温度場 300 K.
システム 'Linux leaf.ep.sci.hokudai.ac.jp 2.4.20-31.9smp #1 SMP Tue Apr 13 17:40:10 EDT 2004 i686 i686 i386 GNU/Linux' (by uname -a).
Fortranコンパイラ Fujitsu Fortran 4.0.

Note: Update: 2005/07/07 実験に関する情報の詳細を追加

履歴

2005/03/16  森川 靖大  新規作成
2005/07/07  森川 靖大  実験に関する情報の詳細を追加

===== 森川君の SIGEN ファイル: 2005-06-23_morikawa.SIGEN ===== Subject: Held and Suarez (1994) 実験結果 Maintainer: 森川 靖大 Description: 解像度 T21L20. 1250 日積分. 初期温度場 300 K.

システム 'SUPER-UX unix 12.1  SX-6' (by uname -a).
Fortranコンパイラ FORTRAN90/SX.

Note: Update: 2005/06/27

履歴

2005/06/27  森川 靖大

===== 森川君の SIGEN ファイル: 2005-06-27_morikawa.SIGEN ===== Subject: Held and Suarez (1994) 実験結果 Maintainer: 森川 靖大 Description: 解像度 T42L20. 1250 日積分. 初期温度場 300 K.

システム 'SUPER-UX unix 12.1  SX-6' (by uname -a).
Fortranコンパイラ FORTRAN90/SX.

Note: Update: 2005/06/27

履歴

2005/06/27  森川 靖大

===== 森川君の SIGEN ファイル: 2005-07-08_morikawa.SIGEN ===== Subject: Held and Suarez (1994) 実験結果 Maintainer: 森川 靖大 Description: 解像度 T63L20. 1200 日積分. 初期温度場 300 K.

システム 'SUPER-UX unix 12.1  SX-6' (by uname -a).
Fortranコンパイラ FORTRAN90/SX.

Note: Update: 2005/07/08

履歴

2005/07/08  森川 靖大

===== 森川君の SIGEN ファイル: 2005-07-11_morikawa.SIGEN ===== Subject: Held and Suarez (1994) 実験結果 Maintainer: 森川 靖大 Description: 解像度 T63L20. 1200 日積分. 初期温度場 250 K.

システム 'SUPER-UX unix 12.1  SX-6' (by uname -a).
Fortranコンパイラ FORTRAN90/SX.

Note: Update: 2005/07/08

履歴

2005/07/08  森川 靖大

===== 森川君の SIGEN ファイル: HS94_T21L20_TempIni300_SX6.htm.SIGEN ===== Subject: DCPAM: Held and Suarez(1994): T42L20 Maintainer: 森川 靖大 Description: relative:thum_src/HS94_T21L20_TempIni300_SX6.rb と

relative:thum_src/HS94_T21L20_TempIni300_SX6.txt
により自動生成

Note: この SIGEN ファイル自体も

relative:thum_src/HS94_T21L20_TempIni300_SX6.rb
からの自動生成である

Update: 2005/07/08 自動生成

===== 森川君の SIGEN ファイル: HS94_T63L20_TempIni250_SX6.htm.SIGEN ===== Subject: DCPAM: Held and Suarez(1994): T63L20 Maintainer: 森川 靖大 Description: relative:thum_src/HS94_T63L20_TempIni250_SX6.rb と

relative:thum_src/HS94_T63L20_TempIni250_SX6.txt
により自動生成

Note: この SIGEN ファイル自体も

relative:thum_src/HS94_T63L20_TempIni250_SX6.rb
からの自動生成である

Update: 2005/07/11 自動生成

#################################################################
Date: Wed, 02 Aug 2006 02:33:27 +0900
From: Takeshi Horinouchi <horinout@xxxxxxxxxxx>
To: Masaki Ishiwatari <momoko@xxxxxxxxxxx>
Subject: Re: 情報爆発IT基盤
Cc: horinout@xxxxxxxxxxx,
 davis-jst@xxxxxxxxxxx

石渡さん

> ですが, もう直前でもありますし現状を送っておきます. > なぐり書きメモの域を出ておりませんが, 当日の議論の > もとにして下さい.

メモを有難うございます！！ 議論のたたき台としては 十分じゃないかと思います。

そのあとの SIGEN に関するメールもありがとうございました。

> * 上記資源達を束ねたものを 1 つのリソースと考えると > 専用の語彙を用意しなければならない最低限セットは > 名前(リソース名) > 場所(具体的にはフルパス) > 説明(あまたの付随情報. SIGEN ファイルの中身そのものかもしれない) > 語彙集の名前 (独自路線でいくなら) > であるような気がする. > > 上記の他にも, netCDF ファイルの大域属性の一部や変数リスト > を入れても良いかもしれないが, 実装(どこまで立派なものを作るか)に > 大きく依存. また変数リストのための語彙は必要ないように思われる. > 「変数リストを出せ」というリクエストに対してリストを調べて > その結果をそのまま返す, ということにするなら語彙は介在しない. > 逆に, 変数リストまでデータベースに突っ込むことにすると > (実用上はニーズが高いのだろうが), > データ形式(netCDF) > 変数名 > 変数に関する説明 > … > と, 用意しなければならない語彙が雪ダルマ式に増える.

おっしゃるとおり、どのような語彙が必要かは、何をしたいかに よりますね。より具体的には、データ検索、データ解析＆可視化、 データアクセス／配布の諸サービスにどのような機能を求めるか ですね。例えば DODS アクセスができるようにしたいなら、 何からの方法で DODS URL を調べることができるように、 なってる必要があります。多くの場合、トップディレクトリ に対応する DODS url がわかれば十分なので、例えばトップ の SIGEN （的な）ファイル一箇所に書けば済むわけですが、 どういう名前をつけて書くかは決めないとなりません。

当日は、このように機能面から何が必要か考えてみませんか。 ただ、ご指摘のように、標準的な語彙はなるべく少なくするの が肝要と思います。膨れると使いこなすのが大変ですから。あと、 標準化されたものでも、できるだけ必須化しないのも肝要でしょう。上の例 では、例えば dods_url というようなキーワードを用意することになる でしょうが、dods によるサービスをしない限り、そもそも使う必要すら ありません。

> * 名前, 場所, 説明に対するキーワードに対するキーワードとして, > 既存(DC, THREDDS, CF 規約, gtool4 規約) > のものをどれか 1 つそのまま流用するなら, THREDDS のカタログを > 使う, ということになってしまいそう. > 名前 : catalog element の name 属性 > 場所 : service element の base, urlPath 属性 > 説明 : documentation element > > * しかし, 気になる点がいくつか. > * DC でも THREDDS でも既存の枠組をそのまま使うという > ことは, 可能は可能. > が, これらをそのまま使うだけでも大変である. 全体像を把握する > だけでも大変(平たく言えば, 勉強したくない). > 当面は全体像を把握する必要はなかろうが, 実際にそっちに向けて > 動き出したらそうはいかんだろう. > > * 我々は既に, CF 規約だか gtool4 規約だかの netCDF ファイル > に関する体系と SIGEN というディレクトリ・ファイルに関する > システムを持っている. キーワードはなるべくそれらから > とり無いものは新たに策定するという路線(つまり独自路線) > が, 結果的にはコストパフォーマンスが高かった, なあんて > 可能性はそんなに低くないかもという気がする. > 要するに, 「似て非なる語彙セットを 3 つも 4 つも持つのは > いかがなものか」ということ.

SIGEN の語彙セットが使えるようにはしたほうがいいでしょうね。 ただ、世界標準という意味では DC は意識すべきと思いますので、DC と SIGEN で同じものを別名で表してるのがあれば、対応は把握すべきと思います。 また、対応がわかれば、必要に応じて DB 化ツールに読み替えを任せられる ので便利でもあります。なお、THREDDS や SPASE は、従う「必要」までは全然なく、「無いものは新たに策定する」ための 参考に利用するのが賢いやりかたではないかと思います。（そのために 一通りサーベイしておきたいという目標は、石渡さんのメモで達せられた と思います。）

ということで、有難うございました。

#################################################################
#################################################################