(57)【特許請求の範囲】
【請求項１】
XMLデータから、当該XMLデータの属性に対応する葉ノードあるいは非葉ノードと、前記ノード間の親子関係を表す枝とを含み、ノード間の冗長な親子関係をマージして最適化したツリー構造である階層ユニットツリーを生成する階層ユニットツリー生成部と、処理部と、表示部と、入力部とを有する処理システムを用いたデータマイニングにおける前処理方法であって、
前記処理システムは、
入力されたXMLデータから前記階層ユニットツリー生成部によって生成した階層ユニットツリーを前記表示部に画面表示するステップ、
前記表示部に表示された階層ユニットツリーに適用するフィルタを前記入力部から入力させるステップ、
前記入力部から入力されたフィルタの適用によって変更された階層ユニットツリーを前記表示部に表示するステップ、
前記入力されたXMLデータに、前記階層ユニットツリーに適用したフィルタに対応するXML用フィルタを適用するステップ、
を実行するデータマイニングにおける前処理方法。
【請求項２】
請求項１記載のデータマイニングにおける前処理方法において、前記階層ユニットツリーに変更を加えるフィルタには、同じ非葉ノードを親に持つ複数のノードを、当該複数のノードと同じ階層に新規に作成するノードの子ノードとするフィルタが含まれることを特徴とするデータマイニングにおける前処理方法。
【請求項３】
請求項１記載のデータマイニングにおける前処理方法において、前記階層ユニットツリーに変更を加えるフィルタには、指定したノードを当該ノードの現在の親とは別のノードの子の位置に移動するフィルタが含まれることを特徴とするデータマイニングにおける前処理方法。
【請求項４】
請求項３記載のデータマイニングにおける前処理方法において、前記指定したノードを当該ノードの現在の親とは別のノードの子の位置に移動するフィルタは、前記表示部の画面表示上で前記指定したノードをマウスによってドラッグし、新しく親となるノードの上にドロップする操作によって実行されることを特徴とするデータマイニングにおける前処理方法。
【請求項５】
請求項１記載のデータマイニングにおける前処理方法において、前記階層ユニットツリーに変更を加えるフィルタには、同じ非葉ノードを親に持つ複数のノードの属性名を同一の属性名に変更し、前記複数のノードをマージするフィルタが含まれることを特徴とするデータマイニングにおける前処理方法。
【請求項６】
請求項１〜５のいずれか１項記載のデータマイニングにおける前処理方法において、前記階層ユニットツリーに対する変更履歴を表示するとともに前記フィルタによって変更された階層ユニットツリーをそれぞれ記録し、前記表示された変更履歴の所定の変更段階を指定したとき当該変更段階に対応する階層ユニットツリーを表示することを特徴とするデータマイニングにおける前処理方法。
【請求項７】
XMLデータを入力するデータ入力部と、
入力されたXMLデータから、当該XMLデータの属性に対応する葉ノードあるいは非葉ノードと、前記ノード間の親子関係を表す枝とを含み、ノード間の冗長な親子関係をマージして最適化したツリー構造である階層ユニットツリーを生成する階層ユニットツリー生成部と、
前記階層ユニットツリーに変更を加えるためのフィルタを選択するためのフィルタ選択部と、
前記階層ユニットツリーを表示する表示部と、
処理部とを備え、
前記処理部は、前記フィルタ選択部で選択された前記階層ユニットツリーに変更を加えるためのフィルタに対応するXML用フィルタを前記入力されたXMLデータに適用する処理を行うことを特徴とするデータマイニングにおける前処理システム。
【請求項８】
請求項７記載のデータマイニングにおける前処理システムにおいて、前記階層ユニットツリーに適用したフィルタの履歴を表示する履歴表示部を備えることを特徴とするデータマイニングにおける前処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、大規模データの解析における前処理方法及び前処理システムに関する。
【０００２】
【従来の技術】
近年、ヒトの全遺伝子情報が明らかになったことに伴い、ヒトを始めとする各種生物のゲノム解析プロジェクトに用いている膨大な配列情報や実験データあるいは文献情報などが蓄積されている。今後は、配列だけでなく遺伝子機能を解明することで、疾病診断、医薬品開発など、個人の遺伝子を対象とした医療が可能となる。既に一部の医療機関では、遺伝子診断システムやDNAチップなどの遺伝子解析技術を用いた個人別の遺伝子解析が始まっており、広範囲な新規産業への利用も期待されている。
【０００３】
遺伝子に関する統合データベースシステムから遺伝子機能を解明するなど、大量のデータの中から人間にとって有用な知識を獲得する作業をデータマイニングと呼ぶ。以前からデータマイニングを行うための解析アルゴリズムとして、相関ルール、決定木、クラスタリング、ニューラルネットワーク、遺伝アルゴリズムなどが研究されている。これらの方法は、どれも一定の評価を得ており、有用なアルゴリズムとして認知されている。しかし、実際に大量に蓄積されているデータをそのまま各解析アルゴリズムに適用できるかというと、それはほぼ不可能といっていい。RDBMSに格納されているデータに、解析アルゴリズムは直接アクセスできないかもしれない。また、必要なデータ構造は異なるだろうし、そもそもデータは期待しているほど正常なものではないかもしれない。データマイニングにおける、これら前処理にかかるコストは、全プロセス中の60%を占めているとも言われている。
【０００４】
前処理が全プロセスの中でどの範囲を指すかについては、まだ標準的な見解はないため、様々な形態で前処理が研究されている。データベースではSQLを代表とする問い合わせ言語を駆使してデータを操作する。同様にXML（http://www.w3.org/XML/）においても問い合わせ言語を用いたデータの操作を実現しようと多様な研究がなされている。これらはデータの操作のための手段を提供することが目的であり、操作自体を自動化するものではない。XMLの有用性については諸分野で認識されており、例えばバイオインフォマティクスの分野でも、XMLは自己記述的であるためにそれ自体の持つ意味的表現力は低いが、その文法の持つ記述力、構造の確かさ、扱いやすさ、普及度などからオントロジーはXMLによって記述されていくだろうという評価を得ている。
【０００５】
ツリー構造をナビゲートする方法については、IBMなどから提案されているツール（特開2000-194466号公報）があり、このツールは、オブジェクトツリーに関して、ナビゲーションにおける非葉ノードへの移動の際に、移動点からツリー構造のルートへのパスと、移動点の完全なサブツリーのみを表示するというものである。この方法は、非対称で複雑な構造を取るオブジェクトツリーから目的の情報を探し出すインタフェースとしては良いが、ユーザからの要求を受けてデータ集合やデータの構造を動的に変形させることはできない。
【０００６】
【発明が解決しようとする課題】
データマイニングの前処理を行う際には、多くのアプリケーション、データ形式、手順を人間が管理しなければならず、その処理過程は多くの労力と困難を伴う。
本発明は、データマイニングの前処理において、データ形式と手順の管理の煩雑さを解消し、より直感的に高度な前処理を行うことができる手段を提供することを目的とする。
【０００７】
【課題を解決するための手段】
本発明では、データマイニングの前処理の際に様々なタイプのデータ集合を一元的に取扱い、ユーザからのインタラクションを反映してデータ集合やデータの構造を動的に変更することが可能な方法とそのためのインタフェースを提供する。具体的には、前処理の対象となるデータ集合を小さな処理単位のXMLデータに分割して、その処理単位に対しての処理フィルタをシステムによって生成し、ユーザがそれら処理フィルタを選択することによって、従来手作業で行われていた前処理を効率良く実施可能とする。すなわち、大量データ中のデータ構造を、データとは独立して作成し、この作成されたデータ構造に対して変形を施し、変形処理を効率化する。
【０００８】
これら機能の実装をするために、データに対して、以下の処理を実行する。
データ集合をXML形式の階層型ユニットツリーに変換して、データ集合を処理単位へと分解する。また、ここで得られた階層型ユニットツリーをビジュアルに表示する。
階層型ユニットツリー及びXML形式のデータ集合に対してノイズの除去などのフィルタが適用可能か検査・実行する。次に、画面上に表示された階層型ユニットツリーに対する画面上でのマウスのドラッグ等の操作を介して、ユーザからの変換要求を実行する。
ユーザが変換作成したデータ集合をマイニングエンジンを用いて解析する。この解析結果を基に再度(2)のデータ変換を実行することも可能とする。
【０００９】
本発明で扱うXML(eXtensible Markup Language)は、W3C(The World Wide Web Consortium)により、もともと電子文書の標準としてISOで規定されたSGML(Standard Generalized Markup Language)の制限されたサブセットである。すべてのXML文書は必ずSGML規格に適合する。XMLが策定された理由は、現在既に広く広まっているHTML(Hyper Text Markup Language)と同様に、任意の文書型を持つSGML文書を標準として広めたかったのだが、実装が困難なSGML文書では、広まりにくかったという背景がある。多くの研究のもと、SGML及びHTMLのどちらに対しても相互運用性を保つ設計がなされた。W3Cでは、XMLの設計目標として次の点が挙げられている。
【００１０】
−XMLは、インターネット上でそのまま使用できる。
−XMLは、広範囲のアプリケーションを支援する。
−XMLは、SGMLと互換性をもつ。
−XML文書を処理するプログラムは容易に書ける。
−XMLでは、オプションの機能はできるだけ少なくし、理想的には一つも存在しない。
−XML文書は、人間にとって読みやすく，十分に理解しやすい。
−XMLの設計は、すみやかに行う。
−XMLの設計は、厳密で、しかも簡潔なものとする。
−XML文書は、容易に作成できる。
−XMLでは、マーク付けの数を減らすことは重要ではない。
【００１１】
これらの設計目標がすべて達成されているデータ形式は他に存在しない。例えば、XMLがインターネット上でそのまま使用できるための仕組みとして、名前付け空間が用意されており、URLを利用して世界で一意な文書の名前付け、及びDTD (Data Type Definition)による厳格なデータ構造の規則付けが可能となっている。また、XML文書を処理するためのAPI (Application Program Interface)であるDOM (Document Object Model)やSAX (Simple API for XML)がW3Cによって提唱されており、すべてのXML処理系はこれらに従っている。
【００１２】
XML文書は、論理構造及び物理構造をもつ。物理的には、文書は実体という単位からなる。実体が他の実体を参照すれば、参照された実体も文書の一部になる。文書は、ルートすなわち文書実体から始まる。論理的には、文書は、宣言、要素、コメント、文字参照及び処理命令を含み、これらすべては、文書内で明示的なマーク付けによって示される。論理構造及び物理構造は、厳密に入れ子になっていなければならない。
【００１３】
厳格さと実装の容易さを両立させたXMLが普及するのは自然な流れであるといえ、様々なベンダーによって構造解析のためのXMLパーザや、整形表示のためのスタイルシートなどが次々に発表されていることも相まって、インターネット上に限らず、他の計算機に関わる分野でのデータ交換に用いられるようになってきている。
【００１４】
例えば生物情報学論文(Robin McEntire, Peter Karp, Neil Abernethy, et al, "An Evaluation of Ontology Exchange Languages for Bioinformatics," ISMB2000.)では、生物情報学分野での情報蓄積には、入力のしやすさ、情報表示や解析のために用いる様々なアプリケーションとの親和性を考えると、従来のLISPで用いるリスト構造ではなく、XMLを用いたデータ構造が必要になってくると述べられている。
【００１５】
このように、本発明で求めるデータ形式の目的に、XMLは合致する。従来前処理で用いていたフラットな表、または関係データベースのような形式では不十分であり、扱うデータ構造を木構造やグラフ構造にする必要がある。XMLは木構造であり、様々な処理を行う前処理で求められる他のアプリケーションとの親和性についても問題がない。さらに、多くの蓄積される情報がXMLに変化しつつあるという現状を踏まえると、XMLを用いて前処理を行うというのは、むしろ自然な流れであるといえる。
【００１６】
本発明では、関係データベースが不得意とする、データ構造の変形を主にした前処理について、XML変形を用いた処理の実現を目標とする。この際に、自動的な前処理を実現できるような仕組みで、前処理を行えることを前提とする。
【００１７】
ここで、XML変形を用いてデータマイニングの前処理を行う場合、操作定義の煩雑さという問題に突き当たる。これは、データマイニングで用いるデータが、通常EDIなどで交換されるXML文書に比べて、要素数が非常に多いことによる。W3Cによって用意されているDOMやSAXのインタフェースでは1度に1つの実体の移動しかサポートしないため、多くの要素を参照する何らかの仕組みが必要となる。
【００１８】
なぜ関係データベースでは簡潔なSQL文によって操作を定義できるかといえば、それは単純な表構造の組合せを用い、行と列で多くのデータを一度に指定できるためである。XMLでこのような多くの実体を参照したり、移動するための代表的な研究として、XML-QL(S.Abiteboul, D.Quass, J.McHugh, J.Windom, and J.Wiener, "The Lorel query language for semistructured data," International Journal on Digital Libraries, 1(1):68-88, April 1997.)がある。本発明のXML変形はこのXML-QLを使用して表現可能であるが、XML-QLを使用する上での問題点として、記述に多少の難解さを伴うことと、変形はブラックボックス的に行われることがある。例えば複数の要素を移動したあとに、ある要素の移動だけを取り消したいなどの要望には、問い合わせ文を書き換える必要がある。
【００１９】
本発明ではこのようなバックトラックを可能にし、また、前処理を自動化させるために前処理全体を分解して小さな処理とした単位を考える。これは機械学習の古典的手段であるプランニングに対するアクションと同じような概念であり、自然な考え方であるといえよう。具体的には、XMLに対する小さな変形をフィルタと呼び、それらフィルタを自由に組み合わせて適用することでXMLの変形全体を実現する。
【００２０】
ここで、フィルタをどのような単位に分ける必要があるか考えると、XMLの要素を1つ作成したり、移動したりすることが1つのフィルタであると言えそうである。しかし、このようにすると、要素数が増大するにつれ、必要なフィルタ数が増大していくことは自明である。そこで、効率的なフィルタを作成でき、かつ見やすいビューを提供するために、図４に示すような、XML全体を一度に見渡すことのできるDTD (Data Type Definition)の概念とよく似た階層ユニットツリーと呼ぶ構造を提案する。階層ユニットツリーはXMLデータによって非可逆的に決定される構造であり、データの内容は含まれない。階層ユニットツリーに対するフィルタはXML変形を行うフィルタに予め対応付けられており、階層ユニットツリー上で決定されたフィルタの集合を用いてXMLデータに対する前処理を行う。
階層ユニットツリーを生成するには、以下に示すアルゴリズムを用いる。
【００２１】
【数１】
0003773426.tif 000002
【００２２】
この中で、makeUnitRoot関数が、階層ユニットツリーを作成する関数である。1〜6 行目で、再帰関数であるmakeUnitに、文書実体と新たに作成した空の階層ユニットツリーのノードを渡して呼び出している。makeUnitは、docNodeの情報を元に、unitNodeより下の階層ユニットツリーを求める関数であり、これにより3行目のunitRootには、docRootを元に構築された階層ユニットツリーのルートが格納されている。makeUnitは次のように動作する。
1. 9行目docChildにdocNodeの子供を順番に代入している。
2. 11〜16行目unitNodeにdocChildと同じ名前を持つ子供が存在しなければ、新たなUnitNodeを作成し、docChildと同じ名前を付けてunitNodeの子供にする。
3. 17行目unitChildにunitNodeの子供で、docChildと同じ名前を持つUnitNodeを代入する。
4. 18〜22行目1つのdocNodeの下に同じ名前を持つElementが存在した場合に、該当Elementを表すUnitNodeのmultipleフィールドを真に設定する。
5. 23行目makeUnit関数を再帰的に呼び出す。
【００２３】
makeUnitRoot関数の引数にXML文書の文書実体を渡すことにより、文書実体から見て同じパスにより到達する要素(以下、これらの要素を対称な要素と呼ぶ)がまとめられ、要素間の関係が一対多の関係なのかを表すmultipleフィールドが適切に設定された階層ユニットツリーのルート要素が得られる。
【００２４】
図３に例示したXMLデータの場合、図の下に示したような階層構造を有する。それに対してmakeUnitRoot関数を適用すると、図４に示すような階層ユニットツリーが作成される。この階層ユニットツリーは、"root"の下に一対多の関係で要素"unit"があり、要素"unit"には１つの"key"、１つの"R1"及び複数の"R2"が属することを示している。階層ユニットツリーは、XMLデータのデータ構造のみを反映したツリー構造であり、データの内容は含まれない。また、冗長なデータ構造がマージされ、最適化されている。
【００２５】
次に、本発明によるシステムの全体の概略構成を図１に示す。入力には表、関係データベース、テキスト、及びXMLなどあらゆる入力が考えられるが、それらはすべて単純なプログラムによってXMLに変換されてから本システムに投入される。実際に本システムでは、図５に示すような変換を行うCSV (Comma Separated Value)からXMLへの簡単な変換プログラムを実装している。
【００２６】
入力されたXMLファイルは、システム内部でDOMとして表現される。DOMとはXMLから可逆的に変換される、W3Cによって定義されたオブジェクトツリーであり、ツリー構造を変化させるAPIを実装している。このAPIを用いて、入力XMLに対応する階層ユニットツリーが生成される。この階層ユニットツリーを見ながら、利用者はWebブラウザ上に用意されたインタフェースを用いてフィルタの組合せであるフィルタパスを構成していく。データを持たず変換元のXMLに対してコンパクトなオブジェクトツリーである階層ユニットツリーに対しては、フィルタパスは即座に適用することができる。利用者は階層ユニットツリーの状態を見ながら前処理を選択していく。ある程度前処理が進んだところで階層ユニットツリーに適用したフィルタパスをXMLに対しても適用し、解析用のXMLを生成する。ここでのフィルタパスはXML用のフィルタパスであり、フィルタごとに階層ユニットツリー用のXML用のものが予め定義されている。解析用のXMLファイルは解析アルゴリズムに入力させることができる。解析結果はWebブラウザ上で閲覧、またはファイルとして取り出すことができ、それらの結果を見てフィルタパスの修正を行う。
【００２７】
また、これらの操作時のフィルタパスは自動的に保存されており、利用者は階層ユニットツリーの類似度により重み付けを用いて自動的にフィルタパスを選択することが可能である。以上の操作を繰り返し行うことで、より興味深い結果を得られる前処理を求めていく。階層ユニットツリーに対する種々のフィルタの適用、すなわち階層ユニットツリーに対する操作履歴は履歴ファイルに保存してあり、必要に応じてフィルタ適用の何段階か前の階層ユニットツリーの状態に戻ることができ、戻った状態の階層ユニットツリーに対して別のフィルタ列を適用することが可能である。
【００２８】
利用者が用いるインタフェースは大きく分けて、次の3つに分類される。
−階層ユニットツリーの閲覧、操作
−フィルタパスの閲覧、操作
−システムの出す質問への回答
【００２９】
階層ユニットツリーの閲覧、操作と、フィルタパスの閲覧、操作は同一の画面内で行われる。例えば図１６に示した画面において、左側がフィルタパスの閲覧と操作のインタフェース、右側が階層ユニットツリーの閲覧と操作のインタフェースである。
【００３０】
階層ユニットツリーの閲覧、操作は、図１６に示すApplet上で行われる。葉ノードと非葉ノード、またXML文書中に表れた回数などの違いが色と形によって一目でわかるようになっている。丸や四角は要素間の関係を表しており、丸は子要素との関係が1対1、四角は子要素との関係が1対多であることを表している。要素中の数字は、XMLから階層ユニットツリーへの変換時にその要素が何回出現したかを表している。要素の名前はその要素を表す丸又は四角の近くに表示される。フィルタの適用は、基本的には1つ、あるいは複数のノードを選択し、フィルタを適用させるためのボタンを押すことで実行する。後述する移動フィルタについては、ノードからノードへのドラッグ&ドロップにても適用が可能である。
【００３１】
フィルタパスの閲覧、操作は、図１６に示すWebブラウザに表示された左側フレームのHTML上で行われる。画面には適用済みのフィルタパスが履歴1605として表示されている。適用済みのフィルタパスのフィルタ名の部分にはハイパーリンクが設定されており、クリックすることでその場所まで戻ることができる。新たなフィルタを作成するときは、Create New Filterハイパーリンク1609をクリックするとサブウィンドウ1611が開き、フィルタの候補が表示される。サブウィンドウ1611に表示されたフィルタ名の部分にもハイパーリンクが設定されており、クリックすると別のインタフェースが表示され、そこでフィルタの詳細設定を行う。作成されたフィルタはフィルタパスの末尾に追加される。階層ユニットツリーの表示はいつでもView Unitハイパーリンクをクリックすることで行われ、現在のフィルタパスの状態を反映したものとなる。
【００３２】
システムが出す質問への回答の例を図２０に示す。上部の図中にあるMiningリンク2001をクリックすることで、下部の図で示されるマイニングエンジンを適用するためのインタフェースが現れる。ここではマイニングエンジンへの入力ファイルの一部2010が見えており、これを見て決定木もしくは相関ルールによる解析アルゴリズムのためのオプション文字列を与えて、実行させることができる。
【００３３】
以上をまとめると、本発明によるデータマイニングにおける前処理方法は、XMLデータから、当該XMLデータの属性を葉ノードあるいは非葉ノードとし、属性値を含まず属性間の関係のみを表現し、ノード間の冗長な親子関係をマージして最適化したツリー構造である階層ユニットツリーを作成するステップと、階層ユニットツリーに対して変更を加えるステップと、階層ユニットツリーに対して加えられた変更を反映するように前記XMLデータを変換するステップとを含むことを特徴とする。
【００３４】
本発明によるデータマイニングにおける前処理方法は、また、XMLデータから作成した、当該XMLデータの属性に対応する葉ノードあるいは非葉ノードと、ノード間の親子関係を表す枝とを含み、ノード間の冗長な親子関係をマージして最適化したツリー構造である階層ユニットツリーを画面表示するステップと、階層ユニットツリーに変更を加える操作を行うステップと、階層ユニットツリーに対して加えられた変更を反映するように前記XMLデータを変換するステップとを含むことを特徴とする。
【００３５】
階層ユニットツリーに変更を加える操作には、同じ非葉ノードを親に持つ複数のノードを、当該複数のノードと同じ階層に新規に作成するノードの子ノードとする操作（Groupフィルタ）、指定したノードを当該ノードの現在の親とは別のノードの子の位置に移動する操作（Moveフィルタ）、あるいは、同じ非葉ノードを親に持つ複数のノードの属性名を同一の属性名に変更し、前記複数のノードをマージする操作（Renameフィルタ）が含まれる。指定したノードを当該ノードの現在の親とは別のノードの子の位置に移動する操作は、指定したノードをマウスによってドラッグし、新しく親となるノードの上にドロップすることによって実行することができる。
【００３６】
また、階層ユニットツリーに対する操作履歴を表示するとともに操作によって変更された階層ユニットツリーをそれぞれ記録し、表示された操作履歴の所定の操作段階を指定したとき当該操作段階に対応する階層ユニットツリーを表示するように構成するのが好ましい。
【００３７】
本発明によるデータマイニングにおける前処理システムは、XMLデータから作成した、当該XMLデータの属性に対応する葉ノードあるいは非葉ノードと、ノード間の親子関係を表す枝とを含み、ノード間の冗長な親子関係をマージして最適化したツリー構造である階層ユニットツリーを表示する表示部と、階層ユニットツリーに変更を加えるためのフィルタを選択するためのフィルタ選択部とを備えることを特徴とする。このシステムに、階層ユニットツリーに適用したフィルタの履歴を表示する履歴表示部を備えると更に好ましい。
【００３８】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を説明する。
本発明で提案する階層ユニットツリー表示は、木構造のルートから見て、ノードの属性に関して同一のパスを持つノードを同一のノードとみなしたものであり、それら階層ユニットツリーのノードに対しての一貫性を持った操作が1つのビュー上で容易に行うことができる。階層ユニットツリーはXMLから非可逆的に変換されるものであり、データを含まずデータ構造のみを反映し、同一のパスを持つノードが大量に存在するならば、元のXMLに比べて非常に小さなオブジェクトで表現することができる。そのため、データを大量に含むXMLに対してもユーザからの操作を受けて、データ集合やデータ構造をインタラクティブに変更・編集することが可能となり、マイニングの前処理を効率的に行うことができる。
【００３９】
まず、図１を用いてシステムの概要を説明する。ユーザ102は、システム101を立ち上げ、入力データ103をXMLデータ104に変換したものをシステム101に登録する。XMLデータ104はシステム内のmakeUnitRoot関数によって自動的に階層ユニットツリー105に変換される。階層ユニットツリー105は、システム内部ではDOMツリー112として表現されている。ユーザ102は、インタフェース107を介した対話的操作113によって階層ユニットツリー105を確認しながら、フィルタ106を生成、操作114し、フィルタパス115を得る。フィルタの生成、操作114の際には、フィルタパス115によって変形された階層ユニットツリー108(DOMツリー112)がインタフェース107によってユーザ102にフィードバックされる。ユーザ102は、インタフェース107を通じてXMLデータ104をフィルタパス115によって変形したXMLデータ109を、解析アルゴリズム110に適用し、解析結果111を得ることができる。結果表示画面116を通じて、解析結果111はユーザ102にフィードバック117され、ユーザ102はさらに洗練されたフィルタパス115を構築することができる。また、ユーザ102はこれら一連の流れについて、インタフェース107を通じて、操作114の履歴から自動構築されたフィルタパス115を得ることができる。以上の処理を繰り返すことで、効率の良い前処理を行う。フィルタの生成、操作の履歴は各操作時点の階層ユニットツリーと共に履歴ファイル120に格納されており、いつでもフィルタパス115の途中の時点に戻り、その時点から階層ユニットツリーに対する操作を再開することができる。
【００４０】
図２は、システムの表示画面の変化を示す概略図である。XMLデータを投入することで、階層ユニットツリー201が生成され、表示される。操作フレーム202又は階層ユニットツリー201を通じて、フィルタを生成、選択することで、フィルタパスを作成することになる。ユーザはフィルタパスの任意の場所での階層ユニットツリー201を表示させることが可能である。ユーザは、階層ユニットツリーに対して加えられた変形、すなわち作成されたフィルタパスに対応する前処理を経たXMLデータを得、その前処理を施したXMLデータを解析アルゴリズムに入力し、解析結果203を得ることができる。
【００４１】
この結果203を見て、ユーザは操作フレーム202や階層ユニットツリー201のインタフェースに対する操作をフィードバック204することで洗練させていき、効率良く前処理を行う。解析アルゴリズムに与えるデータの構造を変化させることは、すなわちデータの属性や量、データ内部要素の関係などを変化させるということであり、解析結果に直接大きな影響を与える。図２の例では、右側の系列と左側の系列とで、同じデータに対して異なるフィルタパスが選択されているために、階層ユニットツリー、及びマイニングアルゴリズムに入力されるデータが異なっており、マイニング結果203も異なっていることがわかる。
【００４２】
ここで、階層ユニットツリーに適用する主なフィルタの種類、フィルタの適用による階層ユニットツリーの変形の様子、フィルタパスをXMLデータに適用したときのXMLデータの変換について説明する。
【００４３】
図６、図７は、Groupフィルタの適用例についての説明図である。Groupフィルタは、階層ユニットツリー中で同じ要素を親に持つ複数の要素を、その階層に新規に作成する要素の子要素としてグループ化するフィルタである。Groupフィルタの作成に当たっては、階層ユニットツリーの該当する要素（グループ化すべき要素）をマウスで選択し、Groupフィルタを起動する。すると、グループ名を入力するよう求められるため、グループ名を入力すると所望のGroupフィルタが作成される。図６は、図４に示した階層ユニットツリーの要素R1と要素R2をグループ名G1という新規に作成した要素のもとにグループ化するGroupフィルタの作成例を示している。このGroupフィルタの適用により、階層ユニットツリーは図６の下方に図示するように変形される。本例の場合、Group フィルタ適用後のXMLは、この階層ユニットツリーの変形に対応して、図７に示したようになる。
【００４４】
図８、図９は、Moveフィルタの適用例についての説明図である。Moveフィルタは、階層ユニット中の指定された要素を、現在の親とは別の要素を親とする子の位置に移動するフィルタである。Moveフィルタが適用される要素が子要素を有する場合には、それらの子要素も指定された要素との親子関係を保ったまま一緒に移動する。Moveフィルタの作成に当たっては、階層ユニットツリーの該当する要素をマウスでドラッグし、新しく親となる要素の上にドロップする。この操作によって、マウスでドラッグした要素を新しい要素の子要素とするMoveフィルタが作成される。図８は、図４に示した階層ユニットツリーの要素R2をRootの直下に移動するMoveフィルタの作成例を示しており、このMoveフィルタの適用により階層ユニットツリーは図８の下方に示すように変形される。本例の場合、Moveフィルタ適用後のXMLは、階層ユニットツリーの変化に応じて図９に示したようになる。
【００４５】
図１０、図１１は、Renameフィルタの適用例についての説明図である。Renameフィルタは、指定された要素の要素名を変更するフィルタである。Renameフィルタは、典型的には、異なる要素名の複数の要素を指定し、それらの要素を同じ要素名に変更することでデータの統合を図る場合に使用される。Renameフィルタの作成に当たっては、階層ユニットツリーの該当する要素をマウスで選択し、Renameフィルタを起動する。すると、新しい要素名を入力するよう求められるため、変更後の要素名を入力すると所望のRenameフィルタが作成される。図１０は、図４に示した階層ユニットツリーの要素R1と要素R2の要素名をRに変更するRenameフィルタの作成例を示している。このRenameフィルタの適用により、階層ユニットツリーは図１０の下方に図示するように変形される。本例の場合、Rename フィルタ適用後のXMLは、この階層ユニットツリーの変形に対応して、図１１に示したようになる。
【００４６】
図１２、図１３は、Deleteフィルタの適用例についての説明図である。Deleteフィルタは、指定された要素を削除するフィルタである。指定された要素が子要素を有する場合には、その子要素以下の要素も全て削除される。Deleteフィルタの作成に当たっては、階層ユニットツリーの該当する要素をマウスで指定し、Deleteフィルタを起動する。この操作によって、マウスで指定した要素に繋がる要素が全て削除される。図１２は、図４に示した階層ユニットツリーの要素R2を削除するDeleteフィルタの作成例を示しており、このDeleteフィルタの適用により階層ユニットツリーは図１２の下方に示すように変形される。本例の場合、Deleteフィルタ適用後のXMLは、階層ユニットツリーの変化に応じて図１３に示したようになる。
【００４７】
図１４、図１５は、Joinフィルタの適用例についての説明図である。Joinフィルタは、指定された要素を別のXMLファイルにある要素と結合するフィルタである。Joinフィルタの作成に当たっては、結合元の要素と、結合先のXMLファイル、及び結合先の要素をマウス等によって指定し、Joinフィルタを起動する。この操作によって、結合先の要素と兄弟関係にある要素、つまり同一の親要素を持つ要素が、結合元の兄弟要素として新たに作成される。この時XMLファイル上では、結合元の要素に含まれるデータと結合先の要素に含まれるデータが照合され、データが等価な要素について結合する。図１４は、図４に示した結合元階層ユニットツリーのR1要素と、別のXMLファイルから生成された結合先階層ユニットツリーのS3要素を結合するJoinフィルタの作成例を示しており、このJoinフィルタの適用により結合元の階層ユニットツリーに対して図１４の下方に示すようにS3要素の兄弟要素であるS1、S2要素が追加される。本例の場合、Joinフィルタ適用後のXMLは、階層ユニットツリーの変化と、R1要素とS3要素のデータに応じて図１５に示したようになる。
【００４８】
ここで、階層ユニットツリーの変形に用いたフィルタパスによるXMLデータの変換について説明する。図1にあるように、フィルタパスは複数のフィルタを順序付けて並べたものである。また、すべてのフィルタについて、階層ユニットツリーの変形を行うものと、XMLデータの変形を行うものが用意されている。すなわち、階層ユニットツリー変形用に作成されたフィルタパスは、フィルタパスを構成するフィルタをXMLデータ用のものに置き換えることによって、XMLデータ変形用のフィルタパスとなる。ここで、XMLデータ用のフィルタパス115下によってXMLデータ104から変形されたXMLデータ109から生成される階層ユニットツリーは、同じフィルタ構成である階層ユニットツリー用のフィルタパス115上によって階層ユニットツリー105から変形された階層ユニットツリー108と等しくなることが条件となる。
【００４９】
以下では、臨床データのサブセットを用いた問題解決の例を説明する。対象となるデータは、MIC菌検査の結果とカテーテル処置の結果を持っている。まずMIC菌検査について、普通このような小さなデータ集合ではそのままでも処理に特に支障がないのであるが、他の菌検査結果などが混在した場合、取り扱いに注意が必要となるために、1つにまとめる処理を行う。また、カテーテル処置については、データ入力の都合上同じ意味を持つ属性が「カテーテル1」「カテーテル2」「カテーテル3」と分裂しており、これらを「カテーテル」1つにまとめたい。つまり、MIC菌検査についてグループ化を行い、カテーテル処置については名前の変更を行う。
【００５０】
Renameフィルタ（名前の変更）とGroupフィルタ（グループ化）を適用した例を、図１６から図１８を用いて説明する。Renameフィルタは要素の名前を変更し、その結果として、文書実体から見た経路も含めて同じ名前の属性が存在する場合は1つにまとめるフィルタである。Groupフィルタは対象となる要素を新たな1つの要素の子供に移動するフィルタである。
【００５１】
図１６は、階層ユニットツリーの初期状態の例を示す図である。操作フレーム1601からビューへのハイパーリンク1602をクリックすることで、画面の右側にユニットの状態を木構造で表した階層ユニットツリーのビュー1603が表示される。このビュー1603は、スクロールバー1604やマウスでのズーム操作によって見やすいように調節が可能である。また、各要素に適用されたフィルタはフィルタパス1605によって把握できる。初期状態では、ビュー1603のように、階層構造が取られていないことが多く、例えばこの初期状態では、同じカテーテル1606を表す属性が、カテーテル1、カテーテル2、カテーテル3と異なる名前で並列に記述されている。表1610は元データのCSV表記であり、この状態で検体ID列とカテーテル列に関して解析アルゴリズムへの出力を作成すると、何もフィルタを適用していないため、表1610となる。解析アルゴリズムへの出力を作成するには、システム内部でまず元データであるXMLに対してフィルタパスを適用し、さらに図５に示す変換の逆変換を行うXMLからCSVへの変換プログラムを適用している。このときカテーテル1606は、解析アルゴリズムによっては列が違うと3つの列が同一の属性とはみなされなく、不適切である。また、表1610には出力していないが、MIC菌検査項目であるabpc1607とampc 1608は、1つのグループとして扱いたい。ユーザは以上のことを把握しているとする。
【００５２】
この状態ではまだ、このデータに対しての前処理を行うフィルタは用意されていない。そこで新しいフィルタを作成するために図１６のフィルタ作成のハイパーリンク1609をクリックする。するとフィルタ選択用のサブウィンドウ1611が開き、フィルタの候補が画面が表示されるため、そこからRenameフィルタを選択する。
【００５３】
Renameフィルタを選択すると、図１７のような画面が表示される。図１７は、Renameフィルタを作成するために必要な情報を収集する画面である。画面の右側にRenameフィルタを適用するのに必要な質問文1702と回答ボックス1703が表示されている。回答ボックス1703から名前の変更を行いたい属性を複数選択し、変更後の名前をテキストボックス1704へ入力して入力送信ボタン1705を押すことでシステムに通知される。図１６のビュー1603で、マウスによってカテーテル1、カテーテル2、カテーテル3を選択した後、フィルタ作成のハイパーリンク1609をクリックして表示されたサブウィンドウ1611でRenameフィルタを選択した場合には、図１７の画面の回答ボックス1703には、カテーテル1、カテーテル2、カテーテル3が選択された状態となっている。
【００５４】
同様の操作をGroupフィルタに関して要素abpc 1607と要素ampc1608に対しても行い、要素abpc 1607と要素ampc 1608のグループ名として"MIC"を入力し、ビューへのハイパーリンク1706をクリックすると、Rename フィルタとGroupフィルタを反映した図１８のようなビューを得ることができる。フィルタパス1805は適用済みのフィルタを示している。カテーテル1801は1つの親属性に対して一対多の関係を持つ属性として認識され、MIC 1802はGroupフィルタ適用の結果、階層化構造を取っている。このビューから検体ID列とカテーテル列に関して出力を行うと表1804のようになり、検体1803とカテーテル1801の一対多の関係が正しく表現されている。
【００５５】
結合(Join)フィルタを適用した例を図１９によって説明する。ここでは階層ユニットツリー1901中の属性名が検出菌である要素1902の属性について、bacteria.xmlという別のXMLファイルの耐性定義分類属性1906によって分類することを考える。ここでは既にJoinフィルタが定義されており、bacteria.xml内の属性名が耐性定義分類である要素1906と、bacteria.xml内の属性名が検出菌である要素1905が結合されている。結合にはマウスドラッグを用いる。bacteria.xmlを表す階層ユニットツリー1904内の検出菌属性1905を階層ユニットツリー1901内の検出菌属性1902にドラッグすることにより結合が成立する (JoinではなくMoveを選択したときにこのドラッグを行うと、検出菌属性1905を検出菌属性1906の子供に移動するという意味になる) 。この結合により、bacteria.xml中の検出菌属性1905の同階層にある耐性定義分類属性1906が検出菌属性1902と同階層に作成される。実際のXMLデータ中では、検出菌属性1902と検出菌属性1905で同じデータを持つものが結合される。適用はJoinフィルタのフィルタ名部1909をクリックすることで行われる。Joinフィルタ適用後の階層ユニットツリーには耐性定義分類属性1908が追加されており、フィルタパスにはJoinフィルタ1910が追加されていることがわかる。
【００５６】
マイニングアルゴリズムからのフィードバックの例を図２０、図２１を用いて説明する。まず、図２０では、ある程度の前処理が既に行われ、耐性定義分類についての決定木を得るためにマイニングエンジンの決定木生成プログラムであるマイニングエンジンに投入するための入力ファイルを作成している。マイニングエンジンでは属性選択を最優先選択法などの組込みアルゴリズムを用いて行うことができ、ここでは、決定木を作る前に耐性定義分類と相関が高いことが自明である属性2004が実際に相関の高い属性として抽出されていることがわかる。このような属性が含まれていた場合、決定木はこれらの属性に統計的に支配されてしまい、自明な決定木しか得られないため、取り除く必要がある。
【００５７】
このようにフィードバックを行い、耐性定義分類と相関が高いことが自明ではないが、相関が高い属性で構成されたマイニング結果が図２１の2102である。この時の階層ユニットツリー2101は、図２０の階層ユニットツリー2002と同じ構造をしているが、異なるマイニングアルゴリズムの適用によって、異なる結果が得られている。このようなマイニング結果は興味深い決定木が得られることが期待でき、実際に得られた決定木は2103のようなものである。
【００５８】
以上が、前処理のプロセスを一元的に行う部分である。図２２では、一度作成されたフィルタを再利用してシステムがフィルタの適用列を多数作成する場合に用いる順序付けを模式的に表した図であり、古典的な重み付けフローである。ユーザ2201は、フィルタ群2202にないフィルタを作り出し、フィルタ群2202に追加2205する。追加2205されたフィルタは複数のユーザ2201によって共有され、それぞれに対して重み付けがなされる。これはユニットの状態によっても変化するが、共有フィルタパスマップ2203によって保持される。共有の評価はユーザ2201からの評価2206によって変化する。セッションごとのフィルタパスマップ2204に対する評価2206には機敏に反応するが、共有フィルタパスマップ2203に対する評価2207は、そう機敏でない。ある閾値を下回る重みを持ったフィルタは、共有フィルタパスマップ2203によってフィルタ群2202から削除2208される。このように重み付けされたフィルタパスを用いて、階層ユニットツリーの類似度からフィルタパスの選択を自動的に行う。
【００５９】
図２３は本発明で作成されたシステムのフローチャートである。システムの起動（ステップ2301）を行った後、ユーザはXMLファイルの選択を行う（ステップ2302）。最初はフィルタパスが空であるので、フィルタの選択を行う。フィルタを自動的に選択する場合は、ステップ2304からステップ2308に進み、複数のフィルタを自動的に選択する。ユーザが自分で選択する場合は、ステップ2305の判定で、望みのフィルタが作成済みの場合は、作成済みフィルタ群から選択し（ステップ2306）、そうでない場合は、フィルタをWebブラウザ上で新たに作成し（ステップ2307）、フィルタパスに追加する。このように選択を行っていき、ステップ2303の判定で最終的に望みどおりのフィルタパスが得られていれば、XMLファイルに対してフィルタパスを適用し、解析結果を表示する（ステップ2309）。望みの解析結果でなければ、またフィルタの選択に戻る。ステップ2310の判定で望みの解析結果であれば、解析結果や前処理済みデータの保存を行い（ステップ2311）、処理を終了する。
【００６０】
【発明の効果】
これまでは発現や臨床データなど様々な種類のデータを、専門家の手作業によって個別に処理してノイズ除去やマイニングへの入力等を行ってきた。本発明では、階層ユニットツリーのノード条件を変更することによって動的にデータ変換と入力を行うことができ、効率的かつ高精度にマイニングを行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の一実施の形態における、処理の流れを示す図。
【図２】本発明の一実施の形態における、表示画面の流れを示す図。
【図３】  XMLデータの例を示す図。
【図４】  XMLデータから作成された階層ユニットツリーの例を示す図。
【図５】  XMLからCSVへの変換を示す図。
【図６】階層ユニットツリーへのGroupフィルタの適用例についての説明図。
【図７】  Group フィルタ適用後のXMLの例を示す図。
【図８】階層ユニットツリーへのMoveフィルタの適用例についての説明図。
【図９】  Moveフィルタ適用後のXMLの例を示す図。
【図１０】階層ユニットツリーへのRenameフィルタの適用例についての説明図。
【図１１】  Renameフィルタ適用後のXMLの例を示す図。
【図１２】階層ユニットツリーへのDeleteフィルタの適用例についての説明図。
【図１３】  Deleteフィルタ適用後のXMLの例を示す図。
【図１４】階層ユニットツリーへのJoinフィルタの適用例についての説明図。
【図１５】  Joinフィルタ適用後のXMLの例を示す図。
【図１６】本発明によるシステムの初期状態の画面例を示す図。
【図１７】クエリーの作成画面の例を示す図。
【図１８】前処理結果表示の一例を示す図。
【図１９】  Joinフィルタの例を示す図。
【図２０】属性選択アルゴリズムで自明な属性の相関を発見した例を示す図。
【図２１】属性選択アルゴリズムで自明な属性の相関を取り除き決定木を得た例を示す図。
【図２２】重み順序付けフローを模式的に表した図。
【図２３】本発明のシステムの処理手順を示すフローチャート。
【符号の説明】
105…階層ユニットツリー、115…フィルタパス、116…結果表示画面、120…履歴ファイル、201…階層ユニットツリー、202…操作フレーム、1601…操作フレーム、1602…ビューへのハイパーリンク、1603…階層ユニットツリーのビュー、1605…フィルタパス、1609…フィルタ作成のハイパーリンク、1611…サブウィンドウ
【図１】
0003773426.tif 000003
【図２】
0003773426.tif 000004
【図３】
0003773426.tif 000005
【図４】
0003773426.tif 000006
【図５】
0003773426.tif 000007
【図６】
0003773426.tif 000008
【図７】
0003773426.tif 000009
【図８】
0003773426.tif 000010
【図９】
0003773426.tif 000011
【図１０】
0003773426.tif 000012
【図１１】
0003773426.tif 000013
【図１２】
0003773426.tif 000014
【図１３】
0003773426.tif 000015
【図１４】
0003773426.tif 000016
【図１５】
0003773426.tif 000017
【図１６】
0003773426.tif 000018
【図１７】
0003773426.tif 000019
【図１８】
0003773426.tif 000020
【図１９】
0003773426.tif 000021
【図２０】
0003773426.tif 000022
【図２１】
0003773426.tif 000023
【図２２】
0003773426.tif 000024
【図２３】
0003773426.tif 000025