視覚化フレームワークは、ソルバを含むことができる。ソルバを使用して、ビュー構成のビューコンポーネントのプロパティを判定することができる。いくつかの例で、ソルバを、依存関係ツリーなどの関係構造を使用して明示的に構成することができる。いくつかの例で、ソルバを、ソルバを有するプロパティ−セッターがソルバを有する他のプロパティ−セッターを呼び出すことに基づいて暗黙のうちに構成することができる。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソルバベースの視覚化フレームワークに関する。
【背景技術】
【０００２】
しばしば、情報を人間に伝える最も有効な形は、視覚的に伝えることである。したがって、数百万人の人が、情報を伝えるか受け取るため、および共同して働くために、広範囲のビジュアルアイテムを用いて働く。そのようなビジュアルアイテムは、たとえば、コンセプトスケッチ、工学図面、部品表の展開、ビルディングまたは分子構造などのさまざまな構造物を示す３次元モデル、トレーニング材料、図示されたインストール指示、プラニング図などを含むことができる。
【０００３】
より最近に、これらのビジュアルアイテムは、たとえばコンピュータ支援設計（ＣＡＤ）およびソリッドモデリングアプリケーションを使用して電子的に構築される。しばしば、これらのアプリケーションは、作成者がジオメトリにデータおよび制約を添付することを可能にする。たとえば、部品表を構築するアプリケーションは、各部品に関連する部品番号および供給業者、２つの構成要素の間の最大角度、または類似物などの属性を許容する場合がある。ある競技場の電子版を構築するアプリケーションが、座席の間の最大クリアランスなどを指定するツールを有する場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
そのようなアプリケーションは、設計および技術の進歩に非常に貢献した。しかし、あらゆる所与のアプリケーションが、視覚的に伝えることができる情報のタイプ、情報をどのように視覚的に伝えるのか、またはさまざまな視覚的表現に帰することができるデータおよび挙動の範囲に関する制限を有する。アプリケーションが、これらの制限を超えて変更されなければならない場合には、新しいアプリケーションは、通常、そのアプリケーションの能力を拡張するか完全に新規のアプリケーションを提供するコンピュータプログラマによって作成される。また、ユーザ（モデルの実際の作成者以外）がさまざまなシナリオをテストするためにどれほどモデルを操作できるのかに対する制限がある。
【課題を解決するための手段】
【０００５】
本明細書で説明される実施形態は、ソルバを使用してビューコンポーネントのプロパティを判定できる視覚化フレームワークに関する。いくつかの場合に、ソルバを、依存関係ツリーなどの関係構造を使用して明示的に構成することができる。いくつかの場合に、ソルバを、ソルバを有するプロパティ−セッターがソルバを有する他のプロパティ−セッターを呼び出すことに基づいて暗黙のうちに構成することができる。これは、作成者が、ビュー構成をよりすばやく作成し、考案することを可能にすることができる。
【０００６】
この要約は、請求される主題の主要な特徴または本質的特徴を識別することを意図されたものではなく、請求される主題の範囲を判定する際の助けとして使用されることも意図されていない。
【図面の簡単な説明】
【０００７】
上で列挙されたおよび他の利益および特徴を入手できる形を説明するために、さまざまな実施形態のより特定の説明を、添付図面を参照することによって描写する。これらの図面がサンプルの実施形態のみを示し、したがって本発明の範囲について限定的と考えられてはならないことを理解して、実施形態を、添付図面の使用を介して追加の限定性および詳細を伴って記述し、説明する。
【０００８】
【図１】入力データに依存するビュー構成を構築するデータ駆動構成フレームワークを含む、本発明の原理を実施できる実施形態を示す図である。
【図２】図１の環境の一例を表すパイプライン環境を示す図である。
【図３】図２のパイプラインのデータ部分の実施形態を概略的に示す図である。
【図４】図２のパイプラインの分析部分の実施形態を概略的に示す図である。
【図５】図２のパイプラインのビュー部分の実施形態を概略的に示す図である。
【図６】データストリームの要素のすべてまたはサブセットを列挙することのできるデータストリームオブジェクトを概略的に示す図である。
【図７】図２のパイプラインによって構築できるビュー構成のレンダリングを示す図である。
【図８】図２のパイプライン環境を使用してビュー構成を生成する方法を示す流れ図である。
【図９】図２のパイプライン構成を使用してビュー構成とのユーザ相互作用に応答してビュー構成を再生成する方法を示す流れ図である。
【図１０】特殊化されたソルバのコレクションを含むさらなる詳細において図４の分析部分のソルバを概略的に示す図である。
【図１１】特殊化されたソルバのコレクションのアクションを調整することによって未知のモデルパラメータについて解く図１０のソルバを示す流れ図である。
【図１２】図１０のソルバの例を表すソルバ環境を概略的に示す図である。
【図１３】モデル分析について解くのに図１２のソルバ環境を使用する方法を示す流れ図である。
【図１４】モデル変数について解くのに図１０のソルバ環境を使用する方法を示す流れ図である。
【図１５】ソルバ環境の実施形態を概略的に示す図である。
【図１６】図１５に示されたソルバ環境によって実行できる方法を示す流れ図である。
【図１７】図７の例を拡張する統合されたビュー構成のレンダリングを示す図である。
【図１８Ａ】複数のビジュアルアイテムが、対応するビジュアルアイテムが実行スクローリングを用いて相互作用できることを表すビジュアルキューで装飾された、ビュー構成を示す図である。
【図１８Ｂ】スクローリング相互作用の後の図１８Ａのビュー構成を示す図である。
【図１９Ａ】ズーミング相互作用が使用可能にされているビュー構成を示す図である。
【図１９Ｂ】ズームイン相互作用の後の図１９Ａのビュー構成を示す図である。
【図２０】各州の高度がデータを表し、州ビジュアルアイテムのうちのいくつかがその州ビジュアルアイテムとの可能な相互作用を示すビジュアルキューを含む、米国地図の形のビュー構成を示す図である。
【図２１】可能な相互作用を示すビジュアルキューを含む組み合わされた相互に関係付けられた円グラフおよび棒グラフの形のビュー構成を示す図である。
【図２２】さまざまなビジュアルキューが相互作用を識別する、ハリケーン経路進行図の形のビュー構成を示す図である。
【図２３】ビュー構成内で相互作用を提供する方法を示す流れ図である。
【図２４】さまざまなビジュアルアイテムを統合し、合併できるユーザインターフェースを示す図である。
【図２５】単なる螺旋がその上でデータがマッピングされる形状として示される、統合の第１ステージを示す図である。
【図２６】図２５の螺旋が１つのデータ系列に結び付けられる、統合の第２ステージを示す図である。
【図２７】図２５の螺旋が２つのデータ系列に結び付けられる、統合の第３ステージを示す図である。
【図２８】図２５の螺旋が図示のグラフに結び付けられる、統合の最終ステージを示す図である。
【図２９】棚レイアウトの視覚化を示し、本明細書で説明される原理を適用できる無数のアプリケーションのうちの１つを表す図である。
【図３０】本明細書で説明される原理を適用できる都市計画の視覚化を表す図である。
【図３１】本発明の原理を適用でき、これによってより動的な学習環境を作成する、子供の教育を比較する従来の視覚化を示す図である。
【図３２】本発明の原理を適用でき、これによってより動的な学習環境を作成する、人口密度を比較する従来の視覚化を示す図である。
【図３３】第１のパラメトリックターゲットに適用されたビューコンポーネントの視覚化を示す図である。
【図３４】第２のパラメトリックターゲットに適用された図３３に示されたビューコンポーネントの視覚化を示す図である。
【図３５】図２の分類コンポーネントが動作できる分類環境を示す図である。
【図３６】図３５のメンバアイテムの分類の例を示す図である。
【図３７Ａ】関係付けられたカテゴリの分類の一例を示す図である。
【図３７Ｂ】関係付けられたカテゴリの分類の一例を示す図である。
【図３７Ｃ】関係付けられたカテゴリの分類の一例を示す図である。
【図３８】複数のプロパティを含むメンバアイテムを示す図である。
【図３９】ドメイン固有分類を示し、図３５のドメイン指定された分類の一例を表す図である。
【図４０】分析をナビゲートし、使用する方法を示す流れ図である。
【図４１】分析を使用して検索する方法を示す流れ図である。
【図４２】図１の構成フレームワーク（またはその諸部分）を実施できる環境を提示するコンピューティングシステムを示す図である。
【発明を実施するための形態】
【０００９】
図１は、ユーザ駆動分析および分析結果の視覚化を使用するビジュアル構成環境１００を示す。環境１００（以下では「パイプライン」とも呼ばれる）は、ビューコンストラクション１３０の問題ドメインと独立に実行されるロジックを実行する構成フレームワーク１１０を含む。たとえば、同一の構成フレームワーク１１０を、都市計画、分子モデル、食品雑貨店棚レイアウト、機械性能分析、機械組立分析、または他のドメイン固有レンダリングの対話型ビュー構成を構成するのに使用することができる。下で説明するように、分析を、さまざまなシナリオでの検索および探索に使用することができる。しかし、まず、基本的な構成フレームワーク１１０を詳細に説明する。
【００１０】
構成フレームワーク１１０は、ドメインに固有の実際のビューコンストラクション１３０（本明細書では「ビュー構成」とも呼ばれる）を構築するためにドメイン固有の形で分類的に編成されるドメイン固有データ１２０を使用して分析１２１を実行する。したがって、構成フレームワーク１１０自体を再コーディングする必要があるのではなく、同一の構成フレームワーク１１０を、ドメイン固有データ１２０を変更することによって任意の個数の異なるドメインのビュー構成を構築するのに使用することができる。したがって、パイプライン１００の構成フレームワーク１１０は、再コーディングおよび再コンパイルではなくデータを変更することによって、潜在的に無制限の個数の問題ドメインまたは少なくともさまざまな問題ドメインに適用することができる。次に、ビューコンストラクション１３０を、適当な２Ｄレンダリングモジュールまたは３Ｄレンダリングモジュールに命令として供給することができる。本明細書で説明されるアーキテクチャは、基本構成要素として既存のビュー構成を新しいビュー構成に便利に組み込むことを可能にもする。一実施形態で、複数のビュー構成を統合されたビュー構成に含めて、１つのモデルに対する２つの可能な解決策の間での簡単な比較を可能にすることができる。
【００１１】
図２は、パイプライン環境２００の形での構成フレームワーク１１０の例のアーキテクチャを示す。パイプライン環境２００は、とりわけ、パイプライン２０１自体を含む。パイプライン２０１は、データ部分２１０、分析部分２２０、およびビュー部分２３０を含み、これらのそれぞれを、それぞれ後続の図３から５および付随する説明に関して詳細に説明する。さしあたり、全体的なレベルでは、パイプライン２０１のデータ部分２１０は、さまざまな異なるタイプのデータを受け入れることができ、そのデータを正規形式でパイプライン２０１の分析部分２２０に提示する。分析部分２２０は、データをさまざまなモデルパラメータにバインドし、モデル分析を使用して、モデルパラメータ内の未知数について解く。次に、さまざまなパラメータ値が、ビュー部分２３０に供給され、ビュー部分２３０は、モデルパラメータのこれらの値を使用して複合ビューを構築する。
【００１２】
パイプライン環境２００は、パイプライン２０１の作成者または他のユーザがパイプライン２０１に供給されるデータを定式化し、かつ／または選択することを可能にするオーサリングコンポーネント２４０をも含む。たとえばオーサリングコンポーネント２４０を使用して、データ部分２１０（入力データ２１１によって表される）、分析部分２２０（分析データ２２１によって表される）、およびビュー部分２３０（ビューデータ２３１によって表される）のそれぞれにデータを供給することができる。さまざまなデータ２１１、２２１、および２３１は、図１のドメイン固有データ１２０の例を表し、後でさらに詳細に説明される。オーサリングコンポーネント２４０は、たとえばデータスキーマ、モデルによって使用される実際のデータ、外部ソースから持ち込まれるデータの位置または可能な位置の範囲、ビジュアル（グラフィカルまたはアニメーション）オブジェクト、ビジュアル上で実行できるユーザインターフェース相互作用、モデリングステートメント（たとえば、ビュー、式、制約）、バインディングなどを含むさまざまなデータの供給をサポートする。
【００１３】
一実施形態で、オーサリングコンポーネントは、総合的なマネージャコンポーネント（図２には図示されていないが、図１の構成フレームワーク１１０によって表される）によって提供される機能性の１つの部分にすぎない。このマネージャは、イベント（ユーザ相互作用イベント、外部データイベント、およびソルバ、オペレーティングシステムその他などの他のコンポーネントのいずれかからのイベントなど）に応答して他のコンポーネント（データコネクタ、ソルバ、ビューワその他など）のすべての動作を制御し、シーケンシングする総合的なディレクタである。
【００１４】
オーサリングコンポーネント２４０は、検索を実行することを可能にする検索ツール２４２をも含む。検索ツール２４２は、複雑な検索動作を実行するためにパイプライン２０１のデータ駆動分析能力を利用することができる。たとえば、いくつかの場合に、検索の１つまたは複数のパラメータが、まず、その検索を完了するためにそれについて解かれる必要がある場合がある。
【００１５】
一例として、データ駆動分析が、都市地図であり、分析の一部が、その都市内の特定の座標での通常の雑音レベルについて解くことができると仮定する。その場合に、居住用不動産を検索する人は、平方フィート単位の面積、価格帯、部屋数などの通常の検索パラメータに対する検索を実行できるだけではなく、分析集中型のパラメータに対する検索をも実行することができる。たとえば、本原理を適用できる制限されない形があるが、不動産の柔軟な検索をどのようにして達成できるのかの選択された少数の多様な例を、これから提供する。
【００１６】
検索パラメータを指定することの一部として、ユーザは、
１）ある上限未満の平均雑音レベルを経験する家屋のみ、
２）月曜から木曜までのそれぞれにユーザの仕事場およびジムまで累積３００分以下の通勤時間を有する家屋のみ、
３）１／５マイル（３２０ｍ）以内のいずれかの道路上であるしきい値未満のトラフィックを経験し、今後１０年にわたってそのレベル未満のトラフィックが予測される家屋のみ、
４）１年のどの時点でも午前９時１５分の後に山の陰にならない家屋のみ、
５）１０年で木が屋根の面積の少なくとも５０％を陰にするように、所有地に十分な既存の木を有する家屋のみ、
６）その他
のうちの任意の１つまたは複数または他の検索アイテムに関する望みを示すことができる。
【００１７】
そのような不動産検索は、従来の技術を使用してたやすく達成可能ではない。これらの例のそれぞれで、要求される家屋検索データが存在しない場合があるが、本明細書で説明される原理は、検索が実行されつつある時にオンザフライでさまざまなカスタマイズされたパラメータに関する検索データを生成することを可能にすることができる。また、検索は、以前にそれについて解かれた任意の検索データを利用することができる。これは、ユーザのためのさまざまな検索能力および探索能力を可能にし、解かれるべき問題を探索する完全に新しい形を開発する。これらのタイプの検索をサポートする基礎になるデータ駆動分析機構に関するより多くを、これから説明する。
【００１８】
伝統的に、対話型ビュー構成アプリケーションのライフサイクルは、２つの主要な時間すなわち、オーサリング時（ａｕｔｈｏｒｉｎｇ ｔｉｍｅ）および使用時（ｕｓｅ ｔｉｍｅ）を伴う。オーサリング時には、対話型ビュー構成アプリケーションの機能性が、所望のドメインに固有の対話型ビュー構成を提供するためにプログラマによってコーディングされる。たとえば、インテリアデザインアプリケーションの作成者（たとえば、通常はコンピュータプログラマ）は、ユーザがインテリアデザインに固有のアクションの有限のセットを実行することを可能にするアプリケーションをコーディングすることができる。
【００１９】
使用時には、ユーザ（たとえば、おそらくは家屋の所有者またはプロフェッショナルインテリアデザイナ）が、そのアプリケーションを使用して、そのアプリケーションにハードコードされた有限のアクションのセットのうちの任意の１つまたは複数を実行することができる。このインテリアデザインアプリケーションの例では、ユーザは、表示される仮想の部屋の寸法を指定し、その部屋に家具および他のインテリアデザインコンポーネントを追加し、おそらくはその部屋のさまざまなアングルを得るためにビューを回転し、各アイテムの色をセットするなどを行うことができる。しかし、ユーザが、そのインテリアデザインアプリケーションをリバースエンジニアリングし、変更することをいとわないプログラマである場合を除いて、そのユーザは、アプリケーション作成者によって使用可能にされたアクションの有限のセットに制限される。たとえば、アプリケーションによって提供されない限り、ユーザは、どの窓配置が環境雑音を最小にするのか、風水ルールに従って部屋レイアウトをどのように実行するのか、または太陽熱寄与をどのように最小化するのかを自動的に計算するのにそのアプリケーションを使用することはできないはずである。
【００２０】
しかし、図２のパイプライン環境２００では、オーサリングコンポーネント２４０が、既存のパイプライン２０１にデータを供給するのに使用され、ここで、入力データの定義から分析モデルの定義、分析の結果がビュー構成内でどのように視覚化されるかの定義までプロセス全体を駆動するのは、そのデータである。したがって、パイプライン２０１をさまざまなドメインおよび問題のうちの任意の１つに適合させるために、コーディングを実行する必要はない。パイプライン２０１に供給されるデータだけが、全く異なる問題ドメインからまたはおそらくは既存ドメインに関する問題解決の調整のためのいずれかで異なるビュー構成を視覚化するためにパイプライン２０１を適用するために変更されるべきものである。パイプライン環境２００は、パイプライン２０１に供給されるデータを編成し、類別し、関係付ける、分類コンポーネント２６０をも含むことができる。分類コンポーネント２６０は、ドメインに敏感とすることができる。したがって、インテリアデザインドメイン、道路設計ドメイン、アーキテクチャドメイン、風水ドメインは、それぞれ、データを通ってナビゲートするのに使用できる異なる分類を有することができる。これが役立つ可能性があるのは、下で説明するように、パイプライン環境２００から使用可能にされるデータセットがますます増加しつつある可能性がある構成アクティビティに起因して、ふるいにかけるために使用可能なかなりのデータがある可能性があるからである。
【００２１】
さらに、データを、使用時（すなわち、ランタイム）ならびにオーサ時に変更できるので、モデルを、ランタイムに変更し、かつ／または拡張することができる。したがって、モデルのオーサリングとモデルの実行との間の区別は、あるとしても、より少ない。すべてのオーサリングがデータアイテムの編集を含み、ソフトウェアがその挙動のすべてをデータから実行するので、データに対する変更のすべてが、再コーディングおよび再コンパイルの必要なしに、即座に挙動に影響する。
【００２２】
パイプライン環境２００は、ユーザが表示されるビュー構成と相互作用した時を検出し、その後、それに応答して何をすべきかを判定するユーザ相互作用応答モジュール２５０をも含む。たとえば、あるタイプの相互作用が、パイプライン２０１に供給されるデータの変更を必要とせず、したがって、ビュー構成に対する変更を必要としない場合がある。他のタイプの相互作用が、データ２１１、２２１、または２３１のうちの１つまたは複数を変更する場合がある。その場合に、この新しいまたは変更されたデータが、新しい入力データがデータ部分２１０に供給されることを引き起こす場合があり、分析部分２２０による入力データの再分析を要求する場合があり、かつ／またはビュー部分２３０によるビュー構成の再視覚化を要求する場合がある。
【００２３】
したがって、パイプライン２０１を使用して、データ駆動分析視覚化を、おそらくは無制限の個数の問題ドメインに、または少なくともさまざまな問題ドメインに拡張することができる。さらに、さまざまな問題に対処するためにビュー構成を変更するために、プログラマである必要はない。パイプライン２０１のデータ部分２１０、分析部分２２０、およびビュー部分２３０のそれぞれを、これから、図３のデータ部分３００、図４の分析部分４００、および図５のビュー部分５００に関して、この順番で説明する。さらに、データの分類は、ドメインに固有であり、したがって、データの編成をそのドメインで活動する者にとってより直観的にすることを可能にする。図３から５から明白になるように、パイプライン２０１を、一連の変換コンポーネントとして構築することができ、ここで、これらの変換コンポーネントは、それぞれ、１）ある適当な入力データを受け取り、２）その入力データに応答してあるアクションを実行し（入力データに対して変換を実行するなど）、３）次の変換コンポーネントへの入力データとして働くデータを出力する。
【００２４】
パイプライン２０１を、クライアント上、サーバ上で実施することができ、または、制約なしにクライアントおよびサーバの間で分散させることさえできる。たとえば、パイプライン２０１を、サーバ上で実施し、レンダリング命令を出力として供給することができる。次に、クライアント側のブラウザは、サーバから受信されたレンダリング命令に従って単にレンダリングすることができる。このスペクトルの他方の端では、パイプライン２０１を、クライアント上に含めることができ、オーサリングおよび／または使用は、そのクライアントで実行される。パイプライン２０１が、完全にクライアントにある場合であっても、パイプライン２０１は、それでも、適当な情報（たとえば、モデル、コネクタ、カノニカライザ（ｃａｎｏｎｉｃａｌｉｚｅｒ）、スキーマ、その他）についてクライアントの外部のデータソースを検索することができる。この２つの手法のハイブリッドを提供する実施形態もある。たとえば、１つのそのようなハイブリッド手法では、モデルはサーバ上でホスティングされるが、ウェブブラウザモジュールは、クライアント上で動的にロードされ、その結果、モデルの相互作用およびビューイングロジックの一部が、クライアント上で動作するようにされる（したがって、より豊かで高速な相互作用およびビューを可能にする）。
【００２５】
図３は、図２のパイプライン２０１のデータ部分３００の多数の可能な実施形態のうちの１つを示す。データ部分３００の機能の１つは、図４に関して述べるパイプラインの分析部分４００によって理解されるスキーマと一貫する正規フォーマットでデータを供給することである。データ部分は、異種データ３０１にアクセスするデータアクセスコンポーネント３１０を含む。入力データ３０１は、そのデータがデータアクセスコンポーネント３１０に正規形式で提示される場合がある（が、そうである必要はない）という意味で「異種」とすることができる。実際に、データ部分３００は、異種データをさまざまなフォーマットのものとすることができるように構成される。モデルによってアクセスでき操作できるさまざまな種類のドメインデータの例は、テキスト文書、ＸＭＬ文書、テーブル、リスト、階層（木）、ＳＱＬデータベースクエリ結果、ＢＩ（ビジネスインテリジェンス）キューブクエリ結果、さまざまなフォーマットの２Ｄドローイングおよび３Ｄビジュアルモデルなどのグラフィカル情報、およびその組合せ（すなわち、複合物）を含む。さらに、アクセスできるデータの種類を、アクセスされるデータの定義（たとえば、スキーマ）を提供することによって、宣言的に拡張することができる。したがって、データ部分３００は、モデルへのさまざまな異種入力を許容し、アクセス可能なデータタイプのランタイムの宣言的拡張をもサポートする。
【００２６】
一実施形態で、データアクセス部分３００は、複数の異なるデータソースからデータを入手する複数のコネクタを含む。コネクタの主要な機能の１つは、対応するデータを正規形式にすることなので、そのようなコネクタは、しばしば、本明細書および図面で「カノニカライザ」と呼ばれる。各カノニカライザは、その対応するデータソースの特定のアプリケーションプログラミングインターフェース（ＡＰＩ）の理解を有することができる。カノニカライザは、データをデータソースから読み取り、かつ／またはデータソースに書き込むためにその対応するＡＰＩとインターフェースする対応するロジックをも含むことができる。したがって、カノニカライザは、外部データソースとデータのメモリイメージとの間で橋をわたす。
【００２７】
データアクセスコンポーネント３１０は、入力データ３０１を評価する。入力データが、既に正規であり、したがって分析部分４００によって処理可能である場合には、入力データを、分析部分４００に入力される正規データ３４０として直接に供給することができる。
【００２８】
しかし、入力データ３０１が正規ではない場合には、適当なデータ正規化コンポーネント３３０が、入力データ３０１を正規フォーマットに変換することができる。データ正規化コンポーネント３３０は、実際には、それぞれが特定の特性を有する入力データを正規形式に変換できる、データ正規化コンポーネント３３０のコレクションである。データ正規化コンポーネント３３０のコレクションは、４つの正規化コンポーネント３３１、３３２、３３３、および３３４を含むものとして図示されている。しかし、省略記号３３５は、他の個数の正規化コンポーネントも存在する可能性があり、おそらくは図示された４つより少数さえ存在する可能性があることを表す。
【００２９】
入力データ３０１は、カノニカライザ自体ならびに相関されたデータ特性（１つまたは複数）の識別さえ含むことができる。次に、データ部分３００は、相関されたデータ特性を登録し、正規化コンポーネントをデータ正規化コンポーネントコレクション３３０に供給し、このデータ正規化コンポーネントコレクション３３０で、その正規化コンポーネントを使用可能な正規化コンポーネントに追加することができる。これらの相関された特性を有する入力データが、その後に受け取られる場合に、データ部分３１０は、その入力データを相関された正規化コンポーネントに割り当てることができる。正規化コンポーネントを、ウェブ上の定義されたコンポーネントライブラリからなど、外部ソースから動的に見つけることもできる。たとえば、所与のデータソースのスキーマが既知であるが、必要なカノニカライザが存在しない場合には、そのカノニカライザを、外部コンポーネントライブラリから突き止めることができる（そのようなライブラリを見つけることができ、そのライブラリが必要なコンポーネントを含む場合に）。パイプラインは、そのスキーマがまだ知られていないデータを解析し、解析結果を既知のコンポーネントライブラリ内のスキーマ情報と比較して、データのタイプの動的判定を試み、したがって、必要なカノニカライザコンポーネントを突き止めることもできる。
【００３０】
代替案では、入力データが正規化コンポーネントのすべてを含むのではなく、入力データが、その代わりに、正規化変換を定義する変換定義を提供することができる。次に、その変換定義を、０個以上の標準デフォルト正規化変換と一緒に変換を実施する対応する正規化コンポーネントに変換するように、コレクション３３０を構成することができる。これは、データ部分３００が、入力データを消費するが、対応する正規化されたデータをパイプラインのさらに下に供給しない場合の例を表す。しかし、おそらくはほとんどの場合に、入力データ３０１は、対応する正規データ３４０が生成されることをもたらす。
【００３１】
一実施形態では、データアクセスコンポーネント３１０を、入力データのファイルタイプおよび／またはフォーマットタイプを基礎としてデータ正規化コンポーネントに入力データを割り当てるように構成することができる。他の特性、たとえば入力データのソースを含めることができる。デフォルト正規化コンポーネントを、指定された対応する正規化コンポーネントを有しない入力データに割り当てることができる。デフォルト正規化コンポーネントは、入力データを正規化することを試みるためにルールのセットを適用することができる。デフォルト正規化コンポーネントが、データを正規化できない場合には、デフォルト正規化コンポーネントは、図２のオーサリングコンポーネント２４０をトリガして、入力データのスキーマ定義を提供するようにユーザに促すことができる。スキーマ定義がまだ存在しない場合には、オーサリングコンポーネント２４０は、入力データを正規形式に変換するのに使用できる対応するスキーマ定義を作成者が生成するのを助けるためにスキーマ定義アシスタントを提示することができる。データが正規形式になった後に、そのデータに付随するスキーマは、パイプライン２０１の残りがそのデータを解釈するために新しいコードを必要としなくなる、そのデータの十分な記述を提供する。その代わりに、パイプライン２０１は、アクセス可能なスキーマ宣言言語を表現可能なすべてのスキーマを考慮してデータを解釈できるコードを含む。
【００３２】
データの１つのタイプは、図６に関して図示し、説明するデータストリームオブジェクト６００などのデータストリームオブジェクトである。データストリームオブジェクト６００は、そのデータストリームオブジェクトに関連するデータストリーム６０２内のある範囲を列挙できる列挙モジュール６０１を含む。その範囲は、実際にデータストリーム６０２の全範囲を含むことができる。その一方で、データストリーム６０２を、「擬似無限」または「部分的擬似無限」データストリームとすることができる。この説明および特許請求の範囲で、「擬似無限」データストリームは、データストリームオブジェクト６００を扱っているコンピューティングシステムの揮発性メモリに完全に収まるには大きすぎるデータストリームである。「部分的擬似無限」データストリームは、そのデータストリームオブジェクトを扱っているコンピューティングシステムの揮発性メモリの少なくとも半分を占めるデータストリームと定義される。列挙モジュール６０１は、たとえば図２のデータ部分２１０、分析部分２２０、またはおよびビュー部分２３０など、外部モジュールからの要求に応答してデータストリームの一部だけを列挙することができる。列挙モジュール６０１は、データストリームの最初の要素から始まる列挙を要求することができる。その一方で、列挙モジュール６０１は、まずデータストリームの初めから列挙することなく、データストリームの任意の他の部分から始まる列挙を可能にすることができる（すなわち、列挙中央ストリームを可能にすることができる）。
【００３３】
データストリームオブジェクト６００は、データのストリームの要求されたメンバ要素に関連するプロパティに基づいて、データストリームの要求された部分（１つまたは複数）を識別できるものとすることができる。その場合に、データストリームオブジェクトは、要求を処理し、要求されたプロパティを有するデータストリームの全メンバ要素を識別するロジックを含むことができる。たとえば、要求を、特定の経度座標および緯度座標から下向きに見て１０００フィート（３０４．８ｍ）の高度から可視の都市のすべての要素に関するものとすることができる。その一方で、データストリームオブジェクトを、メンバ要素に関する要求を表すために応答できるものとすることもできる。
【００３４】
一例として、擬似無限データストリームを、実際のまたは仮想の都市の記述であって、その都市内のすべてのアイテムの記述（これらのアイテムのすべての想像できるすべてのレベルの記述を含む）を含む記述とすることができる。その情報は、単純に、すべて同時にメモリ内で表すには多すぎる可能性がある。したがって、データストリームオブジェクト６００は、現在のビューをレンダリングするのに必要な関連情報のみを提供することができる。たとえば、その都市が、１００マイル（１６０ｋｍ）の高度で見られている場合に、おそらくはその都市の境界情報だけが関連する。その都市の一部が、１０マイル（１６ｋｍ）の高度で見られている場合に、おそらくは、より大きい物体（空港、公園、貯水池、および類似物などに関する情報だけが、ビュー内にある場合に限って提供され得る）。その都市の一部が、１マイル（１．６ｋｍ）の高度で見られている場合に、おそらくは、ビュー内の街路およびビルディングをレンダリングするのに必要な情報が、データストリームオブジェクトによって提供される。その都市の一部が、１０００フィート（３０４．８ｍ）の高度で見られている場合に、おそらくは、街路のさらなる詳細（すなわち、レーン数、街路の名前、矢印など）およびビルディングに関するさらなる詳細（テクスチャおよび窓位置など）が提供される可能性がある。当然、このズームイン動作が発生する時には、情報は、ますます小さくなる地理的面積に関係する。１００フィート（３０．５ｍ）ビューでは、データストリームは、低木、マンホール、側溝、階段、自動販売機、横断歩道、および類似物に関する情報を提供する可能性がある。そのデータの量は、従来のコンピュータが都市全体についてメモリ内に保持するにはむずかしい可能性がある。
【００３５】
もう１つの例として、擬似無限データストリームが、フラクタルの場合のように、文字どおり無限である場合がある。フラクタルは、フラクタルの一部にどれほどズームインするかに無関係に、繰り返す形状が必ず見えてくるように数学的に定義される。必ず、さらに、さらに、際限なくズームインすることができる。同一のことが、ズームアウトにもあてはまる。そのようなフラクタルのジオメトリを文字どおりに表すことは、無限の量の情報を要するはずである。しかし、データストリームオブジェクトは、フラクタルが数学的にどのように定義されるのかに関する概念を有することができる。データストリームオブジェクトが、詳細の特定のレベルでフラクタルを作ることを求められる場合には、データストリームオブジェクトは、詳細のその特定のレベルにあてはまるデータを計算し、そのデータを提供することができる。
【００３６】
したがって、擬似無限データオブジェクトは、詳細を定義する式を評価することによっておよび／またはデータストリームオブジェクトの外部のデータにアクセスすることによってのいずれかで、データの要求された範囲を生成することができる。そのような範囲は、パイプライン２０１の分析部分４００に供給される階層データの例である。一実施形態で、データストリームオブジェクトと通信するプロトコルを、データストリーム自体がどれほど大きいのかにかかわりなく、同一とすることができる。したがって、作成者は、したがって、より小さいデータストリームオブジェクトに関連するデータストリームオブジェクトに関するモデルをテストすることができる。その後、他者がそのモデルを確信した後に、作成者は、モデル自体を変更する必要なしに、データストリームオブジェクトを、無限データストリーム、擬似無限データストリーム、または部分的擬似無限データストリームに関連するデータストリームオブジェクトに切り替えることができる。
【００３７】
正規データ３４０の形にかかわりなく、正規データ３４０は、データ部分３００からの出力データとして、および分析部分４００への入力データとして供給される。正規データは、さまざまなデータタイプを含むフィールドを含むことができる。たとえば、フィールドは、整数、浮動小数点数、文字列、ベクトル、配列、コレクション、階層構造、テキスト、ＸＭＬ文書、テーブル、リスト、ＳＱＬデータベースクエリ結果、ＢＩ（ビジネスインテリジェンス）キューブクエリ結果、さまざまなフォーマットの２Ｄドローイングおよび３Ｄビジュアルモデルなどのグラフィカル情報などのデータタイプ、またはこれらのさまざまなデータタイプの複雑な組合せさえ含むことができる。別の利益として、正規化プロセスは、さまざまな入力データを正規化することができる。さらに、データ部分３００が受け入れることのできるさまざまな入力データは、拡張可能である。これは、本明細書で後で述べるように、複数のモデルが組み合わされる場合に役立つ。
【００３８】
図４は、図２のパイプライン２０１の分析部分２２０の例を表す分析部分４００を示す。データ部分３００が、正規化されたデータ４０１をデータモデルバインディングコンポーネント４１０に供給した。正規化されたデータ４０１は、任意の正規化された形および任意の個数のパラメータを有することができ、この形およびパラメータの個数は、入力データの部分ごとに異なることさえできる。しかし、議論のために、正規データ４０１は、フィールド４０２Ａから４０２Ｈを有し、これらのフィールドを、本明細書で集合的に「フィールド４０２」と呼ぶ場合がある。
【００３９】
その一方で、分析部分４００は、複数のモデルパラメータ４１１を含む。モデルパラメータのタイプおよび個数は、モデルに従って異なるものとすることができる。しかし、特定の例の議論のために、モデルパラメータ４１１は、モデルパラメータ４１１Ａ、４１１Ｂ、４１１Ｃ、および４１１Ｄを含むものとして議論される。一実施形態では、モデルパラメータのアイデンティティおよびモデルパラメータの間の分析的関係を、強制的コーディングを使用せずに宣言的に定義することができる。
【００４０】
データモデルバインディングコンポーネント４１０は、正規化されたデータフィールド４０２とモデルパラメータ４１１との間に入って、これによってフィールドとパラメータとの間のバインディングを提供する。この場合に、データフィールド４０２Ｂは、矢印４０３Ａによって表されるように、モデルパラメータ４１１Ａにバインドされる。言い換えると、データフィールド４０２Ｂからの値が、モデルパラメータ４１１Ａを設定するのに使用される。また、この例では、データフィールド４０２Ｅは、モデルパラメータ４１１Ｂにバインドされ（矢印４０３Ｂによって表されるように）、データフィールド４０２Ｈは、モデルパラメータ４１１Ｃにバインドされる（矢印４０３Ｃによって表されるように）。
【００４１】
データフィールド４０２Ａ、４０２Ｃ、４０２Ｄ、４０２Ｆ、および４０２Ｇは、モデルパラメータのいずれにもバインドされずに図示されている。これは、入力データからのデータフィールドのすべてが必ずモデルパラメータとして使用されることを要求されるのではないことを強調するためである。一実施形態では、これらのデータフィールドのうちの１つまたは複数を使用して、正規化されたデータからのどのフィールドが（この正規化されたデータまたはおそらくはすべての将来の類似する正規化されたデータについて）どのモデルパラメータにバインドされなければならないのかに関する命令をデータモデルバインディングコンポーネント４１０に提供することができる。これは、図２の分析部分２２０に供給できる分析データ２２１の種類の例を表す。正規化されたデータフィールドからのどのデータフィールドがどのモデルパラメータにバインドされるのかの定義を、複数の形で定式化することができる。たとえば、バインディングを、１）オーサリング時に作成者によって明示的にセットされる、２）使用時にユーザによって明示的にセットされる（作成者によって課せられるすべての制限の対象になる）、３）アルゴリズム的ヒューリスティックに基づくオーサリングコンポーネント２４０による自動的バインディング、および／または４）バインディングをアルゴリズム的に行うことができないと判定される時にバインディングを指定するように作成者および／またはユーザにオーサリングコンポーネントによって促すこととすることができる。したがって、バインディングを、モデルロジック自体の一部として解決することもできる。
【００４２】
どのデータフィールドがどのモデルパラメータにマッピングされるのかを定義する、作成者の能力は、作成者に、モデルパラメータを定義するためにその作成者が快適であるシンボルを使用できるという点で高い柔軟性を与える。たとえば、モデルパラメータのうちの１つが圧力を表す場合に、作成者は、そのモデルパラメータに「Ｐｒｅｓｓｕｒｅ（圧力）」もしくは「Ｐ」またはその作成者にとって意味をなす任意の他のシンボルという名前を付けることができる。作成者は、モデルパラメータの名前を変更することさえでき、これは、一実施形態で、データモデルバインディングコンポーネント４１０に、以前に古い名前のモデルパラメータへのものであったバインディングをその代わりに新しい名前のモデルパラメータにバインドすることを可能にするために自動的に更新させ、これによって、所望のバインディングを保存することができる。バインディングに関するこの機構は、バインディングをランタイムに宣言的に変更することをも可能にする。
【００４３】
モデルパラメータ４１１Ｄは、この例でモデルパラメータ４１１Ｄがデータモデルバインディングコンポーネント４１０によって値を割り当てられなかったことを強調するために、アスタリスクと共に図示されている。したがって、モデルパラメータ４１１Ｄは、未知数のままになる。言い換えると、モデルパラメータ４１１Ｄは、値を割り当てられない。
【００４４】
モデリングコンポーネント４２０は、複数の機能を実行する。まず、モデリングコンポーネント４２０は、モデルパラメータ４１１の間の分析的関係４２１を定義する。分析的関係４２１は、式４３１、ルール４３２、および制約４３３を含む３つのカテゴリに類別される。しかし、ソルバのこのリストは、拡張可能である。たとえば、一実施形態では、対応するシミュレーションエンジンが提供され、ソルバとして登録されるならば、１つまたは複数のシミュレーションを、分析的関係の一部として組み込むことができる。
【００４５】
用語「式」は、本明細書で使用される時に、数学の分野で使用される時のこの用語と一致する。
【００４６】
用語「ルール」は、本明細書で使用される時に、条件ステートメントを意味し、ここで、１つまたは複数の条件が満足される場合に（条件ステートメントの条件部分すなわち「ｉｆ」部分）、１つまたは複数のアクションが行われなければならない（条件ステートメントの結果部分すなわち「ｔｈｅｎ」部分）。ルールは、１つもしくは複数のモデルパラメータが条件ステートメント内で表される場合、または１つもしくは複数のモデルパラメータが結果ステートメント内で表される場合に、モデルパラメータに適用される。
【００４７】
用語「制約」は、本明細書で使用される時に、制限が１つまたは複数のモデルパラメータに適用されることを意味する。たとえば、都市計画モデルで、特定の家屋要素が、全体的な可能な地域制指定のサブセットを有する地図位置での配置に制限される場合がある。橋要素が、ある最大長未満またはあるレーン数未満に制限される場合がある。
【００４８】
モデルに馴染みのある作成者は、そのモデルにあてはまるこれらの式、ルール、および制約の表現を提供することができる。シミュレーションの場合に、作成者は、モデルパラメータの間の適当なシミュレーション関係を提供する適当なシミュレーションエンジンを提供することができる。モデリングコンポーネント４２０は、作成者が式、ルール、および制約の自然なシンボリック表現を提供するための機構を提供することができる。たとえば、熱力学関連モデルの作成者は、熱力学教科書から式を単純にコピーし、貼り付けることができる。モデルパラメータをデータフィールドにバインドする能力は、作成者が、その作成者に馴染みのあるどのシンボルでも（その作成者が頼る教科書で使用される正確なシンボルなど）またはその作成者が使用したいと思う正確なシンボルを使用することを可能にする。
【００４９】
解く前に、モデリングコンポーネント４２０は、モデルパラメータのどれについて解くべきか（すなわち、以下では、単数の場合に「出力モデル変数（ｏｕｔｐｕｔ ｍｏｄｅｌ ｖａｒｉａｂｌｅ）」、複数の場合に「出力モデル変数（ｏｕｔｐｕｔ ｍｏｄｅｌ ｖａｒｉａｂｌｅｓ）」、単一のまたは複数の出力モデル変数があり得る場合に「出力モデル変数（１つまたは複数）（ｏｕｔｐｕｔ ｍｏｄｅｌ ｖａｒｉａｂｌｅ（ｓ））」）をも識別する。出力モデル変数（１つまたは複数）は、未知パラメータとすることができ、または、既知のモデルパラメータの値が解く動作で変更の対象になる場合に既知のモデルパラメータとすることができる。図４の例では、データモデルバインディング動作の後に、モデルパラメータ４１１Ａ、４１１Ｂ、および４１１Ｃは既知であり、モデルパラメータ４１１Ｄは未知である。したがって、未知のモデルパラメータ４１１Ｄを、出力モデル変数のうちの１つとすることができる。その代わりにまたはそれに加えて、既知のモデルパラメータ４１１Ａ、４１１Ｂ、および４１１Ｃのうちの１つまたは複数を出力モデル変数にすることもできる。次に、ソルバ４４０が、可能な場合に、出力モデル変数（１つまたは複数）について解く。下で説明する一実施形態では、ソルバ４４０は、解く動作を実行するのを可能にするのに十分な入力モデル変数が提供される限り、単一のモデル内であっても、さまざまな出力モデル変数について解くことができる。入力モデル変数は、たとえば、その値が解く動作中に変更の対象にならない既知のモデルパラメータとすることができる。たとえば、図４で、モデルパラメータ４１１Ａおよび４１１Ｄが入力モデル変数である場合に、ソルバは、その代わりに、出力モデル変数４１１Ｂおよび４１１Ｃについてその代わりに解くことができる。一実施形態で、ソルバは、単一のモデルパラメータについて複数の異なるデータタイプのうちの任意の１つを出力することができる。たとえば、いくつかの式動作（加算、減算、および類似物など）は、オペランドが整数、浮動小数点数、そのベクトル、またはその行列のいずれであるかにかかわりなく適用される。
【００５０】
決して好ましい実施形態ではないが、ソルバ４４０が、複数のスプレッドシートがある（この複数のスプレッドシートが複数のタブ内の単一のスプレッドシートファイル内にあるかどうかおよび／またはこの複数のスプレッドシートが異なるスプレッドシートファイル内の単一のスプレッドシートファイル内にあるかどうかにかかわりなく）スプレッドシートプログラムによって実施される一実施形態がある。通常のスプレッドシートには、複数のセルがある。各セルは、リテラル値またはリテラル値に解決できる関連する式を有することができる。式の場合に、その式が、他のセルからの値に頼る場合があり、その値が、他のセルに関連する対応する式を介して潜在的に解かれた可能性がある。
【００５１】
スプレッドシートは、入力モデルパラメータおよび出力モデルパラメータが既知である１方向で解く時に有効である。しかし、ソルバ４４０にあるとされる利益の１つは、どのモデルパラメータ（１つまたは複数）が入力パラメータ（１つまたは複数）として識別されるのかおよびどのモデルパラメータ（１つまたは複数）が出力モデルパラメータ（１つまたは複数）として識別されるのかに依存して異なる解決方向が使用可能にされ、入力モデルパラメータ（１つまたは複数）および／または出力モデルパラメータ（１つまたは複数）のアイデンティティが変化する時に解決方向がおそらくは解決ごとに変化することである。これには、スプレッドシートプログラムで、可能な解決方向ごとに異なるスプレッドシートを割り当てることによって対処することができる。たとえば、２０個の可能な解決方向がある場合には、解決方向ごとに１つの、合計２０個のスプレッドシートを設けることができる。
【００５２】
各スプレッドシートは、その方向で解くための適当な式を有する適当にリンクされたセルを有する。この実施形態では、スプレッドシートプログラムの内部またはスプレッドシートプログラムの外部のいずれかのマクロまたは他の実行可能ファイルが、どのパラメータが入力パラメータであるのかおよびどれについて解くべきなのかを判定する際にモデリングコンポーネント４２０のために記述された関数を実行し、その解決方向を考慮して適当なスプレッドシートを選択し、選択された解決方向について適当なスプレッドシートフィールドを設定することができる。適当な入力パラメータフィールドが設定された後に、スプレッドシートは、出力モデルパラメータ（１つまたは複数）について解き、スプレッドシート内のリンクされた式を使用して適当な出力モデルパラメータフィールド（１つまたは複数）に値を設定する。しかし、スプレッドシート実施態様が、本明細書で説明される原理の好ましい実施形態ではないことを想起されたい。たとえば、数百個の可能な解決方向がある場合には、１つのスプレッドシートが各解決方向専用である実施形態に、数百個のスプレッドシートがある可能性がある。したがって、分析が、このスプレッドシート実施形態で変更される場合には、このスプレッドシート実施形態は、リンクされた分析式をどのように変更しなければならないのかを調べるためにスプレッドシートのそれぞれを手作業でふるいにかけることを伴う。この説明は、ここで、このスプレッドシート実施形態からより離れて焦点を合わせ、もう一度、ソルバ４００機能性の一般的議論に移る。
【００５３】
一実施形態では、ソルバ４４０が、特定の出力モデル変数について解くことができない時であっても、ソルバ４００は、それでも、実際の数値結果（または何であれそれについて解かれるデータタイプ）への完全な解決が可能ではない場合であっても、出力モデル変数に関する部分的な解を提示する。これは、完全な解決に達するためにどの情報が必要なのかに関して作成者にプロンプトを出すことによって、パイプラインが増分開発を容易にすることを可能にする。これは、オーサ時と使用時との間の区別を除去するのを助けもする。というのは、少なくとも部分的な解決が、さまざまなオーサリングステージ全体を通じて使用可能であるからである。抽象的な例について、分析モデルが式ａ＝ｂ＋ｃ＋ｄを含むと仮定する。次に、ａ、ｃ、およびｄが出力モデル変数であり、ｂが、５という既知の値（この場合には整数）を有する入力モデル変数であると仮定する。解くプロセスでは、ソルバ４４０は、出力モデル変数のうちの１つ「ｄ」について解き、「ｄ」と呼ばれるモデルパラメータに６（整数）という値を割り当てることだけができるが、ソルバ４４０は、「ｃ」について解くことができない。「ａ」は「ｃ」に依存するので、「ａ」と呼ばれるモデルパラメータも、未知数で、それについて解かれないままになる。この場合に、整数値を「ａ」に割り当てるのではなく、ソルバは、部分的な解決を行い、モデルパラメータ「ａ」に「ｃ＋１１」というストリング値を出力することができる。前に述べたように、これは、ドメイン専門家が分析モデルを作成しつつある時に特に役立つ可能性があり、本質的に、モデルパラメータ「ａ」の内容に関する部分的情報を提供するように働き、「ｃ」モデルパラメータについて解くことを可能にする、あるさらなるモデル分析が提供される必要があることの手がかり（キュー）を作成者に与えるようにも働く。この部分的な解決を、おそらく、ドメイン専門家が部分的結果を見ることを可能にするために、ある形でビュー構成内で出力することができる。
【００５４】
ソルバ４４０は、図４では単純化された形で図示されている。しかし、ソルバ４４０は、図１０から１６に関して説明するように、複数の構成ソルバの動作を指示することができる。図４では、モデリングコンポーネント４２０が、モデルパラメータ４１１（現在は既知のそれについて解かれた出力モデル変数を含む）を、図５のビュー部分５００に提供される出力として使用可能にする。
【００５５】
図５は、図２のビュー部分２３０の例を表すビュー部分５００を示す。ビュー部分５００は、図４の分析部分４００からモデルパラメータ４１１を受け取る。ビュー部分は、ビューコンポーネントのコレクションを含むビューコンポーネントリポジトリ５２０をも含む。たとえば、この例のビューコンポーネントリポジトリ５２０は、ビューコンポーネント５２１から５２４を含むものとして図示されているが、ビューコンポーネントリポジトリ５２０は、任意の個数のビューコンポーネントを含むことができる。ビューコンポーネントのそれぞれは、０個以上の入力パラメータを含むことができる。たとえば、ビューコンポーネント５２１は、入力パラメータを全く含まない。しかし、ビューコンポーネント５２２は、２つの入力パラメータ５４２Ａおよび５４２Ｂを含む。ビューコンポーネント５２３は、１つの入力パラメータ５４３を含み、ビューコンポーネント５２４は、１つの入力パラメータ５４４を含む。とは言うものの、これは単なる例である。入力パラメータは、ビジュアルアイテムがどのようにレンダリングされるのかに影響することができるが、必ずそうである必要はない。ビューコンポーネント５２１が入力パラメータを含まないという事実は、モデルパラメータを全く参照せずに生成されるビューがあり得ることを強調するものである。変化しない固定された（組込み）データだけを含むビューを検討されたい。そのようなビューは、たとえば、ユーザの参照情報を構成することができる。その代わりに、モデルにインポートするためにアイテムをカタログから選択できるようにするために、カタログをブラウズする形を提供するだけのビューを検討されたい。
【００５６】
各ビューコンポーネント５２１から５２４は、対応するビューコンポーネント入力パラメータ（１つまたは複数）がある場合にそれを使用してビュー構成コンポーネント５４０によって実行された時に、対応するビューアイテムを仮想空間５５０内に配置させる、対応するロジックを含むか、それに関連付けられる。その仮想アイテムは、静的なイメージもしくはオブジェクトとすることができ、または、動的にアニメートされるビジュアルアイテムまたはオブジェクトとすることができる。たとえば、ビューコンポーネント５２１から５２４のそれぞれは、実行された時にそれぞれ対応する仮想アイテム５５１から５５４を仮想空間５５０内にレンダリングさせる対応するロジック５３１から５３４に関連する。仮想アイテムは、単純な形状として図示されている。しかし、仮想アイテムは、形状において非常に複雑にすることができ、おそらくはアニメーションさえ含む。この説明では、ビューアイテムが仮想空間内でレンダリングされる時に、それは、レンダリングエンジンに供給された時にレンダリングエンジンがディスプレイ上で指定された位置に指定された形でビューアイテムを表示できる十分な命令をビュー構成コンポーネントが作成したことを意味する。
【００５７】
ビューコンポーネント５２１から５２４を、おそらくは、たとえば図２のオーサリングコンポーネント２４０を使用してビュー部分５００にビューデータとして提供することさえできる。ビューデータを、図６に関して上で説明したようにデータストリームオブジェクトによって提供される擬似無限データストリームまたは部分的擬似無限データストリームの範囲とすることさえできる。たとえば、オーサリングコンポーネント２４０は、作成者が複数の幾何的形から選択しまたはおそらくは他の幾何的形を構成することを可能にするセレクタを提供することができる。作成者は、ビューコンポーネントごとに入力パラメータのタイプを指定することもできるが、入力パラメータの一部を、ビュー部分５００によって課せられるデフォルト入力パラメータとすることができる。各ビューコンポーネント５２１から５２４に関連するロジックに、ビューデータを与えることができ、かつ／または各ビューコンポーネント５２１から５２４に関連するロジックが、ビュー部分５００自体によって提供されるあるデフォルト機能性を含むこともできる。
【００５８】
ビュー部分５００は、モデルパラメータのうちの少なくともいくつかをビューコンポーネント５２１から５２４の対応する入力パラメータにバインドするように構成されたモデル−ビューバインディングコンポーネント５１０を含む。たとえば、モデルパラメータ４１１Ａは、矢印５１１Ａによって表されるように、ビューコンポーネント５２２の入力パラメータ５４２Ａにバインドされる。モデルパラメータ４１１Ｂは、矢印５１１Ｂによって表されるように、ビューコンポーネント５２２の入力パラメータ５４２Ｂにバインドされる。また、モデルパラメータ４１１Ｄは、矢印５１１Ｃによって表されるように、それぞれビューコンポーネント５２３および５２４の入力パラメータ５４３および５４４にバインドされる。モデルパラメータ４１１Ｃは、どの対応するビューコンポーネントパラメータにもバインドされずに図示され、すべてのモデルパラメータが、これらのモデルパラメータが分析部分で必須である場合であってもパイプラインのビュー部分によって使用される必要があるのではないことを強調する。また、モデルパラメータ４１１Ｄは、ビューコンポーネントの２つの異なる入力パラメータにバインドされて図示され、モデルパラメータを複数のビューコンポーネントパラメータにバインドできることを表す。一実施形態では、モデルパラメータとビューコンポーネントパラメータとの間のバインディングの定義を、１）オーサリング時に作成者によって明示的にセットされる、２）使用時にユーザによって明示的にセットされる（作成者によって課せられるすべての制限の対象になる）、３）アルゴリズム的ヒューリスティックに基づくオーサリングコンポーネント２４０による自動的バインディング、および／または４）バインディングをアルゴリズム的に行うことができないと判定される時にバインディングを指定するように作成者および／またはユーザにオーサリングコンポーネントによって促すことによって定式化することができる。
【００５９】
やはり、好ましくはないが、ビュー部分５００の一部またはすべてを、スプレッドシートによって実施することができる。たとえば、単一のスプレッドシートが、１つまたは複数のビューコンポーネントの基礎として働くことができ、そのビューコンポーネントのそれぞれの入力パラメータ（１つまたは複数）は、対応するスプレッドシートセル内で表される。ビューコンポーネントの関連するビューコンストラクションロジックを、少なくとも部分的にスプレッドシートプログラム内のリンクされた式を使用して表すことができる。スプレッドシートプログラムのレンダリング能力、マクロ、またはある他の実行可能プログラムを使用して、対応するビジュアルアイテムのレンダリングを完成させることができる。しかし、前に述べたように、このスプレッドシートベースの実施態様は、好ましい実施形態ではなく、したがって、この説明は、ビュー部分５００のより一般的な実施形態に戻る。
【００６０】
前に述べたように、ビューアイテムは、アニメーションを含むことができる。単純な例を挙げると、たとえば、ある会社の、販売地域による所与の時点（所与の暦四半期）の過去の収入、予測収入、広告宣伝費、および利益をプロットする棒グラフを検討されたい。棒グラフを、所望のタイムスパン内の暦四半期ごとに描くことができる。ここで、これらのグラフのうちの１つ、たとえば、タイムスパン内の最も古い時のグラフを描き、１／２秒おきにそれを次のタイムスパン（たとえば、次の四半期）のグラフに置換すると想像されたい。その結果は、地域ごとの利益、売上、および広告宣伝費を表す棒が、アニメーションが進行する時に高さにおいて変化するのを見ることである。この例では、時間期間ごとのグラフが、アニメーションの「セル」であり、セルは、動きの間の瞬間を示し、次々に示されるセルの集合は、動きをシミュレートする。従来のアニメーションモデルは、組込みのハードコーディングされたグラフタイプの経時的なアニメーションを可能にする。
【００６１】
しかし、パイプライン２０１を使用すると、対照的に、すべての種類のビジュアルをアニメートすることができ、アニメーションを、ビジュアルコンポーネントのパラメータの任意の１つまたは任意の組合せを変更することによって駆動することができる。上の棒グラフの例に戻って、時間によるアニメーションではなく、広告宣伝費によるアニメーションを行うと想像されたい。このアニメーションの各「セル」は、広告宣伝費の所与の値に関する経時的な売上および利益を示す棒グラフである。したがって、広告宣伝費が変更される時に、棒は、広告宣伝費の変化に応答して伸び縮みする。
【００６２】
アニメートされたデータディスプレイの威力は、それらが、どのパラメータが他のパラメータの変化に最も敏感であるのかを非常に目に見えるものにすることである。というのは、各パラメータの値がアニメーションパラメータの変更に応答してどれほど速くおよびどれほど大きく変化するのかが即座に見えるからである。
【００６３】
また、パイプライン２０１は、次の特性に起因して、アニメーションを行う能力において区別される。
【００６４】
第１に、アニメーション変数のステップのシーケンスを、事前定義の範囲にわたるステップの固定されたシーケンスであることに対して、モデルの分析によって計算することができる。たとえば、アニメーション変数として広告宣伝費を変更する例で、指定されるものが、「ステップごとに、広告宣伝費を５％だけ増やす場合の広告宣伝費によってアニメーションを行う」または「広告宣伝費がそのステップの総経費の１０％である場合」であると想像されたい。はるかにより洗練された例は、「広告宣伝費が経時的な売上の変化の割合を最大化するように最適化された場合の広告宣伝費によってアニメーションを行う」である。言い換えると、ソルバは、売上の増加の割合が最大化されるように、経時的に（すなわち、四半期などの連続する時間期間ごとに）費やされる広告のステップのセットを判定する。ここで、ユーザは、おそらく、広告宣伝費を変更することによって売上をどれほど速く増やすことができるかを知りたいだけではなく、その成長を達成する広告宣伝費の四半期ごとの量をも知りたい（値のシーケンスを、複合ビジュアルの一部としてプロットすることができる）。
【００６５】
第２に、伝統的なデータグラフだけではなく、すべての種類のビジュアルをアニメートすることができる。たとえば、ａ）対気速度パラメータによってアニメートされ、２）タービンの回転速度が対気速度の関数であり、３）タービンベアリングの温度が対気速度の関数である、ジェットエンジンのコンピュータ支援設計（ＣＡＤ）モデルを検討されたい。ジェットエンジンは、タービンブレードが完全性を失うかベアリングが過熱するかのいずれかになる前にタービンをどれほど速く回転できるかに関する制限を有する。したがって、このアニメーションでは、我々は、対気速度が変更される時に、タービンブレードおよびベアリングの色が、青（安全）から赤（臨界）に変更されなければならないことを望む。「安全」および「臨界」のタービンＲＰＭおよびベアリング温度の値は、これらの部品の物理的特性に基づいてモデルによって計算することができるであろう。ここで、アニメーションが、定義された範囲にわたって対気速度を変更する時に、我々は、タービンブレードおよびベアリングのそれぞれの色が変化するのを見る。ここで興味深いのは、どれが最初に臨界に達するのか、およびどちらかが臨界への突然の（制御がきかない）進行を経験するかどうかに注意することである。この種類の影響は、グラフまたは一連の図を見ることによって区別するのがむずかしいが、アニメーションでは即座に明白になる。これは、任意のパラメータ（対気速度）によって任意のビジュアル（ＣＡＤモデル）をアニメートする１つの例にすぎず、アニメーションは、さらに他の任意のパラメータ（タービンＲＰＭおよびベアリング温度）に影響する。任意のビジュアル（１つまたは複数）の任意のパラメータ（１つまたは複数）を、アニメーション変数として働く任意の所望のパラメータ（１つまたは複数）に従ってアニメートすることができる。
【００６６】
第３に、パイプライン２０１を、データおよびパラメータをユーザによって変更できるようにするために、ストリームの途中で停止することができ、その後、アニメーションを、再開始するか再開することができる。したがって、たとえば、ジェットエンジンの例では、制御のきかない加熱が所与の対気速度で始まることがわかる場合に、ユーザは、その制御のきかない加熱が始まる点でアニメーションを停止し、ベアリングまたはベアリング表面材料の種類などのエンジン設計判断基準を変更し、その後、その変更の影響を見るためにアニメーションを継続することができる。
【００６７】
本明細書で論じる他の能力と同様に、アニメーションを、作成者によって定義することができ、かつ／またはさまざまなシナリオをテストするためにユーザが操作するために残しておくことができる。たとえば、モデルを、ユーザ自身が選択するパラメータに従って、および／またはユーザが選択するアニメーション変数のデータ範囲にわたって、いくつかのビジュアルをユーザによってアニメートすることを可能にするように作成することができる（計算された範囲が望まれる場合に、その範囲を指定する能力を含む）。そのようなアニメーションを、他のｗｈａｔ−ｉｆ比較ディスプレイのように、並べて表示することもできる。たとえば、ユーザは、将来の異なる一般の金利または異なる広告宣伝費ランプ（ａｄｖｅｒｔｉｓｉｎｇ ｅｘｐｅｎｓｅｓ ｒａｍｐ）を有する２つのシナリオで、時間によってアニメートされる経時的な売上および利益のアニメーションを比較することができる。ジェットエンジンの例では、ユーザは、ベアリング設計を変更する前と後との両方の場合のエンジンのアニメーションを比較することができる。
【００６８】
この点で、ビュー構成を実際に構成するために構成フレームワークをどのように使用できるのかの特定の例を、図７に関して説明し、図７は、室内にレイアウトされた家具を有する部屋レイアウト７０１を含み、風水メータ７０２をも含むビュー構成の３Ｄレンダリング７００を示した。この例は、単に、本明細書で説明される原理を、ドメインにかかわりなく任意のビュー構成にどのように適用できるのかを示すために提供される。したがって、図７の例および本明細書で説明されるすべての他の例のビュー構成は、本発明のより広い範囲を定義するのではなく、厳密に、非限定的な具体的な例を参照することによって抽象概念をより十分に理解することを可能にする例にすぎないと見なされねばならない。本明細書で説明される原理を、無数のさまざまなビュー構成を構築するために適用することができる。それでも、具体的な例の参照は、より広義の抽象的な原理を明瞭にすることができる。
【００６９】
図８は、ビュー構成を生成する方法８００の流れ図を示す。方法８００を、図２のパイプライン環境２００によって実行することができ、したがって、図２のパイプライン環境２００を頻繁に参照すると同時に、それぞれ図２のパイプラインの特定の部分を示す図３から５を参照して、説明する。方法８００を、任意のビュー構成を構築するために実行することができるが、方法８００を、図７のビュー構成７００に関して説明する。方法８００の行為のいくつかは、図２のデータ部分２１０によって実行することができ、図８の左の列で見出し「データ」の下にリストされている。方法８００の他の行為は、図２の分析部分２２０によって実行することができ、図８の左から２番目の列で見出し「分析」の下にリストされている。この方法の他の行為は、図２のビュー部分２３０によって実行することができ、図８の右から２番目の列で見出し「ビュー」の下にリストされている。方法８００の行為の１つは、レンダリングモジュールによって実行することができ、図８の右の列で見出し「他」の下にリストされている。
【００７０】
図８を参照すると、データ部分は、どのビジュアルアイテムが表示されるのかまたはビジュアルアイテムのうちの所与の１つまたは複数がどのように表示されるのかに少なくとも集合的に影響する入力データにアクセスする（行為８１１）。たとえば、図７を参照すると、入力データは、家具のアイテムのそれぞれのビューコンポーネントを含むことができる。たとえば、長椅子、椅子、植物、机、花、および部屋自体のそれぞれを、対応するビューコンポーネントによって表すことができる。ビューコンポーネントは、そのビューコンポーネントに適切な入力パラメータを有することができる。たとえば、アニメーションが使用される場合に、入力パラメータのいくつかが、アニメーションの流れに影響する場合がある。パラメータのいくつかが、ビジュアルアイテムの表示に影響する可能性があり、いくつかのパラメータが影響しない可能性がある。
【００７１】
たとえば、部屋自体を、ビューコンポーネントとすることができる。入力パラメータのいくつかは、部屋の寸法、部屋の方位、壁の色、壁のテクスチャ、床の色、床のタイプ、床のテクスチャ、室内の光源の位置および強さなどを含むことができる。このビュー構成では必ずしも反映されないが、この部屋コンポーネントの他のビューおよび使用で反映される可能性がある部屋パラメータもある可能性がある。たとえば、部屋パラメータは、度、分、秒単位の緯度および経度で表された部屋の位置を有することができる。部屋パラメータは、部屋コンポーネントの作成者の識別および部屋の平均賃貸コストを含む可能性もある。
【００７２】
室内のさまざまなコンポーネントを、対応するパラメータ化されたビューコンポーネントによって表すこともできる。たとえば、各植物を、鉢のスタイル、鉢の色、鉢の寸法、植物の色、植物の回復力、太陽光への植物の依存性、植物の毎日の水摂取量、植物の毎日の酸素産生、植物の位置、および類似物を指定する入力パラメータを用いて構成することができる。やはり、表示されているものの性質に依存して、これらのパラメータのいくつかは、ディスプレイがどのようにレンダリングされるのかに影響する可能性があり、他のパラメータは影響しない可能性がある。
【００７３】
風水メータ７０２も、ビューコンポーネントとすることができる。このメータは、直径、メータの直径内に含まれるくさび形の個数、テキストの色、および類似物などの入力パラメータを含むことができる。風水メータのさまざまなくさび形も、ビューコンポーネントとすることができる。その場合に、それらのビューコンポーネントへの入力パラメータを、タイトル（たとえば、水、山、雷、風、火、地、沢、天）、おそらくはくさび形内に現れるグラフィック、色調、または類似物とすることができる。
【００７４】
分析部分は、入力データをモデルパラメータにバインドし（行為８２１）、出力モデル変数を判定し（行為８２２）、出力モデル変数について解くためにモデルパラメータの間のモデル固有分析的関係を使用する（行為８２３）。行為８２１のバインドする動作は、上で述べたものであり、本質的に、モデル作成者が快適なシンボルを使用して作成者がモデル分析の式、ルール、および制約を定義することを可能にする際の柔軟性を可能にする。図１０から１６に関して説明するより複雑なソルバは、出力モデル変数について解く（行為８２３）ように働くことができる。
【００７５】
出力モデル変数の識別は、解く動作ごとに異なる可能性がある。モデルパラメータが同一のままである可能性がある場合であっても、どのモデルパラメータが出力モデル変数であるのかの識別は、特定のモデルパラメータにバインドするためのデータの可用性に依存する。これは、ユーザが所与のビュー構成でｗｈａｔ−ｉｆシナリオを実行することを可能にすることに関して注目すべき密接な関係を有する。
【００７６】
たとえば、図７の風水部屋の例で、ユーザが、彼らの居間に置くために新しい椅子を買ったと仮定する。ユーザは、部屋のデザインをパイプラインへのデータとして提供することができる。これを、部屋の寸法を入力し、おそらくは仮想部屋内の実際の家具が実際の部屋に配置される適当な位置にドラッグアンドドロップするためにユーザが仮想家具を選択することを可能にする選択ツールを提供するようにオーサリングコンポーネントがユーザに促すことによって、容易にすることができる。次に、ユーザは、ユーザによって購入された新しい椅子の特性を有するように編集できる１つの家具を選択することができる。次に、ユーザは、その椅子を部屋にドラッグアンドドロップすることができる。風水メータ７０２は、自動的に更新するはずである。この場合に、椅子の位置および他の属性が、入力モデル変数になり、風水スコアが、出力モデル変数になる。ユーザが、仮想椅子をさまざまな位置にドラッグする時に、風水メータの風水スコアは、更新し、したがって、ユーザは、仮想椅子をさまざまな位置に配置することの風水結果をテストすることができる。ユーザが、どれが最良の風水を与えるのかを調べるために可能なすべての位置に椅子をドラッグする必要を避けるために、ユーザは、椅子をその現在位置から特定の方向に移動することが状況をよりよくまたはより悪くするかどうか、およびどれほどよりよくまたはより悪くするのかをユーザに知らせるローカルな視覚的手がかり（たとえば、傾斜した線または矢印など）を得ることができる。
【００７７】
しかし、ユーザは、従来のビュー構成には見られない他のことを行うこともできる。ユーザは、出力モデル変数を実際に変更することができる。たとえば、ユーザは、風水メータ内で所望の風水スコアを示し、出力モデル変数として仮想椅子の位置を残すことができる。その後、ソルバは、出力モデル変数について解き、少なくとも指定された風水スコアを達成する椅子の提案される１つまたは複数の位置を提供する。ユーザは、複数のパラメータを出力モデル変数にすることを選択することができ、システムは、出力モデル変数に対する複数の解決策を提供することができる。これは、図１０から１６に関してさらに詳細に説明される複雑なソルバによって容易にされる。
【００７８】
図８に戻って、出力モデル変数について解かれた後に、モデルパラメータが、パラメータ化されたビューコンポーネントの入力パラメータにバインドされる（行為８３１）。たとえば、風水の例では、未知の風水スコアについて解かれた後に、スコアが、入力パラメータとして風水メータビューコンポーネントに、またはおそらくはそのメータに含まれる適当なくさび形にバインドされる。代替案では、風水スコアが入力モデル変数である場合に、仮想椅子の位置を、それについて解き、入力パラメータとして椅子ビューコンポーネントに提供することができる。
【００７９】
どのようにしてソルバが式を再配置し、すべてが１つの分析モデルから駆動される入力モデル変数および出力モデル変数の指定を変更するのかの原理を示す単純化された例を、これから提示する。ユーザ自身が、式を再配置する必要はない。この単純化された例は、風水のルールを正確に表さない可能性があるが、それでも原理を示す。部屋の総合的風水（ＦＳ）（ＦＳｒｏｏｍ）が、椅子のＦＳ（ＦＳｃｈａｉｒ）および植物のＦＳ（ＦＳｐｌａｎｔ）と等しいと仮定する。ＦＳｃｈａｉｒが、定数Ａと壁からの椅子の距離ｄとの積と等しいと仮定する。ＦＳｐｌａｎｔが、定数Ｂであると仮定する。部屋の総ＦＳは、ＦＳｒｏｏｍ＝Ａ＊ｄ＋Ｂである。ｄが入力モデル変数である場合には、ＦＳｒｏｏｍは出力変数であり、メータ上に示されるその値は、ユーザが椅子の位置を変更する時に変化する。ここで、ユーザがメータをクリックし、これを入力変数にし、ｄを未知の出力モデル変数状況にすると仮定する。この場合に、ソルバは、上の式をｄ＝（ＦＳｒｏｏｍ−Ｂ）／Ａとして有効に内部的に書き直す。その場合に、ビューコンポーネントは、ユーザがメータ上で所望の値ＦＳｒｏｏｍを変更する時に、椅子をあちこちに動かし、ｄすなわち壁からのその距離を変更することができる。
【００８０】
次に、ビュー部分は、おそらくはビュー構成内のビューアイテムのコンストラクションを駆動するために、入力パラメータ（１つまたは複数）がある場合にその入力パラメータを使用してビューコンポーネントに関連するコンストラクションロジックを実行することによって、ビジュアルアイテムのビューを構築する（行為８３２）。その後、このビューコンストラクションを、レンダリングモジュールに供給することができ、その後、レンダリングモジュールは、そのビューコンストラクションをレンダリング命令として使用する（行為８４１）。
【００８１】
一実施形態では、ビューを構築するプロセスが、ソルバによって実行されるデータ変換として扱われる。すなわち、所与の種類のビュー（たとえば、棒グラフを検討されたい）について、グラフィックスハードウェアを駆動するためにレンダリングソフトウェアが必要とする低水準ジオメトリおよび関連する属性のすべてを符号化する表示可能出力データ構造（シーングラフと呼ばれる）に入力データを変換することによってビューを生成する、ルール、式、および制約からなるモデルがある。棒グラフの例では、入力データは、たとえば、グラフタイトル、軸ラベルその他などのものの属性と一緒に、プロットされるデータ系列である。棒を生成するモデルは、１）何本の棒を描くべきかを判定するためにデータ系列が何個のエントリからなるのかを数え、２）各軸のスケールおよび開始値／終了値などを計算するためにデータ系列がまたがる範囲（最小、最大）を計算し、３）以前に計算されたスケール係数に基づいてデータ系列内のデータ点ごとに棒の高さを計算し、４）タイトルがグラフに関して正しく配置され、センタリングされるようにするためにタイトルの開始位置およびサイズを計算するためにグラフタイトル内に何個の文字があるのかを数えるなどを行う、ルール、式、および制約を有する。要するに、モデルは、入力データに基づいて幾何形状のセットを計算するように設計され、これらの幾何形状は、タイプ「シーングラフ」の階層データ構造内に配置される。言い換えると、シーングラフは、モデルが入力データに基づいてそれについて解く出力変数である。したがって、作成者は、その作成者が任意の種類のモデルを作成し、カスタマイズし、構成するのに使用するものと同一のフレームワークを使用して、完全に新しい種類のビューを設計し、既存のビューをカスタマイズし、前から存在するビューを複合物に構成することができる。したがって、プログラマではない作成者が、新しいコードを立案することなく新しいビューを作成することができる。
【００８２】
図２に戻って、ユーザ相互作用応答モジュール２５０が、ユーザがビュー構成と相互作用する時を検出し、パイプラインに適当に応答させることを想起されたい。図９は、ビュー構成とのユーザ相互作用に応答する方法９００の流れ図を示す。具体的に言うと、ユーザ相互作用応答モジュールは、ビューを再生成するためにパイプラインのどのコンポーネントがさらなる作業を実行すべきかを判定し、ユーザ相互作用を表すデータまたは少なくともユーザ相互作用に依存するデータをそのパイプラインコンポーネントに供給もする。一実施形態では、これが、逆（アップストリーム）ビュー／分析／データ方向に走り、（ダウンストリーム）データ／分析／ビューパイプラインに平行である、変換パイプラインを介して行われる。
【００８３】
相互作用は、アップストリームパイプラインへイベントとしてポストされる。データ／分析／ビューパイプライン内の各トランスフォーマは、着信相互作用データを処理するアップストリームトランスフォーマを提供する。これらのトランスフォーマは、ヌル（パススルー、パスから外れて最適化される）またはさらにアップストリームに供給される相互作用データに対して変換動作を実行できるのいずれかとすることができる。これは、１）ソースデータに影響しないビュー操作などのアップストリーム変換に影響しない相互作用挙動を、パイプライン内の最も適当な（最もダウンストリームの）点で処理でき、２）中間トランスフォーマが、さらにアップストリームのトランスフォーマから最終的に来る最後の更新の前にヒューリスティック的に判定された更新をダウンストリームに送り返すことによってビュー更新性能を最適化できるという点で、パイプラインの向上する性能および応答性を提供する。たとえば、データ編集相互作用の受取時に、ビューレベルトランスフォーマは、ビューに関するシーングラフへ直接に即座のビュー更新を行うことができ（それが解釈の仕方を知っている編集について）、最終的な完全な更新は、アップストリームデータトランスフォーマから後に来、このアップストリームデータトランスフォーマでは、ソースデータが実際に編集される。
【００８４】
所与のビュー相互作用のセマンティクスが、必要とされる基礎になるデータ編集への自明ではないマッピングを有する時には、中間のトランスフォーマが、必要なアップストリームマッピングを提供することができる。たとえば、計算結果のグラフ上の点をドラッグすることは、グラフ上の計算された値を供給する複数のソースデータアイテムの新しい値を計算する逆方向解決を要求することができる。ソルバレベルアップストリームトランスフォーマは、必要な解決を呼び出し、必要なデータ編集をアップストリームに伝搬させることができる。
【００８５】
図９は、ビューコンストラクションとのユーザ相互作用に応答する方法９００の流れ図を示す。ユーザがディスプレイ上のビュー構成のレンダリングと相互作用したことを検出する時に（行為９０１）、まず、ユーザ相互作用がビューの再生成を必要とするか否かが判定される（判断ブロック９０２）。これは、図２のユーザ相互作用応答コンポーネント２５０によって解釈されるイベントをレンダリングエンジンが送出することによって実行することができる。ユーザ相互作用が、ビューの再生成を必要としない場合に（判断ブロック９０２のＮｏ）、パイプラインは、ビューを再構築するためにさらなるアクションを全く実行しない（行為９０３）が、レンダリングエンジン自体は、ビューに対するある変換を実行することができる。そのようなユーザ相互作用の例を、ユーザがビューコンストラクションのレンダリングのコントラストを高める場合またはビューコンストラクションを回転する場合とすることができる。これらのアクションは、レンダリングエンジン自体によって行うことができるので、パイプラインは、ユーザ相互作用に応答してビューを再構築するために作業を実行する必要がない。
【００８６】
その一方で、ユーザ相互作用のタイプが、ビューコンストラクションの再構成を必要とすると判定される場合に（判断ブロック９０２のＹｅｓ）、ビューは、パイプラインによって再構築される（行為９０４）。これは、パイプラインに供給されたデータのある変更を含むことができる。たとえば、風水の例で、ユーザが、仮想部屋内で仮想椅子の位置を移動し、したがって、仮想椅子コンポーネントの位置パラメータが、変更されると仮定する。イベントが点火され、仮想椅子の位置を表す対応するモデルパラメータも変更されなければならないことを分析部分に知らせる。次に、分析コンポーネントは、風水スコアについて再び解き、風水メータまたはくさび形の対応する入力パラメータを再設定し、風水メータに、椅子の新しい位置に適切な最新の風水スコアを用いて更新させる。
【００８７】
ユーザ相互作用は、以前に既知であったモデルパラメータが、現在は未知であることと、以前に未知のパラメータが、現在は既知であることとを要求する場合がある。それは、以前に指定された入力モデル変数が出力モデル変数になり、その逆になる、入力モデル変数および出力モデル変数の指定の変更を必要とする可能性がある複数の可能な例の１つである。その場合に、分析部分は、新しい出力モデル変数（１つまたは複数）について解き、これによって、ビュー構成の再コンストラクションを駆動する。
【００８８】
このタイプの再コンストラクションは、異なるデータによって駆動されるビュー構成の代替ビューを構築する際に役立つ。しかし、これは、あるビュー構成から次のビュー構成へのビューの遷移を発生させることによって、物語を話すことにも役立つ。伝統的に、この物語を話すことは、視覚化内のデータの複数の異なる構成のスナップショットを撮り（視覚化も異なることを意味する）、その後、これらのスナップショットをスライドの間の単純な遷移を有するスライドにすることによって行われてきた。
【００８９】
しかし、この手法は、おそらくは風水の例の部屋の視覚化またはおそらくはトラクタなどの機械装置の複雑な部分の視覚化など、より洗練されたビジュアルをよくは得ない。グラフで使用される単純な視覚化とは異なって、実際の世界または他の洗練された視覚化では、変更できるものの多数の順列がある。さらに、ビジュアルに対する可能な変更内に連続体がある（たとえば、トラクタアームが複数の位置に連続的に移動することができ、そのアーム移動が、多数の他の要素の再位置決め（おそらくは連続的な）につながる可能性がある。または、おそらく、任意の個数の家具もしくは他の部屋要素が、あちこちに移動され、変更される場合がある。
【００９０】
採用される別の手法は、ストーリーボードへの視覚化のスクリプト作成である。ここでの問題は、スクリプトをデータ駆動にすることがむずかしく、スクリプトが、ユーザが行えるデータおよびビジュアルの非常に多数の変更およびビジュアルに対する結果の伝搬される変更を、データおよびビジュアル内の制約および他の関係を尊重する形で予言し、可能にすることがむずかしいことである。
【００９１】
その一方で、本明細書で説明されるパイプライン２０１を使用して構築される時には、非常に複雑なビュー構成を構築することができる。各ビュー構成を、複雑なシーンのストーリーボード内の１シーンとすることができる。ストーリーボードは、さまざまな可能な形のうちの１つでビュー構成を変更することによって、あるシーンから別のシーンに遷移することができる。たとえば、遷移は、次の遷移のうちの１いくつかまたはすべてを含むことができる。
【００９２】
１）ビジュアル変換：この変換では、ビュー構成を駆動するデータが同一のままであることができるが、ビュー構成を構築するのに使用されるビューコンポーネントのセットが、変化することができる。言い換えると、データに対するビューが変化する。たとえば、データのセットは、温度と、風速と、落雷などの環境アクティビティのシーケンスを表す他のデータとを含む環境データを含むことができる。１つのシーンが、その環境を通って飛行する航空機の文脈でそのデータを明示することができる。ストーリーボード内の次のシーンは、完全に同一の環境条件にさらされる別の航空機について話すことができる。
【００９３】
２）データ変換：ここでは、ビューコンポーネントは同一のままになる。言い換えると、ビューは同一に保たれるが、ビジュアルプロパティに影響するデータが変化し、これによって、ビューがどのようにレンダリングされるのかが変更される。たとえば、データが変化することができ、かつ／またはモデルパラメータへのデータのバインディングが変化する。
【００９４】
３）座標系変換。ここでは、データとビューコンポーネントのセットとが、同一のままであることができるが、座標系が、ある座標系から別の座標系に変更される。
【００９５】
４）ターゲット世界変換。ここでは、すべてが同一のままであることができるが、ターゲット仮想世界が変化する。たとえば、あるジオメトリを、別のジオメトリに重畳することができる。ジオメトリの例および重畳されたジオメトリを、後で提供する。
【００９６】
ソルバフレームワーク
図１０は、図４のソルバ４４０の例を表すことができるソルバ環境１０００を示す。ソルバ環境１０００を、ソフトウェア、ハードウェア、または組合せで実施することができる。ソルバ環境１０００は、特殊化されたソルバのコレクション１０１０の動作を管理し、調整するソルバフレームワーク１００１を含む。コレクション１０１０は、３つの特殊化されたソルバ１０１１、１０１２、および１０１３を含むものとして図示されているが、省略記号１０１４は、他の個数の（すなわち、３つより多いまたは３つより少ない）特殊化されたソルバがあることもできることを表す。さらに、省略記号１０１４は、特殊化されたソルバのコレクション１０１０が拡張可能であることをも表す。モデル分析についいて助けることができる新しい特殊化されたソルバが、発見されかつ／または開発される時に、これらの新しい特殊化されたソルバを、既存の特殊化されたソルバを補足するため、またはおそらくは既存のソルバのうちの１つもしくは複数を置換するために、コレクション１０１０に組み込むことができる。たとえば、図１０は、新しいソルバ１０１５が、ソルバ登録モジュール１０２１を使用してコレクション１０１０に登録されようとしていることを示す。一例として、新しいソルバを、おそらくは、１つまたは複数の既知の値を受け入れ、１つまたは複数の未知の値について解くシミュレーションソルバとすることができる。他の例は、連立一次方程式、微分方程式、多項式、積分、ルートファインダ（ｒｏｏｔ−ｆｉｎｄｅｒ）、ファクトライザ（ｆａｃｔｏｒｉｚｅｒ）、オプティマイザなどのソルバを含む。すべてのソルバが、数モード、シンボリックモード、または混合−数シンボリックモードで働くことができる。解の数部分は、パラメータ化されたレンダリングダウンストリームを駆動することができる。解のシンボリック部分は、部分的解レンダリングを駆動することができる。
【００９７】
特殊化されたソルバのコレクションは、出力モデル変数について解くのに適するすべてのソルバを含むことができる。たとえば、モデルが、自転車の抵抗を判定する場合には、複素微積分方程式を解くことを保証することができる。その場合に、特殊化された複素微積分ソルバを、おそらくは既存の式ソルバを補足するか置換するためにコレクション１０１０に組み込むことができる。一実施形態では、各ソルバは、特定の種類の分析関係において１つまたは複数の出力モデル変数について解くように設計される。たとえば、ある式の未知数について解くように構成された１つまたは複数の式ソルバがあるものとすることができる。未知数について解くためにルールを適用するように構成された１つまたは複数のルールソルバがあるものとすることができる。これによって未知数について解くために制約を適用するように構成された１つまたは複数の制約ソルバがあるものとすることができる。他のタイプのソルバは、たとえば、これによって対応する出力データを構築するために入力データを使用してシミュレーションを実行するシミュレーションソルバとすることができる。
【００９８】
ソルバフレームワーク１００１は、これによって１つまたは複数の出力モデル変数について解かせるために、コレクション１０１０内の特殊化されたソルバのうちの１つまたは複数またはすべての処理を調整するように構成される。次に、ソルバフレームワーク１００１は、それについて解かれた値を１つまたは複数の他の外部コンポーネントに供給するように構成される。たとえば、図２を参照すると、ソルバフレームワーク１００１は、パイプラインのビュー部分２３０にモデルパラメータ値を提供することができ、その結果、解く動作が、これによって、ビューコンポーネントがビューアイテムをレンダリングするためにどのように実行するのかに影響し、またはこれによってビューアイテムに関連する他のデータに影響するようになる。解くことのもう１つの潜在的な影響として、モデル分析自体を変更することができる。たとえば、これを実施できる多数の例のうちの１つとして、モデルを、変更可能なルールセットを伴って作成することができ、その結果、所与の解決中に、当初にインアクティブであるいくつかのルール（１つまたは複数）および／または制約（１つまたは複数）がアクティブ化され、当初にアクティブであるいくつかのルール（１つまたは複数）および／または制約（１つまたは複数）がインアクティブ化されるようになる。式を、この形で変更することもできる。
【００９９】
図１１は、ソルバフレームワーク１００１がコレクション１０１０内の特殊化されたソルバの中で処理を調整する方法１１００の流れ図を示す。図１１の方法１１００を、これから、図１０のソルバ環境１０００を頻繁に参照して説明する。
【０１００】
ソルバフレームワークは、モデルパラメータのどれが入力モデル変数であるのかを識別すること（行為１１０１）と、モデルパラメータのどれが出力モデル変数であるのかを識別すること（行為１１０２）と、モデルパラメータの間の関係を定義するモデル分析を識別すること（行為１１０３）とによって解決動作を開始する。この情報を考慮して、ソルバフレームワークは、モデルパラメータ内の依存関係を分析する（行為１１０４）。モデルパラメータの固定されたセットを考慮し、モデル分析の固定されたセットを考慮しても、依存関係は、モデルパラメータのどれが入力モデル変数であり、モデルパラメータのどれが出力モデル変数であるのかに依存して変化する場合がある。したがって、システムは、解決動作が実行されるたびに、どのモデルパラメータが入力であるのかの識別を使用して、モデル分析に基づいて、依存関係グラフを推論することができる。ユーザが各解決の依存関係グラフを指定する必要はない。すべての解決動作について依存関係を評価することによって、ソルバフレームワークは、１つの解決動作中に１つまたは複数のモデル変数の１つのセットについて解き、次の解決動作中に１つまたは複数のモデル変数の別のセットについて解く柔軟性を有する。図２から５の文脈では、それは、ビュー構成との相互作用によってどれが入力でありどれが出力であるのかをユーザが指定するためのより高い柔軟性を意味する。
【０１０１】
いくつかの解決動作では、モデルが、出力モデル変数を全く有しない場合がある。その場合に、解決は、ひとまとめにされた既知のモデルパラメータ値のすべてが、そのモデルについて分析によって表されたすべての関係を満足することを検証する。言い換えると、任意の１つのデータ値が消去され、未知数にされ、解かれる場合に、消去された値は、モデルによって再計算され、前と同一になるはずである。したがって、ロードされたモデルが、解かれた形で既に存在する可能性があり、もちろん、未知数を有し、解決を得るモデルも、解かれた形で存在する。重要なものは、解かれたモデルのビューと相互作用するユーザが、それでも、ビューを編集することができ、これが、１つまたは複数のデータ値を変更するという影響を有する場合があり、したがって、データ値の新しいセットが分析と一貫するようにするために出力モデル変数のデータ値の再計算を試みる再解決を引き起こす場合があることでる。どのデータ値をユーザが編集できるか（モデルが出力モデル変数を伴って始まるか否か）は、作成者によって制御され、実際に、これは、どの変数が許容される未知数を表したかを作成者が定義することによって制御される。
【０１０２】
まず他の式内の他の未知数について解くことなく独立に解くことができる１つまたは複数の未知数を有する式がある場合に（判断ブロック１１０５のＹｅｓ）、これらの式を、おそらくは他の解くステップと並列にさえ、いつでも解くことができる（行為１１０６）。その一方で、まず別の式内の未知数について解くことなく解くことができない式がある場合には、解決依存関係が見つかっている。その場合には、その式は、別の式に関する動作の特定の順序を定義する関係構造（依存関係ツリーなど）の一部になる。
【０１０３】
他の式からの相互に連結された解決依存関係を有する式の場合には、分析された依存関係に基づいて、特殊化されたソルバの実行の順序が判定される（行為１１０７）。次に、ソルバが、判定された順序で実行される（行為１１０８）。一例では、モデル分析が式、制約、およびルールとして表される場合に、実行の順序を、１）依存関係を有する式または独立の式として完全に解くことができるものではない式が、制約として書き直され、２）制約が解かれ、３）式が解かれ、４）ルールが解かれるとすることができる。ルールを解くことが、データを更新させる場合がある。
【０１０４】
ソルバが指定された順序で実行された後に、解くことを停止すべきか否かが判定される（判断ブロック１１０９）。たとえば、出力モデル変数のすべてについて解かれた場合、または、出力モデル変数のすべてについて解かれてはいないが、特殊化されたソルバが出力モデル変数のより多くについて解くためにそれ以上何もすることができない場合には、解くプロセスを停止しなければならない。解くプロセスを終了してはならない場合に（判断ブロック１１０９のＮｏ）、このプロセスは、依存関係の分析（行為１１０４）に戻る。しかし、今回は、入力モデル変数および出力モデル変数のアイデンティティが、それについて解かれた１つまたは複数の出力モデル変数に起因して変化している場合がある。その一方で、解くプロセスを終了しなければならない場合に（判断ブロック１１０９のＹｅｓ）、解決は終了する（行為１１１０）。しかし、出力モデル変数が多すぎるのでモデルを完全には解くことができない場合には、そのモデルは、それでも、部分的な解の生成に成功している可能性があり、この場合に、出力モデル変数は、解決がどれほど進行できたのかを反映するシンボリック値を割り当てられている。たとえば、モデルが式Ａ＝Ｂ＋Ｃを有し、Ｂが、「２」であることがわかっており、入力モデル変数であるが、Ｃが出力モデル変数であり、Ａも出力モデル変数であり、それについて解かれる必要がある場合には、モデルソルバは、Ｂは既知だがＣが未知なので、Ａの数値を作ることができず、したがって、ソルバは、完全な解決ではなく、Ａの値として「２＋Ｃ」を返す。したがって、どの追加変数が既知になる（それに値を供給することによってまたは他の入力データから必要な値を成功して作ることができるさらなるルール／式／制約またはシミュレーションを追加することによってのいずれかで）必要があるのかは、作成者には明白である。
【０１０５】
既知のモデルパラメータのいずれかの値の変化があったことをソルバフレームワークが検出するたびに、ならびに／または既知のおよび未知のモデルパラメータのアイデンティティが変化したことをソルバフレームワークが判定するたびに、この方法１１００を繰り返すことができる。解くことは、少なくとも２つの形で進行することができる。第１に、モデルをシンボリックに完全に解くことができる場合（すなわち、すべての式、ルール、および制約をアルゴリズム的に書き直すことができ、その結果、計算可能な式が未知数ごとに存在するようになる場合）には、終了であり、その後、モデルが計算される。言い換えると、データ値は、未知数ごとに生成され、かつ／または調整が許可されるデータ値は、調整される。第２の可能な形として、モデルをシンボリックに完全に解くことができない場合には、モデルは、シンボリックに部分的に解かれ、その後、１つまたは複数の数値法を使用して必要な解をもたらすことができるかどうかが判定される。さらに、第１の場合であっても、数値法の使用が、シンボリック解決法の実行に対して、必要な値を計算するより高速の形である可能性があるかどうかが判定されるように、最適化ステップが行われる。シンボリック法がより高速である可能性があるが、シンボリック解決があまりに多数の項の書き直しおよび／またはあまりに多数のルール検索の書き直しを実行し、この方法を棄て、数値法を使用して解くことがより高速になる場合がある。
【０１０６】
図１２は、図１０のソルバ環境１０００の例を表すソルバ環境１２００を示す。この場合に、ソルバ調整モジュール１２１０は、入力モデル変数１２０１を受け取り、モデル変数１２０２（出力モデル変数を含む）が生成されるように、順方向ソルバ１２２１、シンボリックソルバ１２２２（または、「インバータ」）、および数値ソルバ１２２３を調整するように働く。順方向ソルバ１２２１、シンボリックソルバ１２２２、および数値ソルバ１２２３は、図１０のソルバコレクション１０１０内にある可能性があるソルバの例である。
【０１０７】
ソルバ調整モジュール１２１０は、対応するモデル変数を有するモデル分析の依存関係グラフを維持する。解決動作ごとに、ソルバ調整モジュール１２１０は、モデル変数のどれが入力モデル変数であり、モデル変数のどれが出力モデル変数であり、したがってそれについて解かれなければならないのかを判定することができる。
【０１０８】
順方向ソルバ１２２１は、順方向に解けるようになるために正しく提示されたモデル分析を解く。たとえば、モデル分析内に１つの式Ａ＝Ｂ＋Ｃだけがあり、ＢおよびＣが入力モデル変数である場合には、ＢおよびＣの値を式に入力し、Ａの結果の値を判定することによって、Ａについて、順方向解決を使用して解くことができる。
【０１０９】
シンボリックソルバ１２２２は、順方向に解けるようになるように、モデル分析を書き直す。たとえば、式Ａ＝Ｂ＋Ｃにおいて、入力変数であるのが変数ＡおよびＣであり、それについて解くべき出力変数が変数Ｂであると仮定する。この状況では、まずモデル分析を逆転する（この場合には、式を逆転する）ことなしに、モデル分析を順方向に解くことはできない。したがって、シンボリックソルバ１２２２は、式Ａ＝Ｂ＋ＣをＢ＝Ａ−Ｃとして書き直す。今や、変数Ｂの値を得るために入力変数ＡおよびＣが式Ｂ＝Ａ−Ｃに入力されるように、逆転された式を、順方向ソルバ１２２１による順方向解決にかけることができる。
【０１１０】
いくつかの式は、数学的に逆転可能ではなく、または、少なくとも、いくつかのタイプの式を逆転する方法はまだ発見されていない。さらに、式が逆転可能であるか、式をどのように逆転すべきかが知られている場合であっても、シンボリックソルバ１２２２が、単純に、式を逆転でない場合がある。または、おそらくは、数値的に解くことなどの他の解く方法に頼ることと比較して、シンボリックソルバ１２２２が式を逆転することが、単純に非効率的である。したがって、数値ソルバ１２２３は、モデル分析が正しく逆転可能ではない（逆転が不可能である、知られていない、またはシンボリックソルバによって使用可能にされないのいずれかのゆえに）場合に、モデル分析を使用してモデル分析を解くために提供される。
【０１１１】
ソルバ調整モジュール１２１０は、各解決動作を管理するように構成される。たとえば、図１３は、モデル分析について解くことができるように解決を管理する方法１３００の流れ図を示す。方法１３００を、ソルバ調整モジュール１２１０の指示の下でソルバ環境１２００によって管理することができる。
【０１１２】
ソルバ調整モジュール１２１０は、モデル分析のモデル変数のどれが特定の解決について入力変数（１つまたは複数）であり、モデル変数のどれが特定の解決について出力モデル変数（１つまたは複数）であるのかを識別する（行為１３０１）。たとえば、入力モデル変数および出力モデル変数が、図４でデータモデルバインダコンポーネント４１０によって定義される場合に、モデル変数の一定のセットを考慮しても、入力モデル変数および出力モデル変数のアイデンティティは、ある解決動作と次の解決動作とで変化する可能性がある。したがって、解決動作の調整は、ある解決動作と次の解決動作とで変化する可能性がある。たとえば、モデル分析の一定のセットを考慮しても、入力モデル変数に応じて、順方向解決が、ある解決動作に十分である場合があり、逆転および逆転された分析の順方向解決が、別の解決動作に十分である場合があり、おそらくは、数値解決が、さらに別の解決動作に十分である場合がある。
【０１１３】
しかし、パイプライン２０１の分析部分２２０の文脈で実施される場合には、モデル分析さえもが、前に述べたようにモデル分析が定式化されるかおそらくは他のモデル分析と組み合わされる時に変化する可能性がある。ソルバ環境１２００は、変化がある時に必ず入力モデル変数および出力モデル変数を識別することと、すべての変化したモデル分析を計上することと、適当に解くこととによって、これらの変化を計上することができる。
【０１１４】
解決ごとに、入力モデル変数および出力モデル変数が識別（行為１３０１）された後に、ソルバ調整モジュール１２１０は、出力パラメータ（１つまたは複数）の順方向解決が、まずモデル分析を逆転することなく入力モデル変数（１つまたは複数）を考慮して実行されるべきか否かを判定する（判断ブロック１３０２）。順方向解決が実行されるべきである場合に（判断ブロック１３０２のＹｅｓ）、順方向ソルバ１２２１が、モデル分析を順方向に解くようにされる（行為１３０３）。この順方向解決は、モデル分析全体の解決またはモデル分析の一部だけの解決とすることができる。後者の場合に、方法１３００を、今回のみ、順方向解決でそれについて解かれるモデル変数を含む入力モデル変数のより完全なセットを用いて、もう一度実行することができる。
【０１１５】
出力パラメータ（１つまたは複数）の順方向解決が、少なくともまずモデル分析を逆転することなしではなく、特定の解決について実行すべきではないと判定される場合に（判断ブロック１３０２のＮｏ）、次に、順方向解決を出力パラメータ（１つまたは複数）について解くことができるように、特定の解決についてモデル分析を逆転すべきか否かが判定される（判断ブロック１３０４）。モデル分析（またはモデル分析の少なくとも一部）を逆転すべきである場合に（判断ブロック１３０４のＹｅｓ）、モデル分析が、シンボリックソルバによって逆転される（行為１３０５）。その後、逆転されたモデル分析について、順方向解決を使用して解くことができる（行為１３０３）。やはり、モデル分析の一部だけについてこの形で解く場合には、方法１３００を、入力モデル変数の拡張されたセットを用いて、もう一度実行することができる。
【０１１６】
モデル分析を、特定の解決について逆転すべきではないと判定される場合に（判断ブロック１３０４のＮｏ）、数値ソルバが、数値法を使用して出力変数（１つまたは複数）について解くことができる（行為１３０６）。やはり、モデル分析の一部だけについてこの形で解く場合には、方法１３００を、入力モデル変数の拡張されたセットを用いて、もう一度実行することができる。
【０１１７】
したがって、どのモデル変数が入力であり、どのモデル変数がある解決動作から次の解決動作への出力であるのかにかかわりなく、さまざまなモデル分析について解くことができる、柔軟なソルバ環境１３００を説明した。
【０１１８】
図１４は、図１０に示されたソルバフレームワーク１００１によって実行できる別の方法１４００の流れ図を示す。具体的に言うと、ソルバは、モデル変数について解き（行為１４０１）、このモデル変数は、ビュー構成のビューコンポーネントのプロパティを定義することができる。たとえば、ソルバは、未知のモデル変数について解くのに既知のモデル変数を使用することができる。いくつかの例で、既知のモデル変数は、ソルバが上で図１０および１１に関して述べた依存関係ツリーなどの関係構造の一部を形成する時など、別のソルバによって提供される出力である場合がある。
【０１１９】
解決動作は、正規データの実際の変化を引き起こす（行為１４０２）。ソルバがモデル変数について解いた後に、ビュー構成のビューコンポーネントのプロパティに、解かれたモデル変数の値がセットされる（行為１４０３）。たとえば、解かれたモデル変数を、図５に示されたモデルパラメータ４１１の一部として提供することができ、このモデルパラメータ４１１を、第１のビューコンポーネント５２０の入力パラメータ５４２にバインドすることができる。いくつかの場合に、解かれたモデル変数について解くのに使用された既知のモデル変数が、第１のビューコンポーネント５２０の別のプロパティを定義する場合がある。その場合には、既知のモデル変数および解かれたモデル変数を、第１のビューコンポーネント５２０のさまざまな入力パラメータ５４２にバインドすることができる。他の例では、既知のモデル変数が、第１のビューコンポーネントが第２のビューコンポーネントの親または子である時など、第２のビューコンポーネント５２０のプロパティを定義する場合がある。これらの他の場合には、解かれたモデル変数を、第１のビューコンポーネント５２０の入力パラメータ５４２にバインドすることができ、既知のモデル変数を、第２のビューコンポーネント５２０の入力パラメータ５４２にバインドすることができる。
【０１２０】
ビューコンポーネントのプロパティに解かれたモデル変数の値をセットした後に、ビューコンポーネントを含むビュー構成が、レンダリングされる（行為１４０４）。
【０１２１】
望まれる場合には、さまざまな環境を、方法１４００に関連して使用することができる。たとえば、図１５は、方法１４００に関連して使用され得、ソフトウェア、ハードウェア、または組合せで実施され得る環境１５００を示す。具体的に言うと、環境１５００は、プロパティ−セッター１５０２ａ、１５０２ｂ、１５０２ｃの一部を形成し、かつ／またはこれによって呼び出され得る１つまたは複数のソルバ１５０１ａ、１５０１ｂ、１５０１ｃを含むことができる。ソルバ１５０１を、たとえば未知のモデル変数について解くのに既知のモデル変数を使用することによって、未知のモデル変数について解く（図１４の行為１４０１）ように構成することができる。さらに、プロパティ−セッター１５０２は、ビューコンポーネントのプロパティに、解かれたモデル変数の値をセットすることができる（図１４の行為１４０３）。しかし、プロパティ−セッター１５０２は、ソルバ１５０１を含む必要がなく、単純に既知のモデル変数を受け取り、その後、ビューコンポーネントのプロパティに受け取られたモデル変数の値をセットすることができる。
【０１２２】
図１６は、図１５に示された環境１５００によって実行できるもう１つの方法１６００の流れ図を示す。さらなる詳細で、環境１５００の第１のプロパティ−セッター１５０２ａが、呼び出される（行為１６０１）。第１のプロパティ−セッター１５０２ａおよび他のプロパティ−セッター１５０２は、望まれる場合に、図５に示されたモデル−ビューバインディングコンポーネント５１０によって呼び出され、かつ／またはその一部を形成することができる。
【０１２３】
呼び出された後に、第１のプロパティ−セッター１５０２ａは、ビュー構成のビューコンポーネントの第１のプロパティをセットする（行為１６０２）。たとえば、第１のプロパティ−セッター１５０２ａは、第１のプロパティにモデル変数１５０３ａの値をセットすることができる。いくつかの例で、第１のプロパティ−セッター１５０２ａは、単純に既知のモデル変数１５０３ａを受け取り、その後、受け取られたモデル変数の値を第１のプロパティにセットすることができる。他の例では、第１のプロパティ−セッター１５０２ａは、モデル変数１５０３ａについて解くことができるソルバ１５０１ａを呼び出すことができ、その後、解かれたモデル変数の値を第１のプロパティにセットすることができる。
【０１２４】
第１のプロパティをセットすることに加えて、第１のプロパティ−セッター１５０２ａは、第２のプロパティ−セッター１５０２ｂをも呼び出す（行為１６０３）。次に、第２のプロパティ−セッター１５０２ｂは、ソルバ１５０１ｂなどの、モデル変数について解くように構成され得るソルバを呼び出す（行為１６０４）。具体的に言うと、図１５に示されているように、ソルバ１５０１ｂは、第２のプロパティ−セッター１５０２ｂによって呼び出され、かつ／またはその一部を構成することができ、呼び出された時に、ソルバ１５０１ｂは、未知のモデル変数１５０３ｂについて解くことができる。いくつかの例で、ソルバ１５０１ｂは、既知のモデル変数、たとえばモデル変数１５０３ａを使用することによって、未知のモデル変数１５０３ｂについて解くことができる。たとえば、第１のプロパティ−セッター１５０２ａが第２のプロパティ−セッター１５０２ｂを呼び出す（行為１６０３）時に、第１のプロパティ−セッター１５０２ａは、モデル変数１５０３ａを第２のプロパティ−セッター１５０２ｂに渡すことができる。その後、ソルバ１５０１ｂは、モデル変数１５０３ａを使用することによって未知のモデル変数１５０３ｂについて解くことができる。もちろん、第１のプロパティ−セッター１５０２ａが、モデル変数１５０３ａを第２のプロパティ−セッター１５０２ｂに渡す必要はなく、第２のプロパティ−セッター１５０２ｂは、任意の他の適切な形でモデル変数１５０３ａにアクセスすることができる。
【０１２５】
次に、第２のプロパティ−セッター１５０２ｂは、ビュー構成のビューコンポーネントの第２のプロパティに、たとえば解かれたモデル変数１５０３ｂの値をセットする（行為１６０５）。もちろん、いくつかの場合に、第２のプロパティ−セッター１５０２ｂは、単純に既知のモデル変数１５０３ｂを受け取ることができ、その後、第２のプロパティ−セッターは、受け取られたモデル変数の値を第２のプロパティにセットすることができる。したがって、第２のプロパティ−セッター１５０２ｂは、ソルバを呼び出すこと（行為１６０４）を必要としない。第２のプロパティ−セッター１５０２ｂが第２のプロパティをセットした後に、ビューコンポーネントを含むビュー構成が、レンダリングされる（行為１６０６）。
【０１２６】
いくつかの場合に、第１のプロパティおよび第２のプロパティを、ビュー構成の単一のビューコンポーネントのプロパティとすることができる。したがって、単一のビューコンポーネントのプロパティ−セッター１５０２ａ、１５０２ｂが、モデル変数１５０３ａ、１５０３ｂの値を第１のプロパティおよび第２のプロパティにセットすることができ（行為１６０２、１６０５）、したがって、モデル変数１５０３ａ、１５０３ｂが第１および第２のプロパティを定義することを可能にする。
【０１２７】
他の例では、第１のプロパティを、第１のビューコンポーネントのプロパティとすることができ、第２のプロパティを、第２のビューコンポーネントのプロパティとすることができる。したがって、第１のビューコンポーネントのプロパティ−セッター１５０２ａは、モデル変数１５０３ａの値を第１のプロパティにセットすることができ（行為１６０２）、したがって、モデル変数１５０３ａが第１のプロパティを定義することを可能にする。さらに、第２のビューコンポーネントのプロパティ−セッター１５０２ｂは、モデル変数１５０３ｂの値を第２のプロパティにセットすることができ（行為１６０５）、したがって、モデル変数１５０３ｂが第２のプロパティを定義することを可能にする。望まれる場合に、第１のビューコンポーネントを、第２のビューコンポーネントの子または親にすることができ、第２のビューコンポーネントを、第１のビューコンポーネントの子または親にすることができる。
【０１２８】
したがって、図１１に関して上で示したように、複数のソルバは、明示的な順序で構成され（行為１１０７）、その後、その順序に従って解かれる（行為１１０８）ものとすることができる。たとえば、ソルバを、依存関係ツリーなどの関係構造を使用して明示的に構成することができる。さらに、図１４から１６に関して示したように、複数のソルバを、ソルバ１５０１を有する他のプロパティ−セッター１５０２を呼び出す、ソルバ１５０１を有するプロパティ−セッター１５０２の能力に基づいて、暗黙のうちに構成することができる。
【０１２９】
複合ビュー構成
図２を参照すると、パイプライン環境２００は、モデルインポート機構２４１をも含み、モデルインポート機構２４１は、おそらくはオーサリングコンポーネント２４０の一部として含まれる。モデルインポート機構２４１は、作成者が前から存在する分析駆動モデルの少なくとも一部を、ユーザが構築しつつある現在の分析駆動モデルにインポートすることを可能にするために作成者にユーザインターフェースまたは他のアシスタンスを提供する。したがって、作成者は、新しい分析モデルを作成する時に、必ず一から始める必要はない。インポートは、分析駆動モデル全体またはおそらくはそのモデルの一部のインポートとすることができる。たとえば、インポートは、次の６つの潜在的な影響の１つまたは複数またはすべてを引き起こすことができる。
【０１３０】
インポートの第１の潜在的影響として、追加のモデル入力データを、パイプラインに追加することができる。たとえば、図２を参照すると、追加のデータを、入力データ２１１、分析データ２２１、および／またはビューデータ２３１に追加することができる。追加のモデル入力データは、追加のコネクタが図３のデータアクセスコンポーネント３１０またはおそらくは異なる正規化コンポーネント３３０に追加されることを含むこともできる。
【０１３１】
インポートの第２の潜在的影響として、モデル入力データとモデルパラメータとの間の追加のまたは変更されたバインディングがある場合がある。たとえば、図４を参照すると、データモデルバインダ４１０は、正規化されたデータ４０１とモデルパラメータ４１１との間で追加のバインディングを発生させることができる。これは、既知のモデルパラメータの個数の増加を引き起こす場合がある。
【０１３２】
インポートの第３の潜在的影響として、モデルパラメータの補足セットを生成するための追加のモデルパラメータがある場合がある。たとえば、図４を参照すると、モデルパラメータ４１１が、インポートされたモデルの分析的挙動のインポートに起因して増補される場合がある。
【０１３３】
インポートの第４の潜在的影響として、モデルに追加される追加の分析的関係（式、ルール、および制約など）がある場合がある。第１の潜在的影響から生じる追加の入力データ、第２の潜在的影響から生じる追加のバインディング、第３の潜在的影響から生じる追加のモデルパラメータ、および第４の影響から生じる追加の分析的関係。これらの追加アイテムの任意の１つまたは複数を、ビュー構成に影響する追加のデータと見なすことができる。さらに、これらの影響の任意の１つまたは複数は、図４のソルバ４４０の挙動を変更することができる。
【０１３４】
インポートの第５の潜在的影響として、モデルパラメータとビューの入力パラメータとの間の追加のまたは異なるバインディングがある場合がある。たとえば、図５を参照すると、モデル−ビューバインディングコンポーネント５１０は、モデルパラメータ４１１の潜在的に増補されたセットを、ビューコンポーネントリポジトリ５２０内のビューコンポーネントの潜在的に増補されたセットにバインドする。
【０１３５】
インポートの第６の潜在的影響として、おそらくはビュー構成に追加される新しいビューアイテムをもたらす、図５のビューコンポーネントリポジトリ５２０に追加される追加のパラメータ化されたビューコンポーネントがある場合がある。
【０１３６】
したがって、別のモデルのすべてまたは一部をインポートすることによって、そのモデルに関連するデータが、インポートされる。ビュー構成はデータ駆動なので、これは、モデルのインポートされた部分が、現在のビュー構成に即座に組み込まれることを意味する。
【０１３７】
前から存在する分析駆動分析モデルの一部がインポートされる時には、パイプライン２０１に供給されるデータの変化が発生し、これによって、パイプライン２０１に、即座にまたはある他のイベントに応答して、ビュー構成の再生成を引き起こさせる。したがって、本質的に既存モデルからのコピーアンドペースト動作であるものの際に、その結果の複合モデルが、再解決動作に起因してディスプレイ上で即座に見られるようになる可能性がある。
【０１３８】
この特徴がどれほど有用になり得るかの例として、図７の風水部屋ビュー構成を検討されたい。このアプリケーションの作成者は、風水専門家とすることができ、標準的な部屋レイアウトビュー構成モデルから始めることを望む可能性がある。したがって、前から存在する部屋レイアウトモデルをインポートすることによって、風水専門家は、今や、瞬間的ではないとしても相対的にすばやく、図７に示されたディスプレイ上に示された部屋レイアウト７０１を見ることができる。それだけではなく、今や、標準的な部屋レイアウトビュー構成モデルに通常付属する可能性がある家具および部屋アイテムのカタログが、今や、図７の風水アプリケーションから使用可能になっている。
【０１３９】
ここで、風水専門家は、風水グラフ要素７０２をビルドするための基礎として基本的な円グラフ要素をインポートすることを望む可能性がある。しかし、今、風水専門家は、おそらくは合計８つのくさび形があることと、おそらくは各くさび形の背景イメージおよびタイトルとを含む、グラフ要素の特定の固定された入力パラメータを指定することができる。ここで、風水専門家は、モデルパラメータがどのように相互に関係付けられるのかを指定する分析的関係を指定することだけを必要とする。具体的に言うと、家具または他の部屋アイテムの色、位置、およびタイプが、特定の風水スコアに影響する可能性がある。専門家は、単純にこれらの関係を書き留めて、これによって部屋レイアウト６０１と風水スコアとを分析的に相互に連結することができる。他者の成果を足場とするこのタイプの共同作業能力は、問題を解決し、ビジュアル分析を可能にするアプリケーションを作成する際の想像力の巨大な波を生み出すことができる。これは、特に、ユーザが固定された依存関係グラフを使用して一方向データをビジュアルにプログラムすることを可能にすることができるシステムとよい対照をなす。これらのシステムは、一方向解決を行うことができ、その方向は、最初に入力から出力へプログラムされる。本明細書で説明される原理は、ユーザとの対話型セッションを与えられて、いつでも、何が既知であり何が未知であるのかに応じて、複数の形での解決を可能にする。
【０１４０】
ビジュアル相互作用
ビュー構成プロセスを、この点までで、ある時にレンダリングされる単一のビュー構成であるものとして説明した。たとえば、図７は、入力データのセットから生成された単一のビュー構成を示す。しかし、本明細書で説明される原理を、複数の成分ビュー構成を含む統合されたビュー構成がある例に拡張することができる。これは、複数の異なる状況で役立つ可能性がある。
【０１４１】
たとえば、入力データの単一のセットを考慮すると、ソルバ機構が出力モデル変数について解いている時に、複数の可能な解がある可能性がある。成分ビュー構成は、それぞれ、複数の可能な解のうちの１つを表すことができ、ここで、別の成分ビュー構成は、別の可能な解を表すことができる。
【０１４２】
もう１つの例では、ユーザは、単純に、入力データの特定のセットを使用して生成された以前のビュー構成を保持し、その後、これによって新しいビュー構成を生成するために新しいシナリオを試みるために入力データを変更することを望む場合がある。次に、ユーザは、その第２のビュー構成をも保持し、入力データをもう一度変更することによって第３の可能なシナリオを試みることを望む場合がある。次に、ユーザは、一時に１つのビュー構成を見ることだけによって得ることが他の形ではむずかしい可能性がある情報を入手するために、おそらくは並べた比較を介して、この３つのシナリオを同時に見ることができる。
【０１４３】
図１７は、図７の風水の例から拡張する統合されたビュー構成１７００を示す図である。この統合されたビュー構成では、図７の第１ビュー構成７００が、正確に図７に示されているように、要素７０１および７０２を使用してもう一度表されている。しかし、ここでは、強調される第２のビュー構成が表されている。第２のビュー構成は、２つの要素すなわち部屋ディスプレイおよび風水スコアメータがあるという点で、第１のビュー構成に似ている。しかし、第２のビュー構成の入力データは、第１のビュー構成の入力データとは異なった。たとえば、この場合に、家具のアイテムのうちの複数の位置データが、異なり、これによって、第２ビュー構成の部屋レイアウト１７０１でのその位置を、第１ビュー構成の部屋レイアウト７０１の位置とは異なるものにする。しかし、さまざまな家具アイテムの異なる位置は、第２ビュー構成の風水メータ１７０２内の、第１ビュー構成の風水メータ７０２と比較して異なる風水スコアに相関する。
【０１４４】
統合されたビュー構成は、以前に作成されたビュー構成と現在表示されているビュー構成とのすべてのうちのいくつかにまたがる少なくとも１つのパラメータの値の比較をビジュアルに表す比較要素を含むこともできる。たとえば、図１３では、表示されるビュー構成ごとに、おそらくはコストおよび配送時間を示す棒グラフがあるものとすることができる。そのような比較要素を、ビューコンポーネントリポジトリ５２０内の追加のビューコンポーネントとすることができる。おそらく、その比較ビュー要素は、表示される複数のビュー構成がある場合に限って表示される可能性がある。その場合に、比較ビュー構成入力パラメータを、モデルの異なる解く反復に関するモデルパラメータにマッピングすることができる。たとえば、比較ビュー構成入力パラメータを、図１７の第１と第２とのビュー構成の生成の両方について生成されたコストパラメータにマッピングすることができ、第１と第２とのビュー構成の生成の両方について生成された配送パラメータにマッピングすることができる。
【０１４５】
図１７を参照すると、使用可能な以前に構築されたビュー構成全体の選択されたサブセットをユーザがビジュアルに強調することを可能にする選択機構もある。選択機構１７１０は、サムネイルの形で示されるかある他の強調されない形で示される３つの可能なビューコンストラクション１７１１、１７１２、および１７１３を含むものとして図示されている。各サムネイルビュー構成１７１１から１７１３は、対応するチェックボックス１７２１から１７２３を含む。ユーザは、ビジュアルに強調されなければならないビュー構成に対応するチェックボックスにチェックマークを付けることができる。この場合に、チェックボックス１７２１および１７２３が、チェックマークを付けられ、これによって、より大きい形の対応するビューコンストラクションを表示させる。
【０１４６】
統合されたビュー構成は、またはそれに関してどの単一のビュー構成であっても、どのモデルパラメータがこれによって分析ソルバ機構による別の解決をトリガする未知数として扱われなければならないのかを指定するためにユーザがビュー構成と相互作用するための機構を有することができる。たとえば、図１７の部屋ディスプレイ１７０１内で、家具の特定のアイテムを右クリックし、特定のパラメータ（たとえば、位置）を右クリックすることができ、ドロップダウンメニューが、現れることができ、そのパラメータを未知数として扱わなければならないことをユーザが指定することを可能にする。次に、ユーザは、調和パーセンテージ（たとえば、風水スコアメータ１７０２内の９５％）を右クリックすることができ、その結果、ユーザが異なる調和パーセンテージを指定することを可能にするスライダが現れることができる（または、他のユーザ入力機構のテキストボックス）。これは、既知のパラメータおよび未知のパラメータのアイデンティティが変更されることをもたらすので、再解決が生じ、その位置が未知数として指定された家具のアイテムが、新しい位置に現れる可能性がある。
【０１４７】
相互作用ビジュアルキュー
一実施形態では、統合されたビュー構成は、ビジュアルアイテムに関連するビジュアルプロンプトまたはビジュアルキューを含むこともできる。ビジュアルキューは、１）関連するビジュアルアイテムと相互作用できること、２）そのビジュアルアイテムとのどのタイプの相互作用が可能であるのか、３）ビジュアルアイテムとの特定の相互作用が行われる場合に結果がどうなるのか、および／または４）１つもしくは複数の他のビジュアルアイテムとの相互作用が結果を達成するために必要であるかどうかのあるビジュアル表示をユーザに与える。
【０１４８】
前に図５を参照して述べたように、ビュー部分５００は、複数のビューコンポーネント５２１、５２２、５２３、５２４を含むビューリポジトリ５２０を含む。ビューコンポーネントのいくつか５２２、５２３、および５２４は、対応する入力パラメータ（ビューコンポーネント５２２についてパラメータ５４２Ａおよび５４２Ｂ、ビューコンポーネント５２３についてパラメータ５４３、ならびにビューコンポーネント５２４についてパラメータ５４４）内で設定される値によって駆動される。入力パラメータ（１つまたは複数）に供給されるデータは、そのデータがビジュアルアイテムのコンストラクションを制御するように、対応するビューコンポーネントの実行ロジックを駆動する。たとえば、ビジュアルアイテム５２２の構造は、入力パラメータ５４２Ａおよび／または入力パラメータ５４２Ｂに供給されるデータに依存するものとすることができる。
【０１４９】
一実施形態では、所与のビューコンポーネントの入力パラメータの１つまたは複数を、相互作用パラメータとすることができる。その相互作用パラメータは、ビジュアルアイテムが相互作用を伴ってレンダリングされるか否かを定義することができる。その代わりにまたはそれに加えて、相互作用パラメータは、特定のタイプの相互作用を、対応するビューコンポーネントの実行ロジックを実行した結果として構築された対応するビジュアルアイテムに適用させることができる。少なくとも１つのそのような相互作用パラメータを含むビューコンポーネントを、以下では「ビジュアルキュー付き対話型（ｖｉｓｕａｌｌｙ ｃｕｅｄ ｉｎｔｅｒａｃｔｉｖｅ）」ビューコンポーネントと呼ぶ。相互作用を可能にすることに加えて、相互作用パラメータに提供されたデータは、１）ビジュアルアイテムが対話型であることおよび潜在的に相互作用のタイプをユーザにビジュアルに知らせるために、対応するビジュアルアイテムが、レンダリングされる時に、どのようにビジュアルにキューを付けられるのかを定義することもできる。レンダリングされるビジュアルアイテムの１つ、いくつか、またはすべてさえ、この形で対話型とし、ビジュアルキュー付きとすることができる。
【０１５０】
ビジュアルアイテムによって提供できる複数の異なるタイプの相互作用がある。１つが、本明細書ではナビゲーション相互作用と呼ばれる。ユーザが、ビジュアルアイテムとナビゲーション的に相互作用する時に、レンダリングのためにビジュアルアイテムを構築するのに使用されるビューコンポーネントのサブセットが、変化する。
【０１５１】
たとえば、ナビゲーション相互作用の１タイプが、本明細書ではスコーピング相互作用と呼ばれる。スコーピング相互作用は、ナビゲーション相互作用の直前に表示されたビジュアルアイテムの少なくともいくつかが、ナビゲーション相互作用の直後にも表示されるように、レンダリングされるビジュアルアイテムのサブセットを相互作用的に変更する。たとえば、図５を参照すると、仮想空間５００は、４つのビジュアルアイテム５５１、５５２、５５３、および５５４を含むものとして図示されている。ビジュアルアイテム５５２が、スコーピング相互作用を有する場合に、ユーザは、ビジュアルアイテム５５１および５５４がもはや仮想空間５５０内でレンダリングされなくなるように、ビジュアルアイテム５５２と相互作用することができる。しかし、ビジュアルアイテム５５２および５５３は、仮想空間５５０内に残ることができる。その代わりにまたはそれに加えて、さらなるビジュアルアイテムをビジュアル空間内に構築することができる。
【０１５２】
スコーピング相互作用の１タイプが、レンダリングのためにビジュアルアイテムを生成するのに使用されるビューコンポーネントの範囲を変更するスクローリング相互作用である。図１８Ａおよび１８Ｂは、スクローリング相互作用の例を表す。図１８Ａは、スクローリング相互作用の前の仮想空間１８００Ａを表す。ここで、ビュー構成コンポーネント（図５を参照されたい）は、６つのビジュアルアイテム１８１１、１８１２、１８１３、１８１４、１８１８、および１８１６を構築した。ビジュアルアイテム１８１１は、このビジュアルアイテムが左スクロール相互作用を使用可能にされていることを示すビジュアルキュー（アスタリスク１８０１によって表される）で装飾されている。ビジュアルアイテム１８１６は、このビジュアルアイテムが右スクロール相互作用を使用可能にされていることを示すビジュアルキュー（アスタリスク１８９９によって表される）で装飾されている。図１８Ｂは、右にスクロールするためのビジュアルアイテム１８１６とのユーザ相互作用の後の仮想空間１８００Ｂを表す。ここでは、ビジュアルアイテム１８１１が、仮想空間から除去されている。さらに、新しいビジュアルアイテム１８１７が、仮想空間に追加されている。編集相互作用の例では、この場合のスクローリング相互作用は、ビジュアルアイテム１８１２が、左向きスクローリング相互作用が使用可能にされていることを表したビジュアルキューで装飾されることをも引き起こした。さらに、ビジュアルアイテム１８１６は、そのビジュアルキューおよび相互作用を失い、この相互作用は、その代わりにビジュアルアイテム１８１７に提供される。ビジュアルキューおよび相互作用機能性は、所与のビジュアルアイテムについて、対応するビューコンポーネントの入力パラメータ（１つまたは複数）を設定するために提供されるデータを単純に変更することによってイネーブルされ、ディスエーブルされ得る。
【０１５３】
別のタイプのスコーピング相互作用が、レンダリングのためにビジュアルアイテムを生成するのに使用されるビューコンポーネントの詳細のレベルを変更する「ディテーリング相互作用（ｄｅｔａｉｌｉｎｇ ｉｎｔｅｒａｃｔｉｖｉｔｙ）」である。「ズームイン」相互作用は、おそらく以前のビジュアルアイテムのいくつかがビューから消えることと共に、ビジュアルアイテムのより特定の粒度が現れることを引き起こすことができる。「ズームアウト」相互作用は、おそらくアイテムの以前のより特定の粒度のいくつかが消えることと共に、ビジュアルアイテムのより粗い粒度が現れることを引き起こすことができる。たとえば、見える宇宙の地図でのズームインの場合に、銀河団が見え始める場合がある。その銀河団にズームインする場合に、個々の銀河が形をなし始める可能性がある。天の川銀河など、これらの個々の銀河の１つにズームインする場合に、個々の星が見え始める場合がある。太陽など、これらの星の１つにズームインする場合に、太陽の詳細が、ますます明白になる可能性があり、おそらくは惑星が見え始める。地球など、これらの惑星の１つにズームインする場合に、大陸などの大規模な地形学的特徴が現れる可能性がある。さらにズームインする場合に、国境が現れる可能性があり、その後、都市が現れる可能性があり、その後、街路が形をなす可能性がある。これは、原子を構成する粒子が形をなすまで継続する可能性がある。そのようなズームする地形での粒度の粗さは、宇宙のモデルのように、物理的に関係付けられる必要がない。他の地形を通ってナビゲートすることもでき、各スコーピング相互作用は、以前のビジュアルアイテムに消えさせ、新しいビジュアルアイテムに現れさせる。やはり、擬似無限データ系列の使用は、この動作を容易にすることができる。
【０１５４】
図１９Ａに、特定のディテーリング相互作用動作の前の例の仮想空間１９００Ａを示す。ここでは、表示され始める２つのビジュアルアイテム１９１１および１９１２だけがある。図１９Ｂの仮想空間１９００Ｂに見られるように、ビジュアルアイテム１９１１が拡大され、今や、いくつかのビジュアルアイテム１９２１および１９２２が、ビジュアルアイテム１９１１の内部にレンダリングされ、今や、ビジュアルアイテム１９１２は、ビューから外れている。これは、ズームイン相互作用の例である。ズームアウト相互作用の例について、図１９Ｂの仮想空間１９００Ｂから始めることができ、仮想空間１９００Ａは、ズームアウト相互作用の後の状態を表す。
【０１５５】
相互作用のタイプを、少なくとも１つのレンダリングされたフレーム（およびおそらくはディスプレイ全体）に、前に表示された完全に異なるビジュアルアイテムを表示させる、リンキング相互作用とすることもできる。たとえば、上の図７の風水部屋の例では、特定のビジュアルアイテム（風水メータ７０２など）をクリックすることが、風水に関するウェブページを風水部屋ビューの代わりに表示させることができる。その代わりに、おそらく、相互作用された場合に全く異なる部屋が現れることを引き起こすことができるビジュアルアイテムがある。
【０１５６】
相互作用のもう１つのタイプを、レンダリングされるビジュアルシーンと独立なアクションが行われることを引き起こす外部アクション相互作用とすることができる。たとえば、電子メールを送信させるか、アラームをセットし、データバックアップをスケジューリングし、性能チェックを実行するなどを行うことができるビジュアルアイテムと相互作用することができる。
【０１５７】
相互作用のタイプを、編集相互作用とすることもできる。編集相互作用は、１つまたは複数のビューコンポーネントの１つまたは複数の入力パラメータ値が変化する形でデータを変更する。その入力パラメータが、あるビジュアルアイテムがどのように構築されるのかに影響する場合には、そのビジュアルアイテムは、結果として変化する。データの変更は、入力モデルパラメータの値を変化させ、または入力モデルパラメータおよび／もしくは出力モデルパラメータのアイデンティティを変化させることもできる。したがって、ビジュアルアイテムに課せられる編集相互作用は、分析部分４００の完全な再計算を引き起こすことができる。編集相互作用の複数の例を、これから提供する。
【０１５８】
図２０は、連続的な米国のレンダリング２０００を示す。米国ビジュアルアイテムを、１つのビューコンポーネントから構築することができる。しかし、構成する州を、それぞれ、対応する子ビューコンポーネントから構築することができる。その州に対応するビジュアルアイテムの高度は、その州のあるパラメータ（たとえば、評価される特定の製品の１人あたりの消費量）を表す。ここで、ニューメキシコビジュアルアイテム２００１は、上に向かう矢印２０１１の形のビジュアルキューを有する。これは、ビジュアルアイテムの高さを変更できるようにニューメキシコビジュアルアイテム２００１と相互作用できることをユーザに思い付かせる。また、それぞれ対応する下に向かう矢印２０１２および２０１３を有するネバダビジュアルアイテム２００２およびフロリダビジュアルアイテム２００３。これらの矢印は、ニューメキシコの矢印２０１１の高さの上向きの調整が、分析部分４００を介するモデルの再分析の後に、ネバダビジュアルアイテム２００２およびフロリダビジュアルアイテム２００３の高さの下向きの調整を引き起こすことをユーザに視覚的に知らせることができる。その代わりにまたそれに加えて、矢印２０１２および２０１３は、ネバダビジュアルアイテム２００２とフロリダビジュアルアイテム２００３との高さの両方がユーザによって下向きに調整される場合に、ニューメキシコビジュアルアイテム２００１の高さが上向きに調整されることを示すことができる。特定のユーザ相互作用の結果を判定するために、パイプライン２０１は、ユーザがレンダリングされたビジュアルアイテムとどのように相互作用できるのかを検討し、結果がどうなるのかを判定するために分析モデルのコンティンジェンシ解決（ｃｏｎｔｉｎｇｅｎｃｙ ｓｏｌｖｅ）を実行することができる。
【０１５９】
図２１は、関係付けられた棒グラフ２１１０および円グラフ２１２０を含むグラフ２１００を示す。棒グラフ２１１０は、複数の棒を含む。棒の１つ２１１１Ａは、この高さを垂直に調整できることを表すために矢印２１１１Ｂと共に図示されている。これは、円グラフ２１２０内のさまざまなくさび形の割当のある調整を引き起こす可能性がある。棒グラフ２１１０および円グラフ２１２０を、視覚的に合併することができる。たとえば、結果の円グラフが、その厚さが棒グラフの関連する棒の高さに依存するくさび形を含むことができる。
【０１６０】
図２２は、ハリケーン２２１１の経路２２０１がグラフ化されつつあるハリケーンマッピンググラフ２２００を示す。ビジュアルキュー２２２０は、ユーザが経路２１０１をたとえば経路２２０２に変更するために経路２２０１と対話型とすることができることを示す。これは、ユーザが、ハリケーンの経路に関する可能な代替の現実を評価することを可能にする。コントロール２２２１、２２２２、２２２３、および２２２４も、たとえば風速、温度、スピン、およびハリケーン移動速度などのハリケーンのさまざまなパラメータを変更することを可能にする。
【０１６１】
図７の風水の例では、特定の調和スコアが、既知の入力パラメータとして指定される場合に、家具のさまざまな位置を、その位置が未知数として指定された家具のアイテムについて提案することができる。たとえば、おそらく複数の矢印が、家具から発出し、より高い調和スコアを得るためにその家具を移動すべき方向、水スコアを最大にするために移動すべき異なる方向、最大限まで水スコアを移動するための異なる方向などを提案する。ビューコンポーネントは、特定のスコアを増やすために椅子を移動できる場合にシャドウを示すこともできる。したがって、ユーザは、最適化されることが望まれる特定のパラメータを中心としてデザインを改善するために、これらのビジュアルプロンプトを使用することができる。別の例では、おそらく、ユーザはコストを削減することを望む。ユーザは、最小化すべき未知数としてコストを指定することができ、提案される家具選択の異なるセットがもたらされる。
【０１６２】
図２３は、複数のビジュアルアイテムを表示するユーザインターフェースと相互作用する方法の流れ図を示す。コンピュータは、前に説明したように、ディスプレイ上にデータ駆動ビジュアルアイテムをレンダリングする（行為２３０１）。データ駆動ビジュアルアイテムのそれぞれが、パラメータ化されたビューコンポーネントにデータを供給することによって定式化されることを想起されたい。そのデータは、データがパイプライン２０１の分析部分４００に供給されることに応答して、またはデータがパイプライン２０１のデータ部分３００に供給されることに応答して、分析モデルによって入手されたものとすることができる。さらに、ビジュアルアイテムの１つ、いくつか、またはすべてが、ビジュアルキューまたは他のビジュアル強調を有し（行為２３０２）、ビジュアルアイテムと相互作用できることおよび／または相互作用のタイプをユーザに伝える。一実施形態では、ビジュアルキューは、当初に、対応するビジュアルアイテムが対話型であることを表すのみであり、ビジュアルキューが相互作用のタイプを伝えるために変更されまたは補足されるのは、ユーザがビジュアルアイテムを選択した（ポインタを用いてビジュアルアイテム上でホバリングすることによって）後である。
【０１６３】
次に、コンピューティングシステムは、ユーザとビジュアルアイテムとの間の所定の物理的相互作用が発生したことを検出する（行為２３０３）。それに応答して、その特定のビジュアルアイテムについて相互作用がイネーブルされ、またはアクティブ化される（行為２３０４）。適当な応答は、その相互作用がナビゲーション相互作用、リンキング相互作用、または編集相互作用のどれであるのかに依存する。編集相互作用の場合に、結果は、パイプラインの分析部分４００によって定義されるさまざまなビジュアルアイテムの間の分析的関係にも依存する。
【０１６４】
相互作用を、ナビゲーション相互作用、リンキング相互作用、および編集相互作用のうちの複数の組合せとすることができる。たとえば、図２０の米国の例では、ニューメキシコビジュアルアイテム２００１の高さの上向きの調整が、ネバダビジュアルアイテム２００２およびフロリダビジュアルアイテム２００３の高さの下向きの調整をもたらすことができる（編集相互作用の例を表す）。しかし、これが、３つのフレームがそれぞれ３つの州ネバダ、ニューメキシコ、およびフロリダのうちの１つにズームインする４つのフレームにディスプレイを分割することをももたらすこともできる（スコーピング相互作用の例）。さらに、第４のフレームは、ニューメキシコの住居の消費プリファレンスに関する調査情報を含むことができる（リンキング相互作用の例）。
【０１６５】
図２４は、もう１つのアプリケーション例を表すユーザインターフェース２４００を抽象的に示す。このアプリケーション例では、ユーザが本明細書で説明される原理を使用してデータ駆動ビジュアルシーンを簡単に構築することを可能にする便利なユーザインターフェースが説明される。
【０１６６】
ユーザインターフェース２４００は、ビジュアルアイテム（１つまたは複数）の第１セット２４１１を含む。この図示の場合では、セット２４１１は、単一のビジュアルアイテム２４１１だけを含む。しかし、本明細書で説明される原理は、ビジュアルアイテムセット２４１１内の１つのみのビジュアルアイテムに限定されない。ビジュアルアイテム（１つまたは複数）２４１１は、関連するデータ２４１２を含み、したがって、本明細書で、時々「データビジュアルアイテム（１つまたは複数）」２４１１と呼ばれる。
【０１６７】
要求されないが、この例では、関連するデータが、複数のデータグループに副分割される。任意の個数のグループが、十分である。しかし、４つのデータグループ２４１３Ａ、２４１３Ｂ、２４１３Ｃ、および２４１３Ｄが、図２４の関連するデータ２４１２内に含まれるものとして図示されている。図示された関連するデータ２４１２内では、データグループのそれぞれが、それぞれが関連する複数のデータフィールドを有して平行に編成される。図示の場合では、図示された関連するデータ２４１２内のデータグループのそれぞれが、対応するフィールドａ、ｂ、およびｃを含む。データグループ２４１３Ａのフィールドａ、ｂ、およびｃは、以下ではそれぞれデータフィールド２４１３Ａａ、２４１３Ａｂ、および２４１３Ａｃと呼ばれる。データグループ２４１３Ｂのフィールドａ、ｂ、およびｃは、以下ではそれぞれデータフィールド２４１３Ｂａ、２４１３Ｂｂ、および２４１３Ｂｃと呼ばれる。データグループ２４１３Ｃのフィールドａ、ｂ、およびｃは、以下ではそれぞれデータフィールド２４１３Ｃａ、２４１３Ｃｂ、および２４１３Ｃｃと呼ばれる。最後に、データグループ２４１３Ｄのフィールドａ、ｂ、およびｃは、以下ではそれぞれデータフィールド２４１３Ｄａ、２４１３Ｄｂ、および２４１３Ｄｃと呼ばれる。
【０１６８】
ユーザインターフェース２４００は、ビジュアルアイテムの第２セット２４２０をも含む。図示の場合では、セット２４２０は、３つの対応するビジュアルアイテム２４２１、２４２２、および２４２３を含む。しかし、第２セット２４２０内のビジュアルアイテムの個数に対する限定はなく、第２セット内のビジュアルアイテムが同一タイプのアイテムであるという要件もない。以下では、ビジュアルアイテム２４２１、２４２２、および２４２３を、「要素ビジュアルアイテム」と呼ぶ場合もある。各ビジュアルアイテム２４２１、２４２２、および２４２３を、たとえば、入力パラメータを使用してそれぞれのビューコンポーネントの対応するロジックを実行することによって構築することができる。そのようなビューコンポーネントは、ビューコンポーネント５２１から５２４について図５に関して説明したものに類似するものとすることができる。したがって、ビジュアルアイテム２４２１、２４２２、および２４２３のそれぞれは、入力パラメータを有するものとして図示されている。そのような入力パラメータを、ビューコンポーネントに供給される入力パラメータとすることができ、または、ビジュアルアイテムのレンダリングを駆動するある他の入力パラメータとすることができる。例としてのみ、ビジュアルアイテム２４２１、２４２２、および２４２３のそれぞれは、それぞれが３つの入力パラメータを有するものとして図示されている。具体的に言うと、ビジュアルアイテム２４２１は、入力パラメータ２４２１ａ、２４２１ｂ、および２４２１ｃを有するものとして図示されている。ビジュアルアイテム２４２２は、入力パラメータ２４２２ａ、２４２２ｂ、および２４２２ｃを有するものとして図示されている。ビジュアルアイテム２４２３は、入力パラメータ２４２３ａ、２４２３ｂ、および２４２３ｃを有するものとして図示されている。
【０１６９】
ユーザインターフェース２４００は、ユーザ相互作用機構２４４０をも含む。ユーザ相互作用機構２４４０は、ユーザが（１つまたは複数のユーザジェスチャを介して）データビジュアルアイテム（１つまたは複数）２４１１のデータ２４１２を要素ビジュアルアイテム２４２０の入力パラメータに適用させることを可能にする。一実施形態では、ユーザジェスチャ（１つまたは複数）は、実際に、関連するデータを要素ビジュアルアイテム２４２０の入力パラメータにバインドさせることができる。そのようなユーザジェスチャは、ドラッグまたはドロップ動作、ホバー動作、ドラッグアンドクリック、もしくは任意の他のユーザジェスチャ、またはジェスチャの組合せとすることができる。したがって、ユーザは、データビジュアルアイテム（１つまたは複数）２４１０からのデータを要素ビジュアルアイテムの入力パラメータに適用しまたはバインドすることができ、これによって、単純なジェスチャを使用して要素ビジュアルアイテムの外見を変更する。一実施形態では、これは、ユーザが関連するデータのいずれかを入力することすら含まず、ジェスチャの単一のセットがデータを複数の要素ビューアイテムに適用しかつ／またはバインドすることを可能にする。１つのデータビジュアルアイテムから複数の要素ビジュアルアイテムへデータを適用しまたはバインドするためのユーザジェスチャのユーザの例を、下でさらに説明する。
【０１７０】
一実施形態では、ユーザ相互作用機構２４４０は、１）データグループのそれぞれの１つのデータグループが、第２の複数のビジュアルアイテムの別個のビジュアルアイテムの１つまたは複数の入力パラメータのセットに適用され、２）複数のデータグループの各データグループからの同一タイプの単一のフィールドが、要素ビジュアルアイテムの別個のビジュアルアイテムの１つまたは複数の入力パラメータのセットの入力パラメータに適用されるように、ユーザがデータビジュアルアイテム２４１１からのデータ２４１２をデータグループごとの基礎で要素ビジュアルアイテム２４２０の入力パラメータに適用することを可能にする。
【０１７１】
例として、図２４を参照すると、ユーザは、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ａａを要素ビジュアルアイテム２４２１の入力パラメータ２４２１ｂに、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｂａを要素ビジュアルアイテム２４２２の入力パラメータ２４２２ｂに、およびデータビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｃａを要素ビジュアルアイテム２４２３の入力パラメータ２４２３ｂに、同時に適用しまたはバインドするためにジェスチャの単一のセットを使用することができる。第４の要素ビジュアルアイテムがある場合には、データフィールド２４１３Ｄａが、第４要素ビジュアルアイテムの対応する入力パラメータに適用された可能性がある。
【０１７２】
ジェスチャのこの同一セットの結果として、またはおそらくはジェスチャの追加のセットに応答して、さらなるアプリケーションまたはバインディングを作ることができる。たとえば、ユーザジェスチャに応答して、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ａｂを要素ビジュアルアイテム２４２１の入力パラメータ２４２１ａに適用するかバインドすることができ、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｂｂを要素ビジュアルアイテム２４２２の入力パラメータ２４２２ａに適用するかバインドすることができ、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｃｂを要素ビジュアルアイテム２４２３の入力パラメータ２４２３ａに適用するかバインドすることができる。さらに、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ａｃを要素ビジュアルアイテム２４２１の入力パラメータ２４２１ｃに適用するかバインドすることができ、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｂｃを要素ビジュアルアイテム２４２２の入力パラメータ２４２２ｃに適用するかバインドすることができ、データビジュアルアイテム（１つまたは複数）２４１１のデータフィールド２４１３Ｃｃを要素ビジュアルアイテム２４２３の入力パラメータ２４３２ｃに適用するかバインドすることができる。
【０１７３】
ユーザインターフェース２４００は、潜在的に、関連するプロパティ２４３１を有する第３ビジュアルアイテム２４３０をも含む。第２ユーザ相互作用機構２４５０は、１）各第２オフセット２４２０ビジュアルアイテムの１つまたは複数の入力パラメータが第３ビジュアルアイテム２４３０の関連するプロパティ２４３１を使用してセットされ、かつ／または２）第３ビジュアルアイテム２４３０のプロパティ２４３１がビジュアルアイテムの第２セット２４２０のそれぞれの１つまたは複数の入力パラメータを変更するのに使用されるように、ユーザがビジュアルアイテム２４２０の第２セットを第３ビジュアルアイテム２４３０に合併するのにジェスチャ（１つまたは複数）のセットを使用することを可能にする。これを達成するのに使用されるジェスチャは、ドラッグアンドドロップ動作、ホバー動作、または任意の他のユーザジェスチャとすることができ、全体的にまたは部分的に、データビジュアルアイテム（１つまたは複数）２４１０からのデータを要素ビジュアルアイテム２４２０に適用するのに使用されたものと同一のユーザジェスチャを使用して達成された可能性がある。
【０１７４】
たとえば、ビジュアルアイテムの第２セット２４２０と第３ビジュアルアイテム２４３０とを合併するのに使用されるユーザジェスチャ（１つまたは複数）（すなわち、ジェスチャ（１つまたは複数）の第２セット）が、データビジュアルアイテム（１つまたは複数）２４１１からのデータを要素ビジュアルアイテム２４２０の入力パラメータに適用するかバインドするのに使用されるユーザジェスチャ（１つまたは複数）（すなわち、ジェスチャ（１つまたは複数）の第１セット）と少なくとも部分的にオーバーラップする場合に、ジェスチャ（１つまたは複数）の第１セットとジェスチャ（１つまたは複数）の第２セットとの両方内に、少なくとも１つの共通のジェスチャがある。しかし、これは、全く必要ではない。実際に、ジェスチャの第１セットとジェスチャの第２セットとの間に共通のジェスチャ（１つまたは複数）がない場合がある。したがって、要素ビジュアルアイテム２４２０をビジュアルアイテム２４３０と合併するのと比較して、別個のユーザアクションを使用してデータビジュアルアイテム２４１１からのデータを要素ビジュアルアイテム２４２０に適用することができる。
【０１７５】
一実施形態では、データビジュアルアイテム（１つまたは複数）２４１１を、それぞれ、図５のビューコンストラクションモジュール５２１から５２４を使用して図５で構築されたビューアイテムに似たものとすることができる。その場合に、関連するデータ２４１２を、対応するビューコンポーネントの入力パラメータ（１つまたは複数）に供給されるデータとすることができる。この関連するデータ２４１２を、ユーザが関連するデータに関するビューを有することを可能にする、ビジュアルアイテム自体内のビジュアルとして表面に出すことさえできる。ビジュアルアイテム２４３０も、ビューコンストラクションモジュール５２１から５２４を使用して構築されたビジュアルアイテムに似たものとすることができる。その場合に、おそらく、ビジュアルアイテム２４３０のプロパティ２４３１の１つまたは複数を、対応するビューコンポーネントの入力パラメータを使用してセットすることができる。
【０１７６】
要素ビジュアルアイテム２４２０の入力パラメータへのデータビジュアルアイテム（１つまたは複数）２４１１の関連するデータ２４１２の適用は、分析モデルに再び解かせることができる。たとえば、図４は、パイプライン２００の分析部分４００を説明する。関連するデータ２４１２の適用を適用することによって、要素ビジュアルアイテム２４２０の入力パラメータをさらに再設定するために再計算される必要があるデータが生じる可能性がある。さらに、要素ビジュアルアイテム２４２０を第３ビジュアルアイテム２４３０に合併することは、これによってビジュアルアイテム２４２０または２４３０の入力パラメータを変更するために分析部分４００の再解決を引き起こす可能性もある。
【０１７７】
もちろん、図２４は、ユーザインターフェースの抽象的な表現である。ユーザが要素ビジュアルアイテムに適用されるデータビジュアルアイテム（１つまたは複数）の関連するデータを指定することを可能にし、要素ビジュアルアイテムを別のより高いレベルのビジュアルアイテムと合併することを可能にするユーザインターフェースのより具体的な例を、これから図２５から２９に関して提示する。
【０１７８】
図２５は、その中で螺旋２５３０が提示されるユーザインターフェース２５００を示す。螺旋２５３０は、第３ビジュアルアイテム２４３０の具体的な例である。この場合に、螺旋２５３０のプロパティ（プロパティ２４３１の例）を、曲率半径、ピッチ（または上昇の角度）、色、線の厚さ、線の断面プロファイル、巻き線の長さ、開始角度などとすることができる。プロパティのそれぞれを、たとえば、実行された時に螺旋をレンダリングするコンストラクションロジックを有する螺旋ビュー構成要素に供給される入力プロパティとすることができる。螺旋形状タイプを、ユーザインターフェースの作業面２５０１にドラッグアンドドロップすることができる複数の形状のうちの１つとすることができる。螺旋は、その入力パラメータに、作業面にドラッグされる時にデフォルト値を設定されるものとすることができるが、これらのデフォルト値を変更させることができる。
【０１７９】
ユーザは、別々の立方形オブジェクト２５２１を作業面にドラッグすることもできた。立方形オブジェクト２５２１は、図２４の要素ビジュアルオブジェクト２４２１の例である。立方形オブジェクト２５２１は、通常、お互いに平行または垂直の６つの長方形の側面を有する。立方形オブジェクト２５２１が、螺旋２５３０以外の、作業面の別の部分にドラッグされた場合には、立方形オブジェクト２５２１は、これらの基礎的な立方形の特性を保持した可能性がある。しかし、この場合には、ユーザは、立方形オブジェクト２５２１と螺旋２５３０とが合併されることをジェスチャで示した（おそらくは、ポインタ２５５０を使用して立方形２５２１を螺旋２５３０の一部の上にドラッグすることを介して）。この場合に、立方形２５２１は、その中心線が螺旋に従うように、その入力パラメータを調整される。これは、螺旋ビジュアルアイテムと合併される要素ビジュアルアイテムのタイプ（たとえば、この場合には立方形）を定義するための機構とすることもできる。
【０１８０】
この合併動作を考慮して、図２６は、ユーザインターフェースのこの特定の例の別のステージ２６００を示す。ここでは、ユーザが、データビジュアルアイテム２６１０、この場合には、おそらくはスプレッドシート文書を獲得した。スプレッドシート文書２６１０は、図２４のデータビジュアルアイテム２４１１の例である。このスプレッドシート文書は、さまざまな精神治療薬をリストしたテーブルを含む。データは、完全に虚構であるが、この例を示すために提供される。第４列２６１４は、行ごとに１つの薬の名前をリストするが、この例では、このフィールドは、単純にデータが虚構なので空白である。第３列２６１３は、各行に対応する薬のカテゴリをリストする。第１列２６１１は、各行に対応する薬が処方使用について承認された開始日（年）をリストする。第２列２６１２は、各行に対応する薬が使用について承認された期間（年）をリストする。開始日、期間、カテゴリ、および名前は、図２４の関連するデータ２４１２のデータグループのフィールドの例である。スプレッドシート文書２６１０の行は、図２４の関連するデータ２４１２のデータグループの例である。
【０１８１】
ここで、入力データテーブル２６２０が現れて、どの入力パラメータが設定のターゲットであるものとして選択されたのかをユーザに示す。ユーザは、「螺旋上の位置」入力パラメータを設定するために第１列２６１１（すなわち、開始日フィールド）を選択した。立方形ビジュアルアイテムが、データグループごと（グラフ２６１０内の行ごと）に生成される。プレビュー２６３０は、螺旋２５３０を示すが、複数の立方形要素および螺旋の合併された版がどのように見えるのかのプレビューを伴う。
【０１８２】
図２７は、ユーザインターフェース２７００を示す。ここで、ユーザは、さまざまな立方形が、切り取られるのではなく、積み重ねの基礎として働く螺旋（今は不可視）と共に他の立方形の上に積み重ねられることを選択した。積み重ねられた立方形２７１０は、要素ビジュアルアイテムの例を表す。螺旋ビジュアルアイテムのプロパティが、各立方形の入力パラメータによって継承されたことに留意されたい。さらに、データビジュアルアイテム２６１０からのデータは、各立方形によって継承された。たとえば、立方形の積み重ね内の各立方形は、対応する薬の開始日に対応する螺旋上の位置を使用して構築された。各立方形の長さは、対応する薬の期間によって継承される。さらに、立方形は、螺旋から位置プロパティおよび曲率プロパティを継承する。
【０１８３】
図２８は、完全なビジュアルシーンを示す。このユーザインターフェース２８００では、色を、対応する薬のカテゴリに従って各立方形に割り当てることができる。したがって、対応する薬の開始日は、螺旋内の曲がった立方形の開始位置を定義する。たとえば、ユーザは、スプレッドシートビジュアルアイテム２４１１からの開始日データを立方形ビジュアルアイテムに適用するために、１）スプレッドシートの第１列を選択し、２）その列を入力パラメータテーブル２６２０の「螺旋上の位置」セクションにドラッグするというジェスチャを使用した可能性がある。さらに、対応する薬の期間は、螺旋内の曲がった立方形の長さを定義する。たとえば、ユーザは、スプレッドシートビジュアルアイテム２４１１からの期間データを立方形ビジュアルアイテムに適用するために、１）スプレッドシートの第１列を選択し、２）その列を入力パラメータテーブル２３２０の「長さ」セクションにドラッグするというジェスチャを使用した可能性がある。最後に、対応する薬のカテゴリは、螺旋内の曲がった立方形の色を定義する。ユーザは、スプレッドシートビジュアルアイテム２４１１からのカテゴリデータを立方形ビジュアルアイテムに適用するために、１）スプレッドシートの第１列を選択し、２）その列を入力パラメータテーブル２６２０の「色」セクションにドラッグするというジェスチャを使用した可能性がある。ユーザは、状況を考慮して、データのどのビジュアル表現が最良であるのかを知るために、入力パラメータフィールドの異なるセクションにスプレッドシートの異なるフィールドをドラッグアンドドロップすることができる。
【０１８４】
本明細書で説明されるこれらの原理を使用して、複雑なジオメトリを、他のビジュアル要素およびジオメトリを用いて構築し、構成することができる。ジオメトリの構成を理解するために、４つの主要な概念を、まず説明する。主要な概念は、１）データ系列、２）形状、３）次元セット、および４）ジオメトリを含む。
【０１８５】
まず、データ系列を説明する。データ系列は、データに対するラッパーである。データ系列オブジェクトの例は、図６に図示され、図６に関して説明された。データ系列オブジェクトは、データ自体ではない。しかし、データ系列は、データをどのようにして列挙すべきかを知っている。たとえば、図６を参照すると、列挙モジュール６０１は、データストリームオブジェクトに対応するデータ系列を列挙する。さらに、データ系列は、プロットの範囲、量子化、および分解能を宣言する属性を有する。データ系列によってラップされ得るデータタイプの例は、テーブル列、テーブル内の繰り返す行、階層、次元階層などを含む。
【０１８６】
形状を、正規ビュー構成から構築された正規ビジュアルアイテムとすることができる。そのような正規ビジュアルアイテムの例は、たとえば、点、棒、角柱、泡、表面パッチ、イメージファイル、２次元または３次元の形状などを含む。しかし、形状を、データからの正規コンストラクションとすることができる。そのようなデータからの正規コンストラクションの例は、ラベルを含む。その代わりに、形状を、データ系列および形状を用いてジオメトリを設定した結果とすることができる（用語ジオメトリは、下でさらに説明される）。
【０１８７】
正規形状は、複数の形状を処理するためにジオメトリの「バインダ−アレンジャ（ｂｉｎｄｅｒ−ａｒｒａｎｇｅｒ）」（下で説明される）をパラメータ化することを潜在的に可能にするメタデータを担持する。このメタデータは、やはり下で説明される「レイアウトヘルパ」のヒントをも提供する。メタデータは、形状が直線または曲線のどちらであるのか、形状が平坦または体積を占めるのどちらであるのか、形状がある次元に関して対称であるのかどうか、形状がテキスト的な意味（たとえば、ラベル）形状で読まれる必要があるのかどうか、形状を着色しまたはテクスチャに重畳できるのかどうかなど、形状の諸態様を示す。
【０１８８】
形状が、絶対次元を有するのではなく、オプションでその次元での比率を指定できることに留意されたい。たとえば、角柱は、その高さＨのある最小パーセンテージである基部ＬおよびＷを有するように指定され得る。形状は、オプションで、たとえば２つの棒の間の最小距離など、その形状の複数のインスタンスをどのようにレイアウトできるのかにおける制約を指定することができる。
【０１８９】
次元セットに関して、これは、座標系から区別される。次元セットは、視覚化されるデータの次元と同数の次元を含む。次元は、通常のユークリッド軸ｘ、ｙ、およびｚならびに時間ｔより多数とすることができる。次元セットでは、いくつかを、ユークリッド（たとえば、デカルト座標もしくは極座標ｘ、ｙ、ｚ、または高さのｚを伴う地図座標）とすることができる。後に、ジオメトリによって使用される時に、これらのユークリッド軸の影響は、形状インスタンス系列（Ｓｈａｐｅ Ｉｎｓｔａｎｃｅ Ｓｅｒｉｅｓ）内の形状が、いくつかの座標で適当なスケーリング、変換、および分配を伴ってどのように挿入されまたは変換されるのかを詳細に叙述し、制御することである。他の次元は、クラスタ化および積み重ねなどのレイアウト効果を介して明示される。さらに他の次元は、アニメーションまたは運動速度など、より高いビジュアル次元を含むことができる。
【０１９０】
例として、既存の国を含むビジュアルアイテムを検討されたい。このビジュアルアイテムは、それぞれ、形状（国の形状を記述する）およびその国の中央の極座標に対応することができる。国の色に従ってレンダリングされるデータ系列もある場合がある。たとえば、青は、その国で対外援助に費やされる少量のリソースを表すことができる。赤は、その国で対外援助に費やされる、より大量のリソースを表すことができる。
【０１９１】
もう１つの次元をアニメートすることができる。たとえば、各国に関連する独楽があるものとすることができる。各国のその独楽次元を、政治的安定性スコアがどのようにして導出されるのかにかかわりなく、その国の政治的安定性に関するデータを用いて設定することができる。より低い政治的安定性を有する国は、より遅い動きおよびより大きい不安定とを伴ってアニメートされる独楽を有することができる。より高い政治的安定性を有する国は、より速い動きおよびより少ない不安定とを伴ってアニメートされる独楽を有することができる。他の非ユークリッド次元は、テクスチャを含むことができる。
【０１９２】
次元セットは、可視性／条件隠蔽、スクロール可能性、チルト、ラベリング、副分割、プロット可能な粒度、許容される範囲（たとえば、負数が許容されるかどうか）などの宣言を含むことができる。
【０１９３】
「ジオメトリ」は、１つのコンテナおよび１つまたは複数のバインダ−アレンジャからなる。
【０１９４】
コンテナに関して、ジオメトリは、その中でデータが形状によって視覚化されるコンテナのビジュアル要素／レイアウトの記述を含む。たとえば、最も単純な可能な棒グラフは、境界長方形の形状、コンテナの２／３Ｄ次元での均整（その代わりに、絶対次元）、座標系（たとえば、デカルト）を指定する。より洗練された視覚化は、追加の概念を指定することができる。たとえば、地図は、座標系内のどこに形状を配置できるのかを制限するジオメトリ内の副分割（ゾーン、街路など）を指定することができる。四分図は、そのデカルト軸が負値、色、テクスチャ、透明度、および他の制御可能なビジュアルパラメータに対処することを指定することができる。
【０１９５】
コンテナは、オプションで、対応するバインダ−アレンジャ内で必要なインテリジェンスの重要な部分を（しばしばソルバベースの）レイアウトヘルパの小さいセットに要因としてわけることを潜在的に可能にするメタデータを指定することができる。このメタデータは、たとえば、ユークリッド軸（さらなる軸タイプがある）が直線または曲線のどちらであるのか、コンテナが平坦または体積を占めるのどちらであるのか、コンテナがある次元に関して対称であるのかどうか、その他など、コンテナの諸態様を示す。
【０１９６】
第２に、ジオメトリは、１）データ値をどのようにして形状の次元属性（たとえば、高さ）またはビジュアル属性（たとえば、色）にマッピングするのか、および／またはデータ値に基づいて形状のセットからどのようにして選択すべきかを記述するＤａｔａＳｈａｐｅＢｉｎｄｉｎｇＰａｒａｍｓに、渡されたデータ系列およびオリジナルの形状（１つまたは複数）を適用することによって、形状インスタンス系列をどのように生成すべきか、２）渡された軸セットをコンテナの座標系およびコンテナの他のビジュアル要素（積み重ね、クラスタ化、着色、動きなど）にどのようにマッピングすべきか、３）ＳｈａｐｅＡｘｉｓＢｉｎｄｉｎｇＰａｒａｍｓに従って、コンテナにマッピングされた１つまたは複数の次元上に形状インスタンス系列をどのようにレイアウトすべきか、ならびに４）たとえば線を接続するか小さいサーフェス−レット（ｓｕｒｆａｃｅ−ｌｅｔ）またはパッチから連続面を作成するために、必要な場合にレイアウトされた形状の間でどのように補間すべきかを知っている「バインダ−アレンジャ」の宣言を、それと共に担持する。
【０１９７】
設定されたジオメトリ（すなわち、１つまたは複数のデータ系列および対応する形状を用いてインスタンス化されたジオメトリ）自体を、別のジオメトリに渡すために形状として扱うことができる。たとえば、積み重ねられ／クラスタ化された棒グラフでは、最も内側のジオメトリは、最も単純なコンテナすなわち他の棒をその中で積み重ねることができる棒を有する。最も内側のジオメトリを設定することは、第２のジオメトリに進む形状をもたらし、この第２のジオメトリでは、コンテナが、棒のクラスタである。最後に、第２のジオメトリを設定することから生じる形状は、最も外側のジオメトリに供給され、この最も外側のジオメトリは、水平軸に沿って形状をどのようにレイアウトすべきかを知っており、ｙ軸上でその高さを示しもする。
【０１９８】
上の積み重ねられ／クラスタ化された棒グラフの例では、最も内側のジオメトリは、高さだけを有し、第２のジオメトリは、（ソートされたまたはソートされていない）クラスタ化を有し、最も外側のジオメトリは、単純な（すなわち、積み重ねられていない）垂直次元および単純な（すなわち、クラスタ化を知らない）水平次元を有した。しかし、複合的な積み重ねられ／クラスタ化された棒グラフを、３つの態様すなわち積み重ねを知っている高さ次元、クラスタ次元、および水平Ｘ次元を有する次元セットにおいて解釈できる単一のジオメトリとして扱うこともできる。
【０１９９】
レイアウトヘルパは、アルゴリズムまたはソルバに頼り、含むジオメトリ内の形状の「正しい」または「最適の」位置ならびに形状の間の補間を判定するのを助ける。上で述べたように、レイアウトヘルパというアイデアは、バインダ−アレンジャ内の特異性を減らすためのものである。２種類のレイアウトヘルパすなわち、特定のバインダ−アレンジャのレベルで呼び出されるローカルレイアウトヘルパと、含むジオメトリ全体（その間に、ジオメトリ内の複数のＢ−Ａのプッティング形状（Ｂ−Ａ’ｓ ｐｕｔｔｉｎｇ ｓｈａｐｅ）の結果を含む）を調べるグローバルレイアウトヘルパとがある。
【０２００】
したがって、パイプラインは、さまざまなドメインにまたがる複雑な相互作用を可能にする。
【０２０１】
追加の例のアプリケーション
図１および２のアーキテクチャは、ドメインにかかわりなく、無数のデータ駆動分析モデルを構築することを可能にすることができる。これらのドメインに関して似ている必要があるものは、全くない。ビジュアルに対して分析を適用することが役立つ可能性がある、解かれるべき問題がある場合には必ず、本明細書で説明される原理が、有益になる可能性がある。ここまででは、風水部屋レイアウトアプリケーションを含む少数の例のアプリケーションだけが、説明された。本明細書で説明される原理の広い範囲にわたる適用可能性を示すために、複数の追加の広い範囲にわたる多様な例のアプリケーションを、これから説明する。
【０２０２】
追加の例＃１−小売業者棚配置
製品セールスマンは、しばしば、棚配置、エンドディスプレイ、および新しい販売促進を小売業者に売り込むために、３Ｄ視覚化を使用する。パイプライン２０１を用いて、セールスマンは、現場でｗｈａｔ−ｉｆを行うことができる。ある製品配置を与えられ、最小限の毎日の売上／リニアフットしきい値を考慮して、セールスマンは、最小限の必要な手元の在庫を計算し、視覚化することができる。逆に、ある手元の在庫を与えられ、隔週の補充サイクルを考慮して、セールスマンは、所望の売上／リニアフットを与える製品配置を計算することができる。小売業者は、影響を視覚化し、シナリオを比較し、利益を比較することができる。図２９は、例の小売業者棚配置視覚化を示す。入力データは、製品のビジュアルイメージ、製品の個数、製品ごとに割り当てられるリニア平方フィート単位の面積、および製品ごとの棚番号などを含むことができる。図２９の例は、仮想世界内のグラフの適用を示す。ここでは、プランシート２９０１および棚レイアウト２９０２を、棚レイアウト２９０２の変化がプランシート２９０１に影響し、逆も同様になるように分析的に関係付けることができる。
【０２０３】
追加の例＃２−都市計画
都市計画マッシュアップは、顕著になりつつある。本明細書で説明される原理を使用して、分析を、そのような解決策に統合することができる。都市計画立案者は、専門家によって作成されたトラフィックモデルを開き、道路改善のギャラリから橋をドラッグする。この橋は、長さ制約および暴風動作制限などの分析的挙動をそれと共に持ってくる。適当な視覚化を介して、立案者は、異なる橋タイプおよび配置のトラフィックに対する影響を見、比較する。本明細書で説明される原理を、地図がさまざまな目的のためのものである可能性がある任意の地図シナリオに適用することができる。地図を、地域の将来を理解し、ある位置への指示を見つけるためのものとすることができる。地図を、地域化されたデータを比較するための視覚的背景とすることもできる。より最近に、地図は、ビルディング、インテリア、および任意の２Ｄオブジェクトもしくは３Ｄオブジェクトを地図内でオーバーレイするか位置決めすることのできる仮想世界を作成するのに使用されつつある。図３０は、例の視覚化された都市計画を示す。やはり、グラフを、仮想世界（この例では１都市）の地図と機能的におよび分析的に統合できることに留意されたい。グラフが変化する時に、仮想世界も変化することができ、逆も同様である。
【０２０４】
追加の例＃３−ビジュアル教育
ドメイン実務家だけではなく公衆によって複雑なデータが理解される必要がある科学、医学、および人口統計などのドメインでは、作成者は、本明細書で説明される原理を使用して、大衆の好奇心をそそり、引き込むデータ視覚化を作成することができる。作成者は、ドメイン固有メタファを使用し、作成者のスタイルのセンスを分け与える。図３１は、子供の教育に関する図である。図３２は、人口密度に関する従来の図である。従来、そのような視覚化は、静的な図にすぎない。本明細書で説明される原理を用いると、これらが、生きた対話型経験になることができる。たとえば、入力データとして地理的に分布する増加パターンを入力することによって、ユーザは、人口ピークが変化するのを見ることができる。作成されたモデルがこれをサポートする、いくつかの視覚化は、ユーザがｗｈａｔ−ｉｆを行うことを許す。すなわち、作成者は、いくつかの値を変更し、他の値に対するその変化の影響を見ることができる。
【０２０５】
追加の例＃４−パラメトリックターゲットにビューコンポーネントを適用する
いくつかの場合に、たとえば図３３および３４に示されているように、さまざまなパラメトリックターゲット（たとえば、他のビューコンポーネント）にビューコンポーネントを適用することが望ましい可能性がある。具体的に言うと、図３３と３４との両方のパネルの高さは、１８１２年の不運なロシア方面作戦中のナポレオンの軍勢を表す。図３３では、パネルは、ナポレオン軍がたどった実際の経路を表すパラメトリックターゲットに適用される。図３４では、パネルは、異なるパラメトリックターゲットすなわち螺旋に適用される。したがって、ビューコンポーネント（パネルなど）を、異なるパラメトリックターゲット（たとえば、ナポレオン軍がたどった実際の経路を表すビューコンポーネントまたは螺旋を表すビューコンポーネント）に適用することができる。
【０２０６】
ビューコンポーネントを、それが適用されるパラメトリックターゲットの子とすることができる。たとえば、図３３のパネルを、軍経路の子とすることができ、図３４のパネルを、図３４の螺旋の子とすることができる。さらに、軍勢を表すラベルを、その高さが軍勢を表すパネルの子とすることができる。
【０２０７】
望ましくは、子ビューコンポーネントのプロパティに結び付けられたソルバおよび親ビューコンポーネントのプロパティに結び付けられたソルバを、依存関係ツリーを介して明示的に構成することができ、または、そのようなソルバを含むプロパティ−セッターの相互関係を介して暗黙のうちに構成することができる。
【０２０８】
したがって、子でプロパティをセットすることは、親のプロパティの再解決（時々、「エスカレーション」と呼ばれる）をトリガすることができ、親でプロパティをセットすることは、子のプロパティの再解決（時々、「委任」と呼ばれる）をトリガすることができる。たとえば、図３３を参照すると、ユーザは、パネルの高さを変更することを試みることができ、この変更は、パネルのスケールを増やすためにそのパネルのプロパティ−セッターをトリガすることができる。さらに、パネルのスケールのプロパティ−セッターは、パネルのセットのスケールに関するプロパティ−セッターを呼び出すことができる（エスカレーション）。次に、パネルのセットのスケールプロパティ−セッターは、パネルのそれぞれの個々のスケールプロパティ−セッターを呼び出すことができる（委任）。
【０２０９】
特に、図３３が、仮想世界へのグラフの適用の例であることに留意されたい。「仮想世界」とは、架空の地図のある現実のコンピュータ化された表現である。この地図は、２次元とすることができ、または、３次元とすることができる。たとえば、都市地図は、すべてが地理的関係においてレイアウトされる、街路、ビルディング、川などを含むことができる。その一方で、「グラフ」は、変数に適用されるデータ系列を表す。グラフを、グラフによって表されるデータ系列を仮想世界のある態様に適用することによって、本明細書で説明される原理を使用して仮想世界に適用することができる。その仮想世界の態様は、水平面、垂直面、３次元オブジェクトの外部サービス、ルートなどとすることができる。仮想世界は、実際の物理空間を表すことができ、または、仮定のエリアを表すのみとすることができる。仮想世界は、町の一部、都市、州、県、領域、ビルディング、近隣、惑星、または任意の他の物理的エリアのすべてを表すことができる。
【０２１０】
たとえば、図３３の例では、グラフデータは、複数の時間期間のそれぞれについて、その時点のナポレオン軍の人数を含む。この情報を、ナポレオン軍のルートに適用することができる。各棒の高さは、軍の行程の特定のセグメントでのナポレオン軍の兵隊の数を表す。望まれる場合に、川、都市、海、その他などの他の地理的特徴を、この地図に含めることができる。グラフを、座標系、軸、またはマーカーなどのグラフ特徴を表面などの仮想世界特徴に適用することによって、仮想世界に適用することができる。
【０２１１】
仮想世界へのグラフの適用の他の例として、ある会社が、従業員モラルを表すデータを有すると仮定する。このグラフデータを、各従業員のウィンドウの色をモラルに従ってある色にレンダリングすることによって、会社キャンパスの３次元レンダリングなどの仮想世界に適用することができる。たとえば、青のウィンドウは、幸福な従業員を表すことができ、赤のウィンドウは、不幸な従業員を表すことができる。その後、適当な分析を行うことができる。たとえば、キャンパス地図の高水準のビューをとり、どのビルディングがより赤い傾向があるのかを判定することができる。おそらく、ビルディングのうちの１つが、他のビルディングから分離され、対話のより少ない機会およびより低いモラルをもたらす可能性がある。次に、その会社は、将来にそのビルディングを貸し出すことを再検討し、これらの従業員のために、全体により近いビルディングを建てることを試みることができる。
【０２１２】
したがって、本明細書で説明される原理は、視覚化された問題解決および分析の世界における重大なパラダイムシフトをもたらす。このパラダイムシフトは、本明細書で説明される原理がすべてのドメインにあてはまり得るので、すべてのドメインにまたがってあてはまる。
【０２１３】
データのドメイン固有分類
戻って図２を参照すると、パイプライン２０１は、データ駆動である。たとえば、入力データ２１１は、データ部分２１０に供給され、分析データ２２１は、分析部分２２０に供給され、ビューデータ２３１は、ビュー部分２３０に供給される。これらのデータのそれぞれの例は、既に説明された。特に、ますます複雑なモデルを構成するためにモデルの諸部分を１つのモデルにインポートできる構成のたやすさを考慮すると、オーサリングコンポーネント２４０によって選択できるデータの量が、非常に多くなり得ると言えば十分である。正しいデータ２１１、２２１、および２３１を選択できるようにするためにデータを通ってナビゲートするのを助けるために、分類コンポーネント２６０は、入力データの複数のドメイン固有分類を提供する。
【０２１４】
図３５は、分類コンポーネント２６０が動作できる分類環境３５００を示す。分類は、カテゴリへのアイテムの類別と、これらのカテゴリの関係付けとを含む。したがって、環境３５００は、分類にかけられるアイテムのコレクション３５１０を含む。図３５では、アイテムのコレクション３５１０は、アイテム３５１１Ａから３５１１Ｐ（集合的に「メンバアイテム３５１１」と呼ばれる）を含む少数のアイテムのみを全体的に含むものとして図示されている。少数のメンバアイテム３５１１だけが図示されているが、任意の個数のアイテム、おそらくは、省略記号３５１１Ｑによって表されるように、類別され分類されなければならない数百個、数千個、または数百万個ものアイテムがある可能性がある。メンバアイテム３５１１は、オーサリングコンポーネント２４０がパイプライン２０１にデータ２１１、２２１、および２３１を供給するためにそこから選択できるメンバアイテムのプールを含む。
【０２１５】
ドメインに敏感な分類コンポーネント３５２０は、メンバアイテム３５１１のすべてまたは一部にアクセスし、メンバアイテム３５１１の別個の分類を生成することもできる。たとえば、分類コンポーネント３５２０は、ドメイン固有分類３５２１を生成する。この場合には、省略記号３５２１Ｆによって表される潜在的な他の分類の中で、５つのドメイン固有分類３５２１Ａから３５２１Ｅがある。分類コンポーネント３５２０によって作成され管理される、５つより少数のドメイン固有分類がある場合もある。
【０２１６】
例として、分類３５２１Ａは、風水ドメインに適切なメンバアイテムを分類することができ、分類３５２１Ｂは、モーターサイクル設計ドメインに適切なメンバアイテムを分類することができ、分類３５２１Ｃは、同様に都市計画ドメインに適切とすることができ、分類３５２１Ｄは、在庫管理ドメインに適切とすることができ、分類３５２１Ｅは、抽象芸術作品ドメインに適切とすることができる。もちろん、これらは、パイプライン２０１によって供給できる潜在的に無数のドメインのうちの５つにすぎない。分類のそれぞれは、対応する分類で類別するために使用可能なメンバアイテムのすべてまたはサブセットを使用することができる。
【０２１７】
図３６は、メンバアイテムの分類の一特定の単純な例３６００を示す。たとえば、分類を、図３５のドメイン固有分類３５２１Ａとすることができる。後続の図は、より複雑な例を示す。分類３６００は、メンバアイテム３５１１Ａおよび３５１１Ｅを除くメンバアイテム３５１１のすべてを含むカテゴリノード３６１０を含む。カテゴリノード３６１０は、たとえば、成分メンバアイテムへのポインタを含むオブジェクトとすることができ、したがって、論理的な意味で、メンバアイテムを、カテゴリノード３６１０「内に含まれる」と考えることができる。カテゴリノード３６１０は、候補メンバアイテムのプロパティを使用してカテゴリノード３６１０のメンバシップ資格を記述するプロパティ相関記述子３６１１を関連付けられもする。あるメンバアイテムをあるカテゴリに含めるべきか否かを判定する時に、プロパティ相関記述子を使用して、そのメンバアイテムのプロパティに対してその記述子を評価することができる。
【０２１８】
分類では、２つのカテゴリを、複数の異なる形でお互いに関係付けることができる。１つの一般的な関係は、あるカテゴリが別のカテゴリのサブセットであることである。たとえば、乗物を表すすべてのオブジェクトを含む「乗物」カテゴリがある場合に、乗物カテゴリのサブセットを含む「自動車」カテゴリがある場合がある。両方のカテゴリのプロパティ相関記述子は、特定の関係を定義することができる。たとえば、乗物カテゴリのプロパティ相関記述子は、１）オブジェクトが可動である、２）オブジェクトが人間を含むことができるというプロパティを有するオブジェクトが、そのカテゴリに含まれることを示すことができる。自動車カテゴリのプロパティ相関記述子は、この２つのプロパティ要件を明示的にまたは暗黙のうちにのいずれかで含むことができ、１）オブジェクトがオブジェクトの移動中に地球との接触を維持する少なくとも３つの車輪を含み、２）オブジェクトが自動推進であり、３）オブジェクトの高さが６フィート（１．８３ｍ）を超えないというプロパティ要件を含むこともできる。カテゴリごとのプロパティ相関記述子に基づいて、分類コンポーネントは、任意の所与のドメイン固有分類内の１つまたは複数のカテゴリにオブジェクトを割り当てることができ、カテゴリの間の関係を理解することもできる。
【０２１９】
図３６では、別のプロパティ相関記述子３６２１を含む第２のカテゴリノード３６２０が図示されている。カテゴリノード３６２０は、プロパティ相関記述子３６２１を満足するすべてのメンバアイテムを論理的に含む。この場合に、そのカテゴリノードに論理的に含まれるメンバアイテムは、第１のカテゴリノード３６１０に含まれるメンバアイテムのサブセットである（たとえば、メンバアイテム３５１１Ｆ、３５１１Ｊ、３５１１Ｎ、および３５１１Ｐを含む）。これは、第２のカテゴリノード３６２０のプロパティ相関記述子３６２１が、１つまたは複数の追加のプロパティ要件を除いて、第１のカテゴリノード３６１０の相関記述子３６１１と同一のプロパティ要件を指定するからである可能性がある。第１のカテゴリノード３６１０と第２のカテゴリノード３６２０との間の関係は、関係３６１５によって論理的に表される。
【０２２０】
乗物−自動車の例では、カテゴリの間の関係は、サブセット関係である。すなわち、一方のカテゴリ（たとえば、自動車カテゴリ）が、他方（たとえば、乗物カテゴリ）のサブセットである。しかし、さまざま他のタイプの関係もあり、おそらく、以前に全く認識されず、使用されなかった新しい関係さえある。たとえば、あるカテゴリ内のオブジェクトの過半数（またはある指定されたパーセンテージ）が特定のプロパティ値を有する場合に、別のカテゴリ内のオブジェクトが、このプロパティを有し、このプロパティ値を継承する、過半数継承関係がある可能性がある。オブジェクトの一方のカテゴリが、可視光のある波長範囲内の原色を有する場合に、他方のカテゴリが、可視光のある隣接する波長範囲内の原色を有するオブジェクトを含む、「類似色」関係がある可能性がある。あるカテゴリが、主に特定のウィルスによって引き起こされる、ある種の感染症を表すオブジェクトを含む場合に、関連するカテゴリが、そのウィルスの突然変異型によって引き起こされるある種の感染症を表すオブジェクトを含むことができる、「ウィルス突然変異」関係がある可能性がある。これらの例は、量に関して延々と続く可能性がある。当業者は、この説明を再検討した後に、カテゴリの間の関係の種類が制限されないことを認めるであろう。
【０２２１】
さらに、単一の分類が、多数の異なるタイプの関係を有することができる。明瞭さのために、さまざまな分類を、これから抽象的な意味で説明する。抽象的に表された分類の例を、図３７Ａから３７Ｃに示す。その後、本明細書で説明される原理がデータ駆動視覚化でドメイン固有分類の無数のアプリケーションを可能にすることを理解して、特定の例を説明する。
【０２２２】
図３６の例は、単純な２カテゴリノード分類であるが、図３７Ａから３７Ｃの例は、より複雑である。図３７Ａから３７Ｃの分類３７００Ａから３７００Ｃ内の各ノードは、０個以上のメンバアイテムを含むカテゴリノードを表し、本質的にカテゴリノードへのメンバアイテムの参加を許可する受付ポリシである、それぞれに関連するプロパティ相関記述子を有することができる。しかし、不当な複雑さを回避するために、分類３７００Ａから３７００Ｃのカテゴリノードのそれぞれのメンバアイテムおよびプロパティ相関記述子は、図示されていない。カテゴリノードの間の線は、カテゴリノードの間の関係を表す。これらの関係は、限定なしに、サブセット関係またはある他の種類の関係とすることができる。カテゴリノードの間の関係の正確な性質は、重要ではない。それでも、分類においてカテゴリノードの間のさまざまな関係タイプがある可能性があることを強調するために、関係に、Ａ、Ｂ、Ｃ、Ｄ、またはＥのラベルを付ける。
【０２２３】
図３７Ａから３７Ｃは、例としてのみ提供される。図３７Ａから３７Ｃの分類の正確な構造は、重要ではないだけではなく、本明細書で説明される原理は、どの種類の分類を入力候補メンバアイテムの同一のセットに基づいてさえ生成できることにおける高い柔軟性を可能にする。これらの例では、分類３７００Ａは、関係タイプＡ、Ｂ、およびＣを使用して互いに関係付けられたカテゴリノード３７０１Ａから３７１０Ａを含む。分類３７００Ｂは、関係タイプＢ、Ｃ、およびＤを使用して互いに関係付けられたカテゴリノード３７０１Ｂから３７０８Ｂを含む。分類３７００Ｃは、関係タイプＣ、Ｄ、およびＥを使用して互いに関係付けられたカテゴリノード３７０１Ｃから３７１２Ｃを含む。この例では、分類３７００Ａおよび３７００Ｂは、階層的であるが、分類３７００Ｃは、より非階層的なネットワークである。
【０２２４】
新しい候補メンバアイテムが使用可能になる時に、これらの候補メンバアイテムを、各分類内のカテゴリノードのそれぞれのプロパティ相関記述子に対して評価することができる。メンバアイテムのプロパティが、そのメンバアイテムがプロパティ相関記述子の要件（すなわち、受付ポリシ）を満足することを可能にする値を有する場合には、そのメンバアイテムは、そのカテゴリノードへの参加を許可される。たとえば、おそらくは、そのメンバアイテムへのポインタが、そのカテゴリノードに追加される。したがって、新しいメンバアイテムが、十分な数のプロパティを有する場合には、新しいメンバアイテムが、すべての分類内の適当なカテゴリに自動的にインポートされる可能性がある。
【０２２５】
図３８は、複数のプロパティ３８０１を含むメンバアイテム３８００を示す。単一のプロパティがある場合があるが、メンバアイテム３８００に関連する潜在的に数千個のプロパティがある可能性もある。図３８では、メンバアイテム３８００は、省略記号３８０１Ｆによって表される潜在的に他のプロパティの中で、４つのプロパティ３８０１Ａ、３８０１Ｂ、３８０１Ｃ、および３８０１Ｄを含むものとして図示されている。これらのプロパティを何にすることができるのかに対する制限はない。これらを、メンバアイテムを分類に類別する際に有用である可能性がある何にでもすることができる。
【０２２６】
一実施形態で、データ部分２１０、分析部分２２０、およびビュー部分２３０のそれぞれの潜在的データを、分類することができる。たとえば、作成者が、個人（消費者または近隣住人）が都市の地図とインターフェースすることを可能にする消費者アプリケーションをその中で構成しているドメインを検討されたい。
【０２２７】
この消費者ドメインには、選択できるビューデータ２３１の分類がある可能性がある。たとえば、ビルディングのすべてを含むビルディングカテゴリがある可能性がある。異なるタイプのビルディングすなわち、政府ビルディング、病院、レストラン、家屋などがある可能性がある。鉄道サブカテゴリ、車道サブカテゴリ、および運河サブカテゴリを含む公共輸送カテゴリもある可能性がある。車道カテゴリは、街路、ハイウェイ、自転車専用道路、陸橋などを表すカテゴリまたはオブジェクトを含む可能性がある。街路カテゴリは、一方通行街路、マルチライン街路、右左折専用車線、中央車線などのビジュアル表現のオブジェクトまたはカテゴリを含む可能性がある。駐車場の異なるタイプのビジュアル表現または駐車場の他のサブカテゴリ（たとえば、立体駐車場、地下駐車場、路上駐車場、パーキングロットなど）を示す駐車場カテゴリがある可能性がある。駐車場を、駐車が無料であるか否か、またはコストがあるかどうかによって副類別することもできる。
【０２２８】
この消費者ドメインに、入力データの分類もある可能性がある。たとえば、駐車場構造は、たとえば、１）駐車場がバレットパーキングであるかどうか、２）駐車に関する１時間あたりの料金はどれほどか、３）駐車場が営業中の時間、４）駐車場が警備によって巡視されているかどうか、および、そうである場合に、駐車場の単位面積あたり何人の警備員がいるのか、５）駐車場のレベル数、６）１レベルだけがある場合には駐車場の平方フィート単位の面積、立体駐車場の場合には各レベルの平方フィート単位の面積、７）駐車場構造内で発生する自動車泥棒の毎年の過去の回数、８）駐車場の体積使用量、９）駐車場が１つまたは複数の条件（すなわち、近くの会社の従業員、レストランまたは商店街の得意客など）の満足に制限されるかどうか、または役立つ可能性がある任意の他のデータなどのデータを関連付けられる可能性がある。他のビジュアルアイテムにも関連するデータ、およびビジュアルアイテムがどのようにレンダリングされるのかには絶対に影響しない可能性があるが、ある点で計算に使用される可能性があるデータも、ある可能性がある。
【０２２９】
しかし、この消費者地図ドメインに固有の分析データ２２１の分類もある可能性がある。たとえば、分析は、あるカテゴリでのコストベースの分析、もう１つのカテゴリでの時間ベースの分析、もう１つのカテゴリでの距離ベースの分析、もう１つのカテゴリでのディレクトリ分析、およびもう１つのカテゴリでのルーティング分析を提示することができる。ここで、分析は、作成者が所望のアプリケーションのために分析モデルを定式化するのを助けるために分類される。たとえば、ルーティング分析カテゴリは、ルートを計算する式、ルーティングに対してどの制限を行えるのかを指定する制約（最短ルート、ハイウェイの最大使用、街路の回避など）、またはルール（特定の道路上のトラフィック方向など）のカテゴリを含むことができる。類似するサブカテゴリを、他のカテゴリのためにも含めることもできる。
【０２３０】
ここで、やはり都市のレイアウトを扱うが、今回はドメインが都市計画である、別のドメインを検討されたい。ここで、消費者にとってほとんど関心のないものである、都市計画立案者には興味深い分析がある。たとえば、あるトラフィック使用量を考慮して舗装をどれほど厚くしなければならないのか、あるエリア内に配置されるある道路タイプのリニアフットあたりの総設置および保守コストはどれほどか、次の２０年間の期待されるトラフィックパターン予想を考慮して、ある橋の安全係数をどれほどにするのか、現在の都市計画でトラフィックボトルネックは何か、特定のビルディングが特定の位置に建築された場合の環境影響はどれほどか、ある制限がその特定のビルディングの使用に対して課せられる場合にその影響はどれほどか、などを計算する分析がある可能性がある。ここで、解かれるべき問題は、消費者ドメインで解かれるべき問題とは異なる。したがって、分析の分類は、消費者ドメインと比較して、両方が都市トポロジを扱う場合であっても、都市計画ドメインについて大きく異なってレイアウトされる可能性がある。
【０２３１】
その一方で、トラクタ設計ドメインは、分析の全く異なるセットで関心を持たれる可能性があり、異なる分類を使用するはずである。たとえば、トラクタ設計ドメインのビジュアルアイテムは、都市計画ドメインのビジュアルアイテムとは全く異なる可能性がある。もはや、都市ビジュアル要素には関係がない。今は、トラクタを構成するさまざまなビジュアル要素が、分類される。例として、ビジュアルアイテムは、何を何に接続できるのかの関係を使用して分類される可能性がある。たとえば、「シートに接続できるもの」、「キャブレタに接続できるもの、「後車軸に接続できるもの」などのカテゴリがある可能性がある。異なる分析分類がある可能性もある。たとえば、トラクタが濡れた土を通ってナビゲートする必要があることを考慮すると、タイヤのトレッドデプスに関する制約がある可能性がある。トラクタまたはその副構成要素の総重量を計算する分析などがある可能性がある。
【０２３２】
図３９は、ドメイン固有分類３９００を示し、図３５のドメイン固有分類３５２１の一例を表す。一実施形態で、ドメイン固有分類は、使用可能なデータアイテムの少なくともいくつかが対応する関係するカテゴリに分類されるデータ分類３９０１と、使用可能なビューコンポーネントの少なくともいくつかが対応する関係するビューコンポーネントカテゴリに分類されるビューコンポーネント分類３９０３と、使用可能な分析の少なくともいくつかが相関する関係する分析カテゴリに分類される分析分類３９０２とを含む。データ、分析、およびビューコンポーネントがドメインに固有の形で分類されるそのようなドメイン固有分類の例は、既に説明された。
【０２３３】
図４０は、分析をナビゲートし、使用する方法を示す。分析コンポーネント２２０が、対応するドメイン固有分析分類（行為４００３）と一緒にアクセスされる（行為４００１）。複数のドメイン固有分析分類がある場合には、ドメイン固有分析分類にアクセスできるようになる（行為４００３）前に、まずドメインを識別することができる（行為４００２）。
【０２３４】
次に、関係付けられたカテゴリをトラバースすることによって、分析分類をナビゲートすることができる（行為４００４）。このナビゲーションを、コンピューティングシステムの助けを得て人間によって実行することができ、または、人間の同時発生の支援なしでコンピューティングシステムだけによって実行することさえできる。コンピュータまたは人間は、分析を各カテゴリに入れるための受付ポリシを定義する、カテゴリごとの相関プロパティ記述子から情報を導出することができる。情報を、カテゴリの間の関係によって導出することもできる。ナビゲーションを使用して、これによって出力モデルパラメータについて解き、またはおそらくは複数のモデルからの分析を合併するために、分析問題を解くことができる。代替案では、ナビゲーションを使用して、最初の段階で分析モデルを構成することができる。
【０２３５】
たとえば、分析分類が、解かれるべき問題のタイプのアイデンティティに関して関係を類別すると仮定する。コンポーザは、関心を持たれている問題タイプカテゴリ内のこれらの分析のすべてを再検討することによって開始することができる。そのカテゴリは、解かれるべき問題の諸部分を定義する関係付けられたカテゴリを有する可能性がある。ユーザは、これらの関係付けられたカテゴリにすばやくナビゲートし、そのドメインで関係する分析を見つけることができる。
【０２３６】
検索および探索
前に述べたように、データ駆動分析モデルを使用して、分析集中型の検索動作および探索動作を形成することができる。図４１は、データ駆動分析モデルを使用して検索する方法４１００の流れ図を示す。方法４１００を、検索ツール２４２が検索要求を受け取るか他の形でこれにアクセスする（行為４１０１）たびに実行することができる。
【０２３７】
本明細書で説明される原理は、ユーザが検索要求を入力するのに使用できる機構に限定されない。それでも、少数の例を、さまざまな検索要求入力機構を示すためにこれから提供する。一例では、おそらく、検索要求は、テキストベースであり、テキスト検索フィールドに直接に入力される。別の例では、おそらく、ラジオボタンが、検索パラメータを入力するために書き込まれる。おそらく、スライダも、検索パラメータの範囲を入力するために使用され得る。検索要求生成は、ユーザを伴う対話型の形で生成された可能性がある。たとえば、ユーザが、ある雑音レベル範囲を経験する不動産を要求する場合に、アプリケーションは、徐々に大きくなる雑音を生成し、雑音が、ユーザが我慢したいものより大きくなった時に「うるさすぎる雑音」ボタンを押すようにユーザに求めることができる。
【０２３８】
検索要求は、従来の検索要求ではなく、データ駆動分析モデルの解く動作を要求することができる。しかし、解く前に、図２の検索ツール２４２は、要求に応答できるようになるために、それについて解かれるべきすべてのモデルパラメータを識別する（行為４１０２）。これは、たとえば、上で述べたさまざまな分離を使用して達成され得る。たとえば、ユーザが、１年のどの時点でも９時１５分の後に山の陰に入らない不動産を検索している場合に、それについて解かれるべき「山の陰」と呼ばれるモデル変数がある可能性がある。ユーザが、ある雑音レベルを経験する不動産を検索する場合に、特定の座標を与えられて、それについて解かれるべき「平均雑音」と呼ばれるモデル変数がある可能性がある。
【０２３９】
関連する出力変数が識別された後に、分析部分２２０の分析関係が、出力変数について解くのに使用される（行為４１０３）。次に、解かれた出力変数（１つまたは複数）が、解かれた値（１つまたは複数）を使用して検索要求への応答を定式化するために検索ツール２４２によって使用される（行為４１０４）。いくつかの場合に、ユーザが、方法４１００が実行されつつある時に方法４１００と相互作用する可能性があるが、方法４１００は、人間からの同時発生の支援なしでコンピューティングシステムによって実行され得る。検索要求を、ユーザによって、またはおそらくは別のコンピューティングモジュールまたはソフトウェアモジュールによってさえ、発行することができる。
【０２４０】
方法４１００を、何回も、検索要求が処理されるたびに繰り返すことができる。それについて解かれるべきモデル変数は、検索要求ごとに異なるものとすることができるが、そうである必要はない。たとえば、ある価格範囲および雑音レベルを有する家屋に関する３つの検索要求がある場合がある。たとえば、４０００，０００ドルから６００，０００ドルまでの価格範囲内で、その平均雑音レベルが５０デシベル未満の家屋に関する検索要求がある可能性がある。ここでのそれについて解かれるべきパラメータは、雑音レベルになるはずである。第２の検索要求を、２００，０００ドルから５００，０００ドルまでの価格範囲内で、その雑音レベルが６０デシベル未満の家屋に関するものとすることができる、ここでのそれについて解かれるべきパラメータは、やはり雑音レベルになるはずである。しかし、第２の検索要求では、解く動作のいくつかが、検索要求について既に行われたことに留意されたい。たとえば、第１の検索要求に基づいて、システムは、既に、その平均雑音レベルが５０デシベル未満である、４０００，０００ドルから５００，０００ドルまでの価格範囲内の家屋を識別した。したがって、これらの家屋について、雑音レベルを再計算する必要はない。解かれた後に、これらの値を、将来の検索のために保存することができる。したがって、これは、ユーザが、追加の要求をサブミットすることによって探索を実行することを可能にする。その後、ユーザは、４００，０００ドルから５００，０００ドルまでの価格範囲内で、４５デシベル未満の雑音レベルを有する家屋に関する第３の検索要求をサブミットすることができる。この家屋の雑音レベルは、既にそれについて解かれているので、それらについてもう一度解く必要はない。したがって、検索結果を、はるかにより少ない計算を用いて返すことができる。本質的に、このシステムは、問題を解くことによって新しい情報を学習することができ、他の問題を解くのにその新しい情報を利用することができる。
【０２４１】
前に述べたように、各検索要求は、異なる出力モデル変数について解くことを含む可能性がある。たとえば、説明したばかりの検索要求を実行した後に、ユーザは、山の陰に入らない家屋に関する検索要求をサブミットする可能性がある。システムがこれについて解いた後に、このユーザまたは別のユーザが類似する要求をサブミットする時には必ず、その解決からの結果を、その後続の検索要求を満足するのに使用することができる。ユーザは、マグニチュード８．０の地震で立ったままでいる家屋に関する検索要求をサブミットし、シミュレーションに、各家屋が立ったままでいるか倒れるかのいずれかになることを検証させ、またはおそらくはその家屋が立ったままになる、あるパーセンテージ可能性を提供させることができる。正確なシミュレーションを実行するのに不十分な構造情報があった家屋について、システムは、結果が確定的でないと単純に述べることができる。地震シミュレーションが実行された後に、再シミュレーションを必要とした家屋に対するある構造的変更があった場合を除き、また、ある改善されたシミュレーションソルバがあった場合を除いて、その結果は、誰かがあるマグニチュードの地震に耐えることのできる家屋に関する検索要求をサブミットする時に必ず、使用され得る。ユーザは、カテゴリ５のハリケーンが発生した場合に洪水を受けず、破壊されない、ある価格範囲内の家屋に関する検索要求を実行することもできる。
【０２４２】
諸実施形態をある詳細で説明したが、注記として、本明細書で説明されるさまざまな動作および構造を、コンピューティングシステムによって実施することができるが、そうである必要はない。したがって、この説明の最後に、例のコンピューティングシステムを、図２５に関して説明する。
【０２４３】
図４２は、コンピューティングシステム４２００を示す。コンピューティングシステムは、今やますますさまざまな形をとりつつある。コンピューティングシステムは、たとえば、ハンドヘルドデバイス、機器、ラップトップコンピュータ、デスクトップコンピュータ、メインフレーム、分散コンピューティングシステム、または従来はコンピューティングシステムではなかったデバイスにさえすることができる。この説明および特許請求の範囲では、用語「コンピューティングシステム」は、少なくとも１つのプロセッサと、プロセッサによって実行され得るコンピュータ実行可能命令をその上に有することができるメモリとを含む任意のデバイスまたはシステム（またはその組合せ）を含むものとして広義に定義される。メモリは、任意の形をとることができ、コンピューティングシステムの性質および形態に依存することができる。コンピューティングシステムは、ネットワーク環境を介して分散させることができ、複数の成分コンピューティングシステムを含むことができる。
【０２４４】
図４２に示されているように、その最も基本的な構成で、コンピューティングシステム４２００は、通常、少なくとも１つの処理ユニット４２０２およびメモリ４２０４を含む。メモリ４２０４は、物理システムメモリとすることができ、物理システムメモリは、揮発性、不揮発性、またはこの２つのある組合せとすることができる。用語「メモリ」は、本明細書で、物理記憶媒体などの不揮発性大容量記憶装置を指すのに使用される場合もある。コンピューティングシステムが分散される場合には、処理能力、メモリ能力、および／または記憶能力をも分散させることができる。本明細書で使用される時に、用語「モジュール」または「コンポーネント」は、コンピューティングシステム上で実行するソフトウェアオブジェクトまたはルーチンを指すことができる。本明細書で説明される異なるコンポーネント、モジュール、エンジン、およびサービスを、コンピューティングシステム上で実行するオブジェクトまたはプロセスとして（たとえば、別々のスレッドとして）実施することができる。
【０２４５】
これに続く説明では、諸実施形態が、１つまたは複数のコンピューティングシステムによって実行される行為を参照して説明される。そのような行為がソフトウェアで実施される場合に、その行為を実行する関連するコンピューティングシステムの１つまたは複数のプロセッサは、コンピュータ実行可能命令を実行したことに応答してコンピューティングシステムの動作を指示する。そのような動作の例は、データの操作を伴う。コンピュータ実行可能命令（および操作されたデータ）を、コンピューティングシステム４２００のメモリ４２０４に格納することができる。
【０２４６】
コンピューティングシステム４２００は、コンピューティングシステム４２００がたとえばネットワーク４２１０を介して他のメッセージプロセッサと通信することを可能にする通信チャネル４２０８をも含むことができる。通信チャネル４２０８は、通信媒体の例である。通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実施し、任意の情報配送媒体を含む。限定ではなく例として、通信媒体は、有線ネットワークおよび直接配線接続などの有線媒体と、音響、無線、赤外線、および他の無線媒体などの無線媒体とを含む。用語コンピュータ可読媒体は、本明細書で使用される時に、記憶媒体と通信媒体との両方を含む。
【０２４７】
実施形態：
実施形態１について説明する。
ビュー構成の１つまたは複数のビューコンポーネントのプロパティを定義する複数のモデル変数を使用する、コンピュータにより実施される方法であって、
前記複数のモデル変数の未知の第２のモデル変数（１５０３ｂ）について解く（１４０１）ために前記複数のモデル変数の既知の第１のモデル変数（１５０３ａ）を使用することと、
ここで、前記第２のモデル変数（１５０３ｂ）は、前記ビュー構成の第１のビューコンポーネントの第１のプロパティを定義するものであり、
前記解かれた第２のモデル変数（１５０３ｂ）の値に前記ビュー構成の前記第１のビューコンポーネント第１のビューコンポーネントの前記第１のプロパティをセットする（１４０３）ことと、
前記第１のビューコンポーネントを含む前記ビュー構成をレンダリングする（１４０４）ことと
を具えたことを特徴とする方法。
【０２４８】
実施形態２について説明する。
コンピューティングシステムの１つまたは複数のプロセッサによって実行される時に、前記コンピューティングシステムに方法を実行させるコンピュータ実行可能命令をその上に有する１つまたは複数の物理コンピュータ可読媒体を含むコンピュータプログラムであって、前記コンピュータ実行可能命令は、
第１のプロパティ−セッター（１５０２ａ）を呼び出す（１６０１）１つまたは複数のコンピュータ実行可能命令であって、前記第１のプロパティ−セッター（１５０２ａ）は、ビュー構成の少なくとも１つのビューコンポーネントの少なくとも１つのプロパティをセットし（１６０２）、第２のプロパティ−セッター（１５０２ｂ）を呼び出す（１６０３）ように構成され、前記第２のプロパティ−セッター（１５０２ｂ）は、
前記ビュー構成の１つまたは複数のビューコンポーネントのプロパティを定義する複数のモデル変数の未知の第１のモデル変数について解くように構成されたソルバ（１５０１ｂ）を呼び出し（１６０４）、
前記解かれた第１のモデル変数の値に前記ビュー構成の第１のビューコンポーネントの第１のプロパティをセットする（１６０５）
ように構成される、１つまたは複数のコンピュータ実行可能命令
を具えたことを特徴とするコンピュータプログラム。
【０２４９】
本発明の範囲内の実施形態は、その内部に格納されたコンピュータ実行可能命令またはデータ構造を担持しまたは有するコンピュータ可読媒体をも含む。そのようなコンピュータ可読媒体は、汎用コンピュータまたは特殊目的コンピュータによってアクセスされ得るすべての使用可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイスなどの物理記憶媒体および／もしくはメモリ媒体、またはコンピュータ実行可能命令もしくはデータ構造の形で所望のプログラムコード手段を担持するか格納するのに使用でき、汎用コンピュータもしくは特殊目的コンピュータによってアクセスされ得る任意の他の媒体を含むことができる。上記の組合せも、コンピュータ可読媒体の範囲に含まれなければならない。
【０２５０】
コンピュータ実行可能命令は、たとえば、汎用コンピュータ、特殊目的コンピュータ、または特殊目的処理デバイスにある機能または機能のグループを実行させる命令およびデータを含む。本主題を、構造的特徴および／または方法論的行為に固有の言語で説明したが、添付の特許請求の範囲で定義される本主題が、必ずしも本明細書で説明された特定の特徴または行為に限定されないことを理解されたい。そうではなく、本明細書で説明される特定の特徴および行為は、特許請求の範囲を実施する例の形として開示されたものである。
【０２５１】
本発明を、その趣旨または本質的特性から逸脱せずに他の特定の形で実施することができる。説明された実施形態は、すべての面で、制限的ではなく例示的であるのみと考えられなければならない。したがって、本発明の範囲は、前述の説明ではなく添付の特許請求の範囲によって示される。特許請求の範囲の意味および同等性の範囲に含まれるすべての変更は、その範囲に含まれなければならない。

【特許請求の範囲】
【請求項１】
ビュー構成の１つまたは複数のビューコンポーネントのプロパティを定義する複数のモデル変数を使用する、コンピュータ実施される方法であって、
前記複数のモデル変数の未知の第２のモデル変数について解くために前記複数のモデル変数の既知の第１のモデル変数を使用することと、
ここで、前記第２のモデル変数は、前記ビュー構成の第１のビューコンポーネントの第１のプロパティを定義するものであり、
前記解かれた第２のモデル変数の値に前記ビュー構成の前記第１のビューコンポーネント第１のビューコンポーネントの前記第１のプロパティをセットすることと、
前記第１のビューコンポーネントを含む前記ビュー構成をレンダリングすることと
を具えたことを特徴とするコンピュータ実施される方法。
【請求項２】
前記既知の第１のモデル変数は、前記第１のビューコンポーネントの第２のプロパティ第２のプロパティを定義することを特徴とする請求項１記載のコンピュータ実施される方法。
【請求項３】
前記第１のビューコンポーネントの前記第１のプロパティのプロパティ−セッターによって呼び出されるソルバは、前記複数のモデル変数の前記未知の第２のモデル変数について解くために前記複数のモデル変数の前記既知の第１のモデル変数を使用することを実行し、
前記第１のビューコンポーネントの前記第１のプロパティの前記プロパティ−セッターは、前記解かれた第２のモデル変数の前記値に前記ビュー構成の前記第１のビューコンポーネントの前記第１のプロパティをセットすることを実行することを特徴とする請求項２記載のコンピュータ実施される方法。
【請求項４】
前記第１のビューコンポーネントの前記第１のプロパティの前記プロパティ−セッターは、前記第１のビューコンポーネントの前記２プロパティのプロパティ−セッターによって呼び出されることを特徴とする請求項３記載のコンピュータ実施される方法。
【請求項５】
前記既知の第１のモデル変数は、前記ビュー構成の第２のビューコンポーネントの第１のプロパティを定義することを特徴とする請求項１記載のコンピュータ実施される方法。
【請求項６】
前記第１のビューコンポーネントの前記第１のプロパティのプロパティ−セッターによって呼び出されるソルバは、前記複数のモデル変数の前記未知の第２のモデル変数について解くために前記複数のモデル変数の前記既知の第１のモデル変数を使用することを実行し、
前記第１のビューコンポーネントの前記第１のプロパティの前記プロパティ−セッターは、前記解かれた第２のモデル変数の前記値に前記ビュー構成の前記第１のビューコンポーネントの前記第１のプロパティをセットすることを実行することを特徴とする請求項５記載のコンピュータ実施される方法。
【請求項７】
前記第１のビューコンポーネントの前記第１のプロパティの前記プロパティ−セッターは、前記第２のビューコンポーネントの前記１プロパティのプロパティ−セッターによって呼び出されることを特徴とする請求項６記載のコンピュータ実施される方法。
【請求項８】
前記第１のビューコンポーネントは、前記第２のビューコンポーネントの子であることを特徴とする請求項７記載のコンピュータ実施される方法。
【請求項９】
前記第２のビューコンポーネントは、前記第１のビューコンポーネントの子であることを特徴とする請求項７記載のコンピュータ実施される方法。
【請求項１０】
前記第１のビューコンポーネントの前記第１のプロパティのプロパティ−セッターによって呼び出されるソルバは、前記複数のモデル変数の前記未知の第２のモデル変数について解くために前記複数のモデル変数の前記既知の第１のモデル変数を使用することを実行し、
前記第１のビューコンポーネントの前記第１のプロパティの前記プロパティ−セッターは、前記解かれた第２のモデル変数の前記値に前記ビュー構成の前記第１のビューコンポーネントの前記第１のプロパティをセットすることを実行することを特徴とする請求項１記載のコンピュータ実施される方法。
【請求項１１】
コンピューティングシステムの１つまたは複数のプロセッサによって実行される時に、前記コンピューティングシステムに方法を実行させるコンピュータ実行可能命令をその上に有する１つまたは複数の物理コンピュータ可読媒体を含むコンピュータプログラムであって、前記コンピュータ実行可能命令は、
第１のプロパティ−セッターを呼び出す１つまたは複数のコンピュータ実行可能命令であって、前記第１のプロパティ−セッターは、ビュー構成の少なくとも１つのビューコンポーネントの少なくとも１つのプロパティをセットし、第２のプロパティ−セッターを呼び出すように構成され、前記第２のプロパティ−セッターは、
前記ビュー構成の１つまたは複数のビューコンポーネントのプロパティを定義する複数のモデル変数の未知の第１のモデル変数について解くように構成されたソルバを呼び出し、
前記解かれた第１のモデル変数の値に前記ビュー構成の第１のビューコンポーネントの第１のプロパティをセットする
ように構成される、１つまたは複数のコンピュータ実行可能命令
を具えたことを特徴とするコンピュータプログラム。
【請求項１２】
前記第１のプロパティ−セッターは、前記ビュー構成の前記第１のビューコンポーネントの第２のプロパティをセットするように構成されることを特徴とする請求項１１記載のコンピュータプログラム。
【請求項１３】
前記第１のプロパティ−セッターは、前記ビュー構成の第２のビューコンポーネントの第１のプロパティをセットするように構成されることを特徴とする請求項１１記載のコンピュータプログラム。
【請求項１４】
前記第１のビューコンポーネントは、前記第２のビューコンポーネントの子であることを特徴とする請求項１３記載のコンピュータプログラム。
【請求項１５】
前記第２のビューコンポーネントは、前記第１のビューコンポーネントの子であることを特徴とする請求項１３記載のコンピュータプログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８Ａ】

【図１８Ｂ】

【図１９Ａ】

【図１９Ｂ】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７Ａ】

【図３７Ｂ】

【図３７Ｃ】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【公表番号】特表２０１２−５３０９７５（Ｐ２０１２−５３０９７５Ａ）
【公表日】平成２４年１２月６日（２０１２．１２．６）
【国際特許分類】
【出願番号】特願２０１２−５１６３５７（Ｐ２０１２−５１６３５７）
【出願日】平成２２年６月１８日（２０１０．６．１８）
【国際出願番号】ＰＣＴ／ＵＳ２０１０／０３９２６８
【国際公開番号】ＷＯ２０１０／１４８３６４
【国際公開日】平成２２年１２月２３日（２０１０．１２．２３）
【出願人】（５０００４６４３８）マイクロソフト　コーポレーション (3,165)
【Ｆターム（参考）】