XMDB meeting 2003/02/10 配付資料１＝XMDB全体像 by Marc 配付資料2（日本語） 今日のテーマ メタデータの標準形を決める。 次週までに被験者にやってもらって発表。 その次の週、Topping先生の前で発表 3月初旬Marc氏来日 彼らのノウハウをふまえて、DRSでのやりかたを考えていく 彼らのやり方にそのまま従うわけではなく、こちらから提案していくというスタンスをとる。 論文だけを包括していない。全体的なXMDB像。そのための情報源（データ）の一覧を示した。それ以外に当てはまるものもあるのではないか。適宜修正を加えていきたい。 19項目挙げたデータを一つ一つ議論していく。 その過程でマニュアルを作成してしまう。 川方： なんでDBが必要なのか？という疑問がある。 今まで、卒業生が出ていくと、その人が作ったデータが使えなくなってしまう、という現実があった。 自分たちのためというよりは、後輩のために残していく。 人の論文を見たときに、生データがあればいろんな解析ができる、と思うことがよくある。DRSの中でもそのようなことが起こるのはおかしい。論文そのものと、そこに使われたデータを残していった方がいい。それを最終的には外の人にも見てもらう。公開して、参照してもらう。学生側から自分たちが使いやすいデータベースはどういうものか、というのを出してほしい。労力を極力少なく、なおかつ使えるデータベース構築のために、メタデータを作成していきたい。 何を目指すか、何をしたらいいか、という質問をまず出してほしい。 高島： 単純にデータを検索できるようになったらいい。検索するときにちゃんと引っかかってほしいというのがあるけど、どこまで丁寧なdescriptionを書くか、が問題になるのではないか。Subject、descriptionなど。どのくらいの手間をかけるか。 浦川： 今の時点では、それをどこまで、というのがわからない。だから、とりあえず、みんなにばっとやってもらって、どのくらいのボリュームになるのか確かめてもらって、フィードバックしてもらう。 後藤： 修論生は、試し？ 浦川： そう。一つのプロセス。 川方： M2と一緒にディスカッションしていていくのは非現実的。こちらが提案したマニュアルがうまくいくかのテストをかねる。 浦川： 今回の成果が、Marcが来たときに提供できる材料になる。 川方： これまではトップダウン。 これからは自分たち主体でやっていく必要がある。良いデータベースを作るという水準の問題もあるが、検索システムそのものがしっかりしている、という水準もある。メタデータがぎりぎりのもので、検索システムがしっかりしていればそれで良い。自分たちが提供できるものを、Marcたちに提供することは必要。今日のミーティングはその過程。こちらがメタデータを作成して、彼らのシステムに載せるという方法もあるが、それは受動的。こちらが言うことに対して、彼らがどういう反応を示すか。 浦川： Marcたちが来る位置づけは理解浸透している？ No.. 高島： XMDBはもっとすごいものを想像していた。だからリストがちょっと貧弱に感じる。 浦川： 実際に検索してみると、難しい結果は返ってこない。いわゆるマルチメディアデータベース。その実際の例が、RedlandsによるXMDB。商標登録もされている。そのノウハウを何とか取り込みたい、というのが最初の動機。彼らも、自分たちの環境（ハードウェア）を挙げてはいるが、それが必要、というわけではない。基本原則は、今ある環境を利用する。XMDBのRedlands版を、DRS版にローカライゼーションしないといけない。 川方： XMDBシステム全体のイメージ データベースサーバーがまず中心にある。 学生のディレクトリとして、使ったデータをおく場所と、ゴミディレクトリに分かれる。その中で、外に公開しても良いデータと、中だけで使う者に分かれる。ありとあらゆるデータが理路整然と並んでいる。 アプリケーションサーバ：カタログを作成してくれる。データベースとのつなぎ ウェブサーバ：ユーザが検索を欠けたらwebベースで返事が返る。そしてDBからデータを取り出せる。あるいは画像だけ、とか。それはデータ別に考える。 そのような３段が前のサーバ。 イントラでもインターネットでも、とにかくwebサーバを介して利用するほうが、結局使いやすいのではないか。どこに行っても使える、という形がいい。 メタデータを考えるのが先なのか、システムの構成を考えるのが先なのか。 浦川：平行でしょう。 浦川：webサーバは既存の者を使おうとしている。 川方：drsmapというArcIMSが入っているサーバを使う予定。アプリ＆データベースサーバは新規購入。先のソフトの部分を同使うかはmarcたちに相談。 こちらからこんな検索システムを使いたい、という提案がないと、向こうも答えようがない。 浦川： メタの標準を決めたら、それに引っかかってくる。 川方： メタデータはアプリサーバに入る？ 浦川： DBサーバだと思います。 高島： システムのことをここで議論する？ 川方： 細かいことはしない。 むしろ概念的なこと。 樋本： データベースシステムを作って、引っかかってくる者が、wordやexcelなど、紙ベースで残っている者なら、システムの必要性はないのではないか。 川方： 論文を書くために使ったデータがいくつかある。解析前の元データもある。それらの関連性を示すためには、namazu型の検索システムでは検索できない。その論文の元データを見つけたい、という要求を満たすためには、何らかの関連づけをつけなければいけない、と思う。 浦川： もっと大きな野望。論文だけじゃなく、ビデオ画像とか・・・。 川方： そこは付加的な部分と理解してるけど・・・。 火災のシミュレーションをするときに、地理情報を使う。何らかの町データが必要。どういう式を使うか、というのは論文に書かれている。 一つの論文で使った式を、他の論文で使う可能性がある。 一箇所にしか、コードに関するものしかおけない。 ハイパーリンクで一応実現できるけど。。 外から見てもらうことを考えるときに、関連づけをしっかりする必要がある。個々のプログラムが何を計算するための者かわかった方がいい。 Googleで検索したときに、中身を見てみないとわからないといけない者がたくさんある。それが、中身が少しでもわかると良い。 メタデータがあれば、そう言うことがわかるようになる。どこにあるか？公開しているか？など。 高島： 一つ一つ説明してもらって、それをつぶしていきましょう。 浦川： それでは、情報源の説明をしていきます。 このリストは私が考えた者で、これじゃ足りないとか、これ要らないとかそう言う意見を出してほしい。その過程がマニュアルになると思ってください。 全デジタルデータに対応するものが15番目まで。 それ以降は、空間情報に特殊なもの。 このように、空間情報以外にも足していくべきデータ（よく使うもの）があれば、追加していかなければならない。 1番＝タイトル、単純に書く。 ２番＝ファイル名、英語表記にする。 ３番＝クリエータ、作成者。DRS※※研究室、とかにする。 ４番＝サブジェクト、キーワード等 ５番＝キーワードを含むような要約を書く ６番＝情報源の発行元。研究室名で統一しても良い ７番＝contributor。自治体と研究した場合は守秘義務など、共同研究ならその組織など、 ８番＝date作成日。有効期日。利用可能日。正式発行日。更新日。 ９番＝type。DRSの中でのカテゴリ １０番＝format　*.doc、CD・FD等 １１番＝source　元データを記載。２次加工したものが自分のデータになっている場合 １２番＝language １３番＝rights　通常はDRSになると思う。共同研究などで権利が発生した場合は書く。Contributorと似てくる １４番＝publication　公開可能かどうか １５番＝coverage　情報源の対象範囲 １６番＝relation　階層性を記述。親と子。 ここまでが一般。結構ボリュームある。ただ、削れないものばかりだと思う。 １７番＝raster/vector １８番＝projection １９番＝data scale　重ね合わせることができるかどうか、のため。ラスターは解像度。 これだけで、今考えている全ての情報源をフォローアップできるのではないかと思っている。 後藤： 情報の作成日はデータベースに入力する日？ 浦川： いや、作成した日。だいたいで良い。 高島： descriptionをどこまで詳しく書くか？ 浦川： １個１個つぶしていきましょう。 樋本： どこまでをデータベースにする？ 毎日実験をしていて、論文に使われるデータは５日分だけだとする。そう言うときは、５日分だけDBに載せるのか、あるいは365日分か？ 高島： 副次的に出てくるものも入れるのか？っていうことだよね。 後藤： 津波の数値計算にも言える。 ボツになった計算結果もある。それらを全部入れるのか。 浦川： 研究をした人自身が、判断できないもの？ 樋本 それは決めていただいた方がいい。一人一人ではなかなか判断は難しいのでは。あらかじめ合意形成をしておいて・・ 浦川： 今の段階で、プロセスのこの部分まで、という風に決めるとする。そのあと、変更する、というのはあり？ おそらく過程も含めた全部は要らないと思う。最終形だけじゃなくて、使いそうなデータはどのくらいありそう？それは個人で判断できないだろうか。 樋本： 論文から参照されないデータの中で、価値があるデータがある。 高島： 次もしかしたら論文になるかもしれない、というデータ？ 後藤： そう言うのは結構ある。 ヒアリング行って来た言語データが結構ある。たくさん捨てちゃうのはもったいない。 浦川： 「プロセスの重要な部分は載せましょう」という大まかな決め方じゃ不十分？ 後藤： 言語データは大した量じゃないので、載せるのは難しくないが・・・。 浦川： いろんな分野のいろんな研究がある。その中で、プロセスのどこまで、というのはなかなか決められない。 高島： 今回は論文に出てきたデータだけ載せる？って言うのはどう？いずれ成長させていくつもりではあるが、今回は論文関連のデータだけ。 浦川： 来週まで全部やる必要ない。自分のデータのサンプルだけメタデータ化する。 高島： それなら、各自一本の論文だけ、という風にする？ 浦川： 莫大なデータを使う論文もある。 後藤： このデータは有用かどうかわからない、というグレーゾーンのデータがある。 浦川： グレーゾーンについては、入れる、という形でやってみましょうか。 木村： 図表は対象になる？ 図表を張ったPPT自体を入れることになる？ その図表を作るためのデータは要らない？ 浦川： 図表のためのエクセルファイルも残す 木村： １つのエクセルファイルは100MBくらいある。そこからグラフを数百作成し、その中から数十選ぶ。そのエクセルファイルをそのまま残しても意味がないのではないか？ 浦川： ワークシートとしてのエクセルファイルは、整理された形ではない。メタデータに乗らない形。その中の、調査の生データなど、他の人が使えるデータはない？ 木村： １．兵庫県の守秘義務に反する ２．何度か加工して(spss)いる。何を持ってリソースとするかが難しい。円グラフがリソースとなるのか？その辺の区別が難しい。PPTの絵なら入れれるが・・。 浦川： リソースの問題が出た。 守秘義務ある生データは整理されたものではない。メタデータはつきそうもない。 それを動の越すか？ 川方： KJの生データは、それだけでは使い道を考えるのが難しい。それから得られるものを、アウトプットとすることで良い。たとえば円グラフにしても、数値そのものがしっかりわかるものであればいい。 生データ＝発言そのものに対して、ある種の著作権が絡んでくるから扱いに注意が必要。たとえば、そのデータを使ってDRSの他の人が研究したい、という場合は出せないと言うこと？ 木村： そう。条例でスタンドアローンで使うことが規定されている。 川方： DRSの中でも共有してもいみがないデータは、そもそもDBに載せてもしょうがない。 浦川： 論文の結果から拾える元データがある。それ以外のデータもある。そう言うグレーゾーンにあるデータはどうするか。 後藤： 実験の結果。玉石混合。 浦川： それらのデータは全部要らない、という判断はできないので、検証する形で今はやってみる。 高島： このデータを作るのに、これとこれを使って、、という階層性を表す必要はない？ 階層の概略図 浦川： 今回サンプルでやるときは、必ず必要というものはメタデータを作る。それ以外のグレーゾーンのファイルは、ファイルの量とか、気づいた注意点（やっぱり不可能、とか）を書いてもらうことにしましょう。 Oracleを入れるか入れないかですったもんだしている。本格的なDBソフト。彼らはそれを使っている。Educationの意味もあって、入れようかと思ってる。 木村： *印についての決まり事はある？ 浦川： *印は今の段階でのオススメ。それも議論していきたい。 それじゃ、一つ一つつぶしていきましょう １． title＝情報源を表現する ２． File name＝今のまま入れても良い。無理矢理自分の名前などを付加する必要はなし。英語で書いてあればいい。プログラムとかで日本語名しかダメという場合があるかもしれないが、そのときに考える ３． Creator＝所属と人は人物データベースにしておいて、ここはシンプルに名前だけにする。 ４． Subject＝キーワードはどのくらい、どのレベルで書くか。 樋本：手間的には、ひとまとまりにキーワードをつけたほうが良いのではないか 浦川：それだと、更に複雑なDBを設計する必要が出てくる。 樋本：検査くじにヒットするのは最終的なアウトプットだけ。それから中間データがヒットしてくればいい 高島：同じフォルダのキーワードは、そのフォルダのキーワードを継承すればいいのではないか。 浦川：たとえば、じぶんの研究でのフォルダの階層と、他の人の研究のフォルダの階層が違うことが往々にしてある。それをどうするか。 高島：フォルダ名をキーワードにするとか。復旧というフォルダに入っているデータは、全てに復旧、というキーワードがついているとする。 樋本：DBに載せるデータは最終形だけにして、その親データがヒットしたら子データが出てくる、というシンプルな設計が良いのではないか。 浦川：関連する子データも記載していく、ということ？ 樋本：いや、フォルダの中をのぞいてもらって、子データは検索でヒットしない。親データとしては、論文集とか修論とか、大きなデータだけを載せるようにする。 浦川：それだとデータの量として少なくない？ 樋本：しかし子データがヒットしてもあまり役に立たないのでは？ 浦川：たとえばマップを例にしたら、行政かいでヒットしたら、それは別に役に立つ可能性がある 樋本：空間データ、実験データ、プログラムデータとか分けてしまって、その一つ一つに対してデータの分け方を定義していく方がいいのでは 浦川：今のはこれまでの方法を根底から覆す方法。これまではある項目を用意して、それからは乱すものは付け足す、ということ。樋本君のは、それぞれのデータに対して項目を作る、ということ。 高島：パスがデータを定義する構造として機能する。それらのフォルダ名がキーワードとして使えるのではないか。 浦川：それだと、ユーザーを限定した使い方になっているのではないか。 高島：地図とか行政かいとかは名前が付けやすい。「加工中」とかは本人しかわからない。項目を分けなくても、パスによって定義していけばいいのでは？子データに対しては、親データを参照するように書いて、いちいち子データにメタデータをつけなくても良いのではないか。 浦川：親データというのが、どこまでのものを親データにするか。論文だけだと絞られすぎ。 樋本：それでも結構な数になる。 高島：全文は基本的にフラット。しかし、階層的である。子データに、１個上は何、という情報を付け加える。ある程度まとまっているものを持っているのであれば、それをスクリプトで読むことも可能なのではないか。 浦川：今フォルダでまとまったデータを持っているときに、フォルダ名でキーワードになる？ 高島：たとえば、樋本君のシステムをこちらに取り込むのはそんなに難しくないと思う。トップのデータだけメタデータを提供してくれればいい。１個１個に全部詳しく書かなくても、親に書いたやつを継承しています、という形のほうが、全部に対してメタデータを記入する必要はなくなる。 浦川：それに対応しないものは１個１個書いていくと。統一した形式で行って、継承できないものはそれぞれ別の形式を用意する。ダブルで。結構高度な気がする。 樋本：親データを検索して、フォルダの中の子データを一覧できれば便利。 高島：キーワードづけに関してはできる。 浦川：ふたつ、別々の方法でやってみる。検証の期間があるから。 あるデータに関しては、６個もかけなかったりする。 論文とか、親だけに書いておいて、子データは、フォルダに入れておく。 データ検索機能があればよい。 ちゃんと、ひっかかってくれる。 メタデータマニュアルをつくる で、そのマニュアルに沿って、試してみる。 マークにアドバイスをもらう。 受動的に答える形よりも、自分ら主体でやっていく。 良いメタデータがある→水準高い。 検索しやすい→水準高い 自分たちで出せるものを、まずのたたき台のようにして、出す。 立派なメタデータを作って、相手のにのせるというのは、受動的である。 こんなメタデータしか載せれないけど、こんな検索をしたいという。 そこにたいして、どういう反応を返してくるのか？それを試してみる。 求めるクオリティと出せるパフォーマンスを示す。 Ｒｅｄｌandインスティテュート マルチメディアデータベース。 クロスメディアデータベース（登録商標） そのノウハウを取り込みたい。 今あるもので、なんとかするというのが、基本原則。 データベースサーバ：とりあえず、全部のデータが収まっている。 論文にのせれる、最終的なもののディレクトリ。 とりあえず、ごみだけど、期間限定でおいておくかぁというもの。 そのなかで、外に公開してもいいというディレクトリと、イントラネット内で公開というもの。 アプリケーションサーバ。 カタログを作成してくれるもの。 外とつないでくれるための、カタログシステム。 ユーザー側が何かいえば、返事が返ってくる。 カタログで番地を調べて、サーバーで探してきて、見せる。 データとしてダウンロード？画像だけで見せる？？ カスタマイズすると考える。 データカタログ。受付窓口。 イントラだよといっておきながら、個人のIPアドレスを指定すれば、たとえ外に居ても、そのイントラネットにいるような顔をしてデータにアクセスできる。 メタデータ先？システムの構成を考えるのが先？？ Webサーバーは既存のものを使う。 DRSマップっていう、DNS登録されている、ArcIMSが入っているものを使う。 ハード的にはそろっている。ソフト、アプリケーションはどんなのを使う？ これらは、どんなことをしたいかを明示しないと、向こうも分からないと思う だから、しっかりと決めたい。 メタの標準を決めたら、検索の仕組みに繋がっていく。 データベース作成。 そこで、ひっかかってくるもの。 紙ベースとして、同じものが返ってくると、おおげさなものを作る必要はないのでは？ 大きな枠組みで考えると、論文が一つある。 それを書くためにたくさんのでーたがある。　解析前のデータもある。 それらの関係を調べるのに。ナマズ型の検索では無理。 どこで使われているのだろうという、関連付けみたいなのは、調べられない。 DRS内の動画とかそういうのを、大きく公開する。 一箇所にしか、コードに関するものはおけない。 それを、いろんなところから、参照にする形にする必要がある。 ハイパーリンクは賢くない？ 外からみるにしても、関連付けがしっかりしてて、個々のコードが、何をするためのコードかがちゃんと書かれているのが好ましい。 中を見てみないと分からない、という、Google検索に対して、欲しいデータがすぐ分かる。 メタデータがあれば、拾っていいものかどうかも分かる。 情報源の話 この内容じゃ、網羅できない。 これいらないっていう、ものをいってもらって、ディテイルまで議論していきたい。 ダブリンコアが基本になってる。 デジタルデータになって残せる。 作成日はいる。他は、、、、 publicationは、ダブリンコアにはなかったもの。 情報源の対象範囲。 京都市にかんするものであったら、京都市とかけば、それで検索が出来る。 親を決めて、そのしたの子供をかく。 一つのスクリプトだけじゃわからないし、そのしたのことも書く。 ＊グレーゾーンは、一回目の検証があるから、いれるってことにしておいて、検証する。 図表：ぱわぽとして、いれる。 図表を作るときの、下のデータが、その物自体のものとして、意味があるものかどうかを、判断してみる。 エクセルデータとかは、一つのエクセルデータとして、残す。 エクセルの中に、表がいっぱい入ってる。 そういうのが、散在してると、グラフが出来てる。そのなかから、何百枚のグラフが出てきて、それをパワポして、そのなかから、必要なものを拾いだす。 ワークシート：個人の使いやすいものとして、残している。 これは、メタデータとして書くとしては、かけないものである。 細かいデータとしては書きづらい。 表になる、その前の加工のデータは、必要にならない？ それは難しい。 守秘義務条例違反になる。 リソースは何を持ってリソースとするかが難しい。 KJの生データなんて、残したところで何の意味があるんだ？？ KJをするためにとったデータ。 それをやるためにとったデータは、そのアウトプットが大事。 それが、結果のすべて。 数値そのものが必要？？ 発言そのものに対して、ある種のコピーライトが関連してくる。 DRSのほかのメンバーが、使うといったら、使わせないのであれば、のせない。 アウトプットに関しては、こういうアウトプットならつかっていいかという、確認を相手に確認する。 その後にデータベースに乗せるかどうかを決める。 ＊グレーゾーンを含む形で一度やってみて、それが大量の量になるのかどうかを、一度検証してみる。 グレーになるところは、ファイル数とファイルのサイズを書いてもらう。 関連図。 核になる部分だけは、メタデータを作成してもらう。 名前だけで、どの研究室だったとかどの研究室かが分かるように、人物データベースを作成しておく。 アプリケーション側から見た、よったデータ。 一個のルールはスタンダードとして、設けるべきである。 最初はディレクトリ構造でも良いかと思ったが、それだと、ケーススタディを考えた場合、子供をシェアすることになる。 プログラムであったり、地図であったりとかは、どれだけを、一個のディレクトリにいれるかってのは、難しくなってくる。 ディレクトリ構成をかえるのは、ストレスがたまる。個データ単独はなし。 ちゃんと決めたほうが良い 孫で地図データであれば、一個一個メタデータを載せる必要がある。 あなたの子供は誰ですか？誰ですか？と聞く項目があれば、親子関連が出来る。 Relationとチャイルドがある。 Readmeは、こんなデータで、こんなところに格納されていますっていう、データがある、。 これが、親データについてると考える。 セクションであったり、階層構造であったりそういうものが書いてある。 Readmeそのものが、メタファイル。 カタログされたものが、出てくる。Readmeが出てくる。 それが作れるかどうかを交渉しないといけないけど。 一つの子供から、ずっと親まで捜せる。 そうすると、見る側からすると、このデータを見たら、その頭までずっとみられる。 Creator側は、データを入れるのを忘れた、っていったときは、簡単にいれられる、 親からの家計図がずっとみれる。 親子っていう両腕を持った形式で作っていくほうが良い。 どこからメタをつけるかは、個人の判断。 地図情報は統計情報は、親情報でなくて、これだけのデータをみたいってときは、全体像が見えない。 ある種の個データと考える。子供オンリーってなると、子供にもメタを作らないといけない。 そこは、どう説明するの？ 買ったデータとか、使ってないデータ、単独である。親子関係はない。これらにも、一個一個、同じように、メタデータを作らないといけない。 親子関係を見たいですって行ったときだけ、親子関係がみれる。 ただのデータが、親子である位置づけは、あまり必要じゃない。 子まで表示してくれとかは、オプションにするべき。 子がどのくらいいっぱいあっても、かく。 子という欄に何十個もかく。 親を継承する形。 自動的に継承できたら、完璧。 自動的に更新されて継承される。 一番重要な親をかいておけば、その親のデータが継承される。 で、ここは大事だっていうことをいえば、そのメタデータは反映される。 親のやつが、子に反映される。 第一段階として、そこまでする必要がある？？再構築しなおさないといけない。 中途半端にうまってるものを、あとから、どうあつかうの？？ オプションっていってるばあい、親を引いてきて、 検索で引っかかってきたそれだけにするか、そのいっしん、上下にするか。 主従関係の、詳細関係の検索という形にする。 検索を若干あいまいにする感じ。 復旧って言うその言葉、もろにしかヒットさせないか、それいがいも、あいまいにヒットさせるのか？ 一つのマニュアルにどうやってのせる？？ キーワードにかんしては、子供は、親のキーワードを全部継承すると、検索したときは、すべてヒットしちゃう。 親だけヒットさせるようにする。そして、リレーションを見たら、その子供もヒットする。 親を持たない復旧って行ったら、復旧の一番上しかみれない。それから、その子供を見せろって言えば良い。 親子の認識のないものは、親がないとしているから、親がないときに出てくる。 みんな、最初は子供である。 親を持たない子。子を持たない親じゃない。 キーワードに関しては、親を継承してよければ、空白。何かあれば、書く。 そのまま、継承。継承＋付加。付加じゃなくて、クリアにしてから新しく入力。 雛形が見えてくるのが、１年かかる。 親のメタをひっぱりだせてて、それを修正するって感じにする。 デフォルトが親になればよい。 タイトルは親と子に対して、二ついる。 FileNameは必須でない。 タイトルのところに、メディアのタイトルが来る。 ☆印は、子供の議論。 １・２・８必須 ３〜７必要に応じて ９かえる？議論が必要。分野が地震だけにするのか、基盤データとかもあるし。 タイトルとキーワードの関係は、別個。 地震予測度データって、地震前と地震直後って、使えるやん。 もっと、明瞭な中で検索できるなら、この項目を入れたほうがいいかもしれないってレベル。 DRSの中での位置づけ。 どの分野でのどの研究で使われたのかを見れる。 キーワードはとらえない？ 検索でかからないものをつけるのは意味がない。 検索は全部でかければよい。 カテゴリー検索できたら？？ 現実的に、直接それを表していなくても、何かしらのキーワードを入れたときに、それが引っかかるようにすれば良い。 キーワード検索というよりかは、その研究そのものが、どの分野に入るのかが、分かるようにしたい。 幅が広い。 一つのデータが、いくつかのカテゴリに属しても良い。 最初からカテゴリをなくしてしまう。 マルチカテゴリに入れてもよいということにする。 大きな枠組みを提示することで、キーワードにおおまかなことをいれられなくてすむ。 カテゴリーを階層化？？ いくつも、カテゴリーを選んでも良い。 カテゴリーに関しては、とりあえず、ピックアップしてみたら？？ 防災学辞典とかの目次のなかから、拾ってくるとか？？ 災害別、時系列？？ 時系列はないけど災害別。 複数選択OK いれる人の両親と労力によりけり。 サブジェクトに入れない。 ＋基礎データとする 親を継承するって言って置きながら、基礎データなら、子供は直す。 テキスト・汎用バイナリ formatは固める。fixと自由記述（その他の場合） オートコンプリートみたいな感じ。 ソフト名称 OS選んで、ソフトを選ぶ。 OS（ハイブリッドもあり） ソフト名称、かけるものだけ書く。 書かなかった人に、こう書いたら？っていえる。 OSは必須 windows、mac、unix、ハイブリッド、その他。その他なら、明確に書く。 オプション。 Sourceがいらない 言語：日・英・日／英・その他 情報源が理解できる言語 Descripionは英語があればよい。 業者は書かない 丸秘備考欄が必要 filename英語 タイトル・日英 くりえいたー でぃすくりぷしょん。 コントリビュータ Date西暦で、／／でyyyy/mm/ddで確定 Type日英 formatは、日本語しかない場合は、英語でも書く。 これは、お任せ。 半角英数は必須 日本語オプション 好みにする。拡張子で書きたい人は、何でも書け。 １２が、必須。子データも必須。日本語・英語・日英どちらでも可・その他（半角英数で） データのプロセスに関しては、親切さで書く。これは、イントラネット内での話しなんだし、子に関しては、日本語で書く？？ 英語でも書き換えるなんて、大変。 親データ（親をもたないもの）は、日英・必須 子データに関しては、日本語は書き換えてあげる。それ自体、親切。だから、英語も書き換えるなんて、その人の気持ち次第。 Right必須。子データに関しても、書き換えが必要 親データと子データは違う可能性がある。 論文に関しては、著作権は、個人になる。データは、DRSとかいてもよい。 個人名の方が、責任が生じるから良い。 論文は個人（もしかしたら、出版社もくっつくかもしれない）とする。それ以外は、DRSが普通となるけど、それ以外のものも当然あるので、考える。 研究室をいれるかどうかは、三教授に確認を取っておく。 地域安全学会は確認しておくこと。 Publicationは、イントラ用か、インターネット用なんか？？ 公開・非公開を選ばせる？？ 完全非公開のものは、データすら載せない。 教授の意向 そと・DRS・研究室まで イントラを超えるかどうかの是非を書く。 研究室内の話は、なくす。 Coverage オプション 空間範囲だけ。場所で、検索したいためようのデータ。 場所と時間だけにする？？ 兵庫県にひっかかる？西宮データベース。 阪神っていっても、引っかかる？？阪神だけじゃ、西宮データベースがひっかかってほしい。 趣旨と外れちゃう。 これで検索できる。地名検索ってな感じででも検索できる。 兵庫県南部という書き方じゃなくて、地名で検索できるように、京都府京都市何区という感じで書く？ キーワードもディスクリプションの中にあるとかいう話になりつつある。 しかし、キーワードがディスクリプションの中に入らない場合がある。 単純な統計レベルだと市区町村レベルでかけるのではないか。 災害名とかの方が、キーワードとしては、適切なのかもしれない。 災害名は、正式名称が決まっている。 プルダウン式になっていると、検索しやすい。 兵庫県南部地震でも、阪神・淡路大震災でも、ヒットする。 災害名を書いても、あまり意味がないって話もある。 カバレッジにかんしても、同じことである。 自分のものを自分で検索して、不具合が出たら、考える。 オプションにして、使えなかったら、捨てる。 対象の範囲を、かける人、書きたい人は書く！ Relationを書く。子が親を書く。 タイトルで、明記するか、親なしか。 親なしの場合、”No”と明記。 ない場合には、Noと書けと明記。 Sourceはオプションで復活。 URLと本は、明記する。 タイトルとか、著者、書き方は何でもOK。見て分かればよい。 備考 丸秘事項 このデータはうそだとか、間違ってるとか、そういうのを書く。 空間情報に関しては・・・ まず１７、選択 １８、不明あり。 基図。分かるものに関しては、書く。 １９、ピクセルの解像度。何mX何mとか。 これらのオプションは、座標を持ったもの。 ただスキャナから読み取ったような、JpegとかTiffとかは、これには入らない。 これは、IDEF用とかがあるんじゃない？？ 項目を、人口に冠するとか、こまかいことを、descriptionに書く？？ 使ってるものを、別々。 使ってないものは、自分で探しに行け。 データをもってれば、持ってるほど、負担に感じる。 ばらさずに乗せる。 労力をはたいてやっても、うん十万もの価値がある？？ 求めてくる人は、そこに何が入ってるか、わかってるんじゃない？ 使ってないものには、おいてあるけど、自力でやりなさい。 長い年月を経れば、ばらばらになっていく。 やる段階になって、作る。一度作ったものは、同じメッシュ構造で作って、んで、それを後に継げるようにしてやる。 URLとか、備考欄に乗せておけばいいんじゃない？？ それぞれが、何をもっているか。何を買っているか。 メタを作ったら、それらは全部把握できるんだ。 ばらしてないものに関しては、ほったらかし。 ばらしたものに関しては、それを乗せておく。 それを、研究室間でやれば、二十投資がなくなって、よくなるかも！？ うちは、いくつのソフトウェアを持っているかっていうのも、書いたほうがいいんじゃない？？ ソフトウェアのデータベース化。 川方先生の書庫のデータベース化と応じて、CDもやる。 本とかと同じ扱いとか、HPのアドレスを書いて、打ち出して、んでも、本と同じ扱いにするべきかもしれない。 GISっていう個別のソフトの項目。 ユーザーのレベルを設定していない。 備考 Appendix いるか、入らないかわからないって言う情報も、いれといてほしい。 １７日と１９日に、サンプルを作成 この中の人じゃないと、まずい？ 何も知らない人にやらせてみたい。 １７・１９日の時点で、マニュアル作成。 サンプルメタデータ。マニュアルをもって、つかってくださいという。