| ||||||||
| ||||||||
|
地球環境データを相互に共有し検索することを可能にするためには、すべてのデータを共通の形式で記述するか、複数の形式の間で相互に変換するための規則を定めておく必要がある。そのような標準的な構文形式としてXMLを用いるための研究を進める。
以下の文章は、「ネットワークに基づく分散型地球環境データベースの構築に関する研究開発 最終成果報告書」の記述を抜粋し、その後の変化を反映するように随時アップデートしているものである。
地球環境データを相互に共有し検索することを可能にするためには、すべてのデータを共通の形式で記述するか、複数の形式の間で相互に変換するための規則を定めておく必要がある。このような形式の必要性はかなり以前から繰り返し議論されてはきたが、地球環境データには複数の地球観測衛星、それも異なる機関から打ち上げられた地球観測衛星が含まれることから、実際のところ地球観測衛星のデータフォーマットを統一することさえ部分的にしか実現できていない。また、地球環境データの利用者は、少数の地球環境データを対象として、自分の興味に沿った独自の処理をおこなうことが多いため、他の利用者の利便性までを考慮した統一的な形式定義に対する関心が、あまり高くなかったという事情も否定できない。
しかし、地球環境データを用いた研究が広がりや深みを見せるにつれて、利用者が多くの種類の地球環境データにアクセスする必要性が増しており、複数の地球環境データを検索し、組み合わせ、加工するという作業を支援する統一的なフォーマットに関するニーズも高まりつつある。ゆえに、(1) データに関する記述（メタデータ）を統一すること、(2) 複数の地球環境データを効率的に検索すること、という、二つの作業を支援するための、フォーマットおよびプロトコルの研究が重要な課題となってきた。
このような長年の課題に対して、近年の大きな変化が影響を与えつつある。まず第一の潮流として、XML (Extensible Markup Language) がデータの記述フォーマットとしての存在感を増してきた。XML の利点は、自己記述的(self-describing)なデータを比較的容易に生成処理できることにある。そして少なくとも構文(syntax)のレベルでは、多様なデータを、統一的な形式で記述することができる。さらに、XML文書のためのパーサやコンバータなど、膨大なソフトウェア資産を流用でき、多様なコンピュータ環境における互換性にも優れている。
第二の潮流は、デジタルアース計画や電子政府計画などに端を発する、大規模地理情報空間の構築へと向かう世の中の動きである。すべての地理的情報を統一的な座標系のもとで記述するという大規模なプロジェクトなどの影響により、少なくとも地理的情報の記述に関しては統一的なフォーマットが実現しつつある。これらを背景として、本研究では地球環境データを定義するための言語および操作するための言語を定めることとした。
ここでデータ定義言語は、地球観測データの記述だけではなく、これらを処理して得られる２次データや３次データの記述にも用いる。また処理手順とデータとを関連させて記述することにより、自己記述的な地球環境データを生成できる。また地球環境データから抽出した画像特徴などに関してもデータ定義言語を用いて記述することにより、このメタデータを対象にした地球環境データの検索を統合的におこなうことも可能となる。
一方、データを操作するための言語を設計するには、データを定義するための言語とは異なる設計が必要である。データの操作方法はほとんど無限に存在し、これらをすべて言語仕様に取り込むことは不可能であるから、データ操作方法の形式化から基本的な操作を抽出し、その他の多くの操作を基本操作の組み合わせとして実現する、ということに関する考察が必須である。そこで地球観測衛星データを中心とする地球環境データの検索操作に着目し、このような検索操作に適したデータ操作言語の設計を研究の目的とする。また、そのような検索操作をネットワーク経由で可能とするようなプロトコルについても考察する。
データ定義言語(data definition language)は情報を記述する言語であり、情報の利用の仕方とは独立に、情報を宣言的なデータとして表現するための言語である。一般的にデータ定義言語では、情報内容の記述に加え、情報内容の無矛盾性を保証するための一貫性制約も記述できることが求められる。そして、情報内容を系統的に記述できるような見通しのよい言語を得るためには、対象とする問題領域に関する深く体系的な知識が必要となる。このような知識体系を一般的に構築するのは困難であるため、問題領域ごとの知識体系を反映したデータ定義言語を定め、情報の相互運用性を高めることを目的とするプロジェクトが、近年は活発化してきている。
その背景には、インターネットの普及に伴うデータ交換の活発化と、それを支える技術としてのXMLの登場がある。これまでバラバラなフォーマットで記述されていたデータ定義言語に対して、XMLはその標準的な構文規則を提供する。そのためXMLは、さまざまな分野において独自のマークアップ言語を作り出す動きを加速し、XML構文を用いたマークアップ言語が各分野で一気に花開くこととなった。また、複数のマークアップ言語をXML名前空間を用いて共存させるメカニズムは、既存のマークアップ言語の拡張や相互運用性に優れた新たなマークアップ言語の定義にも有用な仕組みとして活用されている。
ただし当然のことながら、XMLはデータ定義言語の構文を定めるものに過ぎず、これさえ使えばすべての問題が解決する、という万能薬のたぐいではない。したがって、同じ情報内容を同じ要素を用いて（同じ順序で）記述するという約束事を守らなければ、意味を正しく伝達することはできない。実際のところ、以下のような意味に関する本質的な問題は、XMLの枠内では解決することができないのである。
このように、情報内容の選定および語彙の選択に系統的な方法を導入することが困難であるため、データ定義言語は専門家の意見や観点、知識体系の相違を反映し、複数のデータ定義言語が同一あるいは隣接した分野に並立することにもなりやすい。以上の点を考えると、XML自身は意味を扱うわけではなく、むしろ「意味に関する情報を伝達することができる」存在であるとみなすべきであろう。
では、XMLの上で本当に意味を扱うためにはどうすればよいのだろうか。まずは、XML 要素の意味および使い方を厳密に定義すれば、意味を共有できるのではないかとまず最初に考えるだろう。このような試みの代表的なものの一つに、Dublin Core Metadata Initiativeがある。
これは、文書の基本的な要素（Dublin Core Ver 1.1 では15要素）の意味を定義するためのメタデータ記述規則を定めるものであり、図書館における標準化された目録カードの発想に近いものと言える。ただしこの試みは意味定義に特化するものであって、構文定義については対象外としているため、これを記述するための具体的な構文定義として、XML構文によってメタデータを記述するための枠組みであるRDF (Resource Description Framework) が使われることが多くなってきた。
しかし、個々の要素の定義を厳密に定めたとしても、異なる体系の間で意味を共有することはできないし、また要素間の推論規則を定めることもできない。ならば、XMLという構文規則の上に、より深い意味を扱うための推論規則を次々に重ねていき、階層的な構造を用いて意味を扱えばよいのではないか。そんな考えに基づくものがSemantic Webである。Semantic Webに関する活動は多岐にわたるが、その中でも先述のRDFやWebサービス、そして異なる意味体系の間で知識を共有するための仕組みであるオントロジー(ontology)などに関する研究が進みつつある。
データ操作言語(data manipulation language)とは、データの検索や登録など、様々なデータベース操作をサポートするための言語である。データ操作言語は概念スキーマを用いて記述され、データを定義するための言語とは異なるスキーマをもつ。データ操作言語で用意すべき命令とは、情報構造の利用方法やデータベースの成長に伴って変化するため、原理的には無数の命令が必要となり、あらかじめすべての処理命令を特定しておくことはできない。
この種の言語で最大の成功を収めているのはSQL(Structured Query Language)である。これは関係代数という数学的理論を背景とすることが大きな特徴である。また、選択(selection)、射影(projection)、結合(join)などごく少数の演算子の組み合わせで複雑な操作を記述できることも魅力的であり、実際にこの言語は関係データベースの検索には非常に強力である。しかし関係代数の範疇に入らない情報構造に関する検索操作は難しく、特にデータマイニングのように多様な操作の組み合わせからデータを特徴付けるための機能に対しては、関係代数の枠組みが適しているとは必ずしもいえない。
このような問題があることは広く認識されており、それらの問題点に対する関係代数の拡張、新しい数学的構造、あるいはデータ操作に関する新しいスキーマの提案などを目的とする研究は、実際のところレビューするのが難しいくらいに多数存在する。例えばSQL自身にも、SQL/MM(MultiMedia)とよばれる拡張が存在する。また最近では、XML文書への問合せに特化した言語として、XML Queryなどの言語も提案されている。しかしこれらの既存の言語は、我々が地球環境データベースにおいて実現したい機能という観点から分析すれば、必ずしも使いやすいデザインとはなっていない。
地球環境データの定義には、これまでHDF (Hierarchical Data Format)などの画素値配列定義に関する規格、あるいは個別の衛星データのヘッダに含まれる、汎用性の乏しいフォーマットを用いるしかなかった。それに対し、近年のXMLの普及に伴って、地球環境データの定義にむけたマークアップ言語が部分的ではあるが提案されるようになってきている。
ESML (Earth Science Markup Language) は、地球環境データの相互運用性を重視したマークアップ言語であり、異種フォーマットのデータセットを統一的に扱うためのメタデータを提供することを目指している。ESMLファイルはデータファイルの内容、構造、または意味を記述するものである。ESMLスキーマはESMLファイルを生成するための規則を定義する。ESMLファイルはデータファイルの外部に生成されるので、既存のデータファイルを変更することなくESMLを用いることができる。 ESMLのメタデータは以下の３種類からなる。
Geography Markup Language (GML)あるいはG-XMLは、いずれも地理情報を表現するマークアップ言語であり、今後は大規模地理情報基盤において用いられることになると予想される言語である。特にGML(Geography Markup Language)は地理情報の記述言語として、Open GIS Consortium Incを中心に世界の多くの組織が参加する大規模な規格となっているのに対し、G-XML(Geography XML)は主に日本の組織が中心となって規格化したマークアップ言語である。ただし類似した内容をもつマークアップ言語であり、両者の統合も検討されているようである。
例えばG-XML文書は、計量地理空間 (MetricGeospace)、位相地理空間(TopologicalGeospace)、関心地点(POI)、移動体(Mover)、経路(Route)、画像(Picture)、描画スタイル(RenderingRule、 RenderingRuleList)の組合せによって構成されている。これら計量地理空間、位相地理空間、関心地点、移動体、経路、画像及び描画スタイルは、ほかのG-XMLの構造で指定され、さらにその構造は、G-XMLの部品で指定される。また、記述されたG-XML文書データ全体にメタデータ(Metadata)を関連付けることも可能であり、メタデータはG-XMLの部品を用いて指定することができる。
MPEG-7は「マルチメディアコンテンツ記述インタフェース(multimedia contents description interface)」ともよばれ、マルチメディア環境での視覚・聴覚データの記述を可能とするための標準的な技術を確立することを目的としている。MPEG-7は視覚・聴覚データの特徴を、以下のコンテキストで標準化する。
ここで記述定義言語は、DS内のあるいはDS間の空間的、時間的、構造的、概念的な関係を表現できなければならない。またこの言語は、ひとつあるいはそれ以上の記述子と、記述子が記述するデータ間にリンクあるいは参照を張るためのモデルを提供しなければならない。現在のところこの言語の設計は、XML SchemaおよびRDF (Resource Description Framework)に大きく影響されている。
MPEG-7の中で特にマルチメディア情報の記述に用いられる規格はMDS (Multimedia Description Scheme)と名付けられ、その中で映像信号の特性を記述するためのメタデータとしてMPEG-7/Visualが定められている。このメタデータは、領域記述や輪郭線記述のための記述子を提供しており、気象パターンの記述などにも使える可能性はあるが、今のところMPEG-7の画像記述子の記述力は、それほど強力なものではない。
Weather Observation Definition Format (OMF) は、アメリカ海軍の気象用XMLマークアップ言語であり、気象観測レポートという特定の文書を記述することを目的とする言語である。OMFは、地上あるいは海上の気象観測、レーウィンゾンデとパイバル観測を組み合わせた気象観測、そして海温や海流などの海洋プロファイルデータを記述するためのものである。また重大な気象警報や気象予測を記述するための要素も含んでいる。このフォーマットは気象の基礎的な観測データを記述するには適しているが、本研究のように気象衛星画像も含むデータ定義にはそれほど適していない。
データ操作言語ではSQLが突出した地位を占めているが、それ以外にも数えきれないほどの多数の言語が、データ検索というタスクを中心に提案されている。また近年の大きな研究テーマは、XML文書のような木構造のデータや関係モデルのようなリンク構造をもつデータなど、構造をもつデータに対するデータ検索言語の開発である。
SQL(Structured Query Language)は関係データモデル上のデータ操作言語として著名な言語であり、関係データベースにおいては事実上の標準言語となっている。その起源はE.F. Coddが提案した関係論理および関係代数であるが、SQLはこれらの論理および代数を具体的な構文規則によって記述することを可能としている。ただし実用的な側面をより重視して開発したため、関係論理および関係代数に見られる美しい数学的構造は多少犠牲になっている。SQLは誕生以来さまざまな改良を経ており、最近はマルチメディアデータのための検索言語SQL/MMなど、従来のような表形式のデータではない非構造的なデータへも適用範囲を広げている。
SQLの問合せは「何を対象とし(FROM)、どのような条件を満たすもののうち(WHERE)、この属性を示せ(SELECT)」という形で問合せを記述し、このような単純な構造にもかかわらず多様な検索問合せを記述できるという柔軟性が大きな特徴である。その他にもグルーピングのための操作(GROUP BY)や並べ替えのための操作(SORT BY)などの操作もSQLに備わっている。その他の拡張機能までを含めればきわめて実用的かつ確立された言語となってはいるが、実際はSQL では記述できない問合せもよく知られており、決して万能のデータ操作言語ではない。
XML QueryはXML文書に対する問合せ言語であり、XML文書の階層構造の中から問合せの対象となる部分を選び出し、その部分をフィルタリングし、その結果をツリー構造にするという操作を処理できる言語である。これらの処理はFLWR 式とよばれ、FOR節、LET節、WHERE節、RETURN節から成る。構文としてはSQLに類似した構文を持つXQueryと、XML構文を用いるXQueryXとがあり、XMLの普及とともに今後の発展が期待できる言語である。
分散環境においては、データ操作言語によって記述されたメッセージをクライアントとサーバ間で交換するためのプロトコルが必要である。このようなプロトコルに関しても、種々のプロトコルが提案されている。
Web Servicesは分散したコンピュータ資源の間で情報を交換するための標準的なプロトコルを定める試みであり、特にSOAPなどが有名である。これらのプロトコルは、分散した地球環境データベースサーバ間で情報を交換したり、サーバをまたがる検索を実装したり、という部分で必要になるものである。例えば、分散サーバに対するデータ操作言語の問い合わせ要求を、SOAPのメッセージに包んで送信する、といった活用法が考えられる。このようなプロトコルは以前から存在したものであるが、これをXMLやウェブ技術を用いて実現することには、ソフトウェア資産の活用や互換性の確保という点では利点が大きい。
Z39.50は情報検索のためのプロトコルであり、サーバとクライアントの間でメッセージをやりとりするためのフォーマットと手続きを定めたプロトコルである。分散環境におけるデータベースへの問合せと応答という、現在のネットワーク環境における情報検索につながるプロトコルであり、さまざまな検索サービスの利用やその条件の指定などが可能である。最初のバージョンは1984年に文献情報を用途として提案され、最新のバージョンは1995年のものである。このように歴史の古いプロトコルであるため、現在のWeb環境から見ると古さが感じられる部分もあるが、XMLやSOAPを取り入れた拡張ZINGが提案されるなど、最近の変化への対応も進みつつある。
MRML (Multimedia Retrieval Markup Language) は、本研究で構想しているデータ操作言語に近いアイデアに基づくマークアップ言語である。基本的にはマルチメディアデータの検索のための言語であり、検索に必要な操作をマークアップ言語として形式化している点に特徴がある。またネットワーク環境におけるクライアントとサーバ間の通信プロトコルとしての側面も明確に意識されており、ユーザインタフェースとデータベースサーバとを明確に分離することで、マルチメディア検索のための共通基盤を作り出すことを目的としている。このような視点は我々の研究と非常に近いものである。なお問合せの記述にはXML 構文を用いており、その点も我々の研究と共通している。ただし、彼らが提案する言語ではマルチメディア検索の形式化がまだ未成熟であり、直交性に優れた操作を提供することには成功していない。また構造化が不十分なため、操作の指定とパラメータの指定が平坦に入り混じってしまっており、問合せがどのような操作を意図しているのかを読み取りにくい構造となっている。
|