(57)【要約】      （修正有）【課題】階層データを提示する方法で、異質なデータソースへアクセスし、そこから得られる情報を提示する方法を提供する。【解決手段】１つ以上の子孫データノードを有するコンテキストデータノードをデータから識別することによって提示される階層データを有し、子孫データノードにおいては少なくとも１つのデータパターンが判定する。少なくとも１つのデータパターンに基づいて、少なくとも１つの表示種別が現在のコンテキストデータノードへと割り当てられる。その後、方法は、割り当てられた表示種別のうちの１つに従って少なくとも子孫データノードのサブセットを提示する。また、階層的に表現されたデータソースをブラウズする方法も開示される。【選択図】図１
2004240954.tif 000002
【特許請求の範囲】
【請求項１】
階層データを提示する方法であって、
（ｉ）前記データから１つ以上の子孫データノードを有するコンテキストデータノードを識別する工程と、
（ｉｉ）前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる工程と、
（ｉｉｉ）前記割り当てられた表示種別のうちの１つに従って少なくとも前記子孫データノードのサブセットを提示する工程と
を備えることを特徴とする方法。
【請求項２】
前記工程（ｉｉ）は前記階層データに対するスキーマに含まれる情報を使用することを特徴とする請求項１記載の方法。
【請求項３】
前記スキーマはＸＭＬスキーマを使用して表現されることを特徴とする請求項２記載の方法。
【請求項４】
前記階層データはＸＭＬを使用して表現され、ネットワークを介して得られることを特徴とする請求項１記載の方法。
【請求項５】
前記工程（ｉｉ）の結果、１つ以上の表示種別のリストが割り当てられることを特徴とする請求項１記載の方法。
【請求項６】
前記割り当てられた表示種別は、
（ｉ）ツリー表示種別と、
（ｉｉ）表表示種別と、
（ｉｉｉ）２Ｄグリッド表示種別と、
（ｉｖ）グラフィカル表示種別と
を備える群より選択されることを特徴とする請求項１記載の方法。
【請求項７】
前記表表示種別は、行に関する表示種別及び列に関する表示種別のうちの少なくとも１つであることを特徴とする請求項６記載の方法。
【請求項８】
前記グラフィカル表示種別は、棒グラフ、線グラフ、円グラフ、及びｘｙ散布図のうちの少なくとも１つであることを特徴とする請求項６記載の方法。
【請求項９】
前記棒グラフは、行に関する棒グラフ及び列に関する棒グラフのうちの少なくとも１つであることを特徴とする請求項８記載の方法。
【請求項１０】
前記円グラフは、行に関する円グラフ及び列に関する円グラフのうちの少なくとも１つであることを特徴とする請求項８記載の方法。
【請求項１１】
前記線グラフは、行に関する線グラフ及び列に関する線グラフのうちの少なくとも１つであることを特徴とする請求項８記載の方法。
【請求項１２】
前記ｘｙ散布図は、行に関するｘｙ散布図及び列に関するｘｙ散布図のうちの少なくとも１つであることを特徴とする請求項８記載の方法。
【請求項１３】
前記提示は、前記割り当てられた表示種別のうちの最も適切な表示種別を判定することと、前記階層データを見るために前記割り当てられた表示種別のうちの他の表示種別のユーザ選択に対するオプションを提供することとのうちの少なくとも１つを含むことを特徴とする請求項１記載の方法。
【請求項１４】
前記判定は、分析フェーズ、削除フェーズ、及び優先フェーズを含むことを特徴とする請求項１記載の方法。
【請求項１５】
前記分析フェーズは、
（ｉ）前記子孫ノードの分析と、
（ｉｉ）前記子孫ノードのサブセットの分析と、
（ｉｉｉ）所定のレベルの確実性で判定を行なうことができる場合に終了する前記子孫ノードのサブセットの分析と、
（ｉｖ）前記子孫ノードからのデータ表の構築と、
（ｖ）前記子孫ノードのサブセットからのデータ表の構築と、
（ｖｉ）前記子孫ノードのサブセット及び前記子孫ノードのうちの残りのノードのスキーマ情報からのデータ表の構築とのうちの少なくとも１つを含むことを特徴とする請求項１４記載の方法。
【請求項１６】
前記削除フェーズは、前記分析フェーズ中に構築された前記データ表の分析を含むことを特徴とする請求項１５記載の方法。
【請求項１７】
前記削除フェーズは、相互に独立した削除規則の実行を伴い、前記階層データに適した可能な表示種別のリストを生成することを特徴とする請求項１４記載の方法。
【請求項１８】
前記削除規則の各々は、削除候補のリストと関連付けられ、前記削除規則の各々は３つの可能な結果のうちの１つに対して評価することを特徴とする請求項１７記載の方法。
【請求項１９】
１つの前記可能な結果が真であり、前記削除候補のリストが前記可能な表示種別のリストから削除されると、前記削除規則の実行は完了し、前記削除規則は再び処理されないことを特徴とする請求項１８記載の方法。
【請求項２０】
１つの前記可能な結果が偽であり、前記削除候補のリストが前記可能な表示種別のリストから削除されない場合、前記削除規則の実行は完了し、前記削除規則は再び処理されないことを特徴とする請求項１８記載の方法。
【請求項２１】
１つの前記可能な結果が未知であり、前記削除候補のリストが前記可能な表示種別のリストから削除されない場合、前記削除規則は追加のデータが利用可能になると再実行されることを特徴とする請求項１８記載の方法。
【請求項２２】
前記優先フェーズは、前記分析フェーズ中に構築される前記データ表の分析を含むことを特徴とする請求項１５記載の方法。
【請求項２３】
前記優先フェーズは、前記削除フェーズにより生成される前記可能な表示種別のリストの分析を含むことを特徴とする請求項１７記載の方法。
【請求項２４】
前記優先フェーズは優先規則の実行を含むことを特徴とする請求項１４記載の方法。
【請求項２５】
可能な表示種別の各対に対して、最大１つの前記優先規則があることを特徴とする請求項２４記載の方法。
【請求項２６】
前記優先規則の各々は厳密に２つの表示種別を比較することを特徴とする請求項２４記載の方法。
【請求項２７】
前記優先規則の各々は、
（ｉ）前記２つの表示種別のうちの第１の表示種別が、前記２つの表示種別のうちの第２の表示種別よりも優先される結果と、
（ｉｉ）前記２つの表示種別のうちの第２の表示種別が、前記２つの表示種別のうちの第１の表示種別よりも優先される結果と、
（ｉｉｉ）前記２つの表示種別のうちの第１の表示種別も第２の表示種別も相互に優先されない結果と
の３つの可能な結果のうち、１つに対して評価することを特徴とする請求項２６記載の方法。
【請求項２８】
前記優先規則の前記結果は有向グラフにより表現されることを特徴とする請求項２７記載の方法。
【請求項２９】
前記（第１の）有向グラフにおいて有向サイクルを検出し、存在する場合は、前記（第１の）有向グラフから前記有向サイクルを削除し、第２の有向グラフを生成することを更に含むことを特徴とする請求項２８記載の方法。
【請求項３０】
前記有向サイクルが前記第１の有向グラフに存在しない場合に前記第１の有向グラフが位相的にソートされて優先度の降順に表示種別のリストが生成されることと、
前記第２の有向グラフが位相的にソートされて優先度の降順に表示種別のリストが生成されることとのうちの少なくとも一方であることを特徴とする請求項２９記載の方法。
【請求項３１】
階層的に表現されたデータソースをブラウズする方法であって、
（ｉ）ユーザ操作を解釈して前記データソースから１つ以上の子孫データノードを有するコンテキストデータノードを識別する工程と、
（ｉｉ）前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる工程と、
（ｉｉｉ）前記割り当てられた表示種別のうちの１つに従って、前記現在のコンテキストデータノードの子孫データノードを目標として有する少なくとも１つのハイパーリンクを含む前記子孫データノードのサブセットを提示する工程と、
（ｉｖ）更なるユーザ操作を解釈して前記少なくとも１つのハイパーリンクを選択し、その結果、前記現在のコンテキストデータノードが前記選択されたハイパーリンクの前記目標に対応する前記データノードと交換される工程と、
（ｖ）子孫データノードに対する更なるハイパーリンクが前記工程（ｉｉｉ）において前記サブセットに含まれなくなるまで前記工程（ｉｉ）から前記工程（ｉｖ）までを繰り返す工程と
を備えることを特徴とする方法。
【請求項３２】
前記提示は、前記現在のコンテキストデータノードの祖先ノードに対するハイパーリンクであって、前記データソースの祖先データノードまでユーザが移動できるようにするハイパーリンクを形成することを更に含むことを特徴とする請求項３１記載の方法。
【請求項３３】
前記ハイパーリンクの前記目標データノードの内容は、現在の提示内で前記工程（ｉ）から前記工程（ｉｉｉ）の間にユーザに対して提示され、その結果、複合の表示種別が形成されることを特徴とする請求項３２記載の方法。
【請求項３４】
前記少なくとも１つのハイパーリンクは、前記ハイパーリンクの前記目標を具備する子孫データノードを表示するのに使用される１つの前記表示種別を示すグラフィカル表現と関連付けられることを特徴とする請求項３１記載の方法。
【請求項３５】
前記グラフィカル表現は、前記ハイパーリンクの選択可能な構成要素であり、前記グラフィカル表現の選択により前記ハイパーリンクがたどられることを特徴とする請求項３４記載の方法。
【請求項３６】
前記グラフィカル表現はカラーの境界線を具備し、その結果、前記カラーの境界線の色は前記ハイパーリンクが以前に選択されたか否かを示すことを特徴とする請求項３５記載の方法。
【請求項３７】
前記ハイパーリンクのテキスト表現を表示することを更に含み、前記テキスト表現の選択により前記ハイパーリンクはたどられることを特徴とする請求項３４記載の方法。
【請求項３８】
前記少なくとも１つのハイパーリンクの前記グラフィカル表現は、前記表示種別の一例を表現する所定の画像であることを特徴とする請求項３４記載の方法。
【請求項３９】
前記少なくとも１つのハイパーリンクの前記グラフィカル表現は、前記ハイパーリンクの前記目標を具備する前記子孫データノードを使用して得られることを特徴とする請求項３４記載の方法。
【請求項４０】
前記提示の結果、関連付けられたデータの要約として見られる画像が得られ、前記画像の所定のグラフィカル構成要素は、前記関連付けられたデータの内容をより良く理解するために拡大され、前記構成要素は、前記提示のタイトル、グラフ、図、又はプロットの軸の名前、及び表の各列の名前から成る群より選択され、前記拡大は、より大きいフォント及び太字のうちの少なくとも一方を使用するレンダリングを含むことを特徴とする請求項３１記載の方法。
【請求項４１】
プログラムを記録したコンピュータ可読な媒体であって、前記プログラムはコンピュータに階層データを提示する手順を実行させるように構成され、前記プログラムは、
前記データから１つ以上の子孫データノードを有するコンテキストデータノードを識別するコードと、
前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てるコードと、
前記割り当てられた表示種別のうちの１つに従って前記子孫データノードのサブセットを提示するコードと
を具備することを特徴とするコンピュータ可読な媒体。
【請求項４２】
プログラムを記録したコンピュータ可読な媒体であって、前記プログラムはコンピュータに階層データソースをブラウズする手順を実行させるように構成され、前記プログラムは、
ユーザ操作を解釈して前記データソースから１つ以上の子孫データノードを有するコンテキストデータノードを識別するコードと、
前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てるコードと、
前記割り当てられた表示種別のうちの１つに従って、目標として前記現在のコンテキストデータノードの子孫データノードを有する少なくとも１つのハイパーリンクを含む前記子孫データノードのサブセットを提示するコードと、
更なるユーザ操作を解釈して前記少なくとも１つのハイパーリンクを選択し、その結果、前記現在のコンテキストデータノードが前記選択されたハイパーリンクの前記目標に対応する前記データノードと交換されるコードと、
子孫データノードに対する更なるハイパーリンクが前記サブセットに含まれなくなるまで判定、提示、及び解釈の前記コード手段を繰り返すコードと
を具備することを特徴とするコンピュータ可読な媒体。
【請求項４３】
階層データを提示する装置であって、
前記データから１つ以上の子孫データノードを有するコンテキストデータノードを識別する手段と、
前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる手段と、
前記割り当てられた表示種別のうちの１つに従って少なくとも前記子孫データノードのサブセットを提示する手段と
を具備することを特徴とする装置。
【請求項４４】
階層データソースをブラウズする装置であって、
ユーザ操作を解釈して前記データソースから１つ以上の子孫データノードを有するコンテキストデータノードを識別する手段と、
前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる手段と、
前記割り当てられた表示種別のうちの１つに従って、前記現在のコンテキストデータノードの子孫データノードを目標として有する少なくとも１つのハイパーリンクを含む前記子孫データノードのサブセットを提示する手段と、
更なるユーザ操作を解釈して前記少なくとも１つのハイパーリンクを選択し、その結果、前記現在のコンテキストデータノードが前記選択されたハイパーリンクの前記目標に対応する前記データノードと交換される手段と、
子孫データノードに対する更なるハイパーリンクが前記サブセットに含まれなくなるまで前記解釈手段、前記判定手段、及び前記提示手段の動作を繰り返す手段と
を具備することを特徴とする装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの自動提示に関し、特に、階層データの適切な提示方法の自動選択に関する。
【背景技術】
【０００２】
データは階層化形式で提供されることが多い。例えば、データベースは、通常、各々が複数の列を成すように配置される複数の要素を含む複数の行を具備する表形式でデータを格納する。この他に、ますます普及しつつある形式としてＸＭＬがある。ＸＭＬでは、データは複数の要素により表現されるが、この要素は、下位の要素及び任意のレベルの更に下位の要素を含む可能性がある。データの構造及び内容によっては、ある特定の提示方法が根本的な情報をユーザに伝えるのに他の方法に比べてより適切且つ効果的であるかもしれない。例えば、データテーブルが数値のみを含む場合、このデータは、通常、グラフとしてよりも表として表示される方がより効果的である。
【０００３】
従来のソフトウェアシステムでは、表示の種別の選択はユーザ次第である。提示されるデータのサイズが大きい場合、あるいは、どの表現が最善であるかが明らかでない場合、ユーザにとってデータをプレビューして提示形式を決定しなければならないのは煩雑であることが多い。
【０００４】
自動的に表示形式を選択する方法は現在幾つか存在するがグラフ形式に限られており、提示されるデータが表形式であって数値を含む場合のみ適用可能である。ツリー、表、及びグリッドなどのその他の表示形式はサポートされていない。加えて、このような既存の方法では、表示選択プロセスの開始前に全てのデータが揃っていなければならない。このため、既存の方法は、データがインターネットなどの低速なネットワーク接続を介して取得される必要がある環境での使用に適していない。
【０００５】
従って、全てのデータ要素を調べずにデータ提示の最も適切な方法を選択する自動プロセスを作成することができるソフトウェアシステムが必要とされている。数値以外のデータのみならず数値データでも動作することができ、場合によってはグラフ形式以外の表示種別をサポートするシステムも求められている。
【特許文献１】米国特許第６，００９，４２８号
【特許文献２】米国特許第５，９７０，４９０号
【特許文献３】米国特許第６，１９５，６６２号
【特許文献４】米国特許第６，１７８，４１６号（Thompson, Kathleen A）
【特許文献５】米国特許第６，２２２，５４０号
【特許文献６】米国特許第５，６１１，０３４号
【特許文献７】米国特許第５，５８１，６７８号
【特許文献８】豪州特許出願第２００３２０４８２４号（Lennon等の米国特許出願第１０／４６５２２２号に対応）、発明の名称「Methods for Interactively Defining Transforms and for Generating Queries by Manipulating Existing Query Data」、参照：637389 CFP2659AU DataBrowserGr 01
【非特許文献１】H. Lieberman (ed)の「Your wish is my command - Programming by Example」（Academic Press、2001）
【非特許文献２】Chang, C.K.、Garcia?Molina, H.の「Mind Your Vocabulary: Query Mapping Across Heterogeneous Information Sources」（Stanford University）
【非特許文献３】Y. Papakonstantinou、H. Garcia?Molina、及びJ. Widomの「Object Exchange Across Heterogeneous Information Sources」（IEEE International Conference on Data Engineering、 pp. 251?260、Taipei, Taiwan、March 1995）
【非特許文献４】D. Quass、A. Rajaraman、Y. Sagiv、J. Ullman、及びJ. Widomの「Querying Semistructured Heterogeneous Information」（International Conference on Deductive and Object?Oriented Databases、1995）
【非特許文献５】Levy, A.Y.、Rajaraman, A.、Ordille, J.J.の「Querying Heterogeneous Information Sources Using Source Descriptions」（1995）
【非特許文献６】Carey等の「Towards Heterogeneous Multimedia Information Systems: The Garlic Approach」（Proceedings of the 5th International Workshop on Research Issues in Data Engineering、1994）
【非特許文献７】XML Spy (www.xmlspy.com)
【非特許文献８】Suzuki, Gengo等の「Database Systems」（125?60、18 July 2001、Mediation system for heterogenous information sources based on XML: MediPresto/XML）
【非特許文献９】Sedgewick, R.の「Algorithms. 2nd Ed」（Addison?Wesley、1989）
【非特許文献１０】Papakonstantinou, Y.及びVassalos, V.の「The Encosys markets data intergration platform: lessons from the trenches」（ACM Conference on Information and Knowledge Management (CIKM)、2001）、http://www.db.ucsd.edu/ publications/ CIKM.htm参照
【非特許文献１１】Petropoulos, M.、Vassalos, V.、Papakonstantinou, Y.の「Building XML Query Forms and Reports with XQForms」（Proceedings of WWW10、Hong Kong、2001）
【非特許文献１２】Mukhopadhay, P.、Papakonstantinou, Y.の「Mixing Querying and Navigation in MIX」（data Engineering (ICDE)、2002）、http://www.db.ucsd.edu/people/yannis.htm参照
【非特許文献１３】SVG Namespace (http://www.w3.org/TR/SVG/において記述)
【非特許文献１４】XQuery (http://www.w3.org/XML/Query参照)
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、既存の構成の１つ以上の欠点をほぼ克服、あるいは、少なくとも改善することである。
【０００７】
データ全体を調べることなく階層データを提示する最も適切な方法を自動的に選択する方法が開示される。この方法は、データが低速のネットワーク接続を介してのみアクセス可能であるときに効果的である。数値データを伴うグラフ表現に限定される既存の表示選択方法とは異なり、本発明は非数値データを扱うことができ、グラフ以外の表示形式をサポートする。
【課題を解決するための手段】
【０００８】
本発明が開示する１つの面によると、階層データを提示する方法であって、
前記データから１つ以上の子孫データノードを有するコンテキストデータノードを識別する工程と、
前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる工程と、
前記割り当てられた表示種別のうちの１つに従って少なくとも前記子孫データノードのサブセットを提示する工程とを備えることを特徴とする方法が提供される。
【０００９】
本発明が開示する別の面によると、階層データソースをブラウズする方法であって、
（ｉ）ユーザ操作を解釈して前記データソースから１つ以上の子孫データノードを有するコンテキストデータノードを識別する工程と、
（ｉｉ）前記子孫データノードにおいて少なくとも１つのデータパターンを判定し、前記少なくとも１つのデータパターンに基づいて現在のコンテキストデータノードに少なくとも１つの表示種別を割り当てる工程と、
（ｉｉｉ）前記割り当てられた表示種別のうちの１つに従って、前記現在のコンテキストデータノードの子孫データノードを目標として有する少なくとも１つのハイパーリンクを含む前記子孫データノードのサブセットを提示する工程と、
（ｉｖ）更なるユーザ操作を解釈して前記少なくとも１つのハイパーリンクを選択し、その結果、前記現在のコンテキストデータノードが前記選択されたハイパーリンクの前記目標に対応する前記データノードと交換される工程と、
（ｖ）子孫データノードに対する更なるハイパーリンクが前記工程（ｉｉｉ）において前記サブセットに含まれなくなるまで前記工程（ｉｉ）から前記工程（ｉｖ）までを繰り返す工程とを備えることを特徴とする方法が提供される。
【００１０】
コンピュータプログラム、コンピュータ可読な媒体、及び装置を含むその他の面も開示される。
【発明を実施するための最良の形態】
【００１１】
本発明の少なくとも１つの実施例を図面及び付録を参照して説明する。
【００１２】
１．０  概要
添付のいずれか１つ以上の図面において、同じ符号を有するステップ及び／又は特徴に言及する場合、特に明記されていない限り、以下の記述においては、これらのステップ及び／又は特徴は、同じ機能又は動作を有するものとする。
【００１３】
ここに記載する各構成は、異質なデータソースから成る分散形システムを表すインターネットに関して実施される。この情報空間では、有用なデータはデータベースシステム（著作権のあるソース、従来のソース、及びオープンソース）及び構造化文書（例えば、ＨＴＭＬ／ＸＭＬ文書）に格納される。記載する構成は、ＵＲＩ（Uniform Resource Identifier）空間中の全ての情報を正規化することによってこの情報空間を統一するように動作する。これは、データの各原子が最終的にＵＲＩによりアドレス指定可能であることを意味する。加えて、データソースからのデータはＸＭＬ（Extensible Markup Language）を使用して送受信され、データソースのスキーマはＸＭＬスキーマを使用して表現される。このようなウェブ標準の採用は表記上データを正規化するのに役立つが、意味的な異質性の問題は依然として残っている。
【００１４】
また、ここに記載する構成は、異質なデータソースを有する他のシステムを使用して実現されても良い。例えば、ＵＮＩＸ（登録商標）テキストファイル、Ｏｒａｃｌｅ（登録商標）又はＭｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓ（登録商標）データベースシステムなどの種々のソースに格納されるデータを有するイントラネットシステム及び他の著作権のあるデータベースシステム又は従来のデータベースシステムを使用して本発明の各実施例を実現しても良い。
【００１５】
図１に示すように、ここに記載する構成は、データブラウジングアプリケーション１２０の一部として実施されても良い。データブラウジングアプリケーション１２０は、イントラネット又はインターネット１０１に接続されるローカルコンピュータ１００上のソフトウェアアプリケーションとして実行される。データブラウジングアプリケーション１２０は、インターネット１０１を介して任意の数の分散形異質データソースと通信を行なう。データソースは、オラクルデータベース（例えば、１５０）、Ｓｙｂａｓｅデータベース（例えば、１５１）、Ｕｎｉｘ（登録商標）ファイルなどの単純なテキストデータ（例えば、１５２）、又はＸＭＬ文書の集合（例えば、１５３）であっても良い。各データソース１５０から１５３は、対応するデータサーバ１４０、１４１、１４２、及び１４３と関連する。データサーバ１４０、１４１、１４２、及び１４３はデータブラウジングアプリケーション１２０と通信を行なう。
【００１６】
データサーバ１４０から１４３はＵＲＩにより識別されるプロセスを表す。これらのプロセスは、ＨＴＴＰプロトコルを使用する要求をデータブラウジングアプリケーション１２０から受け取り、ＸＭＬの形式でデータを戻す。要求はＸＰａｔｈ表現を使用して定式化することができる。ＸＰａｔｈ表現はデータサーバのＵＲＩに問合せ文字列として付加される。ＸＰａｔｈはＷ３Ｃ勧告（http://www.w3.org/TR/Path/参照）である。要求は新進のＷ３Ｃ標準ＸＱｕｅｒｙなどのよりリッチな問合せ言語を使用して表現されるのが好ましい。ＸＱｕｅｒｙは、データが物理的にＸＭＬに格納されているか、あるいは、データサーバなどのミドルウェアを介してＸＭＬとして見られているかに関わらず、ＸＭＬの構造を使用してあらゆる種類の異質なデータに共通する問合せを表現する問合せ言語（http://www.w3.org/XML/Query）である。代替の実現例では、要求をＨＴＴＰ要求の本文に含めて（例えば、ＳＯＡＰなどのＸＭＬメッセージングプロトコルを使用して）渡すことができる。
【００１７】
代替の実現例では、データブラウジングアプリケーション１２０は、データサーバを使用せずにウェブアクセス可能なＸＭＬ文書データソースに直接アクセスすることができる。このデータソースはローカルであっても、インターネットを介してアクセスされても良い。このＸＭＬ文書データソース宛の問合せは、データブラウジングアプリケーション１２０により処理される。
【００１８】
データブラウジングアプリケーション１２０は、データソースからのデータをユーザが所望するビューへと変換するのに必要なマッピング情報のみならずユーザの関心の対象であるＵＲＩ（例えば、データソースＵＲＩ）を格納するローカルコンピュータ１００内のデータベース１３０へのアクセス権を有するのが好ましい。データベース１３０は、異質なデータソース及び関連するスキーマから得られるデータに対するキャッシュとしても機能することができる。ローカルデータベースは、Ｗｉｎｄｏｗｓ（登録商標）（Ｍｉｃｒｏｓｏｆｔ社）の実現例でのレジストリ及び種々のテキストファイル形式を含む異質な記憶形態を含むことができる。データブラウジングアプリケーション１２０は、ローカルＸＭＬ文書及び／又は他のローカルデータベースなどのローカルデータソース１３１にアクセスしても良い。
【００１９】
データブラウジングアプリケーション１２０は、データソース要求に応じてＸＭＬデータ（ＸＭＬ文書）を受信する。このＸＭＬ文書は、各々が更に下位の要素から構成される下位の要素を伴う可能性がある根要素から構成される階層ツリー構造である。ＸＭＬツリーの各要素は名前により識別される。必要に応じて、要素のテキスト値と呼ばれる一般的なテキスト文字列が、ＸＭＬツリーの各要素と関連付けられる。これは、通常、ツリーの葉要素、すなわち、下位の要素を含まない要素に当てはまることであるが、葉以外の要素に当てはまっても良い。また、属性名により識別され且つ一般的なテキスト文字列形式での属性値と関連付けられる１つ以上の属性が、必要に応じて、各要素と関連付けられる。
【００２０】
特別なハイパーリンク属性がＸＭＬデータに存在しても良い。この属性の目標を外部ファイル、同じ又は別のＸＭＬ文書構造にあるＸＭＬ要素、又は更なるデータソース要求などのエンティティとすることができる。後者のハイパーリンクの場合、ユーザは、データブラウジングアプリケーション１２０を使用して各ブラウジングステップごとにＸＭＬデータが提示される状態でデータソースをブラウズすることができる。データサーバは生成されたＸＭＬデータにリターンハイパーリンクを含むことができる。
【００２１】
データブラウジングアプリケーション１２０は、各ブラウジングステップのＸＭＬデータに対して最も適切な表示種別を自動的に選択する。これらの表示種別には、ツリー、表、棒グラフ及び線グラフ、ｘｙ散布図、及び２Ｄグリッドが含まれる。最も適切な表示方式を選択する方法はセクション５．０に説明されている。この提示ステップの結果によりデータのビューを表す。ユーザは提示の変化をこのデータのビューにもたらし、結果として生じたデータのビューを今後の使用のために取っておくことができる。取っておいたデータのビューはデータソースのように機能することができる。これらのビューは問合せと関連付けられ、ユーザがデータのビューの提示を選択するときには問合せが実行される。この結果、セクション５．０で説明されるようなＸＭＬ文書がもたらされる。
【００２２】
また、データブラウジングアプリケーション１２０により、ユーザはグラフィカルユーザインタフェース（ＧＵＩ）での表示データを操作することによって、既存のビューから新規のデータのビューを作成することができる。このプロセスはセクション６．０及び７．０において更に詳細に説明される。新規のデータのビューを作成する方法は、望ましいサービスを使用して未知のデータソースをユーザに導入することができる（セクション８．０、９．０、及び１０．０参照）。
【００２３】
最後に、データブラウジングアプリケーション１２０により、ユーザは関心の対象のデータソースからのデータをユーザにとって理解可能な形式へとマップするのに役立つマッピングを作成することによって、そのデータのビューを個別化することができる。これらのマッピングは、再利用及び他のユーザとの交換のために格納しておくことができる。マッピングのセットを交換するプロセスはセクション１１．０において説明されている。
【００２４】
図１のデータブラウジングアプリケーション１２０は、代わりにクライアントサーバアプリケーションとして実現することができる。この場合、サーバアプリケーションの単一のインスタンスを組織のイントラネット上で稼働させ、ユーザはクライアントを使用してこのサーバにアクセスしても良い。この代替の実現例には、ＸＭＬ文書及びスキーマキャッシュが組織に対してサービスを提供することができ、イントラネット上の多様な設備上でデータが重複しないという利点がある。このようなクライアントサーバ型の実現例のクライアントは、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（登録商標）（Ｎｅｔｓｃａｐｅ社）又はＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）（Ｍｉｃｒｏｓｏｆｔ社）などの広く用いられるウェブブラウザ内で実現することができる。
【００２５】
ここに記載する方法は、図１１に示すような汎用コンピュータシステム１１００を使用して実施されるのが好ましい。図１１において、図１から図６４の各プロセスはコンピュータシステム１１００内で実行されるアプリケーションプログラムなどのソフトウェアとして実現されても良い。この点に関して、コンピュータ１１００は、ローカルコンピュータ１００として、あるいは、必要に応じてサーバ１５０から１５３のうちの１台として動作するように構成されても良い。ソフトウェアは、例えば、後述する記憶装置を含むコンピュータ可読な媒体に格納されても良い。ソフトウェアはコンピュータ可読な媒体からコンピュータへとロードされ、このコンピュータにより実行される。このようなソフトウェア又はコンピュータプログラムを記録したコンピュータ可読な媒体は、コンピュータプログラム製品である。コンピュータにおいてこのコンピュータプログラム製品を使用することにより、ここに記載する各方法にとって有利な装置が実現されるのが好ましい。
【００２６】
コンピュータシステム１１００は、コンピュータモジュール１１０１と、キーボード１１０２及びマウス１１０３などの入力装置と、プリンタ１１１５及び表示装置１１１４を含む出力装置とを具備する。変復調（モデム）送受信装置１１１６は、コンピュータモジュール１１０１が、例えば、電話回線１１２１又はその他の機能媒体を介して接続可能な通信ネットワーク１１２０と通信を行なうのに使用される。モデム１１１６は、インターネット１０１及び構内通信網（ＬＡＮ）又は広域通信網（ＷＡＮ）などのその他のネットワークシステムへのアクセス権を取得するのに使用することができる。
【００２７】
コンピュータモジュール１１０１は、通常、少なくとも１つのプロセッサユニット１１０５、例えば、半導体ランダムアクセスメモリ（ＲＡＭ）及び読出し専用メモリ（ＲＯＭ）から形成されるメモリユニット１１０６、ビデオインタフェース１１０７とキーボード１１０２、マウス１１０３、及びオプションとしてのジョイスティック（不図示）用のＩ／Ｏインタフェース１１１３とを含む入出力（Ｉ／Ｏ）インタフェース、並びにモデム１１１６用のインタフェース１１０８を含む。記憶装置１１０９が設けられるが、この記憶装置１１０９は、通常、ハードディスクドライブ１１１０及びフロッピー（登録商標）ディスクドライブ１１１１を含む。磁気テープドライブ（不図示）を使用しても良い。ＣＤ−ＲＯＭドライブ１１１２は、通常、不揮発性のデータソースとして設けられる。コンピュータモジュール１１０１の構成要素１１０５から１１１３は、通常、相互接続バス１１０４を介して、コンピュータシステム１１００の動作モードが、当業者には既知の従来の動作モードになるように通信を行なう。上述の構成が実施されるコンピュータの例としては、ＩＢＭ−ＰＣ及びその互換機、Sun Sparcstation、又はそれを進化させた同様のコンピュータシステムがある。
【００２８】
通常、アプリケーションプログラムはハードディスクドライブ１１１０に常駐し、プロセッサ１１０５による実行の際に読み出されて制御される。プログラムとネットワーク１１２０から取り込まれるデータとの中間記憶装置は、半導体メモリ１１０６を使用し、場合によってはハードディスクドライブ１１１０と協働させるように使用して達成されても良い。アプリケーションプログラムは、ＣＤ−ＲＯＭ又はフロッピー（登録商標）ディスク上に符号化された形でユーザに供給され、対応するドライブ１１１２又は１１１１を介して読み取られる場合もあれば、ネットワーク１１２０からモデム装置１１１６を介してユーザが読み取る場合もある。更に、このソフトウェアは、磁気テープ、ＲＯＭ又は集積回路、光磁気ディスク、コンピュータモジュール１１０１と別の装置との間の無線又は赤外線の伝送チャネル、ＰＣＭＣＩＡカードなどのコンピュータ可読なカード、及び電子メール送受信及びウェブサイトなどに記録された情報などを含むインターネット又はイントラネットを含む他のコンピュータ可読な媒体からコンピュータシステム１１００へとロードすることもできる。その他のコンピュータ可読な媒体を代わりに使用しても良い。
【００２９】
ここに記載する方法の一部は、１つ以上の集積回路などの専用ハードウェアにおいて実現されても良い。このような専用ハードウェアには、グラフィックプロセッサ、デジタル信号プロセッサ、又は１つ以上のマイクロプロセッサ及び関連メモリが含まれても良い。
【００３０】
２．０  データ構成要素及びビュー
後述のセクションでは、データ構成要素という用語が一般的な意味でデータの識別可能な単位を指すのに使用される。好適な構成では、このデータ単位は識別されるＸＭＬ要素又はＸＭＬ属性に対応する。そのデータに対してＸＭＬスキーマが存在する場合、データ構成要素を要素又は属性宣言（及び定義）と関連付けることが可能でなければならない。データ構成要素の名前はＸＭＬ要素又は属性の名前であると見なされる。
【００３１】
データノードはデータ構成要素であり、一意的に識別されるＸＭＬノードに対応する。データノードは、ＸＭＬツリーの単一のノードまで評価する単一のＸＰａｔｈ表現により識別することができる。あるいは、特定の要素がＸＭＬ文書の繰返し構造の一部として存在することができる。例えば、要素Ａ、Ｂ、及びＣを有する以下に示すＸＭＬ文書の断片では、
＜Ａ＞＜Ｂ＞....＜／Ｂ＞＜Ｃ＞....＜／Ｃ＞＜／Ａ＞
＜Ａ＞＜Ｂ＞....＜Ｂ＞＜Ｃ＞....＜／Ｃ＞＜／Ａ＞
など、要素Ｂは、Ａの繰返し構造内で出現する。全てのＢ要素がＸＭＬ文書の断片から抽出されたものであり、例えば、表の列として提示される場合、データの集合はデータセットと呼ばれる。データセットは、反復子及びこれに関連するパス（ＸＰａｔｈ表現）により識別することができる。上述の例の場合、Ｂは反復子「/A」を有するデータセットであり、この反復子に関連するパスは「B」である。
【００３２】
更に、Ｂが数値を表す（すなわち、量で表せる）場合、要素Ｂはデータシリーズとして機能することもできるであろう（要素Ｃに対して）。換言すれば、ＢはＣに関してグラフ化することができる。データシリーズはデータセットを特殊化したものである。データシリーズの識別には、反復子（データセットに関して）、パス（データセットに関して）、及びラベル又は独立軸（すなわち、ｘ軸）のパス関連データセットの反復子が必要である。このため、上述の例においてＢが数値の場合、ラベルパス「C」を有するデータシリーズとして機能することもできるであろう。
【００３３】
代替の実現例によれば、データシリーズのラベルを本開示の趣旨から逸脱することなく更なるデータセットとすることもできる。しかし、データシリーズに対する反復子とその独立データセットとが異なる場合、独立データセットと従属データセットとの間の対応を推定するのに特別な知識が必要となる。
【００３４】
各エンティティは特定の要素宣言と関連付けられているので、データノード、データセット、及びデータシリーズは、データ構成要素を特殊化したものと見なすことができる。従って、以下の記述では、データ構成要素という用語はプロセスが一般的な用語で説明されるときに使用される。しかし、特定の例の説明の際には適切な用語が使用される。例えば、表の表示方式の各列をコピーするプロセスの説明の場合、表の列はデータセットと呼ばれる。
【００３５】
データブラウジングアプリケーション１２０により、ユーザは関心の対象であるデータソース上で個別化されたデータのビューを作成することができる。個別化されたデータのビューは以降「データビュー」と呼ぶ。個別化は、１つ以上のマッピングの使用の可能性を意味する。マッピングは関心の対象のデータソースからのデータをデータビューでユーザが所望する形式へとマップするのに役立つ。換言すれば、マッピングは、１つ以上のデータソースからの１つ以上のデータ構成要素が、データビューの一部である新規の目標データ構成要素へと改名、変換、又は結合される方法を定義する。新規の目標データ構成要素はマッピング無しの（ソース）データ構成要素よりも有意味であるのが好ましい。目標データ構成要素は、ユーザにより作成されるマッピングを保持するように作成される固有のネーム空間に存在するのが好ましい。マッピングのソースデータ構成要素は、参照される任意のネーム空間に存在しても良く、その定義はインターネット上に配置可能な任意のスキーマに格納されても良い。このマッピングプロセスは図２に示される。
【００３６】
例えば、ユーザはＭｙＮａｍｅという名前の目標データ構成要素を作成しても良い。この目標構成要素は、ソースデータ構成要素ＳｅｃｏｎｄＮａｍｅ及びＦｉｒｓｔＮａｍｅをhttp://www.example.com/abcなどのネーム空間から取り出し、これらをＳｅｃｏｎｄＮａｍｅ，ＦｉｒｓｔＮａｍｅの形式で表現し、結果として生じるデータ構成要素を大文字へと変換するマッピングを有しても良い。換言すれば、ユーザは「SMITH, JOHN」の形式のデータを目標データ構成要素ＭｙＮａｍｅのインスタンスとして見るであろう。ユーザは、任意の１つの目標データ構成要素に対して２つ以上のマッピングを指定することができる。また、ユーザはマッピングにより使用されるソースデータ構成要素がユーザのデータのビューから削除されるべきであるか否かを指定することもできる。上述の例では、ユーザが自身のデータビューにおいてＭｙＮａｍｅ、ＳｅｃｏｎｄＮａｍｅ、及びＦｉｒｓｔＮａｍｅを見ることを希望しない場合もあるので、このような指定が望ましいであろう。
【００３７】
既存のソースデータ構成要素を結合、交換、又は変更するであろう新規の目標データ構成要素を作成する目的は、より分かりやすく整合性のあるデータのビューをユーザに対して提供することである。換言すれば、定義されたマッピングは、データ変換の発生を意識させることなくユーザに対してデータのビューを提供するのに使用することができる。ユーザが最終的に対話するデータビューは、リレーショナルデータベースの２つ以上の表の結合を実行する可能性のあるデータベース管理者により構築されるビューに類似している。データビューは主に３つの点で異なっている：
（１）データビューは２つ以上の異質なデータソースの結合を効果的に提供することができる
（２）データビューはデータソースに対して存在するように定義されるデータ構成要素から得られる新規の（マッピングされた）データ構成要素を含んでも良い
（３）データビューはデータ構成要素に対して提示仕様を含んでも良い
データビューは、本質的には、異なるデータソースからのデータを結合することができる問合せである「リッチな」問合せとして理解することができ、ソースデータ上で名前付け及びデータ変換を実施すると共にデータ固有の提示特性を強化することができる。データブラウジングアプリケーション１２０において、データビューはデータビュー定義により定義される。この定義は、データビューに対するデータが得られる方法を指定するＸＱｕｅｒｙ表現を含む。また、定義は、データビューに対するその他の情報（例えば、エクスポートされたマッピング、提示規則、データビューのプロパティなど）を含むこともできる。データビュー定義についてはセクション１１．０において更に詳細に説明される。最も単純な形式では、データビュー定義は問合せ文字列としてのデータソースのＵＲＩに付加することができるＸＱｕｅｒｙ表現である。
【００３８】
データビューはライブデータから動的に生成される。換言すれば、データブラウジングアプリケーション１２０は、２つ以上のデータソースからデータを得るか、あるいは、データの変換を必要とするデータビューを格納しない。ユーザがデータブラウジングアプリケーション１２０においてデータビューを見ることを選択すると、データビューの問合せが実行される。この結果、データは１つ以上のデータソースから動的に収集され、適切にマップされ、提示される。
【００３９】
上述のように、データベース管理者は、従来より、表の定義及びこれに含まれるデータフィールド及び関係を扱えるようにするツールを使用してデータのビューを作成する役割を持つ。ユーザが個別化されたデータビューを作成する１つの方法としては、関心の対象のデータソースのスキーマ（又はデータ辞書）と対話する方法がある。このスキーマは、関心の対象のデータソース内に含まれるデータのクラス及びデータ間の関係を示す。
【００４０】
データブラウジングアプリケーション１２０において、「スキーマビュー」は１つ以上のデータソースのスキーマを表現するのに使用される。スキーマビューは、データソース内に含まれるデータのクラスとデータ間の関係とを示す。データビューとは異なり、スキーマビューはインスタンスデータを含まない。スキーマビューは、概念的に、リレーショナルデータベース管理システム（例えば、Ｍｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓ（登録商標））の表とこれと関連付けられた列とのグラフ表現に類似する。
【００４１】
スキーマビューは、データブラウジングアプリケーション１２０により受信されるデータのＸＭＬ形式と一致する階層化形式でデータのクラスを表示する。データのクラス及びこの相互関係は、Ｗ３Ｃ勧告であるＸＭＬスキーマ（http://www.w3.org/XML/Schema参照）を使用して定義されるのが好ましい。これは、データソース中のデータが１セットのリレーショナルテーブルに格納される場合、このデータソースのスキーマビューがデータソースのＸＭＬスキーマ定義から得られ、本質的に階層化されているであろうことを意味する。スキーマビューの機能は、新規のデータビューを構築することができるデータのユーザクラスを示すことである。
【００４２】
図３を参照して、選択されたデータソースのスキーマビューを表示する方法を説明する。このプロセスにより使用されるマッピングの作成はセクション３．０及び４．０において説明される。スキーマビューは、ユーザが新規のデータビューの構築を希望する際に表示されるのが好ましい。データブラウジングアプリケーション１２０により表示されるスキーマビューは、ユーザが選択したデータソースに依存する点において動的であると同時に通常は部分的である。データブラウジングアプリケーション１２０においてセッションを開始すると、データブラウジングアプリケーション１２０によりユーザをマッピングのセットと自動的に関連付けることができる。これらは、ユーザの作業環境又はアプリケーション設定の一部と見なすことができる。また、データブラウジングアプリケーション１２０の実行により、ユーザは図３のステップ２００に示すように、使用するマッピングのセットを選択することができる。データブラウジングアプリケーション１２０は、ステップ２０２において、ユーザが関心のある複数のデータソースを選択できるようにする。データブラウジングアプリケーション１２０は、ステップ２０４において、選択されたデータソースに含まれるデータ構成要素に対してスキーマ定義を識別し、これらのスキーマ定義からソースの初期のスキーマビューを形成する。
【００４３】
図４を参照して、ステップ２０４を更に詳細に説明する。ユーザがステップ２０２においてデータソースを選択した後、データブラウジングアプリケーション１２０は、ステップ３０２において、そのデータソースと関連付けられたＸＭＬ要素を識別する。ステップ３０４において、システムはその要素に対してＸＭＬスキーマ定義を配置する。これには、その要素に対して定義されたネーム空間中の定義の検索が必要である。好適な構成では、この検索は、そのネーム空間に対して生じたあらゆるスキーマ文書を最初に識別することにより実行される。これらのスキーマ文書は、ＸＭＬ文書又はその他のスキーマで提供されるＸＭＬスキーマｓｃｈｅｍａＬｏｃａｔｉｏｎヒントによって生じたものであっても良い。生じたスキーマは、例えば、ローカルコンピュータシステム１００のメモリ１１０６内のデータブラウジングアプリケーション１２０のローカルキャッシュに格納されるのが好ましい。あるいは、生じたスキーマは、必要に応じて、インターネット１０１中から取り出して再解析することができる。要素に対する定義が配置されている場合、データブラウジングアプリケーション１２０は、ステップ３０６において、その定義に対して可能な限りの子要素定義及び属性定義を再帰的に配置しようと試みる。属性定義は、表示されるスキーマビューの色により子要素定義と区別されるのが好ましい。また、属性名の前に＠などの意味を持つ記号を付加することもできる。配置された定義は、ステップ３０８において、ツリー構造として表現される。このツリー構造は、図３のステップ２０４の初期のスキーマビューを形成する。ステップ２０４のサブルーチンはステップ３１０で終了する。
【００４４】
図３に戻ると、識別されたマッピングセットと関連付けられたマッピングが処理される。セットの第１のマッピングはステップ２０６において選択される。データブラウジングアプリケーション１２０は、ステップ２０８において、マッピングが必要とする全てのソースデータ構成要素が現在のスキーマビューに存在することを確認する。存在する場合、制御はステップ２１４へと進み、マッピングが適用される。これは、現在のスキーマビューにおいて目標データ構成要素に対する定義を作成し、必要に応じて、関連するソースデータ構成要素定義の一部又は全部をスキーマビューから削除することを伴う。好適な構成では、作成された目標データ構成要素定義は、表示色を使用するスキーマビューにおいてネイティブスキーマ構成要素定義から強調表示される。これは絶対必要な訳ではなく、どの構成要素定義がマッピングから得られたものであるかをユーザに対して明確に示す場合にのみ実施すれば良い。
【００４５】
尚、マッピングはスキーマビュー及びデータビューの双方に適用することができる。マッピングがスキーマビューに適用される場合、目標データ構成要素に対してスキーマビューにおいて定義が作成され、マッピングの１つ以上のソースデータ構成要素に対して定義がスキーマビューから任意で削除される。マッピングがデータビューに適用される場合、マッピングの１つ以上のソースデータ構成要素に対応するデータ構成要素が、マッピングに従ってマッピングの目標データ構成要素に対応するデータ構成要素へと変換される。
【００４６】
マッピングが処理されると、スキーマビューがステップ２１６において更新される。更新されたスキーマビューは、ディスプレイ１１１４によりユーザに対して表示されるのが好ましいが、選択されたマッピングと関連付けられる全てのマッピングが処理されたときに更新されたスキーマビューを表示することも可能である。ステップ２１６が終了すると、データブラウジングアプリケーション１２０は、ステップ２１０において、更に処理すべきマッピングが存在するか否かをチェックする。存在する場合、ステップ２１２において、次のマッピングが得られ、制御はステップ２０８へと戻る。ステップ２０８において、マッピングが必要とする全てのソースデータ構成要素に対する定義が現在のスキーマビューにない場合、マッピングは処理されず、制御はステップ２１０へと進む。これ以上のマッピングがない場合、手順はステップ２２０で終了する。
【００４７】
図３を参照して説明した手順は、ユーザインタフェースを使用して達成することができる。この一例が図６に示される。図６は、表示装置１１１４により再生されるであろうグラフィカルユーザインタフェース（ＧＵＩ）画像６００を示す。ＧＵＩ６００の最上部で、広く用いられるデータソースのリスト６０１がユーザに対して提示される。ユーザは、例えば、マウスポインタ１１０３を操作することによって、選択されたデータソースを強調表示しながらデータソースの１つ以上を選択することができる。この例では、選択は枠に囲まれたデータソースにより強調されている。選択するごとに、図３を参照して説明したプロセスを使用して形成されるスキーマビューを伴って、リスト６０１の下方のパネル６０２が直ちに更新される。ユーザは、希望通りにデータ構成要素定義に対する印を展開したり折りたたんだりしながら、スキーマビューパネル６０２を見て回ることができるのが好ましい。データ構成要素定義を表現するために使用される印は、要素の名前から得られるのが好ましい。しかし、他の要素情報、例えば、スキーマ中の要素と関連付けられた文書化ノードもスキーマビュー中のデータ構成要素を表現するのに使用することができるであろう。
【００４８】
図３に示すプロセスを使用して構築されるスキーマビューは、選択されたデータソースにまたがって新規のデータビューに対する制約を収集するのに使用することができる。スキーマビュー中の結合に対して、制約が接続的又は離接的に収集されても良い。動的に構築されたスキーマビューによりユーザのマッピングの観点からデータビューを指定することができる。データビューがユーザに対して提示される場合、ソースデータを取得するために、可能な限りマッピングを反転させることによってマッピングをソースデータ構成要素へと分解しなければならない。場合によっては、マッピング反転の一部の責任をデータサーバに負わせることも必要である。例えば、目標データ構成要素Ｘが文字列ソースデータ構成要素Ａ、Ｂ、及びＣの連結であるように定義され、ユーザが制約Ｘ＝「Hello, Mr Jones」を入力する場合、データから離れた制約を効率的に反転することは難しい。好適な構成では、ソースデータ構成要素が単一のデータソースから得られたものである場合、ＸＱｕｅｒｙ要求の「LET」節が可能な限り使用され、Ｘに対する制約が直接使用されるようにＸに対する変数が定義される。
【００４９】
明らかに、このソリューションは、全てのソースデータ構成要素が１台のデータサーバから生じるものである場合にのみ実現可能である。ＸＱｕｅｒｙ定式化における反転が可能でない場合には、データブラウジングアプリケーション１２０は、ソースデータの受信後に制約を処理しなければならない。しかし、マップされた構成要素に対する制約は、問合せがデータサーバに渡される前に可能な限り反転される。
【００５０】
好適な構成では、問合せに応じてデータサーバ１４０から１４３から戻されるときに、データは関連するマッピングにより定義される変換に従ってデータブラウジングアプリケーション１２０により変換される。これは、データがユーザのマッピングの観点からユーザに対して提示されることを意味する。
【００５１】
構築されたデータビューは他のユーザと交換することができる。このとき、作成時にデータビューにより使用されるマッピングのうちのいずれかが直列化され、データビューの定義と共にパッケージ化される。新規のユーザが別のユーザからデータビューを受信するときには、直列化されたマッピングを使用してデータビューが作成時と同様であるかが確認される。新規のユーザは、データビューに含まれるマッピングを新規のユーザの独自のマッピングセットへとインポートすることができる。データビューを共有し、マッピングをインポートするこのプロセスは、セクション１１．０で更に詳細に検討される。
【００５２】
３．０  マッピングのインタラクティブな定義
マッピング作成プロセスを図５のフローチャートを参照して説明する。プロセスはローカルコンピュータシステム１００内でプロセッサ１０５により実行される別個のアプリケーションプログラムとして実現されても良い。好適な構成では、プロセスはデータブラウジングアプリケーション１２０に組み込まれる。ステップ５００において、ユーザはデータ構成要素定義が新規のマッピングに対するソースデータ構成要素として選択されるデータソースを選択する。図３を使用して説明したように、ステップ５０２において、選択されたデータソースに対するスキーマビューが構築され、ユーザに対して表示される。スキーマビューはツリーとして表示されるのが好ましい。このツリーにおいて、ユーザは、図６と同様の方法で各ノードを展開したり折りたたんだりすることができる。この初期のスキーマビューの各データ構成要素定義は、ユーザによる選択が可能な印により表現される。最も単純な形式では、この印は上述のようなデータ構成要素定義の要素名である。ユーザは、新規の目標データ構成要素がステップ５０４で作成されることを示す。ステップ５０６において、ユーザはスキーマビューから印を選択することが可能になり、関連するデータ構成要素定義がマッピングに含まれることを示す。このため、例えば、２つ以上のソースデータ構成要素の連結となるように目標データ構成要素が作成される場合、ユーザは連結に対する第１のソースデータ構成要素定義を表現する印の上でダブルクリックしても良い。目標データ構成要素に対する型定義は、デフォルト設定で初期化ソースデータ構成要素の型になる。型情報は、ＸＭＬスキーマ型定義により表現されるのが好ましい。図５の構成では、ステップ５０４及び５０６が初期化ソースデータ構成要素に対する単一のアクションとして実行される。
【００５３】
初期化ソースデータ構成要素定義が選択されると、図７Ａに示すようなＧＵＩウィンドウ７００がディスプレイ１１１４に表示される。初期の画面上では、ＧＵＩウィンドウ７００は初期化ソースデータ構成要素と同じ名前の目標データ構成要素を示す。この名前を有する構成要素がユーザのネーム空間に既に存在する場合、ユーザはこの名前（目標名）に更なるマッピングを追加することを希望するか否かを尋ねられる。ユーザがこれを確認する場合はアクションは不要である。ユーザがプロンプトに対して「いいえ」と応答する場合、目標名にフォーカスが設定され、ユーザは名前を適切に変更するように要求される。
【００５４】
図７Ａに示す例示のＧＵＩウィンドウの場合、ユーザはＳｅｃｏｎｄＮａｍｅからＭｙＮａｍｅへと目標名を変更することを選択している。
【００５５】
単純な実現例では、全ての目標名はコンテキスト（すなわち、ＸＭＬスキーマ文書中のスキーマ要素の直接の子である要素宣言により表現することができる名前）を持たず、ユーザのネーム空間に割り当てられる。代替の実現例では、ユーザはネーム空間において何らかの構造を指定しても良く、目標データ構成要素も階層コンテキストを有することができるであろう。例えば、図７ＡのＧＵＩ７００では、「好適な用語」にはコンテキストがない（すなわち、別の指定された要素内に含まれない）。ユーザのネーム空間内のコンテキストが指定される場合、ユーザは好適な名前の一部としてコンテキストを入力することができるであろう。また、ＧＵＩは既存のコンテキストが選択可能な状態、あるいは、新規のコンテキストを作成可能な状態でウィンドウを表示しても良い。
【００５６】
ステップ５０８において、ソースデータ構成要素に対する１セットのデータ例が、選択されたデータ構成要素が定義されたデータソースから得られる。得られる例の数は、予め定めておくことも、あるいは、マッピングを作成中の計算環境の種別によって決めることもできる。例えば、データソースがインターネット１０１上でアクセスされており、インターネットアクセスが低速のモデム（例えば、１１６）により提供されている場合、得られる例は少なくなるであろう。得られた例は、ステップ５１０において、例リストに追加される。例リストは、図７ＡのＧＵＩ７００中のリスト７２０として表示される。初期化ソースデータ構成要素の場合、得られた例は初期の例リストを表す。更なるソースデータ構成要素が選択されてマッピングに含まれると、例データがリスト中の各例の末尾に追加される。
【００５７】
例えば、ソースデータ構成要素ＳｅｃｏｎｄＮａｍｅが選択される場合、例リストは以下のように見えるであろう：
Smith
Jones
BROWN
WU
Hetherington
など
尚、一部の名前は完全に大文字であるが、他のものはそうではない。
【００５８】
更なるソースデータ構成要素ＦｉｒｓｔＮａｍｅが選択される場合、例リストは以下のように見えるであろう（図７Ｂ参照）：
SmithAlan
JonesJenny
BROWNLouise
WUJulie
HetheringtonRupert
など
例のリスト７２０は２つの目的を達成する。第１に、リスト７２０はデータがデータソースに実際に格納される方法をユーザに対して示す。ごく少数の（データベース）スキーマが、データが収集されデータベースへと同化されたときに準拠したであろう表記上の標準を強調表示する。また、この情報が存在する場合は、通常、非常に詳細に説明される。例により標準を説明する方がデータのユーザにとってはるかに分かりやすいことが多い。例えば、上述の例では、ソースデータ構成要素ＳｅｃｏｎｄＮａｍｅにより定義されたデータが文字の一貫性（すなわち、大文字又は小文字が使用されている）にあまり注意を払わずに編集されているとユーザは推論するかもしれない。この情報に基づいて、ユーザは、このデータがユーザのビューにおいて全て大文字であるか、あるいは、小文字であるかを確認するための関数を適用することを選択しても良い。
【００５９】
例リスト７２０の第２の目的は、ユーザがマッピングを定義するための直観的な方法を提供することである。通常、マッピング変換を定義するタスクは、システム管理者又は他の同様に熟練した人間に任せられる。これは、マッピングの作成が、通常、関数的且つ数学的なプロセスの理解を必要とするからである。ソフトウェアエンジニアは、ソースデータ構成要素手段に適用されるtoUpperCase()、insert(6, "/test")といった一連の単項関数がデータを取り、大文字に変換し、文字列「／ｔｅｓｔ」を結果として生じる文字列の位置６に挿入することを理解するであろうが、平均的なユーザはこのような手段を適用して変換を作成することに満足しないかもしれない。この表記法は、位置インデックスが０ベース方式か、あるいは、１ベース方式かを理解しないユーザにとっては更なる困難となる。
【００６０】
好適な構成は、例リスト７２０から一例を選択し、選択された例を編集して所望の目標データ構成要素の形式を実証できるようにすることによってこれらの変換を示す手段をユーザに対して提供する。例えば、上述の例では、ユーザは「JonesJenny」の例を選択し、編集して「JONES, Jenny」を読むことができるであろう。データブラウジングアプリケーション１２０は、編集された例を分析し、適用された関数の推定を試みる。この場合、単項関数toUpperCase()がＳｅｃｏｎｄＮａｍｅソースデータ構成要素へと適用され、コネクタ「,」が２つのソースデータ構成要素間に付加される。この推定の結果が図７Ｃに示される。マッピングが必要とする変換を推定するのに使用される方法については、更に詳細に後述する。
【００６１】
ユーザは、幾つかの提示特性を目標データ構成要素のデータに適用することもできる。例えば、このような提示特性は、目標データ構成要素のＳｅｃｏｎｄＮａｍｅ部が太字又は特定の色で常に表示されるように規定しても良い。この特性は、実証により適用することができ、受信データを変換する際に使用すべく格納することができる。
【００６２】
（編集された）例を使用して所要の変換を実証することによってユーザが変換を定義できるようにする上述の方法は、「例に基づくプログラミング」、すなわち、ＰＢＥとして知られる技術の一例である。ＰＢＥは、ユーザにより提供される１セットの例からの正規の表現の推定、ウェブ上で定期的にアクセスされる情報の収集・照合、ユーザインタフェースにおける繰返しタスクの検出・自動化、及び文法（例えば、電子メールアドレスなど）の定義などのプログラミングタスクのために以前から使用されている技術である。これらのタスクは、変換を定義するタスクと同様に、通常、アクション又はデータのクラスに対する抽象化又は一般化（例えば、定式、文法規則）の識別を必要とする。一般的に、人間は、関数の変換及び文法規則などの抽象化よりも具体例について考える方が楽なようである。先に簡単に説明した変換をインタラクティブに定義する方法は、編集された例を使用するため、先行技術で使用されるようなデータに適用する１セットの関数を選択することに基づく方法よりも多くの人にとって直観的である。
【００６３】
好適な構成がマッピングを行なうのに使用するＧＵＩを図７Ａ、図７Ｂ、及び図７Ｃを参照して説明する。ＧＵＩの分野では、「ボタン」という用語は、例えば、マウス１１０３を使用することによってユーザ選択可能なアイコンに対する口語的な名前であることが認識されるであろう。目標データ構成要素の名前はテキストフィールド７０１に示される。目標データ構成要素フィールド７０１と関連付けられるのは「提示」ボタン７０２及び「定義」ボタン７０３である。「提示」ボタン７０２は、目標データ構成要素に適合するデータに対する提示詳細を見る又は編集するのに使用することができる。この機能については詳細に後述する。「定義」ボタン７０３により、ユーザは目標に対する型定義情報を編集することができる。単純な実現例では、ユーザは目標要素の定義に対してＸＭＬスキーマテキストを直接編集しても良い。代替の実現例により、ユーザの編集動作を厳しく制御するインタフェースを提供しても良い。多くの変換にとっては型情報の編集は不要なものである。この機能は、主に上級ユーザが完全を期す目的で好適な構成に含まれている。
【００６４】
初期化ソースデータ構成要素は、マッピングワークスペース７１０中の第１のソースデータ構成要素として示され、ソースデータ構成要素の名前はテキストフィールドダイアログボックス７１２に示される。関数セレクタ７１３はテキストフィールド７１２に隣接して示されており、手動の関数選択を使用して必要に応じて自動プロセスを補足できるようにする。利用可能な単項関数のドロップダウンメニューがセレクタ７１３から選択されるのが好ましい。手動選択及び関数の編集は必ずしも必要ではなく、上級のユーザに対して自動的な方法を補足するためだけに提供される。また、マッピングワークスペース７１０における各ソースデータ構成要素は、「情報」ボタン７１４及び「提示」ボタン７１５と関連付けられる。「情報」ボタン７１４は、ユーザがマッピングを定義するのに役立つであろう情報を表示するのに使用される。好適な構成では、「情報」ボタン７１４はソースデータ構成要素に対するＸＭＬスキーマ定義中の＜ｄｏｃｕｍｅｎｔａｔｉｏｎ＞タグと関連付けられたコンテキストを示すのに使用される。「提示」ボタン７１５は、ソースデータ構成要素により定義されるデータに適用される提示特性を割り当てる／編集する／見るのに使用することができる。
【００６５】
ワークスペース７１０中の各ソースデータ構成要素の前にはコネクタ７１１が付加される。コネクタ７１１は、コネクタテキスト、２項演算子（数学関数＋、−、／、又は＊など）、又はｎ項演算子（ｍｉｎ、ｍａｘ、ｓｕｍなど）を含んでも良い。マッピングワークスペース７１０の下方には例パネル７２０がある。図７Ｃにおいて、このパネルは上述の編集された例の結果を示す。推定されたソリューションの結果も関数セレクタ７１３に反映される。関数セレクタ７１３では、識別される人の姓が大文字形式で提示されることを定めるために、単項関数toUpperCase()が、ＳｅｃｏｎｄＮａｍｅという名前のソースデータ構成要素に適用されているのが図７Ｃに示される。図示するように、２つ以上のテキストフィールド７１２及び対応する補助構成要素がマッピングワークスペース７１０に含まれても良い。この例では、図７Ｃに示すように、コンマ「,」及びスペース１文字を含むコネクタ７１１ｂがユーザにより定義され、ＦｉｒｓｔＮａｍｅの前に置かれる。
【００６６】
チェックボックス７０５は、ソースデータ構成要素により使用される名前のコンテキストの表示を制御するためにチェックすることができる。コンテキストは、スキーマビュー中のソースデータ構成要素の階層位置を定義する。例えば、図６から明らかなように、ＳｅｃｏｎｄＮａｍｅソースデータ構成要素のコンテキストは、HumanResources/Research/AppliedTechnology/Managersである。コンテキストは上述の例により示すように長くすることができるが、データ構成要素の名前にコンテキストを含めるとインタフェースの外観が複雑になる。ＧＵＩ７００に表示されない場合でも、各ソースデータ構成要素のコンテキストはマッピングの一部として格納される。代替の実現例では、ソースデータ構成要素に対するコンテキストは、「情報」ボタン７１４が選択されたときにユーザに対して提示される情報として含めることができる。
【００６７】
図５において、初期化ソースデータ構成要素をマッピングワークスペース７１０へと含めるべく選択すると、ユーザはステップ５１２において、マッピングが更なるソースデータ構成要素を含むか否かを決定することができる。ソースデータ構成要素を含む場合、制御はステップ５０６へと戻り、ユーザは表示されたスキーマビューから所望のソースデータ構成要素の印を選択し、マウスポインタ１１０３を使用して印をドラッグし、マッピングワークスペース７１０にドロップすることができる。ドロップ位置がマッピングの既存のソースデータ構成要素の上である場合、データブラウジングアプリケーション１２０は、ソースデータ構成要素がドラッグされた構成要素により置き換えられることを想定する。ソースデータ構成要素を含まない場合、ドラッグされた構成要素はソースデータ構成要素のリストの末尾に追加される。この結果、例リスト７２０はステップ５１０において説明したように再度更新される。このプロセスは、ユーザが全ての必要なソースデータ構成  要素がマッピングワークスペースに存在すると決定するまで継続される。
【００６８】
ソースデータ構成要素がマッピングワークスペースへと移動される順序が重要となる可能性がある。例えば、ユーザが変換Ｘ＝（Ａ＋Ｂ）／Ｃに基づいた新規の数値目標を作成することを希望する場合、ソースデータ構成要素Ａ、Ｂ、及びＣはＡ、Ｂ、及びＣ又はＢ、Ａ、及びＣの順序でマッピングウィンドウへと移動されなければならないだろう。
【００６９】
ステップ５１４において、ユーザが例リスト７２０から編集する一例を選択する。この動作により選択された例は強調表示され、ユーザはその例を文字列として編集し、データに適用されるべき所要の変換をシステムに対して実証することができる。このような例では、関数セレクタ７１３を使用して関数を選択する必要がない。ユーザがキーボード１１０２上の「リターン」を押下してユーザが例の編集を終了したことを示すと、データブラウジングアプリケーション１２０はユーザの例により示された変換の推定を試みる。
【００７０】
推定ステップ５１８が終了すると、ステップ５２０において、結果の推定された変換に従って図７Ｃの例リスト７２０が更新される。これは、変換が推定されたことをユーザに対して明確に示すのに役立つ。ステップ５２２において、ユーザ観察により判定されるように、推定されたマッピングが正しいと判明した場合、ステップ５２４においてマッピングが格納される。ステップ５２６において、目標データ構成要素を伴って現在のスキーマビューが更新され、ステップ５２８において、マッピング作成プロセスが終了する。
【００７１】
ユーザが所望した変換を推定ステップが正確に推定しなかった場合、ユーザは別の例を選択し、正しい結果が得られるまでプロセスを繰り返すことができる。図８を参照して後述する推定ステップは、編集された例の部分に対してのみソリューションを見つけようと試みる。図７に示す例では、ＦｉｒｓｔＮａｍｅは編集されていないので、分析には含まれないであろう。
【００７２】
上述の図５のプロセスは、マッピングが必要とする変換の関数の編集により補足することができる。例えば、好適な構成では、ユーザはリストから関数を選択し、データをマッピングの一部として適用することもできる。特定のソースデータ構成要素に対してこの関数を関数リストに追加することも、リストから削除することもできる。また、関数のパラメータのみを編集することもできる。図７Ａの関数セレクタ７１３によりこの機能が実現される。
【００７３】
階層コンテキストがマッピングに含まれるソースデータ構成要素の最大共通コンテキストであるように、マッピングに対する目標データ構成要素が現在のスキーマビューに追加される。例えば、目標データ構成要素が、コンテキストＡ／Ｂ／Ｃ，Ａ及びＡ／Ｂ／Ｃ／Ｄを有する３つのソースデータ構成要素を有するように定義される場合、ビュー中の目標のコンテキストはＡであるだろう。先に説明したように、ユーザはマッピングと関連付けられるソースデータ構成要素がスキーマビューから削除されるか否かをマッピングごとに指定することができる（すなわち、ソースデータ構成要素と関連付けられるデータはこのスキーマビューから得られるデータビューに出現しない）。ユーザは、図７Ｃのソース構成要素削除チェックボックス７１６をチェックすることにより特定のソースデータ構成要素が削除されることを示す。
【００７４】
図１０Ａは、マッピングが適用される前の初期のスキーマビューを示す。このスキーマビューでは、スキーマ構成要素ＳAがデータ構成要素Ａ、Ｂ、及びＣを含み、データ構成要素Ｂが更にデータ構成要素Ｄ及びＥを含む。図１０Ｂは、マッピングと関連付けられたソースデータ構成要素を削除せずに、データ構成要素Ｄ及びＥから得られる目標データ構成要素Ｚをスキーマビューに追加した結果を示す。図１０Ｃは同様のスキーマビューを示すが、ソースデータ構成要素を削除した場合である。ユーザは、マッピングに含まれる各ソースデータ構成要素に対してこのプロパティを定義することができるのが好ましい。換言すれば、マッピングの一部のソースデータ構成要素を削除する一方で、他のものを保持することができる。
【００７５】
目標データ構成要素が２つ以上のマッピングと関連付けられる場合、好適な構成では、目標データ構成要素も種々のマッピングのコンテキストの最大共通コンテキストである階層コンテキストを有するスキーマビューへと挿入される。この動作によりユーザは目標データ構成要素を操作し、単一の制約を使用して複数のデータソースからデータを選択することができるので有用である。
【００７６】
マッピングが定義されている場合、「保存」ボタン７３０の選択によりマッピングが格納される。このような動作は、新規の目標データ構成要素を伴って現在のスキーマビューを更新するのに使用するのが好ましい。
【００７７】
４．０  編集された例からのマッピング変換の推定
ユーザ編集された例からマッピングと関連付けられた変換を推定する方法を図８を参照して説明する。図８は、ローカルコンピュータ１００のメモリ１１０９に格納され、対応するプロセッサ１１０５によりデータブラウジングアプリケーション１２０の一部として実行されるコンピュータアプリケーションプログラムの典型のフローチャートである。方法は、ユーザが編集された例を分析するために提出することにより開始される。このような提出はＧＵＩ７００により行なわれても良い。最初のステップ８００において、データブラウジングアプリケーション１２０は空のソリューションリストを作成する。ステップ８０２において、２項関数又はｎ項関数が可能であるか否かを決めるために判定が実行される。（ｉ）２つ以上のソースデータ構成要素が変換に含まれる場合及び（ii）少なくとも１対の連続ソースデータ構成要素が２項関数又はｎ項演算に関与することができる（例えば、数値データ型を有する）場合にのみ、２項関数又はｎ項関数が考慮されるのが好ましい。尚、連結は厳密には２項演算であるが、分析において、連結はデフォルトの２項演算子として扱われる。
【００７８】
２項関数又はｎ項関数が可能である場合、制御はステップ８０４へと進む。ステップ８０４において、データブラウジングアプリケーション１２０は選択された例に対するソースデータ構成要素ごとに単項のコンテンダのリストを作成する。単項のコンテンダは、１つ以上の所定の単項関数をソースデータ構成要素に対する未編集の例データに適用した予想結果である。単項関数は単一のソースデータ構成要素上で動作する関数として定義される。好適な構成では、単項関数は順次適用することができ、任意の順序で適用可能な関数の最大数は３である。明らかに、順次適用可能な関数の数に関しては、他の限度値を用いることもできる。換言すれば、シーケンス中の各単項関数は、前の関数適用ステップの結果に適用される。本開示の趣旨から逸脱することなく、他の関数を実施することもできる。
【００７９】
【表１】
2004240954.tif 000003
【００８０】
実施される関数の各々は指定のオペランド型を有し、結果の明細は表１の第３列に示される。オペランド型条件が満たされない場合、関数を適用しても単項のコンテンダは得られない。初期のオペランド型は、ソースデータ構成要素のＸＭＬスキーマ定義の基本型から得られる。好適な構成では、これらの基本型は、表２に示すようなＩｎｔｅｇｅｒ（整数型）、Ｄｏｕｂｌｅ（倍精度浮動小数点数型）、及びＳｔｒｉｎｇ（文字列型）の基底型にマップされる。あるいは、ＸＭＬスキーマ基底型をマッピングアプリケーションの型として使用するのも好ましいであろう。この場合、表２に示す型マッピングは不要であり、表１のオペランド型はＸＭＬスキーマ基本型を含むであろう。
【００８１】
【表２】
2004240954.tif 000004
【００８２】
図８に戻ると、ステップ８０４において、例のソースデータ構成要素ごとに単項のコンテンダのリストが生成される。コンテンダがリストに追加される順序は以下の通りである：
（ｉ）不変のソースデータ構成要素、
（ｉｉ）単一の単項関数の適用により得られるコンテンダ、
（ｉｉｉ）２つの単項関数のシーケンスから得られるコンテンダ、及び
（ｉｖ）３つの単項関数のシーケンスから得られるコンテンダ
単項のコンテンダが作成される順序は、機能的に単純なコンテンダがリストの先頭に配置されるのが好ましく、ソリューションに含まれる可能性が高いという点において重要である。
【００８３】
ステップ８０６において、単項のコンテンダの各々が編集された例に存在するか否かが検査される。この検査は、ソースデータ構成要素ごとに単項のコンテンダリストをフィルタリングするように動作し、フィルタリングされたリストの各メンバは、編集された例において有効な開始位置及び終了位置を有するようになる。ステップ８０６により、フィルタリングされた単項のコンテンダリストが生成される。このリストは後述のステップ８１０で必要になる。制御はステップ８０７へと進む。ステップ８０７において、単項のコンテンダに基づくｎ項のソリューションが検出される。ｎ項のソリューションを検出するプロセスは、単項のコンテンダの全ての結合を検査することを含む。検出されたｎ項のソリューションはソリューションリストへと追加される。制御はステップ８０８へと進む。ステップ８０８において、単項のコンテンダに基づく２項のソリューションが検出される。好適な構成では、左から右へと演算するのに２項関数（又は演算）が想定される。換言すれば、演算のオペランドは、前の演算の結果＋新規のコンテンダとすることができる。可能な２項のソリューションを検出するプロセスは、単項のコンテンダの全ての結合を検査することを含む。各々の結合では、ソースデータ構成要素の各々からの貢献が順序付けられている。見つかった２項のソリューションはソリューションリストに追加される。
【００８４】
ステップ８０２において、２項関数又はｎ項関数が可能でなかった場合、ステップ８０４及び８０６に相当する処理が単一のステップ８１５へと合併される。合併によりソースデータ構成要素の各々に対して大規模な単項のコンテンダリストを格納する必要がなくなるため、これは有利である。
【００８５】
ステップ８０８及び８１５の各々に続くステップ８１０において、フィルタリングされた単項のコンテンダリストに基づくソリューションに対して検索が実行される。各ソリューションは、各ソースデータ構成要素に対するフィルタリングされた単項のコンテンダから構成される必要がある。ソリューションが更に必要とするのは、単項のコンテンダが編集された例において重複しないことである。例えば、第１のソースデータ構成要素に対する単項のコンテンダが、編集された例において文字位置３と１５との間に配置され、第２のソースデータ構成要素に対する単項のコンテンダが文字位置１０と２０との間に配置される場合、文字位置のセット間の重複により、これらのコンテンダはソリューションの一部とは見なされない。ステップ８１０で見つかったあらゆるソリューションがソリューションリストに追加される。
【００８６】
ソリューションリストにおける「最適な」ソリューションがステップ８２０で判定される。好適な構成では、ソリューションのコストは２つの要素に基づく：
（ｉ）編集された例におけるコンテンダ間のコネクタの全長と、
（ｉｉ）より単純なソリューションを見つけるべく推定方法にバイアスをかけるために個々の関数に割り当てられる重み
ソリューションはソリューションリストに追加された順序で検査される。ゼロコストのソリューションが見つかった場合、ステップ８２０は直ちに終了する。リストの後方のソリューションは、リストの前方のソリューションよりもコストが低くなければならない。コネクタは２項演算（すなわち、連結）の形式であるが、好適な構成では、ソリューションのコストへの重要な貢献者として扱われる。
【００８７】
例えば、コンテンダに対応する編集された例の各部分が枠で囲まれる以下のソリューションについて考察する：
【００８８】
2004240954.tif 000005
【００８９】
これは、各ソースデータ構成要素が正しい順序（すなわち、ＳｅｃｏｎｄＮａｍｅ、ＦｉｒｓｔＮａｍｅ、Ａｄｄｒｅｓｓ）で表現される場合のソリューションを表す。上述の例のコネクタコストは、コネクタの全長（2 + 11 + 1 = 14）に比例するものと考えられ、単項のコンテンダによらない文字の総数を使用して判定される。単項関数は、コンテンダの一部に対して使用されている可能性があるので（例えば、toUpperCase()）、ソリューションの最終コストは、コスティングの重みが使用される単項関数に割り当てられているか否かによって決まるであろう。
最適のソリューションが検出される場合、ステップ８２２において、マッピングが更新される。好適な構成では、これにより、マッピングワークスペース７１０中のソースデータ構成要素に対する関数リストが、任意の単項関数の名前（及びその識別された引数）を伴って更新される。コネクタフィールドも、最適なソリューションに必要なコネクタ文字列あるいは任意の識別される２項関数又はｎ項関数を伴って更新される（図７Ｃ参照）。例リストも新規のマッピングを使用して更新される。マッピングプロセスはステップ８３０で終了する。
【００９０】
マッピング変換を推定するプロセスは、ユーザが実行を希望する変換の種別によって変わる可能性がある。単項関数、２項関数、又はｎ項関数に関わらず、他の関数は本開示の趣旨から逸脱することなくプロセスへと導入されるであろう。好適な構成では、新規の単項関数、２項関数、及びｎ項関数の追加は比較的簡単である。なぜなら、このような追加は、ＵｎａｒｙＦｕｎｃｔｉｏｎクラス、ＢｉｎａｒｙＦｕｎｃｔｉｏｎクラス、及びＮａｒｙＦｕｎｃｔｉｏｎクラスのうちのいずれかを拡張するシステムにクラスを追加し、新規の関数を対応する関数リストに追加するだけで良いからである。新規の関数に基づくコンテンダは、直ちに生成が開始されるであろう。
【００９１】
図８を使用して説明されるプロセスは、マッピングの変換が最初から推定される（すなわち、前の推定セッション又はユーザが記録したであろう任意の手動で入力された変換に関して何の想定も行なわない）場合に続くプロセスである。場合によっては、単一の例の編集によりマッピングを明確に定義することは不可能であり、推定プロセスは編集された例の変更部分に対してのみ動作する。目的はマッピングの一部を改良することである。
【００９２】
好適な構成では、データブラウジングアプリケーション１２０は、現在の編集セッションでユーザが編集した例の部分のみを検出する。これは、既存のマッピングを改良できることを意味する。また、これにより、分析における余計な処理が不要になる。このため、例えば、初期のマッピングが３つのソースデータ構成要素を有し、ユーザが例を選択してこれらの構成要素のうちの２つと関連付けられたテキストのみを変更する場合、説明した推定方法はデータのサブセットにおいて実行される。推定方法は、どのソースデータ構成要素が変更により影響を受けるかを検出することによってこれを達成し、例の変更部分に対してのみソリューションを見つけようと試みる。
【００９３】
これにより実現が迅速になる。また、これは、プロセスがユーザの変更に対してより敏感に応答可能であることを意味する。例えば、ユーザが例を編集して、変更された例を分析すべくデータブラウジングアプリケーション１２０に提出し終えるのを待つのではなく、必要に応じて、分析をインタラクティブに部分的に実行することができる。ユーザが、ユーザインタフェースにおいて閾値距離よりも長い距離だけカーソルを移動させる場合、分析方法を開始して例の変更部分に対してのみソリューションを生成することができる。結果として生じるソリューションは、他の任意の変更に対応可能な状態で全体のマッピングソリューションへと統合される。マッピングソリューションを見つける革新的な方法により生じる問題の１つは、システムがユーザの変更に対して迅速に応答できなければならないことである。十分に迅速な応答を得るには、小規模の可能な関数のセットを実現する必要がある場合が多い。
【００９４】
例のテキストの編集と同様に、ユーザは、種々の提示特性を編集中の例に適用することもできる。例えば、好適な実現例では、ユーザは編集された例の部分に対してフォント種別、フォントサイズ、書式（例えば、太字、斜体、下線、上付き、下付きなど）、及び色特性を選択することができる。一度上述のプロセスを使用してソリューションを識別すると、データブラウジングアプリケーション１２０は、属性提示特性が適用される場合、それらをソースデータ構成要素のものとすることができる。提示特性は、常に、任意の構造的変換の適用後に適用されるものと想定される（すなわち、データが目標データ構成要素の一部として含まれる前に最後にソースデータ構成要素に適用される変換である）。
【００９５】
ユーザが提示特性を例全体に適用する場合、適用された特性は、ソースデータ構成要素とではなく、マッピングの目標と関連付けられる。従って、ユーザがマッピングに更なるソースデータ構成要素を追加する場合、このソースデータ構成要素のデータは、目標データ構成要素と共に格納される提示特性を取得することになる。しかし、提示特性が例の一部にのみ適用される場合、システムはどのソースデータ構成要素が影響を受けるかを推定し、これらのソースデータ構成要素のみを伴って提示特性を格納する。例えば、先に使用した名前の例では、ユーザはＭｙＮａｍｅの一部であるＳｅｃｏｎｄＮａｍｅを常に太字で表示することを希望しても良い。
【００９６】
2004240954.tif 000006
【００９７】
ユーザは、図７Ａに示す画面レイアウトＧＵＩにおいて対応する提示ボタン７１５を選択することによって、任意のソースデータ構成要素と関連付けられた提示特性を見ることができる。目標データ構成要素のものとされる提示特性は、対応する提示ボタン７０２を選択することによって見ることができる。好適な構成により、ユーザは目標データ構成要素及びソースデータ構成要素の双方の提示関数を使用して提示特性を手動で追加・変更することもできる。これは、ボタン７０２及び７１５ａをそれぞれ選択することによって達成されても良い。提示特性がソースデータ構成要素及び目標データ構成要素の双方に対して定義される場合、ソースデータ構成要素と関連付けられた特性は、目標データ構成要素の特性の前に適用されることになる。
データ集約にとって重要なマッピング変換の１つのクラスは、寸法（及び測定単位）又は通貨を有する値の変換である。現在、多くのデータソーススキーマは測定の意味体系又は通貨の意味体系を伝えないが、それは、主に、データソースが作成領域の外側で使用されることを想定せずに作成されるという事実による。これは、この領域の外側からユーザがデータを見るときに、ＹＴＤ Ｓａｌｅｓ又はＤｉｓｔａｎｃｅＴｒａｖｅｌｌｅｄなどの単純なフィールド名では十分な情報を伝えないことを意味する。例えば、売り値はＵＳドル又はＡＵドルを使用して示され、距離はマイル又はキロメートル単位で示される。不十分なスキーマ情報がデータソースに対して提供される一方で、例えば、換算係数を指定することによってマッピングにおいて所要の変換を定義することは、マッピングを作成するユーザにかかっている。
【００９８】
しかし、データソースの定義がＸＭＬスキーマを使用して表現される場合、測定の意味体系を適切に表現することができる。ＸＭＬスキーマの定義されたデータ型は、既に時間（及び日付）の意味体系を規定している。現在、測定に対しては標準化された意味体系はないが、データブラウジングアプリケーション１２０は、各寸法が所定の可能な単位のセットと関連付けられる寸法型のライブラリを使用する。後述のＸＭＬスキーマの例１はｌｅｎｇｔｈ型の定義を表す。この型は、ｆｌｏａｔのＸＭＬスキーマデータ型を拡張し、この型を使用する各要素はｕｎｉｔｓ属性と関連付けられる。
【００９９】
ＸＭＬスキーマ例１：
【０１００】
2004240954.tif 000007
【０１０１】
従って、データソーススキーマの設計者は所定の寸法型を使用する要素を宣言することができる。例えば、要素ＭｙＬｅｎｇｔｈは：
【０１０２】
2004240954.tif 000008
【０１０３】
のように定義し、
【０１０４】
2004240954.tif 000009
【０１０５】
のように文書中で使用しても良い。
単位が全ての例に対して固定である場合、要素宣言を使用してｕｎｉｔｓ属性の値を「ｍｅｔｒｅ」に制限することによって基底型を改良しても良い。
【０１０６】
データソースがこの寸法及び単位を定義する方法を使用する場合、データブラウジングアプリケーション１２０は、マッピングの作成中にソースデータ構成要素の各々が同様の寸法を有することを確認する。マッピングのソースが寸法的に一致していない場合、マッピングは許容されない。ユーザは、同じ寸法を有するが単位が異なるソース間での数学演算をオペランドソース間に所要の演算子（すなわち、＋、−、／、＊）を挿入することにより示すことができる。データブラウジングアプリケーション１２０は、寸法ライブラリを使用して必要な換算を実行する。マッピングの目標は、演算の第１のオペランドと同じ単位を有する。
【０１０７】
例えば、ユーザが最初にソースデータ構成要素ＤｉｓｔａｎｃｅＴｒａｖｅｌｌｅｄ（ｌｅｎｇｔｈ型を拡張したものであり、キロメートル単位を使用）を選択し、続いて、第２のソースデータ構成要素ＤｉｓｔａｎｃｅＦｒｏｍＳｏｕｒｃｅ（ｌｅｎｇｔｈ型を拡張したものであるが、マイル単位を使用）を選択する場合について考察する。ユーザが各値間に＋演算子を挿入することによってデータの一例を編集する場合、結果として生じるデータ値は距離の合計をキロメートル単位で示すであろう。結果の値がマイル単位を使用して表現されることをユーザが希望する場合、ユーザはソースデータ構成要素が選択される順序を変更することができる。また、マイル単位を使用するために、マッピングの目標データ構成要素の型情報を明示的に編集することもできる。
【０１０８】
データブラウジングアプリケーション１２０は、データソースが適切に記述される場合にのみ、この単位換算を実行することができる。通貨を寸法として定義し、単位を個々の通貨として定義することによりほぼ同じ方法を使用して通貨換算を実行できることは明らかであろう。好適な構成では、データブラウジングアプリケーション１２０はオンライン換算プロセスに換算レートを要求する。この換算プロセスがネットワークの問題により利用可能でない状況では、換算は換算レートの表を使用して実行される。
【０１０９】
５．０  データビューの提示
データビューは、セクション２．０で説明されるようなスキーマビューを使用するか、あるいは、本開示のセクション６．０で説明されるような視覚的方法を使用して作成することができる。これらのデータビューはデータブラウジングアプリケーション１２０によりユーザに対して提示される。
【０１１０】
データブラウジングアプリケーション１２０においてデータビューを提示する好適な方法を説明する。この方法では、ユーザは、図１２Ａに示すようなビデオディスプレイ１１１４上にデータブラウジングアプリケーション１２０により表示されるＧＵＩ環境１２００で作業を行なう。ＧＵＩ１２００の左側にあるのはデータマークパネル１２０５である。データマークは、有用な情報へのリンクを表現する点において、ウェブブラウザブックマークの概念に類似している。データマークパネル１２０５は、各々がＵＲＩと関連付けられた末端項目を含むツリーであるのが好ましい。代替の構成では、データマークパネル１２０５は単純なリストとして実現されても良い。ＵＲＩは、データソース又は予め作成されたデータビューに対応しても良い。好適な構成では、データソースはＸＭＬ文書及びデータサーバを具備する。データサーバについてはセクション１．０において更に詳細に説明されている。代替の構成では、他の種別のデータソースが許容されても良い（例えば、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）表計算ソフト）。これらの代替の構成では、データブラウジングアプリケーション１２０は、データソースからＸＭＬを生成する方法を提供する。
【０１１１】
図１２Ａに示すデータマークパネル１２０５において、データソース及びデータビューは、別々のセクション（例えば、ツリーの２つのノード）で維持管理される。これは必須ではなく、好適な構成においてユーザが１次データソースと派生データソースとを区別するのを支援するために行なわれる。また、データマークパネル１２０５の最上部には、パネルにおいてデータマークを追加・編成するための選択可能なパネルオプション１２０４がある。ユーザがデータマークを追加することを選択する場合、現在選択されているデータビューに対して新規のデータマークが作成され、データマークパネル１２０５に追加される。追加されたデータマークの名前はデータビューのタイトルになることが想定され、ＵＲＩはデータソース又はデータビュー定義のＵＲＩになることが想定される。好適な構成では、データマークはデータマークパネル１２０５の適切なセクション（データソースノード又はデータビューノード）に追加される。
【０１１２】
データマークパネル１２０５から項目を選択することによりＸＭＬデータが生成される。データソースの場合、ＵＲＩはデータサーバがＸＭＬデータ結果を生成するのに使用するＸＱｕｅｒｙを含むのが好ましい。ＸＱｕｅｒｙがＵＲＩに対して指定されない場合、デフォルト要求の「／」が想定される。データビューの場合、データブラウジングアプリケーション１２０は、データビュー定義（セクション１１．０で後述するように生成される）を読み込み、適切な問合せ要求を生成し、データビューの定義に従って、問合せ要求からのＸＭＬデータを照合・形式化する。
【０１１３】
いずれの場合でも、ＸＭＬデータがユーザに対して提示される前に、マッピングが受信データに関連するか否かを確認するためにチェックが行なわれる。関連するマッピングが見つかった場合、対応するデータ変換が実行される。この変換は、１つ以上のデータソースから１つ以上のデータ構成要素を結合することを含むことができる。ユーザがデータビューを見ることを選択する場合にマッピングを適用する好適なプロセスについてはセクション１１．０で後述する。
【０１１４】
ＧＵＩ１２００のデータマークパネル１２０５の右側は、ワークスペース１２０２である。ユーザがデータマークを選択すると、結果のデータビューがワークスペース１２０２に表示される。図１２Ａにおいて、データビューは用語「Ｐｒｏｊｅｃｔ」を先頭とする表である。ワークスペース１２０２は、グリッドとして編成され、見るために選択されたデータビューが矩形のグリッド単位として表示されるのが好ましい。表示されるデータビューの好適なサイズ（及びワークスペース中のグリッドの各行に表示されるグリッド単位の数）がユーザプリファレンスとして指定される。ユーザは、ワークスペースにおいてデータビューをサイズ変更・移動することを選択することができる。この操作が発生した場合、グリッドレイアウトはマニュアルレイアウトへと変えられるが、ワークスペースにおいて新規のデータビューを表示する際には好適なデータビューサイズが使用され、新規のデータビューの初期の配置を判定する際にはグリッドレイアウトが使用される。
【０１１５】
また、ＧＵＩ１２００により、ユーザはワークスペース１２０２に表示されるデータビューを修正することができる。例えば、ユーザは提示特性（例えば、フォント、書式、色など）を修正したり、フィルタを適用したり、ソートの順序を変更したり、１つ以上のデータ構成要素に適用される変換を適用したりすることができる。ユーザは、随時、選択されたデータビューを保存することができる。データビューがデータソースに対応するデータマークから開始され、ユーザが修正を行なった場合、新規のデータビュー定義が作成される。ユーザは、作成されたデータビューが格納される場所を指定することができる。データビューが既存のデータビュー定義から開始される場合、ユーザは既存のデータビュー定義を更新するか、あるいは、選択されたデータビューに対して新規のデータビュー定義を作成することができる。
【０１１６】
代替の構成では、ワークシート１２０２を占有するデータビューの集合も保存することができる。この場合、作業を保存するときにユーザは新規のデータビューを含むワークスペース１２０２の全体を保存することを選択することができる。このワークスペース１２０２は他のユーザと交換することができる。更なるバリエーションでは、データビューは常にワークスペース１２０２の一部として保存される。このワークスペース１２０２は、任意の数のデータビュー及び他のワークスペースを含むことができる。先に説明したグリッドレイアウト種別（例えば、列又は行の形式）以外のワークスペース用のレイアウト種別に従って、含まれるワークスペースの構成要素を配置することも可能である。上述のように、ワークスペースは手動で配置することもできる。ワークスペースは、他のユーザと交換可能なパッケージソフトのように動作することができる。例えば、電子メール又はＵＲＩリンクを介してワークスペースを受信すると、受信ユーザは、含まれるワークスペースを図１２Ａに示すようなデータマークパネル１２０５へとドラッグすることによってワークスペースを復元することを選択することができる。
【０１１７】
代替の構成によれば、２つ以上のワークスペースを一度に開くこともできる。図１２Ａのステータスバー１２９０の上方に位置する１セットのタブを介して複数の開いたワークスペース（現在は不図示）にアクセスしても良い。
【０１１８】
ユーザがデータマークパネル１２０５からデータマークを選択すると、そのデータマークと関連付けられたデータビューが、ワークスペースの次の利用可能なグリッド位置に提示される。提示プロセスについては本セクションで更に詳細に説明する。ワークスペースがクリアになると、データビューがワークスペースの左上端に出現する。また、ユーザはデータマークを選択する前に図１２Ａのツールバー１２０７上のワークスペースクリア制御１２３４を選択することができる。既存のデータビューがワークスペース１２０２に表示され、ワークスペースクリア制御１２３４が選択される場合、データビューが元の状態から修正されているときには、ユーザはこのデータビューを保存するように促される。
【０１１９】
また、ユーザは、図１２Ａのツールバー１２０７の下方の位置オープン制御１２０８においてデータソース又はデータビュー定義のＵＲＩを入力するか、アイコン１２０９を押下することで見られる履歴リストから所望の位置を選択するか、あるいは、ファイルメニューから「位置オープン」機能を使用することによってデータビューを提示することができる。いずれの場合にも、結果としてデータマークの選択に関して説明したのと同様の手順になる。
【０１２０】
データマークと関連付けられるデータビューを表示する好適な方法を図３１Ａを参照して説明する。ユーザはデータマークパネル１２０５において適切なデータマークを選択し、データブラウジングアプリケーション１２０のＧＵＩオブジェクト３１１０は、このデータマークと関連付けられたＵＲＩをワークスペースコントローラオブジェクト３１１５へと渡す。このオブジェクトは、受信したＵＲＩがデータソース又はデータビュー定義に対応するか否かを確認する。後者の場合、オブジェクト３１１５は、好適な構成ではＸＭＬ文書として格納されるデータビュー定義の位置を特定し、データビュー定義を具備するツリー構造へと解析する。データビューの定義は、文書オブジェクトモジュール（ＤＯＭ）オブジェクトを使用して表現されるのが好ましい。データビュー定義についてはセクション１１．０において更に詳細に説明される。
【０１２１】
ワークスペースコントローラ３１１５は、データビュープレゼンタオブジェクト３１２０を作成してデータビューを提示する。ワークスペースコントローラ３１１５は、オブジェクト３１２０に対してデータソースのＵＲＩ又はデータビューの定義のノードを渡す。好適な構成では、データビューの定義の根ノードがデータビュープレゼンタオブジェクト３１２０へと渡される。しかし、他の構成では、データビュー定義は、データビュープレゼンタオブジェクト３１２０へは渡されない記述ノード（例えば、データビューがいつ誰により作成されたか）を伴って異なる方法で編成されても良い。ワークスペース１２０２の表示されたデータビューの各々は、独自のデータビュープレゼンタオブジェクト３１２０と関連付けられるのが好ましい。
【０１２２】
データビュープレゼンタオブジェクト３１２０は新規のデータビューマネージャオブジェクト３１２５を作成し、提示すべきデータビューに対するデータを取得する。（データソースの）ＵＲＩ又はデータビュー定義ノードが作成されたデータビューマネージャオブジェクト３１２５へと渡される。データビューマネージャがＵＲＩを伴って初期化される場合、データビューマネージャ３１２５は、ＸＭＬ格納オブジェクト３１４０に対してＵＲＩを取り出し、ＸＭＬ文書に対応する結果のストリームを解析してＤＯＭ状構造（以降ＸＭＬスキーマＤＯＭ又は簡単にＸＳＤＯＭと呼ぶ）へと解析し、作成された構造へのハンドルを戻すように要求する。
【０１２３】
ＸＳＤＯＭ構造は、要素ノード及び属性ノードがＤＯＭレベル２アプリケーションプログラミングインタフェース（ＡＰＩ）から追加の方法を提供する点においてＤＯＭ構造と異なる。追加の方法は、上述のノードに対するＸＭＬスキーマ定義の位置を特定する。これらのＸＭＬスキーマ定義は、データビュープレゼンタオブジェクト３１２０がデータビューと関連付けられたデータを適切に提示するのに使用する。データビューマネージャオブジェクト３１２５は、ＸＭＬ格納オブジェクト３１４０により作成されたＸＳＤＯＭオブジェクトに対する提供されたハンドルを使用して、提示中のデータビューに対するデータとして動作する独自のＸＳＤＯＭ構造を作成する。
【０１２４】
データブラウジングアプリケーション１２０は、単一のＸＭＬ格納オブジェクト３１４０を有するのが好ましい。このオブジェクトは取り出したＸＭＬ文書をオブジェクトキャッシュに取り入れる。このため、ＸＭＬ格納オブジェクト３１４０は、ＸＭＬデータのＨＴＴＰ取出しを開始する前に、文書がキャッシュにあるか否か及び取り出されたコピーが最新のものであるか否かを最初にチェックする。また、ＸＭＬ格納オブジェクト３１４０は、ＸＭＬスキーマ文書に対する要求も受信する。この要求は、要素及び属性の定義に対するＸＳＤＯＭ要求から生じる。ＸＳＤＯＭ要素／属性ノードは、それ自体のＸＭＬネーム空間を識別し、そのネーム空間と、場合によっては特定の要素又は属性とに対する定義を有するＸＭＬスキーマ文書の位置の特定を試みることが可能である。ＸＭＬ格納オブジェクト３１４０は、ＸＭＬ文書に含まれるスキーマ位置ＵＲＩを使用してＸＭＬスキーマ文書の位置を特定する。ＸＭＬ格納オブジェクト３１４０は、これらのスキーマをスキーマオブジェクトへと解析し、今後の使用のためにこのオブジェクトを図１のデータベース１３０に対応するＸＭＬ格納キャッシュ１３０に取り入れておく。ＸＭＬ文書と同様に、スキーマオブジェクトがキャッシュから使用される前に、ＸＭＬ格納オブジェクト３１４０は、スキーマオブジェクトが最新のものであることを確認する。
【０１２５】
データビュー定義を伴って初期化される場合、データビューマネージャオブジェクト３１２５は定義と関連付けられた問合せを抽出し、問合せを処理するためにＸＭＬ格納オブジェクト３１４０に対して必要なデータを取り出すことを要求する。要求ごとにＸＭＬ格納オブジェクト３１４０におけるＸＳＤＯＭオブジェクトに対するハンドルが生成される。データビューマネージャ３１２５は、これらのハンドルを使用して必要なデータを取得し、データビュー３１３０に対するデータに対応する独自のＸＳＤＯＭ構造を作成する。このデータは、１つ以上のデータソースからの、マッピング、フィルタリング、ソート、グループ化を経たデータを表す。２つ以上のデータソースから取得される場合、このデータはこれらのデータソースの結合を表す。結合については本開示のセクション６．０及び  ７．０において更に詳細に説明される。
【０１２６】
データビュープレゼンタオブジェクト３１２０により実行される提示プロセスは、最も適切な提示種別又は表示種別を選択するために、データビューのＸＳＤＯＭデータ３１３０の分析と関連付けられたスキーマ定義とを必要とする。最も適切な表示種別（例えば、表、グラフ、散布図、２Ｄグリッドなど）が一度選択されると、データビュープレゼンタオブジェクト３１２０は選択された表示種別を使用してデータをレンダリングし、ユーザに対して提示するためにこのレンダリングされたデータビューに対するハンドルをワークスペースコントローラ３１１５へと渡す。
【０１２７】
レンダリングされたデータビューはスケーラブルベクタグラフィックス（ＳＶＧ）オブジェクトであるのが好ましい。データブラウジングアプリケーション１２０は、デフォルトの又は好適なＳＶＧテンプレートと関連付けられる表示種別ごとに１セットのＳＶＧテンプレートを有する。好適な表示種別の選択の際に、データビュープレゼンタオブジェクト３１２０はデフォルトのＳＶＧテンプレートを選択し、それにデータビューのＸＳＤＯＭ構造３１３０からのデータを読み込む。この読込みの結果がレンダリング可能なＳＶＧオブジェクトである。このオブジェクトはユーザに対して表示可能であり、このオブジェクトとユーザは対話することができる。
【０１２８】
また、データブラウジングアプリケーション１２０は、特定のネーム空間に所属するＸＭＬデータに対するＳＶＧオブジェクトを生成するビューワプラグインを登録する機能を備える。プラグインは、１次アプリケーションにより実行されない特定のタスクを実行するためにそれ自体を１次アプリケーション（この場合、データブラウジングアプリケーション１２０）と関連付ける。これらのビューワプラグインは、データブラウジングアプリケーション１２０に登録することができ、登録時に特定のネーム空間ＵＲＩと関連付けられる。本セクションで後述する提示分析を開始する前に、データブラウジングアプリケーション１２０は、登録されたビューワプラグインネーム空間のリストを検査する。表示すべきＸＭＬデータのノードがこれらのネーム空間のうちの１つに所属する場合、関連付けられたビューワを使用してＸＭＬに対するデータビューを表現するＳＶＧオブジェクトが生成される。
【０１２９】
検出されたノードが表示すべきＸＭＬの根ノードである場合、後述の提示分析は行なわれないのが好ましい。また、提示分析は後述するように実行されても良く、ビューワプラグインを使用してデータビュー（例えば、表の列に対するセル、グリッド要素メンバ）の各構成要素に対するＳＶＧオブジェクトを生成しても良い。
【０１３０】
ビューワプラグインにより生成されたＳＶＧオブジェクトは、Ｊａｖａ（登録商標）ＳｃｒｉｐｔコードをＳＶＧオブジェクト内に含むことによる特定のイベントに対する処理を含んでも良い。表示すべきＸＭＬデータの根ノードが、ＳＶＧネーム空間（http://www.w3.org/TR/SVG/において記述）に所属する場合、ＸＭＬデータはデータビューに対するＳＶＧオブジェクトとして扱われる。換言すれば、ＳＶＧ ＸＭＬデータは、データブラウジングアプリケーション１２０のワークスペース１２０２においてレンダリングされる。
【０１３１】
データビュープレゼンタオブジェクト３１２０により実行される提示分析は、本セクションの以降の記述において更に詳細に説明される。説明した方法は、一般的に、階層データに適用することができ、データブラウジングアプリケーション１２０における使用に限定されないことは明らかであろう。
【０１３２】
最も適切な提示を選択する方法は、図３１Ｂのフローチャートに示されるように３つのフェーズにおいて機能する。第１の分析フェーズ３１６０は、階層データ自体から、利用可能であればデータのスキーマ定義から、あるいは、その双方から階層データの構造を検査し、定期的に発生するデータ項目の存在を識別し、代表的な実表データ構造及びフラットデータ表を構築することができるか否かを判定する。後者の存在は、データが１次元又は２次元であることを示すので、グラフ又はｘｙプロット提示が適切であるだろう。第２の削除フェーズ３１７０は、データ及び／又はそのスキーマ定義を検査し、どの表示種別が不適切かを判定する役割を持つ。削除フェーズ３１７０は、各々が関連付けられた条件と削除候補のリストとを有する１セットの削除規則を利用する。規則の条件が満たされると、候補のリストが可能な表示種別のリストから削除される。
【０１３３】
全ての削除規則が処理されたときに、２つ以上の表示種別が残る可能性もある。この場合、第３の優先フェーズ３１８０が開始される。優先フェーズ３１８０において、１セットの優先規則が処理されて残る候補を順序付ける。これらの規則は、表の行数又は列数あるいは円グラフのセグメントの数などの属性に対して検査を行なう。例えば、列よりも行の方が多い場合、表の高さが幅よりも小さくなるように行と列とを交換するのがより適切であろう。この規則は、データビュー及び実際に見ることが可能な表の列数を考慮に入れるのが好ましい。
【０１３４】
５．１  表示種別
データブラウジングアプリケーション１２０は、以下の表示種別、すなわち、ツリー、表、棒グラフ、線グラフ、円グラフ、その集合、ｘｙ散布図（又はただのｘｙプロット）、及び２Ｄグリッドをサポートする。より少ない種類の又は追加の表示種別が使用されても良い。上述の表示種別のうちの１つ以上の集合を具備する表示種別が使用されても良い。２Ｄグリッド表示種別及びツリー表示種別を除いて、各種別には下位の種別がある。一部の表の場合、ユーザは表の転置行列（すなわち、行及び列が転置される）を見るオプションを有しても良い。棒グラフ、線グラフ、円グラフ、及びｘｙプロットの場合、行に関する下位種別及び列に関する下位種別がある。ツリー表示種別は、任意の階層構造のデータを表示するのに使用可能な一般的な表示種別である。この表示種別はデータを自然な階層化形式で示す。
【０１３５】
全ての非ツリー表示種別の基礎を成す実表データ構造は、個々のデータ構成要素のインスタンスが列を成して配置される表の表示形式である。一例のＸＭＬデータ及びその実表表現は図３２及び図３３にそれぞれ示される。図３３において、列見出し３３０１から３３０４は、ＸＭＬデータに存在するデータ構成要素を識別するものであり、通常、データ中の要素及び属性の名前である。１次データを保持するものと見なされる属性のみがデータ構成要素として扱われる。従って、ＸＭＬインスタンスネーム空間又はＸＭＬスキーマインスタンスネーム空間（例えば、xml:lang、xsi:schemaLocationなど）に所属する属性はデータ構成要素として扱われないが、これらの属性の役割が情報を処理アプリケーションへと提供することだからである。同様に、データブラウジングアプリケーション１２０のネーム空間に所属する任意の属性もデータ構成要素として扱われない。このような属性は、データ構成要素に対する代替の名前を格納するか、あるいは、データ構成要素を一時的に列挙するために使用されても良い。この属性については、本開示のセクション７．０において説明される。
【０１３６】
各列に示されるのはこれらの要素及び属性と関連付けられる値３３０５から３３１１である。列の内容は、同じＸＭＬ要素の属性及び下位要素の値が表の同じ行に示されるように順序付けられる。「Ｊａｎ」（項目３３０７）及び「１２３０００」（項目３３０８）は、ＸＭＬデータのｍｏｎｔｈ属性及び同じＳａｌｅｓ要素の値に端を発するので同じ行に出現する。両項目は、同じ（第１の）Ｄｅｐｔ ＸＭＬ要素の下位要素及び子孫であるので、Ａｐｐａｒｅｌ（項目３３０６）と関連付けられる。尚、このＤｅｐｔ要素も他の３つのＳａｌｅｓ下位要素を具備するので、ＡｐｐａｒｅｌはＤｅｐｔ列の項目３３０９、３３１０、３３１１において３回繰り返される。しかし、同じ値が連続的に同じ列に出現するときには、通常、明確にするために第１の実例のみが示され、残りは空白のままである。
【０１３７】
実表データ構造は、図３３に示すように完全に展開することができる。図３３では、全ての属性及び下位要素の値が列挙されている。また、実表データ構造は、ある特定のＸＭＬ下位要素の内容が示されない不完全な展開形式で表示されても良い。代わりに、下位要素は表中のハイパーリンクにより表現される。不完全な展開の実表データ構造が図３４に示される。図３４において、３４０１及び３４０２はハイパーリンクである。ハイパーリンクは、通常、ＸＭＬデータの深度又は次元（及び表示された表のサイズ）を管理可能なレベルにまで縮小するのに使用される。
【０１３８】
ハイパーリンクはデータブラウジングアプリケーション１２０におけるデータソースのブラウジングを可能にするために使用することができる。提示されたデータにおいてハイパーリンクを選択することによって、ユーザは提示する更なるコンテキストノードを選択し、データソース中の更なる内容をブラウズすることができる。また、ユーザは、現在の表示種別内のハイパーリンクの内容を見ることを選択できる。例えば、ユーザは、表のセル内でグラフを見ることを選択することができる。既存のデータビュー内のハイパーリンクの内容を選択的に見ることにより、複合の表示種別が得られる。
【０１３９】
このため、表示されたハイパーリンクは、データの一部として存在するような作成されたハイパーリンク又はＸＭＬデータの深度又は次元を低くするために提示分析プロセスにより生成されたハイパーリンクによるものであっても良い。ハイパーリンクは、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（登録商標）（Ｎｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社製造）及びＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）（Ｍｉｃｒｏｓｏｆｔ社製造）などのウェブブラウザで使用されるようなカラーの下線を引いたテキストキャプションを使用して表現されるのが好ましい。テキストキャプションの色は、ユーザがたどったハイパーリンクを示すべく変化をつけることができる。
【０１４０】
これらのキャプションに対するテキストは、好ましくは、後続の拡張子（例えば、「．ｈｔｍ」、「．ｈｔｍｌ」、又は「．ｊｐｇ」）など（存在する場合のみ）を削除した後に、ハイパーリンクのＵＲＩ目標の終端のエンティティを取ることにより生成されるのが好ましい。終端のエンティティは、ＸＭＬノード及び外部のエンティティ（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄ（登録商標）文書、ＪＰＥＧ画像など）のいずれかを表現することができる。このため、例えば、図３４において、表示されたハイパーリンクの目標の外部のエンティティは、それぞれ、ＸＭＬ要素Ａｐｐａｒｅｌ及びＴｏｙｓである。あるいは、ハイパーリンクと関連付けられたＸＭＬテキストノードの内容をハイパーリンクに対するキャプションとして使用しても良い。例えば、ＸＭＬ要素：
【０１４１】
2004240954.tif 000010
【０１４２】
は、要素Ｓａｌｅｓのテキストノードの内容（すなわち、「Ｊａｎｕａｒｙ」）をテキストキャプションとして有するハイパーリンクとして表示することができる。
代替の実現例では、ハイパーリンクの目標が更なるＸＭＬデータ（例えば、図３４に示すような）を表現する場合、このデータは、本セクションで後述する提示分析を使用して再帰的に分析することができる。提示分析により、ハイパーリンクされたデータに対する好適な表示種別が得られる。ハイパーリンクを図３４に示すようなテキストのハイパーリンクとして提示する代わりに、ハイパーリンクされたデータに対する好適な表示種別のグラフ表現を現在のデータビュー内に表示することができる。グラフ表現は、例示の図、ツリー、表などを示す１セットの所定の画像のうちの１枚を組み込むアイコンであっても良い。また、グラフ表現は、実際のハイパーリンクされたデータのアイコンサイズの表現（すなわち、サムネイル）であっても良い。後者の場合、データブラウジングアプリケーション１２０は、ハイパーリンクされたデータビューの画像をサムネイルとして使用するために生成しても良い。
【０１４３】
テキストのハイパーリンクを表示するのではなく、ハイパーリンクが表のセルに存在する場合、データブラウジングアプリケーション１２０は、ハイパーリンクをハイパーリンクされたデータを提示するのに使用される表示種別を示すグラフ表現として表示するであろう。ブラウズ中のユーザはこのグラフィカルハイパーリンクをたどることができる。グラフィカルハイパーリンクの周囲のカラーの境界線は、たどったことのあるハイパーリンクを示すのに使用することができる。テキストのハイパーリンクと同様に、グラフィカルハイパーリンクの内容は、現在のデータビュー内又は新規のデータビューにおいて表示することができる。前者の場合、結果として、親データビューが表示種別内に異なる表示種別の子データビューを含むフレームを含む複合の表示種別が得られる。例えば、ハイパーリンクが表データビューにおいてたどられる場合、表の個々のセルは図表示種別又はツリー表示種別を有する子データビューを含むことができるであろう。
【０１４４】
グラフ表現上でマウス１１０３を使用して右クリックすることによって、グラフィカルハイパーリンクに対してコンテキストメニューを表示することができる。コンテキストメニューは、ハイパーリンクされたデータを表現するのに使用することができる他の可能な表示種別ごとにオプションを含むことができる。これらの代替のオプションのうちの１つを選択することにより、ハイパーリンクのグラフ表現は更新され、新規の表示種別を表現するようになる。また、コンテキストメニューは、ハイパーリンクされたデータが、現在のデータビューの一部として（すなわち、複合の表示種別を使用して）表示されるか、あるいは、新規のデータビューにおいて表示されるかをユーザが選択できるようにするオプションを含んでも良い。
【０１４５】
更なる実現例では、ハイパーリンクのグラフ表現を有益にテキストハイパーリンクに隣接して表示することができる。これにより、ブラウズ中のユーザは、テキストのハイパーリンク上で再度マウス１１０３を使用してクリックし、ハイパーリンクされたデータを見たいことを示しても良い。ここでのハイパーリンクのグラフ表現の役割は、ハイパーリンクされたデータを表示するのに使用される表示種別を示すことである。
【０１４６】
実表データ構造は、表表示種別に対して直接使用することができる。例えば、同じ下位要素（又は属性）の繰返しパターンを有するデータは、各要素又は属性が列を構成する表としてユーザに対して提示されるのが最適である。しかし、図３３の実表データ構造により表されるような一部のデータパターンでは、データの一部を列見出し又は行見出しに推奨することによって階層データをフラットにすることができる。実表データ構造は、ＸＭＬデータの下部構造を伝えるのに有用であり、セクション６．０において説明するようにデータの容易な操作を考慮に入れている。しかし、よりフラットな表構造の方が、通常、より効果的な提示形式である。
【０１４７】
よりフラットな表データ構造は、棒グラフ表示種別、線グラフ表示種別、及び円グラフ表示種別を識別するのにより適している。これらの表示種別が、相互に１対１の対応を有する２つのデータ構成要素間の関係を提示するのに不可欠な方法であるからである。このようなデータ構成要素が存在する場合、１つのデータ構成要素の内容は表の列見出しとして表示され、残るデータ構成要素の内容は対応する列の下に示される。データ構成要素の内容が２つ以上のサブセットにおいて存在する場合、各サブセットは表の１行のデータとして表示される。サブセットの存在は、最初の２つのデータ構成要素と１対多数の対応を有する第３のデータ構成要素により示される。この第３のデータ構成要素の内容を使用して異なるデータサブセットを識別することができる。この内容は、通常、表示された表の１列の行見出しにおいて示される。単一の値を有する別のデータ構成要素も存在する場合、この内容を表に対するキャプションとして使用するのが適切であろう。
【０１４８】
図３２のＸＭＬデータの実表データ構造をフラットにすることにより取得される表表示３５０１の一例が図３５に示される。図３５において、列見出し３５０２は、データ構成要素３３０３Ｍｏｎｔｈの値であり、データセルはデータ構成要素３３０４Ｓａｌｅｓの値である。また、表は、第３のデータ構成要素３３０２Ｄｅｐｔの値である１列の行見出し３５０３を具備する。列見出しＭｏｎｔｈ及び行見出しＤｅｐｔをそれぞれ構成するデータ構成要素３３０３及び３３０２の名前は、表の左上端セル３５０５において示される。最後に、単一のデータ値を具備するデータ構成要素３３０１が表キャプション３５０６として表示される。
【０１４９】
図３５の表表示の転置形式は行と列とを交換した表である。図３２のＸＭＬデータに基づくこのような表の一例が図３６に示される。図３５又は図３６のような表がワークスペース１２０２においてユーザに対して提示される場合、ユーザはデータに対して実表形式を見ることを選択することもできる（すなわち、図３３）。好適な構成では、ユーザは項目３３０１のような単一の値を有するデータ構成要素が実表データ構造に含まれるか否かを指定することができる。ユーザがこれらのデータ構成要素を含まないことを選択する場合、そのうちの１つ（通常、第１のデータ構成要素）を使用して表示されたデータに対するキャプションが構成される。
【０１５０】
フラットになった表表示種別において表示される第２のデータ構成要素の値が数値である場合、ＸＭＬデータを棒グラフ、線グラフ、又は円グラフとして提示することが可能になるであろう。この場合、表表示の内容とグラフ表示の内容との間にマッピングが直接存在する。行に関する棒表示種別及び線表示種別に関して、後者の一例が図３７に示される。表の各行はグラフにおいてデータシリーズ３７０１として示される。各行と関連付けられる行見出しは、データシリーズ３７０２の名前を構成し、列見出しはｘ軸３７０３に沿ったラベルとなる。列に関する棒グラフ及び線グラフに関して、前者の一例が図３８に示される。データ表３５０１の各列はデータシリーズ３８０１へとマップされ、列見出しはデータシリーズの名前３８０２へとマップされ、行見出しはｘ軸ラベル３８０３へとマップされる。図３７及び図３８に示す両例は図３５により使用されるフラットデータ表に基づいている。
【０１５１】
棒グラフ及び線グラフは、グラフ領域の左端に位置するｙ軸と、右に位置するｙ軸との最大２つの異なるｙ軸（図３７及び図３８には不図示）を有することができるのが好ましい。異なるｙ軸は、通常、異なるデータのセットをプロットするために使用される。異なるデータセットとは、例えば、温度の変化及び降雨量の変化であり、各セットは別個のデータ構成要素により表現される。一方のデータ構成要素の値が左のｙ軸に対してプロットされ、第２のデータ構成要素の値が右のｙ軸に対してプロットされる。好適な構成では、フラットデータ表においてデータシリーズごとに軸索引を維持管理する。
【０１５２】
好適な構成では、単一のｘ軸を有するグラフのみが許容されるが、実表データ構造を使用してネスト状の階層に位置するグラフグループを見つける代替の構成では、複数のｘ軸が許容される可能性がある。また、複数のｘ軸構成はｘ軸ごとに１つのフラットデータ表を使用することができるであろう。
【０１５３】
棒グラフ及び線グラフに使用される同様のマッピングは、行に関する円グラフ表示種別及び列に関する円グラフ表示種別にも使用される。図３９にその一例が示される前者では、表の行は円グラフ３９０１として示される。２行以上存在する場合、複数の円グラフが表示される。表の列見出しは各図の扇形部分と関連付けられたラベル３９０２へとマップされる。行見出しは円グラフのタイトル３９０３へとマップする。後者の列に関する表示種別では、各行ではなく各列が別々の円グラフとして示される。２列以上存在する場合、複数の円グラフが表示される。各図の扇形部分に対するラベルが表の行見出しから取得され、図のタイトルが列見出しから取得される。図３９に示す例は図３５に対して使用されるフラットデータ表に基づいている。
【０１５４】
ｘｙプロット表示種別は、数値データを提示するのに使用される別の表示形式である。棒グラフ、線グラフ、及び円グラフの場合と同様に、ｘｙプロットの使用には、相互に１対１の対応を有する２つのデータ構成要素の存在が必要である。ｘ構成要素と呼ばれる一方のデータ構成要素はｘ軸に対する座標値として機能する。もう一方はｙ軸に対する座標値として機能し、ｙ構成要素と呼ばれる。表表示種別、棒グラフ表示種別、線グラフ表示種別、及び円グラフ表示種別の場合と同様に、シリーズラベル構成要素と呼ばれ、ｘ構成要素及びｙ構成要素に対して１対多数の対応を有する第３のデータ構成要素が存在する場合、ｘ構成要素及びｙ構成要素は複数のサブセットへと分割することができる。この場合、各サブセットはプロットにおいて別々のデータシリーズとして表示される。前述の表示種別とは異なり、ｘｙプロット表示は、ｘ構成要素及びｙ構成要素に対して１対１又は１対多数の対応を有する場合、追加のデータ構成要素を組み込んでも良い。この追加のデータ構成要素が存在する場合には、プロットの各データポイントに対するラベルとして機能し、ポイントラベル構成要素と呼ばれる。
【０１５５】
ｘ構成要素及びｙ構成要素に対して１対多数の対応を有する場合、ポイントラベル構成要素の存在により列に関するｘｙプロット表示種別の作成が可能になる。これは、行に関するｘｙプロットと呼ばれる上述の場合とは対照的である。列に関するｘｙプロットは、シリーズラベル構成要素の役割とポイントラベル構成要素の役割とが交換される点を除いて行に関するｘｙプロットと同様に生成される。
【０１５６】
行に関するｘｙプロットの一例及び対応する実表データ構造が図４０及び図４１にそれぞれ示される。これらの図面では、データ構成要素４００１から４００４が、それぞれ、シリーズラベル構成要素、ポイントラベル構成要素、ｘ構成要素、及びｙ構成要素として機能する。
【０１５７】
２Ｄグリッド表示種別は、主に画像内容を有するデータに対して使用される表示形式であるが、テキストのみのデータを表示するのに使用されても良い。２Ｄグリッド表示種別は、通常、実表データ構造から生成される。実表データ構造では、表の各行全体の内容が単一のデータ項目として提示される。項目の集合は、行数及び列数がユーザ又はワークスペースの寸法により指図される正規の２Ｄグリッドパターンを成すように配置される。グリッドの各項目は、プロパティと値との対のリストを具備する。プロパティは実表表示の列見出しであり、値は対応する列の下のデータ内容である。
【０１５８】
２Ｄグリッド表示種別の一例及び対応する実表データ構造が図４２及び図４３にそれぞれ示される。グリッドの各セルは、従業員の写真の格納位置を指し示すＰｈｏｔｏという名前のプロパティ４２０１を含む。これらの写真４２０１は、残るデータ構成要素Ｎａｍｅ４２０３及びＥｘｔ４２０４のそばに、２Ｄグリッド表示において示される。
【０１５９】
２Ｄグリッド表示種別は、好適な構成において、データ項目のリストを表示するのにも使用される。各データ項目は更なる情報へのリンクを表現する。前述のように、ユーザはこれらのインラインのリンクの内容を見ることを選択することができるのが好ましい。このリンクにより、複合の２Ｄグリッド表示種別が得られる。
【０１６０】
好適な構成では、ユーザはデータ構成要素を操作（例えば、別のデータビューへのコピー、フィルタの適用、ソート、変換、又は結合）することができる。これらのデータ構成要素は、データノードであっても、データセットであっても、あるいは、データシリーズであっても良い。ツリーのノードなどのデータノードは、文書内のノードの位置に対応するＸＰａｔｈ表現により一意的に識別することができる。一方、表の列又はグラフのデータシリーズなどのデータセットは、反復子及び反復子に関連する任意のパスに対応するＸＰａｔｈ表現により識別することができる。このため、例えば、図３６において、Ａｐｐａｒｅｌ列に対応するデータセットに対する反復子は以下の通りである：
Company/Dept[name="Apparel"]/Sales
このデータセットは、反復子に加えて指定すべき更なるパスを必要としない。任意のパスは、全列が同じ反復子を有する（すなわち、行に対する全要素が同じ親要素を有する）表に対して使用されるのが好ましい。
【０１６１】
好適な構成により生成される表示種別の順序付けられたリストに加えて、反復子（及び任意の関連パス）が全てのデータセットに対して提供される。これにより、データ要素は、特定の問合せに対して図３１Ａのデータビューマネージャ３１２５により作成されるＸＳＤＯＭ文書３１３０から直ちに且つ特定的に取得されることが可能になる。また、データビューマネージャオブジェクト３１２５は、この情報を使用して既存のデータビューの問合せを修正し、新規の問合せを構築する。このプロセスについてはセクション６．０において更に詳細に説明される。
【０１６２】
ツリー表示種別はデータセットの特定を必要としない。ツリー表示種別のデータノードに対するパスは、データから直接取ることができる（すなわち、ＸＳＤＯＭ ＡＰＩにより既に提供されている）。
【０１６３】
５．２  分析フェーズ
表示種別を選択・ランク付けするプロセスは、図３１Ｂの分析フェーズ３１６０により開始される。好適な構成では、データは標準ＸＭＬ形式で表現される。他のデータ形式も可能である。
【０１６４】
好適な構成の分析フェーズ３１６０は、ＸＭＬツリーの内容を分析し、ツリーから関連する項目を識別・抽出し、これらの項目から実表データ構造を適切に構築する役割がある。実表データ構造は、ＸＭＬツリーにおいて定期的に発生するデータ項目を検出し、データ項目間の関係を識別する手段を提供する。実表データ構造の各列は、ＸＭＬツリーにおける別個の属性又は要素を表す。各列の下に列挙される値は、ＸＭＬツリーに存在するこれらの属性及び要素のインスタンスである。換言すれば、各列はデータ構成要素である。更に、列ごとのデータは単一のエンティティに属する。
【０１６５】
実表データ構造におけるデータの配置は、ＸＭＬツリー中のデータ要素間の構造上の関係を獲得するのに同じ行にある項目間の暗示の対応を利用する。ＸＭＬツリーは縦に横断し、その間実表構造が左から右へと埋められるのが好ましい。すなわち、下位要素が出現すると、その属性及び内容が直属の親の属性及び内容の右に配置される。親要素が同じ子要素の複数のインスタンスを含む場合、これらのインスタンスは同じ列の相互の下方に配置され、親要素と子要素との間に１対多数の関係があることが示される。同じ親要素を共有する異なる種別の子要素が表の隣接する列を占有する。
【０１６６】
実表データ構造は、一般的に、任意の深度又は次元のＸＭＬツリーから構築することができる。しかし、管理可能なサイズを保証するために、構造は、通常、２次元又は３次元、あるいは、それ以下の次元に制限される。実表データ構造の次元は、データ構成要素間の１対多数の関係をカスケードする数により判定される。例えば、データ構成要素３３０１（Ｃｏｍｐａｎｙ）とデータ構成要素３３０２（Ｄｅｐｔ）との間に１対多数の関係があり、データ構成要素３３０２は、更に、データ構成要素３３０３（Ｍｏｎｔｈ）に対して１対多数の関係を有するので、図３３の表は２次元である。より高次元のＸＭＬツリーが出現する場合、通常、２又は３より高い深度レベルにある下位要素はツリー横断中に展開されず、代わりに、実表データ構造におけるハイパーリンクにより表現される。前述のように、ユーザは複合のデータビューにおいてハイパーリンクされたデータを見ることを選択することができるのが好ましい。
【０１６７】
ハイパーリンクは、親要素が異なる種別の下位要素を具備し、その下位要素のうちの２つ以上がデータの複数のインスタンスを含む場合に使用しても良い。この場合、下位要素は、異なる下位要素の複数のインスタンスにまたがる対応関係が誤解されるのを防止するためにハイパーリンクにより表現されるのが好ましい。図４４のＸＭＬツリー及び図４５の完全に展開された実表表現について考察する。これらの図面において、データ構成要素４４０１Ｄｅｐｔは、各々が２度以上出現する２つの異なる種別の下位要素４４０２Ｓａｌｅｓ及び４４０３Ｓｔａｆｆから構成される。表の同じ行にあるデータ間の暗示の対応のために、図４５の完全に展開された表は、Ｇｅｎｄｅｒの値４５０１及びＳｔａｆｆの値４５０２がＳａｌｅｓの値４５０３及びＭｏｎｔｈの値４５０４と何らかの形で関連することを暗示することになる。この暗示を避けるために、下位要素４４０２Ｓａｌｅｓ及び４４０３Ｓｔａｆｆはハイパーリンクにより表現されるのが好ましい。この結果、各行が単一のエンティティに属する図４６の実表データ構造が得られる。
【０１６８】
一度構築されると、実表データ構造は分析されて他の表示種別が可能であるか否かが判定される。残る表示種別の全てが１次元データ又は２次元データを表示するための本質的に異なる方法であるので、実表データ構造に含まれるデータは同じ次元数でなければならない。同じ次元数でない場合、残る表示種別は不可能である。これらの表示種別の生成を支援するためには、実表データ構造中のデータはフラットデータ表と呼ばれるより適切な形式へと再編成される必要がある。フラットデータ表とは、実表データ構造の階層が崩壊し、１対１の関係で表現されているデータ構造である。これは、実表データ構造が主に相互に１対１の関係を有するｎ個のデータ構成要素を具備するデータ構成要素をほとんど持たず、これらのデータ構成要素のうちの１つを列見出しに推奨し、表のセルに残るデータ構成要素の値を格納することによって達成される場合に可能である。フラットデータ表は、グラフィカルデータにとって必要なデータ構造である。通常、ｎ＝２であり、結果として生じる表の各セルは単一の値を含む。ｎ＝３以上の場合、各セルは複数の値を含み、表は展開されたフラットデータ表と呼ばれる。ｎ＝３の展開されたフラットデータ表は、通常、ｘｙプロット表示種別及び２つの別個のｙ軸を有する棒グラフ及び線グラフに対して使用される。
【０１６９】
フラットデータ表を構築するプロセスは、相互に１対１の対応を有する実表データ構造においてｎ個（ｎ＝２又は３）の複数回発生するデータ構成要素を識別することによって開始される。ラベル構成要素と呼ばれる構成要素がデータ表の列見出しとして機能する一方で、値構成要素と呼ばれる他の構成要素は表のデータセルの内容として機能する。値構成要素には制限はないが、ラベル構成要素は、好ましくは重複したデータを含むべきではない。これは、例えば、重複したラベルが一般的に許容されない棒グラフ又は線グラフにおいて、ｘ軸をラベル付けするのにラベル構成要素が使用されるからである。ラベル構成要素における第２の条件は、好ましくはテキストデータを含むことである。ｎ個のデータ構成要素の全てが数値データを含むとは限らない場合、テキスト構成要素をラベルとして使用することにより、データ表の内容に対する他の数値の可能性のあるデータ構成要素が除かれるからである。これにより、グラフィカル表示種別を生成することができる。
【０１７０】
最初のｎ個のデータ構成要素に対して１対多数の対応を有する別の複数回発生するデータ構成要素が存在する場合、異なる１セットの条件が適用される。シリーズラベル構成要素と呼ばれるこの追加のデータ構成要素の存在は、最初のｎ個のデータ構成要素が別個のサブセットを具備することを示す。ラベル構成要素は、好ましくは、各サブセット内に別個のデータ値を具備するべきであり、個々のサブセットにまたがるデータのセットは、好ましくは、同一であるか、あるいは、ほぼ同一でなければならない。上述の条件が満たされる場合、値構成要素の各サブセットはフラットデータ表の１行のセルを構成し、シリーズラベル構成要素はフラットデータ表の１列の行見出しを構成する。
【０１７１】
実表データ構造に別の１回発生するデータ構成要素が存在する場合、このデータ構成要素はフラットデータ表に対するキャプションとして動作しても良い。これに対して、別の複数回発生するデータ構成要素が存在する場合、一般的に、フラットデータ表に収容することはできない。これは、フラットデータ表には関連付けられた表示種別を生成するために必要な全てのデータが既に格納されており、それ以上の枠は残っていないからである。提示プロセスの目的は、存在するデータの全て又はほぼ全てを示すのに最も適した表示を選択することであるので、好適なオプションは、データの一部のみを見せるのではなく、表表示種別（実表データ構造を使用）又はツリー表示種別へと戻ることである。
【０１７２】
フラットデータ表を構築する手順のフローチャートが図４７Ａに示される。図４７Ａの項目４７１５は図４７Ｂに詳細に示される。図４７Ａは、データブラウジングアプリケーション１２０の一部として実行されるのが好ましい方法４７００を示す。方法４７００において、最初のステップ４７０５は、各々が相互に１対１の対応を有するｎ個の複数回発生するデータ構成要素ｄiを識別するように動作する。ステップ４７１０は、このようなデータ構成要素が何個存在するかをチェックする。０個、１個、又は４個以上の場合、ステップ４７３５が後続し、フラットデータ表の構築は不可能である。データ構成要素の数が２又は３の場合、ステップ４７１５が後続する。ステップ４７１５において、データ構成要素ｄiのうちの１つがラベル構成要素として選択される。また、シリーズラベル構成要素ｓが存在する場合、その識別が行なわれる。後続のステップ４７２０において、残るデータ構成要素ｄiが値構成要素として割り当てられる。ステップ４７２５は、ｄi又はｓ以外の複数回発生するデータ構成要素が存在するか否かを検査する。このようなデータ構成要素はデータ構成要素ｄiに対して１対１の対応を有してはならない。１対１の対応を有する場合、ステップ４７１０においてｄi間で識別されているはずである。ｄi又はｓ以外の複数回発生するデータ構成要素が存在する場合、ステップ４７３５がフラットデータ表の構築を停止するように動作する。存在しない場合、ステップ４７３０が後続し、データ構成要素の数が２であるか否かを検査する。データ構成要素の数が２の場合、ステップ４７４０が後続し、展開なしのフラットデータ表が構築される。２でない場合、ステップ４７３０はステップ４７４５へと制御を渡す。ステップ４７４５において、展開されたフラットデータ表が構築される。
【０１７３】
図４７Ｂはステップ４７１５の詳細を示し、エントリポイント４７５０を有する。ステップ４７５２は、ｄiに対して１対多数の対応を有する複数回発生するデータ構成要素ｓがあるか否かのチェックを実行する。手順は、ステップ４７５４から４７６８を含む分岐とステップ４７７２から４７７８を含む分岐との２つの分岐へと実質的に分かれる。
【０１７４】
ステップ４７５４は、各ｄiを各々がｓの単一の値に対応するサブセットへと分割し、ｓをシリーズラベル構成要素とする。この分岐の残るステップはそれぞれ検査を実行する。肯定応答（すなわち、ｙｅｓ）の場合には制御をステップ４７７０へと移し、否定応答（すなわち、ｎｏ）の場合には制御を分岐の次の検査へと移し、最終的にステップ４７８０へと到達する。ステップ４７５６は、各サブセット内では一意的であるが全てのサブセットにまたがってほぼ同一であるテキスト値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７５８は、各サブセット内では一意的であるが全てのサブセットにまたがってほぼ同一である値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７６０は、各サブセット内で一意的である値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７５６は、同じデータ構成要素ｄi内で同時に真でなければならない３つの条件に関して検査するが、ステップ４７５８ではこれらの条件のうち２つのみが真であれば良く、ステップ４７６０ではこれらの条件のうちの１つのみが真であれば良いので、ステップ４７５６は重複していない。実際、このアプローチでは、最初に、３つ全ての条件を満たすデータ構成要素ｄiを探す。これが存在しない場合、同様の試みが繰り返されるが、今度は３つの条件のうちの２つだけを検査する。以下、同様に続ける。ステップ４７６２は、複数のサブセットにまたがってほぼ同一の値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７６４は、テキストを有するデータ構成要素ｄiがあるか否かを検査する。最後に、ステップ４７６８は、各サブセット内で単調増加又は単調減少する数値を有するデータ構成要素ｄiがあるか否かを検査する。
【０１７５】
ステップ４７７２から４７７８を含む図４７Ｂの分岐では、更なる一連の検査が実行される。肯定（すなわち、ｙｅｓ）応答の場合には、制御をステップ４７７０へと移し、否定（すなわち、ｎｏ）応答の場合には、制御をステップ４７８０へと移す。ステップ４７７２は、一意的な値及びテキスト値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７７４は、一意的な値を有するデータ構成要素ｄiがあるか否かを検査する。ステップ４７７６は、テキスト値を有するデータ構成要素ｄiがあるか否かを検査する。最後に、ステップ４７７８は、単調増加又は単調減少する数値を有するデータ構成要素ｄiがあるか否かを検査する。
【０１７６】
上述の検査のうちの１つに肯定的に応答する場合、ステップ４７７０が後続し、検査をラベル構成要素として満たす左端のデータ構成要素ｄiが選択される。これに対して、全ての検査が否定の場合に発生するステップ４７８０は、ラベル構成要素が存在しないことを記録する。ステップ４７８２は、ステップ４７８０及び４７７０に後続し、プログラム制御をソースへと戻す。
【０１７７】
図４７Ａ及び図４７Ｂからのフラットデータ表の作成が失敗の場合、全てのグラフ表示種別及びｘｙプロット表示種別が、削除フェーズ３１７０に対する可能な表示候補のリストから削除される。ツリー表示種別及び表表示種別のみがリストには含まれており、後者は実表データ構造に基づいている。図４７Ａの手順の結果、展開されたフラットデータ表が得られる場合、棒グラフ表示種別、線グラフ表示種別、及びｘｙプロット表示種別が、表表示種別及びツリー表示種別と共に可能な表示候補のリストに含まれる。好適な表表示は実表データ構造を使用し、棒グラフ表示種別及び線グラフ表示種別は２つの別個のｙ軸を有することになる。ｘｙプロット表示種別の場合、２つの値構成要素がｘ構成要素及びｙ構成要素の役割を果たし、ラベル構成要素がポイントラベル構成要素の役割を引き受けるであろう。一方、図４７Ａの手順の結果、展開なしのフラットデータ表が得られる場合、円グラフ表示種別もリストに含まれ、列に関するｘｙプロット表示種別が削除される。好適な表表示はフラットデータ表構造を使用し、棒グラフ表示種別及び線グラフ表示種別は１つだけｙ軸を有することになる。ｘｙプロット表示種別はポイントラベル構成要素を持たず、ラベル構成要素及び唯一の値構成要素は、それぞれ、散布図におけるｘ構成要素及びｙ構成要素の役割を果たすであろう。
【０１７８】
２Ｄグリッド表示種別は実表データ構造の形式に異なる必要条件を課す。存在するデータ構成要素の数には制限がないが、全ての複数回発生するデータ構成要素は１対１の対応関係を相互に持たなければならない。条件が満たされる場合、２Ｄグリッド表示種別は削除フェーズ３１７０に対する可能な表示候補のリストに含まれる。満たされない場合は削除される。明らかに、このデータパターンは実表データ構造に基づく表表示種別にも適している。優先規則（セクション５．４参照）はこれらの表示種別を適切に順序付けるように動作する。
【０１７９】
表示中のデータが小規模及び／又は迅速にアクセス可能な場合、全てのデータは分析フェーズ３１６０で検査されるのが好ましい。しかし、データが複数の異なるデータソースから取得され、低速のネットワーク接続を介してアクセス可能な典型的なアプリケーション環境では、表示種別の順序付けは全てのデータ要素が利用可能になるのを待つことなく進められるのが好ましい。その結果、顕著な遅延なしに表示を生成し、ユーザに対して提示することができる。従って、短い間に全てのデータを検査することが不可能な場合、分析フェーズ３１６０が終了するまでに限られたサブセットのみが分析される。好適な構成では、データの所定の割合のサブセットが所定の時間内に検査を終了する場合、部分的に構築された実表データ構造における列により識別され示されるデータ構成要素は、ＸＭＬツリーに存在する全てのデータ構成要素を表現するものと想定される。１対１、１対多数、又は多数対１に関わらず、この時点で部分的な実表データ構造において検出されるデータ構成要素間の関係も、見えないデータにおいても当てはまるものと想定される。
【０１８０】
この想定があるため、実表データ構造の分析及び続くフラットデータ表の構築が前述のように実行される。より多くのデータが利用可能になると、想定に反するか否かを判定するために検査が実行される。想定に反する場合、単一のツリー表示種別から構成される表示リストを伴って表示選択プロセスは終了する。例えば、新規に見られるデータにおいて新規の重要なデータ構成要素が検出される場合、あるいは、２つのデータ構成要素間に１対１の対応が存在すると想定されていた場合で、１つのデータ構成要素を表現する下位要素の複数のインスタンスが第２のデータ構成要素を表現する親要素内で検出される場合、想定に反することになる。データ構成要素が複数回発生するデータであるか、あるいは、１回発生するデータが相当の回数存在する場合、データ構成要素は、通常、重要であると見なされる。これに対して、所定の時間内に所定のサブセットの検査が終了しない場合、残るデータは同様のパターンに従わないものと想定され、プロセスは単一のツリー表示種別から構成される表示リストを伴って直ちに終了する。代替の構成では、最後の条件が省略され、検査が済んでいないデータの相対量に関わらず、残るデータは既に検査されたデータと同様のパターンに従うものと想定される。
【０１８１】
実際のデータに加えて、データ内容の構造及び性質を記述するスキーマ情報も利用可能であることが多い。好適な構成で説明したようなＸＭＬデータを操作する場合、スキーマ情報は、ＸＭＬスキーマの形式で表現されるのが好ましい。ＸＭＬスキーマ文書は、要素の集合の各々に対する定義を含む。各定義は、許容可能な属性、下位要素、及び下位要素の基数及び順序を指定する。
【０１８２】
スキーマは実表データ構造及びフラットデータ表の構築における有用な情報源である。スキーマにより、実際のデータを検査せずにデータ構成要素の存在及びその相互関係を推論することができるからである。スキーマは、分析するデータが大規模であり、多くの繰返し要素を含む場合に特に有用である。これは、これらの繰返し要素が単一のスキーマ要素により記述され、後者の迅速な検査が、通常、その内容を推論するのに十分であるためである。
【０１８３】
場合によっては、スキーマは十分な情報を含まないこともあり、実際のデータの検査が必要である。例えば、スキーマがある特定のデータ要素又は属性が任意のものであることを示す場合、実際のデータを検査してその要素又は属性が存在するか否かを判定する必要がある。また、スキーマ定義により、要素は内容の一部として任意の要素を有することが可能であっても良い。この場合、検査の必要があるデータの部分の位置を正確に示すのに役立つため、スキーマは有用である。
【０１８４】
構造上の情報とは別に、スキーマは各データ要素に格納されるデータの型についての情報を含んでも良い。スキーマは、例えば、各データ要素が数値であるか否かを判定し、数値の場合、関連付けられた単位が存在すればそれを取得するのに使用することができる。ＸＭＬデータに関して、各属性又は要素のテキスト値と関連付けられたデータ型がその要素のスキーマ定義において指定される。
【０１８５】
削除フェーズ３１７０における使用を促進するために、実際のデータに加えて、分析フェーズ３１６０において構築されたフラットデータ表は、実際のデータがまだ利用可能でない項目に対するデータ型についてのスキーマ情報を格納する。データ構成要素に対するスキーマ定義が利用可能でない、あるいは、そのデータ型が判定できない場合、一般的なテキスト文字列データ型が想定され、表に格納される。これは、その項目に関して何も分かっておらず、データ型を判定するのに実際のデータの検査が必要であることを示す。
【０１８６】
スキーマ及びデータ分析の双方を組み込む分析フェーズ３１６０のフローチャートが図４８に示される。図４８の方法はプログラムエントリポイント４８０２で開始される。ステップ４８０４が後続し、スキーマが利用可能であるか否かが判定される。利用可能な場合、ステップ４８０６はスキーマを検査し、ＸＭＬデータに存在する全てのデータ構成要素を識別するのに十分な情報を含むか否かを判定する。十分な情報を含まない場合、ステップ４８０８が後続し、必要に応じてデータを検査する。前述のように、例えば、要素又は属性がスキーマにおいて任意のものであると宣言される場合、その要素又は属性が実際にデータに存在するか否かを判定するのに情報が不十分であり、データにおける予想位置の検査が必要である。ステップ４８０４において利用可能なスキーマが見つからない場合、ステップ４８１０が後続し、データのサブセットを検査する。検査のために選択されるデータのサブセットは、通常、無作為に判定されるか、あるいは、先着順に判定される。そのサイズは、所定の継続時間内に処理可能なデータ量により決定される。
【０１８７】
ステップ４８１０、４８０６、及び４８０８の各ステップは、制御をステップ４８１２へと戻す。ステップ４８１２において、実表データ構造が構築される。ステップ４８１４が後続し、フラットデータ表を実表から構築可能であるか否かが判断される。構築可能な場合、ステップ４８１６が後続し、表示候補のリストにおいて棒グラフ、線グラフ、円グラフ、及びｘｙプロットを含むフラットデータ表が構築される。構築可能でない場合、ステップ４８１８が後続し、候補リストから棒グラフ、線グラフ、円グラフ、及びｘｙプロットを削除する。ステップ４８２０がステップ４８１６及び４８１８の各ステップに後続する。ステップ４８２０は、全ての複数回発生するデータ構成要素が相互に１対１の対応を有するか否かを検査する。有する場合、ステップ４８２２が後続し、２次元グリッドが候補リストに含まれる。有しない場合、ステップ４８２４が実行され、２次元グリッドが候補リストから削除される。方法３１６０はステップ４８２６で終了する。
【０１８８】
５．３  削除フェーズ
グラフ又はｘｙプロットなどのグラフ表現が可能であるか否かを判定する際の重要な要因は、表示中のデータ型であり、特に、数値を含むか否かであり、数値を含む場合、長さ、温度、又は通貨などの関連付けられた測定単位である。互換性のある単位を有する数値データのみがグラフ又はプロットとして示すことができる。他の数値データは表又はツリーとしてのみ示すことができる。本文書の以下の記述では、用語「数値データ」は数値又は関連付けられた単位を有する数値から構成されるデータ項目を指し示すのに使用される。
【０１８９】
削除フェーズ３１７０は、不適切な表示種別を削除するためにこのような基準を適用する。モジュラー設計を達成するために、基準は本構成では削除規則の形式で表現されるのが好ましい。各削除規則は相互に独立しており、他の規則に影響を及ぼすことなく修正、追加、又は削除が可能である。削除フェーズ３１７０は種々のグラフィカル表示種別の削除に関係しているので、処理はフラットデータ表に基づいている。この表は実表データ構造を指し示す１セットのポインタを使用して取得される（すなわち、データは重複しない）。
【０１９０】
各削除規則は、ある特定の条件又は検査が一度満たされると、それ自体を全ての可能な候補のリストから削除される１セットの表示種別と関連付ける。各規則の評価は３つの可能な値のうちの１つを戻すことができる：
（ｉ）検査が成功し、表示種別を削除することができる
（ｉｉ）検査が失敗し、表示種別は削除されない（他の削除規則により削除される可能性はある）
（ｉｉｉ）検査の結果を判定するには情報が不十分であり、新規のデータが利用可能になったときに規則を再度実行する必要がある
最初の２つのケースでは、規則の処理が正常に終了したことになり、再度処理する必要はない。規則の処理に先立って追加の検査が実行される。規則と関連付けられる１セットの表示種別のうちの少なくとも１つが残る候補の中にあるか否かを判定するためにチェックが行なわれる。ある場合は規則が処理され、ない場合、規則は無関係であるので削除される。
【０１９１】
各削除規則からの３つの可能な戻り値の使用により、データブラウジングアプリケーション１２０は、全てのデータが存在しなくても動作することができる。新規のデータ項目が利用可能になるたびに、１セットの削除規則が処理される。場合によっては、その結果、ある特定の表示種別が考慮の対象から削除される。ツリー表示種別以外の全ての表示種別が削除される場合（ツリー表示種別は常に可能）、あるいは、全ての規則の処理又は削除が正常に終了した場合、更なるデータを検査する必要はない。
【０１９２】
規則の評価を促進するために、利用可能なデータの増加と共に実表データ構造（及び派生フラットデータ表）が更新される。処理の際、削除規則は、発火発生時には部分的なフラットデータ表の内容に対して作用する。削除規則の好適なリストが表３に示される。より少ない数の又は追加の規則が使用されても良い。表３の列「削除の候補」は、対応する「条件」列の下の条件が真の場合に削除される表示種別を識別する。ここで、「グラフ」という用語は棒グラフ、線グラフ、及び円グラフを総称するものである。
【０１９３】
【表３】
2004240954.tif 000011
【０１９４】
分析フェーズ３１６０のように、スキーマ情報が利用可能な場合、検査の必要のある実際のデータの量を削減するのにそれを使用することができる。分析フェーズ３１６０で構築されたフラットデータ表は、見えないデータ項目のデータ型についての情報も含むことを想起すべきである。この情報は、データ表に既に存在する実際のデータに加えて、各削除規則の実行においても使用される。例えば、数値以外のデータ項目の存在を検査する表３の規則１を実行する際に、見えない項目と関連付けられたスキーマ情報が数値以外のデータ型を有することを示す場合、項目が利用可能になるのを待たずに直ちに検査は正常に終了する。また、全ての見えないデータ項目と関連付けられたスキーマが全て数値データ型であることを示す場合、これらの項目のうちのいずれかが利用可能になるのを待たずに検査は異常終了する。
既に述べたように、データが低速のネットワーク接続を介してアクセス可能な場合、表示種別の順序付けは全てのデータが利用可能になるのを待つことなく進められるのが好ましい。スキーマ情報の使用は全てのデータを検査する必要性を軽減するのに役立つが、常に利用可能又は十分に効果的な訳ではないかもしれない。このため、削除フェーズ３１７０に割り当てられる時間は、通常、短時間に制限される。この時間が経過しても削除フェーズ３１７０が終了しない場合、途中で終了することになり、その時点で残っている候補のリストは、次の優先フェーズにおいて使用される可能な表示候補のリストであると見なされる。
【０１９５】
削除フェーズ３１７０のフローチャートが図４９に示される。最初のエントリポイント４９０２の後、ステップ４９０５が削除フェーズ用のタイマを作動する。割り当てられた時間が経過すると、制御はステップ４９３０へと進む。ステップ４９３０において、削除フェーズ３１７０が終了する。経過していない場合、ステップ４９１０は１つ以上のデータ項目が利用可能になったか否かを検出する。利用可能になっていない場合、制御は戻ってステップ４９０５においてタイマをチェックする。利用可能になった場合、ステップ４９１５が後続し、削除規則を選択する。規則が選択されると、ステップ４９２０が後続し、選択された規則を実行する。これは図５０に詳細に示される。ステップ４９２５が後続し、全ての削除規則の処理が終了したか否かを検査する。終了した場合、削除フェーズはステップ４９３０で終了する。終了していない場合、制御はステップ４９１５へと戻り、未処理の規則を選択する。
【０１９６】
ステップ４９２０により示されるプロセスは図５０において詳細に示される。図５０はエントリポイント５０００を有する。ステップ５００２が後続し、規則が正常に処理されたか否かを検査する。正常に処理された場合、プロセス４９２０はステップ５０１６で終了する。異常終了の場合、ステップ５００４が後続し、選択された規則の削除候補が削除されたか否かを判定する。削除された場合、プロセス４９２０はステップ５０１６で終了する。削除されていない場合、ステップ５００６が選択された規則の条件を評価するように動作する。ステップ５００８が後続し、規則の条件が真であるか否かを検査する。真である場合、ステップ５０１０が表示候補のリストから規則の削除候補を削除する。真でない場合、ステップ５０１４が規則の条件が未知であるか否かを検査する。未知である場合、プロセス４９２０はステップ５０１６で終了する。未知でない場合、ステップ５０１０に後続するステップ５０１２が実現される。ステップ５０１２は、規則を正常に処理されたものとしてマークする。プロセス４９２０はステップ５０１６で終了する。
【０１９７】
５．４  優先フェーズ
削除フェーズ３１７０の終了時、２つ以上の表示種別が可能な表示種別のリストに残っている可能性がある。この場合、第３のフェーズ優先フェーズ３１８０が残る候補の優先度の降順でのランク付けを開始する。このフェーズ３１８０の終了時、順序付けられたリストの先頭の候補がユーザに対して提示される。残る順序付けられた候補のリストもユーザに対して提示されるため、ユーザはデータに対して代替の表示種別を選択するオプションも得る。表示候補のリストのランク付けに使用される基準は、１セットの優先規則として表現されるのが好ましい。削除フェーズ３１７０と同様、優先規則は性質上モジュール方式であり、他の規則の挙動に影響を及ぼすことなく修正又は削除することができる。また、既存の規則を修正することなく新規の規則をシステムに追加することができる。これに対して、複数の表示種別の中から選択する既存のアプローチでは、容易に修正可能ではない固定の所定の検査シーケンスを使用する。
【０１９８】
本構成では、１対の表示候補を比較し、３つの可能な結果、すなわち、（ｉ）第１の候補が第２の候補よりも優先される場合、（ｉｉ）第２の候補が第１の候補よりも優先される場合、及び（ｉｉｉ）１対の候補に優先される選択が存在しない場合のうちの１つを生成する。他の候補を考慮する必要がないため、このように各規則の範囲を１対の候補に制限することにより規則が単純になる。優先規則のリストが表４に示される。列「ＢよりもＡを優先」は、表示種別Ａが表示種別Ｂよりも優先される場合に真でなければならない条件を示す。列「ＡよりもＢを優先」に関しても同様である。より少ない数の又は追加の規則も可能である。規則３は、他の任意の表示種別がツリー種別よりも優先されることを示す。
【０１９９】
【表４】
2004240954.tif 000012
【０２００】
上述のような１セットのモジュール方式の優先規則を使用することの難点は、結果が競合する可能性である。この競合の発生の仕方には幾通りかある。第１に、同じ対の候補を比較する規則が異なる結果をもたらす可能性がある。第２に、異なる対の候補を比較する規則が共に考慮される場合、あいまいな優先関係になる可能性がある。後者の一例として、３つの表示候補ａ、ｂ、及びｃがある場合を考察する。１つの優先規則がｂよりもａを優先し、別の優先規則がｃよりもｂを優先し、第３の規則がａよりもｃを優先するとする。このシナリオでは、候補ａ、ｂ、及びｃ間での優先関係はあいまいである。
第１の問題は、表示候補の各対に対して最大１つの優先規則を使用することによって回避される。一方、第２の問題は、入念に作成された規則間の制約及び従属関係を課すことなしには回避することができない。この制約及び従属関係は、システムの望ましいモジュール性を壊すことになるであろう。好適なアプローチは、あいまい性を解消する手段を組み込むことである。単純にするため、上述の構成では、入念な競合解消方法を使用するのではなく、単にあいまいな優先関係を無視することによって問題に対処し、これらの結果と一致する表示候補間で任意の順序付けを生成する。
【０２０１】
このようなあいまい性の存在は、表示候補及びその優先関係を有向グラフとして表現することによって検出される。グラフ中の各ノードは表示候補であり、ノード間の有向リンクは優先規則の結果を表す。特に、規則が第２の表示候補よりも第１の表示候補を優先する場合、第１の表示候補に対応するノードから始まり第２の候補を示すノードで終了するリンクが作成される。１対の候補に対して規則が存在しない場合、あるいは、規則は存在するが１対の候補間で優先度が生成されない場合、有向グラフ中の対応するノード間において直接のリンクは作成されない。
【０２０２】
上述の有向グラフ表現に関して、あいまいな優先関係は有向サイクルを生じる。あいまいな優先関係を有する表示種別の有向グラフ表現の一例が図５１に示される。あいまい性は、表示種別「列に関する棒グラフ」と、「行に関する円グラフ」と、「行に関する棒グラフ」との間の有向巡回パスにより明確に示される。
【０２０３】
有向グラフ中の有向サイクルは、R. Sedgewickの「Algorithms」（第２版、Addison?Wesley、１９８９年）に記載されるような確立したアルゴリズムを使用して「強連結の構成要素」を識別することによって検出することができる。強連結の構成要素とは、セットの各ノードからそれ以外のノードへの有向パスが存在する１セットのノードである。このような構成要素が見つかった場合は、セットの各対のノード間のリンクを削除することによってあいまい性が解消される。図５２は、図５１のグラフからあいまいな優先リンクを削除した結果を示す。
【０２０４】
また、上述の有向グラフ表現により、上述の文章に記載されている確立した「トポロジカルソート」アルゴリズムを使用して、全ての表示候補の順序付けを容易に取得することができる。これらのアルゴリズムは、第１のノードから第２のノードへと至る未削除のリンクが存在する場合に順序付けられたリストにおいて第１のノードが第２のノードよりも先に出現するように、ノードの順序付けを生成する。図５２のグラフに対して得られるこのような順序付けの一例は、優先度の降順に、｛列に関する棒グラフ、列に関する表、行に関する表、行に関する棒グラフ、行に関する円グラフ、列に関する円グラフ、ツリー｝である。
【０２０５】
優先フェーズ３１８０のフローチャートが図５３に示される。エントリポイント５３００の後、ステップ５３０２は所望の表示種別の候補ごとにノードを作成する。ステップ５３０４は優先規則を実行する。ステップ５３０６は、第１の候補が第２の候補より優先されるか否かを最初に検査する。優先される場合、ステップ５３１２が第１の候補から第２の候補へと至るリンクを作成する。優先されない場合、ステップ５３０８が第２の候補が第１の候補よりも優先されるか否かを検査する。優先される場合、ステップ５３１０が第２の候補から第１の候補へと至るリンクを作成する。優先されない場合、第１の候補と第２の候補との間には優先関係が存在しないことが示される。ステップ５３１２及び５３１０に後続するステップ５３１４が別の優先規則を実行する。
【０２０６】
ステップ５３１６は、全ての優先規則の実行が終了したか否かを確認するためにチェックを行なう。終了していない場合、制御はステップ５３０６へと戻される。終了している場合、ステップ５３１８が後続し、R. Sedgewickの「Algorithms」（第２版、Addison?Wesley、１９８９年）に記載されるような確立したアルゴリズムを使用して強連結の構成要素を識別するように動作する。ステップ５３２０は、各連結された構成要素内で候補間の全てのリンクを削除する。ステップ５３２２は、好ましくは、トポロジカルソート手順を使用して候補を順序付ける。優先フェーズ３１８０はステップ５３２４で終了する。
【０２０７】
優先規則はＧＵＩからのフィードバックを使用してユーザプリファレンスに適合可能であるのが好ましい。例えば、ある特定のユーザは、列数の多い表が嫌いであり、そのような表を繰り返し転置するかもしれない。このため、優先規則は表に対する最適な列数を修正することができるであろう（表４の規則２を参照）。
【０２０８】
５．５  本方法の他の実現例
セクション５．０で説明したような階層データを提示する方法は、ＸＭＬ文書に対してアイコン又は視覚的要約を提供するのに使用することもできる。例えば、検索エンジンはＸＭＬ文書のランク付けされたリストを検索の結果として戻しても良い。説明した提示は、個々の結果へのリンクをたどることなく、戻された文書の各々に含まれるものをユーザが幾らか洞察できるようにするのに役立つであろう。また、上述の提示方法は、ＸＭＬ文書のアイコン又は要約を提供するのにも使用することができる。このように、ユーザは検索結果が表であるか、グラフであるか、あるいは、画像のグリッドであるかについての通知を受ける。これらのアイコンは、実際の文書へのリンクを含むテキストデータと関連付けられても良い。生成されたアイコンは実際の文書に対するハイパーリンクとして動作しても良い。
【０２０９】
検索結果の意味的な情報をユーザに対してより明確にするために、提示方法はデータビュー（アイコン）の有益なグラフィカル構成要素を拡大するように変更されても良い。例えば、データビューのキャプションはより大きいフォント又は太字のテキストでレンダリングされても良い。低解像度又は小さいサイズでデータビューが表示されても容易に読むことができるように、グラフの軸名及び表の列名を拡大しても良い。
【０２１０】
６．０  新規のデータビューの作成
セクション２．０では、スキーマビューを使用して新規のデータビューを作成する方法について説明している。このモードでは、ユーザはデータビューに必要なデータソースを選択するだけであり、データブラウジングアプリケーション１２０が選択されたデータソースに関連する全てのマッピングを組み込むスキーマビューを作成することができる。更に、ユーザが新規のデータビューに必要なデータ構成要素を選択し、異なるデータソース中の本質的に同じ情報を表現するデータ構成要素を指定し、どのデータをデータビューに出現させるか（例えば、Salary ＞ $100,000及びAge ＜ 40）を制御する制約を指定することが可能なＧＵＩを提供することができる（例えば、図７Ａから図７Ｃ）。ユーザは、同じ情報を表現する異なるソースのデータ構成要素が効果的にデータソースを結合することができる方法を指定しなければならない。
【０２１１】
用語「結合」は、既存のリレーショナルデータベース管理システム（ＲＤＢＭＳ）が２つ以上の表からの情報を効果的に結合するのに使用する。通常、このような結合には合同条件の表現が必要である。例えば、以下の単純なＳＱＬステートメントは、合同条件t1.id = t2.idに基づいて表ｔ１とｔ２との結合を実施する：
select * from t1,t2 where t1.id = t2.id
このＳＱＬ表現の生成系は表ｔ１及びｔ２のｉｄ列が同じデータを有するという予備知識を持つ必要がある。また、同様の合同条件が異なるデータソースのデータ構成要素間にも存在し、異なるデータソースにまたがってデータビューを作成するのに使用される可能性がある。
【０２１２】
次に、既存のデータビューから新規のデータビューを作成する好適なグラフによる方法を説明する。この方法により、ユーザは新規のデータビューを作成するプロセスと所要のマッピングを作成するプロセスとを単一のグラフィカルプロセスへと統合することができる。このグラフィカルプロセスは、セクション２．０において説明したようなスキーマ駆動型ではなく、データ駆動型である。このモードでは、データブラウジングアプリケーション１２０はスキーマビューを生成する必要がなく、ユーザはデータソースに対するスキーマの存在を理解する必要がない。ユーザは実際のデータを操作するので、データ構成要素の名前の意味を正しく理解することに伴う問題が減少する。更に、既存のデータビューは、ユーザが認識していないかもしれないデータソース間の結合に関する暗示の知識をもたらす可能性がある。実際、ユーザは、本人以外が確立した可能性がある結合関係又は合同関係を認識さえしなくても、この方法を使用することで新規のデータビューを作成することができる。
【０２１３】
このようにして、ユーザは、図１２Ａに示されると共にほぼセクション５．０において説明したように、ビデオディスプレイ１１１４上にデータブラウジングアプリケーション１２０により表示されるＧＵＩ１２００において操作する。ＧＵＩ１２００によりユーザはワークスペース１２０２に表示されるデータビューを修正することができる。例えば、ユーザは、提示プロパティ（例えば、フォント、書式、色など）を修正したり、フィルタを適用したり、ソート順を変更したり、データ構成要素を非表示化したり、データ構成要素の名前を変更したり、１つ以上のデータ構成要素に適用される変換／結合を指定・適用したりすることができる。
【０２１４】
好適な構成では、各データビューはＸＱｕｅｒｙ表現と関連付けられる。ＸＱｕｅｒｙ（http://www.w3.org/XML/Query参照）又はＸＭＬ Ｑｕｅｒｙは、物理的にＸＭＬ形式で格納されるか、あるいは、ミドルウェアを介してＸＭＬとして見られるかに関わらず、種々のデータ形式にまたがって問合せを表現するのに使用可能な問合せ言語である。ＸＱｕｅｒｙバージョン１．０は、ＸＰａｔｈバージョン２．０の拡張である。ＸＰａｔｈ２．０及びＸＱｕｅｒｙ１．０の双方において構文的に有効であり、正常に実行される任意の表現は、双方の言語において同じ結果を戻すであろう。ＸＱｕｅｒｙ表現を実行するモジュールはＸＱｕｅｒｙプロセッサと呼ばれる。リレーショナルな階層データソースを処理する能力があるので、ＸＱｕｅｒｙは好適な問合せ言語である。明らかに、同様の機能を有する他の問合せ言語も使用可能である。
【０２１５】
ＸＱｕｅｒｙの基本的な構成単位は表現である。ツリー内でノードの位置を特定するにはパス（ＸＰａｔｈ）表現が使用されるが、繰り返したり変数を結合して中間結果を得たりするにはｆｌｗｏｒ表現が使用される。後者の種類の表現は、２つ以上のデータソース間の結合を表現したり、データを再構築したりするのに有用である場合が多い。ｆｌｗｏｒという名前は、ｆｌｗｏｒ表現で見出される５つの句、すなわち、キーワードのｆｏｒ、ｌｅｔ、ｗｈｅｒｅ、ｏｒｄｅｒ、及びｒｅｔｕｒｎを表す。これらの基本表現のシーケンス及び論理的結合を表現する他の表現も許容される。
【０２１６】
既存の問合せデータを使用して新規のデータビューを作成する方法について図５４を参照して説明する。この方法はデータ構成要素を参照して説明されるが、データ構成要素が、セクション２．０で定義されるように、データノード、データセット、及びデータシリーズも表すことを明らかにすべきである。データ構成要素という用語はこれらの用語の総称として使用される。
【０２１７】
図５４は、データブラウジングアプリケーション１２０のモジュールとして実現されるのが好ましい方法５４００を示す。方法５４００はステップ５４０５で開始される。ステップ５４０５において、既存のデータビューがワークスペース１２０２に表示される。このステップによりユーザは１つ以上の所要の既存のデータビューを選択することができる。これらのデータビューは、セクション５．０において説明したように図１２Ａのデータマークパネル１２０５を介し、データソース又は予め作成されたデータビュー定義の選択から生じても良い。
【０２１８】
ユーザは、ワークスペース１２０２における新規のデータビューの作成を希望することを示す。好適な構成では、ユーザは２つの方法のうちの１つによりこれを行なうことができる。最初に、ユーザはワークスペース１２０２用のコンテキストメニュー１２９２から新規のデータビューオプションを選択することができる。コンテキストメニュー１２９２は、図１２Ａに想像線で示されるように、ワークスペース１２０２の余白の任意の場所でマウス１１０３を右クリックすることによって表示されても良い。データブラウジングアプリケーション１２０は、ステップ５４１０に従って、新規のデータビューに対する可能な表示種別のリストをユーザに対して提示するので、ユーザはこのリストから好適な表示種別を選択することができる。例えば、２つの既存のデータビューが、それぞれ表表示種別及び棒グラフ表示種別を使用してワークスペース１２０２に提示されても良い。ユーザは線グラフの表示種別で新規のデータビューを作成することを選択しても良い。この動作の結果、ステップ５４１５において、選択された表示種別に対するデフォルトのテンプレートが、新規のデータビューとしてワークスペース１２０２に表示される。このデータビューの初期のサイズ及び位置は、セクション５．０において説明したように割り当てられる。また、データブラウジングアプリケーション１２０は、新規のデータビューと関連付けられたＸＱｕｅｒｙ表現を初期化する。
【０２１９】
第２の方法では、ユーザは１つ以上の既存の表示されたデータビューから１つ以上のデータ構成要素を選択し、データ構成要素をワークスペース１２０２中の未使用の位置へとコピー又はドラッグすることができる。データ構成要素をドロップ又はペーストすると、新規のデータビューがドロップ位置又はペースト位置に作成される。このデータビューは、既存のデータ構成要素の表示種別と一致する表示種別である。例えば、データ構成要素が、既存のデータビューにおける線グラフのｘ軸として動作するようにワークスペース１２０２へとドラッグされる場合、新規のデータビューは線グラフになる。作成されたデータビューは、ｘ軸として動作するドラッグされた構成要素を伴って線グラフに対するデフォルトのテンプレートを使用して表示されるであろう。
【０２２０】
しかし、２つのデータ構成要素が、それぞれ線グラフ及び表からワークスペース１２０２中の位置へとコピー・ペーストされる場合、新規の表示種別は最小の制約を有するもの（すなわち、表）である。データビューを初期化するのに２つ以上の構成要素が使用される場合、新規のデータビューがワークスペースにおいて作成される前に、後述のステップ５４２５で実行されるチェックが実行されることになる。
【０２２１】
ステップ５４１５から続くステップ５４２０において、ユーザは、ワークスペース１２０２中の既存の１つ以上のデータビューから１つ以上のデータ構成要素をコピーすることを選択し、新規のデータビューにおいて指定の役割で動作させることができる。役割は、新規のデータビュー中のペースト又はドロップの選択された目標位置により示される。例えば、ユーザがコピーされたデータセットを線グラフのｘ軸へとペーストする場合、ユーザはデータセットがグラフに対するｘ軸として動作するように希望していることが想定される。同様に、ユーザがデータセットを表のある特定の列へとペーストする場合、データセットがその表の列に置き換わることが想定される（すなわち、表の特定の列の役割を負うべきである）。また、メニューオプションは、選択された表の列の前後に挿入するオプションをユーザに対して提供するのが好ましい。
【０２２２】
２つ以上のデータ構成要素がコピーされる場合、新規のデータビューにおける示された役割は２つ以上のデータ構成要素をサポート可能でなければならない。例えば、好適な構成では、グラフ（線グラフ又は棒グラフ）テンプレートは、２つ以上のｙ軸データセットをサポートするが、ｘ軸データセットは１つしかサポートしない。代替の構成では複数のｘ軸を許容することができるので、この機能をサポートするテンプレートを有する。同様に、表は複数の列をサポートすることができ、円グラフは１つ以上の個々の扇形部分（各々が単一のデータシリーズを視覚化する）をサポートしても良い。換言すれば、新規のデータビューに対する可能な役割は、データビューを作成するのに使用されるテンプレートによって決まる。新規のデータビューにおける示された役割が複数のデータ構成要素をサポートしない場合、後述するように５４３０においてエラーが生成される。
【０２２３】
コピーは２つの方法のうちの１つにより行なうことができる。最初に、ユーザは、既存のデータビューからデータ構成要素をコピー（又はカット）し、それを新規のデータビューへとペーストすることができる。第２に、ユーザはデータ構成要素を選択し、それを新規のデータビューへとドラッグすることができる。ドラッグ中、ドラッグされた列の影が示されるのが好ましい。コピーされたデータの役割は、データ構成要素ドロップ目標（例えば、グラフのｘ軸）又はセパレータドロップ目標（例えば、２つの列間の境界線）により示すことができる。後者の場合、ドラッグされたデータ構成要素は境界線の位置で挿入される。データビュー間のドラッグ操作の結果、ドラッグされたデータ構成要素はコピーされる。データビュー内のドラッグ操作も許容されるが、この場合、ドラッグされたデータ構成要素は元の場所から目標場所まで移動される。
【０２２４】
データ構成要素がデータビューへと追加される前に、ステップ５４２５においてチェックが実行され、データ構成要素が新規のデータビューにおける示された役割と互換性があるか否かが確認される。換言すれば、ユーザにより示されるデータ操作は、表示種別の意味体系と一致する必要がある。これについてはセクション５．０及び８．０において説明されている。このことは、ユーザがデータセットを表データビューへとドラッグしてもこのデータセットを既に表にある他のデータセットへと結合することができない場合、ドラッグは許容されないことを意味する。表は、通常、行のデータが単一のエンティティに関する場合にのみ意味を持つからである。ステップ５４３０において、エラーメッセージがユーザに対して提示され、試みたドラッグを許容しない理由が説明される。プロセスはステップ５４４０へと続く。同様に、数値以外のデータセットをドラッグして棒グラフの「ｙ軸」として動作させる試みも許容されないであろう。
【０２２５】
データブラウジングアプリケーション１２０は、既存のデータビューと関連付けられた問合せ及び操作されたデータ構成要素と関連付けられたデータ指定の双方を検査することによって、試みたデータ操作が許容可能か否かを確認することができる。データ指定は、セクション５．０において説明した表示種別決定プロセスの一部として形成され、操作されたデータを問合せ中の対応する指定と連結する手段を提供する。既存のデータビューは、新規のデータビューに対するデータのソースとして有効に動作する。また、データブラウジングアプリケーション１２０は、既知の合同（結合）の独自の格納された知識を利用することもできる。データブラウジングアプリケーション１２０はこのような知識を永続的に維持管理する。
【０２２６】
ステップ５４２５において、試みたデータ操作が許容可能であることが確認される場合、ステップ５４３５において、データ構成要素が表示された新規のデータビューへと追加される。新規のデータビューと関連付けられたＸＱｕｅｒｙも更新される。これは、関連付けられた問合せが常に表示されたデータと一致し、ユーザがデータビューを保存することをいつでも選択できることを意味する。更なるデータ構成要素がチェックボックス５４４０において新規のデータビューへとコピーされる場合、プロセスはステップ５４２０へと戻る。
【０２２７】
図５４のプロセスについて１セットの既存のデータビューから棒グラフを作成する更なる例を参照して詳細に説明する。特定の年における目標数の特許の出願に関して会社の各プロジェクトがどの程度十分に機能したかを示す図の編集をユーザが希望するものとする。会社はデータソースＰｒｏｊｅｃｔｓＤＢを有し、このデータソースはデータブラウジングアプリケーション１２０を使用してデータサーバを介してブラウズすることができる。このデータソースは、会社の全てのプロジェクトの詳細を含む。その構造は以下のように表現することができる：
ProjectsDB
Year
Project
Code
Name
Description
Budget
Manager
PatentEstimate
ProjectResources
ProjectCode
EmployeeID
PersonMonths
ユーザは、自身のデータブラウジングアプリケーション１２０に以下の結合情報を記録しているのが好ましい：
ProjectsDB/Year/Project/Code =
ProjectsDB/Year/ProjectResouces/ProjectCode
会社のプロジェクトに関する情報をデータビューに表示するために、ユーザは、図１２Ａに示すように、データマークパネル１２０５においてＰｒｏｊｅｃｔｓＤＢデータマーク１２１０を選択することができる。これにより、最初にプロジェクトデータが記録された年ごとのリンクが表示されるのが好ましい。ユーザは対象の年（例えば、２００２年）を選択することができる。この結果、データビューは更新され、２つの更なるリンク、すなわち、Ｐｒｏｊｅｃｔ用のリンク及びＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓ用のリンクが示される。ユーザがＰｒｏｊｅｃｔリンクを選択する場合、図１２Ａの左上端に示されるようなデータビューがワークスペース１２０２に表示される（一部の列データは不図示）。位置オープン制御１２０８は、ＵＲＩとしての現在選択されているデータビューと関連付けられる問合せを表示する。この場合、ＸＱｕｅｒｙ表現はパス表現である。
【０２２８】
このデータを「Joe Brown」により管理されるプロジェクトのみを示すように制限するために、ユーザはＭａｎａｇｅｒ列を選択し、この列に対してフィルタ制約を指定することができるだろう（例えば、Ｍａｎａｇｅｒ＝「Joe Brown」）。直ちに、データビュー中のデータは、選択された年の「Joe Brown」により管理されるプロジェクトのみに制限されるであろう。このフィルタリング操作は現在のタスクには不要である。フィルタ操作については、セクション７．２において更に詳細に説明される。
【０２２９】
Ｐｒｏｊｅｃｔデータビューに対して指定されるフィルタ制約は、データブラウジングアプリケーション１２０により記録される。ユーザが再利用のためにデータビューの保存を選択する場合、フィルタ制約はそのデータビューに対する問合せへと統合される。例えば、関連付けられたＸＱｕｅｒｙは以下の通りであろう：
ＸＱｕｅｒｙ例１
【０２３０】
2004240954.tif 000013
【０２３１】
ＸＱｕｅｒｙ例１では、http://www.example/com/Projectsにより識別されるプロセスはデータサーバを表し、疑問符に後続する表現/ProjectsDBはデータサーバに対する問合せを表す。
この例においてフィルタを適用した結果、ＸＱｕｅｒｙ表現がパス表現からｆｌｗｏｒ表現へと変更されている。フィルタはｆｌｗｏｒ表現のｗｈｅｒｅ句を使用して表現されるのが好ましい。このプロセスについてはセクション７．２において更に詳細に説明される。代替の構成では、パス表現を保存し、述語の形式でフィルタを適用しても良い。
【０２３２】
同じワークスペース１２０２を使用して、ユーザはこれらのプロジェクトに必要なリソースを表示することを選択しても良い。このためには、ユーザは再度ＰｒｏｊｅｃｔｓＤＢデータマーク１２１０、所望の年を選択すると共に、今回はＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓリンクを続けて選択する。この結果、ＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓデータ構成要素に含まれる全てのデータ構成要素を列挙するテーブルが得られる。データブラウジングアプリケーション１２０は、図１２Ｂに示すように、ＰｒｏｊｅｃｔデータビューのＣｏｄｅをＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓデータビューのＰｒｏｊｅｃｔＣｏｄｅと結合コネクタ１２２２を使用して自動的に連結する。これらの２つのデータ構成要素の合同は既知であるので、結合コネクタ１２２２の表示は可能である。ＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓデータビューの行数は多くても良い。図１２Ｂはデータビュー中の垂直スクロールバー１２２０を示す。このバーはＰｒｏｊｅｃｔＣｏｄｅ「ＤＬＥ」及び「Ｐａｇｅ＋」を有するプロジェクトに対するデータのみを示すために部分的にスクロールされている。
【０２３３】
タスクを終了するには、ユーザは指定された２００２年にプロジェクトごとに実際に出願された特許の件数に関する情報を取得しなければならない。これを達成するために、ユーザは、データマークパネル１２０５のデータビューセクションにおいてＰｒｏｊｅｃｔ Ｐａｔｅｎｔｓ ２００２データビュー１２３０を選択する。このデータビューの結果、図１２Ｃに示されるように、セクション５．０において説明した方法を使用して棒グラフが表示される。このデータビューは、データマークパネル１２０５におけるＣｏｍｐａｎｙＰａｔｅｎｔｓデータマーク１２３１を使用して予め得られるものである。このデータマークは、以下のように階層的に表現可能なデータソースに対応する：
Patents
Invention
ProjectCode
InventionCode
Year
InventorName1
InventorName2
InventorName3
InventorName4
DataFiled
Abstract
Ｐｒｏｊｅｃｔ Ｐａｔｅｎｔｓ ２００２データビューと関連付けられたＸＱｕｅｒｙは以下の通りである：
ＸＱｕｅｒｙ例２
【０２３４】
2004240954.tif 000014
【０２３５】
ＵＲＩ（http://www.example.com/Patent）により識別されるプロセスはＰａｔｅｎｔｓデータソース専用のデータサーバを表す。
この問合せは、まず、全ての別個のＰｒｏｊｅｃｔＣｏｄｅ値を抽出し、各値に対して、問合せは２００２年中に出願された発明のリストを取得するように命令する。このリスト中の要素の数は、ＸＱｕｅｒｙのcount()関数を使用してカウントすることができる。問合せはＰｒｏｊｅｃｔ要素のリストを戻す。各Ｐｒｏｊｅｃｔ要素は、変数＄ｐから得られる内容を伴うＰｒｏｊｅｃｔＣｏｄｅ要素と、count()関数を変数＄ｉｎｖ（ＸＱｕｅｒｙのｌｅｔＡｓｓｉｇｎｍｅｎｔ句を満たす全てのＩｎｖｅｎｔｉｏｎ要素のリストを保持する）に適用することにより得られる内容を伴うＰａｔｅｎｔｓＦｉｌｅｄ要素とを有する。
【０２３６】
ユーザは、自身のデータブラウジングアプリケーション１２０に以下の結合情報を記録しているのが好ましい：
ProjectsDB/Year/Project/Code = Patents/Invention/Projectcode
結合は、ユーザがワークスペース１２０２において２つのデータセットを選択し、ツールバー１２０７上で結合アイコン１２３２を選択することにより登録することができる。この動作の結果、結合が、選択されたデータ構成要素に対してデータブラウジングアプリケーション１２０により格納される。
【０２３７】
ステップ５４１０と同様に、ユーザはワークスペース１２０２の余白を右クリックし、表示されたコンテキストメニュー１２９２からオプション新規のデータビューを選択する。続いて、ユーザは表示種別の提示されたリストから「Ｂａｒ Ｃｈａｒｔ」を選択し、棒グラフに対するデフォルトのテンプレートが、図１２Ｄに示されるように、ワークスペース中の次の利用可能なグリッド単位に表示される。テンプレートには最初はデータがなく、データ構成要素に対するスロット（例えば、ｘ軸スロット１２５２）及びテキストオブジェクト（例えば、タイトルスロット１２５０）のみである。テキストスロットは、シェーディングによってデータ構成要素スロットと区別されるのが好ましい。図１２Ｄにおいて、テキストスロットは破線の境界線（例えば、１２５０）により区別される。また、テンプレートはデータが新規のデータビューに対して指定されると生成される複数のバー１２５８の一例を示すのが好ましい。
【０２３８】
新規のデータビューに対するｘ軸を確立するために、ユーザはＰｒｏｊｅｃｔ Ｐａｔｅｎｔｓ ２００２データビューからＰｒｏｊｅｃｔＣｏｄｅデータ構成要素をコピーし、このデータ構成要素をｘ軸用に確保されたスロット１２５２へとペーストすることができる。また、ユーザはこのデータ構成要素をスロット１２５２へとドラッグすることもできる。２００２年のプロジェクトを表現するｘ軸用のラベルが直ちに表示される。データセットがコピーされる場合、データセットの繰返し操作により暗示される任意の述語が維持管理されるのが好ましい（例えば、Year = 2002、ＸＱｕｅｒｙ例２参照）。
【０２３９】
ユーザは、表中の関連する列を選択し、キーボード１１０２上でＣＴＲＬ Ｃを押下し、このデータセットを新規のデータビューの左側のｙ軸へとペーストすることによって、ＰｒｏｊｅｃｔデータビューからＰａｔｅｎｔＥｓｔｉｍａｔｅデータセットをコピーすることができる。これは、データブラウジングアプリケーション１２０に対して、ペーストされたデータセットが選択されたｘ軸に対してｙ軸として動作し、このｘ軸に従属することを示す。データブラウジングアプリケーション１２０は、ＰｒｏｊｅｃｔデータビューのＣｏｄｅデータ構成要素がＰｒｏｊｅｃｔ Ｐａｔｅｎｔｓ ２００２データビューからのＰｒｏｊｅｃｔＣｏｄｅデータ構成要素へと結合されていることと、ＰｒｏｊｅｃｔデータビューのＣｏｄｅ及びＰａｔｅｎｔＥｓｔｉｍａｔｅデータ構成要素が点に関する対応を有することとを知っているので、この操作は許容可能な操作である。
【０２４０】
コピーされたデータセットが受信中のデータビューにおいて（例えば、表データビューにおけるように）他のデータセットと一致する必要がある場合、図５４のステップ５４２５は、これが可能か否かを判断する。最も単純な場合、コピーされたデータセットはデータビューの他のデータセットと同じ親ノードを共有しても良いので、表データビューに対する現在の反復子は別のデータセット（例えば、表の列）の追加によっても不変である。しかし、他の場合には、反復子を伴う結合条件及び表の既存の反復子が存在し、データセットのコピーが可能なこともある。結合条件は、２つの反復子を統一できることを暗示するが、データの１対１の対応が存在することは暗示しない。
【０２４１】
例えば、ＰｒｏｊｅｃｔｓＤＢデータソースは、全てのプロジェクトの記録を有しても良いが、Ｐｒｏｊｅｃｔ Ｐａｔｅｎｔ ２００２データビューはこれらのプロジェクト（すなわち、特許が出願されたプロジェクトのみ）のサブセットを含んでも良い。このため、ユーザがＰｒｏｊｅｃｔ Ｐａｔｅｎｔ ２００２データビューのｙ軸から図１２Ｃの表示されたＰｒｏｊｅｃｔデータビューの新規の列へとＰａｔｅｎｓＦｉｌｅｄデータセットをコピーすることを選択する場合、ProjectsDB/Year/Project/CodeとPatents/Invention/ProjectCodeとの間の結合条件により、この操作は許容されるであろう。しかし、表の新規の列に対する反復子により、表に列挙されるプロジェクトのサブセットが得られることになる（すなわち、Ｐｒｏｊｅｃｔデータビューに列挙された全てのプロジェクトがＰａｔｅｎｔｓＦｉｌｅｄに対する対応の値を有する訳ではない）。換言すれば、結合されたデータをユーザに対して提示する方法は２つ以上ある。例えば、ＰａｔｅｎｔｓＦｉｌｅｄに対して対応する値をもたない場合にプロジェクトを更新された表に列挙すべきか？及びＰａｔｅｎｔｓデータソースがＰｒｏｊｅｃｔｓＤＢデータソースに格納されていないプロジェクトを参照する場合、新規のプロジェクトを表に追加すべきか？である。これらの異なるオプションは、結合条件を実行する異なる方法に対応する。好適な構成により、ユーザは結合条件を実施する以下の３つの方法、すなわち、（ｉ）相異ユニオン、（ｉｉ）外結合、及び（ｉｉｉ）内結合から選択することができる。
【０２４２】
第１の相異ユニオン方法において、データブラウジングアプリケーション１２０は、結合属性値（例えば、上述の例では、ProjectsDB/Year/Project/Code及びPatents/Invention/ProjectCode）の相異（すなわち、非反復性）ユニオンを介して繰り返す問合せを生成し、識別された結合属性値ごとにデータ結果を生成する。１つのデータソースからデータが欠落している場合、空の要素又はゼロ要素が生じる。この方法により、データが合併し、ゼロセル又は空のセルを有するテーブルが得られる。ユーザがデータに不慣れであるか、あるいは、誤ったデータの検出を希望する場合には有用である。続いて、空のデータ又はゼロデータを削除するために、フィルタ操作をデータビューに適用することができる。
【０２４３】
第２の外結合方法において、データブラウジングアプリケーション１２０は、追加されたデータセットがＸＱｕｅｒｙのネスト状の（内部の）ｌｅｔ句又はｆｏｒ句を介して得られる問合せを生成する。内部のｌｅｔ句は２つの反復子間での１対１の関係を暗示するのに対し、内部のｆｏｒ句は１対多数の関係を暗示する。ネスト状の繰返し操作は、現在の外部繰返しに対する結合属性値の値により叙述され、外部繰返し操作のデータ結果ごとにデータ結果が生成される。このため、上述の例の場合、表には余計な行が出現せず、一部の行はＰａｔｅｎｔｓＦｉｌｅｄデータ構成要素に対してゼロ値を有する可能性がある。
【０２４４】
最後の内結合方法は、外部繰返し操作及び内部繰返し操作の双方が結果を有する場合にのみデータ結果が作成される点を除いて外結合方法に類似している。このため、上述の例の場合、ＰａｔｅｎｔｓＦｉｌｅｄデータ構成要素に対して値を持たない行は表から削除される。
【０２４５】
ユーザは、ブラウジングセッションに対して使用されるデフォルトの結合挙動を指定することができるのが好ましく、このブラウジングセッションは全ての結合操作に対して使用される。これは、どの種別の結合が必要であるかをユーザが操作ごとに指定しなくても良いことを意味する。しかし、データブラウジングアプリケーション１２０は、ユーザが特定のデータビューに対して結合方法を変更するメニューオプションを提供する。この結果、データビューと関連付けられたＸＱｕｅｒｙは繰返しの異なるパターンを反映するように変更される（例えば、distinct-values繰返し操作の使用からネスト状ｆｏｒＡｓｓｉｇｎｍｅｎｔノードへの変更）。結合操作の実施についてはセクション７．０において更に詳細に検討する。
【０２４６】
例のタスクへと戻ると、ＰａｔｅｎｔＥｓｔｉｍａｔｅデータセットが新規のデータビューへとコピーされる場合、結果として生じるデータビューはユーザにより選択されたデフォルトの結合方法によって決まることになる。相異ユニオン方法が使用される場合、ｘ軸上のデータは以下のデータ構成要素の相異ユニオンを反映するであろう：
・ProjectsDB/Year[.=2002]/Project/ProjectCode、及び
・Patents/Invention/[Year=2002]/ProjectCode
これは新規のプロジェクトコード値が、ＰａｔｅｎｔｓデータソースではなくＰｒｏｊｅｃｔｓＤＢデータソースに存在するプロジェクトを反映するｘ軸上に出現する可能性があることを意味するであろう。この新規の値は、関連付けられた親推定値を有するであろう。しかし、一部のプロジェクトコードは対応する親推定値（すなわち、Ｐａｔｅｎｔｓデータソースからのプロジェクトコード）を持たないこともある。
【０２４７】
外結合方法が使用される場合、新規のプロジェクトがｘ軸上に出現することはなく、一部の親推定値は図中に出現しない可能性がある。内結合方法が選択される場合、対応する親推定値がないと問合せから削除されるために一部のプロジェクトコードがｘ軸から消失する可能性がある。この例の以下の記述では、相異ユニオン方法が想定される。
【０２４８】
実際に出願された特許の件数と２００２年に各プロジェクトで推定された特許の件数との比較を取得するために、ユーザはＰｒｏｊｅｃｔ Ｐａｔｅｎｔ ２００２データビューからＰａｔｅｎｔｓＦｉｌｅｄデータセットを選択することができる。これは、ｙ軸名（軸と関連付けられた単一のデータセットがある場合）を選択するか、あるいは凡例（表示されている場合）からデータセット名を選択することによって達成することができる。また、このデータセットは、新規のデータビューの左側のｙ軸へとペーストすることもできる。この操作は、データブラウジングアプリケーション１２０に対して、ＰａｔｅｎｔＥｓｔｉｍａｔｅデータセット及びＰａｔｅｎｔｓＦｉｌｅｄデータセットの双方が同じｙ軸を使用すべきであることを示す。この結果、ＰａｔｅｎｔＥｓｔｉｍａｔｅ及びＰａｔｅｎｔｓＦｉｌｅｄが列挙された新規の棒グラフに対する凡例が描かれる。ユーザは、適切なスロットを選択し、含まれたテキストを編集することによってこれらのデータセット名を修正することができる。このため、例えば、図１２Ｅにおいて、ユーザはｙ軸名を「Ｎｏ ｏｆ Ｐａｔｅｎｔｓ」、凡例のデータセット名を「Ｅｓｔｉｍａｔｅ」及び「Ａｃｔｕａｌ」として編集している。
【０２４９】
ユーザの最終的なタスクは、この結果を得るために使用したリソースを棒グラフ上に示すことである。ユーザはＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓデータビューからＰｅｒｓｏｎＭｏｎｔｈｓデータセットを選択し、このデータセットを新規のデータビューの右側のｙ軸へとコピーする。これは、データブラウジングアプリケーション１２０に対して、ＰｅｒｓｏｎＭｏｎｔｈｓもＰｒｏｊｅｃｔＣｏｄｅに対してグラフ化されることを示す。ＰｒｏｊｅｃｔｓＤＢ／Ｙｅａｒ／Ｐｒｏｊｅｃｔデータ構成要素及びＰｒｏｊｅｃｔｓＤＢ／Ｙｅａｒ／ＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓデータ構成要素のＣｏｄｅ要素とＰｒｏｊｅｃｔＣｏｄｅ要素との間の結合条件があるため、これは許容可能な操作である。好適な構成では、データブラウジングアプリケーション１２０は、新規のデータビューへとコピーされる前にプロジェクトごとの人月を合計しなければならないことを想定する。代替の構成では、最初に、プロジェクトにかかわる全ての人員を合計することによって、ＰｒｏｊｅｃｔＲｅｓｏｕｒｃｅｓ表がＰｒｏｊｅｃｔＣｏｄｅによりグループ化されることをユーザは指定する必要があるかもしれない。
【０２５０】
このデータセットに対するデータが直ちに示される。この新規のデータ構成要素は凡例へと追加される（ＰｅｒｓｏｎＭｏｎｔｈｓデータ構成要素が「Ｒｅｓｏｕｒｃｅｓ」へと改名された図１２Ｆを参照）。テンプレートは種々の手段を使用して汎用項目により使用されるｙ軸間の区別を行なうことができる。説明した例では、色の使用が想定される。換言すれば、ＰｅｒｓｏｎＭｏｎｔｈｓデータ構成要素に対する棒は、ＰａｔｅｎｔＥｓｔｉｍａｔｅデータ構成要素及びＰａｔｅｎｔｓＦｉｌｅｄデータ構成要素とは違う色で示される。あるいは、右側のｙ軸に対するデータを表現するのに線を使用し、棒形式と線形式とが組み合わさった図を作成することもできるだろう。
【０２５１】
ユーザはタイトル及び（場合によっては）一部の軸名を編集することができる。最終結果は図１２Ｆに示される。この結果に対して生成されるＸＱｕｅｒｙは以下の通りである：
ＸＱｕｅｒｙ例３
【０２５２】
2004240954.tif 000015
【０２５３】
最終的な問合せは３つのデータのソース（プロジェクトデータ、特許データ、及びプロジェクトリソースデータ）間の結合を表現する。いずれの場合でも、結合は相異ユニオン方法を使用して実施される。相異ユニオン演算（ＸＱｕｅｒｙ例３に示すようなdistinct-values関数を使用）の実行は、一般的に、非効率的である。代替の構成では、利用可能なデータを分析することによって１次繰返し操作と関連付けられた処理を削減することができる。例えば、データの検査がProjectsDB/Year/Project/Codeデータ構成要素が全てのプロジェクトコードの完全なリストを含むことを実証する場合、相異ユニオン演算はProjectsDB/Year/Project/Code値に対する繰返しにより置き換えることができるだろう。
ユーザは、データビュー（例えば、ＸＱｕｅｒｙ例１）にフィルタを適用することもできる。このフィルタは、問合せにより戻される任意のデータ構成要素を伴うことができる。このため、例えば、問合せがパス表現である場合、フィルタ制約はデータビューに対する任意の表示された子孫要素を伴うことができる。問合せがｆｌｗｏｒ表現である場合、フィルタ制約は問合せにより戻される任意のデータ構成要素（非表示のデータ構成要素を含む）を伴っても良い。好適な構成では、フィルタはデータビューのプロパティとして扱われる。ユーザは、ソースデータビューのフィルタがデータ構成要素を伴って目標データビューへとコピーされるべきか否かを指定することができる。これは、ユーザによる設定が可能なシステムプリファレンスである。設定されると、データのコピーの際にソースデータビューの有効なフィルタが目標データビューのフィルタへと追加される。
【０２５４】
生成されたＸＱｕｅｒｙはデータビュー定義に含まれる。ＸＱｕｅｒｙを生成可能な方法についてはセクション７．０において更に詳細に説明される。データビュー定義は、提示情報とデータビューの構築（セクション１１．０参照）で使用される任意のマッピングとを含む。尚、生成された問合せは、データが棒グラフとして表示される必要があることを指定しない。引き続き問合せが実行されると、セクション５．０で説明した提示プロセスがデータに対する最善の表示種別を判定する。生成された問合せは、作成されたデータビューが必要とするデータのみを定義する。これは、問合せに含まれるデータソースが、問合せが作成されたときとその後で再表示されたときとで変化する場合、提示に使用される表示種別がデータに適合することを意味する。
【０２５５】
新規のデータビューを生成するこのグラフィカルな方法は、既存のデータ構成要素の変換又は結合の結果として新規のデータ構成要素を作成するのに使用することができる。ユーザは今後再利用可能な新規のマッピングとしてこれらの操作を保存することを選択することができる。この新規のマッピングは、新規のデータビューの定義の一部になると共に、ユーザのマッピングセットの一部としても保存される。ユーザは、新規のマッピングを作成せずに変換操作又は結合操作の実行を選択することができる。この場合、操作は、新規のデータビューに対して生成されたＸＱｕｅｒｙへと統合される。このプロセスについてはセクション７．０において更に詳細に説明される。
【０２５６】
図１３Ａはワークスペース領域１２０２を示し、この領域はＣｏｎｔａｃｔｓデータビュー１３０５を示す。このデータビューは、データ構成要素ＳｅｃｏｎｄＮａｍｅ、ＦｉｒｓｔＮａｍｅ、Ａｄｄｒｅｓｓ、及びＥｍａｉｌから構成される４つの列を含む表である。この例では、ユーザは新規のデータビューを作成することを希望する。このデータビューでは、名前が「SecondName, FirstName」の形式のように出現し、新規のデータ構成要素のＳｅｃｏｎｄＮａｍｅ部分が大文字であり、太字で提示される。ユーザがこの操作の再利用を希望する場合、マッピングが作成されるべきである。
【０２５７】
この結果は、ＧＵＩ１２００を使用して、ユーザがマッピングの第１のデータ構成要素、すなわち、ＳｅｃｏｎｄＮａｍｅというタイトルのデータ列を選択し、この列１３１０をワークスペース１２０２の空白領域へとドラッグすることによって達成することができる。この操作は上述のように行なわれる。ユーザは、マッピングの第２のデータ構成要素（この場合、ＦｉｒｓｔＮａｍｅというタイトルのデータ列を選択し、この列１３２０を新規のデータビュー中の既存の列と部分的に重複する位置へとドラッグする。新規の列は、部分的に左側又は右側で重複する可能性がある。図１２Ａから図１２Ｆを参照して先に説明したデータ付加ドラッグ操作と同様に、ドラッグ中はドラッグされた列の影が示される。列が部分的な重複位置にドロップされる場合、図１３Ｂに示すように、データブラウジングアプリケーション１２０は２つの列が単一の列１３５０へと結合（連結）されるべきであると想定する。連結された列１３５０は、左端の列（この場合、ＳｅｃｏｎｄＮａｍｅ）の名前を想定する。
【０２５８】
２列間の結合操作は、ユーザが最初にＳｅｃｏｎｄＮａｍｅ列及びＦｉｒｓｔＮａｍｅ列を新規のデータビューの最初の２列へとドラッグすることにより示すことができる。ユーザは、キーボード１１０２及びマウス１１０３を使用してＣＴＲＬ又はＳＨＩＦＴの左クリック操作を介して両列を選択し、コンテキストメニュー１２９２オプションを選択して選択されたデータ構成要素を結合することができる。この手順の結果、両列は図１３Ｂに示すように単一の列へと連結されることになる。ユーザがデータ構成要素（例えば、表の列）上での変換の実行を希望する場合、ユーザはデータ構成要素を選択し、コンテキストメニュー１２９２上で変換オプションを選択することができる。
【０２５９】
マッピングと関連付けられた変換を定義するプロセスについては、セクション３．０及び４．０においてほぼ説明されている。ユーザはマウスポインタ１１０３を使用して表のセルをクリックすることによってデータの例を選択する。このため、例えば、図１３Ｂにおいて、ユーザは表１３５０のセル１３６０ａを選択している。ユーザは例のテキストを編集し、データブラウジングアプリケーション１２０に対して、この列に対するデータが変換されることを示す。この場合、明確にするために、図１３Ｂの離れたセル枠１３６０ｂにおいて示すように、新規のデータ構成要素のＳｅｃｏｎｄＮａｍｅ部分が大文字に変換され、２つのソースデータ構成要素間にコンマ及びスペースが挿入される。また、ユーザは、太字書式を新規のデータ構成要素のＳｅｃｏｎｄＮａｍｅ部分へと適用している。ユーザが終了を示すためにキーボード１１０２上でＥＮＴＥＲを押下したのを検出すると、データブラウジングアプリケーション１２０は、セクション４．０において説明した方法を使用して編集された例を分析し、ユーザの編集された例により示される変換を推定する。
【０２６０】
ユーザは、セクション３．０及び４．０において説明した方法を使用して推定された変換の受付け又は修正を行なうことができる。また、ユーザは、実行された操作がマッピングとして保存されるべきか否かを指定することもできる。このプロパティに対するデフォルトの挙動が、ユーザプリファレンスとして格納されるのが好ましい。ユーザがマッピングを作成することを選択する場合、データ構成要素の名前はマッピングに対する目標データ構成要素名として登録される。マッピングはユーザのネーム空間において作成される。
【０２６１】
表１３５０における更新されたデータが図１３Ｃに示される。ユーザは、列のタイトル１３８０を選択してその名前をＭｙＮａｍｅへと変更することができる。例の名前１３８２から認識されるように、姓は大文字且つ太字に変換され、コンマ及びスペースによって名と隔てられる。マッピングの作成中には、これらの提示特性はマッピングの一部として格納されるのが好ましい。作成されたマッピングは直ちにユーザのマッピングセットへと保存されるのが好ましい。マッピングはデータビューの定義の一部として格納されるが、この定義はユーザが保存を選択した場合のみ保存される。明らかに、本開示の趣旨から逸脱することなく、新規のマッピングを定義するための、他のデータに基づくＧＵＩ方法も実現することができるだろう。
【０２６２】
７．０  データビュー用の問合せの維持管理
前のセクションでは、ユーザがＧＵＩにおいて既存のデータビューと関連付けられたデータを操作し、新規のデータビューを視覚的に作成することができる方法を説明している。この方法は、既存のデータビューを修正するのにも使用することができる。例えば、ユーザはグラフからデータシリーズを選択・削除することができる。新規のデータビューを作成するプロセス及び既存のデータビューを修正するプロセスの双方は、表示されたデータビューごとに問合せ表現を維持管理することを伴う。データビューに対する問合せを内部で維持管理するこのプロセスについて説明する。
【０２６３】
ＸＱｕｅｒｙ表現は、データビューの表示されたＸＭＬデータの根ノードと関連付けられる。データブラウジングアプリケーション１２０がイントラネット又はインターネットからデータビューに対するデータを取得するのに使用するのがこの表現である。ＸＱｕｅｒｙ表現はツリー構造として表現することができる。ＸＱｕｅｒｙＸ構文（http://www.w3.org/TR/xqueryx参照）が使用されるのが好ましいが、他の問合せツリー構造も使用することができる。ＸＱｕｅｒｙのＸＱｕｅｒｙＸ表現の一例が図５８に示される。これは上述のＸＱｕｅｒｙ例１のＸＱｕｅｒｙＸ形式であり、図１２Ａに示すＰｒｏｊｅｃｔデータビューに対する問合せを表現する。問合せツリー構造では、問合せの個々の構成要素（例えば、ｆｏｒ句）が別個のノードツリー（例えば、ｆｏｒＡｓｓｉｇｎｍｅｎｔノード）へと分割される。これにより、例えば、繰返し操作はサブツリーとして別のサブツリーへと抽出又はコピーすることができる。これは、本質的に、ユーザが１つのデータビューから別のデータビューへとデータセットをコピーする際に実行されなければならないプロセスである。
【０２６４】
ユーザが示したデータの操作により生成される問合せは、データのコピー元のデータビューではなく、データソースにより表現されるのが好ましい。これは、生成された問合せが他のデータビュー定義から独立しており、他のデータビュー定義と交換可能であり、他のユーザがデータのコピー元である元のデータビュー定義へのアクセス権を持たないことを意味する。また、ソースデータビューを解放せずに感知可能な情報を有するであろうデータビューからデータ構成要素をコピーできることも意味する。セクション２．０において述べたように、好適な構成では、データのセキュリティがデータソースレベルで維持管理されることを想定する。更に、生成された問合せに対するデータは、中間のデータビューを読んだり処理したりせずに必要なデータソースから直接取得することができる。
【０２６５】
代替の構成では、新規のデータビュー構築の元となるデータビューによって決まる問合せを生成しても良い（すなわち、ソースデータビューはデータソースとして扱われる）。この方法は新規の問合せを作成するプロセスを単純にする。生成された問合せに対するデータを取得するプロセスは、この問合せに含まれる全てのデータビューの定義のアクセス・分析を伴うのでより複雑である。
【０２６６】
データビューが提示のために選択される場合、データビューと関連付けられた問合せが問合せツリーへと解析される。データビューと関連付けられた図３１Ａのデータビューマネージャオブジェクト３１２５は、この問合せツリーを使用してデータビューに対するデータを取得する。結果のデータは、セクション５．０において説明したように、対応するデータビュープレゼンタオブジェクト３１２０により分析・提示される。
【０２６７】
データビューは、更なるＸＭＬデータに対するハイパーリンクを含んでも良い。ユーザがこのハイパーリンクをたどると、新規のＸＭＬ文書が発生し、上述のプロセスを使用して表示される。結果として、新規のデータビュー（及び関連付けられた問合せ）がワークスペース中の同じグリッド位置に表示される。この新規のデータビューと関連付けられた問合せが、前のデータビュー及びハイパーリンクから得られる。ユーザがこの時点でデータビューを保存することを選択する場合、現在表示されているデータに対応するデータビューが保存される。このため、ユーザがデータブラウジングアプリケーション１２０を使用してデータソースのブラウズ中である場合、操作して再利用可能な明示データビューとして保存することができる一連の暗示データビューがユーザに対して提示される。明示データビューは、格納されたデータビュー定義と関連付けられたデータビューである（セクション１１．０参照）。
【０２６８】
セクション５．０において説明した分析プロセスは、データビューのデータ構成要素をデータビューのＸＳＤＯＭデータ３１３０に関してデータが取得される方法を指定するパス表現及び反復子と関連付ける。このため、セクション２．０において説明したように、データセット（例えば、表の列に表示されるもの）が反復子及びこれに関連する任意のパスにより指定される。例えば、図１２Ａにおいて、データブラウジングアプリケーション１２０は、表の列ＰａｔｅｎｔＥｓｔｉｍａｔｅをＰｒｏｊｅｃｔの反復子及びＰａｔｅｎｔＥｓｔｉｍａｔｅのパス表現と関連付ける。このデータセットが図１２Ｅの新規のデータビューへとコピーされる場合、反復子Ｐｒｏｊｅｃｔ及びパスＰｒｏｊｅｃｔＣｏｄｅを有するＰｒｏｊｅｃｔ Ｐａｔｅｎｔ ２００２データビューから得られた独立したデータセット（例えば、ｘ軸）と関連付けられたデータシリーズとして動作する。
【０２６９】
反復子はいずれの場合でも同じであるが、この反復子は表示中のＸＭＬデータを指し示す（例えば、ＸＱｕｅｒｙ ｆｌｗｏｒ表現のｒｅｔｕｒｎ句のデータに対する反復子）。コピー操作が許容可能か否かを確認するためには、データブラウジングアプリケーション１２０は、ソースに対するこれらのデータ反復子を分解しなければならない。換言すれば、反復子は、ソースに対するパスを完全に指定するソースデータパスへと変換される必要がある。例えば、ＰｒｏｊｅｃｔｓデータビューのＰａｔｅｎｔＥｓｔｉｍａｔｅデータセットと関連付けられた反復子に対するソースデータパスは以下の通りである：
document("http://www.example.com/Projects?/ProjectsDB")/Year,
[.=2002]/Project
ソースデータパスについては、本セクションにおいて更に詳細に後述する。
【０２７０】
ユーザが実行する各データ操作は、図５４のステップ５４２５により示されるように、最初に互換性のチェックを受ける。操作に互換性のある場合、データブラウジングアプリケーション１２０のデータビューマネージャオブジェクト３１２５（図３１Ａ）が操作を実施する。例えば、データセットがデータビューの表のある特定の列へとコピーされる場合、受信中のデータビューのデータビューマネージャオブジェクト３１２５には、データセットが特定の列番号として現在のデータビューへと追加されることが通知される。コピーされたデータセットは、ソースデータビュー、その反復子、及びパス（反復子に関連）により識別される。データビューマネージャオブジェクト３１２５は、可能であれば、現在のデータビューと関連付けられた問合せを更新して操作を詳細に説明する。
【０２７１】
データブラウジングアプリケーション１２０の好適な構成において実現されるデータ操作は以下の通りである：
１．データ構成要素のデータビューへのコピー、
２．フィルタのデータビューへの適用、
３．データビューに対するソート順の指定、
４．データ構成要素の変換、
５．２つ以上のデータ構成要素の結合、
６．データ構成要素の非表示、
７．データ構成要素の名前変更
これらの操作の各々に関して、操作中のデータビューと関連付けられたデータビューマネージャオブジェクト３１２５は、データビューに対する問合せを更新する。これらの操作は、通常、データセット及びデータシリーズを伴うが、一部の操作はデータノードにも適用可能である（例えば、単一のノードのツリーデータビューへのコピー、データ構成要素の名前変更又は非表示）。ユーザがデータシリーズのコピー、フィルタリング、ソート、変換、又は結合を選択する場合、データシリーズはデータセットと同様に扱われる。
【０２７２】
操作がデータセットを伴う場合、そのデータセットと関連付けられた反復子を使用して受信中のデータビューの問合せが更新される。反復子は、データビューマネージャオブジェクト３１２５に対してデータ値の集合と関連付けられた繰返し構造について通知する。データセットと関連付けられたパスは、データビューマネージャオブジェクト３１２５に対して、ＸＭＬ要素又はＸＭＬ属性（値を提供）の反復子要素に対する相対位置について通知する。パスは、通常、データセットのグループが同じ反復子を用いる場合に使用される（例えば、同じ親反復子要素を共有する表の列）。パスは指定する必要がない。パスが指定されない場合、反復子がデータセットの値に対するパス全体を指定するものと想定される。次に、異なる操作プロセスについてより詳細に説明する。
【０２７３】
７．１  データ構成要素のデータビューへのコピー
ユーザがワークスペース中のデータビューからデータ構成要素をカット／コピー又はドラッグし、そのデータ構成要素を別のデータビューへとペースト／ドロップすることを選択する場合、データブラウジングアプリケーション１２０のデータビュープレゼンタオブジェクト３１２０は、目標データビューに対するデータビューマネージャオブジェクト３１２５上で以下の方法のうちの１つを呼び出す：
１．addDataSet(DataSet source, DataSet target)
２．addDataSet(DataSet source, DataSeries target)
３．addDataSeries(DataSeries source, DataSet target)
４．addDataSeries(DataSeries source, DataSeries target)
５．addDataNode(DataNode source, DataNode target)
これらの方法の各々において、ｓｏｕｒｃｅ引数はコピーされたデータを指し示す。この引数は、ソースデータビューオブジェクトとそのデータビューにおけるデータノード、データセット、又はデータシリーズとを指定する。ｔａｒｇｅｔ引数は、コピーされたデータが追加される目標データビュー中のデータセット、データシリーズ、又はデータノードを示す。
【０２７４】
上述の５つの方法のうちのどれが呼び出されるかは、目標データビューの表示種別、コピーされたデータの型（データノード、データセット、又はデータシリーズ）、及びコピーされたデータの役割によって決まる。コピーされたデータの役割は、目標データビューにおけるドロップ位置又はペースト位置により判定される。ユーザがデータセットをコピーする場合（例えば、表又はグラフのｘ軸から）、データビュープレゼンタオブジェクト３１２０はドロップ位置に応じて第１の方法又は第２の方法を呼び出すことができる。データシリーズがコピーされる場合、データビュープレゼンタオブジェクト３１２０はドロップ位置又はペースト位置に応じて第３の方法又は第４の方法を呼び出すことができる。データシリーズがデータセット（例えば、表の列、グラフのｘ軸）としてデータビューに追加される場合、データシリーズはデータセットとほぼ同様に扱われる。
【０２７５】
データノードがコピーされる場合、第５の方法のみが呼び出される。データノードが呼び出され、目標データビュー中のドロップ位置又はペースト位置が、データセットが予期されていることを暗示する場合、データビューマネージャオブジェクト３１２５は、操作が許容されていないことを報告する。好適な構成では、第５の方法はツリーのノードを操作する際にのみ使用される。目標データビューにおいて指定される既存のデータが存在しない場合、ｔａｒｇｅｔ引数はヌルに設定することができる。ヌルのｔａｒｇｅｔ引数は、目標データビューがデータを含まない（すなわち、セクション６．０において説明したように新規のデータビューメニューオプションを使用して作成されている）場合にのみ有効であるのが好ましい。
【０２７６】
データビューにデータセットを追加するプロセスについて図５５から図６１と図１２Ａから図１２Ｆを参照して説明した例とを参照して更に詳細に説明する。特に、ＰｒｏｊｅｃｔデータビューのＰａｔｅｎｔＥｓｔｉｍａｔｅ列をコピーして図１２Ｄ、図１２Ｅ、及び図１２Ｆに示す新規のデータビューにおけるデータシリーズとして動作させるプロセスについて説明する。ソースデータビューに対するＸＱｕｅｒｙ定義は、ＸＱｕｅｒｙ例１に示すようなＰｒｏｊｅｃｔデータビューのＸＱｕｅｒｙ定義である。このＸＱｕｅｒｙは図５８において問合せツリーとして示される。操作の目標データビューである新規の棒グラフに対するＸＱｕｅｒｙ表現は、ＸＱｕｅｒｙ例４に示す通りであり、図５９において問合せツリーとして示される。
【０２７７】
ＸＱｕｅｒｙ例４
【０２７８】
2004240954.tif 000016
【０２７９】
尚、ＰｒｏｊｅｃｔＣｏｄｅデータセットがＰｒｏｊｅｃｔ Ｐａｔｅｎｔ ２００２から新規の棒グラフへとコピーされる場合、棒グラフに対する問合せは、所望の年に対するｉｎｖｅｎｔｉｏｎ要素と関連付けられた全ての別個のプロジェクトコードを取得するのに使用されるdistinct-values関数を維持管理する。
図５５は、データブラウジングアプリケーション１２０の一部として実現されるのが好ましい既存のデータビューへとデータセットを追加する方法５５００のフローチャートを示す。ステップ５５０５において、ソースデータセット／シリーズは、ユーザが図１２Ａから図１２Ｆに示されるようなＧＵＩと対話することによって識別される。ソースデータセット／シリーズは、コピー又はカット操作、あるいは、ドラッグ操作の開始により識別することができる。このため、例では、図１２Ｄに示すＰｒｏｊｅｃｔデータビューにおけるＰａｔｅｎｔＥｓｔｉｍａｔｅ列をドラッグすることをユーザは選択・開始しても良い。ドラッグされたデータ構成要素はデータセットであるので、ドラッグ操作の目標データビューと関連付けられたデータビュープレゼンタオブジェクト３１２０は、列挙した最初の２つの方法のうちの１つを最終的に呼び出すことになる。
【０２８０】
ステップ５５１０において、ペースト／ドロップ位置を使用して目標データビューのどのデータセット／シリーズが目標データセット／シリーズとして扱われるかが判定される。例えば、ユーザがグラフのｙ軸上にデータセットをドロップする場合、目標データビューと関連付けられたデータビュープレゼンタオブジェクト３１２０は、データシリーズがグラフに対して既に存在するか否かを最初に確認するであろう。存在する場合、データビュープレゼンタオブジェクト３１２０は、最後のデータシリーズを目標データシリーズとして識別し、対応するデータビューマネージャオブジェクト３１２５のaddDataSet(DataSet source, DataSeries target)方法を呼び出す。グラフに対してデータシリーズが存在しない場合、ｘ軸に対応するデータセットが目標データセットとして選択され、addDataSet(DataSet source, DataSet target)方法が呼び出されるであろう。
【０２８１】
あるいは、ドロップ／ペースト位置が２つの汎用項目間にある場合、目標データシリーズはドロップ／ペースト位置の直前の汎用項目に対応するデータシリーズへと設定されるであろう。操作に対するソースがデータシリーズである場合、ペースト／ドロップ目標に応じて第３又は第４の方法が呼び出されることは明らかである。addDataSeries()方法がデータビューマネージャオブジェクト３１２５上で呼び出される場合、オブジェクトはデータシリーズのラベルに関する情報を使用して操作が許容可能であるか否かの決定を支援し、許容可能な場合、目標データビューに対する問合せを更新できるのが好ましい。例えば、データシリーズのラベルは操作に対する結合条件に関する情報を提供することができる。結合条件についてはセクション６．０において検討したが、本セクションでも更に詳細に後述する。
【０２８２】
このため、図１２Ｄに示される例では、ユーザはドラッグされたＰａｔｅｎｔＥｓｔｉｍａｔｅデータセットを図１２Ｄのｙ軸データ構成要素１２５３上にドロップする。この例では、新規の棒グラフに対して既存のデータシリーズは存在しないので、目標データセットはｘ軸データセットであり、棒グラフデータビューと関連付けられたデータビューマネージャオブジェクト３１２５上でaddDataSet(DataSet source, DataSet target)方法が呼び出される。データビューマネージャオブジェクト３１２５がこの呼出しを処理する。
【０２８３】
ステップ５５１５において、データビューマネージャオブジェクト３１２５は、ソース問合せツリー及び目標問合せツリーに対するハンドルを取得する。データビューマネージャオブジェクト３１２５は独自の問合せツリー、すなわち、目標問合せツリーに対する格納されたハンドルを有する。また、データビューマネージャオブジェクト３１２５は、渡されたソースデータセットオブジェクトを介してソース問合せツリーに対するハンドルを取得する。ステップ５５２０において、双方の問合せがｆｌｗｏｒ表現の形式であることを確認するためのチェックが行なわれる。好適な構成により生成された問合せは既にこの形式であるが、データソース問合せはdocument関数に包まれると共に繰返し操作が適用される必要がある。
【０２８４】
例えば、データソース問合せ：
http://www.example.com/Projects?/ProjectsDB/Year/[.=2002]/Project
は、ＸＱｕｅｒｙ例５に示すｆｌｗｏｒ表現により表現することができる。好適な構成では、以下に示すようにトップレベルのｌｅｔＡｓｓｉｇｎｍｅｎｔノードにおいてデータソースのルートを分離しようと試みる（ＸＱｕｅｒｙ例５の場合、＄ｐｒｏｊｅｃｔｓ変数に対して）。パスのそれ以外の部分は、ｆｏｒＡｓｓｉｇｎｍｅｎｔノードのソースデータパスとして使用される。
【０２８５】
ＸＱｕｅｒｙ例５
【０２８６】
2004240954.tif 000017
【０２８７】
ステップ５５２５において、データセット反復子の各々と関連付けられたループ変数が判定される。ループ変数は、繰返し操作のデータをバインドするように宣言された変数である。このため、ループ変数は、他のＸＱｕｅｒｙ操作が繰返しプロセスの結果を参照するための手段を提供する。ループ変数は、ｆｏｒＡｓｓｉｇｎｍｅｎｔノード（例えば、ＸＱｕｅｒｙ例５における＄ｐ）又はｌｅｔＡｓｓｉｇｎｍｅｎｔノード（例えば、ＸＱｕｅｒｙ例３における＄ｉｎｖ）により定義される。ｆｏｒＡｓｓｉｇｎｍｅｎｔを介して定義された変数は繰返しプロセスの結果を明示的に保持し、ｌｅｔＡｓｓｉｇｎｍｅｎｔにより定義された変数は繰返しプロセスの結果を暗示的に保持するものとして見ることができる。例えば、ｆｏｒＡｓｓｉｇｎｍｅｎｔノードを使用して１セットのキーを繰り返し、１つ以上のｌｅｔＡｓｓｉｇｎｍｅｎｔノードを使用して個々のキー値に対するデータを取得することは便利であろう。このプロセスはＸＱｕｅｒｙ例３に示される。ｆｏｒＡｓｓｉｇｎｍｅｎｔノードにおいて定義されるキーは、１次ループ変数（ＸＱｕｅｒｙ例３における＄ｐ）として扱うことができ、ｌｅｔＡｓｓｉｇｎｍｅｎｔ変数（ＸＱｕｅｒｙ例３における＄ｉｎｖ）は２次又は従属ループ変数として扱うことができる。データ間に１対ｎの関係がある場合、ネスト状のｆｏｒＡｓｓｉｇｎｍｅｎｔノードが使用される。
ステップ５５２５におけるループ変数の判定は、データビュー（反復子の生成元）の結果のデータをデータソースにより表現される問合せ中の関連付けられた繰返し操作と連結するのに必要とされる。これは、結果の問合せが既存のデータビューではなくデータソースにより表現される場合に必要である。この関連付けの結果、データビューソースから独立し、元のデータソースにのみ従属する目標問合せが得られる。
【０２８８】
データセットに対する反復子に対応するループ変数を判定するプロセス、すなわち、ステップ５５２５について図５７を参照して更に詳細に説明する。一般的に、（ｉ）データセットの反復子がｒｅｔｕｒｎサブツリーにおいて明示的に定義される場合、（ｉｉ）データセットの反復子がｒｅｔｕｒｎサブツリーにおいて変数を介して定義される場合、及び（ｉｉｉ）データセットの反復子の最初の部分がｒｅｔｕｒｎサブツリーにおいて明示的に定義される場合の３つの場合を考慮すべきである。第１の場合及び第３の場合は、反復子のパスの全部又は一部がＸＱｕｅｒｙのｒｅｔｕｒｎサブツリーにおいてタグとして明示的に定義される（すなわち、各要素がＸＱｕｅｒｙの要素コンストラクタ表現を使用してＸＱｕｅｒｙ表現のｒｅｔｕｒｎサブツリーにおいて明示的に構築される）ときに起こる可能性がある。第１の場合は、図５９に示す目標問合せに関して当てはまる。図５９において、提供された反復子Ｐｒｏｊｅｃｔは、ｅｌｅｍｅｎｔＣｏｎｓｔｒｕｃｔｏｒノード５９１０の子孫ノード５９１５として明示的に配置される。第２の場合は、反復子が変数ノードにより暗示されるときに起こる可能性がある。例えば、ソース問合せの場合、ｒｅｔｕｒｎサブツリー５８０５は＄ｐ５８１０の値を有する変数ノード５８０６を有する。
【０２８９】
図５７から明らかなように、決定５７０５において、反復子の全ての要素がｒｅｔｕｒｎサブツリーにおいて明示的に定義されない場合、制御はステップ５７２０へと進む。ステップ５７２０において、明示的に定義された反復子の初期の要素が反復子のパスから削除される。これは、要素コンストラクタが問合せの結果を包むのに使用されている場合であるだろう。ステップ５７３０において、全ての可能なループ変数（及び関連付けられた繰返し操作）のリストがＸＱｕｅｒｙ表現に対して編集される。このことは、問合せに対して全ての繰返し操作（ｌｅｔＡｓｓｉｇｎｍｅｎｔノード及びｆｏｒＡｓｓｉｇｎｍｅｎｔノードにより定義されるような）を配置し、各々に対してリスト項目を作成することを伴う。従って、この例におけるソースデータセットに関しては、単一のループ変数＄ｐのみが存在する。
【０２９０】
ステップ５７３５において、このリストの第１の項目が選択・処理される。ステップ５７３０において、単一のループ変数が識別される場合、制御はステップ５７２５へと進むのが好ましい。これは図５７の破線により示される。識別されない場合、ステップ５７４０において、繰返し操作のサブツリーを解析することによって繰返し操作に対するソースデータパスが生成される。前述のように、ソースデータパスは含まれる任意の変数名をその値と置き換える。ソース問合せ（すなわち、図５８）中のソースデータセットの場合、ループ変数＄ｐに対するソースデータパスは以下の通りである：
document("http://www.example.com/Projects?/ProjectsDB")/
Year[.=2002]/Project
目標問合せ（すなわち、図５９）中のループ変数＄ｐに対するソースデータパスは以下の通りである：
distinct?values(document("http://www.example.com/Patents?/
Patents")/Invention[Year=2002]/ProjectCode)
決定ステップ５７４５において、ソースデータパスの終端部分が指定された反復子を含む場合、ステップ５７２５において、項目と関連付けられたループ変数が反復子に対するループ変数として設定され、プロセスは５７９０で終了する。好適な構成では、部分文字列検索が実行される前に、ソースデータパスはまず骨組みのソースデータパスへと変換される。骨組みのソースデータパスとは、document関数を除く全ての述語表現及び関数が削除されるソースデータパスである。例えば、ソースデータセットのループ変数＄ｐに対する上述のソースデータパスは以下の骨組みソースデータパスに対応する：
document("http://www.example.com/Projects?/ProjectsDB")/Year/Project
骨組みソースデータパスの使用により、部分文字列検索が迅速且つ頑強になる。しかし、ステップ５７４５は、図５７に示すようなソースデータパスを使用して実行することもできる。
【０２９１】
指定された反復子が現在のループ変数に対するソースデータパスにおいて識別できない場合、制御はステップ５７４７へと進む。反復子の最初の部分がソースデータパスに存在するか否かを確認するためにチェックが実行される。存在する場合、データブラウジングアプリケーション１２０は、反復子パスを終了するために、この反復子に対して検出された最後の要素に対する子孫要素を識別しようと試みる。これは、反復子の最後の要素に対するスキーマ定義を検査することによって達成されるのが好ましい。この定義は、対象の要素に対する任意の子孫要素を指定すべきである。スキーマ定義が利用可能でないか、あるいは、子コンテキストを明示的に指定しないためにこれが可能でない場合、好適な構成は、問合せと関連付けられたデータを検査し、反復子の最後に列挙された要素の子孫要素を識別する。反復子パスがこのようにして終了可能である場合、制御はステップ５７２５へと進み、現在のループ変数は反復子へと割り当てられる。
【０２９２】
反復子パスが終了可能でない場合、制御は決定ステップ５７５０へと進む。リスト中に更に項目がある場合、ステップ５７５５において次の項目が選択され、制御はステップ５７４０へと戻る。ステップ５７５０において、更なる項目が識別されない場合、不認可の操作が試みられたものと思われる。これは、ステップ５７６０において報告され、プロセスはステップ５７９０で終了し、図５５のステップ５５２８へと戻ることができる。
【０２９３】
ステップ５７０５において、反復子の全ての要素がｒｅｔｕｒｎサブツリーにおいて明示的に定義される場合、制御はステップ５７１０へと進む。これは、目標データセットの場合である。ステップ５７１０において、問合せツリーは、反復子のパスが識別された（すなわち、同じｆｌｗｏｒ表現）ｒｅｔｕｒｎノードに対応する任意のｆｏｒＡｓｓｉｇｎｍｅｎｔノードまでたどられる。ｆｌｗｏｒ表現は、複数の繰返し操作を有することができ、各操作の結果はループ変数へと結び付けられる。加えて、ｆｏｒＡｓｓｉｇｎｍｅｎｔノードに従属するｌｅｔＡｓｓｉｇｎｍｅｎｔノードは、更なる２次ループ変数を定義することができる。ｒｅｔｕｒｎ句はネスト情報ｆｌｗｏｒ表現を含むことができるので、ＸＱｕｅｒｙ表現のある特定のｒｅｔｕｒｎ句（及びｆｌｗｏｒ表現）に対応する繰返し操作を識別することができ、検索空間が削減される。
【０２９４】
ステップ５７１５において、ステップ５７１０で識別されたｆｏｒＡｓｓｉｇｎｍｅｎｔノードが検査される。ステップ５７１５において、単一の繰返し操作（及びこれをバインドするループ変数）が宣言される場合、制御はステップ５７２５へと進む。ステップ５７２５において、このループ変数は反復子へと割り当てられ、プロセスはステップ５７９０で終了する。これは目標データセット反復子の場合である。２つ以上のループ変数が宣言される（すなわち、ｒｅｔｕｒｎ表現が２つ以上の繰返し操作と関連付けられる）場合、制御はステップ５７１７へと進む。このステップにおいて、反復子の終端要素に対応する要素コンストラクタと関連付けられたサブツリーが検査される。このコンストラクタがデータセットと関連付けられたパスを明示的に含む場合、対応する要素コンストラクタの内容の検査により正しいループ変数を判定することができる。例えば、ＸＱｕｅｒｙ例３において反復子Ｐｒｏｊｅｃｔ及びパスＰｒｏｊｅｃｔＣｏｄｅにより識別されるデータセットに対するループ変数を見つける場合について考察する。反復子Ｐｒｏｊｅｃｔはｒｅｔｕｒｎサブツリーにおいて明示的に定義される。データセットのパスは、Ｐｒｏｊｅｃｔ要素コンストラクタに含まれるＰｒｏｊｅｃｔＣｏｄｅ要素コンストラクタに対応する。このデータセットに対するループ変数は、ＰｒｏｊｅｃｔＣｏｄｅ要素の定義された内容を検査することにより判定することができる。この場合、ループ変数は変数＄ｐを使用するので、＄ｐはデータセットに対するループ変数として割り当てることができる。
【０２９５】
また、データセットは、反復子の要素コンストラクタ内の変数（例えば、＄ｐ／Ｃｏｄｅ）に関連するパスにより明示的に識別することが可能であっても良い。最終的な可能性は、反復子のコンストラクタ中の変数がパスを暗示的に含む（すなわち、ループ変数がデータセット値を表す）ことである。後者の場合が起こり、２つ以上のループ変数が可能である場合、好適な構成では、可能なループ変数をソースデータパスへと分解し、ステップ５７４７に対して説明した方法を使用してデータセットのパスを配置することにより正しい変数を配置しようと試みる。
【０２９６】
図５５に戻ると、ステップ５５２５において、ループ変数がソース反復子及び目標反復子の各々に対してループ変数を識別することができる場合、制御は決定ステップ５５２８からステップ５５３０へと進む。ステップ５５３０において、ソースデータパスがループ変数に対して構築される。ステップ５５２５のプロセス中に構築されたソースデータパスは、このステップでの使用のために保持されているのが好ましい。ステップ５５２５の結果がエラーの場合、制御はステップ５５５０へと進む。ステップ５５５０において、不認可の操作が報告される。
【０２９７】
ステップ５５３０の終了後、ステップ５５３５は、可能であれば、目標問合せツリーを更新するように動作する。ステップ５５４０は更新が可能であるか否かをチェックする。可能でない場合、ステップ５５５０において、プロセスは不認可の操作を報告し、ステップ５５９０で終了する。更新が可能な場合、操作が許容されていると見なされるので、ステップ５５６０において、ソースデータビューからのデータが目標データビューへとコピーされる。このステップの結果、目標データビューと関連付けられたＸＳＤＯＭ構造３１３０が更新される。表示されたデータビューは更新されてコピーの結果を反映する。プロセスはステップ５５９０で終了する。
【０２９８】
目標問合せツリーを更新するプロセス（図５５のステップ５５３５）について図５６を参照して更に詳細に説明する。ステップ５６０２において、ソースループ変数及び目標ループ変数の各々に対して骨組みソースデータパスが構築される。前のステップの処理中に構築されている場合、これらのパスは再利用される。ステップ５６０５において、骨組みソースデータパスが比較される。骨組みソースデータパスが同一である場合、制御はステップ５６１５へと進む。ステップ５６１５において、ソースデータパスが比較される。ソースデータパスが同一である場合、これは、述語条件が２つの反復子に対して変動せず、目標データセットの反復子をそのまま使用できることを意味する。ソースデータパスが同一である場合、制御はステップ５６３０へと進む。ステップ５６３０において、ソースデータセットは目標問合せツリーのｒｅｔｕｒｎサブツリーに含まれる。
【０２９９】
ステップ５６３０は、ソース問合せツリーから目標問合せツリーへとソースデータセットに対する要素コンストラクタをコピーし、参照されたループ変数を目標データセットのループ変数へと更新することを意味することができる。しかし、ソースデータセットがソース問合せツリーにおいてループ変数を伴う表現を使用して参照される場合、この表現は目標問合せ中のｒｅｔｕｒｎサブツリーへとコピーされ、表現のループ変数は目標データセットと同じになるように変更される。いずれの場合にも、ソースデータセットは目標データセットの直後のｒｅｔｕｒｎサブツリーへと追加される。プロセスはステップ５６９０で終了する。
【０３００】
骨組みソースデータパスが同一であるがソースデータパスが同一でない場合、ソース反復子のソースデータパスと目標反復子のソースデータパスとには異なる述語表現が存在しなければならない。述語表現は、問合せに対して収集されたデータ上でフィルタリング条件を定義するので、使用中のデフォルトの結合方法によって決まる。決定ステップ５６１８において、外結合方法が検出される場合、制御はステップ５６１９へと進む。検出されない場合、制御はステップ５６２０へと進む。ステップ５６２０において、複数のソースデータパスが単一のソースデータパスへと併合される。この操作は相異ユニオン及び内結合方法に関してのみ可能である。ステップ５６２０の結果、目標問合せに対して少なくとも１つの新規の繰返し操作が得られる。可能であれば、共通のソースデータパスを有する単一の繰返し操作が起こる。
【０３０１】
相異ユニオン結合方法が使用される場合、２つのソースデータパスの述語条件が併合され、個々の述語条件の結果のユニオンが生成される。述語条件はユニオンを得るために以下の規則を使用して併合される：
１．ソースデータパス中のある特定の要素が２つの異なる述語を有する場合、これらの述語は「ＯＲ」関数で結合される
２．一方のソースデータパス中の要素に対しては述語が存在し、他方のソースデータパス中の同じ要素に対しては述語が存在しない場合、述語は破棄される
決定ステップ５６１８において、外結合方法が検出される場合、ステップ５６１９において、ソースデータセットに対して内部のｆｏｒＡｓｓｉｇｎｍｅｎｔノードが作成される。目標ビューの外部のインタラクションは変更されない。制御はステップ５６３０へと進み、ソースデータセットは、ステップ５６１９において内部のｆｏｒＡｓｓｉｇｎｍｅｎｔノードにより使用されたループ変数を用いてｒｅｔｕｒｎサブツリーへと追加される。
【０３０２】
最後に、内結合方法が使用されている場合、２つのソースデータパスの述語条件が併合され、個々の述語条件の共通部分が生成される。述語条件は共通部分を得るために以下の規則を使用して併合される：
１．ソースデータパス中のある特定の要素が２つの異なる述語を有する場合、これらの述語は「ＡＮＤ」関数で結合される
２．一方のソースデータパス中の要素に対しては述語が存在し、他方のソースデータパス中の同じ要素に対しては述語が存在しない場合、述語は保持される
相異ユニオン方法又は内結合方法が使用される場合、ステップ５６２０の併合プロセスの結果、新規のソースデータパスが得られる。この新規のソースデータパスは目標データビューにおける共通の繰返し操作に対して使用される。ステップ５６２５において、ｆｏｒＡｓｓｉｇｎｍｅｎｔノードが新規のソースデータパスを伴って更新される。これは、ｐｒｅｄｉｃａｔｅｄＥｘｐｒノードを更新、削除、又は追加することを伴う。例えば、図５８において、述語併合プロセスがＹｅａｒ要素上の述語の削除を要求する場合、ノード５８６０はノード５８６５の直系の子とされ、ｐｒｅｄｉｃａｔｅｄＥｘｐｒサブツリー５８７０のその他のノードは問合せツリーから削除されるであろう。
【０３０３】
ステップ５６０５において、骨組みソースデータパスが同一でない場合、ステップ５６１０において、操作の続行を可能にする結合条件を識別する必要がある。データブラウジングアプリケーション１２０は、異なるデータソース内／間で結合を表現する骨組みソースデータパスの対のリストを格納するのが好ましい。このため、セクション６．０において説明した例では、以下の結合条件がデータブラウジングアプリケーション１２０に登録される：
１．document("http://www.example.com/Projects?/ProjectsDB"/Year/
Project/Code=document("http://www.example.com/Projects?/
ProjectsDB")/Year/ProjectResources/ProjectCode
２．document("http://www.example.com/Projects?/ProjectsDB"/Year/
Project/Code=document("http://www.example.com/Patents?/
Patents")/Invention/ProjectCode
各結合条件は、各々が骨組みソースデータパスとして指定される２つの結合属性を表現する。好適な構成では、同等の操作を使用する結合条件のみが考慮される。これらの結合条件は、ユーザが図１２Ｂに示すような結合記号１２２２により２つのデータ構成要素を結合することによって、ワークスペースにおける結合を示す結果として記録されても良い。
【０３０４】
好適な構成では、適切な結合条件は、同胞として動作するか、あるいは、ソースデータセットと同じである一方の結合属性と同胞として動作するか、あるいは、目標データセットと同じである他方の結合属性とを有するものとして識別される。換言すれば、各結合属性とその関連するデータセット値は共通の親を共有しなければならない。２つ以上の可能な結合条件が識別される場合、好適な構成はソースデータセット値と目標データセット値との間の１対１の関係を維持管理する結合条件の方をより好む。しかし、１対ｎ、ｎ対１、及びｎ対ｎの関係も許容される。ソースデータセットの結合属性がソースデータセット値に対して１対ｎの関係を有し、目標データセットの結合属性が目標データセット値に対して１対ｎの関係を有する場合、目標データセット値とソースデータセット値との間に１対ｎの対応が起こる。各結合属性インスタンスに対して２つ以上のデータセット値が存在する可能性がある場合、ｎ項の関係が発生する。関係の基数は、存在する場合にはスキーマ定義、あるいは、データの検査により判定されるのが好ましい。
【０３０５】
説明した例では、上述の２つの結合条件のうちの第２の結合条件は、操作の有効な結合条件を表現する。この結合条件の第１の結合属性は、以下の骨組みソースデータパス、すなわち：
document("http://www.example.com/Projects?/ProjectsDB")/Year/
Project/PatentEstimate
により識別されたソースデータセットの値の同胞である。第２の結合属性は、目標データセットの骨組みソースデータパスに正確に合わせられる。
【０３０６】
ステップ５６１０において、骨組みソースデータパスの対に対して結合条件が識別されない場合、ステップ５６６０において、操作には不認可を示すフラグを立てられ、プロセスはステップ５６９０で終了する。ステップ５６４０において、対に対する結合条件が識別される場合、データセットごとにソース結合パスが作成される。ソース結合パスとは、データセットのソースデータパスの述語表現を有する結合属性のソースデータパスである。このため、ソースデータセット及び目標データセットに関して、説明した例に対するソース結合パスは、それぞれ：
document("http://www.example.com/Projects?/ProjectsDB")/
Year[.=2002]/Project/Code
及び
document("http://www.example.com/Patents?/Patents")/
Invention[Year=2002]/ProjectCode
である。
【０３０７】
ステップ５６４５において、目標問合せの繰返し操作が更新される。このステップは、どの結合方法（すなわち、相異ユニオン、外結合、及び内結合）が使用されているかによって決まる。
【０３０８】
相異ユニオン結合に関して、図６０の方法６０００を参照してステップ５６４５のプロセスについて説明する。ステップ６０１０において、外部のｆｏｒＡｓｓｉｇｎｍｅｎｔノードが目標問合せにおいて作成され、ソース結合パスの相異ユニオンにより生成された値が繰り返される。重複するdistinct-values関数又はdistinct-nodes関数は、distinct-values関数のソース結合パス引数から削除されるのが好ましい。決定ステップ６０２０において、ソースデータセットが目標データセットの値に対して１対ｎの関係を有することが判明した場合、制御はステップ６０５０へと進む。この情報は、利用可能な場合にはスキーマ定義、あるいは、データの検査より確認することができる。ソースデータセットの値と目標データセットの値との間に１対１の関係が存在する場合、制御はステップ６０３０へと進む。
【０３０９】
ステップ６０３０において、ｌｅｔＡｓｓｉｇｎｍｅｎｔノードがソースデータセットに対して作成される。この割り当ては、結合条件を指定する述語により限定される（ＸＱｕｅｒｙ例３参照）。また、データセットは要素コンストラクタとして追加されるのが好ましいが、代替の構成では、このステップで作成されたｌｅｔＡｓｓｉｇｎｍｅｎｔノードにより定義されたループ変数を伴う表現を使用してデータセットを指定しても良い。ソースデータセットに対してｌｅｔＡｓｓｉｇｎｍｅｎｔノードを作成するプロセスは、ソース問合せから高レベルのｌｅｔＡｓｓｉｇｎｍｅｎｔノードをコピーし、新規のデータソース（この場合、ＰｒｏｊｅｃｔｓＤＢデータソース）を定義するのが好ましい。これは必須ではないが、含まれる各データソースが変数により明確に識別される場合、生成されたＸＱｕｅｒｙの理解が容易になる。
【０３１０】
決定ステップ６０５０において、表示種別は１対ｎの関係（例えば、グラフ）をサポートしない。セクション６．０の例でＰｅｒｓｏｎＭｏｎｔｈｓデータセットに対して先に説明したように、関係はcount()関数又はsum()関数を使用して圧縮される必要がある。コピーされたデータが数値の場合、sum()関数が使用されるのが好ましい。
【０３１１】
制御はステップ６０３０へと進み、１対１の関係に関する処理が継続される。但し、データセットは、選択された圧縮関数を使用してｒｅｔｕｒｎサブツリーにおいて指定される。この一例は、ＸＱｕｅｒｙ例３により使用されたcount()関数において見られる。
【０３１２】
表示種別が１対ｎのデータ（表など）をサポートする場合、ステップ６０５５において、外部のｒｅｔｕｒｎサブツリー内に内部のｆｏｒＡｓｓｉｇｎｍｅｎｔノードが作成される。このｆｏｒＡｓｓｉｇｎｍｅｎｔは、ステップ６０３０において使用された結合条件により同じように限定される。内部繰返しごとに値が存在するか否か及び値が存在せずネスト状の繰返しのために空の要素コンストラクタを生成するか否かを検査するのに、検査用ｌｅｔＡｓｓｉｇｎｍｅｎｔを使用するのが好ましい。制御はステップ６０４０へと進む。
【０３１３】
ステップ６０４０において、プロセスは目標問合せに対するデータの他のソース（例えば、目標データセット）に対して繰返し／割当て操作が存在することを確認する。換言すれば、１対１の関係及び１対多数の関係を作成するのに、それぞれ、ｌｅｔＡｓｓｉｇｎｍｅｎｔノード及びｆｏｒＡｓｓｉｇｎｍｅｎｔノードが必要とされるであろう。これらのノードは、前の結合が実施されたときに既に存在しているかもしれない。最後に、プロセスはステップ６０９０で終了する。
【０３１４】
内結合方法又は外結合方法が図５６のステップ５６４５において使用される場合、目標問合せの繰返し操作を更新するプロセスが図６１に示される方法６１００に従って進行する。ステップ６１１０において、ソースデータセットが目標データセットの値に対して１対１の関係を有する場合、制御はステップ６１２０へと進む。ステップ６１２０において、ソースデータセットに対してｌｅｔＡｓｓｉｇｎｍｅｎｔノードが作成され、この割り当てが結合条件により限定される。データセットはｒｅｔｕｒｎサブツリーへも追加される。
【０３１５】
ソースデータセットが目標データセットの値に対して１対ｎの関係を有する場合、制御はステップ６１１５へと進む。表示種別が１対ｎの関係を圧縮することを要求する場合、制御はステップ６１２０へと進む。ステップ６１２０において、結果のｌｅｔＡｓｓｉｇｎｍｅｎｔにより内部繰返しごとに値のリストが得られるであろう。このリストは、図６０に対して説明したようにｒｅｔｕｒｎサブツリーにおいて圧縮関数による作用を受ける。表示種別が１対ｎの関係をサポートする場合、ソースデータセットに対して内部のｆｏｒＡｓｓｉｇｎｍｅｎｔノードが作成される。
【０３１６】
内結合の場合、ステップ６１２５において作成されたｆｏｒＡｓｓｉｇｎｍｅｎｔノードが外部のｒｅｔｕｒｎサブツリーの上方に追加されるが、外結合の場合、このノードは相異ユニオン方法に対して説明したようにｒｅｔｕｒｎサブツリーの内部に作成されなければならない。ｒｅｔｕｒｎサブツリーにおける内部繰返しの結果は、まず、結果のデータに関して検査され、データが存在しない場合、戻されるデータの中に空の要素が構築されるのが好ましい。内結合の場合及び外結合の場合の双方において、ソースデータセットはｒｅｔｕｒｎサブツリーへと追加される。換言すれば、外結合では、ネスト状のｒｅｔｕｒｎサブツリーが得られるが、内結合は単一のｒｅｔｕｒｎサブツリーのみを要求する。制御はステップ６１４０へと進む。
【０３１７】
決定ステップ６１４０において、内結合が必要とされる場合、ステップ６１４５において条件ノードが追加され、全ての反復子が関連付けられた値を有する場合にのみデータが戻されることが確認される。また、目標データセットとソースデータセットとの間に１対１の関係が存在する場合、ステップ６１２０において作成されたｌｅｔＡｓｓｉｇｎｍｅｎｔノードがｆｏｒＡｓｓｉｇｎｍｅｎｔノードへと変更される（すなわち、目標データセットとソースデータセットとの間の１対ｎの関係に対して異なる扱いをしない）場合に、この条件ノードを省略することができる。最後に、プロセスはステップ６１９０で終了する。
【０３１８】
説明した例に対するステップ５６４５の結果は以下のＸＱｕｅｒｙ例６に示される。ループ変数＄ｐは各ソース結合パスの繰返しの結果を含み、重複は削除されることになる。すなわち、以下の通りである：
document("http://www.example.com/Projects?/ProjectsDB")/
Year[.=2002]/Project/Code
及び
document("http://www.example.com/Patents?/Patents")/
Invention[Year=2002]/ProjectCode
図５６により示されるプロセスはステップ５６９０で終了し、制御は図５５のステップ５５４０へと戻る。目標データビューに対する更新された問合せはＸＱｕｅｒｙ例６に示される通りである。
【０３１９】
ＸＱｕｅｒｙ例６
【０３２０】
2004240954.tif 000018
【０３２１】
代替の構成は、変則的なデータに対する障害許容力を生成された問合せへと組み込むこともできるだろう。例えば、ＸＱｕｅｒｙ例６において、＄ｐｒｏｊ変数が２つ以上のＰｒｏｊｅｃｔノードを含む（すなわち、２つ以上の同じコードを有するプロジェクトが存在する）場合、上述の問合せは予測不可能であろう。実際の結果の挙動は、ある特定のＸＱｕｅｒｙプロセッサが実現される方法によって決まっても良い。ｒｅｔｕｒｎサブツリーにおいてソースデータセットに対する要素コンストラクタを作成する際に、チェックを追加することができる。例えば、複数のＰｒｏｊｅｃｔノードが同じコードを伴わない場合、ＰａｔｅｎｔＥｓｔｉｍａｔｅ要素が以下に示すように結果ごとに構築されるように、ＰａｔｅｎｔＥｓｔｉｍａｔｅ要素コンストラクタを挿入することができる。
【０３２２】
2004240954.tif 000019
【０３２３】
７．２  フィルタのデータビューへの適用
データブラウジングアプリケーション１２０の好適な構成では、ユーザはデータビューに対して１つ以上のフィルタを指定することができる。各フィルタ指定は、ブール式接続語ＡＮＤ、ＯＲ、又はＮＯＴのうちの１つ以上と結合された１つ以上のフィルタ制約を含むことができる。フィルタ制約は、データ構成要素（ＸＰａｔｈ表現により識別）、フィルタ操作、及び目標又は値（例えば、Salary ＞ 100,000、Salary ＞ AvgSalary）を定義する。フィルタは、データビューに貢献する複数のデータ構成要素を伴うことができるので、データビューのプロパティとして扱われる。
【０３２４】
また、好適な構成では、フィルタは問合せ（すなわち、データビューの一部である）により指定されるデータ構成要素のみを含むことができる。これは、繰返し操作及び割当て操作のソースデータパスにおける述語表現がフィルタとして扱われないことを意味する。代替の構成は、問合せにより明示的に取り出されないデータを伴うフィルタ制約を許容しても良い。フィルタは、非表示の（すなわち、問合せにより戻されるがデータビューの一部として表示されない）データ構成要素を伴うことができる。データ構成要素の非表示についてはセクション７．６において更に詳細に説明される。
【０３２５】
フィルタ指定はユーザにより有効又は無効に設定できるのが好ましい。これは、ユーザが１セットの代替のフィルタ指定を作成し、これらを現在のデータビューに対して異なる形式で結合できることを意味する。また、フィルタ指定及びその現在の状態が、データビューの定義の一部として格納されなければならない（すなわち、フィルタ指定は、データビューに対するＸＱｕｅｒｙへと単純に統合されるのではない）ことも意味する。好適な構成では、フィルタはデータビュー定義（付録Ａ参照）においてリストとして格納される。代替の構成では、１セットのフィルタ指定を提供しなくても良い。この場合、データビューに対するアクティブフィルタをデータビューの定義におけるＸＱｕｅｒｙへと統合することができる。
【０３２６】
データビューに対して複数のフィルタ指定が存在する場合、好適な構成では、これらの指定は接続的に（すなわち、「ＡＮＤ」により）結合される。このため、データビューに対するアクティブフィルタ（すなわち、全ての結合された有効なフィルタ指定）ｆは、以下の形式の表現ツリーにより表すことができる：
f ::= fc('AND'|'OR'|'NOT'fc)*
但し、ｆｃは：
fc ::= XPath op String | Number | XPath
op ::= 'equals' | 'less?than' | 'greater?than' | 'not' | 'contains' |
'starts?with' | 'ends?with'
により定義されるフィルタ制約を表す
ＸＰａｔｈ引数は、データビューの根ノードに関連するデータ構成要素パスのパスである。制約の値は、Ｓｔｒｉｎｇ（すなわち、ＸＱｕｅｒｙデータ型のＣＨＡＲＳＴＲＩＮＧ）、Ｎｕｍｂｅｒ（すなわち、ＸＱｕｅｒｙデータ型のＮＵＭＢＥＲ）、又は別のデータ構成要素（すなわち、ＸＰａｔｈ表現）として表現される。他の構成では、他のフィルタ操作及び接続語が使用されても良い。例えば、個々のフィルタ指定の結合を接続語「ＡＮＤ」に限定する必要はない。
【０３２７】
フィルタリング操作は、通常、ＸＱｕｅｒｙ ｆｌｗｏｒ表現のｗｈｅｒｅ句へとマップする。ＸＱｕｅｒｙ表現は２つ以上のｆｌｗｏｒ表現（例えば、ネスト状の表現又は表現のシーケンス）を含むことができるので、アクティブフィルタは問合せツリーにおいて２つ以上のｗｈｅｒｅサブツリーの修正を伴っても良い。また、好適な構成では、ユーザはデータを伴ってコピーされるフィルタに対してシステムプリファレンスを指定することができる。このため、例えば、データセットが別のデータビューへとコピーされる場合、ソースデータビューのアクティブフィルタが目標データビューへと追加される。この結果、目標データビューに対する新規のアクティブフィルタが得られる。
【０３２８】
データビューに対してフィルタを設定するプロセスについて図６２に示す方法６２００を参照して説明する。方法６２００は、データブラウジングアプリケーション１２０の一部として動作可能である。このプロセスは、図１２Ａに示すようなＧＵＩにおいて、更なるフィルタ指定が適用される、あるいは、既存のフィルタ指定が修正又は削除されることをユーザが示すことによって開始される。既存のフィルタ指定の修正は、状態の変更（すなわち、有効から無効へ）を含むことができる。また、プロセスは、ユーザがコピーフィルタプリファレンスセットを伴う新規のデータビューへとデータ構成要素をコピーするたびに開始される。これらのユーザ媒介型動作により、修正中の現在のデータビューに対するフィルタ指定のリストが得られる。修正されたリストは、Ｆｉｌｔｅｒオブジェクトとして、フィルタが変更中のデータビューと関連付けられたデータビューマネージャオブジェクト３１２５（図３１Ａ）へと渡される。これには以下の方法を使用する：
void setFilter(Filter f)
引数ｆはフィルタ指定のリストを含む。各々の指定は、本セクションで先に定義したＥＢＮＦにより記述される形式の表現ツリーとして表現されると共に、状態（有効／無効）を定義する関連付けられたフラグを有する。図６２のステップ６２０５において、データビューマネージャオブジェクト３１２５は、ｆにおけるフィルタ指定のリストから使用可能なこれらの指定を抽出し、アクティブフィルタに対する単一の表現ツリーを生成する。
【０３２９】
ステップ６２１０において、データビューに対する現在の問合せが検査される。現在の問合せがｆｌｗｏｒ表現でない場合（ユーザがデータソースをブラウズ中に起こりうる）、ステップ６２２０において、ＸＱｕｅｒｙはｆｌｗｏｒ表現へと変換される。所要のフィルタは述語をＸＰａｔｈ表現へと追加することによって適用することができるが、好適な構成では、ＸＰａｔｈ表現は既存のＸＰａｔｈ表現（ＸＱｕｅｒｙ例５に示すような）により指定されたデータパスに対して作成中のｆｏｒＡｓｓｉｇｎｍｅｎｔノードを有するｆｌｗｏｒ表現へと変換される。
【０３３０】
問合せがｆｌｗｏｒ表現の形式になれば、処理をステップ６２１５へと継続することができる。このステップにおいて、全ての現在のｗｈｅｒｅサブツリーが問合せツリーから除かれる。これらのサブツリーは、前のフィルタ操作に含まれていても良い。このステップは、好適な構成では、前のフィルタリング操作の結果が削除されたことを確認するために実行される。
【０３３１】
ステップ６２２０において、アクティブフィルタに含まれるＸＰａｔｈ表現のリストが構築される。各フィルタ制約は、フィルタ条件が適用されるデータ構成要素を識別する少なくとも１つのＸＰａｔｈ表現を定義することになる。一部のフィルタ制約は、値がフィルタ制約の第１の構成要素と比較される第２の（目標）データ構成要素を伴っても良い。前述のように、これらのＸＰａｔｈ表現はデータビューの根ノードに関連している。ステップ６２２５において、対応するバインド操作（すなわち、ｌｅｔＡｓｓｉｇｎｍｅｎｔノード又はｆｏｒＡｓｓｉｇｎｍｅｎｔノードを使用して定義されるような）が、ステップ６２２５において構築されたリスト中のＸＰａｔｈ表現ごとに識別される。バインド操作（及び対応するバインド変数）の識別は、ほぼコピー方法に関してセクション７．１において説明したようにして達成される。
【０３３２】
ＸＱｕｅｒｙが単一のｆｌｗｏｒ表現を含む場合、全てのＸＰａｔｈはその表現のｆｏｒＡｓｓｉｇｎｍｅｎｔノード及びｌｅｔＡｓｓｉｇｎｍｅｎｔノードにおいて明示的なバインド操作に対応する。各フィルタ制約は、既存のバインド変数を使用してｆｌｗｏｒ表現のｗｈｅｒｅ句において表現できるべきである。このため、決定ステップ６２３０において、ＸＱｕｅｒｙが単一のｆｌｗｏｒ表現を含む場合、制御はステップ６２３５へと進む。ステップ６２３５において、ｗｈｅｒｅサブツリーが、ステップ６２０５において作成された表現ツリーから構築される。このプロセスは表現ツリーにおいて全てのＸＰａｔｈ表現を配置し、これをバインド変数に関連する表現と置き換えることを伴う。例えば、Ｐｒｏｊｅｃｔデータビューが、セクション６．０において説明したようにフィルタリングされる場合、単一のフィルタ制約はＸＰａｔｈ表現Ｐｒｏｊｅｃｔ／Ｍａｎａｇｅｒを伴う。この表現は、変数＄ｐ（ＸＱｕｅｒｙ例１参照）へと結び付けられるように変更されなければならない。ステップ６２３５が終了すると、制御はステップ６２６０へと進む。
【０３３３】
ＸＱｕｅｒｙが２つ以上のｆｌｗｏｒ表現を含む場合、制御は決定ステップ６２４０へと進む。複数のｆｌｗｏｒ表現はシーケンス（例えば、表現のリスト）又はネスト状に結合することができる。ネスト状の場合、個々のフィルタ制約は接続的又は離接的に結合することができるため、制約を分離可能（すなわち、独自のｆｌｗｏｒ表現への適用直後）と見なすのは適切ではない。表現のシーケンスの場合、個々のｆｌｗｏｒ表現は本質的に相互に独立しているので、分離可能と見なすことができる。ステップ６２４０において、ｆｌｗｏｒ表現のシーケンスが検出される場合、制御はステップ６２４５へと進む。このステップにおいて、個々のｆｌｗｏｒ表現が検査される。アクティブフィルタに含まれる１つ以上のデータ構成要素がその表現から生じるものである場合、表現に適用されるアクティブフィルタの一部に対してｗｈｅｒｅサブツリーが作成される。制御はステップ６２６０へと進む。
【０３３４】
ステップ６２５０において、データビューマネージャオブジェクト３１２５は、内部ｆｌｗｏｒ表現の各々を検査する。データビューマネージャオブジェクト３１２５は、まず、アクティブフィルタの任意のフィルタ制約が内部ｆｌｗｏｒ表現を伴うか否かを確認する。伴わない場合、制御はステップ６２５５へと進む。伴う場合、フィルタｆ全体に対してｗｈｅｒｅサブツリーを構築し、内部ｆｌｗｏｒノードへと追加しなければならない。このサブツリーでは、データ構成要素に対するＸＰａｔｈ表現は、バインド変数（例えば、内部ｆｌｗｏｒ表現及び場合によっては外部ｆｌｗｏｒ表現のループ変数）を伴う表現により置き換えられる必要がある。制御はステップ６２５５へと進む。複数の内部ｆｌｗｏｒノードが存在する場合、各内部ｆｌｗｏｒノードに対してステップ６２５０が実行される。
【０３３５】
ステップ６２５５では、フィルタを外部ｆｌｗｏｒ表現へと適用しなければならない。フィルタ制約がこの繰返し操作を伴わない場合、フィルタをこのレベルで適用する必要がないのが好ましい。制御はステップ６２６０へと進むことができる。フィルタ制約が外部繰返し操作を介して得られたデータ構成要素を伴う場合、ｗｈｅｒｅサブツリーもこのｆｌｗｏｒノードへと追加しなければならない。しかし、このｗｈｅｒｅサブツリーはフィルタ全体を表現する必要があるので、場合によっては、内部繰返し操作により得られるデータ構成要素を参照する必要がある。従って、外部繰返し操作のｗｈｅｒｅサブツリー内に検査用繰返しを追加する必要がある。この検査用繰返しは、基本的に、フィルタのために内部繰返しを実行する。検査用繰返しは、内部繰返しをコピーし、繰返しのループ変数を変更して問合せにより予め使用されていない変数を使用し、ＸＰａｔｈ２．０のexists()関数を適用することによって作成することができる。この検査用繰返しを使用してｗｈｅｒｅサブツリーを構築し、外部ｆｌｗｏｒノードへと追加することができる。
【０３３６】
一般的に、繰返し操作のネストを解除（すなわち、内部のｆｏｒＡｓｓｉｇｎｍｅｎｔサブツリーを外部ｆｌｗｏｒノードのｒｅｔｕｒｎサブツリーの外部へと移動）することは不可能である。なぜなら、この解除が結果として生じるデータのグループ化に影響を及ぼすからである。ＸＱｕｅｒｙが、複数のレベルのネスティングを含む場合、親子の対ごとにステップ６２５０及び６２５５が実行されなければならない。最後に、ステップ６２６０において、Ｆｉｌｔｅｒオブジェクトに含まれるフィルタ指定リストがデータビューに対して格納され、データビューの定義の一部となる。プロセスはステップ６２９０で終了する。
【０３３７】
図６２のプロセスについて一例を参照して検討する。セクション６．０において説明したＰｒｏｊｅｃｔｓＤＢデータソースを使用する以下の問合せについて考察する。
【０３３８】
ＸＱｕｅｒｙ例７
【０３３９】
2004240954.tif 000020
【０３４０】
この問合せを使用して得られたデータは、セクション５．０において説明した方法を使用して、４列のデータ（ＰｒｏｊｅｃｔＣｏｄｅ、ＰｒｏｊｅｃｔＮａｍｅ、ＥｍｐｌｏｙｅｅＩＤ、及びＰｅｒｓｏｎＭｏｎｔｈｓ）を有する表として提示することができるだろう。この表では、最初の２つのデータセットと最後の２つのデータセットとの間に１対ｎの関係がある。ユーザはその形式（Project/ProjectNameが「Ｄ」で開始される、あるいは、Project/PersonMonths ＞ 6）のアクティブフィルタを指定しても良い。この場合、ステップ６２２０において、ＸＰａｔｈ表現Ｐｒｏｊｅｃｔ／ＰｒｏｊｅｃｔＮａｍｅ及びＰｒｏｊｅｃｔ／ＰｅｒｓｏｎＭｏｎｔｈｓは、変数＄ｐ及び＄ｒをそれぞれ使用してバインド操作と関連付けられる。ステップ６２３０において、２つのｆｌｗｏｒ表現が含まれるので、制御はステップ６２４０へと進む。問合せはｆｌｗｏｒ表現のシーケンスを含まないので、制御は更にステップ６２５０へと進む。
ステップ６２５０において、フィルタ制約全体（すなわち、アクティブフィルタはデータ構成要素Ｐｒｏｊｅｃｔ／ＰｅｒｓｏｎＭｏｎｔｈｓを伴う）を実施するために、内部ｆｌｗｏｒ表現に対してｗｈｅｒｅサブツリーを構築する必要がある。フィルタ中のＸＰａｔｈ表現は関連するバインド変数と置き換えられる。この場合、ＸＰａｔｈ表現Ｐｒｏｊｅｃｔ／ＰｒｏｊｅｃｔＮａｍｅ及びＰｒｏｊｅｃｔ／ＰｅｒｓｏｎＭｏｎｔｈｓは、表現＄ｐ／ＰｒｏｊｅｃｔＮａｍｅ及び＄ｒ／ＰｅｒｓｏｎＭｏｎｔｈｓに対応する。構築されたｗｈｅｒｅサブツリーは、内部ｆｌｗｏｒノードへと追加され、制御はステップ６２５５へと進む。
【０３４１】
また、フィルタは外部繰返し操作を介して得られるデータ構成要素を伴うので、ｗｈｅｒｅサブツリーはこのｆｌｗｏｒノードへと追加されなければならない。しかし、このサブツリーは、内部繰返し操作を介して得られるデータ構成要素Ｐｒｏｊｅｃｔ／ＰｅｒｓｏｎＭｏｎｔｈｓを参照しなければならない。従って、検査用繰返しが外部繰返しのｗｈｅｒｅサブツリーに対して構築される必要がある。これは、構築されたｗｈｅｒｅサブツリーを備える内部繰返しをコピーし、問合せで使用されていない新規の変数でループ変数を置き換え、ＸＰａｔｈのexists()関数を繰返しの結果に適用することによって構築される。構築されたｗｈｅｒｅサブツリーは外部ｆｌｗｏｒノードへと追加される。結果として生じたフィルタリング済のＸＱｕｅｒｙは、以下のＸＱｕｅｒｙ例８において示される。
【０３４２】
この例では、戻されたデータのグループ化を保護するために、ネスト状の繰返しが何度も行なわれる必要がある。例えば、ＸＱｕｅｒｙ例６により戻されたデータは、データのグループ化に影響する可能性があるので、内部繰返しをｒｅｔｕｒｎノードの上方に移動するのは不可能であろう。各Ｐｒｏｊｅｃｔ要素は複数のＥｍｐｌｏｙｅｅＩＤ子要素及びＰｅｒｓｏｎＭｏｎｔｈｓ子要素を有することができる。内部ｆｌｗｏｒノードが外部ｆｌｗｏｒノードのｒｅｔｕｒｎサブツリーの外部に移動される場合、各Ｐｒｏｊｅｃｔ要素は多くとも単一のＥｍｐｌｏｙｅｅＩＤ／ＰｅｒｓｏｎＭｏｎｔｈｓ子要素を有するであろう。換言すれば、実際に戻されるデータは同じであるが、データの１対ｎのグループ化は変更される。
【０３４３】
ＸＱｕｅｒｙ例８
【０３４４】
2004240954.tif 000021
【０３４５】
好適な構成では重複が生じる可能性がある（例えば、内部ｗｈｅｒｅサブツリーが内部繰返し操作に関するフィルタ制約のみを含むように修正される）が、方法はフィルタの異なる活用ごとに特定のプロセスを必要としないので、一般的な意味で容易に適用される。図６２を参照して説明した方法は、相異ユニオン、外結合、又は内結合を表現する問合せに使用することができる。
フィルタは、空のＦｉｌｔｅｒオブジェクトを有するsetFilter(Filter f)方法を呼び出すことによってデータビューから削除することができる。この場合、問合せにおけるｗｈｅｒｅサブツリーは、図６２のステップ６２１５に対して説明したように削除される。
【０３４６】
７．３  データビューに対するソート順の指定
好適な構成では、データビューに対するソートシーケンスをある特定のデータセットの昇順又は降順に設定することができる。データビューに対しては単一のソートシーケンスが許容されるのが好ましい。これは、図１２Ａに示すようなＧＵＩを使用して、ユーザがソートするデータセットを選択し、コンテキストメニュー１２９２上でソートオプションを選択し、昇順又は降順を指定することによって達成されても良い。代替の構成では、本開示の趣旨から逸脱することなく、２つ以上のデータ構成要素を伴うソートシーケンスを指定することができるだろう。
【０３４７】
ユーザが所望のソート順を指定する場合、関連するデータビューと関連付けられたデータビューマネージャオブジェクト３１２５（図３１Ａ）の以下の方法に対して呼出しが行なわれる：
setSortBy(DataSet dataSet, SortDirection direction)
但し、ｄａｔａＳｅｔ引数はセクション７．１において定義された通りであり、ｄｉｒｅｃｔｉｏｎ引数はａｓｃｅｎｄｉｎｇ（昇順）又はｄｅｓｃｅｎｄｉｎｇ（降順）に設定される
データビューマネージャオブジェクト３１２５は、まず、問合せがフィルタ操作に関してセクション７．２において説明したようなｆｌｗｏｒ表現の形式であることを確認する。データビューマネージャオブジェクト３１２５は、データビューと関連付けられた問合せツリーを更新し、指定されたデータセットが必要とする繰返し操作を定義するｆｌｗｏｒ表現にｏｒｄｅｒＢｙノード及び関連付けられたサブツリーを挿入する。問合せにおける既存のｏｒｄｅｒＢｙノードは削除される。代替の構成では、データビューに対して複数のｏｒｄｅｒＢｙノードが存在することができるだろう。
【０３４８】
図６３は、ノード６３０５により示された指定のソート順を有する問合せの一例を示す。ｏｒｄｅｒＢｙノードは、１つ以上のｏｒｄｅｒＦｉｅｌｄノード６３１０を含まなければならない。各ｏｒｄｅｒＦｉｅｌｄノードは、順序付けられるデータとその順序（昇順又は降順）を指定する。ｏｒｄｅｒＢｙノード及び関連付けられたサブツリーを作成するには、データビューマネージャオブジェクト３１２５は、データセットにより使用される繰返し操作を定義するｆｌｗｏｒ表現５８８２を識別可能でなければならない。
【０３４９】
選択されたデータセットと関連付けられた反復子は、セクション７．１において説明したように、対応するループ変数及び関連するｆｌｗｏｒ表現の識別に使用することができる。続いて、データセットのループ変数に対するパスを判定することができる。新規のｏｒｄｅｒＢｙノード及びその子孫ノードを関連するｆｌｗｏｒ表現へと追加することができる。
【０３５０】
例えば、図１２Ａにおいて、ユーザが表のＭａｎａｇｅｒ列を選択し、その列に対して降順でデータビューをソートすることを選択する場合、そのデータビューと関連付けられたデータビューマネージャオブジェクト３１２５上で上述の方法が呼び出される。ｄａｔａＳｅｔ引数は、反復子Ｐｒｏｊｅｃｔ及びパスＭａｎａｇｅｒを有するであろう。セクション７．１で説明した方法を使用してこのデータセットに対するループ変数が＄ｐであることを判定することができる。これは、ｏｒｄｅｒ ｂｙ表現に対する識別子がパスＭａｎａｇｅｒであることを暗示する。ｏｒｄｅｒＢｙノードの１つ以上の子ｏｒｄｅｒＦｉｅｌｄノードは、識別されたｆｌｗｏｒ表現のループ変数に関連する識別子を指定する。
【０３５１】
このため、例の場合、データビューマネージャオブジェクト３１２５は、図６３に示すようにｏｒｄｅｒＢｙノード６３０５を挿入することになる。この図は図５８のｆｌｗｏｒ表現５８８２を示す。ｏｒｄｅｒＢｙノード６３０５は図５８の識別されたｆｌｗｏｒ表現５８８２の下方に挿入される。続いて、ｏｒｄｅｒＦｉｅｌｄノード６３１０が、反復子に関連するソート対象のデータセット値を指定するｉｄｅｎｔｉｆｉｅｒ子ノード６３１５を伴って追加される。
【０３５２】
問合せツリーの更新後、データビューマネージャオブジェクト３１２５は、データを更新して新規のソートシーケンスを反映する。これは、問合せに対して取り出されたデータをソートすることによって達成されるのが好ましい。しかし、データビューマネージャオブジェクト３１２５は、問合せに対するデータを再度取り出し、データサーバの機能を使用してソート操作と関連付けられた処理を実行することもできる。
【０３５３】
７．４  変換操作の実行
変換はＸＱｕｅｒｙへと組み込まれる関数へとマップされる。好適な構成では、図１２Ａに示すようなＧＵＩにより、ユーザは選択されたデータセット又は選択されたデータセットの結合に適用する変換を指定することができる。結合操作についてはセクション７．５において更に詳細に説明される。変換操作及び結合操作はデータセットに対してのみ許容されるのが更に好ましいが、本開示の趣旨から逸脱することなく、この概念をデータノードに適用することもできるだろう。
【０３５４】
例えば、ユーザは図１２Ａに示すＰｒｏｊｅｃｔデータビューのＭａｎａｇｅｒ列を選択し、データに対して関数toUpperCase()を適用することを選択しても良い。この動作は、セクション３．０及び４．０において説明した例に基づく方法を使用して達成されるのが好ましい。また、ユーザは、提供された関数のリストからtoUpperCase()関数を選択することもできる。
【０３５５】
変換を実行するためのユーザの指示の結果、所望の変換を実行すると共に問合せ及び関連付けられたデータを更新するために、操作中のデータビューと関連付けられたデータビューマネージャオブジェクト３１２５（図３１Ａ）が呼び出されるのが好ましい。好適な構成では、以下の方法のうちの１つがデータビューマネージャオブジェクト３１２５上で呼び出される：
１．void transform(DataSet dataSet, Transform transform)
２．void transform(String newName, DataSet dataSet, Transform transform, boolean createMapping, boolean removeSource)
第１の方法は、ユーザが所定の位置にある一部の表示されたデータの変換を希望する場合に使用される。この場合、データセットの名前は変更されず、この変換に対するマッピングを生成することはできない。第２の方法は、ユーザが、データセットのコピーを変換されたデータを含むように生成し、新規の名前を変換されたデータへと割り当て、及び／又は変換に基づくマッピングを作成することを所望する場合に必要である。
【０３５６】
dataSet引数及びtransform引数は、作用を受けるデータセットと実行される変換種別とをそれぞれ指定する。変換（例えば、表１参照)に必要な引数は、transform引数オブジェクト内に含まれる。第２の方法が使用される場合、newName引数は変換されたデータに対して使用する名前を含むべきである（名前の変更をすべき場合）。ブールフラグcreateMappingは、変換に基づいてマッピングを作成する必要があるか否かをデータビューマネージャオブジェクト３１２５に対して通知する。第２の方法の最後の引数removeSourceフラグは、元のデータを保護する場合には偽に設定されるべきである。このフラグに対するデフォルトは、変換に対するソースデータを削除することである。
【０３５７】
transform()呼出しを処理する際、データビューマネージャオブジェクト３１２５はＸＱｕｅｒｙ関数の利用可能なライブラリを使用する。これらのライブラリ関数は可能な限り内部ＸＰａｔｈ関数を使用する（例えば、ＸＱｕｅｒｙ例９におけるupper?case($in)）。データビューマネージャオブジェクト３１２５は、ライブラリから必要な関数を識別し、関数の定義をそのデータビューの問合せツリーへと挿入する（以下の例ＸＱｕｅｒｙ９を参照）。尚、フィルタ操作及びソート操作と同様に、データビューマネージャオブジェクト３１２５は、まず、問合せがｆｌｗｏｒ表現の形式であることを確認しなければならない。データビューマネージャオブジェクト３１２５は、続いて、問合せツリーのｒｅｔｕｒｎサブツリーにおける正しいデータセットに対して関数を適用しなければならない。これは、関数がｒｅｔｕｒｎサブツリーにおいてｄａｔａＳｅｔ識別子を識別しなければならないことを意味する。この操作は、セクション７．１から７．３においてフィルタ操作及びソート操作に関して説明したのとほぼ同様に行なわれる。説明した例に対する結果のＸＱｕｅｒｙは以下のＸＱｕｅｒｙ例９に示される。
【０３５８】
ＸＱｕｅｒｙ例９
【０３５９】
2004240954.tif 000022
【０３６０】
第２の方法が指定されたnewName引数を伴って使用される場合、タグ名newNameを有する要素コンストラクタが問合せのｒｅｔｕｒｎサブツリーへと追加される。この新規の要素の内容は、関数を元のデータに適用した結果となる（ＸＱｕｅｒｙ例９において示す）。removeSourceフラグのブール値は、元のデータセットがｒｅｔｕｒｎサブツリーから削除されるべきか否かを指定するであろう。createMappingフラグが真の場合、セクション１１．０において説明されるように、マッピングがデータビューに対して格納される。このデータビューを受信する別のユーザは、今後の使用のためにマッピングをインポートすることを希望するか否かを選択できるだろう。換言すれば、マッピングは、他のユーザと共有できる再利用可能な変換を表現することができる。
ネスト状の変換は、上述の方法に対して何度も呼び出すことによって実行することができる。
【０３６１】
７．５  結合操作の実行
データ構成要素の結合を伴うデータ操作は、データビューマネージャオブジェクト３１２５により関連付けられたデータビューに対して処理することもできる。これらの結合は変換を伴っても、伴わなくても良い。通常、データ構成要素の結合の結果、問合せツリーにおいて新規の要素コンストラクタが得られる。変換操作と同様に、データビューマネージャオブジェクト３１２５は、まず、問合せがセクション７．２においてフィルタ操作に関して説明したようなｆｌｗｏｒ表現の形式であることを確認しなければならない。
【０３６２】
好適な構成では、ユーザはデータビュー（例えば、表の列）において２つ以上のデータセットを選択し、コンテキストメニュー１２９２上で結合オプションを選択することによって結合が必要であることを示すことができる。あるいは、図１３Ａから図１３Ｃを参照して先に説明したように、新規のデータをデータビューへとドラッグする際に２つのデータセットを結合することを選択することもできる。ユーザは、セクション３．０、４．０、及び６．０において説明した例に基づく方法を使用して所望の結合を定義できるのが好ましい。代替の構成では、結合の機能を指定するようにユーザに対して要求しても良い。結果として生じる結合操作に対する要求は、セクション３．０及び４．０において説明したように、１つ以上の２項演算又はｎ項演算を伴っても良い。
【０３６３】
好適な構成では、結合は、操作中のデータビューと関連付けられた図３１Ａのデータビューマネージャオブジェクト３１２５上で以下の方法のうちの１つを呼び出すことによって処理される。
１．void combine(String newName, Operation op, DataSet ds1, DataSet ds2, boolean createMapping, boolean removeSources)
２．void combine(String newName, Operation op, DataSetList dataSetList, boolean createMapping, boolean removeSources)
一連の変換及び２項演算又はｎ項演算を伴う結合操作は、積分演算成分へと分解されるのが好ましく、個々の呼出しは、transform(.)方法及び上述のcombine(.)方法に対して行なわれる。演算はセクション３．０及び４．０において先に説明したように左から右に実行される。
【０３６４】
各結合操作は、オプションのnewName引数と関連付けることができる。供給される場合、この引数は結合の結果を保持するようにＸＱｕｅｒｙにおいて作成された要素の名前となるであろう。供給されない（すなわち、ヌル）場合、第１のデータセットの名前が使用されることになる。ブールフラグremoveSourcesが偽であり、newNameが指定されない場合は、エラーが発生する。これは、結果のＸＱｕｅｒｙが同じ名前及び場合によっては同じネーム空間を有する２つの要素を持つことになるからである。結合に対するremoveSourcesのデフォルト値は真である。
【０３６５】
２項演算の場合、第１の方法が所望の操作を指定するｏｐ引数を伴って使用されるべきである。データブラウジングアプリケーション１２０がサポートする２項演算はセクション３．０に列挙される。このリストは好適な構成に対して列挙されたものから更なる演算又は異なる演算を含むように補足されても良い。データセット引数ds1及びds2は、操作を実行中のデータセットを指し示す。
【０３６６】
ｎ項演算の場合、第２の方法が使用されるべきである。２項演算に関して、op引数は、dataSetList引数における全てのデータセット上で実行される所望の操作を定義する。データブラウジングアプリケーション１２０がサポートするｎ項演算のリストはセクション３．０に列挙される。２項演算と同様に、このリストも更なる演算又は異なる演算を含むことができるのは明らかであろう。
【０３６７】
変換に対して可能であるのと同様に、結合に対してもマッピングを作成することができる。createMappingフラグが真に設定される場合、データビューマネージャオブジェクト３１２５は、セクション７．４において説明したように結合に対するマッピングを作成するであろう。
【０３６８】
７．６  データ構成要素の非表示
好適な構成では、ユーザはデータビューのデータ構成要素を「非表示化する」こともできる。これは、データ構成要素に対するデータが問合せの一部として収集されるが、提示に関しては無視されることを意味する。ユーザは、最初にＧＵＩ１２００においてデータ構成要素を選択し、次にコンテキストメニュー１２９２から非表示化オプションを選択することによって、データ構成要素を非表示化するのが好ましい。この動作の結果、以下の方法が、データ構成要素が存在するデータビューと関連付けられた図３１Ａのデータビューマネージャオブジェクト３１２５上で呼び出される：
void hide(DataComponent dc)
但し、dc引数はデータノード、データセット、又はデータシリーズを表すことができる
データ構成要素を非表示化するプロセスについて図６４を参照して説明する。ステップ６４０５において、図３１Ａのデータビューマネージャオブジェクト３１２５は、データビューと関連付けられた問合せを検査する。問合せがｆｌｗｏｒ表現でない場合、ステップ６４１０に従って、ＸＱｕｅｒｙ例５及び図６２のステップ６２２０を参照して説明したように、ｆｌｗｏｒ表現へと変換される。制御はステップ６４１５へと進む。ステップ６４１５において、非表示化するデータ構成要素が、ｆｌｗｏｒ表現のｒｅｔｕｒｎサブツリーにおける要素コンストラクタにより表現される場合、制御はステップ６４２５へと進む。表現されない場合、ステップ６４２０において、データ構成要素を表現するために要素コンストラクタが作成される。このステップは、データ構成要素が属性コンストラクタから予め取得されているか、あるいは、可変アドレス要素又は属性から得られる場合に必要とされるであろう。
【０３６９】
ステップ６４２５において、データビューマネージャオブジェクト３１２５は、ｈｉｄｄｅｎ属性に対して属性コンストラクタを生成し、これがまだ存在していない場合にはこの属性の値を真に設定する。ｈｉｄｄｅｎ属性は、データブラウジングアプリケーション１２０に関連付けられたネーム空間に対して存在するように定義されるため、データソースにより使用される他のデータ構成要素と競合すべきではない。プロセスはステップ６４９０で終了する。
【０３７０】
セクション５．０において説明したデータビュー提示処理は、非表示としてマーク付けされたデータ構成要素を事実上無視する。ユーザは、データビューのコンテキストメニュー１２９２の非表示化されたデータ構成要素の表示オプションを選択することによって、非表示のデータ構成要素を見ることを選択することができる。この結果、データビューは全ての構成要素が表示された状態で提示される。ユーザは、非表示のデータ構成要素を表示せずにデータビューを見ることができるように、非表示化されたデータ構成要素の表示オプションをトグルとして使用することができる。
【０３７１】
非表示データ構成要素は、ユーザがＧＵＩ１２００において表示された非表示データ構成要素を選択し、コンテキストメニュー１２９２から可視状態設定オプションを選択することによって可視状態（すなわち、隠れていない状態）にすることができる。この動作の結果、以下の方法が関連するデータビューマネージャオブジェクト３１２５上で呼び出される：
void unHide(DataComponent dc)
引数dcにより示されるデータ構成要素は、非表示の状態を削除する。この方法は、問合せのｒｅｔｕｒｎサブツリーにおいてデータ構成要素に対するｈｉｄｄｅｎ属性の値を偽に設定するのが好ましい。代替の構成では、データ構成要素の要素コンストラクタから属性を削除することができる。データビュー提示プロセスが再度実行され、今度はデータビューが指定されたデータビューを含むようになる。
【０３７２】
非表示のデータ構成要素がデータビューの一部として提示される場合、セクション５．０において説明した提示プロセスにより、異なる１セットの許容可能な表示種別が得られるかもしれない。データの提示に使用される表示種別は、ユーザが可視状態設定動作又は非表示化されたデータ構成要素の表示動作を開始する前に使用されていた表示種別から変更されないのが好ましい。
【０３７３】
７．７  データ構成要素の名前変更
データ構成要素は名前を変更することもできる。好適な構成では、ユーザは図１２ＡのＧＵＩ１２００においてデータ構成要素（例えば、表の列、グリッド単位など）を選択し、そのデータ構成要素の名前を変更することができる。この結果、データビューと関連付けられた図３１Ａのデータビューマネージャオブジェクト３１２５の以下の方法が呼び出される。
void rename(String newName, DataComponent dc, boolean createMapping)
データノード、データセット、及びデータシリーズは、全てデータ構成要素の専門化したものである（セクション２．０参照）ので、これらの種別のオブジェクトを引数として渡すことができる。
【０３７４】
前述の方法と同様に、データビューマネージャオブジェクト３１２５は、まず、ｒｅｔｕｒｎサブツリーにおいてデータ構成要素を配置しなければならない。この方法では、正しい識別子をｒｅｔｕｒｎサブツリーに配置するために、データ構成要素に対してその種別（すなわち、データノード、データセット、又はデータシリーズ）を問い合わせる必要があるかもしれない。一度配置されると、ｎｅｗＮａｍｅ引数により指定された識別子を有するｔａｇＮａｍｅを伴う要素コンストラクタがｒｅｔｕｒｎサブツリーへと追加され、指定されたデータ構成要素に対応する要素が削除される。データ構成要素の内容は名前変更操作によって変更されない。データ構成要素が要素コンストラクタ（変数に対するパスではない）により予め表現されている場合、要素コンストラクタの名前は変更されるのが好ましい。換言すれば、データビューマネージャオブジェクト３１２５は、ｒｅｔｕｒｎサブツリーにおいてｔａｇＮａｍｅノードの名前を変更するだけで良い。
【０３７５】
ｎｅｗＮａｍｅ引数がタグ識別子の必要条件に合致しない（例えば、スペースを含む）場合、データビューマネージャオブジェクト３１２５は、データ構成要素に対する配置された要素コンストラクタにおいて、ｄｃｎａｍｅ属性に対する属性コンストラクタを作成するのが好ましい。属性コンストラクタはこの属性の値をｎｅｗＮａｍｅ引数の値へと設定する。非表示の属性と同様に、ｄｃｎａｍｅ属性は、データブラウジングアプリケーション１２０と関連付けられたネーム空間に対して存在するように定義される。
【０３７６】
変換及び結合と同様に、名前変更操作もマッピングとして保存することができる。
【０３７７】
８．０  選択された表示種別及びキーワードの意味体系を使用して新規のデータビューを作成する代替の方法
新規のデータビューの作成は、データビューを作成するユーザが仕事に関連する情報を有するデータソースについて知らないために困難になることが多い。本開示のセクション６．０及び７．０において説明したグラフィカルな方法は、ユーザが既存のデータソース及びデータビューへのアクセス権を有することに依存する。ユーザの持つデータソース及び適切なマッピングの知識は、他のユーザとのデータビューの交換により拡張される。本セクションでは、データビュー内で使用するためにデータ構成要素をユーザに対して推奨する方法について説明する。この推奨方法は、生成されたデータビュー及びデータソースに関する情報を格納する中央の推奨サービスを使用する。説明する推奨方法は、選択された表示種別及びキーワードの意味体系を使用して賢明な推奨をユーザに対して提供する。
【０３７８】
未熟なユーザが複数の異質なデータソースにまたがって新規のデータビューを視覚的に作成できるようにするコンピュータ実現方法は、データブラウジングアプリケーション１２０の一部を形成するプロセス１４９０により実行されても良い。プロセス１４９０については図１４のフローチャートを参照して説明する。ステップ１４００において、プロセス１４９０は許容された表示種別のリストから表示種別のユーザ選択を検出する。これは上述の構成と同様の方法でＧＵＩを使用することで実行されても良い。表示種別はデータビューにより使用される視覚表現であり、好適な構成では、表、棒グラフ、線グラフ、円グラフ、散布図、２Ｄグリッド、及びツリーを含む。必要に応じて、他の表示種別を代わりに使用しても良い。各表示種別は１つ以上の表示テンプレートと関連付けられる。例えば、棒グラフ表示種別は２Ｄ棒グラフテンプレート及び３Ｄ棒グラフテンプレートなどと関連付けられる。各表示テンプレートは独自の書式指定を有する。表示テンプレートは、ステップ１４０５に示すように、ＧＵＩを介してユーザに対して表示される。ユーザは、プロセス１４９０によりステップ１４１０において検出され、新規のデータビューに対して使用される１つの表示テンプレートを選択する。表示種別は、デフォルトの表示テンプレートと関連付けられ、表示種別の選択時にデフォルトの表示テンプレートが自動的に選択されるのが好ましい。
【０３７９】
図１５は、棒グラフ表示種別に対する表示テンプレートの一例である。表示テンプレートは複数のデータ構成要素スロット１５０５から１５２５を含む。新規のデータビューを作成するためには、これらのスロットに対してデータ構成要素を指定しなければならない。データ構成要素スロットは、選択された表示種別の意味体系に従って関連付けられる。例えば、グラフにおいて、ｙ軸と関連付けられたデータ構成要素は、ｘ軸と関連付けられたデータ構成要素に対して点別の対応を有する必要がある。このため、各表示種別はある特定の１セットの意味体系と関連付けられる。この１セットの意味体系については詳細に後述する。また、表示テンプレートは、図１５に示す１５００のようなユーザがテキストを供給可能な１つ以上の記述スロットを含む。これらのスロットはユーザに対して識別可能であり、シェーディング又は図１５に示す破線の境界線のようなその他の手段によりデータ構成要素スロットと区別することができる。データ構成要素スロット及び記述スロット１５００から１５２５の役割は、ユーザがマウスポインタ１１０３を操作することによりカーソルがスロット（例えば、タイトル）の上方に配置されるときに表示されるのが好ましい。また、データ構成要素が一度スロットに対して指定されると、ユーザはスロットに対する表示テキストを修正することができるのが好ましい。
【０３８０】
ステップ１４１５において、プロセス１４９０は、既知のデータソースのリストから１つ以上のデータソースのユーザ選択を検出する。プロセス１４９０は、ほぼセクション２．０において説明したように、選択されたデータソースに対するスキーマビューをステップ１４２０において作成・表示する。代替の実現例では、プロセス１４９０は、ステップ１４１５及びステップ１４２０がステップ１４００の前に実行されるように構成されても良い。ステップ１４２５において、プロセス１４９０はデータビューに含むべき１つ以上のデータ構成要素のユーザ指定を検出する。ユーザは、各データ構成要素をステップ１４２０において作成されたスキーマビューから新規のデータビューのデータ構成要素スロットへとドラッグすることによってこの検出を行なっても良い。各選択されたデータ構成要素は、テンプレート中のスロットと関連付けられる。また、ユーザは既存のデータビューからデータ構成要素を選択し、これらのデータ構成要素をテンプレートスロットへとコピーすることができる。このプロセスについてはセクション６．０において説明されている。
【０３８１】
ステップ１４３０において、プロセス１４９０は、データブラウジングアプリケーション１２０のユーザ要求を検出し、作成中のデータビューに関連するであろう他のデータ構成要素に対して推奨のリストを提供するように動作する。ステップ１４３５において、プロセス１４９０は、１つ以上の指定されたデータ構成要素及び選択された表示種別の意味体系に従って、新規のデータビューの１つ以上の未指定のデータ構成要素に対して推奨のリストを提供する。ステップ１４４０において、データソース推奨はスキーマビュー内に表示される。スキーマビューは、推奨のコンテキストを示すのに役立つ。このコンテキストは、ユーザが推奨のデータソースを識別できるようにデータソースルートを含むのが好ましい。
【０３８２】
ステップ１４４０において作成されたスキーマビューにおいて、データ構成要素推奨は強調表示される。ユーザは、このスキーマビューから未指定のデータ構成要素スロットに対するデータ構成要素を選択することができる。選択動作は、プロセス１４９０によりステップ１４４５において検出される。ステップ１４４５において、選択されたデータ構成要素を含むようにデータビューのデータが更新される。データビューと関連付けられた問合せも更新される。決定ステップ１４６５において、ユーザが全ての所要のデータ構成要素を指定する場合、プロセス１４９０は終了する。ステップ１４６５において、更なるデータ構成要素が必要な場合、ステップ１４４５におけるユーザ選択に従って推奨リストが更新される。これは、１つの選択により異なるランク付け順序が得られる場合、あるいは、先に選択された推奨のうちの１つ以上が無関係になる場合に起こる可能性がある。例えば、ユーザがｘ軸に対してデータ構成要素を選択する場合、選択されたｘ軸データ構成要素に対するデータシリーズとして動作可能なデータ構成要素を含むように推奨のリストが更新されることになる。データ構成要素選択及び推奨リストの修正は、ユーザがデータビューに含むことを希望する全てのデータ構成要素が指定されるか、あるいは、ユーザにより推奨プロセスが終了させられるまで継続する反復過程である。
【０３８３】
新規のデータビューを視覚的に作成する代替の方法が図１６に示される。図１６は、別のプロセス１６９０のフローチャートを示す。ステップ１４００から１４１０（図１４のプロセス１４９０の各ステップに対応）に引き続き、ユーザは、選択された表示テンプレートにおける１つ以上のデータ構成要素スロットに対してキーワード表現を指定し、テンプレートスロットに対する所望の内容を示すことができる。これは、ステップ１４２５ではなく、プロセス１６９０のステップ１６００により検出される。これらのキーワード表現は、個々のキーワードの論理結合とすることも、あるいは、１つ以上のキーワードのリストとすることもできる。キーワード表現は引用符により囲まれる（「このように」）。図１７は、キーワード表現が指定されるデータ構成要素スロットを有する円グラフ表示テンプレートの一例を示す。ユーザは、円グラフの値及びラベルデータ構成要素として、それぞれ、キーワード表現「Ｓａｌｅｓ」及び「Ｐｒｏｄｕｃｔ」を入力している。ステップ１６０５において、データブラウジングアプリケーション１２０の一部を形成するプロセス１６９０が、データに対して推奨のリストを提供する。推奨は、データ構成要素のデータ構成要素名、スキーマ記述、又はＸＭＬパスと指定されたキーワード表現との類似性及び表示種別の意味体系に基づいている。ステップ１６１０において、プロセス１６９０は、スキーマビューを作成・表示して推奨のコンテキストを示す。
【０３８４】
ステップ１４４５におけるように、ユーザは、推奨のリストにより生成されたスキーマビューからデータ構成要素を選択する（プロセス１６９０によりステップ１６１５において検出）か、あるいは、未指定のデータ構成要素スロットに対してキーワード表現を指定する（ステップ１６２５において検出）ことを継続することができる。前者の場合、ステップ１６２０において、データビュー及び関連付けられた問合せが更新され、ユーザが全ての所要のデータ構成要素を指定したか否かを判定するために検査１６４０が実行される。指定していない場合及び代替の操作の場合、ステップ１６３０において、リストから選択されたデータ構成要素又は新規に指定されたキーワード表現に従って推奨リストが更新される。また、推奨は選択された表示種別の意味体系にも基づいている。キーワード表現を指定する場合、ユーザは、スロットに対するデータ構成要素を確認するために、推奨リストからデータ構成要素を選択しなければならない。ユーザが選択された表示テンプレートにおいて必要なデータ構成要素スロットを指定した後、プロセス１６９０は終了する。
【０３８５】
推奨を生成する方法は、図２２のデータ流れ図において示される。好適な構成では、中央推奨システム２２００が、指定された１セットのデータ構成要素（例えば、ｄｃ１、ｄｃ２、．．．）に関連するランク付けされたデータ構成要素の完全なリストを当面の操作に対して推奨する。この１セットのデータ構成要素は、データビューに対して既に選択されているデータ構成要素を具備しても良い。中央推奨システム２２００が使用する好適な方法についてはセクション９．０において更に詳細に説明する。キーワードマッパ２２０５は、ユーザが入力したキーワード表現（例えば、ｋｗ１、ｋｗ２、．．．）を既知のデータソース中の可能なデータ構成要素へとマップする。また、キーワードマッパ２２０５は、一度に単一のキーワードを取ることによって動作し、そのキーワードを可能なデータ構成要素へとマップすることができる。
【０３８６】
中央推奨システム２２００及びキーワードマッパ２２０５の双方は、利用可能なデータソース及び先に生成されたデータビューに関する情報へのアクセス権を有する中央サーバ２２２０上に位置する及び／又は中央サーバ２２２０上で動作するソフトウェアアプリケーションにより形成されるのが好ましい。上述のステップ１４３５は、中央推奨システム２２００を使用して推奨の初期リストを生成する。ステップ１６０５において、推奨のリストを生成する方法は、キーワードマッパ２２０５を使用して既知のデータソースにおいて可能なデータ構成要素を識別することを伴う。２つ以上のキーワード表現が指定される場合、あるいは、ユーザにより他のデータ構成要素がデータビューに対して指定されている場合、これらの可能なデータ構成要素に基づいて中央推奨システム２２００により推奨のリストを生成することができる。ユーザが表現を１つだけ指定し、データビューに対して他のデータ構成要素が指定されない場合、推奨は、キーワードマッパ２２０５により識別される可能なデータ構成要素である。ステップ１４３５及び１６０５の双方において、中央推奨システム２２００により生成される推奨のリストは、データブラウジングアプリケーション１２０の一部を形成するプロセス２２１０において、選択された表示種別の意味体系に従ってフィルタリングされる。推奨を生成する方法については更に詳細に後述する。
【０３８７】
一例を用いて図１４に示す方法に対する更に詳細な説明を提供する。企画部の販売企画部長が棒グラフを作成し、１９９９年１月の各製品の製品売上と売上目標との比較を示すことを希望するものとする。販売部には製品売上記録が保管されているが、企画部長は製品売上データベースについて知らない。売上目標情報は自身のデータシートＳａｌｅｓＴａｒｇｅｔＤＳに記録されている。棒グラフ（すなわち、新規のデータビュー）を作成するために、企画部長は、棒グラフ表示種別を有する新規のデータビューの作成を選択することができ、図１５に示すように、デフォルトの棒グラフ表示テンプレートが表示される。これにより、企画部長は、既知のデータソースを検査しても良い。恐らく、既知のデータソースは２つ、すなわち、ＳａｌｅｓＴａｒｇｅｔｓＤＳ及び人事データベース（ＨＲＤＢ）だけであろう：
HRDB
SalesTargetsDS
ＨＲＤＢデータソースは、ＸＭＬ文書又はデータサーバにより表現することができる。ＳａｌｅｓＴａｒｇｅｔｓＤＳを選択することにより、ＳａｌｅｓＴａｒｇｅｔｓＤＳのスキーマビューをほぼセクション２．０において説明したように示すことができる。このスキーマビューを以下に示す：
SalesTargetsDS
ProductCode
ProductName
Descriptions
SalesManager
Year
Month
SalesQuota
ＳａｌｅｓＴａｒｇｅｔｓＤＳにおけるＰｒｏｄｕｃｔＮａｍｅは、企画部長が棒グラフのｘ軸上に表示することを希望するデータ構成要素である。企画部長は、上述のＰｒｏｄｕｃｔＮａｍｅをデータ構成要素スロット１５２０へとドラッグすることによってこれを示すことができる。また、ユーザは、図１２Ａのワークスペース１２０２における別のデータビューに表示されたＳａｌｅｓＴａｒｇｅｔｓＤＳ／ＰｒｏｄｕｃｔＮａｍｅデータ構成要素を選択し、選択されたデータ構成要素を新規のデータビューにおけるｘ軸スロットへとドラッグすることができる。新規のデータビューをグラフィカルに作成するこのプロセスについてはセクション６．０において説明されている。ユーザは、残るデータ構成要素スロットに対して中央推奨システム２２００からの推奨を提供するようにデータブラウジングアプリケーション１２０に対して要求する。中央推奨システム２２００は、ユーザが他のユーザの使用に供するために作成したデータビューを出版（又は登録）できる出版サービスとして動作するのが好ましい。企画部長がこのサービスを用いてＳａｌｅｓＴａｒｇｅｔｓＤＳを出版したものとする。通常、このようなサービスは会社単位で実現されるであろう。全ての出版されたデータビューに対するアクセス権を有するので、中央推奨システム２２００は登録されたデータビューを分析し、データソースの存在と異なるデータソースにおけるデータ構成要素間の関係（例えば、データソースにまたがる結合）とについて知ることができる。この中央推奨システム２２００は、ＳａｌｅｓＴａｒｇｅｔｓＤＳと関連付けられた問合せを使用してＳａｌｅｓＴａｒｇｅｔｓＤＳと他の既知のデータソースとの関係を識別することができる。関連するデータソースである製品売上データベース（ＳａｌｅｓＤＢ）が識別される。ＳａｌｅｓＤＢは、ＰｒｏｄｕｃｔＣｏｄｅと呼ばれるデータ構成要素を有し、このＰｒｏｄｕｃｔＣｏｄｅは、データソースＳａｌｅｓＴａｒｇｅｔｓＤＳのＰｒｏｄｕｃｔＣｏｄｅと同じデータである。ＳａｌｅｓＤＢは、子データ構成要素Ｓａｌｅｓ、Ｐｒｏｄｕｃｔｓ、及びＣｕｓｔｏｍｅｒを有する。データ構成要素Ｐｒｏｄｕｃｔｓ／ＰｒｏｄｕｃｔＣｏｄｅ及びＳａｌｅｓ／ＰｒｏｄｕｃｔＣｏｄｅは、ＸＭＬスキーマ定義における共通キー指定に従って関連していることが知られている。従って、以下の関係を推論することができる：
（１）SalesDB/Products/ProductCode = SalesDB/Sales/ProductCode
及び
（２）SalesDB/Products/ProductCode = SalesTargetsDS/ProductCode
ＳａｌｅｓＤＢのスキーマビューが以下に示される：
SalesDB
Sales
ProductCode
Quality
Year
Month
Products
ProductCode
ProductName
Descriptions
Price
Customers
CustomerID
CompanyName
ContactName
Address
Phone
中央推奨システム２２００は、既に選択されたＳａｌｅｓＴａｒｇｅｔｓＤＳ／ＰｒｏｄｕｃｔＮａｍｅデータ構成要素と関連するデータ構成要素を具備する推奨のリストを生成することができる。このプロセスについては次のセクションにおいて説明する。推奨のリストに加えて、中央推奨システム２２００は、推奨されたデータ構成要素に関連する結合条件に関する情報を戻す。この結合条件情報は、データブラウジングアプリケーション１２０が新規のデータビューに対する問合せを生成するのに必要である（更なる詳細についてはセクション７．０を参照）。この推奨のリストは、２２１０において表示種別の現在の選択に基づいてフィルタリングされ、関連するデータ構成要素は結果として生じるスキーマビューにおいて強調表示されたデータ構成要素としてユーザに対して提示される。
【０３８８】
2004240954.tif 000023
【０３８９】
強調表示されたデータ構成要素は、ＳａｌｅｓＴａｒｇｅｔｓＤＳ／ＰｒｏｄｕｃｔＮａｍｅデータ構成要素がｘ軸に割り当てられているグラフに対するデータシリーズとして動作することができる唯一のデータ構成要素である。データシリーズは、数値であると共にｘ軸データ構成要素に対して点別の対応を有する必要がある。これらの推奨は棒グラフ表示種別の意味体系に基づいている。
販売企画部長は、対応するスキーマビュー項目をデータビューの対応するスロットへとドラッグすることによって、スロット１５０５に対してはＳａｌｅｓＴａｒｇｅｔｓＤＳのＳａｌｅｓＱｕｏｔａを、スロット１５１０に対してはＳａｌｅｓＤＢ／Ｓａｌｅｓ／Ｑｕａｎｔｉｔｙを選択することができる。グラフが単一のデータシリーズを必要とする場合は、直接スロット１５２５へとドラッグすることができる。この場合、選択されたデータ構成要素の名前は、第１フィールドの凡例項目として自動的に表示されるであろう。必要でなければ、ユーザは凡例を削除することができる。
【０３９０】
必要に応じて、タイトルテキストボックス１５００においてタイトルを指定することもできる。ｘ軸に対するラベルは、ｘ軸に対して選択されたデータ構成要素の名前へとデフォルト設定される。しかし、ユーザはこのラベルのテキストをより有意味なものへと変更しても良い。同様に、データブラウジングアプリケーション１２０は、ｙ軸に対するラベルを生成しようと試みる。しかし、選択されたデータ構成要素の知識を必要とするために自動的にこれを行なうのが困難である場合が多い。従って、ユーザは、軸ラベルに対して所要のテキストを入力しても、あるいは、関連するデータ構成要素名からデータブラウジングアプリケーション１２０により自動的に生成されたラベルを上書きしても良い。テンプレートスロットは、必要でない場合には空のままにすることも、あるいは、削除することもできる。新規のデータビューに対してデータ構成要素が一度選択されると、データビューに対してフィルタ制約を指定し、表示するデータをＹｅａｒ「１９９９」及びＭｏｎｔｈ「Ｊａｎｕａｒｙ」に制限することができる。これらのフィルタ制約は、セクション６．０において説明したように、実際にはＳａｌｅｓＴａｒｇｅｔｓＤＳ／Ｙｅａｒ構成要素及びＳａｌｅｓＴａｒｇｅｔｓＤＳ／Ｍｏｎｔｈデータ構成要素に対して指定することができる。結果の図は図１８に示される。
【０３９１】
図が完成したことを示すために、ユーザはデータビューの保存を選択することができる。この結果、データブラウジングアプリケーション１２０も、新規のデータビューに対する問合せを保存する。好適な構成では、問合せはセクション７．０において説明したようにＸＱｕｅｒｙを使用して表現され、新規のデータ構成要素をデータビューへと追加するごとに更新される。上述の例に対して生成された問合せを以下に示す：
【０３９２】
2004240954.tif 000024
【０３９３】
表示種別意味体系に基づく図２２のフィルタリング操作２２１０の詳細な説明を提供する。中央推奨システム２２００は、指定された１つ以上のデータ構成要素に関連する可能性がある全てのデータ構成要素を含む推奨のリストを生成する。このリストは、指定されたデータ構成要素と直接的又は間接的な関係を有する全てのデータ構成要素を含み、所望の表示種別の知識なしに生成される。データブラウジングアプリケーション１２０は、このリストが現在のデータビューの未指定のスロットを満たすことのできるデータ構成要素のみを含むようにフィルタリングを行なう（すなわち、このリストは表示種別の意味体系に従ってフィルタリングされる）。
各表示種別の詳細な意味体系が以下で説明される：
表表示種別意味体系
１．表のある行に対して表示されるデータは同じエンティティを指し示さなければならない
２．各列はデータセットとして動作可能でなければならない。データセットは同じデータ構成要素の複数のインスタンス又は同じデータ構成要素として動作可能なデータとして定義される（例えば、データ構成要素の変換又は結合の結果）。ＸＭＬデータの要素及び属性の双方はデータ構成要素として動作することができる
棒グラフ表示種別意味体系
１．棒グラフのｘ軸上に表示されるデータ構成要素は、例えば、Ｐｒｏｄｕｃｔ１、Ｐｒｏｄｕｃｔ２、．．．などのデータセットを表現する
２．棒グラフのｙ軸上に表示されるデータ構成要素は、ｘ軸データ構成要素に対するデータシリーズとして動作可能でなければならない。これは、
（ｉ）データセットとして動作可能でなければならないこと（上述参照）、
（ｉｉ）数値又は関連付けられた単位（例えば、１００ｋｇ、＄１００）を有する数値でなければならず、後者の場合、データシリーズにおけるこのような全ての値が同じ単位又は互換性のある単位を持たなければならないこと［例えば、全てが通貨値であるか、あるいは、全てが重量の測定値である場合。これは、数値が予期される他の表示種別にも当てはまる］、及び
（ｉｉｉ）ｘ軸データ構成要素に対して点別の対応を有することを意味する
線グラフ表示種別意味体系
線グラフと関連付けられた想定される意味体系は、棒グラフに対して定義されるのと同様であり、追加の必要条件としては、ｘ軸上に表示されるデータ構成要素は、数値又は数値的に解釈可能でなければならない。例えば、月などの時間関連のラベルは数値的に解釈することができる
円グラフ表示種別意味体系
全体として表現されるデータ構成要素は、セグメントラベルに対する数値のデータシリーズである。
２Ｄグリッド表示種別意味体系
１．２Ｄグリッドの各グリッド単位に表示されるデータは同じエンティティを指し示す（例えば、写真及び名前）
２．各グリッド単位は同じ形式の同じセットのデータ構成要素を含む
散布図表示種別意味体系
散布図表示種別意味体系は線グラフと同じである。
【０３９４】
関連付けられた意味体系を有する他の表示種別も含まれるであろう。代替の実現例では、異なる意味体系を有する異なる１セットの表示種別を選択しても良い。例えば、代替の実現例は、線グラフと散布図とを同じ表示種別と見なしても良く、グラフが棒グラフ又は線グラフの書式を持つようにしても良い。
【０３９５】
ユーザ指定のキーワード表現に基づいてデータ構成要素を推奨する方法について詳細に説明する。図２２において明らかなように、キーワードマッパ２２０５は、データブラウジングアプリケーション１２０を介してユーザから１セットのキーワード表現を受信する。キーワードマッパ２２０５は、キーワード検索エンジンを使用して、指定されたキーワード表現に何らかの点で類似する名前又はスキーマ記述を有するデータ構成要素を検索する。これらのデータ構成要素は、データソースのスキーマ及び利用可能なデータビュー定義から識別されるのが好ましい。キーワードマッパ２２０５は、指定されたキーワード表現と類似する、あるいは、指定されたキーワード表現の同義語であるデータ構成要素（すなわち、要素及び属性）を識別する。換言すれば、キーワードマッパは、データ構成要素をキーワード表現へと動的にマップする。検索の結果は、データ構成要素名と指定されたキーワード表現との類似性に基づいてランク付けされる。
【０３９６】
キーワードマッパ２２０５により生成されたデータ構成要素のランク付け順序は、提示されたスキーマビューに反映される。スキーマビューにおけるデータソースの順序は、一致の種別（完全／部分）とデータソースにおける一致したデータ構成要素の数とによって決まる。完全に一致したデータ構成要素は、部分的に一致したデータ構成要素よりも高くランク付けされ、部分的に一致したデータ構成要素は、同義語による一致よりも高くランク付けされる。例えば、２つの完全に一致したデータ構成要素を含むデータソースは、１つの完全に一致したデータ構成要素を含むデータソースよりも高くランク付けされ、１つの完全に一致したデータ構成要素を含むデータソースは、部分的に一致したデータ構成要素のみを含むデータソースよりも高くランク付けされる。
【０３９７】
ユーザが単一のキーワード表現を指定する場合及びそのデータビューに対して他のデータ構成要素が指定されておらず、ユーザが推奨を取得することを選択する場合、ランク付けされたリストがキーワードマッパ２２０５により生成される。
【０３９８】
ユーザが２つ以上のキーワード表現を指定する場合、あるいは、他のデータ構成要素がそのデータビューに対して既に指定されており、ユーザが推奨を取得することを選択する場合、キーワードマッパ２２０５により生成されたデータ構成要素のランク付けされた可能なセットは、まず、経路２２０７を介して中央推奨システム２２００へと渡されるのが好ましい。これは、可能なデータ構成要素の結合に基づいて推奨のリストを生成するように動作する。
【０３９９】
いずれの場合でも、結果として生じる推奨されたデータ構成要素は、選択された表示種別の上述の意味体系に基づいて更にフィルタリングされる。指定されたキーワード表現に幾らか類似し、選択された表示種別の意味体系を満たすデータ構成要素は、データブラウジングアプリケーション１２０のスキーマビューにおいて強調表示されたデータ構成要素として推奨される。
【０４００】
図１６に示す詳細な方法について一例として説明する。プロジェクトマネージャがプロジェクトに対するイントラネットページを作成し、そのページ上に各プロジェクトメンバの名前、電話番号、電子メールアドレス、及び写真をグリッドとして含むことを希望するものとする。情報は会社のデータベース又はファイルに格納されており、このデータベース又はファイルはイントラネットを介して分散している可能性がある。表示種別のリストから、プロジェクトマネージャは２Ｄグリッド表示種別を選択することができる。図１９に示すようなデフォルトの２Ｄグリッド表示テンプレートが表示される。マネージャは、データ構成要素スロット１９００にキーワード表現「ｐｈｏｔｏ」をキー入力し、表示テンプレートのこのスロット及び他のスロットに対する推奨を取得することを選択する。以下の可能なデータ構成要素は、図２２のキーワードマッパ２２０５により戻される。推奨のリストはスキーマビューとして表現され、ＨＲデータベースＨＲＤＢの推奨されたデータ構成要素Ｐｈｏｔｏが強調表示される。この例では、ＨＲＤＢはデータサーバを介してアクセスされるものとする。
【０４０１】
2004240954.tif 000025
【０４０２】
この推奨を使用するには、マネージャはスキーマビュー中の所望のデータ構成要素をスロットへとドラッグしなければならない。この結果、データビューは、図２０に示すように、ＨＲＤＢ／ＰｅｒｓｏｎａｌＤｅｔａｉｌｓデータセットにおけるＰｈｏｔｏインスタンスごとにグリッド単位を示すように更新される。スロット中のキー入力されたキーワード表現は、選択により置き換わるまで引用符でマーク付けされる。マネージャは、図１９のスロット１９０５へとドラッグすることによってＮａｍｅデータ構成要素をスキーマビューから選択することができる。この選択の結果、図２１において明らかなように、推奨リストは中央推奨システム２２００により更新され、データブラウジングアプリケーション１２０のフィルタ２２１０によりフィルタリングされる。これが起こるのは、Ｎａｍｅデータ構成要素が他の多くのデータ構成要素に直接的又は間接的に関連している可能性があるからである。更新されたスキーマビューは以下のように表示されるであろう：
【０４０３】
2004240954.tif 000026
【０４０４】
強調表示されたデータ構成要素は、データ構成要素名とキーワードとの類似性、データ構成要素のスキーマ定義におけるキーワードの存在、又はデータ構成要素のＸＭＬパスにおけるキーワードの存在に基づいて検出されたであろう推奨を表現する。ユーザがスキーマビューにおいて強調表示された項目の上でマウスを移動すると、推奨の理由が示される。
上述のスキーマビューにより、マネージャは、ＰｈｏｎｅＮｕｍｂｅｒデータ構成要素及びＥｍａｉｌデータ構成要素をスロット１９１０及び１９１５へとドラッグすることによって、ＣｏｍｐａｎｙＰｈｏｎｅＬｉｓｔＤＳからこれらのデータ構成要素を選択することができる。これが可能であるのは、ＣｏｍｐａｎｙＰｈｏｎｅＬｉｓｔＤＳ／ＩＤＮｏがＨＲＤＢ／ＰｅｒｓｏｎａｌＤｅｔａｉｌｓ／ＩＤＮｏへと結合されること、すなわち、
HRDB/PersonalDetails/IDNo = CompanyPhoneListDS/IDNo
を中央推奨システム２２００が認識しているからである。
【０４０５】
プロジェクト「ＤＢＲ」の人員のみを表示するには、ProjectManagementDB /.Projects/ProjectCode = "DBR"のように、ＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢのＰｒｏｊｅｃｔＣｏｄｅに対してフィルタ条件が指定されなければならない。これが可能であるのは、中央推奨システム２２００が、ＨＲＤＢ．ＰｅｒｓｏｎａｌＤｅｔａｉｌｓ／ＩＤＮｏとＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢ／ＥｍｐｌｏｙｅｅＴａｓｋｓ／ＩＤＮｏとの結合関係、すなわち：
HRDB/PersonalDetails/IDNo = ProjectManagementDB/EmployeeTasks/IDNo
と、
ＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢ／Ｐｒｏｊｅｃｔｓ／ＰｒｏｊｅｃｔＣｏｄｅとＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢ／ＥｍｐｌｏｙｅｅＴａｓｋ／ＰｒｏｊｅｃｔＣｏｄｅとの結合関係、すなわち：
ProjectManagementDB/Projects/ProjectCode
= ProjectManagementDB/EmployeeTask/ProjectCode
とを認識しているからである。
【０４０６】
ユーザが作成されたデータビューの保存を選択すると、データブラウジングアプリケーション１２０は、選択されたデータ構成要素及びその既知の関係に基づいて問合せを生成する。
【０４０７】
2004240954.tif 000027
【０４０８】
最終データビューが図２１に示される。データソースから戻された４人のメンバの情報がある。最終データビューは、各セルがプロジェクトに対するメンバの情報を含む２ｘ２のグリッドである。セル情報は、メンバの写真、名前、電話番号、及び電子メールアドレスを含む。図２１の最終データビューでは、ラベル（Ｐｈｏｔｏ、Ｎａｍｅなど）として表示されるデータ構成要素名は非表示化されている。ユーザは最終データビューの生成後にラベルを非表示化できるのが好ましい。
マネージャは、まず、スロット１９００に「Ｐｈｏｔｏ」、スロット１９０５に「Ｎａｍｅ」の２つのキーワード表現をキー入力し、表示テンプレートのこれらのスロット及び他のスロットに対する推奨の取得を選択することができる。「Ｐｈｏｔｏ」キーワード及び「Ｎａｍｅ」キーワードへの類似性を有する可能なデータ構成要素がキーワードマッパ２２０５により識別され、中央推奨システム２２００へと渡される。結果として生じる推奨リストが、適切なデータ構成要素推奨が強調表示されたスキーマビューとして以下に示される：
【０４０９】
2004240954.tif 000028
【０４１０】
ＨＲＤＢは、指定されたキーワード表現に正確に一致し、同じデータベース表に出現する２つのデータ構成要素を有する。これは、最高ランクの可能性であるので先頭に列挙される。ＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢデータソースからは２つのデータ構成要素が識別される。キーワード表現と正確に一致するのは一方のデータ構成要素のみであり、他方のデータ構成要素は同じキーワード表現と部分的に一致する。このため、ＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＤＢはＨＲＤＢの後にランク付けされる。最後のデータソースＣｏｍｐａｎｙＰｈｏｎｅＬｉｓｔＤＳは１つのキーワード表現のみと一致するデータ構成要素を１つだけ含むため、最後にランク付けされる。表示種別２Ｄグリッドと関連付けられた意味体系に従って、グリッドに表示されたデータ構成要素は同じエンティティを指し示さなければならない。これは、中央推奨システム２２００が知る関係により保証される。
マネージャは、ＨＲＤＢのデータ構成要素Ｐｈｏｔｏ及びＮａｍｅをデータビューのスロット１９００及び１９０５へとドラッグすることによって、スロットにおいて指定されるキーワード表現に対するデータ構成要素を確認することができる。この結果、スキーマビュー（推奨を含む）は他の可能な推奨を強調表示するように更新される。マネージャは、ＣｏｍｐａｎｙＰｈｏｎｅＬｉｓｔＤＳのデータ構成要素ＰｈｏｎｅＮｕｍｂｅｒと、ＣｏｍｐａｎｙＰｈｏｎｅＬｉｓｔＤＳのＥｍａｉｌデータ構成要素を選択し、データビューを終了することができるだろう。
【０４１１】
３つ以上のキーワード表現に対する推奨のリストを生成する方法について説明する。指定されたキーワード表現の各々に対する可能なデータ構成要素がキーワードマッパ２２０５により識別される。この結果、指定されたキーワード表現ごとに１セットのデータ構成要素が得られる。例えば、ユーザは２つのキーワード表現ｋ１及びｋ２をキー入力する。データ構成要素の可能なセットが以下に示される：
k1      k2
---------- ----------
DS1.ck11  DS1.ck21
DS1.ck12  DS1.ck22
DS1.ck13
左列では、３つのデータ構成要素がｋ１へとマップされている。これらのデータ構成要素は、３つの異なるデータソース（ＤＳ１、ＤＳ２、及びＤＳ３）からのものである。右列では、２つのデータ構成要素がデータソースＤＳ１及びＤＳ５からｋ２へとそれぞれマップされている。中央推奨システム２２００は、指定されたデータ構成要素の存在に基づいて推奨を戻すことができるので、データブラウジングアプリケーション１２０は、上述のセットからデータ構成要素の対を系統的に選択し、推奨のためにこれを中央推奨システム２２００へと渡すことができる。中央推奨システム２２００に渡される対が以下に列挙される：
DS1.ck11,  DS1.ck21
DS1.ck11,  DS5.ck22
DS2.ck12,  DS1.ck21
DS2.ck12,  DS5.ck22
DS3.ck13,  DS1.ck21
DS3.ck13,  DS5.ck22
中には、無関係であるために推奨が得られない対もある。重複したデータ構成要素の推奨は、作成された推奨のリストがフィルタ２２１０へと渡される前に推奨のリストから削除される。推奨の最終リストは、上述の対から生成された推奨の非反復性のリストを含むであろう。
【０４１２】
９．０  データビュー作成のために推奨を作成する方法
本開示のセクション８．０から１０．０において記載する構成により、データのビューを異質なデータソースにまたがって形成することができ、このビューは平均的なユーザ（すなわち、コンピュータシステム及びデータベースの管理技術に必ずしも熟練していないユーザ）により作成できるようになる。このデータのビューは、好適な構成のデータブラウジングアプリケーション１２０のデータビュー又は他のアプリケーション及びシステムに必要なデータのビューの他の表現を表すことができる。以降、本セクション及び以降のセクションでは、用語「ビュー」は、一般的に、データのビューを指し示すのに使用される。本セクション及びセクション１０において開示される記載の構成は、関連するデータ構成要素を識別し、ビュー作成プロセスに対して推奨することができる推奨システムを使用する。セクション１０．０は、既存のビューを識別し、データブラウジングアプリケーション１２０などのアプリケーションに対して推奨するための推奨システムの使用について説明する。
【０４１３】
利用可能なデータを追跡し、データの定義及びその関係を格納することとは別に、記載する構成は、他のユーザにより作成されたビューからそれまで未知であった関係を習得し、定義済の習得された関係に基づいて関連するデータ構成要素をユーザに対して推奨する。推奨されたデータ構成要素は、ユーザが新規のビューに含めたデータ構成要素の現在のセットへの認識された関連性によりランク付けされる。異なるデータソースの異なる構成要素間のそれまで未知であった関係を習得する意義については、データベースソース及びスプレッドシートを伴う例を参照して以下で簡潔に説明する。
【０４１４】
２つの表Ａ及びＢを有するリレーショナルデータソースを考える。表Ａは列ａ（すなわち、Ａ．ａ）を有し、この列は表Ａの１次キーとして定義される。これは、表Ａのａの各値が一意的であり、各レコードはａの値に基づいて表Ａから一意的に得ることができることを意味する。表Ｂは、表ＢはＡ．ａの形式で格納される値を含む列ａ（すなわち、Ｂ．ａ）を有するように定義される。換言すれば、Ａ．ａ及びＢ．ａは定義済の一次／外部キーの対である。
【０４１５】
ＭＳ Ｅｘｃｅｌ（登録商標）などの表計算アプリケーションを使用して作成されたであろうスプレッドシートＳがあるとする。スプレッドシートＳは、Ａ．ａ及びＢ．ａと等価のフィールドＳ．ａを含む（すなわち、Ｓ．ａ、Ａ．ａ、及びＢ．ａの値は等価又は合同）。Ａ及びＳに関して熟知するユーザを想定し、このユーザが著作権のある報告システム、例えば、結合条件「where A.a = S.ａ」を使用するシステムにおいてビューＶを既に作成していたとする。更に別のユーザがＢのある特定のデータ構成要素、すなわち、Ｂ．ｂを含む新規のビューの作成を希望するものとする。このユーザは、例えばＳ．ｓのような新規のビューに必要な別のデータ構成要素を実際に含むスプレッドシートＳの存在に気づいていない。既存のシステムでは、ＢとＳとの関係は未知である。
【０４１６】
上述の構成では、システムのユーザにより作成されたビュー（上述のＶなど）により確立されたデータ構成要素間（異質なデータソースにまたがる）の関係が追跡・分析・習得される。記載する構成は、ビューＶから表Ｂがデータ構成要素ａを介してスプレッドシートＳと関連することを推論することができる。表Ａが一次／外部キー定義を介して表Ｂに関連することは分かっているので、システムは、スプレッドシートＳもＢに関連しており、新規のビューにおいて使用するためにスプレッドシートＳのデータ構成要素を関連するデータ構成要素としてユーザに対して推奨できることを推定する。
【０４１７】
また、特定の構成は、推奨されたデータ構成要素ごとに必要な結合条件を提示し、推奨されたデータ構成要素をランク付けすることができる。推奨されたデータ構成要素の関連性を計算する際には、間接度、他の結合条件の存在などの他に、一致する１次キー、外部キー、及び結合条件などの要因も考慮される。
【０４１８】
本開示のキーポイントは：
・既存のビューからデータ構成要素間のそれまで未知だった関係を習得することと、
・データ構成要素間の定義済の（例えば、データソースからの指定のキー／外部キー情報）習得された関係に基づいてビューを作成するためにユーザに対して関連するデータ構成要素を推奨することと、
・計算された関連性に従って推奨されたデータ構成要素をランク付けすることとによって異質なデータソースにまたがるビュー作成を支援することにある。
【０４１９】
同様の方法は、ユーザに対して関連するビューを推奨するのにも使用される。この方法についてはセクション１０．０において更に詳細に説明される。ユーザがデータの表示のために適切なビューを選択するのを支援するために、システムは、所要のデータ構成要素におけるユーザの基準に対して既存のビューをランク付けし、関連するビューをユーザに対して推奨する。
【０４２０】
記載する構成では、データブラウジングアプリケーション１２０が使用するようなＸＭＬ対応データソース及びＸＱｕｅｒｙベースビュー定義を使用する。しかし、当業者は、構成が他の非ＸＭＬ対応データソースに対して使用されても、データ定義とＳＱＬを含む問合せ言語との混合を伴って使用されても良いことを認識するであろう。
【０４２１】
高レベルのデータ流れ図が図２３に示され、コンピュータネットワーク（不図示）内で動作可能な推奨モジュール２３００により実行されるデータ推奨プロセスの要約が提供される。スキーマ／ビュー定義アナライザ２３０５は、利用可能なスキーマ２３１５及びビュー定義２３１０を分析し、ここでは習得されたデータモデル２３２０と呼ばれるデータモデルを作成・更新する。習得されたデータモデル２３２０は、既知のデータ構成要素間の関係を獲得する。
【０４２２】
スキーマ／ビュー定義アナライザ２３０５は、新規の又は更新されたビュー定義及び既知のデータソースに対する更新されたスキーマを求めてネットワークを活動的に巡回できるのが好ましい。この巡回プロセスは、配置されたビュー定義の内容を分析することによって情報の新規のソース（データソース及びビュー）を再帰的に検出することを伴うことができる。これらのビュー定義は、推奨モジュール２３００にとってそれまで未知であったデータソース及びビューを識別することができる。また、スキーマ／ビュー定義アナライザ２３０５は、新規の又は更新されたビュー定義及びデータソースに対する更新された指定の通知を他のプロセスから受信しても良い。以降、データソースの指定はスキーマと呼ぶ。データブラウジングアプリケーション１２０により使用される好適な構成では、データソーススキーマは、ＸＭＬスキーマ推奨を使用して表現される。しかし、他のスキーマ表現も可能であることは明らかであろう。
【０４２３】
データソーススキーマにおいて定義されるキーは、習得されたデータモデル２３２０に記録される。データベース用語キーは、データベースシステムに応じて様々に解釈される（例えば、リレーショナルであるか否か。ただし、リレーショナルシステムであっても様々に異なる）。しかし、大半のデータベースシステムは、ユニークキー（指定されたフィールドに対する各値は一意的でなければならない）及び外部キー（ユニークキーへの参照）の概念をサポートする。
【０４２４】
記載する構成では、供給されたデータに存在することも、存在しないこともある１次キー（ユニークキー）と外部キーとの存在を想定する。これらのキー種別が想定されるのは、ＸＭＬスキーマ推奨で実現されるためである。ＸＭＬスキーマ要素名ｋｅｙは、ある特定の要素が一意的であり、供給されたデータに存在しなければならないことを指定するのに使用することができる。要素名ｕｎｉｑｕｅは、ある特定の要素が供給されたデータにおいて一意的（しかし、必ずしも存在しなくても良い）でなければならないことを指定するのに使用することができる。また、ＸＭＬスキーマは、指定された要素の内容が指定されたｋｅｙフィールドの内容と一致しなければならないという表明を許容するｋｅｙＲｅｆ要素を提供する。すなわち、ｋｅｙＲｅｆは外部キーの機能を提供する。他の構成では、異なるキー／外部キー指定を利用できることは明らかであろう。
【０４２５】
ビュー定義の結合条件は、データソーススキーマにおいて指定されていない関係について習得するために分析される。結合についてはセクション６．０において簡潔に説明したが、更に詳細な説明をここで提供する。結合操作は、２つのデータソースからある特定の結合条件を満たす関連するレコードを単一のレコードへと結合するのに使用される。結合条件は以下のような形式である：
【０４２６】
2004240954.tif 000029
【０４２７】
各＜ｃｏｎｄｉｔｉｏｎ＞は、結合属性と呼ばれる２つのデータ構成要素、すなわち、第１のデータソースからの構成要素及び第２のデータソースからの構成要素の値を比較する。例えば、結合条件t1.id = t2.idは、ｔ１及びｔ２がＲＤＢＭＳの表を表す場合、結合属性ｔ１．ｉｄ及びｔ２．ｉｄを伴う単一の条件を有する。
結合条件において使用される比較演算子＝、≠、＜、＞、≦及び≧は、通常、２つのデータソースからの２つのデータ構成要素が関連するか、あるいは、等価（すなわち、意味論的に合同）であることを暗示するが、これは常にそうであるとは限らず、特に、比較演算子＜、＞、≦及び≧に関してそうである。例えば、以下の結合条件：
/corporateDatabase/employeeTable/employee/code
= /myProjectWorksheet.team/member/id
において比較される２つのデータ構成要素が等価であることが予期される場合、以下の結合条件に含まれる２つのデータ構成要素はほとんど関係がない。
/person/numberOfDependents = /person/numberOfPets
習得されたデータモデル２３２０は記憶装置２３７０へと書き込まれる。データは、実行時に情報を効率的に抽出できるように構造化データ（例えば、データベース）として格納されるのが好ましい。しかし、他の格納形態も可能である。例えば、習得されたデータモデル２３２０はＸＭＬ文書へと直列化することもでき、推奨モジュール２３００の開始時にメモリに読み込み、保持することが可能である。
【０４２８】
習得されたデータモデル２３２０の作成に対して取られる習得方法は、図２８のフローチャートの方法２８００により要約される。方法２８００はステップ２８１０で開始される。ステップ２８１０はデータ関係モデルの作成・初期化のソフトウェアエントリポイントである。ステップ２８１５において、ソフトウェアは新規の／更新されたスキーマ２３１０又はビュー定義２３１５を検索し、その通知を受信する。ステップ２８１６は、これ以上通知が検出できないときを検査する。検出できない場合、方法２８００はステップ２８１８で終了する。通知が検出される場合、ステップ２８２０はこの通知がスキーマに関連するか否かを検査する。関連する場合、ステップ２８２５で開始される分岐が実行される。ステップ２８２５において、新規の／更新されたスキーマ定義が解析される。後続するステップ２８３０において、キー／外部キー機能が分析される。この後には、ステップ２８３５における習得されたデータモデル２３２０の更新が続く。この更新はキー／外部キー定義により暗示された等価関係を伴う。ステップ２８２０において検査された通知がスキーマでない場合、これはビュー定義であるので、ステップ２８４０で開始される分岐が実行される。このステップは新規の／更新されたビュー定義を解析し、ステップ２８４５はデータ構成要素間のそれまで未知であった関係に対するビュー定義に含まれる結合条件を分析する。ステップ２８５０は、関係の実在に対する確信度を計算する。ステップ２８５５において、習得されたデータモデル２３２０が更新される。処理されたビューにより参照されるデータソース、ビュー、及びデータ構成要素に関する情報も分析・格納される。ステップ２８３５及び２８５５は、方法２８００をステップ２８１５へと戻し、新規の通知を検索する。従って、習得されたデータモデル２３２０が、生じた種々のデータソーススキーマ及びビューから漸増的に／繰り返し構築されることが図２８により認識されるであろう。
【０４２９】
キー／外部キーの対（スキーマ形式）及び２つのデータ構成要素間の結合（ビュー形式）の存在は、習得されたデータモデル２３２０における２つのデータ構成要素間の等価関係として表現される。習得されたデータモデル２３２０は、等価関係をサポートし、使用される比較演算子を記録する任意のビュー定義への参照を格納する。また、習得されたデータモデル２３２０は、確信度を等価関係と関連付ける。０から１の範囲の値である確信度は、２つのデータ構成要素が等価であるか否かについて推奨モジュール２３００が有する確信の度合を記述する。確信度は、スキーマにおけるキー／外部キーの対として定義されるデータ構成要素に対して１に設定される。一方、ビューの結合操作から習得された関係に対する確信度は、手動で割り当てられるか、あるいは、計算される必要がある。確信度は、図２３のスキーマ／ビュー定義アナライザ２３０５により計算されるのが好ましい。
【０４３０】
確信度は以下の項目に基づいて計算される：
・スキーマにおける２つのデータ構成要素間のキー／外部キー定義の存在、
・２つのデータ構成要素間で使用される結合操作の種別及び任意の関連付けられたビューにおいて結合操作が使用される回数、
・データ構成要素がＸＭＬ文書などの構造化文書のノードである場合、データ構成要素の祖先ノード、同胞ノード、又は子孫ノード間の他の等価関係の存在及びこのような関係の確信度。
【０４３１】
例えば、以下の公式を図２４の例において使用し、確信度（ＣＦ）を計算することができる：
・２つのデータ構成要素がキー／外部キーの対である場合、CF = 1、
・２つのデータ構成要素がキー／外部キーの対でなく、ビュー定義において結合されていない場合、CF = 0、又は、それ以外の場合、CF = min(0.95,(max(0.7,CFm) x 1.05n x 0.5m)
但し、
（ｉ）min関数及びmax関数は、引数の最小値及び最大値を戻し、ＣＦmは２つのデータ構成要素の祖先ノード、同胞ノード、及び子孫ノード間の全ての等価関係の最大確信度であり、
（ｉｉ）ｎは２つのデータ構成要素を比較するのに＝演算子が使用される回数であり、
（ｉｉｉ）ｍは結合操作において２つのデータ構成要素を比較するのにその他の比較演算子が使用される回数である。
【０４３２】
上述の公式は、スキーマにおけるキー／外部キーの対として定義されるデータ構成要素に対しては確信度を１に設定し、キー／外部キーの対ではなく、ビュー定義において結合されていないデータ構成要素に対しては０を設定する。
【０４３３】
２つのデータ構成要素を２回以上比較するのに＝演算子が使用される場合、公式は高い信頼度を付与し（２つのデータ構成要素間の等価関係の存在に対して）、他の演算子が使用される場合には確信度を急速に下げる。２つのデータ構成要素が構造化文書の一部であり、等価関係がその祖先ノード、同胞ノード、又は子孫ノード間に既に存在する場合、このような関係の最大確信度は確信度を計算するためのベースとして使用される。
【０４３４】
既存のビュー又はスキーマが修正又は削除されるか、あるいは、新規のビューがシステムへと追加されるたびに、変更による影響を受ける等価関係の確信度が再計算される。
【０４３５】
図２４は、例示の習得されたデータモデル２３２０の適合したＥ−Ｒ図を示す。エンティティ及び（エンティティの）属性の双方は、有効なデータ構成要素である。実際、エンティティは複合のデータ構成要素と見なされる。従来のＥ−Ｒ図のように２つの関連するエンティティを連結することにより関係を表現するのではなく、図２４は実際に連結を提供する２つのエンティティの（場合によっては複合の）属性を連結することによって等価関係を表現する。１次キーエンティティには下線が引かれている。例では、データベース２４００は３つのエンティティ、すなわち、ｐｒｏｊｅｃｔ２４０２、ｅｍｐｌｏｙｅｅ２４０４、及びｄｅｐａｒｔｍｅｎｔ２４０６を定義する。エンティティｐｒｏｊｅｃｔ２４０２は、１次キーｃｏｄｅ２４１２及び別の属性ｎａｍｅ２４１４を有する。エンティティｅｍｐｌｏｙｅｅ２４０４は、一次キーｉｄ２４２２、属性ｎａｍｅ２４２４及び属性ｄｅｐａｒｔｍｅｎｔ２４２６（従業員が勤務する部署のコードを格納する）、及び従業員が携わるプロジェクトのコードを格納する多値属性ｐｒｏｊｅｃｔ２４２８を有する。エンティティｄｅｐａｒｔｍｅｎｔ２４０６は、一次キーｃｏｄｅ２４３２と、属性ｎａｍｅ２４３４及び属性ｌｏｃａｔｉｏｎ２４３６とを有する。図２４の例では、ｄｅｐａｒｔｍｅｎｔ／ｃｏｄｅ及びｅｍｐｌｏｙｅｅ／ｄｅｐａｒｔｍｅｎｔのみならずｐｒｏｊｅｃｔ／ｃｏｄｅ及びｅｍｐｌｏｙｅｅ／ｐｒｏｊｅｃｔもデータベーススキーマにおける一次／外部キーの対として定義される。１のｃｏｎｆｉｄｅｎｃｅを有する等価関係（２４４０及び２４４２）は、このキーの対の各々と関連付けられている。
【０４３６】
また、図２４は、別のデータソースであるスプレッドシート２４６０を示す。スプレッドシート２４６０は、属性ＩＰ＿ａｄｄｒｅｓｓ２４７２、属性ｎａｍｅ２４７４、属性ｄｅｐａｒｔｍｅｎｔ２４７６（機械が配置される部署のコードを格納する）、及び属性ｏｓ２４７８（機械のオペレーティングシステムを識別する）を有するエンティティｍａｃｈｉｎｅ２４７０を定義する。スプレッドシート２４６０のｍａｃｈｉｎｅ２４７０とデータベース２４００のエンティティｄｅｐａｒｔｍｅｎｔ２４０６との関係は定義済ではなく、図２５のビュー定義２５００から推論されている。ビュー定義２５００におけるＸＱｕｅｒｙ述語［ｄｅｐａｒｔｍｅｎｔ＝＄ｄｅｐｔ］は、スプレッドシート２４６０の／ｍａｃｈｉｎｅ／ｄｅｐａｒｔｍｅｎｔがデータベース２４００の／ｄｅｐａｒｔｍｅｎｔ／ｌｏｃａｔｉｏｎ／ｃｏｄｅと等価であることを暗示する。
【０４３７】
等価関係２４８０は、２つのデータ構成要素ｍａｃｈｉｎｅ／ｄｅｐａｒｔｍｅｎｔ２４７６及びｄｅｐａｒｔｍｅｎｔ／ｃｏｄｅ２４３２をリンクするために追加される。システムは関係の実在を完全に確信している訳ではないので、この場合、ｃｏｎｆｉｄｅｎｃｅ２４９０は０．６３として計算されている。関係２４８０は、関係が定義済ではなく習得されたものであることを強調するために図２４の破線により示される。関係２４８０は、２つのデータ構成要素の結合の際に使用されるｃｏｍｐａｒｉｓｏｎ ｏｐｅｒａｔｏｒ（比較演算子）２４９６のみならず関係の存在を暗示する各ビュー２４９２へのｒｅｆｅｒｅｎｃｅ（参照）２４９４を保持する。
【０４３８】
推奨モジュール２３００は、図２３の習得されたデータモデル２３２０を使用して利用可能なデータソースについて限られた知識しか持たない平均的なユーザが新規のビューを作成するのを支援する。１セットの所要のデータ構成要素２３３０がユーザから得られる。所要のデータ構成要素２３３０を指定する際には、ブール演算子（ａｎｄ、ｏｒ）のセットが使用されても良い。データ要求プロセッサ２３３５は、習得されたデータモデル２３２０を使用して所要のデータ構成要素のセットに関連するデータ構成要素を検索する。
【０４３９】
データ要求プロセッサ２３３５及びデータランク付けプロセッサ２３４５は、図２９のフローチャートに示される方法２９００により要約されるソフトウェアに従って動作する。方法２９００はステップ２９１０で開始される。ステップ２９１０において、ユーザの所望のビューの形成元であるデータ構成要素のセット２３３０が得られる。ステップ２９２０では、習得されたデータモデル２３２０において関連するデータ構成要素を検索する。
【０４４０】
複数の関連するデータ構成要素２３４０が見つけられ、データランク付けプロセッサ２３４５へと渡される。データランク付けプロセッサ２３４５は、データ構成要素の所要のデータ構成要素のセット２３３０への関連性を計算し、それに従ってデータ構成要素をランク付けする。ステップ２９５０において、関連するデータ構成要素のランク付けされたリスト２３５０が選択のためにユーザへと戻される。ユーザは、推奨されたデータ構成要素を所要のデータ構成要素のセット２３３０へとリンクするのに必要な結合条件に反しない限り、推奨されたデータ構成要素の祖先、子孫、又は同胞へと移動し、これを選択できるのが好ましい。
【０４４１】
関連するデータ構成要素のランク付けされたリスト２３５０の使用は、リストを受信するアプリケーション又はプロセスによって決まる。セクション８．０では、データブラウジングアプリケーション１２０が関連するデータ構成要素のランク付けされたリスト２３５０を使用して新規のデータビューを作成する方法を説明した。この場合、ユーザは、推奨されたデータ構成要素の子孫間及び場合によっては祖先間を移動し、新規のデータビューに対するデータ構成要素を選択することができる。しかし、データ構成要素のユーザの選択は、新規のデータビューの表示種別意味体系に反したものとすることはできない。
【０４４２】
所要の結合条件は、推奨されたデータ構成要素を伴って戻されるであろう。好適な構成では、戻された結合条件は、データブラウジングアプリケーション１２０が新規のデータビューの問合せを構築するのに使用する。また、ユーザは、結合条件のテキストを直接編集するか、あるいは、何らかのグラフィカルユーザインタフェースを介して結合条件を修正することを許容されても良い。
【０４４３】
データ構成要素の所要のデータ構成要素のセット２３３０への関連性は、以下の要因の全て又はサブセットに基づいて計算されるのが好ましい：
（ａ）データソースは１次キー又は外部キーを介して直接的に関連するか否か、
（ｂ）データソースは他の１次キー／外部キー、結合条件、及び間接度を介して間接的に関連するか否か、
（ｃ）データ構成要素はデータソースを直接的に又は間接的にリンクする一次キー又は外部キーの一部を構成するか否か、
（ｄ）データ構成要素を直接的に又は間接的にリンクする等価関係の確信度、
（ｅ）データ構成要素の同胞、祖先、又は子孫が、データ構成要素を直接的に又は間接的にリンクする一次キー又は外部キーの一部を構成するか否か、
（ｆ）データ構成要素が結合属性である関連付けられたビューにおける結合条件、
（ｇ）データ構成要素が結合属性でない（ｆ）に記載したビューにおける他の結合条件、
（ｈ）既存のビューにおけるデータ構成要素と所要のデータ構成要素のサブセットとの共出現の相対頻度、及び
（ｉ）データ構成要素が利用可能なデータの量（データに関する統計値が利用可能な場合）
上述の要因の一部では、図２３のビュー上の統計値２３５５及びデータ上の統計値２３６０が収集され、推奨モジュール２３００にとって利用可能になることが必要である。大半のデータベースは格納するデータに関する統計値を提供するが、システムは非データベースソース自体からのデータ上の統計値を収集しなければならないであろう。
【０４４４】
図２４の例を使用して、ユーザが新規のビューを作成し、プロジェクトによる機械の使用を要約することを希望する場合を想定する。既存の報告システムでは、通常、ユーザは所望の要約を作成するのにスプレッドシート２４６０のｍａｃｈｉｎｅ２４７０とデータベース２４００のｄｅｐａｒｔｍｅｎｔ２４０６との間に存在する関係を利用することができない。スプレッドシートが報告システムの外部で作成される場合、この関係は既知ではないからである。しかし、ここで記載する構成では、データベース２４００とスプレッドシート２４６０との関係についての知識を有する別のユーザにより先に作成された図２５のビュー２５００と関連付けられた問合せにより暗示される関係を追跡・習得することができる。ユーザが新規のビューに対するデータベース２４００からｐｒｏｊｅｃｔ２４０２の属性ｃｏｄｅ２４１２を使用することを選択した後、モジュール２３００は、ｅｍｐｌｏｙｅｅ２４０４、ｄｅｐａｒｔｍｅｎｔ２４０６、ｍａｃｈｉｎｅ２４７０が関連していることをユーザに対して暗示し、関係に対するリンクを提供するデータ構成要素（すなわち、ｐｒｏｊｅｃｔ２４０２のｃｏｄｅ２４１２、ｅｍｐｌｏｙｅｅ２４０４のｐｒｏｊｅｃｔ２４２８及びｄｅｐａｒｔｍｅｎｔ２４２６、ｄｅｐａｒｔｍｅｎｔ２４２６のｃｏｄｅ２４３２、及びｍａｃｈｉｎｅ２４７０のｄｅｐａｒｔｍｅｎｔ２４７６）を示すであろう。ユーザが正しいデータ構成要素を選択するのを支援するために、ｅｍｐｌｏｙｅｅ２４０４、ｄｅｐａｒｔｍｅｎｔ２４０６、及びｍａｃｈｉｎｅ２４７０は計算された関連性に従ってランク付けされる。ｅｍｐｌｏｙｅｅ２４０４及びｄｅｐａｒｔｍｅｎｔ２４０６は、ｍａｃｈｉｎｅ２４７０よりも高くランク付けされるであろう。これは、主として、ｅｍｐｌｏｙｅｅ２４０４及びｄｅｐａｒｔｍｅｎｔ２４０６が（定義済のキー／外部キーの対を介して）１の信頼度を伴ってより直接的にｐｒｏｊｅｃｔ２４０２に関連しているためである。これに対して、ｍａｃｈｉｎｅ２４７０は、既存のビュー２４６０、ｄｅｐａｒｔｍｅｎｔ２４０６、及びｅｍｐｌｏｙｅｅ２４０４を介して０．６３の信頼度を伴って間接的にｐｒｏｊｅｃｔ２４０２に関連していることが知られている。所要の結合条件（ＸＱｕｅｒｙ形式で表現）は以下の通りである：
for $prj in distinct?values(document("HumanResourcesDB")/project/code)
let $dept :=
document("HumanResourcesDB")/employee[project=$prj]/department
let $mc := document("MachineSpreadsheet")/machine[department=$dept])
この例では、ユーザはｍａｃｈｉｎｅ２４７０のデータ構成要素に関心がある。ユーザは、新規のビューに含めるためにｍａｃｈｉｎｅ２４７０のｎａｍｅ２４７４へと移動し、これを選択する。これが許容されるのは、所要の結合条件が不変であるからである。好適な構成では、データブラウジングアプリケーション１２０は、選択されたデータ構成要素及び所要の結合条件を使用して図２６に示す問合せ２６００を構築する。
【０４４５】
１０．０  データビューを推奨する方法
本開示の別の面は、平均的なユーザがそのデータ必要条件に非常に厳密に一致する既存のビューを選択するのを支援することである。この特徴は、修正のために既存のビューを選択するのにも使用することができる。高レベルブロック図が図２７に示され、好適な構成のビュー推奨プロセスの概要が提供される。
【０４４６】
システムは、習得されたデータモデル２７２０（図２３の習得されたデータモデル２３２０と同じ）を使用して利用可能なビューについて限られた知識しか持たないユーザがユーザのデータ必要条件に最も良く適合する既存のビューを選択するのを支援する。１セットの所要のデータ構成要素２７３０がユーザから得られる。所要のデータ構成要素２７３０を指定する際には、ブール演算子（ａｎｄ、ｏｒ）のセットが使用されても良い。ビュー要求プロセッサ２７３５は、習得されたデータモデル２７２０を使用して所要のデータ構成要素の全て又はサブセットを含むビューを検索する。所要のデータ構成要素の祖先、子孫、又は同胞を含むビューも考慮される。ビュー要求プロセッサ２７３５により見出された関連するビュー２７４０がビューランク付けプロセッサ２７４５へと渡される。ビューランク付けプロセッサ２７４５は、ビューの所要のデータ構成要素のセット２７３０への関連性を計算し、それに従ってビューをランク付けする。ビューのランク付けされたリスト２７５０が選択のためにユーザへと戻される。
【０４４７】
推奨モジュール２７００により実行されるビューを推奨する方法は、図３０のフローチャートにおいて要約される。方法３０００はステップ３０１０で開始される。ステップ３０１０において、ソフトウェアはユーザが必要とする１セットのデータ構成要素を取得する。次に、ステップ３０２０において、ソフトウェアは所要のデータ構成要素２７３０の全て又はサブセットを含むビュー２７１０を検索する。ビュー要求プロセッサ２７３５は、ステップ３０３０に従って、所要のデータ構成要素２７３０のいずれかの祖先ノード、子孫ノード、又は同胞ノードを含むビュー２７４０を検索する。ビューランク付けプロセッサ２７４５により実行されるステップ３０４０では、ビューがどの程度所要のデータ構成要素のセット２７３０と一致するかに従ってビュー２７４０をランク付けする。最後に、ステップ３０５０において、プロセッサ２７４５は、ランク付けされたビューをリスト２７５０として選択のためにユーザに対して提示し、直接含まれる所要のデータ構成要素の数を示す。
【０４４８】
好適な構成では、ビューの所要のデータ構成要素のセット２７３０への関連性は、以下の要因の全て又はサブセットに基づいて計算される：
（ａ）ビューは所要のデータ構成要素の全て又はサブセットを含むか否か、
（ｂ）ビューは所要のデータ構成要素のいずれかの同胞、祖先、又は子孫を含むか否か、
（ｃ）所要のデータ構成要素を除く他のデータ構成要素の数、
（ｄ）データ構成要素のセットを結合するのに必要な結合条件、
（ｅ）ビューにより指定される他の結合条件、及び
（ｆ）ビューが使用される相対頻度（ビュー提示アプリケーションにより統計値が収集される場合）
最後の要因では、ビュー上の使用統計値２７５５が収集され、システムに対して利用可能にされる必要がある。
【０４４９】
一例として、システムが図２５及び図２６において定義される２つのビューのみを含むものとする。ユーザが所要のデータ構成要素として図２４のｍａｃｈｉｎｅ／ｎａｍｅ２４７４を指定する場合、図２５のビュー２５００及び図２６のビュー２６００の双方が戻され、ビュー２６００はビュー２５００よりも高くランク付けされる。これは、ビュー２６００がデータ構成要素ｍａｃｈｉｎｅ／ｎａｍｅ２４７４を含むのに対し、ビュー２５００はその同胞のｍａｃｈｉｎｅ／ｏｓ２４７８のみを含むからである。別の例として、ユーザが所要のデータ構成要素としてｍａｃｈｉｎｅ／ｎａｍｅ２４７４及びｐｒｏｊｅｃｔ／ｎａｍｅ２４１４を指定する場合、ビュー２６００のみが戻される。これは、ビュー２５００がｐｒｏｊｅｃｔ／ｎａｍｅ２４１４も、その同胞、祖先、又は子孫も含まないからである。更に別の例として、ユーザがｄｅｐａｒｔｍｅｎｔ／ｎａｍｅ２４３４又はｐｒｏｊｅｃｔ／ｃｏｄｅ２４１２を指定する場合、ビュー２５００及びビュー２６００の双方が戻され、ビュー２６００はビュー２５００よりも高くランク付けされる。これは、ビュー２６００がデータ構成要素ｐｒｏｊｅｃｔ／ｃｏｄｅ２４１２を含むのに対し、ビュー２５００はｄｅｐａｒｔｍｅｎｔ／ｎａｍｅ２４３４の同胞であるｄｅｐａｒｔｍｅｎｔ／ｌｏｃａｔｉｏｎ２４３６を含むからである。
【０４５０】
システムは、各データソース（スキーマにより定義）を暗示的なビューを有するものと見なし、ビューを推奨する際にユーザが定義した全ての明示的なビューに加えてこれらの暗示的なビューを考慮しても良い。この場合、ユーザが所要のデータ構成要素としてｍａｃｈｉｎｅ／ｎａｍｅ２４７４を指定する場合、ビュー２５００及びビュー２６００のみならずｍａｃｈｉｎｅ２４７０の暗示的なビューもランク付けされ、選択のために戻されるであろう。
【０４５１】
また、システムは関連するビューを修正して、ユーザに対して推奨するためにデータの新規のビューを自動的に作成しても良い。１つの方法は、関連するビューの結合条件が有効である限り、同胞、祖先、又は子孫ではなく、ユーザが指定したデータ構成要素自体を使用することである。別の方法は、ユーザが指定したデータ構成要素のセットを取得するのに不要な結合条件を関連するビューから削除することによるものである。
【０４５２】
１１．０  マッピングセットの漸増的な拡大
新規のデータビュー及びその関連付けられたマッピングを作成するのには時間がかかる。このため、ユーザがデータビュー及びその関連付けられたマッピングを共有できるのが非常に望ましい。この共有プロセスは、更に、ユーザが共有のデータビューにおいて見出すマッピングを独自のブラウジング環境へと追加できることを必要とする。データブラウジングアプリケーション１２０は、ユーザが共有のデータビューにおいて見出したマッピングをインポートすることによってマッピングをマッピングセットへと漸増的に追加する手段を提供する。換言すれば、データビューの共有は、更なるデータビューの作成に使用されるマッピングセットを漸増的に改良するためのメカニズムとして使用することができる。
【０４５３】
このプロセスは、データビュー定義が直列化可能であると共に、他のユーザと共有可能であることを必要とする。これらのデータビューは、スキーマビュー（セクション２．０において説明）を使用して作成されても、既存のデータビュー（セクション６．０及び７．０において説明）からグラフィカルに得られても良い。データブラウジングアプリケーション１２０は、データビューを他のユーザとの交換に適したＸＭＬ形式へと直列化する手段を提供する。これらのデータビュー定義文書に対する好適な直列化構文は、付録ＡのＸＭＬスキーマにより定義される通りである。
【０４５４】
直列化されたデータビュー定義は、データビューにより使用される任意のマッピングを含む。これらのマッピングは、他のデータビューから継承されるマッピングと特にデータビューに対して作成されるマッピングとを含む（セクション６．０において説明）。ユーザが、本開示の前の各セクションで説明した方法を使用してデータビューを作成する際に、マップされたデータ構成要素を使用することを選択する場合、前者の部類のマッピングはデータビューに関連するようになる。
【０４５５】
マッピングは、構造的構成要素及び提示構成要素へと分解され、Ｗ３ＣのＸＳＬＴ（Extensible StyleSheet Language Transformations）バージョン２．０（http://www.w3.org/TR/xslt20/を参照）を使用して直列化されるのが好ましい。この直列化プロセスにより、データビュー定義文書における構造的構成要素及び提示構成要素ごとに単一の変換ブロック（「＜ｘｓｌ：ｔｒａｎｓｆｏｒｍ＞」タグにより囲まれる）が得られる。構造的構成要素は、データビュー定義のＱｕｅｒｙ要素内にブロックとして格納されるが、提示構成要素はＰｒｅｓｅｎｔａｔｉｏｎ要素に格納される。ＸＳＬＴを使用してマッピングを直列化する利点は、受信するデータブラウジングアプリケーション１２０が標準ＸＳＬＴプロセッサを使用して受信するＸＭＬデータ上で所要の変換を実施できることである。ＸＳＬＴを使用することの更なる利点は、データブラウジングアプリケーション１２０以外のアプリケーションが変換を容易に利用できることである。
【０４５６】
データブラウジングアプリケーション１２０は、提示特性を追加する前に変換されたＸＭＬを生成するのが好ましいので、構造的構成要素及び提示構成要素は、別々の変換ブロックへと直列化される。また、マッピングを使用する一部のアプリケーションは、マッピングの提示構成要素及び構造的構成要素のいずれかにのみ関係しているであろう。
【０４５７】
代替の構成では、マッピングは専用に設計された構文を使用して直列化することができるだろう。構文はＸＭＬベースであることが望ましいが、必ずしもそうでなくても良い。更なる変形例では、直列化される情報の単位は、ワークシート又はデータビューの集合であっても良い。この場合、直列化された文書のデータビュー定義構成要素は、付録Ａに含まれる例とほぼ変わらないようにすることもできる。
【０４５８】
データビュー定義を直列化するプロセスについて図９Ａの方法９００を参照して説明する。方法９００は、データブラウジングアプリケーション１２０の一部として実現されても良い。データブラウジングアプリケーション１２０は、プロセッサ１１０５により実行され、例えば、記憶装置１１０９から供給され、場合によってはディスプレイ１１１４へと出力されるであろう。ステップ９０２において、方法９００は保存又は直列化するデータビューのユーザ選択を検出する。これは、図１２Ａに示すようなＧＵＩのワークスペース１２０２において現在選択されているデータビューであるのが好ましい。ステップ９０４において、データビューの定義へと直列化される必要があるので、データビューにより使用される任意のマッピングが識別される。ステップ９０６において、各マッピングが構造的構成要素及び提示構成要素へと分解される。ステップ９０８及び９１０において、全ての関連するマッピングの構造的構成要素及び提示構成要素が、それぞれ、単一の構造的ＸＳＬＴ変換ブロック及び提示ＸＳＬＴ変換ブロックへと直列化される。
【０４５９】
ステップ９１２において、データビューに対する問合せが直列化される。この問合せは、作成・修正される際に徐々にデータビューに対して維持管理されるのが好ましい。問合せは、データブラウジングアプリケーション１２０においてＸＱｕｅｒｙ表現として表現されるのが好ましく、データビューに対するソースデータ構成要素を取得する方法を定義する。このため、例えば、このＸＱｕｅｒｙは、２つ以上のデータソースにまたがる結合を実行する方法を指定しても良い。好適な構成では、セクション７．０において説明した問合せツリー構造は、ＸＱｕｅｒｙＸ ＸＭＬ形式へと直列化される。代替の構成では問合せを文字列として直列化しても良い。
【０４６０】
ステップ９１４において、ＸＱｕｅｒｙ、構造的変換ブロック、及び提示変換ブロックがＸＭＬファイルへと書きこまれ、保存される。プロセスはステップ９１６で終了する。
【０４６１】
ユーザが別のユーザから受信したデータビューを見ることを選択する場合、好ましくは、変換操作、名前変更操作、及び結合操作が問合せに組み込まれているので、ユーザは受信したデータビューのマッピングにより変換されたデータを直ちに見る。必要に応じて、ユーザは、独自のビューイング環境と関連付けたマッピングを適用することを選択しても良い。受信したデータビューを見るプロセス９４０について図９Ｂを参照して説明する。プロセス９４０は、ステップ９５０において、受信したデータビューを見るユーザ選択を検出することによって開始される。このデータビューは、ウェブサイトから取得されたものであっても、電子メールを介して取得されたものであっても、あるいは、データビューリポジトリから取得されたものであっても良い。また、ワークスペースとして保存されたデータビューの集合の一部として受信されたものであっても良い。ステップ９５２において、受信したデータビューは含まれるマッピングを使用して処理される。この処理は、データビューの定義の一部として定義された問合せを使用して１つ以上のデータソースからデータを収集することを伴う。このプロセスは図３１Ａに示されている。マッピングがデータビューに対して存在する場合、ソースデータは含まれるマッピングに従って変換され、その結果、ステップ９５２において、データビューが、セクション５．０において説明した方法を使用してユーザに対して提示される。
【０４６２】
ステップ９５４において、ユーザは、ユーザの独自のマッピングセット内に存在するであろう他の関連するマッピングを適用すべきか否かを尋ねられる。表示可能な関連するマッピングが存在しない場合、このプロンプトは表示されないのが好ましい。ユーザが、既に蓄積した他の関連するマッピングを適用することを選択する場合、受信したデータビューのマッピングがユーザのマッピングセットへと追加されていた場合に生じたであろうマッピングのセットを使用してデータビューが再生される。ステップ９５６に示すように、新規のマッピングがユーザの現在のセットの末尾へと追加され、ユーザの既存のマッピングの後に適用される。このステップは、データビューの問合せへと統合されたマッピングが、ユーザの改正されたマッピングセットがデータに適用される前に、まず反転されなければならないことを意味する。代替の構成では、データビューのマッピングを保存されたＸＱｕｅｒｙへと統合しなくても良い。ステップ９５６の結果を提示する際に、ユーザは前に生成されたデータビューへと戻ることを選択しても良い。
【０４６３】
ステップ９５８において、ユーザはデータビューのマッピングをマッピングセットへと追加すべきか否かを尋ねられる。ユーザがこのプロンプトに対して肯定的に応答する場合、ステップ９６０において、受信したデータビューからのマッピングがユーザのマッピングセットへと同化される。プロセスはステップ９７０で終了する。ステップ９５６において、ユーザが既存のマッピングを適用しないことを選択する場合、プロセスはステップ９７０で終了する。代替の実現例では、ユーザは、データブラウジングアプリケーション１２０のプリファレンス又は設定として図９Ｂの２つのプロンプトに対するデフォルトの応答を指定しても良い。
【０４６４】
デフォルトの同化は、新規のマッピングを直列化された順序で既存のマッピングセットの末尾へと追加することによって達成されるのが好ましい。これは、既存のマッピングが適用された後に新規のマッピングが適用されることを示す。これが適切でない場合もあるが、その場合、ユーザはデータブラウジングアプリケーション１２０を使用してマッピング規則の優先度を変更することができる。マッピングセットの全てのマッピングをマッピング適用順のシーケンスで見ることができる機能が提供される。ユーザは、マッピングが適用される順序の変更を実施するために、特定のマッピングを選択し、優先度シーケンスリストを上下にドラッグすることができる。マッピングを選択し、削除キーを押下することによって、不適切なマッピングをマッピングセットから削除することもできる。
【０４６５】
直列化マッピング定義は、マッピングの目標データ構成要素に対してｓｃｈｅｍａＬｏｃａｔｉｏｎヒントを含むのが好ましい。ｓｃｈｅｍａＬｏｃａｔｉｏｎヒントが提供されておらず、データブラウジングアプリケーション１２０が目標データ構成要素に対する定義を探す場合には（例えば、スキーマビューの作成のため）、データブラウジングアプリケーション１２０は目標データ構成要素のネーム空間に対する定義を含むスキーマを探すように試みなければならない。
【０４６６】
データブラウジングアプリケーション１２０内で、ユーザのマッピングセットのマッピングが、例えば、ＨＤＤ１１１０により保持されるリレーショナルデータベースの表に格納される。代替の記憶構成も使用可能であるが、明らかに、ソースデータ構成要素名及び目標データ構成要素名を介した迅速な検索を可能にする形式でマッピングを格納するのが好ましい。例えば、スキーマビューを作成する際には、ソースデータ構成要素名に基づいて関連するマッピングを配置する必要がある。しかし、データビューを直列化しなければならない場合、関連するマッピングを目標構成要素名に基づいて識別する必要がある。
【０４６７】
１２．０  スタイルシートで使用される変換の推定
本開示の代替の使用は、ＸＭＬ文書に対するスタイルシートを生成する問題に適用される。多くのウェブサイトの実現では、ブラウザでの表現のためにＸＭＬ文書を再利用することが慣習になっている。この再利用は、構造化変換を実行すること及び／又は提示特性を元のＸＭＬデータへと追加することを伴うことができる。所要の変換を指定する最も一般的な方法は、ＸＳＬＴを使用してＸＭＬスタイルシートを設計することである。
【０４６８】
ウェブサイトを実現する組織が直面する１つの問題点は、通常、グラフィックデザイナーが情報を提示する方法の設計を選択する人物だということである。このデザイナーは、ウェブページ（通常、ＨＴＭＬ）オーサリングツールを使用して所望の提示の例示のページを作成する。この例示のページは、スタイルシートを作成するためのプログラミング技術においてより熟練した人物へと委ねられる。スタイルシートは、グラフィックデザイナーの例示のページにより示されるように提示するために、ＸＭＬデータソースにおけるデータをどのように変換しなければならないかを定義する。
【０４６９】
この変換は、ＸＭＬソースにおける複数のデータフィールド上で数値演算を実行すること（例えば、四半期ごとの売上値の合計から今年のそれまでの売上値を生成）及び／又は提示特性を種々のデータフィールドへと適用することを伴っても良い。グラフィックアーティストは、このような変換の一部に不満を感じないかもしれないが、ＸＳＬＴスタイルシートにおいて一般的に使用される多くの構造的変換は、アーティストにとっては直観的ではないと思われる。アーティストが一般的にスタイルシートを作成しない他の理由は、ＸＳＬＴ変換言語が複雑であり、ＸＭＬ及び関連する標準（例えば、ＸＭＬネーム空間）の本質的な理解を必要とする可能性があるからである。上述の作業慣例から、スタイルシートを構成するＸＭＬを書かずにＸＳＬＴスタイルシートをグラフィカルに生成することが可能なツールをグラフィックアーティストに対して提供するのが望ましい。このようなオーサリング環境は、有利なことに、テキスト的にではなく、グラフィカルに所要の変換を定義する手段を提供する。主に本開示のセクション３．０及び４．０において説明したように、所要の変換の例に基づく実証は、このプロセスにおいて必要なリンクを提供することができる。この代替の実現例では、所望の変換を目標名と関連付ける必要はない。
【０４７０】
好適なスタイルシートオーサリング環境は、既存のオーサリング環境（例えば、Ｎｅｔｓｃａｐｅ Ｃｏｍｐｏｓｅｒ）のように実現されても良い。グラフィックデザイナーは、馴れている方法を使用してウェブページの外観（例えば、ページの色、フレームの存在など）を定義しても良い。グラフィックデザイナーは、主にマッピング変換の定義に関して説明したように、ＸＭＬデータを選択することができる。１つ以上のデータソースを選択しても良い。データソースと関連付けられたデータが、アクセス可能なファイルシステム上に格納された静的なＸＭＬ文書に既に存在しても良い。また、データソースにより表現されたデータはデータベースに格納され、必要に応じてＸＭＬを使用して表現することが可能であっても良い。
【０４７１】
デザイナーが選択されたソースから関心の対象のデータ構成要素を選択すると、データの例のリストが表示される。この例のリストは、データが格納される方法をデザイナーに対して示すので、それ自体有用である。デザイナーは、１つの例を選択し、提示形式に必要とされるように編集することができる。先に説明した推定方法を使用して暗示的な変換を予測することができる。推定された変換の結果は、更新された例のリストによりデザイナーに対して伝達することができる。変換の改良は、先に説明したように実行することができる。
【０４７２】
スタイルシート設計プロセスの出力は、ＸＳＬＴスタイルシートである。このスタイルシートは、システムがＸＭＬ文書に対してサーバー上でＸＳＬＴ変換を実行することによって、提示可能な内容（ＸＭＬ、あるいは、現在より一般的なＨＴＭＬ）を生成するのに使用することができる。また、ＸＭＬ処理及びＸＳＬＴ処理をサポートするブラウザアプリケーションが増加しているので、内容の提示可能な形式をクライアント側で生成することができる（すなわち、ユーザ端末で稼動中のＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（登録商標）ブラウザアプリケーション又はＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）ブラウザアプリケーション）。
【０４７３】
グラフィックアーティストにより使用可能なこのようなスタイルシートオーサリングシステムを提供することの主な利点の１つは、ブラウザによりユーザに対して提示される情報に変更が必要になっても、グラフィックデザイナーがその変更を実施するだけで良いことである。現在のシステム及び作業慣例では、提示可能な内容に変更がある場合には、それがどれ程小さいものであっても、通常、グラフィックデザイナー及びスタイルシート作成者の双方を巻き込むことになる。これは、変更の実現に大変な費用がかかることを意味する。
【産業上の利用可能性】
【０４７４】
各構成で説明した以上の内容は、データベースに適用可能であると共に、このようなデータベースにより保持されるデータ（例えば、コンピュータ及びデータ処理産業含む）へのビューイングアクセスを促進するための構成にも適用可能である。
【０４７５】
前述の説明では、本発明の幾つかの実施例のみを説明しているが、本発明の趣旨から逸脱することなく、変形及び／又は変更を行なうことができる。各実施例は例示のためのものであり、本発明を限定するものではない。
【０４７６】
付録Ａ
この付録は、ビューの定義をもたらすＸＭＬコードの一例を提供する。
【０４７７】
2004240954.tif 000030
2004240954.tif 000031
2004240954.tif 000032
2004240954.tif 000033
2004240954.tif 000034
2004240954.tif 000035
2004240954.tif 000036
2004240954.tif 000037
【図面の簡単な説明】
【０４７８】
【図１】ここに記載した構成の動作環境を示すブロック図である。
【図２】スキーマビューのソース構成要素が目標ビュー構成要素へとマップされる方法を示す概略図である。
【図３】ユーザに対するスキーマビューを作成するプロセスを記述するフローチャートである。
【図４】ＸＭＬスキーマを用いて表現されるデータを使用してスキーマビューが形成される方法を記述したフローチャートである。
【図５】マッピング作成プロセスを記述するフローチャートである。
【図６】選択された複数のデータソースにわたるスキーマビューを作成するために使用される典型的な画面レイアウトを示す概略図である。
【図７Ａ】新規のマッピングを作成するのに使用される画面レイアウトを概略的に示す図である。
【図７Ｂ】新規のマッピングを作成するのに使用される画面レイアウトを概略的に示す図である。
【図７Ｃ】新規のマッピングを作成するのに使用される画面レイアウトを概略的に示す図である。
【図８】ユーザが編集した例を使用して変換を推定する１つの構成を使用したプロセスを記述するフローチャートである。
【図９Ａ】直列化するプロセス及びマッピングを受信するプロセスをそれぞれ記述するフローチャートである。
【図９Ｂ】直列化するプロセス及びマッピングを受信するプロセスをそれぞれ記述するフローチャートである。
【図１０Ａ】マッピングがスキーマビューにどのように作用することができるかを概略的に示すフローチャートである。
【図１０Ｂ】マッピングがスキーマビューにどのように作用することができるかを概略的に示すフローチャートである。
【図１０Ｃ】マッピングがスキーマビューにどのように作用することができるかを概略的に示すフローチャートである。
【図１１】記載した構成で使用されるであろうコンピュータシステムの概略ブロック図である。
【図１２Ａ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１２Ｂ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１２Ｃ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１２Ｄ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１２Ｅ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１２Ｆ】グラフィカルユーザインタフェース（ＧＵＩ）を使用して新規のデータビューを作成する例示の実現を示す図である。
【図１３Ａ】ユーザが新規の変換操作又は結合操作を定義可能な一連のＧＵＩを示す図である。
【図１３Ｂ】ユーザが新規の変換操作又は結合操作を定義可能な一連のＧＵＩを示す図である。
【図１３Ｃ】ユーザが新規の変換操作又は結合操作を定義可能な一連のＧＵＩを示す図である。
【図１４】１つ以上の既存のデータ構成要素に基づく推奨を使用する複数の異質なデータベースにまたがるデータビューの視覚的作成を示すフローチャートである。
【図１５】棒グラフ表示種別に対する表示テンプレートの一例を示す図である。
【図１６】図１４の方法への代替のアプローチを示すフローチャートである。
【図１７】表示テンプレートの別の例を示す図である。
【図１８】図１５のテンプレートから形成される完了した棒グラフを示す図である。
【図１９】２次元（２Ｄ）グリッド表示テンプレートのグリッド単位を示す図である。
【図２０】図１９のテンプレートを使用して形成される例示のデータビューを示す図である。
【図２１】図２０のテンプレートから形成される最終データビューの一例を示す図である。
【図２２】推奨を生成する方法を示すデータ流れ図である。
【図２３】ビュー構築のための推奨データ構成要素に使用されるデータ推奨プロセスのデータ流れ図である。
【図２４】データ推奨プロセスを実証するのに使用される例示のスキーマの適合したＥ−Ｒ図である。
【図２５】習得プロセスを実証するのに使用されるデータビューと関連付けられた例示のＸＱｕｅｒｙを示す図である。
【図２６】データ推奨プロセスが作成を支援するデータビューと関連付けられた例示のＸＱｕｅｒｙを示す図である。
【図２７】データビューを推奨するのに使用されるデータビュー推奨プロセスのデータ流れ図である。
【図２８】データ構成要素間の関係をモデリングするのに使用される習得プロセスを示すフローチャートである。
【図２９】１セットの指定されたデータ構成要素に関連するデータ構成要素を推奨するのに使用されるプロセスを示すフローチャートである。
【図３０】データビューを推奨するのに使用されるプロセスを示すフローチャートである。
【図３１Ａ】データビューを提示するプロセスを示す図である。
【図３１Ｂ】表示選択方法のフローチャートである。
【図３２】提示する例示のＸＭＬデータを示す図である。
【図３３】実表データ構造の一例を示す図である。
【図３４】ハイパーリンクを有する実表データ構造の一例を示す図である。
【図３５】表表示種別の一例を示す図である。
【図３６】転置された表表示種別の一例を示す図である。
【図３７】行に関する線グラフの一例を示す図である。
【図３８】列に関する棒グラフの一例を示す図である。
【図３９】行に関する円グラフの一例を示す図である。
【図４０】行に関するｘｙプロットの一例を示す図である。
【図４１】図４０のｘｙプロットに対応する実表表示を示す図である。
【図４２】２Ｄグリッド表示種別の一例を示す図である。
【図４３】図４２に示す２Ｄグリッドに対応する表表示を示す図である。
【図４４】別の例示のＸＭＬデータを示す図である。
【図４５】図４４のＸＭＬツリーの完全に展開された実表データ構造を示す図である。
【図４６】ハイパーリンクを有する図４４のＸＭＬツリーの実表データ構造を示す図である。
【図４７ａ】フラットデータ表構築手順のフローチャートである。
【図４７ｂ（ｉ）】フラットデータ表構築手順のフローチャートである。
【図４７ｂ（ｉｉ）】フラットデータ表構築手順のフローチャートである。
【図４８】データビュー提示プロセスの分析フェーズのフローチャートである。
【図４９】データビュー提示プロセスの削除フェーズのフローチャートである。
【図５０】図４９の項目４９２０のフローチャートである。
【図５１】提示プロセスで使用されるあいまいな優先関係を有する有向グラフの一例を示す図である。
【図５２】あいまいな優先関係が図５１から削除された後に得られる有向グラフである。
【図５３】データビュー提示プロセスの優先フェーズのフローチャートである。
【図５４】既存の問合せデータを使用して新規のデータビューを作成するプロセスのフローチャートである。
【図５５】データセットを既存のデータビューへと追加するプロセスのフローチャートである。
【図５６】図５５のステップ５５３５により示される問合せツリーを更新するプロセスを詳述するフローチャートである。
【図５７】図５５のステップ５５２５により示すようにデータセット反復子に対するループ変数を判定するプロセスのフローチャートである。
【図５８】例示のデータ操作プロセスのソースデータビューを記述するのに使用される例示の問合せツリーを示す図である。
【図５９】例示のデータ操作プロセスの目標データビューを記述するのに使用される例示の問合せツリーを示す図である。
【図６０】相異ユニオン結合方法に対する目標問合せの繰返し操作を更新するプロセスのフローチャートである。
【図６１】内結合方法及び外結合方法に対する目標問合せの繰返し操作を更新するプロセスのフローチャートである。
【図６２】目標問合せに対するフィルタを更新するプロセスのフローチャートである。
【図６３】指定された問合せソート順を有する問合せツリーの一例を示す図である。
【図６４】データ構成要素を非表示化するプロセスのフローチャートである。付録Ａは、データビュー定義文書に対する好適な直列化構文のＸＭＬスキーマ例である。
【符号の説明】
【０４７９】
１００…ローカルコンピュータ、１２０…データブラウジングアプリケーション、１３０…ローカルデータベース、１５０…オラクルデータベース、１５１…Ｓｙｂａｓｅデータベース、１５２…Ｕｎｉｘ（登録商標）テキストファイル、１５３…ＸＭＬ文書、１１００…汎用コンピュータシステム、１１０１…コンピュータモジュール、２２００…中央推奨システム、２２０５…キーワードマッパ、２２２０…中央サーバ、２３００、２７００…推奨モジュール、２３０５、２７０５…スキーマ／ビュー定義アナライザ、２３３５、２７３５…データ要求プロセッサ、２３４５、２７４５…データランク付けプロセッサ、３４０１、３４０２…ハイパーリンク
【図１】
2004240954.tif 000038
【図２】
2004240954.tif 000039
【図３】
2004240954.tif 000040
【図４】
2004240954.tif 000041
【図５】
2004240954.tif 000042
【図６】
2004240954.tif 000043
【図７Ａ】
2004240954.tif 000044
【図７Ｂ】
2004240954.tif 000045
【図７Ｃ】
2004240954.tif 000046
【図８】
2004240954.tif 000047
【図９Ａ】
2004240954.tif 000048
【図９Ｂ】
2004240954.tif 000049
【図１０Ａ】
2004240954.tif 000050
【図１０Ｂ】
2004240954.tif 000051
【図１０Ｃ】
2004240954.tif 000052
【図１１】
2004240954.tif 000053
【図１２Ａ】
2004240954.tif 000054
【図１２Ｂ】
2004240954.tif 000055
【図１２Ｃ】
2004240954.tif 000056
【図１２Ｄ】
2004240954.tif 000057
【図１２Ｅ】
2004240954.tif 000058
【図１２Ｆ】
2004240954.tif 000059
【図１３Ａ】
2004240954.tif 000060
【図１３Ｂ】
2004240954.tif 000061
【図１３Ｃ】
2004240954.tif 000062
【図１４】
2004240954.tif 000063
【図１５】
2004240954.tif 000064
【図１６】
2004240954.tif 000065
【図１７】
2004240954.tif 000066
【図１８】
2004240954.tif 000067
【図１９】
2004240954.tif 000068
【図２０】
2004240954.tif 000069
【図２１】
2004240954.tif 000070
【図２２】
2004240954.tif 000071
【図２３】
2004240954.tif 000072
【図２４】
2004240954.tif 000073
【図２５】
2004240954.tif 000074
【図２６】
2004240954.tif 000075
【図２７】
2004240954.tif 000076
【図２８】
2004240954.tif 000077
【図２９】
2004240954.tif 000078
【図３０】
2004240954.tif 000079
【図３１Ａ】
2004240954.tif 000080
【図３１Ｂ】
2004240954.tif 000081
【図３２】
2004240954.tif 000082
【図３３】
2004240954.tif 000083
【図３４】
2004240954.tif 000084
【図３５】
2004240954.tif 000085
【図３６】
2004240954.tif 000086
【図３７】
2004240954.tif 000087
【図３８】
2004240954.tif 000088
【図３９】
2004240954.tif 000089
【図４０】
2004240954.tif 000090
【図４１】
2004240954.tif 000091
【図４２】
2004240954.tif 000092
【図４３】
2004240954.tif 000093
【図４４】
2004240954.tif 000094
【図４５】
2004240954.tif 000095
【図４６】
2004240954.tif 000096
【図４７ａ】
2004240954.tif 000097
【図４７ｂ（ｉ）】
2004240954.tif 000098
【図４７ｂ（ｉｉ）】
2004240954.tif 000099
【図４８】
2004240954.tif 000100
【図４９】
2004240954.tif 000101
【図５０】
2004240954.tif 000102
【図５１】
2004240954.tif 000103
【図５２】
2004240954.tif 000104
【図５３】
2004240954.tif 000105
【図５４】
2004240954.tif 000106
【図５５】
2004240954.tif 000107
【図５６】
2004240954.tif 000108
【図５７】
2004240954.tif 000109
【図５８】
2004240954.tif 000110
【図５９】
2004240954.tif 000111
【図６０】
2004240954.tif 000112
【図６１】
2004240954.tif 000113
【図６２】
2004240954.tif 000114
【図６３】
2004240954.tif 000115
【図６４】
2004240954.tif 000116
【外国語明細書】
2004240954.tif 000117
2004240954.tif 000118
2004240954.tif 000119
2004240954.tif 000120
2004240954.tif 000121
2004240954.tif 000122
2004240954.tif 000123
2004240954.tif 000124
2004240954.tif 000125
2004240954.tif 000126
2004240954.tif 000127
2004240954.tif 000128
2004240954.tif 000129
2004240954.tif 000130
2004240954.tif 000131
2004240954.tif 000132
2004240954.tif 000133
2004240954.tif 000134
2004240954.tif 000135
2004240954.tif 000136
2004240954.tif 000137
2004240954.tif 000138
2004240954.tif 000139
2004240954.tif 000140
2004240954.tif 000141
2004240954.tif 000142
2004240954.tif 000143
2004240954.tif 000144
2004240954.tif 000145
2004240954.tif 000146
2004240954.tif 000147
2004240954.tif 000148
2004240954.tif 000149
2004240954.tif 000150
2004240954.tif 000151
2004240954.tif 000152
2004240954.tif 000153
2004240954.tif 000154
2004240954.tif 000155
2004240954.tif 000156
2004240954.tif 000157
2004240954.tif 000158
2004240954.tif 000159
2004240954.tif 000160
2004240954.tif 000161
2004240954.tif 000162
2004240954.tif 000163
2004240954.tif 000164
2004240954.tif 000165
2004240954.tif 000166
2004240954.tif 000167
2004240954.tif 000168
2004240954.tif 000169
2004240954.tif 000170
2004240954.tif 000171
2004240954.tif 000172
2004240954.tif 000173
2004240954.tif 000174
2004240954.tif 000175
2004240954.tif 000176
2004240954.tif 000177
2004240954.tif 000178
2004240954.tif 000179
2004240954.tif 000180
2004240954.tif 000181
2004240954.tif 000182
2004240954.tif 000183
2004240954.tif 000184
2004240954.tif 000185
2004240954.tif 000186
2004240954.tif 000187
2004240954.tif 000188
2004240954.tif 000189
2004240954.tif 000190
2004240954.tif 000191
2004240954.tif 000192
2004240954.tif 000193
2004240954.tif 000194
2004240954.tif 000195
2004240954.tif 000196
2004240954.tif 000197
2004240954.tif 000198
2004240954.tif 000199
2004240954.tif 000200
2004240954.tif 000201
2004240954.tif 000202
2004240954.tif 000203
2004240954.tif 000204
2004240954.tif 000205
2004240954.tif 000206
2004240954.tif 000207
2004240954.tif 000208
2004240954.tif 000209
2004240954.tif 000210
2004240954.tif 000211
2004240954.tif 000212
2004240954.tif 000213
2004240954.tif 000214
2004240954.tif 000215
2004240954.tif 000216
2004240954.tif 000217
2004240954.tif 000218
2004240954.tif 000219
2004240954.tif 000220
2004240954.tif 000221
2004240954.tif 000222
2004240954.tif 000223
2004240954.tif 000224
2004240954.tif 000225
2004240954.tif 000226
2004240954.tif 000227
2004240954.tif 000228
2004240954.tif 000229
2004240954.tif 000230
2004240954.tif 000231
2004240954.tif 000232
2004240954.tif 000233
2004240954.tif 000234
2004240954.tif 000235
2004240954.tif 000236
2004240954.tif 000237
2004240954.tif 000238
2004240954.tif 000239
2004240954.tif 000240
2004240954.tif 000241
2004240954.tif 000242
2004240954.tif 000243
2004240954.tif 000244
2004240954.tif 000245
2004240954.tif 000246
2004240954.tif 000247
2004240954.tif 000248
2004240954.tif 000249
2004240954.tif 000250
2004240954.tif 000251
2004240954.tif 000252
2004240954.tif 000253
2004240954.tif 000254
2004240954.tif 000255
2004240954.tif 000256
2004240954.tif 000257
2004240954.tif 000258
2004240954.tif 000259
2004240954.tif 000260
2004240954.tif 000261
2004240954.tif 000262
2004240954.tif 000263
2004240954.tif 000264
2004240954.tif 000265
2004240954.tif 000266
2004240954.tif 000267
2004240954.tif 000268
2004240954.tif 000269
2004240954.tif 000270
2004240954.tif 000271
2004240954.tif 000272
2004240954.tif 000273
2004240954.tif 000274
2004240954.tif 000275
2004240954.tif 000276
2004240954.tif 000277
2004240954.tif 000278
2004240954.tif 000279
2004240954.tif 000280
2004240954.tif 000281
2004240954.tif 000282
2004240954.tif 000283
2004240954.tif 000284
2004240954.tif 000285
2004240954.tif 000286
2004240954.tif 000287
2004240954.tif 000288
2004240954.tif 000289
2004240954.tif 000290
2004240954.tif 000291
2004240954.tif 000292
2004240954.tif 000293
2004240954.tif 000294
2004240954.tif 000295
2004240954.tif 000296
2004240954.tif 000297
2004240954.tif 000298
2004240954.tif 000299
2004240954.tif 000300
2004240954.tif 000301
2004240954.tif 000302
2004240954.tif 000303
2004240954.tif 000304
2004240954.tif 000305
2004240954.tif 000306
2004240954.tif 000307
2004240954.tif 000308
2004240954.tif 000309
2004240954.tif 000310
2004240954.tif 000311
2004240954.tif 000312
2004240954.tif 000313
2004240954.tif 000314
2004240954.tif 000315
2004240954.tif 000316
2004240954.tif 000317
2004240954.tif 000318
2004240954.tif 000319
2004240954.tif 000320
2004240954.tif 000321
2004240954.tif 000322
2004240954.tif 000323
2004240954.tif 000324
2004240954.tif 000325
2004240954.tif 000326
2004240954.tif 000327
2004240954.tif 000328
2004240954.tif 000329
2004240954.tif 000330
2004240954.tif 000331
2004240954.tif 000332
2004240954.tif 000333
2004240954.tif 000334
2004240954.tif 000335
2004240954.tif 000336