知財求人 - 知財ポータルサイト「IP Force」
特表2019-505877プロジェクト階層のオーグメンテーション、探査およびメンテナンスのための方法
この文献は図面が300枚以上あるため,図面を表示できません.
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】特表2019-505877(P2019-505877A)
(43)【公表日】2019年2月28日
(54)【発明の名称】プロジェクト階層のオーグメンテーション、探査およびメンテナンスのための方法
(51)【国際特許分類】
G06F 16/00 20190101AFI20190201BHJP
【ＦＩ】
G06F17/30 419B
【審査請求】未請求
【予備審査請求】未請求
【全頁数】197
(21)【出願番号】特願2018-527974(P2018-527974)
(86)(22)【出願日】2016年11月25日
(85)【翻訳文提出日】2018年7月24日
(86)【国際出願番号】US2016063789
(87)【国際公開番号】WO2017091821
(87)【国際公開日】20170601
(31)【優先権主張番号】62/260,072
(32)【優先日】2015年11月25日
(33)【優先権主張国】US
(81)【指定国】
AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＪＡＶＡ
(71)【出願人】
【識別番号】518183479
【氏名又は名称】チーミフィア，インコーポレイテッド
(74)【代理人】
【識別番号】100114775
【弁理士】
【氏名又は名称】高岡 亮一
(74)【代理人】
【識別番号】100121511
【弁理士】
【氏名又は名称】小田 直
(74)【代理人】
【識別番号】100202751
【弁理士】
【氏名又は名称】岩堀 明代
(74)【代理人】
【識別番号】100191086
【弁理士】
【氏名又は名称】高橋 香元
(72)【発明者】
【氏名】ガンツ，スティーブン
(57)【要約】
ネットワークを介したユーザ 協働を促進するように、有向 非周期 グラフの一部を階層 ツリー 構造としてグラフィカルに 示す方法が提供される。本方法は、 複数の ユーザ間で共有される 協働 プロジェクトを通信 ネットワークを介して入手することを含む。前記プロジェクト は、 複数の エンティティおよび 複数の関係付けを含む有向 非周期 グラフ 構造によって示され、前記複数の エンティティは１つ以上の ローカス エンティティを含み、 前記ローカス エンティティはそれぞれ、 ローカス ノードと関連付けられる。ローカス ノードからは 、 各ローカス エンティティの前記有向 非周期 グラフ中の祖先 エンティティ が反転 ツリー 構造としてトラバースされ、 前記反転 ツリー中の各子 ノードは、前記有向 非周期 グラフ中の 親として関連する 各エンティティを前記反転 ツリー中のその 親の前記エンティティに対して示す。本方法は、前記反転 ツリーのリーフノード においてユーザ 入力に応答してルートされた サブツリーを拡張させることを含む。【選択図】図１０９
[この文献は図面を表示できません]
【特許請求の範囲】
【請求項1】
ヒエラルキツリー構造としてグラフィックに指向性非環式グラフを表示し、通信ネットワークを介してユーザの共同作業を容易にするシステムであって、
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、複数のエンティティと複数の対応関係を含む指向型非環式グラフ構造により示され、上記複数のエンティティは、１つ以上のローカスエンティティを含み、該１つ以上のローカスエンティティのそれぞれは、各ローカスエンティティの子孫エンティティが、上記指向型非環式グラフにおいて、ツリー構造として延びる起点となるローカスノードと対応付けられており、上記ツリーにおける各子ノードは上記指向型非環式グラフにおける子として、上記ツリーにおける親のエンティティと
関連付けられている各エンティティを示す、取得と、
ユーザ入力に応じて上記ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、複数のエンティティと複数の対応関係を含む指向型非環式グラフ構造により示され、上記複数のエンティティは、１つ以上のローカスエンティティを含み、該１つ以上のローカスエンティティのそれぞれは、各ローカスエンティティの子孫エンティティが、上記指向型非環式グラフにおいて、ツリー構造として延びる起点となるローカスノードと対応付けられており、上記ツリーにおける各子ノードは上記指向型非環式グラフにおける子として、上記ツリーにおける親のエンティティと
関連付けられている各エンティティを示す、取得と、
ユーザ入力に応じて上記ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
【請求項2】
ヒエラルキツリー構造としてグラフィックに指向性非環式グラフを表示し、通信ネットワークを介してユーザの共同作業を容易にするシステムであって、
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、複数のエンティティと複数の対応関係を含む指向型非環式グラフ構造により示され、上記複数のエンティティは、１つ以上のローカスエンティティを含み、該１つ以上のローカスエンティティのそれぞれは、各ローカスエンティティの祖先エンティティが、上記指向型非環式グラフにおいて、反転ツリー構造として延びる起点となるローカスノードと対応付けられており、上記反転ツリーにおける各子ノードは上記指向型非環式グラフにおける親として、上記反転ツリーにおける親のエンティティと関連付けられている各エンティティを示す、取得と、
ユーザ入力に応じて上記反転ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、複数のエンティティと複数の対応関係を含む指向型非環式グラフ構造により示され、上記複数のエンティティは、１つ以上のローカスエンティティを含み、該１つ以上のローカスエンティティのそれぞれは、各ローカスエンティティの祖先エンティティが、上記指向型非環式グラフにおいて、反転ツリー構造として延びる起点となるローカスノードと対応付けられており、上記反転ツリーにおける各子ノードは上記指向型非環式グラフにおける親として、上記反転ツリーにおける親のエンティティと関連付けられている各エンティティを示す、取得と、
ユーザ入力に応じて上記反転ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
【請求項3】
請求項１のシステムであって、
上記命令は、さらに上記システムに、
上記システムが、上記展開が上記ユーザ入力に応じて上記複数のノードの上記少なくとも１つのノードを展開するのに応じて、上記ツリーの少なくとも１つの他ノードに根を有する上記サブツリーを折り畳むことを可能にし、それにより上記複数のエンティティの特定のエンティティに、上記複数のノードの内の１つの可視ノードによりグラフィックに示されることを可能にすることを実行させるシステム。
上記命令は、さらに上記システムに、
上記システムが、上記展開が上記ユーザ入力に応じて上記複数のノードの上記少なくとも１つのノードを展開するのに応じて、上記ツリーの少なくとも１つの他ノードに根を有する上記サブツリーを折り畳むことを可能にし、それにより上記複数のエンティティの特定のエンティティに、上記複数のノードの内の１つの可視ノードによりグラフィックに示されることを可能にすることを実行させるシステム。
【請求項4】
請求項３のシステムであって、
上記命令は、さらに上記システムに、
上記システムが、上記展開が上記ユーザ入力に応じて上記複数のノードの上記少なくとも１つのノードを展開するのに応じて、上記反転ツリーの少なくとも１つの他ノードに根を有する上記サブツリーを折り畳むことを可能にし、それにより上記複数のエンティティの特定のエンティティに、上記複数のノードの内の多くても１つの可視ノードによりグラフィックに示されることを可能にすることを実行させるシステム。
上記命令は、さらに上記システムに、
上記システムが、上記展開が上記ユーザ入力に応じて上記複数のノードの上記少なくとも１つのノードを展開するのに応じて、上記反転ツリーの少なくとも１つの他ノードに根を有する上記サブツリーを折り畳むことを可能にし、それにより上記複数のエンティティの特定のエンティティに、上記複数のノードの内の多くても１つの可視ノードによりグラフィックに示されることを可能にすることを実行させるシステム。
【請求項5】
請求項１のシステムであって、
いくつかのエンティティが、１つ以上のファイルの何れかに対応付けられており、１つ以上の進捗レポートがそれぞれ、期間、上記プロジェクトへの貢献の１つ以上の記録、ユーザにより探査可能なサブ構造を有するローカスとして設定可能な関連エンティティ、または補助データをカバーし、
上記命令は、さらに上記システムに、
各可視ノードにより示された上記特定ノードに対応付けられた、期間、上記プロジェクトへの貢献の１つ以上の記録、ユーザにより探査可能なサブ構造を有するローカスとして設定可能な関連エンティティ、または補助データの集約を上記システムが表示可能にすることを実行させるシステム。
いくつかのエンティティが、１つ以上のファイルの何れかに対応付けられており、１つ以上の進捗レポートがそれぞれ、期間、上記プロジェクトへの貢献の１つ以上の記録、ユーザにより探査可能なサブ構造を有するローカスとして設定可能な関連エンティティ、または補助データをカバーし、
上記命令は、さらに上記システムに、
各可視ノードにより示された上記特定ノードに対応付けられた、期間、上記プロジェクトへの貢献の１つ以上の記録、ユーザにより探査可能なサブ構造を有するローカスとして設定可能な関連エンティティ、または補助データの集約を上記システムが表示可能にすることを実行させるシステム。
【請求項6】
請求項１のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記ローカスエンティティの１つ以上の少なくとも１つの適切な詳細化祖先が、さらに、上記対応する１つ以上のローカスエンティティの子孫ではない１つ以上の他の子孫と対応付けられており
、上記１つ以上の他の子孫は、上記対応する１つ以上のローカスノードの継承済み子孫として明確に示され、上記１つ以上のローカスノードのそれぞれを示すシステム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記ローカスエンティティの１つ以上の少なくとも１つの適切な詳細化祖先が、さらに、上記対応する１つ以上のローカスエンティティの子孫ではない１つ以上の他の子孫と対応付けられており
、上記１つ以上の他の子孫は、上記対応する１つ以上のローカスノードの継承済み子孫として明確に示され、上記１つ以上のローカスノードのそれぞれを示すシステム。
【請求項7】
請求項１のシステであって、上記命令は、さらに上記システムに
第１操作による上記指向型非環式グラフの拡張であって、該第１操作は、新たなノードを上記複数のノードに追加し、上記複数のノードの内の特定のノードから開始されるものであり、上記新たなノードは、上記特定のノードの子として表示される、拡張と、
上記新たなノードに対応付けされた新たなエンティティと、該新たなエンティティと上記特定のエンティティと間の対応関係の作成であって、上記新たなノードと上記対応関係の種類は、第１操作に基づいている、作成とを実行させるシステム。
第１操作による上記指向型非環式グラフの拡張であって、該第１操作は、新たなノードを上記複数のノードに追加し、上記複数のノードの内の特定のノードから開始されるものであり、上記新たなノードは、上記特定のノードの子として表示される、拡張と、
上記新たなノードに対応付けされた新たなエンティティと、該新たなエンティティと上記特定のエンティティと間の対応関係の作成であって、上記新たなノードと上記対応関係の種類は、第１操作に基づいている、作成とを実行させるシステム。
【請求項8】
請求項６のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり
上記命令は、継承ノード、再言及操作または、上記パスの最終再言及ノードにおけて実行される第２操作からなるパスにより、該第２操作の前兆としてローカスノードに接続されている、上記複数のノードの内の、開始文脈ノードからユーザが操作を開始すると、
上記ローカスノードからのパス上の、上記ローカスノードを除く各継承済みノードについて、上記システムに、さらに
再言及エンティティの作成と、
上記再言及エンティティと上記ローカスノードにより示されたエンティティ間に第１対応関係を作成する第１対応関係の作成であって、もし上記ローカスノードが上記継承済みノードの親である、または、上記再言及エンティティと、上記パスに沿った上記継承済みノードの親の再言及の結果の間にある場合、上記第１対応関係は、上記継承済みエンティティと上記適切な詳細化祖先の間の対応関係と同じ種類であり、もし上記ローカスノードが上記継承済みノードの親でない場合、上記第１対応関係は、上記継承済みノードが示すエンティティと、その親ノードが示すエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記再言及エンティティと、再言及された上記継承済みエンティティとの間に第２対応関係を作成する第２対応関係の作成であって、上記再言及エンティティが、再言及された上記継承済みエンティティを詳細化する、第２対応関係の作成とを実行させる、システム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり
上記命令は、継承ノード、再言及操作または、上記パスの最終再言及ノードにおけて実行される第２操作からなるパスにより、該第２操作の前兆としてローカスノードに接続されている、上記複数のノードの内の、開始文脈ノードからユーザが操作を開始すると、
上記ローカスノードからのパス上の、上記ローカスノードを除く各継承済みノードについて、上記システムに、さらに
再言及エンティティの作成と、
上記再言及エンティティと上記ローカスノードにより示されたエンティティ間に第１対応関係を作成する第１対応関係の作成であって、もし上記ローカスノードが上記継承済みノードの親である、または、上記再言及エンティティと、上記パスに沿った上記継承済みノードの親の再言及の結果の間にある場合、上記第１対応関係は、上記継承済みエンティティと上記適切な詳細化祖先の間の対応関係と同じ種類であり、もし上記ローカスノードが上記継承済みノードの親でない場合、上記第１対応関係は、上記継承済みノードが示すエンティティと、その親ノードが示すエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記再言及エンティティと、再言及された上記継承済みエンティティとの間に第２対応関係を作成する第２対応関係の作成であって、上記再言及エンティティが、再言及された上記継承済みエンティティを詳細化する、第２対応関係の作成とを実行させる、システム。
【請求項9】
請求項６のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、継承ノードおよび未継承ノード、再言及操作または、上記パスの最終再言及ノードにおけて実行される第２操作からなるパスにより、該第２操作の前兆としてローカスノードに接続されている、上記複数のノードの内の、開始文脈ノードからユーザが開始を行うと、上記ローカスノードからのパス上の、上記ローカスノードを除く各ノードについて、上記システムに、さらに
上記パスノードが継承された場合は、上記パスノード再言及エンティティの作成と、
上記パスノードの親が継承された場合、または、ローカスノードである場合、もし上記パスノードが継承されているなら、上記再言及エンティティ、そうでないなら上記パスノードと、上記ローカスノードが示す何れかのエンティティとの間に第１対応関係を作成する第１対応関係の作成であって、上記第１対応関係は、もし上記ローカスノードが上記パスノードの親である場合または上記パスに沿った上記パスノードの親の再言及の結果である場合は、上記パスエンティティと上記適切な詳細化祖先の間の対応関係と同じ種類であり、もし上記ローカスノードが上記パスノードの親でない場合は、上記第１対応関係は上記パスノードに示されたエンティティとその親ノードが示すエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
もし上記パスノードが継承された場合、上記再言及エンティティと、再言及される上記継承済みパスエンティティの間に第２対応関係を作成する第２対応関係の作成であって、上記再言及エンティティは、再言及される上記継承済みパスエンティティを詳細化する、第２対応関係の作成とを実行させるシステム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、継承ノードおよび未継承ノード、再言及操作または、上記パスの最終再言及ノードにおけて実行される第２操作からなるパスにより、該第２操作の前兆としてローカスノードに接続されている、上記複数のノードの内の、開始文脈ノードからユーザが開始を行うと、上記ローカスノードからのパス上の、上記ローカスノードを除く各ノードについて、上記システムに、さらに
上記パスノードが継承された場合は、上記パスノード再言及エンティティの作成と、
上記パスノードの親が継承された場合、または、ローカスノードである場合、もし上記パスノードが継承されているなら、上記再言及エンティティ、そうでないなら上記パスノードと、上記ローカスノードが示す何れかのエンティティとの間に第１対応関係を作成する第１対応関係の作成であって、上記第１対応関係は、もし上記ローカスノードが上記パスノードの親である場合または上記パスに沿った上記パスノードの親の再言及の結果である場合は、上記パスエンティティと上記適切な詳細化祖先の間の対応関係と同じ種類であり、もし上記ローカスノードが上記パスノードの親でない場合は、上記第１対応関係は上記パスノードに示されたエンティティとその親ノードが示すエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
もし上記パスノードが継承された場合、上記再言及エンティティと、再言及される上記継承済みパスエンティティの間に第２対応関係を作成する第２対応関係の作成であって、上記再言及エンティティは、再言及される上記継承済みパスエンティティを詳細化する、第２対応関係の作成とを実行させるシステム。
【請求項10】
請求項６のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、上記複数のノードの内の継承開始ノードであって、それぞれローカスノードに、再言及操作または、各パスの最終再言及ノードにおいて実行される第２操作の継承済みノードからなる対応するパスにより、該第２操作の前兆として接続されている継承開始ノードからユーザが開始を行うと、複数のパスの内の何れかのパス上の、ローカスノードを除く、各ノードについて、上記システムに、さらに
再言及エンティの作成と、
上記再言及エンティティと上記ローカスノードにより示されたエンティティの間に第１対応関係を作成する、第１対応関係の作成であって、上記第１対応関係は、もし上記ローカスノードが上記継承済みノードの親である場合は、上記継承済みエンティティと上記適切な詳細化祖先との間の対応関係と同じ種類であり、そうでなければ、上記再言及エンティティと、上記対応するパスに沿った上記継承済みノードの親の再言及の結果との間の対応関係と同じ種類であり、もし上記ローカスノードが上記継承済みノードの親でなければ、上記第１対応関係は、上記継承済みノードにより示されたエンティティと、その親ノードにより示されたエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記再言及エンティティと、再言及される上記継承済みエンティティとの間に第２対応関係を作成する、第２対応関係の作成であって、上記再言及エンティティは、再言及される上記継承済みエンティティを詳細化する第２対応関係の作成とを実行させるシステム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、上記複数のノードの内の継承開始ノードであって、それぞれローカスノードに、再言及操作または、各パスの最終再言及ノードにおいて実行される第２操作の継承済みノードからなる対応するパスにより、該第２操作の前兆として接続されている継承開始ノードからユーザが開始を行うと、複数のパスの内の何れかのパス上の、ローカスノードを除く、各ノードについて、上記システムに、さらに
再言及エンティの作成と、
上記再言及エンティティと上記ローカスノードにより示されたエンティティの間に第１対応関係を作成する、第１対応関係の作成であって、上記第１対応関係は、もし上記ローカスノードが上記継承済みノードの親である場合は、上記継承済みエンティティと上記適切な詳細化祖先との間の対応関係と同じ種類であり、そうでなければ、上記再言及エンティティと、上記対応するパスに沿った上記継承済みノードの親の再言及の結果との間の対応関係と同じ種類であり、もし上記ローカスノードが上記継承済みノードの親でなければ、上記第１対応関係は、上記継承済みノードにより示されたエンティティと、その親ノードにより示されたエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記再言及エンティティと、再言及される上記継承済みエンティティとの間に第２対応関係を作成する、第２対応関係の作成であって、上記再言及エンティティは、再言及される上記継承済みエンティティを詳細化する第２対応関係の作成とを実行させるシステム。
【請求項11】
請求項８のシステムであって、
上記少なくとも２つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記１つ以上の子孫は、上記ローカスノードの継承済みの子孫として明確に示されており、
上記少なくとも１つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記子孫は、再言及詳細化を含み、
上記再言及ノードとその子孫は、上記ローカスノードの上記継承済み子孫から除外されているシステム。
上記少なくとも２つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記１つ以上の子孫は、上記ローカスノードの継承済みの子孫として明確に示されており、
上記少なくとも１つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記子孫は、再言及詳細化を含み、
上記再言及ノードとその子孫は、上記ローカスノードの上記継承済み子孫から除外されているシステム。
【請求項12】
請求項８のシステムであって、
上記少なくとも１つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記１つ以上の子孫は、上記ローカスノードの継承済み子孫として明確に示されており、
上記少なくとも１つの他の子は、上記ローカスノードの子孫により再言及され、
上記他の子は、上記ローカスノードの継承済み子孫から除外されているシステム。
上記少なくとも１つの他の子が、上記ローカスノードの子孫ではない１つ以上の子孫と対応付けられており、上記１つ以上の子孫は、上記ローカスノードの継承済み子孫として明確に示されており、
上記少なくとも１つの他の子は、上記ローカスノードの子孫により再言及され、
上記他の子は、上記ローカスノードの継承済み子孫から除外されているシステム。
【請求項13】
請求項２のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、さらに上記システムに、
第１操作による上記指向型非環式グラフの拡張であって、該第１操作は、新たなノードを上記複数のノードに追加し、上記複数のノードの内の特定のノードから開始されるものであり、上記新たなノードは、上記特定のノードの反転ツリーにおいて、上記特定のノードの子として表示される、拡張と、
上記新たなノードに対応付けされた新たなエンティティと、該新たなエンティティと上記特定のエンティティと間の対応関係の作成であって、上記新たなノードの種類は、上記特定のノードの種類と同じであり、上記対応関係の種類は詳細化であり、上記特定のノードは上記新たなノードを詳細化している、作成とを実行させるシステム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、
上記命令は、さらに上記システムに、
第１操作による上記指向型非環式グラフの拡張であって、該第１操作は、新たなノードを上記複数のノードに追加し、上記複数のノードの内の特定のノードから開始されるものであり、上記新たなノードは、上記特定のノードの反転ツリーにおいて、上記特定のノードの子として表示される、拡張と、
上記新たなノードに対応付けされた新たなエンティティと、該新たなエンティティと上記特定のエンティティと間の対応関係の作成であって、上記新たなノードの種類は、上記特定のノードの種類と同じであり、上記対応関係の種類は詳細化であり、上記特定のノードは上記新たなノードを詳細化している、作成とを実行させるシステム。
【請求項14】
請求項２のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、そして
上記命令は、上記複数のノードの内の開始文脈ノードからユーザが操作を開始すると、上記開始文脈ノードと上記対応するローカスノードの間のパス上の、上記開始文脈ノードを除く、複数の文脈ノードのそれぞれに対し、上記システムに、
一般化エンティティを、上記新たなエンティティの種類を上記文脈ノードの種類と同じとして作成する一般化エンティティの作成と、
上記一般化エンティティと上記開始文脈ノードにより示されたエンティティの間に、第１対応関係を生成する第１対応関係の生成であって、上記第１対応関係は、もし上記文脈ノードが上記開始文脈ノードの上記反転ツリーにおける親である場合、上記文脈エンティティと、上記開始文脈ノードにより示されたエンティティの間の対応関係と同じ種類であり、もし文脈ノードが上記開始文脈ノードの上記反転ツリーにおける親でない場合、上記第１対応関係は、上記文脈ノードにより示されたエンティティのと、上記反転ツリーにおけるその子ノードにより示されたエンティティの間の対応関係と同じ種類である、第１対応関係の作成と、
上記一般化エンティティと、上記文脈ノードにより示されたエンティティの間に第２対応関係を作成する第２対応関係の作成であって、上記一般化エンティティは、上記文脈ノードにより示されたエンティティにより詳細化される第２対応関係の作成とを実行させる、システム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、そして
上記命令は、上記複数のノードの内の開始文脈ノードからユーザが操作を開始すると、上記開始文脈ノードと上記対応するローカスノードの間のパス上の、上記開始文脈ノードを除く、複数の文脈ノードのそれぞれに対し、上記システムに、
一般化エンティティを、上記新たなエンティティの種類を上記文脈ノードの種類と同じとして作成する一般化エンティティの作成と、
上記一般化エンティティと上記開始文脈ノードにより示されたエンティティの間に、第１対応関係を生成する第１対応関係の生成であって、上記第１対応関係は、もし上記文脈ノードが上記開始文脈ノードの上記反転ツリーにおける親である場合、上記文脈エンティティと、上記開始文脈ノードにより示されたエンティティの間の対応関係と同じ種類であり、もし文脈ノードが上記開始文脈ノードの上記反転ツリーにおける親でない場合、上記第１対応関係は、上記文脈ノードにより示されたエンティティのと、上記反転ツリーにおけるその子ノードにより示されたエンティティの間の対応関係と同じ種類である、第１対応関係の作成と、
上記一般化エンティティと、上記文脈ノードにより示されたエンティティの間に第２対応関係を作成する第２対応関係の作成であって、上記一般化エンティティは、上記文脈ノードにより示されたエンティティにより詳細化される第２対応関係の作成とを実行させる、システム。
【請求項15】
請求項２のシステムであって、
上記反転ツリー構造は、複数のツリー構造を含む森構造内に形成され、各ツリー構造が、サブストレートツリーに提示された２つのリストを、一方を他方にネスティングして備え、
ツリー構造の第１リスト
ノードの第２リスト
全ての第２リストの全てのノードは、最後のノードを除いて、上記サブストレートツリーに子を有しておらず、
ローカスノードは、上記サブストレートツリーに兄弟や子を有しておらず、
全ての第２リストの各ノードに示される上記エンティティは、上記第２リストの上記最後のノードの上記サブストレートツリーの第１リストにおける各子の上記サブストレートツリーの第２リストにおける第１子の上記指向型非環式グラフにおける親であるシステム。
上記反転ツリー構造は、複数のツリー構造を含む森構造内に形成され、各ツリー構造が、サブストレートツリーに提示された２つのリストを、一方を他方にネスティングして備え、
ツリー構造の第１リスト
ノードの第２リスト
全ての第２リストの全てのノードは、最後のノードを除いて、上記サブストレートツリーに子を有しておらず、
ローカスノードは、上記サブストレートツリーに兄弟や子を有しておらず、
全ての第２リストの各ノードに示される上記エンティティは、上記第２リストの上記最後のノードの上記サブストレートツリーの第１リストにおける各子の上記サブストレートツリーの第２リストにおける第１子の上記指向型非環式グラフにおける親であるシステム。
【請求項16】
請求項１のシステムであって、
上記反転ツリー構造は、複数のツリー構造を含む森構造内に形成され、各ツリー構造が、サブストレートツリーに提示された２つのリストを、一方を他方にネスティングして備え、
指定されたノードを含むツリー構造の第１リスト
ノードの第２リスト
全ての第２リストのノードにより示された各エンティティは、子を有さず、上記サブストレートツリーにおけるそれらの親ツリー構造の指定されたノードにより示されたエンティティの上記指向型非環式グラフにおける子であり、
最も外側のツリー構造は、ローカスノードのみのリストを有し、
すべての第１リストの各ツリー構造の上記指定されたノードにより示されたエンティティは、上記サブストレートツリーにおけるかれらの親の親の上記指定されたノードにより示されたエンティティの上記指向型非環式グラフにおける子であるシステム。
上記反転ツリー構造は、複数のツリー構造を含む森構造内に形成され、各ツリー構造が、サブストレートツリーに提示された２つのリストを、一方を他方にネスティングして備え、
指定されたノードを含むツリー構造の第１リスト
ノードの第２リスト
全ての第２リストのノードにより示された各エンティティは、子を有さず、上記サブストレートツリーにおけるそれらの親ツリー構造の指定されたノードにより示されたエンティティの上記指向型非環式グラフにおける子であり、
最も外側のツリー構造は、ローカスノードのみのリストを有し、
すべての第１リストの各ツリー構造の上記指定されたノードにより示されたエンティティは、上記サブストレートツリーにおけるかれらの親の親の上記指定されたノードにより示されたエンティティの上記指向型非環式グラフにおける子であるシステム。
【請求項17】
請求項１５のシステムであって、
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、そして
上記命令は、ユーザが、上記複数のノードの中の開始文脈ノードのから、操作を開始すると、上記開始文脈ノードとローカスノードとの間の上記サブストレートツリーを介した何れかのパス上の、上記開始文脈ノードを除く複数の文脈ノードのそれぞれについて、上記開始文脈ノードを含むより、各第１リストの上記第１素子を含む、上記システムに、
一般化エンティティの作成と、
上記一般化エンティティと上記開始文脈ノードにより示されたエンティティとの間に第１対応関係を作成する第１対応関係の作成であって、上記第１対応関係は、もし上記文脈ノードが、上記開始文脈ノードの上記反転ツリー内の親である場合、上記文脈ノードと、上記開始文脈ノードにより示されたエンティティの間の対応関係と同じ種類であり、もし上記文脈ノードが上記開始文脈ノードの上記反転ツリー内の親でない場合は、上記第１対応関係は、上記文脈ノードにより示されたエンティティと上記反転ツリーにおけるその子ノードにより示されたエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記一般化エンティティと上記文脈ノードにより示されたエンティティとの間に第２対応関係を作成する、第２対応関係の作成であって、上記一般化エンティティは、上記文脈ノードにより示されたエンティティにより詳細化される、第２対応関係の作成とを実行させる、システム。
エンティティは、特定の種類のそれぞれであって、対応関係は特定の種類のそれぞれであって、そのような対応関係の１種類が詳細化であり、そして
上記命令は、ユーザが、上記複数のノードの中の開始文脈ノードのから、操作を開始すると、上記開始文脈ノードとローカスノードとの間の上記サブストレートツリーを介した何れかのパス上の、上記開始文脈ノードを除く複数の文脈ノードのそれぞれについて、上記開始文脈ノードを含むより、各第１リストの上記第１素子を含む、上記システムに、
一般化エンティティの作成と、
上記一般化エンティティと上記開始文脈ノードにより示されたエンティティとの間に第１対応関係を作成する第１対応関係の作成であって、上記第１対応関係は、もし上記文脈ノードが、上記開始文脈ノードの上記反転ツリー内の親である場合、上記文脈ノードと、上記開始文脈ノードにより示されたエンティティの間の対応関係と同じ種類であり、もし上記文脈ノードが上記開始文脈ノードの上記反転ツリー内の親でない場合は、上記第１対応関係は、上記文脈ノードにより示されたエンティティと上記反転ツリーにおけるその子ノードにより示されたエンティティとの間の対応関係と同じ種類である、第１対応関係の作成と、
上記一般化エンティティと上記文脈ノードにより示されたエンティティとの間に第２対応関係を作成する、第２対応関係の作成であって、上記一般化エンティティは、上記文脈ノードにより示されたエンティティにより詳細化される、第２対応関係の作成とを実行させる、システム。
【請求項18】
請求項１４のシステムであって、
上記作成さらた一般化対象詳細化は、再言及を含むシステム。
上記作成さらた一般化対象詳細化は、再言及を含むシステム。
【請求項19】
ヒエラルキツリー構造としてグラフィックに指向性非環式グラフを表示し、通信ネットワークを介してユーザの共同作業を容易にするシステムであって、
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、特定の種類のそれぞれの複数のエンティティと特定の種類のそれぞれの複数の対応関係を含む指向型非環式グラフ構造により示され、そのような種類の１つは詳細化であり、上記複数のエンティティは、少なくとも１つのローカスエンティティを含み、該少なくとも１つのローカスエンティティのそれぞれは、各ローカスエンティティの子孫エンティティが、上記指向型非環式グラフにおいて、ツリー構造として延びる起点となるローカスノードと対応付けられており、上記ツリーにおける各子ノードは上記指向型非環式グラフにおける子として、上記ツリーにおける親のエンティティと関連付けられている各エンティティを示し、１つ以上の上記ローカスエンティティの
少なくとも１つの適切な詳細化祖先が、さらに、上記対応する１つ以上のローカスエンティティの子孫ではない１つ以上の他の子孫と対応付けられ、上記少なくとも１つの他の子孫のそれぞれは、上記少なくとも１つのローカスエンティティを示す上記対応する少なくとも１つのローカスノードの継承済み子孫として明確に示されている、取得と、
ユーザ入力に応じて上記ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
１つ以上のプロセッサと、
命令を記録したメモリとを備え、
上記命令は、上記１つ以上のプロセッサにより実行されると、上記システムに、
通信ネットワークを介して複数のユーザ間で共有された共同プロジェクトを取得する取得であって、上記共同プロジェクトは、特定の種類のそれぞれの複数のエンティティと特定の種類のそれぞれの複数の対応関係を含む指向型非環式グラフ構造により示され、そのような種類の１つは詳細化であり、上記複数のエンティティは、少なくとも１つのローカスエンティティを含み、該少なくとも１つのローカスエンティティのそれぞれは、各ローカスエンティティの子孫エンティティが、上記指向型非環式グラフにおいて、ツリー構造として延びる起点となるローカスノードと対応付けられており、上記ツリーにおける各子ノードは上記指向型非環式グラフにおける子として、上記ツリーにおける親のエンティティと関連付けられている各エンティティを示し、１つ以上の上記ローカスエンティティの
少なくとも１つの適切な詳細化祖先が、さらに、上記対応する１つ以上のローカスエンティティの子孫ではない１つ以上の他の子孫と対応付けられ、上記少なくとも１つの他の子孫のそれぞれは、上記少なくとも１つのローカスエンティティを示す上記対応する少なくとも１つのローカスノードの継承済み子孫として明確に示されている、取得と、
ユーザ入力に応じて上記ツリーのリーフノードに根を有するサブツリーを展開する展開とを、実行させるシステム。
【発明の詳細な説明】
【技術分野】
【0001】
[0001]本開示は、プロジェクト 情報（プロジェクトそのものおよび関連情報を含む）を示す階層 構造の レイアウトおよびオーグメンテーションと、 階層 構造を通じた探査と、協働 設定に改変が生じた場合のこれらの構造のメンテナンスとに関する。
【発明の概要】
【0002】
[0002]いくつかの 実施形態において、 本開示 は、 DAG (恐らくはツリー) をオーグメントする際の方法を提供する。このDAG は、少なくとも２種類のエンティティを提示し、そのうち、前記第1の (独立的な) 種類の１つのエンティティは、前記第２の 種類の各エンティティが前記第1の 種類の １つのエンティティと間接的に関連付けられるようにこの関係 を伸長させるように、前記第２の (従属的な) 種類のエンティティと直接関連付けられ得る。
【0003】
[0003]いくつかの 実施形態において、 本開示 は、厳密に前記ローカス ノードの前記サブ構造ではないかまたは厳密にその文脈においてそうではない情報へのアクセスを提供しかつ前記文脈との関係付けを介して前記サブ構造 を継承するように１つ以上の ローカス ノードが中央となるようにDAGを ナビゲートする際の方法を提供する。さらに、このような継承された 構造がトップダウン オーグメンテーション される場合、当該 構造を継承する１つ以上の ローカス ノードについて（当該構造をより高精度に定義できるような様態で）当該構造が詳細化されることを暗示する。前記サブ構造との関係付けを介して前記文脈に情報を継承することも適切であり得る。 同様に、このような継承された 構造がボトムアップ オーグメンテーションされた場合、当該構造を継承した１つ以上の ローカス ノードについて当該構造が詳細化されることを暗示する。 あるいは、前記文脈中のノードがトップダウン オーグメンテーション される場合、前記関連した ローカス ノードについて前記先行 文脈 が一般化されることを暗示し得る。
【0004】
[0004]本明細書中に記載のいくつかの実施形態において、先ず、「階層 構造およびその文脈の表現の探査方法」において初期に行われるようにまたはベン図または他の任意の手段を用いて、DAGのナビゲーション状態を１つまたは一対の 論理 ツリー(１つはサブ構造 用であり、別は文脈用の反転型)として示す。その後、前記文脈から継承されたさらなる 情報で前記サブ構造をオーグメントする(またはその逆またはその逆)。 このような継承された 構造のオーグメンテーションの後、継承された 構造の詳細化に必要なものとして前記ネーティブ サブ構造が先ずローカス ノードについて構築され、その後、最近追加された ネーティブ サブ構造についてインクリメンタルに構築される。 このプロセスは、前記サブ構造から継承された情報で文脈を オーグメントすることに類似する。
【0005】
[0005]本開示は、プロジェクト 情報 およびそのオーグメンテーションを提示するDAGの他の関係態様を含む。
【0006】
[0006]さらに、 本開示 は、DAGのナビゲートの際にサブDAG およびその文脈をツリーとして可視化および 集中することができるようにサブDAG およびその文脈 を制限する方法を提供し、これにより、任意の時点において任意のエンティティのみが 前記可視化において単一の ノードとして示される。いくつかの 実施形態において、３つの 操作（すなわち、ツリー 初期化、 ノード 拡張、およびノード コラプス）について説明する。 ツリー 初期化、 ツリー 構築に対する予備 プロセスは、戦略 0656．1に関連する ; 戦略 0656． 2 は、前記初期化 プロセスにノード 構築を採用する。 後者の２つの操作は、前記階層の探査をサポートし、いずれかのサブ構造 ノードまたは文脈 ノードに潜在的に適用され得る。 前記ローカス ノード または任意の可視 サブ構造 ノードから、例えばより深い サブ構造を可視化または隠蔽それぞれのために拡張またはコラプスし得、前記ローカス ノード または任意の可視 文脈 ノードから、より高遠な 文脈を可視化または隠蔽それぞれのために拡張またはコラプスし得る。 本開示 は、ファセット 値を選択および選択解除することおよび前記多様な ローカス ノードの前記共通の 祖先および 子孫を明示することにより、 前記1組のローカス ノードを調整する方法も提供する。
【0007】
[0007]本開示は、 簡単に説明すると、 第1にDAGのナビゲーション状態を(サブ構造 および 文脈について) 一対の 論理 ツリーとして示した後、これらをサブストレート ツリーにおいて示す。 次に、より複雑な 解説において、第1にDAG森の ナビゲーション状態を複数対の 論理 ツリーの シーケンスを( (サブ構造 および 文脈について）示し、 サブ構造はサブ構造と 潜在的に 重複し、文脈は、文脈と潜在的に 重複し)た後、これらをサブストレート ツリーにおいて示す。
【0008】
[0008]いくつかの実施形態は、サブ構造または 文脈または双方の拡張の境界の状態を維持し、これにより、単一の ユーザ アクション が(前記ローカス ノードと共に) サブ構造 ノードへ適用されると、当該ノードの サブ構造が拡張またはコラプス され得、単一の ユーザ アクションが(ローカス ノードと共に) 文脈 ノードへ適用されると、当該ノードの文脈の拡張またはコラプスされ得る。
【0009】
[0009]１つの主要な考察として、ノードについてサブ構造 または文脈 を拡張する際には、潜在的に 矛盾するサブ構造または文脈を全てそれぞれ自動的にコラプスする必要がある。 別の 主要な 考察として、本明細書中に述べるように、共通の 子孫および祖先それぞれの可視化を促進するために、サブ構造 および 文脈を２つのバラエティの ネスト状 シーケンス のリストとして示すことができる。
【0010】
[0010]エンティティの親および子について言及する際、 その基礎をなすDAGについて言及する。 サブ構造 または文脈 について具体的に言及する親および 子について言及する場合、前記対応する 論理 ツリーを主に指す。 他の場合にノードの 親および子について言及する際、抽象 サブストレートツリーを指し、 HTML または 他の任意の 特定のサブストレート ツリーへ適用されるように適合される必要がある。
【0011】
[0011]さらに、 いくつかの実施形態において、（明示的な 分岐指令およびマージ指令によってではなく各変更による影響を受ける内容に基づいた分岐および マージにより）DAGの変更記録を配置することにより、システム 履歴が維持され、これにより、同一内容を順次に改変する必要と共に 、別個の 内容が別個の分岐において改変される。
【0012】
[0012]いくつかの実施形態において、プロジェクト (または当該階層中の関係プロジェクト) についての ユーザ の役割または関連するエンティティの生成または改変におけるユーザの以前の履歴に応じて前記グローバル DAGの異なる ビューが得られるように、システムデータの前記可視性も維持され得る。 システムデータの構成は、ユーザ間において形成され得る関係に依存する。
【0013】
[0013]多様な 実施形態において、 DAG中の１つ以上の ノードの連帯的特殊化をユーザが安全かつ効率的に行うことを可能にする方法が提示される。 これらのノードはそれぞれ、前記詳細化すべきノード を 前記ローカス ノードの継承された 子孫として提示することにより、前記新規詳細化対象ノード を ローカス ノードと関連付けつつ共通の 祖先を ローカス ノードと共に共有する。 ユーザ がDAG中の １つ以上の ノードの 連帯的一般化を安全かつ効率的に行うことを可能にする方法が提示される。各DAGは、 前記詳細化対象ノードをローカス ノードとして取り扱うことおよび前記共通の 祖先からの操作を開始することにより、 前記新規詳細化された ノード を前記共通の 祖先と関連付けつつ共通の 祖先を ノードと共有する。
【0014】
[0014]多様な 実施形態において、１つ以上の ノードがローカスとして区別されるように有向 非周期 グラフの形態の階層 構造をユーザが探査することを可能にする方法が提示される。ローカス ノードの子孫は、ツリーとして 探査され得、ローカス ノードの祖先は、反転 ツリーとして探査され得る。 いくつかのノードが拡張されると、任意のエンティティ が単一の 可視 ノードのみとして示されるように、他のノードがコラプスされる。 複数の ローカス ノードの祖先または 子孫を通じて前記同一エンティティ に到達した場合、 当該 エンティティ は単一の ノードによって示される。
【0015】
[0015]多様な 実施形態において、多様な ユーザがプロジェクト 構造への自身のアクセスを調整することおよびプロジェクト 構造 を改変することを可能にすることにより、特定の独立的に生成された内容 に対する逐次的 変更の階層ベースの ユーザ インターフェースを介したロールバックを（他の 内容を妨害することなく）可能にし、矛盾を含む変更の 直観的 マージをサポートすることが可能になる方法が提示される。
【0016】
[0016]多様な 実施形態において、通信 ネットワークを介したユーザ 協働を促進するために 有向非周期 グラフの一部を 階層 ツリー 構造としてグラフィカルに 示すためのシステム、 方法および 非一時的な コンピュータ読出可能な媒体が提供される。 上記の システム、 方法および コンピュータ読出可能な媒体 は、以下を行うように構成され得る： 複数の ユーザ間で共有される 協働 プロジェクトを通信 ネットワークを介して入手することであって、前記協働 プロジェクトは、複数の エンティティおよび 複数の関係付けを含む有向 非周期 グラフ 構造によって示され、前記複数の エンティティは、１つ以上の ローカス エンティティを含む。前記１つ以上の ローカス エンティティはそれぞれ、ローカス ノードと関連付けられ、ローカス ノードから、前記有向 非周期 グラフ中の各ローカス エンティティの 子孫 エンティティがツリー 構造としてトラバースされ、前記ツリー中の各子 ノードは、 前記ツリー中のその親のエンティティに対して前記有向 非周期 グラフ中の 子として関連する各エンティティを示す、ことと、前記ツリーの リーフ ノードにおいてルートされたサブツリーをユーザ 入力に応答して拡張すること。
【0017】
[0017]多様な 実施形態において、通信 ネットワークを介したユーザ 協働を促進するために有向非周期 グラフの一部を階層 ツリー 構造としてグラフィカルに示すためのシステム、 方法、および 非一時的な コンピュータ読出可能な媒体が提供される。 上記のシステム、 方法およびコンピュータ読出可能な媒体 は、以下を行うように構成され得る： 複数の ユーザ間で共有される 協働 プロジェクトを通信 ネットワークを介して入手することを行うことであって、前記協働 プロジェクトは、複数の エンティティおよび 複数の関係付けを含む有向 非周期 グラフ 構造によって示され、前記複数の エンティティは、１つ以上の ローカス エンティティを含み、前記１つ以上の ローカス エンティティはそれぞれ、ローカス ノードと関連付けられ、ローカス ノードから、各ローカス エンティティの前記有向 非周期 グラフ中の祖先 エンティティが反転 ツリー 構造としてトラバースされ、 前記反転 ツリー中の各子 ノード は、前記反転 ツリー中のその親の前記エンティティに対して前記有向 非周期 グラフ中の 親として関連する 各エンティティを示す、ことと、前記反転 ツリーのリーフノードにおいてルートされた サブツリー をユーザ 入力に応答して拡張すること。
【0018】
[0018]いくつかの 実施形態において、前記システム、 方法、および 非一時的な コンピュータ読出可能な媒体 は、前記ユーザ 入力に応答した前記複数の ノード中の前記少なくとも１つの ノードの拡張に応答して前記ツリー中の少なくとも１つの 他の ノードにおいてルートされた前記サブツリーをコラプスするように構成され、これにより、前記複数の エンティティの特定の エンティティ を前記複数の ノードの単一の 可視 ノードによりグラフィカルに 示すことが可能になる・
【0019】
[0019]いくつかの 実施形態において、前記システム、 方法、および 非一時的な コンピュータ読出可能な媒体は、 前記ユーザ 入力に応答して前記複数の ノードの前記少なくとも１つの ノードの前記拡張に応答して 前記反転 ツリーの少なくとも１つの 他の ノードにおいてルートされた前記サブツリーをコラプスするように構成され、 これにより、前記複数の エンティティの特定の エンティティを 最大でも前記複数の ノードの単一の 可視 ノード によってグラフィカルに示すことが可能になる。
【0020】
[0020]いくつかの 実施形態において、 いくつかのエンティティは、１つ以上のファイルのうち任意のものと関連付けられ、 １つ以上の 進捗報告はそれぞれ、期間、前記プロジェクトへの貢献の１つ以上の 記録、サブ構造のユーザによる探査が可能なローカス ノードとして設定可能な関連エンティティ、 または他の 補助データ を網羅する。上記のシステム、 方法、および 非一時的な コンピュータ読出可能な媒体 は、（期間、 前記プロジェクトへの貢献の１つ以上の 記録、 または各可視 ノードによって示される前記特定の エンティティと関連付けられた 他の任意の 補助データをそれぞれ網羅する）１つ以上のファイル、 進捗報告の任意のものの集合を表示するように構成される。
【0021】
[0021]いくつかの 実施形態において、特定の 種類 および 関連付けそれぞれのエンティティは、それぞれ特定の 種類であり、 １つのこのような 種類の関係付け は 詳細化である。 前記ローカス エンティティのうち１つ以上の少なくとも１つの 適切な 詳細化 祖先 が前記対応する １つ以上の ローカス エンティティの子孫ではない１つ以上の 他の 子孫とさらに関連付けられ、前記１つ以上の 他の 子孫は、前記各１つ以上の ローカス エンティティを示す前記対応する １つ以上の ローカス ノードの継承された 子孫として別個に示される。
【0022】
[0022]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、 １つのこのような 種類の関係付け は詳細化である。上記のシステム、 方法、および 非一時的な コンピュータ読出可能な媒体 は、第1の 操作によって 前記有向 非周期 グラフの オーグメンテーション を発生させるように構成され、前記第1の 操作 は、新規ノード を前記複数の ノードへ付加し、前記第1の 操作 は、前記複数の ノードの特定の ノードから開始され、前記新規ノード は、前記特定の ノードの子として出現し、前記新規ノードと関連付けられた新規エンティティ ならびに前記新規エンティティと前記特定の エンティティとの間の関係付けが生成され、前記新規ノード および 関連付けの種類 は、前記第1の 操作に基づく。
【0023】
[0023]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、 １つのこのような 種類の関係付け は詳細化である。上記のシステム、 方法および 非一時的な コンピュータ読出可能な媒体 は、継承された ノードを含む経路によってローカス ノードへ接続された前記複数の ノードから の開始継承された ノードから再声明 操作 または前記経路の前記最終 再声明ノードへ行われるべき第２の 操作 を前記第２の 操作に対する 前兆としてユーザが開始すると、前記ローカス ノードからの前記経路上の各継承された ノードについて前記ローカス ノードを除いて、以下を行うように構成される: 再声明エンティティを生成することと、前記再声明エンティティと前記ローカス ノードによって示される前記エンティティとの間の第1の関係付けを生成することであって、前記ローカス ノード が前記継承された ノードの親であるかまたは前記再声明エンティティ と前記継承された ノードの親の前記経路に沿った再声明の結果との間にある場合、前記第1の関係付けは、前記継承された エンティティ と前記適切な 詳細化 祖先との間の関係付けと同じ種類であり、前記ローカス ノード が前記継承された ノードの親ではない場合、前記第1の関係付けは、 前記継承された ノードによって示される前記エンティティとその親 ノードによって示される前記エンティティとの間の前記関連付けと同じ種類である、ことと、前記再声明エンティティと前記再声明された継承された エンティティとの間に 第２の関係付け を生成することであって、前記再声明エンティティは、前記再声明された継承された エンティティを詳細化する、こと。
【0024】
[0024]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、 １つのこのような 種類の関係付けは詳細化であり、上記のシステム、 方法および 非一時的な コンピュータ読出可能な媒体は、継承されたノードおよび非継承されたノードを含む経路によって ローカス ノードへ接続された前記複数の ノードからの開始継承された ノードから再声明 操作 または 前記経路の前記最終 再声明ノードへ行われるべき第２の 操作 を前記第２の 操作に対する 前兆としてユーザが開始すると、前記ローカス ノードからの前記経路上の各ノードについて前記ローカス ノードを除いて、以下を行うように構成される: 前記経路 ノードが継承された場合に再声明エンティティを生成することと、 前記経路 ノードの親が継承されたかまたは前記ローカス ノードである場合、前記経路 ノード が継承されたかまたは前記経路 ノード およびいずれかの前記ローカス ノードによって示される前記エンティティである場合 、前記再声明エンティティ間第1の関係付けを生成することであって、前記ローカス ノード は前記経路 ノードの親 または前記経路に沿った前記経路 ノードの親の再声明の結果である場合、前記第1の関係付け は、前記経路 エンティティと前記適切な 詳細化 祖先との間の前記関連付けと同じ種類であり、前記ローカス ノードが前記経路 ノードの親ではない場合、前記第1の関係付け は、前記経路 ノードによって示される前記エンティティと、その親 ノードによって示される前記エンティティとの間の前記関連付けと同じ種類である、ことと、前記経路 ノードが継承された場合、前記再声明エンティティ と前記再声明された継承された 経路 エンティティとの間に第２の関係付けを生成することであって、前記再声明エンティティは、前記再声明された継承された 経路 エンティティを詳細化する、こと。
【0025】
[0025]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、１つのこのような 種類の関係付けは詳細化である。上記の前記システム、 方法および 非一時的な コンピュータ読出可能な媒体は、前記複数の ノードからの 複数の 継承された 開始ノードからユーザが再声明 操作 または各経路の前記最終 再声明ノードへ行われるべき 第２の 操作 をユーザが開始すると、各継承された 開始ノードは、対応する 継承された ノードを含む経路によってローカス ノード へ接続され、 前記第２の 操作に対する 前兆として前記複数の 経路からの任意の経路上の各ノード について前記ローカス ノードを除いて、以下を行うように構成される: 再声明エンティティを生成することと、前記再声明エンティティと前記ローカス ノードによって示される前記エンティティとの間の第1の関係付けを生成することであって、前記ローカス ノードが前記継承された ノードの親であるかまたは前記再声明エンティティと、前記対応する 経路に沿った前記継承された ノードの親の 再声明の結果との間にある場合、前記第1の関係付けは、前記継承された エンティティ と前記適切な 詳細化 祖先との間の関係付けと同じ種類であり、前記ローカス ノード が前記継承された ノードの親ではない場合、前記第1の関係付け は、前記継承された ノードによって示される前記エンティティ と、その親 ノードによって示される前記エンティティとの間の関係付けと同じ種類である、ことと、前記再声明エンティティと前記再声明された継承された エンティティとの間に 第２の関係付け を生成すること であって、前記再声明エンティティは、前記再声明された継承された エンティティを詳細化する、こと。
【0026】
[0026]いくつかの 実施形態において、前記少なくとも１つの 他の 子は、前記ローカス ノードの子孫ではない１つ以上の子孫と関連付けられ得、前記１つ以上の 子孫は、前記ローカス ノードの継承された 子孫として別個に示され、前記少なくとも１つの 他の 子 は、前記ローカス ノードの子孫ではない１つ以上の子孫と関連付けられ、前記子孫は、詳細化再声明を含み得、前記再声明ノード およびその子孫は、前記前記ローカス ノードの継承された 子孫から除外され得る。
【0027】
[0027]いくつかの 実施形態において、前記少なくとも１つの 他の 子 は、前記ローカス ノードの子孫ではない１つ以上の子孫と関連付けられ、前記１つ以上の 子孫は、前記ローカス ノードの継承された 子孫として別個に示され得、前記少なくとも１つの 他の 子 は、前記ローカス ノードの子孫によって再声明され得、前記他の 子 は、前記前記ローカス ノードの継承された 子孫から除外され得る。
【0028】
[0028]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、１つのこのような 種類の関係付けは詳細化である。上記のシステム、 方法、および 非一時的な コンピュータ読出可能な媒体は、 以下を行わせるように構成される：第1の 操作によって 前記有向 非周期 グラフの オーグメンテーションを行うことであって、前記第1の 操作により、新規ノードが前記複数の ノードへ付加され、前記第1の 操作は、前記複数の ノードの特定の ノードから開始され、前記新規ノードは、前記特定の ノードの前記反転 ツリー内の子として出現する、ことと、前記新規ノードと関連付けられた新規エンティティならびに前記新規エンティティと前記特定の エンティティとの間の関係付けを生成することであって、前記新規ノードの種類 は、 前記特定の ノードの種類と同じであり、前記関連付け の種類は詳細化であり、前記特定の ノードは前記新規ノードを詳細化する。
【0029】
[0029]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、１つのこのような 種類の関係付けは詳細化である。上記のシステム、 方法および 非一時的な コンピュータ読出可能な媒体は、以下を行うように構成される：前記開始文脈ノードと前記対応する ローカス ノードとの間の前記経路上の複数の 文脈 ノードそれぞれについて前記開始文脈ノードを除いて、前記複数の ノードからの 開始文脈ノードからユーザが操作を開始すると、: 一般化エンティティを開始することであって、前記新規エンティティの種類は、前記文脈 ノードの種類と同じである、ことと、 前記一般化エンティティ と、前記開始文脈ノードによって示されるエンティティとの間に 第1の関係付け を生成することであって、前記文脈 ノード が前記開始文脈ノードの前記反転 ツリー内の前記親である場合、前記第1の関係付けは、 前記文脈 エンティティと、前記開始文脈ノードによって示されるエンティティとの間の関係付けと同じ種類であり、前記文脈 ノードが前記開始文脈ノードの前記反転 ツリー内の前記親ではない場合、前記第1の関係付け は、 前記文脈 ノードによって示される前記エンティティ と、前記反転 ツリー内のその子ノードによって示される前記エンティティとの間の関係付けと同じ種類である、ことと、前記一般化エンティティ と、前記文脈 ノードによって示される前記エンティティとの間に 第２の関係付けを生成することであって、前記一般化エンティティ は、前記文脈 ノードによって示される前記エンティティによって詳細化される。
【0030】
[0030]いくつかの 実施形態において、前記反転 ツリー 構造は、複数の ツリー 構造を含む 森構造内に形成され、各ツリー 構造は、相互に入れ子状に配置されることによりサブストレート ツリー状に提示された２つのリストを含む。 第1の ツリーリストにより、第２の ノードリストが構築され、任意の第２のリスト中の最終ノードを除く全ノードは、前記サブストレート ツリー中に子を持たず、ローカス ノードは、前記サブストレート ツリー中に兄弟または子を持たず、任意の第２のリスト中の各ノードによって示されるエンティティは、前記第２のリスト中の前記サブストレート ツリーaAZs 第1の最終ノードリスト 中の各子の前記サブストレート ツリーaAZs 第２のリスト 中の前記第1の 子の前記有向 非周期 グラフ中の親である。
【0031】
[0031]いくつかの 実施形態において、前記ツリー 構造は、 複数の ツリー 構造を含む 森構造内に形成され、各ツリー 構造は、相互に入れ子状に配置されることによりサブストレート ツリー状に提示された２つのリストを含む。第1の ツリーリスト 構造は、指定 ノード 第２の ノードリストを含み、任意の第２のリスト中のノード によって示される各エンティティは、子を持たず、前記サブストレート ツリー中のその親 ツリー 構造の前記指定 ノードによって示される前記エンティティの前記有向 非周期 グラフ中の子であり、 最外側の ツリー 構造は、ローカス ノードのみのリストを有し、任意の第1のリスト中の 各ツリー 構造の前記指定 ノードによって示されるエンティティは、前記サブストレート ツリー中のその親の親の前記指定 ノードによって示される前記エンティティの前記有向 非周期 グラフ中の子である。
【0032】
[0032]いくつかの 実施形態において、 エンティティはそれぞれ特定の 種類であり、関連付けはそれぞれ特定の 種類であり、１つのこのような 種類の関係付けは詳細化である。上記のシステム、 方法および 非一時的な コンピュータ読出可能な媒体は、 前記複数の ノードからの 開始文脈ノードからユーザが操作を開始すると、前記開始文脈ノード とローカス ノードとの間の（前記開始文脈ノードを含むもの以外の各第1のリストの前記第1の 要素を含む）前記サブストレート ツリー（前記開始文脈ノードを除く）を通じた任意の経路上の 複数の 文脈 ノードそれぞれについて、以下を行うように構成される: 一般化エンティティを開始することと、 前記一般化エンティティ と、前記開始文脈ノードによって示されるエンティティとの間に 第1の関係付け を生成することであって、 前記文脈 ノード が前記開始文脈ノードの前記反転 ツリー内の前記親である場合、前記第1の関係付けは、 前記文脈 エンティティと、前記開始文脈ノードによって示されるエンティティとの間の関係付けと同じ種類であり、前記文脈 ノードが前記開始文脈ノードの前記反転 ツリー内の前記親ではない場合、前記第1の関係付け は、前記文脈 ノードによって示される前記エンティティ と、前記反転 ツリー内のその子ノードによって示される前記エンティティとの間の関係付けと同じ種類であり 、前記一般化エンティティ と、前記文脈 ノードによって示される前記エンティティとの間に 第２の関係付けを生成すること であって、前記一般化エンティティは、前記文脈 ノードによって示される前記エンティティによって詳細化される、こと。
【0033】
[0033]いくつかの 実施形態において、前記生成された 詳細化一般化は、再声明を含む。
【0034】
[0034]多様な 実施形態において、通信 ネットワークを介したユーザ 協働を促進するように 有向非周期 グラフの一部 を 階層 ツリー 構造としてグラフィカルに示すためのシステム、 方法、および 非一時的な コンピュータ読出可能な媒体 が提供される 。 上記の システム、 方法および 非一時的な コンピュータ読出可能な媒体 は、以下を行うように構成され得る： 複数の ユーザ間で共有される 協働 プロジェクトを通信 ネットワークを介して入手することであって、前記協働 プロジェクトは、それぞれ特定の 種類の複数の エンティティ および複数の関係付けを含む有向 非周期 グラフ 構造によって示され、１つのこのような 種類 は詳細化であり、前記複数の エンティティは、少なくとも１つの ローカス エンティティを含み、前記少なくとも１つの ローカス エンティティはそれぞれ 、ローカス ノードと関連付けられ、このローカス ノードから、各ローカス エンティティの前記有向 非周期 グラフ中の子孫 エンティティがツリー 構造としてトラバースされ、 前記ツリー中の各子 ノードは、前記ツリー中のその親のエンティティに対して前記有向 非周期 グラフ中の 子として関連する各エンティティ を示し、前記ローカス エンティティのうち１つ以上の少なくとも１つの 適切な 詳細化 祖先は、 前記対応する １つ以上の ローカス エンティティの子孫ではない１つ以上の 他の 子孫とさらに関連付けられ、前記少なくとも１つの 他の 子孫はそれぞれ、前記少なくとも１つの ローカス エンティティを示す前記対応する 少なくとも１つの ローカス ノードの 継承された 子孫として別個に示される、ことと、ユーザ 入力に応答して、前記ツリーの リーフ ノードにおいてルートされたサブツリーを拡張すること。
【0035】
[0035]データフロー 図中の矢印は、末尾における前記処理 ユニットから先頭における前記処理 ユニット への情報フローを示す。 データフロー 図において両方向矢先 が用いられる場合、流入によってコンポーネントの状態の変更が発生し得ることを示し、単一の 矢先は、そうではないことを示す。
【0036】
[0036]プロセス フロー図において、楕円内の多様な 指令（例えば、スタート指令、 STOP指令、 CONTINUE指令および FAIL 指令）が用いられる。 声明 ブロックを矩形として示し、ディシジョンポイントを菱形として示す。 データ構造 についての繰り返しを、「for」 ブロックによって示す。「for」 ブロックは、各繰り返しについて実行されるべき命令を含む大型矩形 として出現する。
【0037】
[0037]プロセス フロー図中の矢印は、末尾における前記処理 ユニットから先頭における前記処理 ユニット への制御フローを示す。 矢先において ラインが処理 ユニット と出合った場合、 制御フローは当該処理 ユニットへ進み、そうではない場合、制御フローは前記処理 ユニットから離れて移動する。 複数の ラインが処理 ユニットを退出すると、 全経路が任意の順序でまたは同時にとられ、ソフトウェア開発分野の当業者にとって周知のように 適切な 注意 が任意の共有リソースへ付与される。 例外として菱形ノードからの フォークがあり得、このフォークにおいては、 指定条件にて連続する全経路が任意の順序でまたは同時に同じ警告と共にとられるべきである。 上記の慣習は、これらの処理 ステップ全てまたは実施形態の実現が可能な このようなステップ の可能な順序全ての網羅的解説を提供する目的のためではなく、多様な 処理 ステップ間の関係についての直観を提示する目的のみのために記載される。
【0038】
[0038]プロセス フロー図において、コンポーネントデータ（各 サブルーチン呼出しを含む）についてのサブルーチン呼出しを示すために、 ステップのクラスターへの矢印が用いられ得る。 再帰呼び出し後にさらに仕事をする必要が有る場合、このように残っている仕事の実行は、CONTINUE 指令によって明示的にまたはSTOP 指令によって暗示的に示され得る。 この 再帰 は、解説的な 機構である。 その 根幹をなす計算は、再帰、 繰り返し、 マクロ 拡張などを用いて実行され得る。
【0039】
[0039]処理 ユニット の内側から外側への円弧は、他の任意の 矢印として解釈され得るが、このような矢印は、再帰呼び出しを介した実行の候補である。 直観の支援のため、テキスト記述中のこのような矢印を記述するための再帰言語を非公式に用いるが、実施形態においては、このようなものを実行することを選択してもよいし、しなくてもよい。記載において スタックについて言及する場合、ほとんどのプログラミング 言語によって想定されるシステム スタックであれば充分であることが多い。
【0040】
[0040]分岐における論理和 記号(V) は、正しい１つの経路 をとるべきであることを示す。 分岐における接続 記号(Λ)は、全経路が独立的にとられるべきである旨を示し、より低い実行レベルにおける共有リソースによって課される分岐以外の分岐の各フローに制限は無い。 このような計算は全て、 ジョインポイントにおいて出合った後に進行していくことが意図される。
【0041】
[0041]ブロック 構造 図中の矢印は、先頭のモジュールが末尾の前記モジュールを用いて実行されることを示す。
【0042】
[0042]図面要素が1箇所よりも多くにおいて出現しかつ同一符号が付与されている場合、記載の実施形態中の同一物を指すものと考えられるが、他の 実施形態においては当該要素は区別され得る。
【図面の簡単な説明】
【0043】
【図23】[0065] 図23は、段落０３１６に記載のような、実施形態のいくつかの 使用例の相互作用 シーケンス 図である。 [0066] 例示的な DAGおよび ツリーにおいて、具体性のため、円形は 問題を示し、四角形は解決法を示し、これらを順次に集合的にナンバリングするものとする。 関連付けの種類については、この 実施形態 においてソース の種類および前記関連付けのターゲットから明らかであるため、記載しない。 選択されたノードは境界と共に図示され、操作の開始元となる ノードは 、境界および ４つの均等配置されたノッチと共に図示される。
【図26】[0069] 図26 は、いくつかの実施形態による、ナビゲーション および継承されたいくつかの構造 (ノード9、 11、 12および15を含む)を用いた、図25からの１つのノード (1)上にセンタリングされた例示的DAG のサブDAG を示す図である。from 図25 with、 いくつかの実施形態による、。 ノード 10 から ノード 1 へのリンクは、スプライスアウトされている。
【図28】[0071] 図28 は、いくつかの実施形態による、ツリーとして提示されている前記サブ構造 (4) および 10)からの解決法 ノード を新規解決法 ノード (13)によって明示的に 詳細化するプロセスにおける、１つのノード (1)上にセンタリングされたナビゲーションを用いた図２７からの探査を示す図である。
【図30】[0073] 図30 は、いくつかの実施形態による、 ツリーとして提示されたサブ構造 (4)からの解決法 ノードおよび 継承された 解決法 ノード (10)を問題 ノード 5を解決する新規 解決法 ノード (16)により明示的に詳細化するプロセスにおける、１つのノード (1)上にセンタリングされたナビゲーションを用いた図２７からの探査を示す図である。
【図31】[0074] 図31 は、 いくつかの実施形態による、図28に示すように問題 ノード 5を解決する 新規 解決法 ノード 16を用いた解決法 ノード4 および10 の明示的な 詳細化の後の前記例示的DAGを示す図である。
【図33】[0076] 図33 は、 いくつかの実施形態による、図32からの１つのノード (5)上にセンタリングされたナビゲーションと、継承されたいくつかの構造 (ノード4、 7、 8、 9、 10、 11、 12および 15を含む)とを用いた、前記例示的DAGの前記サブDAGを示す図である。
【図35】[0078] 図35 は、いくつかの実施形態による、ツリーとして提示された当該問題 ノードを解決し、２つの継承された 解決法 ノード(4および8) を新規 解決法 ノード (14)により詳細化するプロセスにおいて１つのノード (5)上にセンタリングされたナビゲーションを用いた、図34からの前記探査 を示す図である
【図36】[0079] 図36は、いくつかの実施形態による、問題 ノード 5 を解決することおよび解決法 ノード4および8 を図35に示すように新規 解決法 ノード 14により詳細化することの後の前記例示的DAGを示す図である。
【図38】[0081] 図38 は、いくつかの実施形態による、ツリーとして提示された、２つの継承された 解決法 ノード(12 および15) を 新規 解決法 ノード (17)を用いて詳細化するプロセスの繰り返しにおいて、１つのノード (1)上にセンタリングされたナビゲーションを用いた図37からの探査を示す図である。
【図40】[0083] 図40 は、 いくつかの実施形態による、ツリーとして提示された ２つの継承された 解決法 ノード(12および15) を 新規 解決法 ノード (17)によって定位置詳細化するプロセス繰り返し時における、 １つのノード (1)上にセンタリングされたナビゲーションを用いた図37からの探査を示す図である。
【図41】[0084] 図41 は、いくつかの実施形態による、 ２つの継承された 解決法 ノード(12および15) を新規 解決法 ノード (17)によって詳細化する前記定位置プロセス繰り返し後の、１つのノード (1)上にセンタリングされたナビゲーションを用いた図３７からの探査を示す図である。
【図45】[0088] 図45 は、いくつかの実施形態による、段落０３５０に記載のような継承無しのDAGの単一の 特殊化オーグメンテーションを行うためのクライアント アクション のプロセス フロー図である。
【図50】[0093] 図50は、いくつかの実施形態による、継承無しおよび間接的 オブジェクト有りでサブ構造 および 文脈 ツリーへ変換されたDAG の特殊化オーグメンテーションが制限を満たす証拠を生成するクライアント アクションのプロセス フロー図である。
【図51】[0094] 図51は、いくつかの実施形態による、間接的 オブジェクトを用いたDAG の特殊化オーグメンテーションが制限を満たす証拠を有効化するためのサーバ アクションのプロセス フロー図である。
【図52】[0095] 図52は、いくつかの実施形態による、 継承無しかつ直接的オブジェクトのみ有りでサブ構造 および文脈 ツリーへ変換されたDAGの特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションのプロセス フロー図である。
【図53】[0096] 図53 は、いくつかの実施形態による、 直接的オブジェクトのみ有りの DAGの特殊化オーグメンテーションが制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図 である。
【図55】[0098] 図55 は、 いくつかの実施形態による、問題 ノード 52 および 詳細化する解決法 ノード 54 を新規 解決法 ノード 55によって解決した後の 図54からの前記例示的DAG を示す図である。
【図56】[0099] 図56 は、いくつかの実施形態による、段落０３６２に記載のような継承無しのDAG の 単一の クロス種類 および特殊化オーグメンテーションを行うためのクライアント アクションの プロセス フロー図 である。
【図57】[0100] 図57は、いくつかの実施形態による、継承無しかつ直接的オブジェクトのみ有りでサブ構造 および 文脈 ツリーへ変換されたDAGの クロス種類 および 特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションのプロセス フロー図である。
【図58】[0101] 図58 は、 いくつかの実施形態による、継承無しかつ 間接的 オブジェクト有りでサブ構造 および 文脈 ツリーへ変換されたDAGのクロス種類 および 特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図59】[0102] 図59 は、いくつかの実施形態による、サブ構造 および 文脈 ツリーへ変換されたDAGの オーグメンテーション が制限を満たすという証拠の一部を生成するためのクライアント アクションの プロセス フロー図である。
【図60】[0103] 図60 は、 いくつかの実施形態による、間接的 オブジェクトを用いたDAGの クロス種類および特殊化オーグメンテーションが制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図である。
【図61】[0104] 図61は、 いくつかの実施形態による、直接的オブジェクトのみを用いた DAGの クロス種類および特殊化オーグメンテーションが 制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図である。
【図66】[0109] 図66 は、いくつかの実施形態による、継承された 構造 を段落０３７５に記載のような前記DAGへ接続させる前記継承プロセスの 実施形態の前記コンポーネント の プロセス フロー図 である。
【図67】[0110] 図67 は、いくつかの実施形態による、段落０３７８に記載のように先行順 トラバーサルを介して継承されるべき構造を収集する前記継承プロセスの前記コンポーネントの最も浅い第1の 実施形態の前記コンポーネントの プロセス フロー図 である。
【図68】[0111] 図68 は、いくつかの実施形態による、段落０３７９に記載のように先行順 トラバーサルを介して 継承されるべき構造 を収集する前記継承プロセスの前記コンポーネントの 最も深い第1の 実施形態の前記コンポーネントの プロセス フロー図である。
【図69】[0112] 図69 は、いくつかの実施形態による、段落０３７９に記載のように後行順 トラバーサル を介して継承されるべき構造 を収集する前記継承プロセス のコンポーネントの別の 最も深い第1の 実施形態のコンポーネントの プロセス フロー図である。
【図70】[0113] 図70は、いくつかの実施形態による、段落０３７９に記載のように 継承された 構造をDAGへ接続させる前記継承プロセスの 最も深い第1の 実施形態のコンポーネントの プロセス フロー図である。
【図71】[0114] 図71 は、いくつかの実施形態による、段落０３９４に記載のように継承されるべき構造を収集する継承プロセスおよびその継承経路の前記コンポーネントの最も深い第1の 実施形態のコンポーネントの プロセス フロー図である。
【図72】[0115] 図72 は、いくつかの実施形態による、段落０３９８に記載のように継承されるべき構造を収集する前記継承プロセスおよびその継承フロー (DAG)の前記コンポーネントの最も深い第1の 実施形態の コンポーネントの プロセス フロー図 である。
【図74】[0117] 図74 は、 いくつかの実施形態による、継承および間接的 オブジェクトを用いてサブ構造および文脈 ツリーへ変換されたＤＡＧの特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図75】[0118] 図75は、いくつかの実施形態による、継承および直接的オブジェクトのみを用いてサブ構造および文脈 ツリーへ変換された DAGの 特殊化オーグメンテーションが制限を満たすというクライアント アクションの プロセス フロー図である。
【図76】[0119] 図76 は、いくつかの実施形態による、継承を用いて サブ構造および文脈 ツリーへ変換された ＤＡＧの 特殊化オーグメンテーションが制限を満たすという証拠の独立ノード 経路を生成するためのクライアント アクションの プロセス フロー図 である。
【図77】[0120] 図77 は、いくつかの実施形態による、段落０４０８に記載のようにDAGの単一の クロス種類および特殊化オーグメンテーションを行うための クライアント アクションの プロセス フロー図である。
【図78】[0121] 図78 は、いくつかの実施形態による、継承および 間接的 オブジェクトを用いてサブ構造および文脈 ツリーへ変換されたDAGの クロス種類および特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図79】[0122] 図79 は、いくつかの実施形態による、継承および直接的オブジェクトのみを用いてサブ構造および文脈 ツリーへ変換されたDAGの クロス種類および特殊化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図81】[0124] 図81 は、いくつかの実施形態による、段落０４２１に記載のように詳細化された 祖先をコピーするプロセスの一部として単一の 継承された ノードの詳細化を取り扱うDAGの 特殊化オーグメンテーションを行う別の バージョン の クライアント アクション のプロセス フロー図である。
【図82】[0125] 図82 は、いくつかの実施形態による、段落０４２２に記載のようにDAGのクロス種類および特殊化オーグメンテーションを行うための クライアント アクションの プロセス フロー図 である。
【図83】[0126] 図83 は、いくつかの実施形態による、段落０４２４に記載のように前記ローカス ノードへ特殊化されたノードの前記継承された 祖先をコピーするためのクライアント アクションの プロセス フロー図である。
【図86】[0129] 図86 は、いくつかの実施形態による、段落０４３５に記載のような継承されるべき構造 およびその継承経路を再声明を介して収集する前記継承プロセスの前記コンポーネントの最も浅い第1の 実施形態の コンポーネントの プロセス フロー図である。
【図87】[0130] 図87 は、いくつかの実施形態による、段落０４３８に記載のような（無関係の 再声明をスキップしつつ）継承された 構造を前記DAGへ接続させる継承プロセス の実施形態の コンポーネントの プロセス フロー図 である。
【図88】[0131] 図88 は、いくつかの実施形態による、段落０４３８に記載のような（無関係の 再声明をスキップしつつ）継承された 再声明を前記DAGへ接続させる継承プロセス の実施形態の コンポーネントの プロセス フロー図 である。
【図89】[0132] 図89 は、いくつかの実施形態による、単一の 継承された ノードであっても再声明した後に詳細化させる特殊化オーグメンテーションを行うための クライアント アクションの プロセス フロー図 である。
【図90】[0133] 図90 は、いくつかの実施形態による、段落０４３９に記載のような前記ローカス ノードへ特殊化されたノード 定位置の前記継承された 祖先を 再声明するためのクライアント アクションの プロセス フロー図である。
【図91】[0134] 図91は、いくつかの実施形態による、段落０４３９に記載のようなDAGの単一の 特殊化再声明オーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図92】[0135] 図92 は、いくつかの実施形態による、段落０４４０に記載のようなDAG の単一の クロス種類および特殊化再声明オーグメンテーション を行うためのクライアント アクションの プロセス フロー図である。
【図95】[0138] 図95 は、いくつかの実施形態による、いくつかの 構造 (ノード24および25を含む)を継承した図94からの２つの ノード(22および23)上にセンタリングされた前記例示的DAG の前記サブDAGを示す図である。
【図97】[0140] 図97は、いくつかの実施形態による、ツリーとして提示された２つの ノード(22および23)を解決し、詳細化 ２つの 継承された 解決法 ノード(24および25) を新規 解決法 ノード (26)によって詳細化するプロセスにおいてこれら２つの ノード(22および23)上にセンタリングされたナビゲーションを用いた図96 からの前記探査を示す図である。
【図98】[0141] 図98 は、 いくつかの実施形態による、図97に記載のように新規 解決法 ノード 26を用いて問題 ノード22および23を解決し、解決法 ノード24および25を詳細化した後の図93 からの前記例示的DAG を示す図である。
【図101】図101 は、いくつかの実施形態による、新規従属ノード (38)を用いて ２つの従属ノード(36および37)をツリーとして提示された状態で一般化するプロセスにおけるノード 31上にセンタリングされた ナビゲーションを用いた図100からの探査を示す図である。
【図102】[0144] 図102は、いくつかの実施形態による、図101に記載のように新規従属ノード 38を用いて独立ノード 31をオーグメントし、従属ノード36および37 を一般化すること後の図99 からの例示的DAGを示す図である。
【図105】図105 は、いくつかの実施形態による、２つの従属ノード(48および49) をツリーとして提示された状態で新規従属ノード (50)を用いて一般化しつつノード 41 を オーグメントするプロセスにおける、ノード46および47上にセンタリングされた ナビゲーションを用いた 図104からの探査を示す図である。
【図106】[0147] 図106は、いくつかの実施形態による、独立ノード 41をオーグメントし、従属ノード 48および49を図105に記載のように新規従属ノード 50を用いて一般化させた後の図103からの例示的DAG を示す図である。
【図108】[0149] 図108は、いくつかの実施形態による、問題 ノード70を 新規 解決法 ノード 78を用いて解決した後の図107からの前記例示的DAGの図である。新規 解決法 ノード 78は、前記既存の解決法 ノードを一般化し、前記既存の解決法 コンポーネントの一般化によってコンポーネント化される。
【図110】[0151] 図110 は、いくつかの実施形態による、段落０４７７に記載のようにDAGの 単一の 一般化オーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図122】[0163] 図122 は、いくつかの実施形態による、継承無しかつ 間接的 オブジェクト有りでサブ構造および文脈 ツリーへ変換されたDAGの 一般化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図 である。
【図123】[0164] 図123 は、 いくつかの実施形態による、間接的 オブジェクトを用いたDAG の一般化オーグメンテーション が 制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図 である。
【図124】[0165] 図124は、いくつかの実施形態による、直接的オブジェクトのみを用いたDAGの一般化オーグメンテーションが制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図 である。
【図125】[0166] 図125は、 いくつかの実施形態による、段落０４９１に記載のようなDAGの単一の クロス種類および一般化オーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図126】[0167] 図126 は、いくつかの実施形態による、継承無しかつ 間接的 オブジェクト有りでサブ構造および文脈 ツリーへ変換されたＤＡＧのクロス種類および一般化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図127】[0168] 図127は、いくつかの実施形態による、継承無しかつ直接的オブジェクトのみ有りでサブ構造および文脈 ツリーへ変換されたDAG のクロス種類および一般化オーグメンテーションが制限を満たすという証拠を生成するためのクライアント アクションの プロセス フロー図である。
【図128】[0169] 図128は、いくつかの実施形態による、間接的 オブジェクトを用いたDAGの クロス種類および一般化オーグメンテーションが制限を満たすという証拠を有効化するための サーバ アクションの プロセス フロー図である。
【図129】[0170] 図129 は、直接的オブジェクトのみを用いたDAG のクロス種類および一般化オーグメンテーションが制限を満たすという証拠を有効化するためのサーバ アクションの プロセス フロー図である。
【図131】[0172] 図131 は、いくつかの実施形態による、段落０５０１に記載のようなDAGの クロス種類および一般化オーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図134】[0175] 図134 は、いくつかの実施形態による、段落０５１５に記載のように前記サブ構造中のノード間の 詳細化関係付けを用いてDAGの オーグメンテーションを行うためのクライアント アクションの プロセス フロー図 である。
【図135】[0176] 図135 は、いくつかの実施形態による、段落０５１８に記載のようにローカス ノード間の 詳細化関係付けを用いてDAGのオーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図136】[0177] 図136は、いくつかの実施形態による、既存の エンティティ間の詳細化関係付けの追加によるＤＡＧの 単一の オーグメンテーションを行うためのクライアント アクションの プロセス フロー図である。
【図139】[0180] 図139 は、いくつかの実施形態による、Specialize Termの適用前のノード 81における ナビゲーションにおける図１３７の例についての 局所的条件 DAG である。
【図140】[0181] 図140は、いくつかの実施形態による、Specialize Terms (およびその後の操作) の適用後の ノード 81における ナビゲーションにおける図１３７の例についての 局所的条件 DAG である。
【図142】[0183] 図142 は、いくつかの実施形態による、Remove Disjunct (およびその後の操作) の適用後のノード 82におけるナビゲーションにおける図１３７の例についての局所的条件 DAG である。
【図144】[0185] 図144 は、いくつかの実施形態による、Add Conjunct (およびその後の操作)の適用後のノード 8３におけるナビゲーションにおける図１３７の例についての局所的条件 DAGである。
【図147】[0188] 図147 は、いくつかの実施形態による、Merge Disjunct (およびその後の操作) の適用後のノード 8４におけるナビゲーションにおける図１３７の例についての局所的条件 DAGである。
【図157】[0198] 図157は、いくつかの実施形態による、Conjoin Disjunct (およびその後の操作)の適用後のノード ９１におけるナビゲーションにおける図１５４の例についての局所的条件 DAGである。
【図158】[0199] 図158 は、いくつかの実施形態による、Embed Conjunctionの適用前のノード ９２におけるナビゲーションにおける図１５４の例についての局所的条件 DAGである。
【図159】[0200] 図159 は、いくつかの実施形態による、Embed Conjunction (およびその後の操作) の適用後のノード ９２におけるナビゲーションにおける図１５４の例についての局所的条件 DAGである。
【図174】[0215] 図174 は、いくつかの実施形態による、解決法との相互作用をその状態に基づいて行うためのサンプル ユーザ インターフェースを示す。 [0216] 図1 〜 図174 の図面 要素は、以下のような4桁 コード が割り当てられ得る: ・ 第1の 桁は、詳細化 オーグメンテーションの方向と、実施形態が継承を取り扱うかとを示す。 1:非継承された ノードおよび明示的な オーグメンテーションについての主要サポート 特殊化 2: 継承された ノードおよび暗示的 オーグメンテーション についての主要サポート 特殊化 3: 継承と無関係の 主要サポート 特殊化 4: 非継承された ノードおよび明示的な オーグメンテーションについての主要サポート一般化 5:継承された ノードおよび暗示的 オーグメンテーション についての主要サポート一般化 6: 継承と無関係の主要サポート一般化 0: 詳細化 オーグメンテーションの継承または方向と無関係の適用 ・ 第２の 桁は、要素 が本実施形態における前記クライアント または前記サーバに主に関連するかを示す。 1: 主に クライアント 向け 2: 主にサーバ向け 0: いずれか ・ 第3の 桁 は、 逐次的である。 ・ 最終 桁 は、関連操作を指す。 0: 初期化 1: 詳細化 オーグメンテーション 2: 詳細化/クロス種類 オーグメンテーション 3: 任意のオーグメンテーション 4: 削除/リンク切り離し 5: 移動/コピー 6: 詳細化を介したリンク付け ナンバリングシステムは、 直観を支援することを意図し、ここで提示される特定の 実施形態 を指す。 任意のルーチンの適用可能性を制限することを意図しない。
【図180】[0222] 図180 は、いくつかの実施形態による、戦略 0656．1、 戦略 0652．1および戦略 0653．1に記載のように子 ノードは 矛盾しないという仮説の元の前記最大 サブ構造 拡張 プロセスの実施形態の プロセス フロー図 である。
【図181】[0223] 図181 は、 いくつかの実施形態による、戦略 0656．1、 戦略 0652．2および戦略 0653．2に記載のような任意の共通の 子孫に到達するまで拡張する前記サブ構造 拡張 プロセスの実施形態の プロセス フロー図 である。
【図182】[0224] 図182 は、いくつかの実施形態による、戦略 0656．1、 戦略 0652． 3および戦略 0653． 3に記載のような子 ノードが 矛盾しないという仮説の元に単一の ノンリーフ 子を開く初期化 のための前記サブ構造 拡張 プロセスの実施形態のプロセス フロー図 である。
【図183】[0225] 図183 は、いくつかの実施形態による、戦略 0656． 1、 戦略 0652．4および戦略 0653． 4に記載のような子 ノードが矛盾しないという仮説の元に単一の 子を開く初期化のための前記サブ構造 拡張 プロセスの実施形態のプロセス フロー図である。
【図184】[0226] 図184 は、いくつかの実施形態による、戦略 0656．1、 戦略 0652．5および戦略 0653． 5に記載のように子 ノードが矛盾しないという仮説の元の初期化のための前記単項 サブ構造 拡張 プロセスの実施形態のプロセス フロー図である。
【図185】[0227] 図185 は、いくつかの実施形態による、戦略 0656．1および戦略 0653． 1および戦略 0653． 2に記載のような矛盾する可視 ノードを隠蔽する前記最大 サブ構造 拡張 プロセスの部分の実施形態のプロセス フロー図である。
【図186】[0228] 図186は、いくつかの実施形態による、特定のサブ構造 拡張 プロセスの一部の戦略 0656．1、 戦略 0652． 4および戦略 0653． 4に記載のように矛盾する可視 ノードを隠蔽する (単一の 子または単一の ノンリーフ 子を開く) 実施形態のプロセス フロー図である。
【図190】[0232] 図190 は、いくつかの実施形態による、戦略 0656．2および段落０６７４に記載のような単一の エンティティ についての前記文脈 コラプス プロセス の実施形態のプロセス フロー図である。
【図191】[0233] 図191 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652． 1および戦略 0653． 1に記載のような子 ノードが矛盾しないという仮説の元の前記最大 文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図192】[0234] 図192 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．2および戦略 0653．2に記載のような任意の共通の 祖先 に到達するまで拡張する前記サブ構造 拡張 プロセスの実施形態のプロセス フロー図である。
【図193】[0235] 図193 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．3および戦略 0653．3に記載のような子 ノードが矛盾しないという仮説の元の単一の ノンリーフ 子を開く単一の ローカス エンティティについての前記文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図194】[0236] 図194 は、いくつかの実施形態による、戦略 0656． 2、 戦略 0652． 4および戦略 0653． 4に記載のような子 ノードが矛盾しないという仮説の元の単一の 子を開く前記文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図195】[0237] 図195 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．5および戦略 0653．5に記載のような親 ノードが矛盾しないという仮説の元の前記単項 文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図196】[0238] 図196は、いくつかの実施形態による、戦略 0656．2および戦略 0653．1および戦略 0653． 2に記載のような矛盾する可視 ノードを隠蔽する前記最大 文脈 拡張 プロセスの部分の実施形態のプロセス フロー図である。
【図197】[0239] 図197は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．4および戦略 0653． 4に記載のような矛盾する可視 ノードを隠蔽する(単一の 親または 単一の 非孤児 親を開く) 特定の文脈 拡張 プロセスの一部の実施形態のプロセス フロー図である。
【図205】[0245] 図205は、いくつかの実施形態による、戦略 0656．2および段落０６８８に記載のような複数の エンティティについての前記文脈 コラプス プロセスの実施形態のプロセス フロー図である。
【図206】[0246] 図206 は、いくつかの実施形態による、戦略 0656． 2、 戦略 0652． 3および戦略 0653． 3に記載のような子 ノードが矛盾しないという仮説の元の 単一の ノンリーフ 子を開く複数の ローカス エンティティについての前記文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図207】[0247] 図207 は、いくつかの実施形態による、戦略 0656． 2、 戦略 0652． 4および戦略 0653． 4に記載のような子 ノードが矛盾しないという仮説の元に単一の 子を開く複数の ローカス エンティティについての前記文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図208】[0248] 図208 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．5および戦略 0653． 5に記載のように親 ノードが 矛盾しないという仮説の元の前記単項 文脈 拡張 プロセスの実施形態のプロセス フロー図である。
【図209】[0249] 図209 は、いくつかの実施形態による、戦略 0656．2、 戦略 0652．4および戦略 0653．4に記載のように矛盾する可視 ノードを隠蔽する(単一の 親または 単一の 非孤児 親を隠蔽する) 特定の文脈 拡張 プロセスの一部の実施形態のプロセス フロー図である。
【図210】[0250] 図210 は、いくつかの実施形態による、戦略 0656．2に記載のようにその DAG 子孫を トップレベルまで引き上げることにより矛盾する可視 ノードを隠蔽する複数の ローカス エンティティについての前記文脈 拡張 プロセスの一部の実施形態のプロセス フロー図である。
【図211】[0251] 図211は、いくつかの実施形態による、戦略 0656．2に記載のように 拡張 時に親セットが 明示されたトップレベル ノードを捕獲する複数の ローカス エンティティについての文脈 拡張 プロセスの一部の実施形態のプロセス フロー図である。
【図213】[0253] 図213 は、いくつかの実施形態によるルーチンの実施形態のプロセス フロー図である。このルーチンは、段落０４２６に記載のように、サブ構造における1点から前記ルートまでのエンティティ 識別子の経路を受容し、当該経路に沿ったノードが展開することを保証する。
【図214】[0254] 図214は、いくつかの実施形態によるルーチンの実施形態のプロセス フロー図である。このルーチンは、段落０４６６に記載のように、文脈における1点から前記ルートまでのエンティティ 識別子の経路を受容し、当該経路に沿ったノードが展開することを保証する。
【図215】[0255] 図215 は、いくつかの実施形態による、文脈およびサブ構造双方に関連するアクティブ 補助 情報を含むプロジェクト 画面である。 [0256] 図215 は、いくつかの実施形態による、文脈およびサブ構造双方に関連するアクティブ 補助 情報を含むプロジェクト 画面 である。
【図227】[0268] 図227 は、 いくつかの実施形態による、エンティティをローカス ノードとして含ませる際に用いられるファセット 値を選択するための前記クライアント プロセスの実施形態の プロセス フロー図 である。
【図228】[0269] 図228 は、 いくつかの実施形態による、エンティティをローカス ノードとして含ませる際に用いられるファセット 値を選択解除するための前記クライアント プロセスの実施形態の プロセス フロー図 である。[0270] 図175〜図228の各 図面 要素には、６桁の コードが以下のように割り当てられる: ・第1の 桁は、 相対的 位置を指す。 1: サブ構造 2: 文脈 ・第２の 桁 は、 ナビゲーション状態に対してアクティブであるノードを指す。 1: 単一の ローカス ノード 2: 複数の ローカス ノード 3: 均一 ノード 0: １つよりも多くの集中への関係 ・ 第3の 桁 は、前記要素が最も密接に関連付けられた操作を指す。 1: 生成 2: 拡張 3: コラプス 4: 除去 0: 複数の 操作へ関連 ・ 第4の 桁 は、 (段落０６５６に記載のように)前記ノードが再声明的に または 動的に 割り当てられているかを指す。 1: 静的 2: 動的 ・ 第５の 桁 は、段落０６５２または 段落０６５３にリストされている順序においてどれくらいの内容を明示すべきかまたは任意のまたはN/Aについては0を示すべきかについての戦略を指す: ・ 最終 桁は逐次的である。 ナンバリングシステム は、直観を支援することを意図し、ここで提示される特定の 実施形態 を指す。 任意のルーチンの適用可能性を制限することを意図しない。
【発明を実施するための形態】
【0044】
詳細な説明[0279]
プロジェクトについて、「解決法 空間」 から前記「問題 空間」が値において分離されることが認識されている。前記問題 空間の要素は、 「問題」または「チャレンジ」と呼ばれる場合があり、前記解決法 空間の要素は「解決法」または「アプローチ」と呼ばれる場合がある。 多様な システムにより、チャレンジに対処するチャレンジおよび潜在的 解決法の提案を可能にすることにより、 協働および/または イノベーションが促進され得る。
【0045】
[0280]任意の領域（例えば、広範な社会的 問題および問題を軽減し得る解決法、 技術的問題またはエンジニアリング問題およびその問題を満たす解決法、ならびに顧客 痛点としてのマーケティング努力によって特定された問題およびこれらの問題を軽減し得る新規製品としての解決法）へ適用される問題および解決法が、広範に解釈される。
【0046】
[0281]プログラミング 言語理論における問題および解決法空間について、類似性が発見され得る。 例えば、問題は 種類に対応し得、解決法は数式に対応し得、 １つの種類が問題に対処する解決法に対応する数式へ割り当てられる。 このような類似性は、不十分である。なぜならば、解決法は、対処しようとする問題の任意の特殊な場合を必然的に解決するものの、１つの種類に属する 数式は、当該種類の任意のサブタイプに必ずしも属していないからである。 これは、その種類の理論が関連しないということではなく、その関係が反変であるということである。 詳細には、１つの問題により別の問題が 詳細化されるとき、後者の問題は、より具体的な ドメインを含む関数型とみなすことができる。 例えば、都市という設定における貧困を低減するという問題により、貧困低減という問題がより一般的に詳細化される。なぜならば、都市という設定はより一般的な設定よりもより具体的であるため、解決法の構築においてこの設定の特徴を利用することが可能であるからである。
【0047】
[0282]オブジェクト指向 言語は、このような状況について類似性を提供する。なぜならば、クラスは詳細化 階層中にあるため、１つの方法 パラメータ (主に「これ」または「セルフ」) が前記階層中の前記位置に関連するためより下位レベルにおいてより具体的になるからである。スーパークラス における方法を任意のサブクラスによって呼ぶことができるのと同様に、詳細化された 問題に対する解決法は任意の詳細化する問題へ適用されるが、 その逆(すなわち、サブクラスにおける方法を スーパークラスから呼び出すこと)は安全ではないことが多い。 「詳細化」という用語を一貫して用いているが、この用語はより特殊なエンティティを指し、「詳細化された」とは、詳細化するより一般的なものを指し、いくつかの共通の使用例と異なる場合がある 点に留意されたい。
【0048】
[0283]プログラミング 言語理論において、数式の詳細化という観念があり、前記詳細化された 数式 が同じ結果をもたらす場合に必ず終端する場合、１つの 数式 が別の数式を詳細化する。前記詳細化 数式の前記状態 図から前記詳細化された 数式の前記状態 図への準同形写像 によって 数式の詳細化を行うという観念もある。
【0049】
[0284]プロジェクトの観点においては、問題を詳細化するということは、問題の特別な場合の特定に対応し得、解決法の詳細化は、解決法をさらなる詳細により精緻化することに対応し得る。 問題に対処する解決法の関係に加えて、問題をモチベートする 解決法の関係を検討することにより、モチベートされた 問題に対する解決法の実行により、前記モチベートする 解決法の実行への貢献が得られる。 問題についての前記詳細化関係を通じた解決法の継承と、解決法についての前記詳細化関係を通じた問題の継承とについて検討する。 問題についての前記詳細化関係を通じた解決法の継承は、詳細化する解決法がより適切であり得るものの、問題に対する 解決法は、当該問題の任意の詳細化にも関連すると認識する。 解決法についての詳細化関係を通じた問題の継承は、解決法 がモチベートする 解決法の実行に必要な問題が当該解決法の任意の詳細化の実行にも関連しており、（恐らくは詳細化する問題の形態で）対処する必要である旨を認識する。一般的に、問題についての詳細化関係および解決法についての詳細化関係はどちらも、多数対多数の関係である（すなわち、同じ問題 または解決法 を多数の方法で詳細化できるだけでなく、所与の問題 または 解決法 が複数の 他の 問題または 解決法もそれぞれ詳細化することができる）。 問題に対処しかつ問題をモチベートする解決法の関係も、多数対多数の関係であり得る。
【0050】
[0285]解決法は、問題について詳細化される（すなわち、提供されるさらなる詳細 は、詳細化する解決法が詳細化する問題に対処するという事実に関連する）ことが多いものの、理解されていない。あるいは、別の観点からみると、問題に対する解決法は、より一般的な問題に対してより非具体的な解決法 を活用し得る。 同様に、 問題が解決法について 詳細化された（すなわち、特定された特別な場合 は、詳細化する問題が達成すべき内容をより厳密に定義する詳細化する解決法によって モチベートされていることに関連する）場合が多く、理解されていない。 あるいは、解決法 によってモチベートされた 問題の場合、より非具体的な解決法によってモチベートされたより一般的な問題への資格が必要になる場合がある。
【0051】
[0286]問題に対処する解決法および解決法によってモチベートされた問題を超えて、 実施形態において、プロジェクト 情報の他の 要素（例を非限定的に挙げると、スキル、 議論、個人および資金）についての情報が維持される。 例えば、解決法に必要なスキルが維持され得、より具体的な 解決法に必要になるものとして、より具体的な スキルおよび同様に問題を支持または問題に反対する議論 (その関係性)、 解決法(その正確さ)、または他の 議論 (その有効性)がある。 必要なスキルは、解決法についての詳細化関係を通じて継承され得る。 さらに、スキル は、解決法についても詳細化され得る。 プロジェクト 情報 の多様な 要素により、自然な 詳細化関係と、これらの詳細化関係に沿った多様な 方向におけるプロジェクト 情報 の継承とが支持される。 例えば、プロジェクトおよび熟練の 個人の必要性は、 前記サブスキル 詳細化関係を通じて継承され得る。
【0052】
[0287]トップダウン 方式での階層のオーグメンテーション は、 既存のものを詳細化する問題または解決法、既存の問題に対処する解決法、および既存の解決法によってモチベートされる問題によって支持され得る。 逆に、階層がボトムアップ方式でオーグメントされる場合もある。 プロジェクトを示すDAGをオーグメントする直観的手段を用いて、事実を暗示的に獲得（例えば、詳細化された 問題の解決法について問題の解決法を定義）し、詳細化された 問題 モチベーションについて 問題 モチベーションを定義できる（いわゆる 相対的 DAG オーグメンテーション）が可能であると有用である。 このような施設は、関連付け間の詳細化 対応関係も維持し得るため、後日に前記プロジェクト 構造を改変する場合も適切に対応することができる。
【0053】
[0288]情報 は、 エンティティ間の非周期 親関係について提示されることが多い。 前記親関係の逆が前記子関係である。 ここで、エンティティは、物理的 または概念的なものであり得る。 「非周期」という用語は、任意のエンティティからの関係が連続的に1つ以上適用 されても、同一エンティティは得られないということを意味する。 このような関係は、例えば、１つのエンティティ または概念が 別のものに優位に立つか、別のものを包含するかまたは生み出すことを意味する。 いくつかのより具体的な 例を以下に挙げる: セットは、 厳密により少数の要素を含む親セットとしてみなされ得、従来のオブジェクト指向 言語中の インターフェースまたはクラスあるいは委譲ベースの オブジェクト指向 言語中のインスタンスは、世襲 構造によって関係つけられ、個人(またはそのゲノムの部分) は、その生物学的 親に関係し、文書のアウトライン 構造において、文書の任意の宣言された 部分は、細区分それぞれの親としてみなされ得、文書のバージョンは、その大元となる先行バージョンの子である。 ツリーは階層 構造であり、その内部においてエンティティは最大でも親を１つ有する。より一般的には、有向 非周期 グラフ (DAG) は、内部においてエンティティ が任意の数の親を持ち得る階層 構造である。 従来のオブジェクト指向 言語について、Java プログラム中のクラスはツリー 構造を形成する一方、Java プログラム中のインターフェースおよびC++およびPython プログラム中のクラスは全て、複数の 継承をサポートするため、DAG 構造を形成する。 非空 ツリーは、単一の ルート ノードを有し、親は持たない。 非空の DAGは、１つ以上の ルート ノードを有し、親は持たない。 子を持たない ノード をリーフと呼び、親を持たないノード を 孤児と呼ぶ。多様な非空 ツリーまたはDAGをそれぞれ、森 または DAG森と呼ぶ。DAG またはツリー ノード の兄弟は、その親の他の 子である。 DAG ノード の非兄弟は、その子の他の 親である。 混乱を避けるため、前記その下側のDAGおよびサブストレート ツリー中の非兄弟である前記文脈 ツリー中の兄弟を文脈 兄弟と呼ぶ。 この記載の残りについては、 ツリーのみについてノードを用い、下側のDAGをエンティティ間の概念的 関係とみなす。
【0054】
[0289]階層 構造 は大型である場合があるため、観察者 が最も関係の深い内容へ方向付けることが困難となる。 ツリーは、その親の下側の子 ノードを用いて 可視化され得る。 ツリーの部分に集中する標準的かつ一般的に受容された方法においては、多様な ノードがコラプスおよび拡張される。 これらのノードは、開いたフォルダ、閉じられたフォルダまたは恐らくは 空の フォルダなどのアイコンと共に表示され得、前記ツリーのその部分の現在の 集中状態を示す。 開いたフォルダ は、ノード が拡張されているため、その 子が可視状態になっていることを示し、閉じられたフォルダは、ノードがコラプスされているため、その子が隠蔽されていることを示し、空のまたは上下反転した フォルダは、ノードが子無しのエンティティを示す。 ノード の前記文脈 または サブ構造を 当該 ノードのマーク付けとして適切に開くかまたは閉じることにより、 当該階層についての適切な集中を表現する。 いくつかの実施形態において、「開いた」アイコンおよび「閉じた」アイコンのみをサポートすることが選択され得、 これにより、子孫無しの エンティティを示すノードを開いた状態または閉じた状態で表現することができる。
【0055】
[0290]DAGは、その下側グラフとして可視化され得、 全エッジが概ね同一方向を向く。 これは、例えば、多様な バージョンのファイルシステム（例えば、分岐バージョンおよびマージバージョン）の展開の可視化をサポートするオープンソースツールにおいて用いられる。しかし、DAG は、視覚的表示を行うのには複雑かつ気が散る場合がある。ツリーは、DAGよりも概念的に単純であり、DAG内の１つまたは２〜3個のサブツリーのみが任意の時点において関連する場合があり得る。 １つ以上の エンフローカス ノードを指定することにより、DAG をあたかもツリーであるかのように集中させる方法が有れば有用である。これら １つ以上の エンフローカス ノードは、ユーザの ナビゲート先になり得、これらのエンフローカス ノードについてノードがコラプスおよび拡張 され得、 これにより、任意のエンティティが任意の時点における前記可視化において単一の ノードのみによって表現され得る。 ツリー 表現の別の利点として、共通の イディオム（例えば、DAGの部分の コピー、カットおよびペースト）の利用が可能になる点がある。
【0056】
[0291]いくつかの実施形態の記述に関連して、多様な定義が提示される。 ツリー内のノードにおいてルートされたサブツリー全体は、 当該ノードから前記子関係を介して到達することが可能なノード全てによって構成される。すなわち、その文脈は、 前記ノード から前記ルートへの経路である。 同様に、DAG内のノードにおいてルートされた サブDAG全体は、子関係を介して当該ノードに到達することが可能なノード全てによって構成される。 すなわち、その文脈は、 当該ノードにおいてルートされかつ任意の数の親関係適用によって到達することが可能なノードを含む反転 ツリーである。 一般的に、文脈は前記ローカス ノードを含むものとしてみなされ、ローカス ノードを除外したい場合は適切な 文脈を指すものとしてみなされる。 サブツリー 全体またはサブDAG全体のサブ構造 は、内部に含まれるノード全てである。一般的に、サブ構造は前記ローカス ノードを含むものとしてみなし、ローカス ノードを除外したい場合に適切な サブ構造を指す。 前記サブ構造 および前記文脈 双方により、論理 ツリーが形成される。すなわち、そのコンポーネントも論理と呼ばれる。 これにより、コンポーネントが内部にコンポーネントを含むサブストレート ツリーと区別される。コンポーネントはサブストレートとも呼ばれる。 文脈 は上方に成長するのに対し、サブ構造は下方に成長する。 サブストレート ツリーは、常に下方に成長する。これらの定義は、ひとえに 解説目的のためのものである。実施形態においていくつかの形態において明示的に存在しなければならない唯一のツリーは、ツリー探査 がイネーブルされたユーザによって可視化されるツリーである。 このようなツリーは、ノードを適切にインデントし、これらの中間 表現全てを 差し控えることにより、生成され得る。
【0057】
[0292]ツリーのナビゲーション をサポートしかつ前記ツリー内のローカス ノードの概念を有するシステムの場合、 当該ノードにおいてルートされた前記サブツリーの文脈へのアクセスを親関係中のノードの（ツリーの前記ルートまでの）シーケンスとして提供することが多い。 例えば、オペレーティングシステム シェル は、いくつかの指定 ルート またはホームディレクトリへ戻る親 ディレクトリのシーケンスをそのプロンプト中に表示し得る。 DAG内の サブDAGの文脈上への可視化および集中の方法が有れば有用であり、 ここでも、任意のエンティティは、任意の時点における前記可視化において単一の ノードのみによって示される。 １つのアプローチ として、どちらも下方に成長するサブ構造 ツリー および文脈 ツリーを別個に表示し、双方を単純なツリーとして操作することを可能にするが、 その場合、サブ構造と前記文脈との間に存在する前記ローカス エンティティ の代わりにユーザに提供することができないため、不十分である。
【0058】
[0293]HTML は、ツリーをネスト状のリストとして提示する際に適しており、ブラウザは、 可視化ing このようなツリー 構造を可視化する標準的方法を有する。 他の 表現 言語（例えば、JSON）も、ツリー提示に適している。 サブツリーおよびその 文脈 をツリー全体内においてツリー全体と同一ルートを有する 単一の ツリー として提示することが明確に可能であり、これは、任意のノードをサブツリーまたはルートへの経路から除外することによって行われる。 サブ構造の部分およびDAG内のサブDAGの文脈を単一の ツリーとして可視化し、このツリーをサブストレート （例えば、 HTML）内に提示することができれば有用である。
【0059】
[0294]さらに、 (それぞれが異なる ローカス ノードにおいてルートされた) 多様な サブDAGについては、共通の 祖先および子孫への多様な接続が明白になるようにこれらのサブDAG を確認できると有用である。
【0060】
[0295]バージョン 制御 システムは、改訂 履歴を「コミット」のシーケンスとして取り扱う点において逐次的であり得る。 これらのコミットはそれぞれ、同一ファイルまたは多様な ファイルへの 複数の 変更を含み得る。 ファイル内の変更は、当該ファイルの旧バージョンと新規バージョンとの間の差を認識することにより、特定される。 これらの変更は、共にコミットされ、これらを後でティーズして別個のコミットとすることは常に可能であるが、これは意図される用途ではない。 すなわち、コミットは、確立されたときと逆の順序で一度にアンドゥされることが意図される。 コミットは、「diff」結果として記録され、ファイルのうちどのラインを他の ラインと交換すべきかを示す。 そのため、前記diffを前記オリジナルの ファイル へ適用して改変ファイルと一致させること（その逆）が容易に可能になる。 「diff」をいずれかのファイルの改変バージョンへ適用することはより困難であり、この プロセスを行った場合、ユーザが解決することが必要にな矛盾が発生する場合がある。
【0061】
[0296]標準的な「diff」ファイルは、ファイルへの変更を記録する方法が１つよりも多く有る点において、若干任意である。極端な例において、前記初期ファイルは、1000個の 同一の ラインおよびこれらのラインの改変ライン999を含み、任意のファイルは削除されたものとしてみなされ得る。後でオリジナルの ファイルの改変 バージョンへdiff ファイル が適用された場合、差が問題になり得る。
【0062】
[0297]さらに、標準バージョン 制御における一連のコミットは、DAGにおいて分岐およびマージし得る分岐を形成する。 そのため、ユーザ が異なる 変更によって平行 分岐を確立し、これらの変更を別個にアンドゥすることができる。しかし、 各分岐 は1組の変更のみを含み、これらの分岐が最終的にマージされた場合、 同様にコミットの線状の シーケンスを取り扱う。
【0063】
[0298]It is possible in 標準的 バージョン 制御において、シーケンスの中間において コミットを更新し、その後後続 コミットを再生することができ、その結果恐らくはこの プロセスにおいて矛盾がトリガされる。 このような矛盾は、管理および解決することが困難であり得るが、これらの改変が付加されたときと逆の順序でこれらの改変を アンドゥする必要が有る場合、変更が独立的であると、制約が過度になる。
【0064】
[0299]変更の配置を線状の シーケンスとしてではなくDAGにおいて自然に行う バージョン 制御の階層 システムが有ると、有用である。
【0065】
[0300]データベース 記録に対する変更に矛盾が有る場合、 標準的 慣習においては、提案された変更のうち１つをほとんど拒否することが多い。 矛盾を含む変更を秩序的に 矛盾 する分解のために維持および編成するバージョン 制御の階層 システムが有れば、有用である。
プロジェクト 階層の前記オーグメンテーションをサポートするための継承を用いた方法
問題および解決法 空間の分離を含む、プロジェクト 管理 エンティティおよび関係
【0066】
[0301]実施形態において、多様な所与の直観的に非周期の関係に基づいて DAG (恐らくは ツリー)が構築される。 多くの種類の エンティティについて、以下のような自然な 詳細化関係が存在する:
directlyRefinesProblem ： 問題へ、その詳細化する問題のうち１つ（すなわち、前記第1の 問題の特別な場合）から。
directlyRefinesSolution ：解決法へ、その詳細化する解決法からの１つ（すなわち、当該解決法と一貫する別の 解決法）から。ただし、さらなる詳細も付加される。
directlyRefinesSupportingArgument： サポートする議論へ、その詳細化 サポートする議論のうち１つ（すなわち、前記第1のものと一貫する 別の サポートする議論）から。 ただし、さらなる詳細を追加するかまたはより強力な位置がとられる。
directlyRefinesOpposingArgument：反対の 議論へ、 fromその詳細化 反対の 議論のうちの１つ（すなわち、前記第1のものと一貫する 別の 反対の 議論）から。ただし、さらなる詳細を追加するかまたはより強力な位置がとられる。
directlyRefinesSkill： スキルへ、その詳細化 スキルのうちの１つ（すなわち、前記第1の スキルの特殊化） (すなわち、 下位専門領域または サブスキル)（例えば、心冠手術 から手術）から。
directlyRefinesUser ：ユーザへ、その詳細化 ユーザのうちの１つ（例えば、前記第1の ユーザの組織図中のメンティ または部下）から。
【0067】
[0302]エンティティ間において、以下のよな自然な クロス種類関係も有る：
directlyAddresses ： 解決法から、当該解決法が対処する問題へ。各解決法 が少なくとも１つの 問題に対処することが必要であることが自然である（が必ずしもそうではない）。
directlyMotivatedBy ：問題から、当該問題をモチベートする解決法へ (前記問題 への解決法は、所与の解決法の実行に向かって貢献する)。
directlySupports ： 問題、 解決法あるいはサポートする議論または反対の 議論へ、これをサポートする議論から。
directlyOpposes ： 問題、 解決法あるいはサポートする議論または反対の 議論へ、これに反対する議論から。
directlyRequiredBy ：スキル から、このスキルを必要とする解決法 へ。
directlyProficientlnSkill ：熟練した スキルを持つユーザから、当該スキルへ。 この関係 の元の関係付けには、 熟練度 レベルが注釈付けされ得る。
これらの関係のうちいずれかは、DAG 構造の生成の基本として利用され得る。 多様な 実施形態は、より多数またはより少数の関係を利用し得る（例えば、これらまたは他の任意の 自然な非周期 関連）。 これらの関係は、多数対多数であってもよいし、あるいはこれらのうち任意のものを多数対一に制限してもよい。 全てがそのように制限された場合、当該関係に対してツリー が有れば充分であるため、DAGの一般性は不要になるが、いくつかのこのような関係統一も多数対多数であり得る。 場合によっては(特に、後者の２つの場合)において、 実施形態において、記載の関係 またはその逆に基づいてDAGを構築することが望まれ得る。
【0068】
[0303]クロス種類関係 （例えば、directlyAddresses、 directlyMotivatedBy、 directlySupports、 directlyOpposes、またはdirectlyRequiredBy）において、第1の 議論 を前記従属的な エンティティと呼び、第２の議論を前記独立的な エンティティと呼び、独立的な エンティティの詳細化 鎖を通じて 従属的な エンティティ を継承することが可能である。このような従属的な エンティティとの関係の元に関連付けられた 独立的な エンティティを、当該の従属的な エンティティのオブジェクトと呼ぶ。
【0069】
[0304]「詳細化関係」 という用語は、 詳細化された 独立的な エンティティからその詳細化するエンティティのうち任意のものへの継承(主に、従属的な エンティティおよび恐らくはその子孫の継承)をサポートすることができる任意の関係を指す。 以下、段落０４３５において、再声明である詳細化関係も、 当該詳細化関係または別の 詳細化関係下の詳細化するエンティティの継承をサポートし得る。 「クロス種類」関係とは、関連するエンティティの種類が実際に同一であるか否かに関係無く、任意の非詳細化関係を指す。 実施形態において、同じ種類のエンティティ間の１つの詳細化関係のみまたは複数のこのような詳細化関係が支持され得る。 実施形態において、(必ずしも別個ではない)一対の 種類の エンティティ間のみに関係がある場合、これらの種類のエンティティ間の このような関連付けは全て、その関係に起因すると仮定され得る。
【0070】
[0305]次に、多様な 導出された関係を生成することができる。 先ず、 導出された関係のいくつかの標準的な技術的定義から開始する:
・前記インフィックス オペレータ が用いられる;２つの関係の構成を示す（すなわち、第3の 要素が存在する場合、前記第1の 要素および前記第3の要素が前記第1の関係によって関係し、第3の要素および第２の要素が第２の関係によって関係するように、一対の 要素が関係する）。双方の関係が1対１である場合、 関係の構成は、1対１よりも多い数を有する。前記関係が対多数 または1対１によって構成される場合、 関係の構成は、1対多数よりも多くの数を有する。 前記関係が多数対一 または 1対１によって構成される場合、関係の構成は、多数対一よりも多くの数を有する。少なくとも１つの関係が1対多数および多数対一それぞれによって構成されるかまたは少なくとも１つの関係 が多数対多数によって構成される場合、 関係の構成は、多数対多数のみであり得る。
・ポストフィックス オペレータ Kleene star (_*)を用いて、供給される関係(１種類〜同一種類)のゼロまたはより多数の適用の構成を示す。 Kleene star 操作の結果は、その議論と同じ数を有する。
・前記ポストフィックス 逆 オペレータ (_−1) を用いて、 議論関係から反転した全ての矢印との関係を示す (クロス種類 関係について、前記入力および出力の種類が逆転する)。
【0071】
[0306]これらの直接定義された関係を自然に 伸長させると、有用である 。 明らかに、以下の詳細化関係について:
【表1】
[この文献は図面を表示できません]
【0072】
[0307]場合によっては、各従属的な エンティティを１つ以上の 独立的な エンティティと関係させることが必要であり得る。 例えば、各 解決法が１つ以上の 問題に対処することあるいは各議論が１つ以上の オブジェクトを支持または１つ以上の オブジェクトに反対することが必要になり得る。 各問題 を１つ以上の 解決法によってモチベートするかまたは１つ以上の プロジェクトにおいて各スキルが必要になる可能性は低い。場合によっては、各従属的な エンティティ を１つの独立的な エンティティのみに関連させることが必要になり得る。 エンティティの種類および表現される関係に応じて、多様な 他の 制限を関係に強制することが望まれ得る。
【0073】
[0308]クロス種類関係については、以下と共に開始することが明らかである:
【表2】
[この文献は図面を表示できません]
次に、継承において以下が用いられる: addresses; refinedByProblem ⊆ addresses ：１つの 解決法 は、当該解決法が対処する任意の問題 の詳細化全てに対処すると仮定する。 問題は、解決法によって詳細化される任意の問題に対処する任意の解決法によって対処すべきものと仮定する 。
motivatedBy; refinedBySolution ⊆ motivatedBy ：１つの 問題は、 問題をモチベートする任意の解決法 の詳細化全てによって持ちべー知されるものと仮定する。 解決法 は、問題を詳細化する任意の解決法によって持ちべー知される任意の問題をモチベートすると仮定する。
supports; refinedByObject ⊆ supports ： 議論は、議論がサポートする任意のオブジェクトの詳細化全てをサポートすると仮定する。 オブジェクト は、議論が詳細化する任意のオブジェクト をサポートする任意の議論によってサポートされると仮定する。
opposes; refinedByObject ⊆ opposes ：議論 は、議論が反対する任意のオブジェクトの詳細化全てに反対するものと仮定する。 オブジェクト は、 議論が詳細化する任意のオブジェクトに反対する任意の議論 によって反対されるものと仮定する。
requiredBy; refinedBySolution ⊆ requiredBy ： スキルは、 スキルが必要とする任意の解決法詳細化全てに必要であると仮定する。 解決法 は、スキルが詳細化する任意の解決法 に必要な任意のスキルを必要とすると仮定する。
【0074】
[0309]１つのエンティティ が別のエンティティを詳細化する場合、詳細化されている前記エンティティと関連付けられた従属的 エンティティも、詳細化するエンティティと関連付けられる。 そのため、ユーザ が特定の エンティティへナビゲートした場合、 これらが詳細化するエンティティに直接従属するエンティティを示すことが理解される。 これらのことを、継承された エンティティと呼ぶ。 例えば、「どうやったら貧困を低減することができる? 」という問題をルート 問題として生成した場合、この問題を「どうやったら都市部の貧困?を低減することができる?」および「どうやったら健康で丈夫な個人間の貧困を低減することができる? 」という問題に詳細化することができる。 図1 〜図6 は、これらの アクションをサポートする実施形態を示す。 図1は、初期 Teamifier ユーザ ページであり、(アクティブ ユーザ が自身のページをビューする場合に) 新規の 「チャレンジ」を生成するためのボタン がページ内に存在する(この システムは、「問題」に対して「チャレンジ」を用い、「解決法」に対して「アプローチ」を用いる)。 このボタンがクリックされると、 (ユーザがその問題の本質（例えば、どのようなことを確立したいか）を入力するための図2中の入力 フィールドが出現する。 図3において、このフィールドが入力される。 この入力フィールドの後、トランザクション がサーバへ送られ、成功 を示す応答が受信された場合、チャレンジ ページへのリンクが図4のように生成される。 ルート 問題について生成されたリンクをクリックすると、ユーザ はその問題の ページへ移動し、 このページから、ユーザは前記詳細化する問題を生成することができる。 図5は、特殊化操作の選択を示し、図6 は、第1の 特殊化問題の入力を示す。 「困窮者にスキルを教えよう! 」が前記問題に対処する解決法として追加され得、 「どうやったら貧困を低減できる? 」が前記問題に対処する解決法として追加され得、これにより、解決法もこれらの詳細化する問題へ必然的に適用されるが、詳細化する解決法が有用であり得ることが分かる。 図7〜図9 は、 (双方の特殊化問題が生成された後に) ユーザが前記解決法を提案する様態を示す。 図7 は、解決操作の選択を示し、図8は、この 解決法の入力を示す。 図9 は、 前記解決法 が生成された後のページを示す。 図10 は、 前記新規 解決法についての前記コンポーネント化操作の選択を示し、 図11は、 「みんなが既に知っていることをどうやったら示すことができる？」をコンポーネント 問題として入力する様子を示す。 ここで、詳細化する解決法のうちの１つへのリンクをクリックすると、前記ユーザに表示されるのは、図12に示すような前記解決法およびその コンポーネント を 継承された 子孫(ここでは、グレーのアイコンによって示す) ならびに文脈 としての一般的 問題 (これもグレーのアイコンによって示す)である。 同様に、解決法として「補給品を必要なところに送ろう！」 を詳細化して「補給品を潜水艦で送ろう！ 」および「材料を宇宙船で送ろう！ 」にすることができる。 「どうやったら輸送時に補給品を保護できる? 」という問題は、「補給品を必要なところに送ろう！」という解決法よってモチベートされた問題であり得るため、 この問題が解決された場合、これらの 詳細化する解決法への解決法に必然的に貢献することになるが、詳細化する問題も有用であり得ることが分かる。 図13は、前記第２の 解決法 特殊化をクリックした結果を示す。一般的問題の コンポーネント 問題 は、継承された 子 ノードとなる。
【0075】
[0310]詳細化するオブジェクトを継承するために、以下の基本があることがさらに認識される。
refinesSolution; addresses ⊆ addresses： 解決法によって対処される任意の問題も、前記解決法の詳細化によって対処される。 解決法は、問題が詳細化する解決法によって対処される任意の問題に対処する。
refinesProblem; motivated By ⊆ motivatedBy ：問題をモチベートする任意の解決法は、前記問題の 詳細化もモチベートする。 問題は、解決法が詳細化する問題をモチベートする任意の解決法 によってモチベートされる。
refinesSupportingArgument; supports ⊆ supports ：議論 によってサポートされる任意のオブジェクト は、前記議論の詳細化によってもサポートされる。 議論は、詳細化する議論によってサポートされた任意のオブジェクト をサポートする。
refinesOpposingArgument; opposes ⊆ opposes ：議論によって反対される任意のオブジェクトは、 前記議論の詳細化によっても反対される。 議論は、詳細化する議論によって反対される任意のオブジェクト に反対する。
refinesSkill−1; requiredBy ⊆ requiredBy ： スキルを必要とする任意の解決法は、スキルの 一般化も必要とする。
スキル は、詳細化するスキルを必要とする任意の解決法 によって必要とされる。
【0076】
[0311]解決法によってスキル 要求を含める場合、詳細化関係は反対方向に働く 点に留意されたい。すなわち、スキルの サブスキルではなくスーパースキルは、当該スキルを必要とする解決法 の詳細化に必ず必要になる。
【0077】
[0312]ユーザ が特定の エンティティへナビゲートした場合、ユーザが詳細化するエンティティに直接従属する エンティティおよび前記従属的な エンティティを詳細化するエンティティだけでなく、任意の一連の直接従属性および詳細化を通じて 従属的な エンティティも示す。
【0078】
[0313]実施形態において、エンティティおよび関係に基づいてDAGを展開および伸長させる際に、ユーザまたは複数の ユーザが 協働的にサポートされる。
【0079】
[0314]問題の解決法は、詳細化する問題の１つ以上の 解決法について定義され得る。
同様に、解決法によってモチベートされる問題は、 詳細化する解決法によってモチベートされる１つ以上の 問題について定義され得る。 問題に対処する「困窮者にスキルを教えよう! 」の例の場合、「どうやったら貧困を低減できる? 」および 「困窮者に農業を教えよう!」はどちらも、「困窮者にスキルを教えよう! 」を詳細化し、詳細化する問題である「どうやったら 都市部の貧困を低減できる? 」および「どうやったら健康で丈夫な個人間の貧困を低減できる? 」に直接対処する。 さらに進むと、「どんな作物をどのように育てることができる?」は、「困窮者に農業を教えよう! 」の コンポーネント であり、「みんなが既に知っていることをどうやったら示すことができる?」を特殊化する。 「補給品を必要なところに送ろう！」および「多様な圧力条件下においてどうやったら輸送時に補給品を保護できる? 」という前記解決法双方によってモチベートされる問題である「どうやったら輸送時に補給品を保護できる? 」の例は、「どうやったら輸送時に補給品を保護できる? 」を詳細化し、詳細化する解決法である「補給品を潜水艦で送ろう！」および「材料を宇宙船で送ろう！」によって直接モチベートされる。このようなオーグメンテーション 操作は、ユーザによって明示的に または 暗示的に指定され得る。 前記第1の 例について、 図14 〜図21は、これらのプロジェクト エンティティおよびその結果を生成するためのユーザ アクションのデモンストレーションを示す。 図14は、ユーザが 「どうやったら 都市部の貧困を低減できる? 」および「どうやったら健康で丈夫な個人間の貧困を低減できる？」を相互に特殊化する操作を開始する様子を示す。 ユーザは、前者を選択して、緑色 境界でマーク付けし、前記特殊化操作を後者から開始する。ユーザ は、特殊化問題を生成し、これへナビゲートした後、前記文脈を拡張させると仮定する。 「みんなが既に知っていることをどうやったら示すことができる？」は、 前記新規問題の継承された 子孫として表示される。 １つ以上の 詳細化関係付けに沿ったクロス種類関係付け の生成の多様な 公式化が提示される。 図15は、この 継承された 子孫からの特殊化 操作の開始を示し、その継承された 親である「困窮者にスキルを教えよう! 」の特殊化も暗示的にリクエストする。 図16は、当該問題の解決法としての 「困窮者に農業を教えよう! 」 に対する 「困窮者にスキルを教えよう! 」の前記ユーザによる定位置 再声明を示す。 次に、システム は、前記ユーザにより図17中の定位置 再声明に進み、「みんなが既に知っていることをどうやったら示すことができる？」から「どんな作物をどのように育てることができる? 」へ進む。 次に、前記ユーザ が前記新規 解決法へナビゲートし、前記文脈を適切に拡張させると、図20から分かることとして、新規問題が双方のコンポーネントである解決法の子であり、前記新規 解決法が詳細化する双方の問題の子であり、 「みんなが既に知っていることをどうやったら示すことができる？」、その解決法は、コンポーネントである「困窮者に農業を教えよう! 」である。 同様に分かることとして、後者の解決法は、 詳細化する「解決法」である「困窮者にスキルを教えよう! 」と、それによって解決される問題である「どうやったら健康で丈夫な個人間において都市部の貧困を低減できる? 」との双方の子である。 前記ユーザ が前記オリジナルの一般的問題である「どうやったら貧困を低減できる? 」へナビゲートされ、前記サブ構造を適切に拡張させると、図21から分かるように、解決法である「困窮者にスキルを教えよう! 」がその 子と同様に未だ存在する場合、 「みんなが既に知っていることをどうやったら示すことができる？」、これらはそれぞれ、子 としてその 再声明を有する。
【0080】
[0315]図22 は、 実施形態を通じたデータフローの様態を示す。 DOM ツリー は前記クライアント上のみに存在し、前記フルDAGは前記サーバ上のみに存在する。 局所的DAGは、 クライアントによる使用のために、サーバによって生成される。 局所的DAGは、前記クライアント が ナビゲートされた１つ以上の エンティティの視点からの前記フルDAGからの情報のサブセット を含む。 ３つの データストア全てが、クライアント UIを通じて生成されたユーザ 操作に基づいて維持される。
【0081】
[0316]図23 は、実施形態下のクライアントと サーバ システムとの間の相互作用の可能なシーケンス処理を示す。 前記サーバと相互作用する任意の数のクライアント システムがあり得、前記クライアントまたは前記サーバ のいずれかが、 潜在的に多数のコンピューティングおよび記憶装置に分配され得る。 値トランスポートのための任意のシリアル化およびアンマーシャリング については省略する。なぜならば、この 要求は、ソフトウェア開発分野の当業者にとって公知であるからである。 クライアント は、前記サーバへサーチクエリを提示することにより、開始し得る。 サーバ は、 ゼロ以上のサーチ 結果と共に応答し得、この結果の中から、クライアントは１つ以上の ローカス エンティティを選択し得る。 あるいは、前記クライアントは、フルDAGの表現を通じてナビゲートして、１つ以上の ローカス エンティティを選択し得る。 この 選択が前記サーバへ通信されると、サーバは、局所的DAG 2200を介して前記DAG をこれらのエンティティへ局所化する。 その結果得られたDAGは前記クライアントへ送られ、Present DAG 0100と共にユーザによって探査されるように設定される。 任意の時点において、前記サーバ は、ウェブソケットを通じて実行可能な他の セッションによって生成された局所的 DAG エンティティに対するアップデートをクライアント へ通知し得る。 ユーザ は、１つ以上の エンティティを選択し得、 この 処理 をサーバ 側において繰り返す。 あるいは、前記ユーザは、操作的 操作 を前記DAGへ行い得る。 前記ユーザが前記DAGをオーグメントすると、前記クライアント (クライアント 特殊化DAG オーグメンテーション 2101およびクライアント クロス種類および特殊化DAG オーグメンテーション 2102を介して)前記DAG の自身のコピー側のこの 操作を実行する(ユーザの 可視化を含む)に加えて、前記親 エンティティ idsおよび新規エンティティ 情報が前記サーバへ送られ、前記サーバは、(特殊化DAG オーグメンテーション 3201および特殊化クロス種類 DAG オーグメンテーション 3202を介して) 対応する 操作を前記サーバの DAGへ行う。 前記DAGのオーグメントにおいて、継承された ノードのオーグメントが行われ得、この場合、特殊化 2103 のためのコピー 継承が必要になり得る。ここで、 トップダウン オーグメンテーションを仮定したが、 もちろん、ボトムアップ も同様に取り扱われ得る。ユーザ が前記DAG 削除されたAG Portion 0104の一部を削除する場合、恐らくは削除すべきエンティティ idをエミュレートすることにより、前記サーバに対し、その部分について通知する必要がある。クライアントおよびサーバ は、これらのエンティティおよび任意の接続 関係を削除し得る (継承された エンティティは削除されない) （Delete Entity 0204、Delete Relationship 0214 ）。前記削除された ノードの親および子が前記DAG中に残っている場合、 これらの親および子は、 新規関係によって生成され得る（Create Relationship 0213）。 前記ユーザ が子をその親からリンクを切断する（Unlink Entity 0114）と、前記サーバ に対し、前記エンティティ idおよびその親 エンティティ idが通知される。 クライアントおよびサーバは、前記DAG Delete Relationship 0214の自身のコピー上のこれらの関係を削除し得る (継承された エンティティは、その親からリンク切断されない)。ユーザ がDAG の部分を新規の親および子へ移動させ、既存の関係を交換する（Move DAG Portion 0105）と、前記サーバに対し、このようにして移動されたDAGの部分、 その古い親および子 エンティティ idおよびその新規の親および子 エンティティ idが通知される。 クライアントおよびサーバ は、前記DAG のこの部分をその古い親をリンク付けする関係を削除し得（Delete Relationship 0214）、その新規の親へのリンク付けする関係を生成する（Create Relationship 0213）。ここでも、前記削除された ノードの親および子が前記DAG中の定位置に残留している場合、これらの親および子は、新規関係によって接続され得る。これらの操作は、広範に定義されるため、実施形態は、これらのうちの任意のものの特別な場合を提供し得る。 任意の数の他の 操作を前記クライアントを通じて前記ユーザ が表現することが可能である。それぞれは、 DAGのクライアントコピーおよびサーバ コピー双方に行われる。 いずれの場合も、操作は、 任意のレベル の抽象化においてサーバへ通信され得る。例えば、前記高レベル 操作の分析が、クライアントのみまたはクライアント および前記サーバ双方のみに行われ得る。 後者の場合、操作が重複するが、輸送コストが低減され得、インターフェースがよりセキュアになる。 例えば、 いくつかの実施形態において、各サーバ 操作 により単一の エンティティ または 関係のみが生成され得、これらは前記基礎的操作である。
【0082】
[0317]「クライアント」および「サーバ」という用語は、広範に解釈されるべきである。 場合によっては、 クライアント および前記サーバは同じマシンであり得る。 さらに、前記グローバル DAG を任意の数のサーバ システム間において分割してもよい。極端な場合、各ユーザ は、自身が管理するプロジェクトの内容を自身のマシン上にホストし得る。
特殊化による明示的な DAG オーグメンテーション
【0083】
[0318]いくつかの実施形態において、前記フルDAGのグローバル ビューまたはその任意の制限がユーザへ提供される。 この DAGから、ノードを選択し、この選択されたノードから前記DAGを伸長させる ことができる。
【0084】
[0319]ユーザは、 連帯的に 詳細化すべき同一種類のいくつかのエンティティを選択し得る。 図24中のDAGを考えると、円形は、独立的な 種類の エンティティを指し、四角形は、従属的な エンティティ 種類の エンティティを指す(ここで、以下、具体性のためかつ一般性を失うことなく、円形および四角形はそれぞれ問題および解決法を示し、同じ形状間のリンクは詳細化を示し、円形および四角形間のリンクは 、問題に対処する 解決法また解決法によってモチベートされたは問題を方向に応じて示すものとする)。 ここで、「菱形」 詳細化 パターンが問題間に記載されている。 ユーザがノード4および10を連帯的に 詳細化する場合、図29中の前記DAGが可能な結果となる。
【0085】
[0320]あるいは、ユーザは、 独立的な エンティティ をクロス種類関係付けによって伸長させることと、任意の数の従属的な エンティティを 詳細化することと双方を明示的に選択し得る。 例えば、前記ユーザは、 問題と、前記問題に対処する詳細化する解決法の導出元となる1組の解決法とを選択し得、 あるいは、前記ユーザは、 解決法と、前記解決法によってモチベートされる 詳細化する問題の導出元となる1組の問題とを選択し得る。 図24中の前記DAGに作用するユーザは、同様に解決法ノード 4および10を詳細化するが、 今回は、ノード 5を解決しつつ詳細化を行い、図36中の前記DAGが可能な結果となる。
【0086】
[0321]この モデルにおいて、この 情報を維持し、ユーザへ提示すること以外は、 ノード種類間または関係間の任意の差を認識する必要は無い。
【0087】
[0322]暗示的 オーグメンテーションについて以下に述べる多様な問題も、明示的な シナリオに適用され得る。 さらに、 DAGの ツリーベースのビューの場合、例えば「階層 構造およびその 文脈 の表現の探査方法」において、これらの明示的な 操作を 適切な制限を可能にするような様態でサブ構造、前記文脈または双方において全体的に行うことができることが分かる。
【0088】
[0323]図42は、継承を用いない実施形態の前記階層 構造を示す。 本 実施形態 は、クライアント システム、サーバ システム、および両者間のネットワーク 接続からなる。クライアント システム は、ブラウザ を実行する。ブラウザ は、ユーザによる DAGの探査 または オーグメントを行うことを可能にするインターフェースを表示する。 クライアントのオーグメンテーション プロセスにおいて、ノードをオーグメントするための一般的 ルーチンが用いられ、証拠が生成され、前記サーバとの通信がトリガされる。 これらの下側には、オペレーティングシステムが設けられる。オペレーティングシステムは、システム ハードウェアへのアクセスを制御する。 サーバ システムは、データベース 管理 システム (DBMS) サーバおよびウェブサーバを実行する。 ウェブサーバ は、ルーチン間を協調させる。これらのルーチンは、局所的バージョンのDAG を特定の ローカス ノードまたは前記クライアントによって用いられる ノードに対して構築し、前記サーバのDAG表現 を改変する。前者は、 前記サーバのフルバージョン のDAGを変換するルーチンを用いる。 前記サーバのDAG表現を変換しかつ変換前記サーバのフル バージョンのDAGを変換するルーチンは、データベース 管理 システム (DBMS) クライアントを通じてデータベースにアクセスする。 多様な ルーチンにおいて、システム ハードウェアへのアクセスを制御するオペレーティングシステムが用いられる。 ウェブブラウザ (クライアント)は、伝送制御プロトコル (TCP)およびインターネットプロトコル (IP)を用いて転送されるハイパーテキスト転送プロトコル (HTTP)を介してウェブサーバ と通信する。
【0089】
[0324]ユーザ は、 自身がナビゲートされた前記ノードによって示される前記エンティティに特に関心を持つと仮定することができる。 DAGのサイズを変換すると、多様な理由において有用である。そのような理由を以下に挙げる:最も関連する情報のみを提示すること、探査およびオーグメンテーション が行われる可能性の高い別個のマシンへ情報を転送するコストを低減すること、後続 処理が行われ得るグラフのサイズを低減すること。 また、この 操作を行う際、前記DAGは自然にセグメント化されてローカス ノード、 その 文脈およびそのサブ構造に分割されるため、任意の点において探査を一対の ツリーとして提示することができる。 この 表現は、前記オーグメンテーション 操作にも有用であることが分かる。 しかし、 DAG低減を避ける実施形態も可能である。 このような実施形態においても、DAGを通じたナビゲートが可能になり、ローカスからおよびローカスへの円弧に基づいた文脈およびサブ構造の相当する観念があり得る。
【0090】
[0325]DAG Dagの場合、任意のエンティティ E について、Dagにおいて到達可能な EからもDagにおいて到達可能なE からも到達できない任意のノードが除外される点においてDagと異なるように、「オリジナルの 文書」上において利用可能なDAG Dag１Eを定義する。
【0091】
[0326]図25 は、ノード 1においてセンタリングされたナビゲーションによる低減（すなわち、Dag11）後の図24からのDAG Dag を示す。図32は、ノード 5（すなわち、Dag15
）においてセンタリングされたナビゲーションによる低減後のDag（すなわち、「オリジナルの 文書」上において利用可能な画像）を示す。
【0092】
[0327]ローカス ノードを設けることならびにその 祖先および子孫をスキャンおよび包含することにより、Dag1EをDagから得る。 多数対多数の関係により、コンピュータ アルゴリズム分野の当業者に公知のように任意の共通の 子孫を 複数回包含する事態を回避するよう、訪問された ノードの データ構造を維持することが必要である。 図43は、この ルーチンを示す。
【0093】
[0328]（特に補助 情報を同時に収集する際に）極めて大型であり得るDAG全体を必ず処理するのではなく、 実施形態において、深さ、 必要な累積的保存または他の任意の 機構に基づいて制限がかけられ得る。 ユーザが前記階層により深く進む必要がある旨を示した場合 ( 局所的DAG の構築が停止している任意のノードからより多くのサブ構造 または文脈をリクエストした場合)、 さらなる ノードが前記サーバによってフェッチされ得る。 前記クライアントへ送られた局所的DAG 構造において、 信号 値が延ばされた各論理 ツリーの子のリストの定位置に挿入され得 (サブ構造中の詳細化されかつ関連する従属的エンティティおよび前記文脈中の詳細化されかつ関連する独立的エンティティ)、 あるいは、情報 がサーバから検索されていない前記局所的DAGエンティティ中にダングリング 参照を残留させてもよい。
【0094】
[0329]これは、制限に到達したときに前記サーバにDAG のスキャンが停止される各ノードとの 継続部を保存させ、この 継続部を前記クライアント が前記DAGの当該部分のスキャンを再開することが可能なURLと関連付けることによって実行され得る。しかし、このような継続をユーザによって維持する以外にも、多数の実施形態において、前記継続の自由変数値（恐らくはスキャンを停止するエンティティを含む）をクライアントに提供させることにより、前記DAG のスキャンを再開することが好まれ得る。この アプローチにより、サーバに全子孫（前記クライアントの 局所的DAG中に既に常駐するものを含む）をフェッチさせる事態を回避するために、前記クライアントは、さらなる 情報のために当該情報を そのリクエスト と共に送る必要がある。
【0095】
[0330]適用において深さ制限を固定する代わりに、実施形態において、 エンティティ 情報への初期 アクセスをリクエストする前記クライアントから送られたパラメータとして深さ制限を設定することができる。
【0096】
[0331]詳細化関係が 多数対多数である場合、 いくつかの実施形態において、詳細化するエンティティの前記多様な 提案された親間の間接的 詳細化を確認することにより、間接的詳細化関係付けが既に存在しているのに 直接的詳細化関係付け が 生成される状況を回避することが望まれ得る。 他の 実施形態において、これらの定位置を回避するためには、新規詳細化関係付け（これは、潜在的に 高コストな操作 (特に、段落０３２８に記載のように局所化 時にDAGに深さ制限がある場合)である ）の生成時に既存の 詳細化の確認が必要であるため、これらの定位置が残り得る。
【0097】
[0332]あるいは、これらの冗長な 関連付けを形成した後、別個のパスでまたは例えばReduce DAG 0210時に特定および除去することも可能である。 長さ１ の詳細化 経路を特定および除去することが望まれ、ここで、より長い詳細化 経路が同一エンティティ間に存在する。 詳細化 サブ構造を降下し、調査されている詳細化対象ノード の各兄弟をその含まれる詳細化関係付けへマッピングする際に、関連付け リスト または ハッシュテーブル を累積的に保持できれば充分である。前記ディクショナリ中のエンティティに遭遇した場合、対応する 関連付けを冗長なものとして安全に除去することができる。もちろん、文脈スキャン時に類似の手順を用いてもよい。スタンドアロン バージョンを図44に示す。
【0098】
複数同時詳細化[0333]
まず、段落０３１９に示すような実施例から始める。ユーザは、再度あるノードへのナビゲートを行い、結果得られたサブ構造または文脈からノードを選択し（ただし、いくつかの実施形態では、この選択を適切なサブ構造に限定していてもよい）、そして、もし可能であれば、ユーザはこの新規ノード（およびエンティティ）を選択したノード（エンティティ）を用いて詳細化親として定義する機会を与えられる。再び、ノード選択に対する正確な制約は、実施形態によりなされた選択肢に依存しうるが、選択されたノードは、同種と見なされ、対象の子として同じ種類と見なされる。以下では、具体的にこれら対象の親（parentNode）のうちの１つから動作が開始されると仮定しているが、選択の開始は、どのように行われてもよい。
【0099】
[0334]各従属的なエンティティと、識別された独立的なエンティティとを対応付けする良い理由がある場合がしばしばあり、例えば解決法が問題に対して対処するものとされていたり、または賛成または反対の議論が解決方法に対して対処するものとされているなどがある。このようにすることは、アドレス、賛成、または反対などの導出された関係は、多数対一であり、例えば、１つの問題には多数の解決法案があるが、各解決法が対処するものとされているのは１つの問題のみである場合を含んでいる。
【0100】
[0335]もし詳細化関係（例えば、直接詳細化解決法（directlyRefinesSolution））が多数対多数である場合（よって、複数の継承をサポートする場合）、それが従属する種類（例えばアドレス）であるクロス種類関係は、それが生成された任意の関係（直接対処（directlyAddresses）)が多数対一であったとしても、詳細化済みの解決法が、それぞれ詳細化対象解決法が対処する必要がある、異なる問題に直接対処する可能性があるので、多数対多数であるかもしれない。
【0101】
[0336]よって、任意の（直接指定された）クロス種類関係が多数対一であり、各エンティティに、それに関連する識別された独立的なエンティティを、導出されたクロス種類関係で割り当てたい時にさらに懸念が生ずる（段落０３０８および段落０３１０と同様）。特に、本来そのような独立的なエンティティに直接クロス種類対応を介して割り当てられないのに、そのような割り当てで従属的なエンティティを詳細化する従属的なエンティティの場合、独立的なエンティティの様々なオプションがある。
【0102】
[0337]しかし、また、これらオプションを制約にて限定する良い理由がある（段落０４０７を参照、または段落０３４５のGLBの算出における優位点を参照）。独立的なエンティティを新たな従属的なエンティティに、従属的なエンティティが１つ以上の既存の従属的なエンティティを詳細化するクロス種類関係下で割り当てる際に、実施形態は、各詳細化された従属的なエンティティについて、独立エンティテの任意の詳細化祖先が同じクロス種類関係にて、その従属的なエンティティの詳細化祖先に直接関連付けされ（ダイレクトオブジェクトとされて）、新たなクロス種類関係といくつかの既存の、詳細化されたもの（例えば詳細化された問題に対処するものとされている解決法）との間の対応関係を示していることを必要とする構成であってもよい。いくつかの実施形態は、各詳細化された従属的なエンティティについて、独立的なエンティティの任意の祖先（詳細化でなくてもよい）が同じクロス種類関係により直接その従属的なエンティティの祖先（詳細化でなくてもよい）に関連付けされている（ダイレクトオブジェクトとされ）ている。これらの変更点を考慮すると、制約を満足するプルーフを有効にする下記に記載のルーチンは、場合によっては、詳細化パスを要求するより任意のパスを提供することを確認する。他の実施形態では、さらに進み、各詳細化された従属的なエンティティが独立的なエンティティと同じ祖先を有することのみを要求する構成であってもよい。
【0103】
[0338]ユーザが、対象のノードへのナビーゲト（恐らく従属的なエンティティノードの祖先は詳細化されている）を行い、例えば、サブ構造を介してこれらノードを探査する際に、現在のサブ構造、または文脈ツリーを、効率的なトラバーサルガイドとして対象として残して残す場合がある。ある実施形態では、この記録を、独立ノードを新たな従属ノードに割り当てるためのポリシーを作成する際に利用することができる。または、これをする代わりに、サブ構造を共通の子孫のサブDAG（subDAG）について、または文脈を共通のサブDAGについて探査を行ってもよい。しかし、非効率であることに加え、共通の祖先がない場合や選択できるものが複数ある場合があるので、これは満足のいくものではない。ツリーを使用することで、サブ構造における共通の祖先、文脈ツリーにおええる共通の子孫へのアクセスを少なくとも確保できるが、その逆はなく、また必要な詳細化の祖先と子孫すべてを介する必要もない。「複数の逆ツリーの共通文脈の提示」に記載の技術を用いて異なるローカスノードの共通の祖先は文脈において明らかにされてもよく、サブ構造における異なるローカスノードの共通の子孫を「複数のツリーの共通サブ構造の提示」に記載の技術を用いて明らかにしてもよい。よって、祖先は、ＰＡＲＡ０３３７の制約を満足させるためにサブ構造または文脈の何れかに配置されてもよい。
【0104】
[0339]従属的なエンティティは、できるだけ一般的に適用されるのが好ましく、例えば、それぞれ、できるだけ一般的な独立的なエンティティに対応付けされるのが好ましい。よって、実施形態としては、詳細化従属的なエンティティを、各詳細化された従属的なエンティティに対応付けされた独立的なエンティティにより詳細化された単独の最も詳細化されたエンティティ、つまり、ユーザのナビゲーションに対する詳細化された従属的なエンティティのオブジェクトの最小上界（LUB）に対応付けされるのが好ましい。実際、ソリューションは、例えば、ある程度、それが対処するものとされた問題の詳細化された祖先の何れかに、ある程度、関連している。
【0105】
[0340]例えば、図２４のDAGを考えてみる。ユーザがノード１へのナビゲーションを行た後、DAGは、ユーザがノード１へのナビゲーションを行った後、DAGは、図２５のものにまで減少される。図２７にユーザがノード４および１０に探査をしているところを示す。ユーザが、図２８に示すように、ノード４および１０に対して新規ノード１３で詳細化を行った場合、結果得られるグローバルDAGは、この実施形態では、図２９に示すようなものとなる。識別された独立的エンティティは、段落０３３９のように割り当てられ（段落０３３４参照）、ノード１は、ノード３および６の最小上界として新規ノード１３に割り当てられる。もし、代わりに、ノード３および８が詳細化された場合は、２が新規ノードにノード３および６の最小上界として割り当てられる。
【0106】
[0341]新規詳細化対象ノードへ詳細化済みノードのLUBを割り当てる実施形態では、ユーザがローカスノードへの注目していることを知って、どの独立的エンティティを新規従属的エンティティに割り当てるかの決定に利用するのが困難でありうる。文脈において詳細化済みノードのオブジェクトが現れる場合、ローカスノードを優先したい場合は、このようにすれば、効果的に新たな詳細化対象ノードにローカスノードのGLBと詳細化済みノードのオブジェクトのLUBを割り当てることができる。
【0107】
[0342]最大下界（GLB）の自然な代替物は、詳細化対象の従属的エンティティによりマッチしたものを提供する場合があり、よって、いくつかの実施形態では、好ましいとされ得る。よって、LUBの算出は、一般化の議論に委ねられる。例えば、各解決法が異なる問題に対応し、それが解決する如何なる問題も詳細化されることを望んだり、各引数が異なるオブジェクトに賛成または反対し、それが対処するものとされている如何なるオブジェクトもリファインされることを望むかもしれない。残念ながら、段落０３３８において示されるように、サブ構造ツリーが提供する最大下界へのアクセスは非常に限定されたものである。継承を組み込むことで、より一般的な解決法を提供し得る。
【0108】
[0343]また、GLBを従属的エンティティの間接的オブジェクトの設定に使用すると、段落０３４１のものと対応する、つまり、GLB入力を広げて、ローカスノードを含むようにするか否かについて、（詳細化対象の、文脈における、オブジェクトの全てを詳細化すると仮定して）より自然な決定が導かれる。もしローカスノードが従属的ノードの場合、GLB入力を広くして、ローカスノードのオブジェクトを含むようにすることも可能である。いずれを行っても、ユーザがローカスへのナビゲーションをしたことの有意性を関連性の信号として認識する。
【0109】
[0344]上記独立的エンティティを従属的エンティティに割り当てを行うための最大下界は、（例えば、直接詳細化解決法（directlyRefinesSolution）の場合)もし唯一のものがあるなら（つまりアドレスにより解決法に関連付けされ、他の同様の問題を厳密に詳細化する唯一の問題があるなら）、アドレスにより解決法に関連付けされた問題から最も特定な問題を選択することで、または、もしクロス種類関係（直接詳細化問題（directlyRefinesProblem））により生じた種類についての詳細化関係が、多数対多数の場合、（自動的に共通の従属的問題を導出し、詳細化解決法を直接それに対処するものとすることで）１つ生成することで実現できる。素朴な実施形態では、詳細化される従属的エンティティに対応付けされた様々な独立的エンティティ間で両方向に詳細化を確認する構成であってもよいが、これは非効率的であり得る。他の実施形態では、このコストを、ユーザに問題を選択または生成することを可能にして、システムに他の対処するものとされた問題を実際に詳細化することを承認させることで、削減しているが、ユーザにこの複雑な操作をさせることになる。本明細書で提供される技術は、このコストを削減し得る。
【0110】
[0345]サブ構造および文脈ツリーに対し、GLBとして、新規詳細化多少の従属的エンティティに関連付けする独立的エンティティの算出を説明する。詳細化対象の従属的エンティティがサブ構造（全ては適切な文脈からのもの）から選択されていない場合、段落０３３７の制約を強制する実施形態では、LUB（逆文脈ツリーでは、ツリーに関するLUBの算出0101を用いて得られるLUB）が存在するなら、そのLUBのオブジェクトを新規詳細化対象ノードに安全に割り当てをし、ない場合は、フェイルすることができる。しかし、好ましい実施形態では、このステップを省略し、単にローカスノードを、段落０３４３毎に使用する構成であってもよい。または、サブ構造から選択された、詳細化対象の従属的ノードがある場合、それらがサブ構造のGLBを有するなら、段落０３３７の制約を強制する実施形態では、新規詳細化対象ノードにGLBのオブジェクトを安全に割り当てることができる。詳細化対象の従属的ノードが同じオブジェクトを有するなら、実施形態を、そのオブジェクトを新規詳細化対象ノードに割り当てる構成としてもよい（このステップは、効率を向上させ得るが、下流のステップでカバーされているので、省略することもできる）。そうでない場合（または、このアプローチに直接移行することを好ましいとする実施形態では）サブ構造または文脈ツリーにおいて詳細化される従属的ノードのオブジェクトの存在を利用して、サブ構造と文脈ツリーに関するGLBの算出１１１１を用いて、それらをGLBについて確認する構成としてもよい。明示的なサブ構造と文脈ツリーに関する詳細化済みノードのオブジェクトのGLBの算出３１２１を図４６に示す。この代わりに、全ての詳細化されたノードが文脈にあり、ブランチを反転させているか確認するという実施形態にしてもよい。そうすることは正しいが、適切な文脈からのローカスとノードのみを詳細化する場合、若干効率性が落ちる。
【0111】
[0346]サブ構造と文脈ツリーに関するGLBの算出１１１１では、その入力がノードリストに到着しすると仮定し、最初に全てのメンバーがサブ構造または文脈の何れかにあることを確認し、そうでない場合は、フェイルする。サブ構造にいずれかのノードがある場合は、クライアントは、ツリーに関するGLBの算出０１１１を用いてサブ構造ツリーに対してそのGLBを算出し、適切な文脈のものを無視する。全てのノードが文脈ツリーにある（そして、ローカスを用いて反転させていない）場合は、ツリーに関するLUBの算出０１０１を用いて反転文脈ツリーに対してLUBを算出する。いくつかの実施形態では、上記に示すように直ぐにフェイルにする代わりに、より徹底的なサーチなど、他の手段によりDAGにおいてGLBの検索を試みる構成であってもよい。
【0112】
[0347]一本のツリー（サブ構造または文脈）に対するLUBまたはGLBを算出する基本的なルーチンを示す。各ケースにおいて、詳細化パスのみに注目する！LUBは、各ノードからローカスノードに向かう詳細化パス（左から右）を考慮し、これらパスの共通の拡張子の最も左のノードにより代表されるエンティティを選ぶことで得ることができる。このアルゴリズムを図４８に示す。GLBは、各ノードからローカスノードに向かう詳細化パス（左から右）を考慮し、全てのパスが１つの最も長いパスの拡張子であり、最大下界がその最も長いパスの最も左のノードであることを確認することで得ることができる。このアルゴリズムを図４９に示す。
【0113】
[0348]段落０３１９の例におけるGLBにて新規ノード１３に割り当てられる独立的ノードは３である。
【0114】
[0349]このアルゴリズムを使用するクライアントが独立的エンティティの従属的エンティティへの合理的な割り当てを得るとき、サーバが、全てのクライアントがこれらのルールでプレイしていると信用できず、よって、例えば、特定された各エンティティのオブジェクトが、自身も新規ノードの提供されたオブジェクト（差し当たり、全てのそのようなオブジェクトの見なしGLB）により特定され、よって、新規のノードのオブジェクトは、少なくとも詳細化されたノードのオブジェクトの下界になることを確認することを望む構成であてもよい。しかし、そのような詳細化の対応のチェーンの確認は、非効率的とされるかもしれない。よって、サーバーが、新規詳細化対象エンティティから既存の詳細化済みエンティティへの各対応関係を確立する前に、特定される各従属的なエンティティについて、詳細化（具体的には、最も特定なものから、最も特定でないものを仮定）により関連付けされたエンティティの、新規ノードのオブジェクトから特定されるその従属的エンティティのオブジェクトまでのチェーンの形式でアシスタンスを必要とする構成であってもよい。もちろん、シーケンスの順番は慣習のものによる。そのようなチェーンは、プロジェクト構造のツリーに基づくエクスポジションを用いて提供することができる。詳細化される各ノードについては、クライアントは、いくつかのケースの１つに基づいてパスを構成することができる。サブ構成において詳細化されるノードのGLBとオブジェクトの両方については、クライアントは、ノードが詳細化されるノードにおけるエンティティのオブジェクトにたどり着くまで、詳細化の後を追いながらGLBからサブ構造ツリー介して上方にパスを辿る。サブ構造のGLBと文脈において詳細化されるノードのオブジェクトについては、ローカスまで上記パスを辿り、その後パスの反転をオブジェクトノードから始まって、反転文脈ツリーを遡り、ローカスに達するように連結することができる。（段落０３４２に示すように）GLBの算出においてローカスノードを含むことを暗示していない実施形態では、文脈にGLB（およびオブジェクトノード）のケースを加えたり、そのような場合に、オブジェクトノードから開始し、反転文脈ツリーをGLBに達するまで遡ることで得られるパスの反転を使用する構成であってもよい。このケースの追加しないプルーフ作成プロセスの一実施形態を、図５９のプルーフパスの生成０１１３を用いて図５０に示す。一例では、ユーザがノード４および１０を詳細化する場合、本実施形態のプルーフは、４個の場合、GLBから、３、それ自身までのパス、オブジェクトの４つ、１０個の場合は、GLBから、３、１までのパス[２、１]、オブジェクトの１０からなる。なお、慣習により、最初のノード（それぞれ、３および１）を暗示のものとして扱い、パスには含めていない。クライアントは、サブ構造や文脈ツリーの現状により、正しい検証を作成できない場合がある。
【0115】
[0350]これらのピースを集めて、クライアントは、DAG拡張のアトミックな明示的特殊化１１４１を使用し、１つの新たなノードを、既存のノードの詳細化として生成することができる。図４５は、詳細化されるノードのオブジェクトのサブ構造と文脈に関して、各従属的エンティティがオブジェクト独立的エンティティにGLBとして、割り当てられるシチュエーションのシーケンスを示す。まず、詳細化される各ノードについて、詳細化により関連付けされた、そのオブジェクトから、サブ構造または文脈を介して、ローカスノードに向かう、ノードの順番を判別する（GLBにローカスノードが暗示的に含まれる暗示実施形態では、サブ構造に限定することもできる）。これは、現在のサブ構造または文脈を使用するか、もしくは以前のサブ構造または文脈から保存されたいずれかのパスを用いて行うことができる。また、ローカルのサブ構造または文脈DAGを用いてパスを生成することも可能であるが、１つ以上のパスとすることも可能である。そして、図４６に示すように、詳細化されたノードのオブジェクトのGLBを算出する。GLBが存在しない場合は、フェイルとし、エラーメッセージを出す。図５０に示すように、GLBとその詳細化パスをサーバー用のプルーフ作成時に使用する。一方、ユーザに、新たなエンティティに情報を保存するように促す。そして、サーバにアクセスし、プルーフを送って、拡張操作をリクエストする。これがフェイルした場合、部分的に作成したノードをクリーンアップする。または、クライアント情報を、新規エンティティを含むように更新する（ユーザが入力した情報とそのオブジェクトを含む新規エンティティの記録を作成し、新規エンティティを追加の子として含むように詳細化されたノードのエンティティについて記録を更新する）。サーバは、新規エンティティのデータベース識別子を返送し、該識別子は、例えば、新規ノードのＵＲＬを作成するのにクライアントにより使用されることができる。
【0116】
[0351]各従属的エンティティがオブジェクトを割り当てられているプルーフ検証プロセス（間接的オブジェクトによるDAG拡張の特定のためのプルーフの検証３２１１）を図５１に示す。サーバは、詳細化される各エンティティについて、そのパスが実際に、詳細化のチェーンのなのかを、新規詳細化対象エンティティの提供されたオブジェクト（通常詳細化されたオブジェクトのGLB）から始め、詳細化されたエンティティのオブジェクトまで、検証する。グローバルDAGを介して提供されたパスを辿り、各ステップが詳細化であることを検証する。
【0117】
[0352]直接オブジェクトのみが従属的エンティティに保存されていたとしても、それが各詳細化されるノードの上のサブ構成にある場合、または、それが文脈にある場合はもう少し努力することで、クライアントは、時に間接的オブジェクトにアクセスすることができ得る。通常は、詳細化されたノードのオブジェクトのGLBを算出する必要はないが、プルーフの生成に関するこれらオブジェクトからパスを導出する最初のステップは、各詳細化されたノードのからローカスのパスを直接オブジェクトの検索において辿ることでも実現することができる。このより一般的な場合におけるプルーフは、独立的エンティティのチェーンと、上記同様、親が独立的エンティティ（直接オブジェクト）であるものに導かれる従属的エンティティのチェーンの両方を示す必要がある。このシチュエーションのプルーフ生成プロセス、直接オブジェクトのみによるDAG増加を明示的に特定するためのプルーフの生成１１５１は、図５２に示すようなものである。このシチュエーションのプルーフ検証プロセス、直接オブジェクトのみによるDAG増加を明示的に特定するためのプルーフの検証３２２１は、図５３に示すようなものである。詳細化される各エンティティについて、サーバは、その独立的エンティティが実際には、詳細化のチェーンであることを、新規詳細化対象エンティティの提供されたオブジェクト（一般に、詳細化されたエンティティのオブジェクトのGLB）から始まり、詳細化された見なし直接オブジェクトまで確認し、その従属的パスが、実際に詳細化のチェーンであることを、新規詳細化対象エンティティから始まって、詳細化されたエンティティまで確認し、そして、最後に、詳細化されたエンティティの見なし直接オブジェクトが真正なものであることを確認する。
【0118】
[0353]異なる独立的エンティティが各従属的エンティティに割り当てられる場合、従属的エンティティに割り当てられたそのエンティティへの参照（または、割り当てられた独立的エンティティを段落０３６５のように推定することを選択した場合は、フィラー）を保存し、クロス種類対応関係を直接的に示す必要がないようにすることは合理的である。そうでなければ、エンティティのペアとしてそのような対応を直接的に示すことが望ましい場合がある。どちらの場合でも、実施形態は、上記（および下記）のプルーフと同じように、独立的エンティティへの参照だけでなく、詳細化された対応関係の対応の証拠とを記録するように選択する構成であってもよい。もし従属的エンティティの詳細化の対応関係が解消された場合は、詳細化対象のエンティティ間のクロス種類対応関係を解消できるようにするという利点があるだろう。
【0119】
複数同時詳細化による単一クロス種類増加[0354]
段落０３２０に示すような例の実施について説明する。ユーザがあるノードへのナビゲーションを行い、その結果のサブ構造または文脈からノードを選択し、クロス種類操作を特定の親ノード（ベースノード）から始める。可能であれば、ユーザには、新規ノード（およびエンティティ）を選択したノード（エンティティ）で詳細化親として定義し、ベースノードのエンティティを関連する関係の下の親（独立的エンティティ）として定義する機会が与えられる。ノードの選択における正確な制約は、下記に示すように実施形態における選択に依存してもよい。一般に、選択されたノードは、同じ種類であること、意図される子と同じ種類であること、または少なくとも種類が一貫していることが仮定される。ある実施形態、特に（段落０３４３に示すように）暗示的にGLBの計算にローカスノードを含む実施形態では、ベースノードがサブ構成にあり、選択された詳細化親が適切なサブ構成にあることを必要とする構成であってもよい。
【0120】
[0355]各従属的エンティティに独立的エンティティを割り当て、この選択を我々でするのではなく、ユーザからの命令を利用する実施形態を説明する。しかし、多くの実施形態は、段落０３３７からの制約を適用するものであってもよい。
【0121】
[0356]新規ノードのオブジェクト（GLBでなくても良い）から各詳細化されたオブジェクトまでパスについて説明する。詳細化されたノードの詳細化されたノードオブジェクトのGLBと拡張された独立的ノード（ベースノード）間の接続に関しいくつか懸念が生じる。ベースノードが詳細化されたノードオブジェクトのGLBを詳細化する場合、ベースノードから各詳細化されたノードのオブジェクトまでのパスを保証し、段落０３３７の制約を満足するが、逆にそのような証拠がない場合、その制約を満たさなくなる恐れがある。そして、もしベースノードが、詳細化されたノードオブジェクトのGLBと同じだけ詳細化されなかった場合、詳細化が実際には、必要なものとは逆の方向に向かって行われるというシチュエーションを生ずることなく、新規のオブジェクトをベースに向かって設定することができない。この点をより分かり易く説明する一例を挙げる。図５４に、問題ノード５１におけるナビゲーションを伴うDAGを示す。ユーザがその子問題ノード５２を、解決法ノード５４を特定した新規解決法ノード５５にて解決しようとする場合、５２は、詳細化されたノード５４の自明なGLBである５３の親だとすると、シチュエーションは、図５５に示すようなものになる。台形を平たくして四角形にすると、２つの詳細化が反対方向に向かっていることがよくわかる。しかし、いくつかの目的においては、この反変関係は、共変関係の代わりに好ましい場合がある。共変的制約を適用する実施形態は、ベースノードが詳細化されたノードオブジェクトのGLBを詳細化するように見えない場合、その特定のベースノードを無視するか、このシチュエーションをシンプル詳細化として取り扱うか、もしくはこれをユーザエラーとするか選ぶ構成であってもよい。他の実施形態では、どの場合でも操作を許してもよい。制約を適用するため、GLBの計算を上記のように行うことができるが、結果はベースノードに対して比較される。
【0122】
[0357]サブ構成または文脈における２つのノード間のパスを特定するルーチンを図５９に示す。ここでは、詳細化対象ノードおよび詳細化済みノード間で求められるパスについて言及するが、これらの名称は他の使用に対して何の関係もなく、特にユーザにより特定、または一般化するノードに関係はない。もし、詳細化対象ノードが適切な文脈にあり、詳細化済みノードが適切なサブ構成にある場合は、すぐにフェイルとなる。詳細化済みノードおよび詳細化済みノードの両方ともサブ構成にあるバイは、詳細化対象ノードからローカスに向かう詳細化パスを、詳細化済みノードまで辿る。もし詳細化済みノードが見つかったら、パスに戻るが、見つからなかったらフェイルとなる。りふぁリメント対象ノードと詳細化済みノードの両方が文脈にある場合は、詳細化済みノードからローカスに向かう反転詳細化パスを、詳細化対象ノードまで辿る。もし詳細化対象ノードが見つかれば、パスの反転に戻り、見つからなかったらフェイルとなる。最後に、もし詳細化済みノードが文脈にあり、詳細化対象ノードがサブ構成にあるなら、詳細化対象ノードからローカスへの詳細化パスを詳細化済みノードからローカスまでの反転詳細化パスに連結し、どちらもがローカスに達しない場合は、フェイルとする。なお、一実施形態では第１のケースの確認を省略し、詳細化済みノードがサブ構成にあるかという第２のケースと、詳細化対象ノードが文脈にあるかという第３のケースのみを必要とし、その処理においてフェイルが起こるようにするとい構成であってもよい。一般的プルーフパス０１１３を一つのルーチンとして示したが、いくつかの実施形態ではあるシチュエーションではケースの数を減らしてもよい。
【0123】
[0358]もしベースノードが詳細化されたノードのオブジェクトのGLBと同じであれば、これは冗長であり、シンプルな詳細化などの拡張を選ぶ実施形態もある。
【0124】
[0359]各従属的エンティティが独立的エンティティと対応付けられ、段落０３３７の制約が適用される場合、段落０３４９および段落０３５１に記載のプルーフメカニズムを使用できる。ここでベースノードとGLBが区別されているので、最適が可能である（これはローカスエンティティを有した暗示的GLBについても同様である）。全ての詳細化パスがベースノードから詳細化されたノードオブジェクトのGLBへの共通のプレフィックスを共有するので、このプレフィックスを分割して、生成と検証が一回のみ必要となるようにすることができる。そして、ベースノードから詳細化されたノードのオブジェクトまでのパスを得るために、プレフィックスを独立的パスに接続する。生成プルーフパス０１１３を用いた、明示的なクロス種類と、間接的オブジェクトによるDAG拡張の特殊化のためのプルーフの生成１１１２によるこの形のプルーフの生成を図５７に示す。間接的オブジェクトによるDAG拡張の特殊化のためのプルーフの検証３２１２によるその検証を図６０に示す。
【0125】
[0360]もし代わりに(段落０３３５の例の）直接対処（directlyAddresses）が多数対多数または、実施形態にそれを多数対一に拡張する意図がなく、オブジェクトを従属的エンティティに、段落０３３４に示すように割り当てない場合でも、詳細化問題（refinesProblem）の適用を介して他のものに達するには十分な対処（addresses）を介して関連した問題のサブセットを識別することを望ましいとする。独立的エンティティを識別することがなかったとしても、実施形態を、そのような「敬意を払う」対応関係を特殊化することを可能にする、例えば、対応関係を従属的エンティティ（B）と独立的エンティティ（A）との間のクロス種類関係下に形成できるようにして、（B）が、（A)により詳細化される独立的エンティティと対応関係にある他の従属的エンティティを詳細化するような構成としてもよい。特に、直接対処（directlyAddresses）を介して対応付けを可能にして、他のそのような対応関係を活用し、前者の解決法と問題が後者のそれらをそれぞれ詳細化するようにすることができる。同様に、直接動機付け（directlyMotovtedBy）を介して対応付けを可能にして他の対応関係を活用し、前者の問題と解決法が後者のそれらをそれぞれ詳細化するようにすることができる。また、どのようなクロス種類関係も従属的エンティティに他のエンティティを詳細化することを許すのは、従属的エンティティの、ある詳細化祖先が独立的エンティティの詳細化祖先に関係する場合のみとすることもできる。プルーフを使用して説明したアプローチは、従属的ノードのオブジェクトを、ローカスへのパス上の詳細化対応付け後の第１クロス種類対応関係の独立的エンティティとして考える限定的な形の必要条件をサポートする構成であってもよい。
【0126】
[0361]このケースでは、段落０３５９のそれに加え、段落０３４９のプルーフ構造に対する他の変形例が好適である。ここでプルーフは、ベースノードからGLBへのプレフィックスパスの形態をとり、各詳細化される従属的エンティティについては、従属的エンティティからのものと、GLBからのものとの２つの詳細化パスの形態をとり、それぞれ同じクロス種類関係により順に対応付けされたエンティティで終わる。独立的パスの計算も図５９を使用する。サブ構成における詳細化されたノードについては、従属的パスはローカスノードに向かう詳細化チェーンというだけのものである。プルーフ生成プロセスは、図５８に示すようなものとなる。段落０３２０の例については、いくつかの実施形態のプルーフは、２対のパスであり、それぞれ詳細化された各ノード用である（もし間接オブジェクトが利用できるなら、独立的（問題）パスのみを提供すればよい）。ここにおける各ケースにおいて、詳細化された解決法ノードからローカスノードに向かう解決法詳細化ヒエラルキーを辿ることと、オブジェクト問題を止めることで、現在の操作により生じた新規詳細化対象問題／解決法ペアに対応する詳細化された問題／解決方法ペアが生ずる。ノード４については、この実施形態の従属パスは、独立的ノード３と直接対応付けされているので、空であり（その間に詳細化された解決法がない）、この実施形態の独立的パスは、が新規ノード１６のオブジェクト５からオブジェクトの４に達するには１ステップのみが必要なので、[３]である。ノード１０については、この実施形態の従属的パスも[６、２、１]であり、これはこれらのノードを新規ノード１６のオブジェクト５から辿り、オブジェクト１０の１に到達するからである。なお、慣習に従い、最初のノードを暗示的なものとし、パスには含めていない。
【0127】
[0362]１つのクロス種類の取扱いのステップおよびDAG拡張の特殊化のステップは、図４５のDAG拡張のアトミックな明示的特殊化１１４１と同様である。違いは、間接的オブジェクトによる明示的クロス種類のプルーフ作成およびDAG拡張の特殊化１１１２、直接的オブジェクトのみによる明示的クロス種類のプルーフ作成およびDAG拡張の特殊化１１３２、およびクロス種類DAG拡張３２０２を含む、クロス種類および特殊化拡張をサポートする意図がある上記のルーチンの使用する点、および対応する詳細化操作（例えば、特殊化されたノードの種類のもの）に変換するステップを、もしGLB（図４６で算出されたもの）がベースノードと同じである場合に、追加する点にある。変換する可能性があるため、間接的オブジェクトによるDAG拡張の明示的な特殊化のプルーフの生成１１３１と、DAG拡張の特殊化３２０１を可能性のあるステップとして含む。このルーティンを図５６示す。
【0128】
[0363]直接オブジェクトのみによるプルーフ検証プロセスは、図６１に示すようなものになる。サーバは、詳細化される各エンティティについて、新規詳細化対象エンティティの提供されたオブジェクトから始まる独立的パスが、詳細化されｔエンティティから始まる従属的パスが辿る先のエンティティのオブジェクトに辿るかを確認する構成であってもよい。
【0129】
[0364]どの様な実施形態も上記のような検証を必要とし得るが、他の実施形態では他の手段の検証を行う構成であってもよく、検証を完全に省略してもよい。
【0130】
[0365]なお、段落０３６２に示すように、いくつかの実施形態では、割り当てられた独立エンティティが実際にはGLBである場合に正式な詳細化操作を使用するのみである構成であってもよい。よって、従属的エンティティの詳細化は、詳細化される従属的エンティティの対応関係（のGLB）に基づいた独立エンティティと対応付けさていてもよい。この独立的エンティティを従属的エンティティと共に保存しても、必要に応じて算出してもよい。明示的に保存されている場合、この情報は、すぐに利用可能であるが、いくつかの実施形態では、独立的エンティティとして保持され、詳細化の対応関係が追加、または解除される必要がある。
【0131】
特殊化のための継承の活用[0366]
実施形態では、独立的ノードの詳細化チェーンを介して従属的ノードに根を有する構造の継承を活用することで多くの利点を享受することができる。そのような構造は、関係している可能性が高いとき、ユーザに対して提供することができる。そのような継承された構造をユーザが見ることができるだけでなく、拡張することができ、そうすることで、ナビゲーションの現状に対してそれを特殊化することができる。
【0132】
[0367]図６２は、継承をサポートする一実施形態による図４２のバージョンである。クライアントの拡張プロセスは、継承されたノードのコピーと、ノードの祖先を介して継承されたパスをコピーするルーチンとを組織的に行う高レベルのルーチン（クライアント特殊化DAG拡張２１０１およびクライアントクロス種類および特殊化DAG拡張２１０２）を含む。サーバーの開始プロセスは、縮小DAG０２１０と、交互に新たなルーチンの継承収集２２４０および継承保存２２５０を行って、ユーザの文脈から継承されるノードを収集しローカライズされたDAGにそれぞれ組み込む新たなルーチンの構造継承２２３０とを利用する高レベルルーチンのローカライズDAG２２００を始める。
【0133】
DAG探査への継承の活用[0368]
いくつかの実施形態では、継承された従属的エンティティがローカスノードのサブ構造に現れることができるようにする。継承された構造は、実際にはサブDAGであってもよく、これら継承された構造は何らかの対応関係を介してサブ構造のネイティブ（非継承）ノードに接続されていてもよい。そのような継承後、結果得られるDAGを、続けてツリーとして探査される構成であってもよい。
【0134】
[0369]図６３は、ルーチンのローカライズDAG２２００を示す図である。まず、DAGをDAG０２１０を用いて縮小し、一部のノードとそのサブ構造と文脈のみを含むようにし、そして構造継承２２３０を用いて文脈から構造を継承する。
【0135】
[0370]一実施形態では、さらにDAGの変形例を使用する。DAG2EがDag1Eと異なる点は、Eにより継承されたEエンティティの子、例えば、Eにより詳細化されたエンティティに基づくエンティティとして含まれている点のみである。
【0136】
[0371]図２６に、継承されたノード９、１１、１２および１５、すなわちDag21を含む構造を有する状態の図２５からのDAG Dagを示す。図３３は、継承されたノード４、７、８、９、１０、１１、１２および１５、すなわちDag25を含む構造を有する状態の図３２からのDagを示す。リンク１０から１は、下記の段落０３７５の終わりに示すように、図２６から接続している。
【0137】
「0372]次に、Dag1EからのDag2Eを得ることを考える。ローカスノードについて、各継承されたエンティティに対して、継承収集２２４０、次に継承記録２２５０を呼び出し、親Iｄを子Idに対して設定する。図６４にこのルーティンの一般的な構造を示す。例えば、もしローカスノードが問題であれば、ローカスの問題により詳細化された問題の解決法を収集し、記録する。なお、構造継承２２３０を全てのクロス種類関係に対して作用するように示しているが、実施形態では、継承が行われる各関係に対してそれぞれバージョンを作成する構成であてもよい。
【0138】
[0373]直感的に、継承収集２２４０は、最も一般的な（詳細化された）継承されたエンティティを継承のために収集するのみであってもよい。これは、より特殊化したものがこれらエンティティの継承可能な子孫の記録プロセスで含まれ得るからである。継承収集２２４０と継承記録２２５０の最初の実施は、この直感的アプローチに基づく。
【0139】
[0374]継承収集２２４０は、エンティティの詳細化祖先を走査する。これは、共通の祖先を２度カウントすることを回避することを含む。走査時に、継承可能なエンティティを段落０３０８に定義するように収集し、それらに到達できる最低限の根を保持する。これは、各遭遇した継承可能なエンティティが既に収集したものを詳細化するか否か、またはその逆を確認することを含む。なお、上記したように、継承されたエンティティが他の継承されたエンティティに包含される（つまり、右側の他の継承されたエンティティの左側に現れる関係である）場合、このアルゴリズムは、両方を（継承収集２２４０により返された包括エンティティを介して）含む。いくつかの実施形態では、このケースの包括されたエンティティのみを（この包括されたエンティティを送り返す継承収集２２４０によって）含むように選択する構成であてもよい。なぜなら、包括する継承されたエンティティは、しばしば無関係であるかもしれないからである。これは、継承されたエンティティの根よりリーフを保持することで達成できる。オリジナルの方法の優位点は、詳細化対象のエンティティからの新たな代替の派生物を生成する可能性を残している点である。図６５にこのルーティンを示す。なお、一部の制約下では、上記包括された／包括対象のエンティティを詳細化対象／詳細化済みエンティティで置き換えることができる。
【0140】
[0375]継承記録２２５０は、収集した継承されたエンティティとその子孫をDag2Eに組み込むことを含むが、このプロセスは、既にDag1Eにあった子孫があると停止する必要がある。継承記録は、継承されるノードを受け取り側のエンティティの子として追加することで始まる。継承されたエンティティが既にDag2Eにある場合も、初めて遭遇する場合もある。もし初めて遭遇する場合は、それをその親元へDag2Eに追加し、その子を続ける。または、この親をDag2Eエントリに加える。始まると、このプロセスは、ローカスノードの直近の子を、たとえそれらが継承されるノードから到達でるとしても、所定の場所に残す。この増井実施形態では、このようなノードを接合させ、継承されたノードを介してより長いパスでのみ到達可能にする。このルーティンを図６６に示す。
【0141】
[0376]解決法詳細化を介して継承されたスキル条件の場合、継承記録２２５０は些細なものとなる。これは、段落０３１１に記載するように、スキルのサブスキルではなく、スーパースキルがそのスキルを必要とする解決法の詳細化には必須である。よて、継承記録２２５０により実施されるサブスキルを介した下向きのトレーシングは必要ではない。それゆえ、解決法により継承されるスキルは、単に孤児の継承ノードのとして解決法に付されたものであってもよい。プロジェクトのヒエラルキとして、同じDAGにおけるサブスキルヒエラルキを提示することで得られる洞察は少ない。
【0142】
[0377]ノードがそれぞれを詳細化するかをチェックすることは非効率的な場合があり、よって直感的アルゴリズムがこのようなチェックを回避するよう様々な方法で変形できることは望ましい。これら、強化されたアルゴリズムのそれぞれにおいて、最も一般的な継承エンティティをフィルターするために継承収集２２４０を必要とはしないが、直接的に継承可能な全てのエンティティを返送する。そのようなエンティティの順番を固定し、継承記録２２５０がそれを最も一般的なものからの順番、または最も特殊化したものからの順番として処理することができるようにする。
【0143】
[0378]図６７に、継承可能なものがリストされたシーケンスが、ローカスノードから、例えばより特殊化した所からより一般的な所へ進む詳細化パス上のそれらの継承元のノードの位置と一致するかを確認する継承収集２２４０のバージョンを示す。反復を有するプログラミング言語では、これは順序付けツリートラバースとして実施することができる。よって、継承記録２２５０がこれらより浅い位置にあるエンティティの継承可能な子孫を含み、そしてより深い位置にあるエンティティの継承可能な子孫を含むことを予期してもよい。前者の子孫が後者に含まれることも可能である。そのような既に形成されたノードは、全く継承されていないが、オリジナル構造の一部である遭遇ノードとして扱う必要がある。よって、継承記録２２５０は、変わらずに操作する構成であってもよい。
【0144】
[0379］しかし、より良い構成とすることもできる。継承可能なものを最も深いものからの順番で記録することで（継承収集２２４０の最も浅いものからのバージョンの出力を反転させる、または、リストの最後ではなく最初に継承されたエンティティを挿入することで（図６８））、実施形態を、継承可能なエンティティが、既により増分的な方法で検出可能なように記録され、既知の場合に、継承記録２２５０の工程を完全に避けることができるように構成してもよい。実際に、様々な実施形態ではそのようなケースを確認し、継承記録２２５０を、より深いエンティティの記録プロセスでサブDAGに追加されたより浅いエンティティについて呼び出し、余分なリンクを生成することを避ける必要がある。そして、継承記録２２５０も（図７０のように）変形し、各子を繰り返して、サブDAG中のノードの有無を確認する直前まで待つようにしてもよい。反復を有する言語では、ポストオーダツリートラバーサルとして、図６７に示すようにリストの最後にエレメントを挿入して実施することもできる（図６９）。
【0145】
[0380]サブDAGを生成するローカスノードの文脈も走査する実施形態では、他の可能な最適化によりこの事実を利用して継承可能なものを同時に収集するという構成としてもよい。
【0146】
[0381]詳細化の再記述を含む実施形態では、再記述がサブDAGに追加され、再記述されたエンティティを加えることを避ける機会を与えるので、最も浅いものからの順番が好ましい。もし、より深いエンティティから記録される順番で、他の継承されたエンティティが再記述される場合、前者をサブDAGから除外する必要がある。
【0147】
[0382]継承可能なものがプレオーダの順番で（詳細化のためのフィルタリングなしで）記録された場合、継承されたクロス種類関係は多数対多数であり、同じ継承可能なエンティティが複数の詳細化パスによって到達可能である構成であってもよい。この場合、上記のチェックにより重複する記録を回避できるだけでなく、さらに効率的にするには、実施形態を、継承可能なものをセットとして返送する（よって、重複の回避は、継承収集２２４０における挿入のまえにメンバーシップを確認することで行われる）構成であってもよい。
【0148】
[0383]いくつかの実施形態では、最初の継承可能なエンティティが既にサブDAGに記録されているか否かを確認することは技術的に必要とさない（それは起きないので）。ソフトウェア開発の当業者にとって、この最初のチェックを回避するプロセスをどのように調整するかは、明らかであろう。
【0149】
[0384]図２７および図３７に図２６のツリーを示す。前者にはノード４および１０の探査を図示し、後者はノード１２および１５の探査を図示している。図３４は、ノード４よよび８を探査後の図３３のツリーを示す。
【0150】
[0385]段落０３２８に示すように、いくつかの実施形態では、DAGのいくつかの部分に延期されたアクセスを提供することを好ましいとする。そのような実施形態では、伐採（deforestation）などのソフトウェアエンジニアリングの当業者が熟知する技術を使って、
上記のルーチンを１つは文脈用、もう１つはサブ構造用の２つのルーチンにまとめるような構成となる可能性が高い。このようなケースでは、全ての継承されたノードが直ぐにユーザが利用可能になるわけではない。ユーザが、継承の収集（および詳細化された祖先と関連する独立ノード）が延期されたローカスの詳細化済みの祖先からの文脈をさらに探査しようと試みる場合、追加の継承されたノード（直接的に継承されたものと、その子孫の両方）を、継承記録２２５０におけるサーバについて説明した手順同様にクライアントのローカライズされたDAGに記録する構成としてもよい。また、ユーザに、段落０７０８に記載のように「追加」リンクを提供し、追加の継承されたノードがあることを示し、起動したら、追加のノードとその継承のローカルのDAGへのロードをトリガーする構成であってもよい。
【0151】
DAG拡張への継承とツリービューの活用[0386]
ユーザは、プロジェクト情報を示すDAGを拡張することができる。DAG（はツリーとは反対に）構造は、多数対多数詳細化関係（複数継承）、従属エンティティも１つ以上の既存の従属エンティティを詳細化するクロス種類関係、または多数対多数のクロス種類関係の何れかに起因するものであってもよい。これらはそれぞれ長所と短所を有している。
【0152】
[0387]もしユーザが、拡張対象のノード文脈のノードへのナビゲーションをした場合、ユーザは明示的にこれらノードを、上記の明示的なDAG拡張とは同様ではない方法で選択する構成であってもよい。他のケースでは、拡張プロセスの継承を活用することが可能であってもよい。
【0153】
[0388]図２４のDAGを再度参照する。ユーザがノード５へのナビゲーションを行った後、DAGは図３３のそれにローカライズされる。図３４に、ノード４および８に対してユーザが行う探査を示す。ノード４および７は、ノード５により継承を受け、ノード８は７を詳細化する。そしてユーザが、図３５に示すように、新たなノード１４にてノード４および８を詳細化すると、この実施形態において結果得られるグローバルなDAGは、図３６のようになる。本実施形態の新たなノード１４は、ノード４および８を詳細化するだけでなく、クロス種類関係を介してローカスノード５と暗示的に対応している（問題の解決など）。５は３のGLB（８のオブジェクト）なので、実施形態は、詳細化としてこれを考慮することを選択してもよい。しかし、もしユーザが、ノード５の詳細化子孫へのナビゲーションを行っており、同じ操作を実行するんら、それは、直接的なクロス種類関係として明確に記録される。ノード５での関心を示すだけで、ユーザは、ノードへの継承を介して直ぐにアクセスを与えられ、そのアクセスは、そのノードに関係するように堅調可能であり、ノード５がグローバルＤＡＧの３や６のGLBであり、如何なるサブ構造ツリーに関するものではないという事実により制限されない。
【0154】
複数同時詳細化の継承とツリー図の活用[0389]
いくつかの実施形態では、複数の同時詳細化は、ユーザが詳細化対象のノードを選択したら示されるが、そのすべてが同じ種類のクロス種類対応関係を継承しているわけではなく、継承されたクロス種類対応関係は、種類について異なっているか、詳細化対象の少なくとも１つのノードがサブ構造の１部となっている。（「ここでは「クロス種類対応関係」とは、複数のクロス種類関係は同じ従属的種類を共有する場合があるので、単に「ノード」ではない。）詳細化のために選択された全てのノードが同じ種類の継承されたクロス種類対応関係である場合、その操作を同様のクロス種類拡張として取り扱うことが好ましい。
【0155】
[0390]ここで、直接的に継承されたノードを詳細化しない継承されたノードは、詳細化に選択されないが、反復的な拡張を行う実施形態では、変更されるということを仮定する。
【0156】
[0391]再度図２６の継承されたノードを備えるローカライズされたDAGを参照する。段落０３４２に記載のように、ノード４および１０が詳細化され、異なる独立的ンエンティティが割り当てられている場合、ここではノード３は新たなノードに割り当てられており、ノード３および１の最大下界となっている。同様に、もし段落０３４２のように、ノード（７を介した）８および１０が詳細化され、異なる独立的エンティティが割り当てられている場合、ノード６は新たなノードに割り当てられ、最大下界はノード６および１となる。ノード４および８が詳細化される場合、実施形態をフェイルする構成とし、もし１つのノードが唯一存在しているなら（ここではノード５）唯一の最大下界のサブ構造を探し、１つもないなら１つ作成し、または複数あるなら１つ選択することを可能にする構成であってもよい。フェイルはまずい選択というわけではない。なぜなら、下記に示すように、ユーザは、下界としたいノードへのナビゲーションによりこの操作を完了できるからである。
【0157】
[0392]同様に、（段落０３４２同様に）GLB算出のローカスノードを暗示的に含む実施形態は、継承がある場合は、その算出からの如何なる継承ノードのオブジェクトも除外する構成としてもよい。これは、それらに割り当てられた独立的エンティティがローカスノードの詳細化祖先となり、非継承ノードにより示されるエンティティに割り当てられた独立的エンティティにより詳細化されることになるからである。好ましい実施形態は、全てのリファインされたエンティティが継承される場合（そしてそれらが直接的に継承されたエンティティを詳細化する場合）ローカスノードを詳細化対象ノードのに関連付ける構成としてもよいが、他の実施形態としてこの場合に上記計算の継承ノードを含むことを選択し、（文脈ヒエラルキが反転しているので）上記LUBアルゴリズムを用いて文脈のノードを選択する構成であってもよい。
【0158】
[0393]また、サーバについて、間接的オブジェクトが、詳細化対象の各従属エンティティについて、最大下界から従属的エンティティへの詳細化（最も具体的なものから最も具体的でないものへの具体性を仮定）により関連付けされたエンティティのチェーンを必要とすることで新たな従属的エンティティについて設定される場合、クライアントによりリクエストされた詳細化操作を検証することを好ましいとするかもしれない。上記において、そのようなチェーンがクライアントがプロジェクト構造のツリーベースエクスポジションを用いて生成できる構成を説明した。しかし、詳細化されたオブジェクトが文脈DAGの場合、必要な詳細化チェーンを生成するために、文脈ツリーにおいて、その点を明らかにしなければならない。もし継承されたノードが継承される場合、継承メカニズムと、プロジェクト構造のツリーベースエクスポジションの組み合わせを用いて必要な詳細化チェーン生成し、非継承ノードについて、最大下界から、詳細化対応関係をトレースしている間はサブ構造ツリーを介して、詳細化されるノードのオブジェクトに達するまで、または、継承ノードについては、ローカスノードに向かうパスをとり、そして、パスがローカスに達すると、グローバルDAGを介するパスと連結して、それによりその詳細化対象ノードを継承するようにする構成とすることができる。図７６のDAG拡張の特殊化のためのプルーフの１つの独立的パスの生成２１１３を用いる、プルーフ生成プロセスの変形例を図７４に示す。段落０３８８における例では、もしユーザがノード４および８を詳細化する場合は、この実施形態のプルーフは、４について、継承パス[３］であり、８については、継承パス［６］からなる（ここで、最初のノード５は、慣習により暗示的なものとなっている）。もしユーザがノード１へのナビゲーションを行い、ノード４および１１を詳細化する場合は、プルーフは、４については、空のパス（GLBから、３からそれ自身、４のオブジェクト）からなり、１１については、GLB３からサブ構造を介して１までとして得られ、独立的パス０が後に続くパス[２、１、０］からなる（最初のノード３はここでも慣習により暗示的なものとする）。
【0159】
[0394]そのような独立的パスはどのようにクライアントにより得られるのであろうか？継承収集２２４０の間にサーバにより導出され、ローカライズされたDAGと共にクライアントに渡され、トラック可能となり、最終的にサーバに返されるようにすることができる。図７１の継承パスを収集する継承収集２２４０のバージョンを説明する。これは、文脈に更に侵入し、撤退時に撤退する継承パスを維持する点で図６８と異なる。
【0160】
[0395]適正化として、実施形態は、直接的継承可能エンティティからパスに至る直接的マッピングを用いて操作せず、第１には直接的継承可能なエンティティから、継承先の独立的エンティティへ、第２にはこれら独立的エンティティからローカスからのパスというマッピングの混合物を用いることを選択する構成であってもよい。
【0161】
[0396]プルーフ検証プロセスは図５１に示すようなものである。サーバは、詳細化される各エンティティついて、そのパスが実際に、新たな詳細化対象エンティティの提供されたオブジェクト（通常詳細化されたエンティティのオブジェクトのGLB）から始まり、詳細化されるオブジェクトで終わる詳細化のチェーンであるかを確認する構成であってもよい。
【0162】
[0397]「フロー」を指定されたソースとシンクノードを備えたDAGとする。ソフトウェア開発の当業者が利用可能な一般的なグラフのRAGの表現であれば、どのようなものでもこの目的について、許容可能であるが、「ヒエラルキ構造とその文脈の表現の探査方法（A Method for Exploration of Hieratchical Structures and representation of Context Thereof)に提案されているものが挙げられる、特殊化された表現も可能である。拡張の検証には継承パスが１つだけ必要であるが、クライアントに送付した継承パスを継承フローで置き換え、ノードが幾つかの継承パスの１つにより継承されている場合クライアントが保持し、サーバが、任意のそのようなパスだけでなく、おのパスのフローも含めたプルーフを受け取るように向上させることもできる。その利点は、もしそのようなパスの全部ではないがいくつかがノード削除により妨害された場合、詳細化操作の成功の確率を最適化することができ得る点である。
【0163】
[0398]このアプローチは、継承収集２２４０に、各収集されたエンティティと共に、パスだけでなくフローを返すことを要求する。各独立的ノードと共に、継承されたエンティティからフローまでの送達可能なマップを保存する。各詳細化されたエンティティについて反復して（まだ訪問していない場合）マップを取得し、そして各マップにおいて現在のノードを各フローの前に追加する（例えば、古いフローの開始ノードを指す新たなノードでフローを作成する）。あるエンティティに２回以上達する場合、各追加時間は更に反復されないが、巻き戻しにおいて、異なる新たなフロントノードを追加する。全ての詳細化済みのノードを処理した後、それらの各マップを合成する（例えば、ドメインが各詳細化されたエンティティのマップのドメインを集合させたものである新たなマップを生成し、２階以上現れるエンティティについては、フローを合成する）。標準グラフ表現を用いて開始ノードと終了ノードが同じフローを合成するには、単にエンティティセットの集合とエッジの集合を用いる。このアプローチを図７２に示す。ここでも継承パスを使ってスタックのモデル化している。段落０３９５に記載の最適化をここでも適用する。図７６の、DAG拡張の特殊化のためのプルーフの１つの独立的パスの生成２１１３において、プルーフに含まれる独立的ノードのパスは、独立的パスを示すもしかすると空かもしれないフローに沿ったノードのシーケンスの形態（ローカスノードへのパス）、もしくは、１つのフローとして合成されてもよい２つのエレメントの何れかを取る。図５１の間接的オブジェクトによるDAG拡張の特定のためのプルーフの検証３２１１は、もし所定のフローを介する第１パスが成功しなかったら、すぐにフェイルする代わりに、別のパスを試すように簡単に変形可能である。
【0164】
[0399]継承を含み、１つの特殊化DAG拡張の処理を図７３に示す。段落０３５０のDAG拡張のアトミックな明示的特殊化１１４１と、上記図７４および図７８における継承対応バージョンを使用する点で異なる。暗示的にローカスノードをGLBに含む実施形態では、継承され詳細化されたノードを全体的に処理するのを避ける構成であってもよい。なぜなら、それのオブジェクトは文脈にあるからである。詳細化されたノードの各オブジェクトをローカスノードが詳細化し、全ての詳細化されたノードが継承される場合、いくつかの実施形態では、GLB操作のローカスノードを暗示的に含むラインに沿って、ベースノードとしてローカスノードを使当てクロス種類操作に詳細化操作を変換する構成であってもよい。詳細化されたノードの反復されたコピーや再言及はより強固な解決法をもたらし得る。
【0165】
[0400]直接的オブジェクトのみがある実施形態やエンティティの種類は、プルーフ生成プロセス（直接的オブジェクトのみでDAG拡張を特殊化するためのプルーフの生成２１２１）は、図５２からの変形例で、図７６のDAG拡張の特殊化のためのプルーフの１つの独立的パスの生成２１１３を使用して継承を取り扱うものであり、図７５に示されている。
【0166】
複数の同時詳細化による１つのクロス種類拡張の継承とツリー図の活用[0401]
多数の実施形態が継承を利用して、DAGの拡張に必要なユーザやサーバ処理への認識的な負担を減らしている。ユーザが最大詳細化対象独立的ノードへのナビゲーションを行い、それをローカスにした場合、いくつかの実施形態では、承継ノードとしては、詳細化に選択しうる様々な従属的ノードのみを考え、ローカスノードが新しく生成された詳細化対象の従属的エンティティに対する個別の独立的エンティティを示す。
【0167】
[0402]より一般的には、いくつかの実施形態では、クロス種類拡張は、ユーザがそのような拡張用のノードを選択した時に示されるか、またはすべて同じ種類の継承されたクロス種類対応関係である、詳細化用のノードを選択した時に示される。従属的エンティティも既存の１つ以上の従属的エンティティに対して詳細化をするクロス種類関係では、いくつかの懸念事項がある。
【0168】
[0403]最初にそのような対応関係を作成することを直感的かつ自然なものにする。１つ以上の既存の従属的エンティティに対して１つの従属的エンティティを定義すること、例えば、１つ以上の詳細化済みの問題の解決法に対して１つの解決法を定義する、詳細化された解決法により動機付けされた１つ以上の問題に対して１つ以上の問題を定義することは適切でありえるとし、これらのケースでは、ユーザが手動で拡張するエンティティと詳細化するエンティティの両方を選ぶことができるとしてきた。しかし、多くの実施形態では、そのような対応関係は継承された従属的エンティティを詳細化することで、直観的に編成することができるという洞察に基づいている。この技術は、直近の継承ノードだけでなく、そのノードの如何なる継承された子孫の詳細化にも適用可能である。
【0169】
[0404]従属的関係が直接的である、ローカスノードにより継承された従属的ノードの明示的な選択を単に詳細化することは妨害される場合がある。なぜなら、ユーザは、あるローカスノードにナビゲーションを行い、選択された継承済みの従属的ノードにより示されたエンティティを詳細化するだけでなく、ローカスノードと（独立的ノードとして）直接的なクロス種類対応関係を形成する新たな従属的ノードを生成するからである。
【0170】
[0405]このセクションおよび以下のセクションでは、そのような詳細化を生成する方法を提供するが、ここでも再言及と称す。「インプレース反復DAG拡張」セクションは言及の様々な実施と使用を紹介するが、その多くは、インプレース反復DAG拡張を行うことなく、適用可能である。
【0171】
[0406]継承された従属的エンティティの詳細化は、従属的および独立的パスの両方が詳細化関係をサブ構造ツリーを、詳細化対応関係を辿る限り、辿って行く。もし独立的パスがローカスノードに達すると、独立的ノードの継承パス（またはDAG）は、独立的パスに連結される。図７８は、図５７とは継承に関する手順であるDAG拡張の特殊化のためのプルーフの１つの独立的パスの生成２１１３を使用する点でことなり、図７６とは間接的オブジェクトによるDAG拡張のクロス種類と特殊化のためのプルーフの生成２１３２について異なる。段落０３８８の例では、いくつかの実施形態のプルーフは、２対のパスであり、それぞれ詳細化される各ノードの対するものである。ここの各ケースでは、クライアントが解決法詳細化ヒエラルキを詳細化された解決法ノードからローカスノードに向かって辿り、問題詳細化ヒエラルキを解決された問題（ローカスノード）から解決法が継承されたパスを介して辿る。本実施形態の独立的パスは、段落０３９３から変わっていない。ノード４については、それは直接的なオブジェクトなので、本実施形態の従属的パスは空である。ノード８については、本実施形態の従属的パスは[７］であり、直接的オブジェクトを有しない、詳細化親のシングルトンはである。慣習により、ここでも最初のノードを暗示的なものとし、パスには含めていない。
【0172】
[0407]各従属的エンティティとが１つの詳細化対象独立的エンティティと対応付けられることを必要とはしなくても、実施形態が従属的ノードが独立的ノードの拡張と共に詳細化されることができると制約することを選択してもよい他の理由がある。それは、継承との矛盾の回避である。既存の独立的エンティティに関する従属的エンティティを生成する操作および既存の従属的エンティティを詳細化する操作は、一般に、継承後の様々な関係の集合が実際には周期的なものになりうるシチュエーションに繋がり得る。単純な例では、問題に対処するものとられた解決法からの開始を考慮し、解決法により動機付けられる中、解決される問題を詳細化する問題を導入する。より一般には、詳細化対象エンティティから（クロス種類関係から）対応関係のオブジェクトを辿ることで詳細化済みのエンティティが到達可能なシチュエーションを避けることが好ましい。一方で問題のオブジェクトである解決法のオブジェクトである問題の場合、このようなシチュエーションは、クロス種類関係の偶数数の適用によりのみ起こり得る。これらは直接的オブジェクト対応関係である必要はないが、詳細化を含みえる。上記制約は、そのような循環を防止するのに十分であり、実施形態は、便利であると考えられるプロジェクト構造を除外するか否かを判定する構成であってもよい。しかし、これら循環は、問題と取られない場合がある。同じエンティティが文脈とサブ構造の両方に現れる場合がある点が変則的なだけである。実施形態は、同じエンティティに対応付けられた１つ以上のノードが同時に見ることができるのを防止するため、ヒエラルキを崩すように構成されていてもよい。
【0173】
[0408]再度これらをまとめると、クライアントは、他の既存のノードを詳細化する一方で、ベースノードのクロス種類拡張として１つの新たなノードを作成することができる。ルーチンは、図７７に図示されているが、段落０３６２に記載のものと、上記図７４および図７８の継承対応バージョンのルーチンを使う点のみ異なっている。また、GLBのローカスノードを暗示的に含む実施形態は、全体的に継承された詳細化されたノードの処理を回避することができる。なぜなら、これらのオブジェクトは文脈にあるからである。
【0174】
[0409]上記のように、ユーザは、（ローカスを含む）ローカスノードのサブ構造の継承ノードまたは非継承ノードへの拡張操作を実施できるが、ただし、もしユーザが、直接的に継承されたノードではなく、またそれを詳細化するものでもない継承ノードの拡張を特殊化した場合は、実施形態はエラーメッセージを発行する必要があるという構成であってもよい。そのようなシチュエーションは、次のセクションに提示する拡張の反復を介して対処されうる。
【0175】
DAG拡張の反復[0410]
従属関係が間接的な場合（様々な従属的なクロス種類対応関係と詳細化対応関係の合成）、段落０３８８からのプロセスを反復し、継承された構造をコピーして、各新たなノードが、生成済みのノードや最終的にはローカスノードへのリンクを維持することが可能である。複数の継承されたノードに対して共通の継承構造は、どのようなものも、一回のみコピーされる必要がある。全体の構造を再生成する必要はないが、例えば、いくつかの実施形態では、クロス種類対応関係のみを再生成することに満足し、クロス種類対応関係を大部分の詳細化対象エンティティに関係していると考慮して詳細化対応関係を省略する構成であってもよい。
【0176】
[0411]図２４のDAGを参照すると、ユーザは、一連の操作を実行することができ、まずノード１へのナビゲーションと、ノード１に対するノード９のノード９’への詳細化を行い、そして新たなノード９’へのナビゲーションと、それぞれノード９’に対するノード１５のノード１５’への詳細化とノード１１のノード１１’への詳細化を行い、１１’へのナビゲーションと、１１’に対する１２の１２’への詳細化を行い、最後に９’に戻るナビゲーションと、１１’に対する１２’と１５’の１７’への詳細化を行う。図３９のDAGは、可能性のある一結果である。ここでは、このような自動的な順序付けを如何に行うかを説明する。図２５、図２６および図３７に、ノード１に対してローカライズされたDAGを、ユーザがノード１２および１５を探査に使用できるツリーとして示すための処理の様々なステージを示した。
【0177】
[0412]この反復により、ユーザは拡張継承されたノードについて、直接的に継承されたノードではなく、また、それを詳細化しないようなものでも選択することができる。これは、そのようなノードは暗示的にローカスに接続できないので、問題であった。ローカスへのパス上の継承されたノードの進行は順次コピーされるので、ローカスへの接続は、拡張についてその都度生成される。
【0178】
[0413]図３８に、ノード１に対して対処するものとされた新たな問題ノード（１７）による問題ノード１２および１５の問題の詳細化のプロセスを示す。また、図３９に、このプロセス後結果得られるDAG全体を示す。
【0179】
[0414]一般に、新たなエンティティが、拡張された継承済みノードから子をなしていき、また究極的にはその継承を受けるノードから子をなしていくことが好ましい。図３８に示すように、実施形態では、ローカスから拡張対象のノードまでの如何なるパス上の継承構造にも対応し、詳細化する構造を生成するように構成されていてもよい。これは、ローカスからクロス種類関係により拡張されるベースノード上の如何なる継承済みノード、およびローカスから詳細化対象のノードまでのパス上の如何なる継承済みノードをもコピーすること（しかしユーザは名前変更、もしくは調整可能）を含むが、共有ノードは一度のみコピーするように注意する。継承構造のコピー後、最終ノードを生成して、詳細化対象の構造を拡張するステップを更に設けてもよい。
【0180】
[0415]いくつかの実施形態（以下に記載するものも含む）では、ユーザに、継承を受けるノードの子から始めて、拡張対象のノードをトップダウン的に定義することを勧める。他の実施形態では、ユーザに拡張対象の継承済みノードの子から始めて、拡張対象ノードをボトムアップ的に定義することを勧める。
【0181】
[0416]詳細化関係を用いてノードを拡張するとき、いくつかの実施形態では、詳細化されたノードの値を詳細化対象ノードのデフォルトの初期値として提示する構成であってもよいが、他の実施形態では、このような場合でもそのようなデフォルトの初期値を提供しない構成であってもよい。
【0182】
[0417]いくつかの実施形態（以下に記載するものも含む）では、ユーザが継承されたノードの継承された祖先それぞれを詳細化することを可能とする。他の実施形態では、拡張対象の継承済みノードの継承済み祖先のそれぞれを詳細化することを好ましいとせず、そのような祖先における詳細化の如何なるチェーンにおいても、最後の詳細化対象の祖先のみを詳細化し、異なる種類のノードとの次の対応関係に直接関わるものとする（例えば、問題に対処するものとされた解決法や、解決法に動機付けされた問題）。
【0183】
[0418]実施形態は、下記段落０４２１に示すように、継承されたノードに直接操作を行うことを可能にするが、そのような操作の実行の前に、各継承された引数の祖先について、ローカスノード下の位置を認識するためにそれらをコピーし修正するため、ユーザの新たな情報をリクエストする。または、実施形態は、継承済みのノードの再言及のいをサポートし、他の操作をサポートせず、ユーザが進行前に明示的に各引数を再言及するしかない構成としてもよい。
【0184】
[0419]なお、任意の複雑なDAG構造がローカスエンティティにより継承され、その子孫と一体化してもよいが、ユーザはローカスノードからサブ構造を探査し、拡張対象の継承済みノードに到達するので、様々な実施形態では、サブ構造がローカスノードに根を有するツリーを形成するので、これらのステップを戻ることでローカスノードに帰る個別のパスがある。
【0185】
[0420]また、第１継承済みノードは、その親とは異なるタイプであると仮定することもできる（がそうする必要もない）。これは、例えば問題が解決法の詳細化のチェーンを介して継承されるので、解決法が問題の詳細化のチェーンを介して継承されるからである。
【0186】
[0421]ここで、この反復を明示的な詳細化操作に組み込んだハイレベルなプロセスフローを提示することができる。継承済みノードのコピーの結果を保持するデータ構造を初期化することから始める。これは、どのノードも一度したコピーしたものを再度コピーすることを回避するのに使用できる。この構成では、親ノード（そこから詳細化が開始されるもの）を、クロス種類拡張用のベースノードではなく、他の詳細化済みノード（ここでは、最後の拡張の位置決めにおける使用にてのみ区別される）として扱う。また、データ構造は、新たなノードと、（まだ設けられてない場合）次に各詳細化済みノードに対して、特殊化のための継承コピー２１０３を呼び出して生成し、この構造に記録する新たなノードを介してパスを収集することで開始される。特殊化のための継承コピー２１０３を各詳細化済みノードについて呼び出す前に、そのルーチンのために、そのノードからローカスノードへのパスを生成する（もしまだ設けられてない場合）。拡張対象の継承済み構造をコピー後、ユーザーに、明示的に拡張するノードに関する情報を求め、DAG拡張のアトミック特殊化２１４１を用いてそれを生成することで進行することができる。実施形態は、１つのノードのコピープロセスを介してそのノードの明示的な詳細化を処理するか、暗黙的なコピーが完了した後明示的な拡張を用いて処理するかにおいて、違っていてもよい。前者のオプションは、図８０に概略が示されており、最終拡張が１つの継承済みノードの詳細化ではないことを確認して許可する。後者のオプションでは、段落０４１７に記載かつ図８１に概略を示した最後の詳細化対象の継承済みノードのみをコピーするアプローチと同様に、その代わりに１つのノードのケースを回避するため、継承済みで詳細化済みのノードのコピーを許可する。また、他の実施形態では、詳細化を２回実施するが、実際にこれが「インプレースDAG拡張の反復」の場合同様、インプレースを反復するには好ましいアプローチである。
【0187】
[0422]クロス種類（および詳細化）拡張のプロセスの概略を図８２に示す。これは図８０および図８１と、詳細化されたparentNodeを処理するステップを省略している点、シングル詳細化の発生を処理する必要のない点、ベースノードの継承済み祖先および詳細化済みノードの継承済み祖先のコピーの点、および、もちろん、最終拡張の形態（アトミッククロス種類とDAG拡張の特殊化２１４２）の点で異なる。
【0189】
[0424]継承済みノードの拡張のプロセスは、それらノードそれぞれの継承祖先構造をコピーすることを含んでいてもよい。ルーチンの特殊化用継承のコピー２１０３は、拡張される１つの継承済みノード（ベースノードまたは詳細化済みのノードの何れか）の継承済み祖先を反復して再生する。結果は、新たなノード（それもまたその親を指す）のへのポインタと、サーバが拡張についての検証が必要な実施形態では、拡張されるノードから、これらのプルーフを生成するのに使用できるローカスへのパスである。このルーチンを図８３に図示する。この記載ではスタックを仮定する。各スタックエントリの内容は、継承済みノードと、それが導出される操作を含むと仮定してもよい。この操作がノードの種類により推測できる実施形態では、継承済みノードのみを保持することで足りる。継承済みノードと共にまたは継承済みノードと一体化することはそのノードの親に辿りつく方法である。スタックはそのまま明示的に形成されてもよいし、既に形成された連続について使い回された値を処理する連続を形成する、または当業者が知っているスタックを形成するための他の計算方法によりシステムスタック（パラメーターを手順に渡すことでプッシュし、返信によりポッピング）を使用してもよい。ルーチンは、順に実行される２つのループからなる。第１のループは、スタックを形成しながら祖先を下に降りていくもので、後者は、継承済みのノードをコピーしながら、スタックを読み取るとうものである。最初のループでは、拡張するノードの祖先を介して上方に走査し、遭遇した各継承済みノードをプッシュし、コピー済みのノード、または未継承の祖先に達するまで続ける。前者の場合、保存した値で第２ループを始める。後者のケースでは、未継承の祖先を新たな親ノード（newParentNode）として使用し、親パス（parentPath）を、第２ループの開始時に、新たなパス（newPath）の形象化ノード（inheritedNode）で親パス（parentPath）を準備する。様々な実施形態では、DAG拡張のアトミッククロス種類および特殊化２１４２同様、この第１のコピーされたノード（最後の継承済みノードのコピー）は、常に、新たな親ノード（newParentNode）(継承済みノード（inheritedNode）の親）のクロス種類拡張の形態をとる。なぜなら、ノードはクロス種類対応関係として継承されているからである。そうでなければ、実施形態は、継承済みノード（inheritedNode）および親パス（parentPath）を以後の使用のためにプッシュし、継承済みノード（inheritedNode）をその親に対して設定し、親パス（parentPath）を第１エレメントがないバージョンで置き換えて第１ループを介して反復を続けることで祖先ヒエラルキを介して進行する。その後、最後の継承済みノードを新たなノード（newNode）としてコピーし、実施形態は、新たなノード（newNode）を新たなパス（newPth）にプリペンド（prepend)することで最終パス（finalPath）（プルーフ作成用）を形成する構成であってもよい。この時点で、新たなノードおよび最終パスを既にコピー済みのノードのデータ構造に記録し、新たなノードが継承済みノードおよび親パスの下にあることを確認し、これによりGLB計算がエラーなく行えるようにする。最後に、実施形態は、事前に算出された値がある場合は、それを拾える場所であるスタックが空であるかどうかを確認することで第２ループを開始することができる。もしそうなら、終了であってもよい。そうでなければ、スタックをポップし、次の最も浅い継承済み祖先ノードと親パスを取得し、新たな親ノードを次に最も深い祖先のコピーに設定する。この時点で、実施形態は継承済みノードをコピーする。もし、継承済みノードがその親のクロス種類拡張である場合は、実施形態は、DAG拡張のアトミッククロス種類および特殊化２１４２により、上記のように進行してもよい。しかし、もし継承済みノードがその親の詳細化である場合は、その代わりに、継承済みノードと新たな親ノードを詳細化済みノード（refindedNode）として用いたDAG拡張のアトミック特殊化を使用し、対応するノード生成ステップ後に進行してもよい。
【0190】
[0425]なお、全てのノードが実際にコピーされる限り、多数対多数の詳細化関係に対して上記に記載された（段落０３３５〜段落０３９９）継承済みノードの詳細化を簡略化することができる。詳細化対象の従属的ノードのそれぞれをコピーするので、様々な実施形態では、最終的な複数詳細化により、これら「コピー」が詳細化され、それぞれ、継承済み従属的ノードに対応づけられた独立的ノードではなく、ローカスノードに対応付けされる。このケースでは、従属的エンティティの複数の詳細化について、同じ独立的エンティティと対応関係であることを要求することも可能である。中間ステップは、そのような従属的エンティティの１つ、例えば最後のものが、他の詳細化対象の従属的エンティティと対応関係にある独立エンティティを詳細化する独立的エンティティと対応関係ことを必要とし得る。
【0191】
[0426]ロジカルサブ構造ツリーを延長することでDAGの自動拡張を必要とする実施形態では、時に、DAGの異なるセクションが拡張されていいるので、所望のDAGノードが目視出来ない場合がある。これは、表示を再調整して所望のノードが見えるようにすることで対応できる。サブ構造のノードにそれを行う手順を図２１３に示す。パスを受け取り、まずは、パスの既に目視できる部分を走査し、所望のノードが見つからなかった場合は、まず干渉し合っている兄弟を閉じ、そして１つひとつのノードについて、パスを展開していく。
【0192】
[0427]段落０４２４の特殊化のための継承のコピー２１０３は、拡張される（またはエースされている）ノードからローカスノードへのパスは、（ローカスノード以外は）全体的に継承済みノードからなると仮定する点で限定されている。継承済みノードと未継承ノード間でロジカルサブ構造ツリーが通ることも可能である。そのような状況は、このようなシチュエーションは、ダイアモンドが継承され、それを通る１つのパスがコピーされるが、ユーザが他のパスを探査する場合に起こり得る。しかし、どの継承ノードからも、それがそこを介して継承される各ローカスノードへ、ローカルなDAGには必ずパスがあり、よっていくつかの実施形態では、それで十分であると考えてもよい。他の実施形態では、特殊化のための継承のコピー２１０３は、下記のように変形して、そのようなシナリオで作動することが可能である。未継承ノードや、既にコピー済みのノードであればどのようなものに対しても引き返すのではなく、ローカスノードやコピー済みのノードに対してのみ引き返す構成であってもよい。実施形態は、ローカスノードからパスを引き返すので、継承済みノードの後の最初の未継承のノードに達したら、ノードを作成して、それをコピーされた親エンティティに対応させるのではなく、そのエンティティと、パス上のトラッキングの対象となっているものとの間で対応関係を作り、自身のノードを、それが継承される場合リンクされる、パス上の次のノードに渡す構成であってもよい。続く未継承のノードは、子が継承済みの場合は、子に変える時に単に親ノードを自身のノードで置き換える。図８５はノード１１＋と１２＋が継承されていないという仮定における図８４の変形例である。最適化として、実施形態は、パスを遡る時に、どのノードが復路のノードを必要とし、どれをコピーする必要があるのかを判断し、復路での操作を削減する構成であってもよい。
【0193】
インプレース反復DAG拡張[0428]
この反復は、クロス種類関係が多数対一である場合により直観的なものになり得る。継承されたものに対応する平行構造を作成するより、インプレースの継承された構造を変形することができる。ヒエラルキで他のものより下にある構造は、グローバルDAGでは下ではないかもしれないので（後者がのみが継承されている場合）、これは一見おかしな考えのように見えるかもしれない。しかし、これが受け入れられたら、正確かつ直観的な表現を提供できる。
【0194】
[0429]図２４のDAGを参照する。ユーザは、段落０４１１に記載の操作のシーケンスをインプレースで実行することができる。図３９のDAGは可能性のある結果である。それは下記のようにある詳細化アークが、再言及を示す文字「Ｒ］でマークされている点で、図３９とことなっている。上記のように、図２５、図２６、図３７に、ユーザがノード１２および１５の探査に用いるツリーとしてノード１においてローカライズされたDAGを示す様々なステージを示している。
【0195】
[0430]図４０に、承継されたノードの反復されたインプレースの再言及を用いて、ノード１に対して対処するものとされた新しい問題ノード（１７）で問題ノード１２および１５を詳細化をするプロセスを示す。また、図３９にこのプロセス後、結果得られたDAG全体を示す。
【0196】
[0431]標準の反復コピーについて記載されたものと同様のバリエーションも反復コピーインプレースについては関連がある。
【0197】
［0432］これは、上記のようにユーザにより再言及された情報を示すのを回避するようにユーザに最初のローカライズされたDAGをどのように示したらよいかという問題を提起する。いくつかの実施形態では、これをDAG構造に基づいて暗黙的に行い、少なくともインプレースの再言及で形成された構造がローカライゼーションにて再言及だと見なされるようにする。このような実施形態では、例えば、もし解決法が直接いくつかの問題ノードを解決し、他の解決法ノードも詳細化する場合、詳細化対象の解決法は再言及だとされ、詳細化済みのノードの位置で目視可能とされることを必要とする。これは、詳細化対象のエンティティと詳細化済みのエンティティは異なるオブジェクトを有する必要があるとする要件と同様である。下記に概略を示すものも含む他の実施形態では、例えば継承されたノードが修正され、マークされた詳細化の取扱いがローカライゼーション時に異なる可能性がある場合のみ、再言及を明示的に生成する構成であってもよい。そのような再言及は、修正された継承済みノードをオリジナルのものと結びつけ、継承されたノードの祖先の結果として得られるコピーをオリジナルと結びつける。再言及の生成には、どのようなエンティティも、最大でも１つの他の（より一般的な）エンティティを再言及するいう制約を設けることができる。
【0198】
[0433]いずれのケースでも、再言及は、アクセスコントロールのベースを形成することもできる。いくつかの実施形態では、関連していない再言及、例えば、サブ構造や文脈に存在していないノードに対処するものとされた再言及の閲覧を防止する。暗黙的な再言及により、実施形態では、例えば、問題が解決法の継承パス上にある場合でない限り、問題を直接解決する解決法を継承するのを避けるように構成されていてもよい。または、一実施形態では、段落０６３１に記載のように、共通の専用の詳細化の定義をサポートし、解決法の、詳細化対象の問題と交互に対処するものとされた子孫を継承するのおをさけるように構成されていてもよい。以下に明示的な再言及によりローカライゼーション中のアクセスをコントロールする方法を示す。ゴールは、ユーザに、ユーザに無関係の解決法を示すことを避け、また、解決法は、それを見なければならない者（組織の創立者はより広いゴールを持つ可能性があるが、同じ創立者の下の姉妹組織はそうではない）にのみ目視可能とする点である。
【0199】
[0434]再言及をこのように使用すると、アクセスだけでなく関係性もコントロールする。プロジェクトヒエラルキに依存する組織ヒエラルキを考慮する。ユーザは、基本的にプロジェクトに関心があるので、プロジェクトについて任命された個人の部下が、無関係のプロジェクトの仕事に対して任命されている場合は、その部下に会うことに興味はないであろう（この場合、ユーザの解決法への任命の関係は多数対多数であろう）。
【0200】
[0435]様々な実施形態では、継承された再言及は再言及されたエンティティの場所に現れるので、再言及されたエンティティの他の（再言及されていない）子孫を再言及の下に置く方が、便利であろう。また、これは、グローバルなDAGから分化したローカルなDAGのためおかしなように思えるであろう。また、いくつかの実施形態では、このステップを取るのを避け、特に非再言及詳細化の場合は避ける。このアプローチに合わせて、図８６に、継承収集２２４０を変形し、再言及を介して他の詳細化対象のノードを詳細化するようにした構成を示す。
【0201】
[0436]インプレース反復の提案された方法は、操作がローカスノードに対して開始されるノードからのパスに沿って、継承済みノードの再言及をトリガする。例えば、操作が開始されるノードには、同じ祖父を有する２つの親がある「ダイアモンド」構成の場合、操作はダイアモンドを介して１本のパスに対して開始され、再言及は一方の親だけで他方にはしないという構成であってもよい。後の操作が同じノードまたは、他方の親を介して遡る子孫から始まるなら、いくつかの実施形態では、そのパスの全ての継承済みノードについて再言及し、他の実施形態では、そのパスのプレフィックスを継承するものがあれば、それを行う構成であってもよい。前者では、ローカスに向かって操作して遡る時に、ノードが、継承された親からなるかを通知し、ローカルまでずっと継続して、操作をして下ってくる時に、継承済みのノードのみ再言及して、その親が再言及されている構成ノードの親を脚設定する構成であってもよい。
【0202】
[0437]同じ種類のエンティティ間の詳細化対応関係のある特定の種類として再言及を考慮している。サーバへのローカライゼーションプロセスは、それが遭遇するどのような再言及も集める構成であってもよい。これは、これらはクライアントにより、適切なサーバリクエストを作成するのに必要になるかもしれないからである。
【0203】
[0438]まず、サブ構造のノードにより再言及される継承済みのエンティティを隠すことが望まれるかもしれない。これを容易にするため、いくつかの実施形態では、継承済みのノードをDAGボトムアップに追加する継承記録２２５０のバージョンを使用する（それゆえ、サブ構造に一番近い位置の継承されたノードが最初に追加される）。簡略化のため、実施形態では、継承収集２２４０の最も浅いものからの順番のバージョンを使用してもよい。１つの親ノードや、継承を受け取るターゲットノードの位置に、ターゲットノードのスタックを保持し、継承の直近の受領者をトップターゲットと称する。ここで、補助ルーチンは、継承された子孫を辿る過程でサブDAGに達したかどうか、およびトップターゲットノードの下の位置に子があるかの両方について返信する。他のルーチンでは、再言及対象子の記録２２７０は現エンティティ（currentEntity）の各再言及対象子を記録する。先祖の適性チェックを含む操作のほとんどは、冗長な詳細化リンクの存在を防止するためのもので、段落０３３１に記載のように対処され得る。これらルーチンでは、子ノードが再言及されているか否かにより分岐する。重要な点は、子についてのオブジェクト―オブ操作のシーケンスがローカスノードを生じる場合または子のオブジェクトが継承パス上にある場合にこの判定をいくつかの再言及を無視して行う点であり（または、各再言及に、それが形成された拡張で反復済みのものを保存し、これらがローカスノードに導くか確認することを考慮する。これはクロス種類拡張のインプレース再言及の場合オブジェクトに対応する）、もしサブDAGにあるなら、非再言及として扱い、そうでない場合は無視する。さらに、段落０４３３に提案するように再言及を使ってアクセスをコントロールするために、継承パスを継承記録２２５０に利用できるようにする。この改良により、ルーチンは無関係の再言及を省略できるようになる。ここで、継承パスに親がない場合、継承ノードが無関係であると再言及することを考える。これを図８７に示す。
【0204】
[0439]クライアントサイドでは、いくつかの実施形態では、図８０および図８１に提示の交互のハイレベルプロセスフローを、適切な場合は１つの継承ノードを再言及し詳細化するという図８９のもので置き換えるが、他の実施形態では、他のルーチンの変形例を使ってもよい。このケースで使用する図９０では、基本的に図８３とは、再言及を行うアトミックルーチンを使用する点で異なる。また、これまでの再言及の記録も保持する。図９１に明示的な詳細化操作用にインプレースとなっている可視化したノードを再言及する一方でDAGを拡張するプロセスフローを示す。次に図７３との違いを示す。各詳細化済みノードのオブジェクトからローカスノードに向かう詳細化パスの特定の際に、オリジナルの再言及されたエンティティの詳細化からオブジェクトの再言及のチェーンを分離する。そして、GLBの算出時に、詳細化パスに対処する。GLBそれ自体が継承されているなら、特殊化のための継承の再言及２１３３を繰り返し、それとその祖先を再言及する。そして、GLBを、詳細化済みのエンティティからの詳細化パスについての再言及にて置き換え、GLB再言及を対応する再言及パスのそれぞれに追加する。DAG拡張のプルーフ作成の際に、再言及対象ノードから再言及済みノードへの再言及パスのそれぞれを、再言及済みノードからローカスに向かう対応する詳細化パスに接続する。または、DAG拡張アトミック特殊化２１４１のように継続する。
【0206】
複数クロス種類拡張[0441]
多数対多数のクロス種類関係は、もし独立的エンティティ種類上の詳細化関係が多数対の場合は、独立的エンティティの数がいくらであってもまとめて詳細化可能であり、新しい従属的エンティティは独立的エンティティを詳細化するものとのみ対応させることが可能なので厳密には必要ではない。
【0207】
[0442]いくつかのケースでは、実施形態は、多数対多数のクロス種類関係をサポートするのが好ましいとするかもしれない。図９３のDAGを、それがどのように働くかについての例として参照する。ここで、４つの子を有する１つの問題、それを解消する２つの問題、およびそれを詳細化する２つの問題がある。図９４に、継承前に２つの子問題を軸としたナビゲーションを行う同じDAGを示す。両方の子問題が両方の解決法を継承した後、DAGは図９５に示すものになる。図９６の探査から、図９７に示すように、２つの解決法の詳細化を実行する。図９８に示すように、詳細化に加え、各子問題との暗黙的なクロス種類対応関係がある。明らかに、ここでの仮定では、各解決法に割り当てられた問題は１つもない。
【0208】
[0443]多数対多数のクロス種類関係を直接的にサポートする実施形態は、複数の独立的エンティティと対応付けされた従属的エンティティの生成と複数の他の従属的エンティティの詳細化をどのように制約するかを考慮するかもしれない。１つの方法としては、拡張対象の各独立的エンティティおよび詳細化対象の各従属的エンティティについて、祖先クロス種類対応関係が、独立的エンティティが拡張対象の独立的エンティティにより詳細化され、従属的エンティティが詳細化対象の従属的エンティティにより詳細化されることを要求することである。しかし、また、独立的エンティティ中の従属的エンティティをパーティションし（または、同様に、従属的エンティティ中の独立的エンティティをパーティションし）、祖先クロス種類対応関係が同じパーティション内の各従属的エンティティと独立的エンティティにのみ存在する必要があるようにする。
【0209】
[0444]関係するDAG拡張を直感的かつ効率的にする上記技術は、複数のローカスノードを有することにより、同じクロス種類関係により複数の独立的エンティティに関係付けられている従属的エンティティの作成および複数の従属的エンティティの詳細化に適用可能である。複数のローカスノードは、一般化（「DAG一般化」にて説明）など他の目的にも有効である。
【0210】
[0445]これは、我々のDAGの若干の一般化を用いて達成可能である。DAG Dagを前提とすると、任意のE｜について、DAG DagE｜1を定義し、DagE｜1は、Dag中のE｜の中のあるEから到達できないノードまたは、そのノードからE｜中のあるEがDagにおいて到達できないようなノードを含まない点でDagとは異なるとする。
【0211】
[0446]ある実施形態は、DAGに対して更なる修正を用いる。DagE｜２は、DagE｜1とは、Eにより承継されたEエンティティ中の各Eの子として、例えば、Eにより詳細化されたエンティティに従属するエンティティを含む点でことなる。
【0212】
[0447]この実施形態では、共通の文脈を有するDAG DagE｜２をしめす。ここで、もしユーザが、詳細化対象エンティティがそこから導かれるE中のとあるＥにより継承された１つ以上のノード（それぞれ、Ｅにより直接的に継承されたノードを詳細化する）を選択した場合、クロス種類対応関係は、詳細化される継承済みノードの文脈中の各Eと、新たな詳細化対象エンティティの間に暗黙的に形成される。
【0213】
[0448]DagE｜1は、段落０３２７におけるDag1Eと同様にDagから得られるが、そこからサーチされる複数のエンティティから始まり、共通の減縮されたDAGで遭遇する全ての構造を含み、E｜を横断する訪問したノードの共通のコレクションを保持する。
【0214】
[0449]DagE｜２は、段落０３２７におけるDagE｜1と同様にDag２Eから得られるが、各ローカスノードについて継承収集２２４０を呼び出す。さまざまなローカスノードは、共通の文脈をシェアしているかもしれないので、E｜中の各Ｅを横断する各文脈ノードについて、継承されるノードのコレクションを維持し、エンティティに以後遭遇したら事前に算出された継承を使用することが好ましい。継承記録２２５０は、あらゆるローカスノードによって継承された各エンティティについて呼び出される。
【0215】
[0450]サブ構造と文脈の両方に跨る境界を満足する際に「ローカスノード」を使用できる場合、複数のローカスノードがサポートされている実施形態では、ツリーの下層の境界（GLBについてシェアされたサブ構成）を探す必要がある構成であってもよい。
【0216】
[0451]多くの実施形態では、ローカスノードはそれぞれの祖先や子孫ではない、少なくともローカライゼーションされたDAGではそうではないことを確認する構成であってもよい。なぜなら、これは、サブ構成や文脈の概念が複雑化するからである。
【0217】
[0452]多数対多数の関係の場合および間接的オブジェクトが保存されていない場合、同じ種類のすべてのローカスを用いて、ユーザは、別々のローカスにより継承された複数のノードをまとめて詳細化することができ、簡単に最終詳細化に加えてそれぞれの「ダイアモンド」構造を形成することができる。
【0218】
[0453]全てのローカスが同じ種類であるという事により考えられる他の利点は、一般化（説明は後述する）について、ユーザが各ローカスにより詳細化された従属的エンティティのクロス種類対応関係を形成することができる点である。
【0219】
[0454]複数のローカスノードがある場合、実施形態では、補助的情報（「補助的情報および集約」にて説明を省略する構成であってもよい、または「いずれかの」ローカスエンティティ、または「すべての」ローカスエンティティに関連する何れかまたは両方の情報を提供する構成であってもよい。補助的情報が目立たないものである場合、これは、さまざまなローカスエンティティの補助的情報について、集合もしくは交点が関与するものであってもよい。補助的情報がヒエラルキである場合、段落０６０５に記載のように、関連するエンティティがさまざまなローカスエンティティを介して補助的情報に含まれている場合、実施形態では、さまざまなローカスエンティティに関連するエンティティの集合を取ったのち、他のローカスエンティティに補助的なものとなっているエンティティの先祖であるものを除く構成であってもよい。または、「すべて」の場合、各ローカスノードについて、そのローカスノードに補助的であるノードのへの詳細化を介してそれらが関連している場合のみ交点の代わりに、ローカスノードに対して補助的になっているノードを考慮し、そのような補助的ノードの最も一般的なもののみを含む。よって、もしあるローカスユーザがJavaのプログラミングおよび製品管理に精通し、他のユーザがPythonのプログラミングおよび製品管理に精通し、３人目がプログラミングとAgileの製品管理に精通してる場合、全てのユーザが精通していると選択したスキルはプログラム管理とプログラミングであり、何れかのユーザが精通しているとしたスキルはJavaプログラミング、PythonプログラミングおよびAgile製品管理である。
【0220】
[0455]実施形態では、しばしば全てのローカスが同じ種類であることが望ましいが、例外もある。ユーザーとプロジェクトの役割とのマッチングに資するため、ユーザーのプールとプロジェクトのプールが全てローカスであってもよい。そして、クロス種類関係の直接スキルに熟練（directlyProficientInSkill）および直接必須（directlyRequiredBy）を含め、直接詳細化関係と共に（少なくとも直接詳細化スキル（directlyRefinesSkill））、スキルを介して特定のプロジェクトの役割に特定のユーザが結びつけられているか可視化するのは容易である。
【0221】
[0456]プロジェクトが全てのスキル要件を満たす場合にのみ、プロジェクトを個人にマッチさせるという要望に対応するため、１つとは言わぬ実施形態では、直接スキルに熟練（directlyProficientInSkill）と直接必須（directlyRequiredBy）の両方を多数対多数ではなく多数対一として扱い、暗黙的に解決法が要求する、またはユーザが精通するスキルのそれぞれを詳細化するスキルを作成する。これは、スキルの要件がリソース要件（段落０６１９に記載）に結びつけられている実施形態には役立つが、スキル要件が全体としてプロジェクトに結び付けられている実施形態では無関係（段落０６０３に記載）である。
【0222】
[0457]そのように作成された各マルチスキルについて、DAGも、スキルの親として、同じスキルコレクションのより少ない組み合わせを、DAGにも含まれるであろうシングルトンスキルまで、含む。そのように多いDAGエンティティのクラッタや非効率性を避けるため、冗長なく既存のDAGスキルエンティティに接続する必要がある時に、詳細化スキル（refinesSkill）対応関係を直接詳細化スキル（directlyRefinesSkill）対応関係の場所に含むのが好ましい。インデックスは、個々のスキルエンティティからマルチエンティティまで、それらが参加しているDAGから作成される。そして、各マルチエンティティについて、その各等位項と対応付けされた他のマルチエンティティを参照することが可能であり、それ自身と、それ自身の要素ではない個々のスキルを含むマルチスキルを省略し、残りのものを、個々のスキルのセットにおけるサブセット関係により順序付けすることができる。隣接するスキルセットはDAGにて接続されている必要がある。
【0223】
[0458]DAGが複数のエンティティが一次液なDAGの複数のローカスに関係づけれらている二次的なDAG（段落０６０５参照）である場合、またはユーザが明示的に複数のノードにナビゲーションをした場合は、DAGを複数のローカスで閲覧することができる。
【0224】
DAGの一般化[0459]
上記では、プロジェクト構造のトップダウン拡張についてのみ説明した。しかし、ボトムアップからプロジェクトを拡張することも有効である。特殊化の素直な反対は一般化である。特に有効なケースでは、より一般的な問題と解決法をより特殊化したものから生成することを含む。他のいかなあるエンティティの従属的エンティティとなる必要がない種類のエンティティについて、実施形態はそのよな上向きの詳細化を制限する必要はない。
【0225】
[0460]詳細化対象エンティティのオブジェクト割り当ての保持を正当化するため、いくつかの実施形態では、特殊化についての段落０３３７の制約と同様の制約を適用する構成であってもよい。独立的エンティティと新たな従属的エンティティに、１つ以上の従属的エンティティがによりその従属的エンティティが詳細化されているクロス種類関係の下、割り当てられる場合、実施形態では、各詳細化対象従属的エンティティについて、その独立的エンティティのいくつかの詳細化子孫が同じクロス種類関係にて、（直接的なオブジェクトを有する）その従属的エンティティの詳細化祖先に関連付けされ、新たなクロス種類対応関係といくつかの既存のものとの間の対応関係（段落０３３７の制約下よりもいくらか緩いもの）の形態を示す。よって、もし新たな詳細化済み（一般化対象）の従属的エンティティが独立的エンティティによりそのオブジェクトとして生成された場合、各詳細化対象の従属的エンティティのオブジェクトは様々な実施形態ではその独立的エンティティを詳細化するものである必要がある。
【0226】
[0461]ゼロまたは１つの独立的エンティティ（例えば、ゼロまたは１つの解決法の要素である問題など）に対応付けられた種類の従属的エンティティについて、いくつかの実施形態では、詳細化対象エンティティは、すべてオブジェクトを有するか、またはすべて持たないとする必要がある。前者のケースでは、新たな、一般化対象エンティティは、それらのオブジェクトのLUBを割り当てられていても良い。後者では、新たな、一般化対象エンティティは、何らかのオブジェクトを割り当てられていてはならない。他の実施形態では、オブジェクトを有しないこの種類の従属的エンティティのどのような一般化も許し、どのような数の詳細化対象エンティティであってもオブジェクトを持つことを許す、または許さない構成であってもよいが、また、もしオブジェクトが該新たな詳細化済みエンティティに割り当てられている場合、それは、詳細化対象エンティティの何れかのオブジェクトのLUBである必要がある。
【0227】
[0462]独立的エンティティに対応付けられる必要がある従属的エンティティについては、いくつかの従属的エンティティの一般化を、もし新たな、一般化対象の、従属的エンティティのオブジェクトとして、それらのオブジェクトのLUBを算出できるなら、行うことができる。これは、特に、一般化の対象のノードが、そのノード同様、サブ構造にある場合に可能であるが、その場合に限定されるわけではない。またはクロス種類操作は、一般化が対応付けられ、ベースノードとして称される独立的エンティティのノードから開始されてもよい。従属的ノードの、そのオブジェクトとの対応関係は、ベースノードが存在し、それがLUBとは異なっている場合に直接的と考慮されるが、そうでなければ間接的と考慮される。実施形態は、特に（段落０４７１に記載するように）ローカスノードのをLUB計算に暗黙的に含むものは、ベースノードが文脈にあることを必要としてもよい。
【0228】
[0463]よって、ユーザは、独立的エンティティとのクロス種類関係を維持または作成する一方で、従属的エンティティの一般化を所望するかもしれない。その利点は、より一般的なっ問題を適用するために一般化された後、一般化された解決法は、他の特殊化されたノードにより継承され、上記のように詳細化されるできることである。文脈にあるベース（独立的）ノード（ユーザが下向きに拡張しようとするかもしれないもの）については、ユーザに新たな従属的ノードが詳細化する必要がある従属的ノードを選ばせるのではなく、一実施形態では、ユーザに、その新たな従属的ノードを詳細化し得る同じまたは少なくとも一貫性のある種類の従属的ノードをを選ばせ（いくつかの実施形態ではこれを文脈に限定してもよい）ても良い。そして新たなノードは、拡張対象のノードと詳細化対象のノードの間に配置される。これは、新たなノードが、詳細化対象ノードが文脈にある場合にこの詳細化対象ノードの上に位置し、もしベースノードがサブ構造にあるなら、ベースノードの下に位置してもよいことを示唆する。もしベースノードが適切な文脈にあり、詳細化対象ノードが適切なサブ構造にあるなら、新たな詳細化済みノードは、いくつかの実施形態では表示されず、そのような実施形態では詳細化対象ノードを文脈に対して制限してもよい。
【0229】
[0464]ユーザは、まとめて一般化される同じ種類の複数のエンティティを選択し得る。図９９のDAGを参照のこと。ここでは、長さ３の問題の詳細化の２本のチェーンがあり、最も一般的な３１で結合し、それぞれ１つの解決法（３６および３７）にて終了している。もし、図１００に示すように、ユーザが３１にナビゲーションを行い、３６および３７に向かって探査する場合は、図１０１に示すように３６および２７のジョイント一般化を開始し、図１０２に示すDAGが可能性のある結果となる。
【0230】
[0465]ユーザは、代わりに明示的にクロス種類対応関係で拡張する独立的エンティティと、一般化する任意の数の従属的エンティティの両方を選択してもよい。例えば、ユーザは、ある特定の、より一般的な問題を解決する意思をもって解決法を一般化したいと思うかもしれない。図１０３のDAGを参照されたい。これは図９９とは、独立的ノードと直接的に対処するものとされている各従属的ノード（４６および４７）が既に他の従属的ノード（それぞれ４８および２９）により一般化されている点、オブジェクトノードのLUB４１が詳細化親４０を有している点で異なっている。図１０４の探査から、２つの従属的ノード（４８および４９）を一般化のために選択肢、図１０５に示すように根の独立的ノード４０からクロス種類操作を開始する。図１０６に示すように、ここで、新たなノード５０は、それが対処するものとされている独立的ノードと、それが一般化する従属的ノードの間に配置されている。
【0231】
[0466]上記の例では、一般化され、ユーザにより明示的に選択されるノードは、そのオブジェクトがベースノードであるローカスノードにより詳細化された。より複雑な従属性のシーケンスがある場合、特殊化の反復について説明したものと同様のプロセスは、いくつかの一般化操作とクロス種類拡張操作をシーケンスで処理し、そしてトップダウンで進行する。そのシチュエーション（段落０４２６に記載）同様に、ノードをを見せる必要があるかもしれないが、今回は文脈のなかである。これを達成する同様のルーチンを図２１４に示す。
【0232】
[0467]文脈中のベースノードのクロス種類拡張を実行時に、暗黙的にローカスからベースノードを含まずにそこまでのパスを、新たな拡張ノードにより一般化するシーケンス（または複数のシーケンス）として処理する実施形態では、最も高い位置のコピーされたノードにより（反復を介して）コピーまたは一般化することができる。例えば、図１０７を考えて頂きたい。これは問題の構造であるが、２つの子を有する１つの詳細化問題であり、子はそれぞれ１つのコンポーネント問題を有史っている。この２つのコンポーネント問題７４および７５をローカスノードとしてナビゲーションを行ったと仮定する。根問題７０から解決法を開始した場合、これは、その解決法が文脈のコピーされた部分により詳細化されるように実施形態により解釈される。特に、複数のローカスにより開始し、２つのコンポーネント問題をコピーし（上記同様、ユーザは情報を修正可能）て一般化に供し、そして、２つの既存の解決法を一般化し、根問題を解決する新たな解決法を構成する。結果得られたDAGを図１０８に示す。
【0233】
[0468]一般化は多くの面で特殊化と類似しているが、その構造と文脈は反転したものである（だたし、ここでは両方のケースについてトップダウンのクロス種類拡張のみを説明した）。
【0235】
複数同時詳細化[0470]
独立的エンティティを、ある特定の種類の各従属的エンティティと対応付ける実施形態では、いくつかの従属的エンティティが一般化される場合、新たなエンティティに対して一般化対象のノードのオブジェクトの最小上界を割り当てるのが道理である。例えば、それぞれの解決法が、それが解決するどの問題をも詳細化する個別の問題に対応付けられているか、それぞれの引数が、それが対処するものとされているあらゆるオブジェクトを詳細化する個別のオブジェクトに賛成または反対しているのが望ましい場合がある。残念ながら、段落０３３８に示すように、文脈ツリーは、最小上界へのアクセスをかなり限定している。継承を組み込む（上方向に）ことで、いくつかのケースでは解決法を提供しうる。
【0236】
[0471]LUBを算出する際に、段落０３４３のGLBの場合と同様に、LUB入力を暗黙的に広げてローカスノードを含むようにするか否かを考える必要がある（それが、詳細化致傷の、サブ構造中のオブジェクトの全てによって詳細化されると仮定）。そうすることで、ユーザがローカスにナビゲーションしたことの有意性を関連性の信号として認識できる。
【0237】
[0472]サブ構造や文脈ツリーに対するLUBとして新たな詳細化済み従属的エンティティに対する関連付けをする、独立的エンティティの算出を説明する。サブ構造からは従属的な詳細化対象ノードは選択されない（適切な文脈から選択される）場合、段落０４６０の制約を適用する実施形態では、それらのGLBのオブジェクト（反転した文脈ツリーにあり、ツリーに関するGLBの算出０１１１を用いて取得）を、もしそのLUBが存在するなら、新たな詳細化済みノードに対して、安全に割り当てることができる。しかし、いくつかの実施形態では、段落０４７１に従ってローカスノードを単純に使用することができる。詳細化済みの従属的ノードが同じオブジェクトを有する場合、そのオブジェクトを新たな詳細化済みノードに割り当てることができる（ここでも、ステップは効率を向上し得るが、後続のステップでカバーされているので、省略可能である）。そうでない場合（もしくはこのアプローチに直接行くことが好ましい実施形態では、サブ構造や文脈ツリーにある詳細化対象ノードのオブジェクトの存在に依存し、サブ構造および文脈ツリーに関するLUB算出４１０１を用いてそれらの間LUBを確認する構成であってもよい。図１１１に、サブ構造および明示的文脈ツリーに関する詳細化対象ノードのオブジェクトのLUBの算出５１１１を示す。
【0238】
[0473]サブ構造および文脈ツリーに関するLUB算出４１０１は、ノードリストに入力が到着すると仮定し、まず全てのメンバーがサブ構造にあるか文脈にあるかを確認し、なければフェイルする。文脈にノードがあれば、ツリーに関するGLBの算出０１１１を用いてクライアントが、反転文脈ツリーに関するそれらのGLBを算出し、適切なサブ構造にあるものを無視する。全てのサブ構造ツリー内の全てのノード（およびローカスを使用して先祖返りをしていない）場合、ツリーに関するLUBの算出０１０１を用いて、サブ構造ツリーに関するそれらのLUBを得る。いくつかの実施形態では、上記の場合に直ぐにフェイルにするのではなく、より詳細な検索など他の手段でDAGにLUBがないか探すように構成されていてもよい。
【0239】
[0474]段落０４６４の例では、３１は３８に３４および３５のLUBとして割り当てられており、ノードのオブジェクトが詳細化されている。なお、図１０１では、新たな解決法ノード２８が、段落０４６３にて提案されているように、問題ノード３１の下に作成されている。
【0240】
[0475]ここで、サーバは、一般化される各エンティティのオブジェクトそれ自身が、新たなノードの提供されたオブジェクト（ここでは、そのような全てのオブジェクトのLUB）により一般化されていることの検証、すなわち、新たなノードのオブジェクトが詳細化対象ノードのオブジェクトの少なくとも上界であることの検証を要求するものであってもよい。サーバは、一般化される各従属的エンティティについて、一般化対象の従属的エンティティのオブジェクトから最小上界までの詳細化により関連付けされたエンティティのチェーン（最も特殊化したものから最も特殊化していない方向の具体性を仮定）を要求するものであってもよい。そのよううなチェーンは、プロジェクト構造のツリーベースのエクスポジションにより提供することができる。詳細化対象の各ノードについて、クライアントは、いくつかのケースの内の１つに基づいてパスを構築することができる。文脈中のLUBと詳細化対象オブジェクトの両方について、クライアントは、LUBから文脈ツリーの根に向かうパスをトレースした結果を反転させ、詳細化対象ノードにおけるエンティティのオブジェクトによりノードに到達するまで詳細化を辿ることができる。文脈内のLUBとサブ構造内の詳細化対象ノードのオブジェクトについては、詳細化対象エンティティのオブジェクトのノードからローカスまでのパスと、LUBからローカスまでの反転パスを連結することができる。（段落０３４１同様）LUB算出におけるローカスノードの暗黙的に含んでいない実施形態は、サブ段落中のGLB（およびオブジェクトノード）の場合を加え、その場合は、オブジェクトノードにより開始し、LUBに届くまでサブ構造を遡ることで、得られるパスを使用する構成であってもよい。図１２２に、図５９からプルーフパスの生成０１１３を使うプルーフ生成プロセスの実施形態を示す。我々の例では、ユーザがノード３６と３７を一般化する場合は、本実施形態のプルーフは、３６については、そのオブジェクト３４からLUB３１までの[３２、３１］からなり、３７については、同様にオブジェクト３５からLUBまでの３１までの[３３、３１]、そのオブジェクトからの[３３、３１］からなる。
【0241】
[0476]文脈中のノードの一般化する際には、好ましい実施形態は、まずノードをその親ノードリスト（段落０６８２参照）のトップに移動させる。もし操作が開始されるノードがDAGの最も上のノードだった場合、実施形態は、（サブ構造における）新たなノードの下にDAG全体を置き、新たなフレーム内に構築する。または、新たなノードを包括フレームのノードリストのトップに置く。
【0242】
[0477]これらをまとめると、クライアントは、DAG拡張のアトミック明示的生成４１４１を使って既存のノードにより詳細化される新しいノードを生成する。図１１０に各従属的エンティティがLUBとしてオブジェクト独立的エンティティを詳細化対象ノードのオブジェクトのサブ構造と文脈に対して割り当てる。まず、各詳細化対象ノードについて、サブ構造または文脈を介したオブジェクトから、ローカスまでの詳細化により関係するノードのシーケンスを識別する。段落０３５０のコメントと同様のものが当てはまる。そして、図１１１に示すように、詳細化対象ノードのオブジェクトのLUBを算出する。LUBが存在しない場合は、フェイルとし、エラーメッセージを提供する。図１２２に示すように、サーバ用のプルーフを生成する際にLUBとその詳細化パスを使用する。一方で、ユーザに対して新たなエンティティに保存する情報を求める。そしてサーバにアクセスし、プルーフを送って拡張操作をリクエストする。フェイルした場合は、部分的に作成したノードをクリーンアップする。そうでなければ、クライアント情報を更新し、新たなエンティティを含ませる（ユーザが入力したデータとそのオブジェクトを含む新たなエンティティの記録を作成、詳細化するノードのエンティティの記録を更新し、該新たなエンティティを追加の子として含ませる）。サーバは、ユーザが使用できる新たなエンティティのデータベース識別子を返送し、例えば、新たなノードのためのURLを構築する。
【0243】
[0478]各従属的エンティティがオブジェクトに割り当てられているプルーフ検証プロセスは、図１２３に示すもののようになる。サーバーは、各詳細化対象エンティティについて、そのパスが実際には詳細化のチェーンであり、詳細化対象エンティティのオブジェクトから始まり、新たな詳細化済みエンティティの提供されたオブジェクト（通常詳細化対象エンティティのオブジェクトのLUB）で終わるものであることを確認する構成であってもよい。それは、グローバルDAGを介して提供されるパスを辿り、各ステップが詳細化であることを検証する。
【0244】
[0479]直接的なオブジェクトのみの場合におけるプルーフ検証プロセスである、直接的オブジェクトのみによりDAG拡張の一般化のためのプルーフを検証５２３１を図５３に示す。サーバは、各詳細化対象エンティティについて、ある独立的パスが、実際には詳細化のチェーンであり、詳細化対象エンティティの提案された直接的オブジェクトから始まり、新たな詳細化対象エンティティの提供されたオブジェクト（一般には詳細化対象のオブジェクトのLUB）により終了するものであり、任意の従属的パスが実際には詳細化のチェーンであり、詳細化対象エンティティから始まり、新たな詳細化済みエンティティにより終わるものであり、最後に詳細化対象エンティティ提案された直接的オブジェクトが真正であることを確認にする構成であってもよい。
【0245】
継承されたノードの一般化[0480]
段落０３３７の制約を適用する実施形態では、「DAG拡張の反復」および「インプレース、DAG拡張の反復」において記載するようにまずコピーされた場合にのみ、サブ構造へ継承されたノードの一般化を許す構成であってもよい。しかし、この操作では、継承されたノードのものを一般化せず、ノードの特殊化のみを行う。継承されたノードは、ノードの継承が始まるノード、または文脈におけるその祖先のうちの１つによりクロス種類拡張を作成する。独立的ノードを買う従属的ノードに割り当てている図２４からのDAGの一例にて考えてみる。ノード２へのナビゲーションを行い、継承されたノード１０について直接的に一般化しながらこのノードからクロス種類拡張を開始する場合、１０および新たな詳細化済み従属的ノードは、それぞれ１および２のオブジェクトであるが、詳細化は反対方向に進み、２が１を詳細化するが、１０は新たなノードの詳細化する。文脈中のノード１または０から操作を行ってもよいが、まずこれらノードの何れかにナビゲーションを行い、継承されたノードではない１０により操作を開始してもよい。ノード１０はまず詳細化１０’、にコピーされ、１０’はオブジェクト２を有するようになる。２を拡張しつつ１０’を一般化すると、段落０４８５に記載のような状況になり、適宜進行することができる。
【0246】
[0481]しかし、ある種のエンティティを上方向に文脈へ継承することをサポートする実施形態では、そのようなノードを、サブ構造の継承済みノードの特殊化について上記に記載の同じ技術を使って一般化することができる。
【0247】
複数の同時詳細化による単一クロス種類拡張[0482]
解決法を更なる再利用することを可能にするため、ユーザは解決法を一般化し、より一般的な問題に対処するようにしてもよい。一般的な解決法は、他の特殊化した問題により継承され（そして、これら問題に対して特殊化す）ることができる。より抽象的には、従属的エンティティの更なる再利用を可能にするため、ユーザは、選択された独立的ノード（ベースノード）からクロス種類拡張を開始してもよい。その場合、一般的な従属的エンティティは、他の特殊化した独立的エンティティにより継承され（そしてこれら独立的エンティティに特殊化され）ることができる。
【0248】
[0483]段落０３５６のGLBの場合と同様に、LUBによるベースノードの詳細化は、各詳細化対象ノードのオブジェクトからベースノードまでのパスを保証し、それにより段落０４６０の制約を満足することを保証する。そのようなパスが見つからなければ、この制約を適用する実施形態では、同様のオプションを有する。
【0249】
[0484]ベースノードが詳細化対象ノードのオブジェクトのLUBと同じであると、冗長であり、実施形態では、そのような拡張をシンプルな詳細化と考えることを選択する構成であってもよい。
【0250】
[0485]独立的ノードのクロス種類拡張が、すでにオブジェクトである従属的ノードの一般化と共にリクエストされる場合、これらの間に新たなノードを挿入することもできるが、独立的ノードが新たな従属的ノードの直接的オブジェクトによりなる場合は、独立的ノードは既存の従属的ノードの間接的オブジェクトのみからなるものである必要がある。
【0251】
[0486]各従属的エンティティが独立的エンティティに対応付けられ、段落０４６０の制約が適用されている場合、段落０４７５および段落０３５１に記載のプルーフメカニズムを使用することができる（ただし、段落０４７５のメカニズムについては一部変更あり）。ベースノードとLUBの間が区別され、独立的パスについては、様々な実施形態が効果的に詳細化対象ノードのオブジェクトからLUBまでのパスを、LUBからベースノードまでのパスに連結させることができる。ここでも、サフィックスパスをサーバにプルーフの一部として渡し、一回だけチェックすればよいようにする。プルーフパス作成０１１３を使用して、LUBからベース（または必要であれば、フェイル）までの詳細化パスをするルーチンを図１２６に示す。
【0252】
[0487]段落０３６０に記載の懸念が、ここでも問題になる。
【0253】
[0488]段落０４８６のものの他、段落０４７５のプルーフ構造への他の変形例も有効である。ここでは、プルーフは、LUBから、各詳細化対象従属的エンティティについての２つの詳細化パスのベースノードへのサフィックスの形態をとり、該詳細化パスの内の１つは、詳細化対象従属的エンティティまでのもので、もう１つは、LUBまでのものであり、それぞれ同じクロス種類関係により同様に対応付けられているエンティティから始まる。プルーフ生成プロセスは図１２７に示すようなものになる。段落０４６５に示す例では、いくつかの実施形態のプルーフは２対のパスであり、１つは詳細化される各ノードについてのもの（間接的オブジェクトがあるなら、独立的（問題）パスのみ提供が必要）である。ここでの各ケースでは、詳細化対象解決法ノードからローカスノードに向かう解決法詳細化ヒエラルキを辿り、オブジェクト問題において止まることで、現在の操作により作成された新たな問題／解決法のペアに対応する既存の問題／解決法ペアを生成することができる。ノード４８については、従属的パスは、本実施形態では空である。これはそれが直接的に独立的なノード４２と対応付けられている（間に詳細化済みの解決法がない）からであり、本実施形態では独立的パスが［４１，４０］となるのは、これらのステップを４８のオブジェクト４２から辿ると、新たなノード５０のオブジェクト４０に行きつくからである。また、慣習により、最初のノードを暗黙的なものとして扱い、パスには含めていない。
【0254】
[0489]直接的オブジェクトのみによるプルーフ検査プロセスを図１２９に示す。サーバは、各詳細化対象エンティティについて、新たな詳細化済みエンティティの提供されたオブジェクトが、詳細化対象エンティティに続く従属的パスが始まるエンティティからのオブジェクトから始まることを確認する構成であってもよい。
【0256】
[0491]単一のクロス種類の処理のステップとDAG拡張の一般化のステップは、図１１０におけるDAG拡張のアトミック明示的生成４１４1と同様である。これらは、段落０３６２での検討と同様に、間接的オブジェクトによる明示的クロス種類およびDAG拡張の一般化についてのプルーフ作成４１２２、直接的オブジェクトのみよる明示的クロス種類とDAG拡張の一般化のプルーフの生成４１３２、クロス種類DAG拡張の一般化５２０２、を含むクロス種類と拡張の一般化をサポートする意図の上記ルーチンを使用する点と、もしLUB(図１１１および図１１２を使って算出）がベースノードと同じである場合、対応する詳細化操作（例えば、一般化されるノードの種類のもの）に変換するステップを追加する点でことなる。
【0257】
一般化、再言及、および反復[0492]
以下の記載では、問題と解決法を使い、クロス種類関係の「解決法」（および反対方向の「コンポーネント化」）を、それぞれ独立的および従属的な種類について、提示の具体性のみについて検討する。
【0258】
[0493]再言及を段落０４３３に記載のようにアクセスのコントロールに使用され、解決法が異なる団体間で選択的に共有することができる場合、一般的な解決法の特殊化の際だけでなく、具体的なものを一般化する際にも再言及を生成する必要がある。特殊化のケースでは、解決法は、より具体的な問題について再言及され、そして以後の詳細化やコンポーネント化はこのより具体的な問題の専用のものとなる。一般化の際には、同じ２ステップを適用してもよいが、該より一般的な問題の管理者（または権限を有する他のユーザ）に再言及の具体的な問題側でそれを一般化する裁量を与え、過剰な情報が他の具体的な問題により継承されないようにする必要がある。これを行う１つの方法は、２つのステップを別々に行うというものである。まず第１に、該より一般的な問題の管理者が「解決および一般化」ができるものとし、該より一般的な問題をそれらの問題に対して直接的に該具体的な問題の一般化として提示するが、再言及として考慮され（ただし、差異は、一般的な用語を具体的な用語で置き換えること以上でありうる）、恐らく具体的な解決法へのナビゲーションを行い、この操作を一般的な問題から開始することで行う。第２に、管理者は、具体的な問題から「再言及への一般化」を始めることができる場合、該最も一般的な解決法の、具体的な問題のドメインへの論理的再言及を生成するが、再言及の詳細化は技術的に既に生成されているので、この操作は該最も一般的な解決法の再言及として具体的なものの代わりに新たな解決法を散在しつつ、具体的な解決法によりこの新たな再言及解決法の非再言及的詳細化を生成する。
【0259】
[0494]より一般的な問題の管理者は、恐らく一般の個別の特殊化に応じて異なる団体により構成されたいくつかの別個の別個の解決法の一般化をまとめて実行することを所望するかもしれない。このケースでは、管理者はこれらの解決法へのナビゲーションをまとめて行う。第１の上記「解決および一般化」ステップが１回実行され、最も一般的な解決法と、相当の一般性を加えることができ得る各具体的な解決法に対応付けられた技術的再言及を生成する。そして、第２の「再言及への一般化」ステップを各具体的な解決法について１回実行し得る。
【0260】
[0495]ここで、より一般的な問題の管理者が問題に対するハイレベルな解決法だけでなく、各具体的な問題について別個に提案されるコンポーネント問題への解決法も一般化したいと望む状況を検討する。この場合、段落０４６７の再言及に考慮なく提示された例のようにいくつかのコンポーネント解決法へのナビゲーションおよび、一般的問題からの開始することを含む構成であってもよい。実施形態は、一般的な問題ノードからローカスノードまでのパス上の様々なノードを介して、まず最も一般的なハイレベル解決法（およびいくつかの再言及の対応関係）の生成、その後最も一般的なコンポーネント問題（およびさらにいくつかの再言及）、および最後に（この例では）最も一般的なコンポーネント解決法（およびさらにいくつかの再言及）を作成することを繰り返す構成であってもよい。複数のローカスノードがある場合、実施形態は、ベースノードからの１本のパスを介して繰り返すだけでなく、各ローカスノードへベースノードからツリーのトレースも行う。いくつかの実施形態では、ベースノードから始め、ローカスノードへ進むが、他の実施形態は各ローカスノードから始め、ベースノードを処理し、サブパスを横断することを回避する。段落０６８２に記載の提示を用いて、ひとつのアプローチとして、文脈間の各親ノードリストについて遭遇する各文脈フレームを介してベースノードの子孫を反復することを含む。そして、第２ステップを実行し、各特殊化したコンポーネント解決法から開始し、他の反復をそれと一般的な問題との間のパスを介して生成する構成であってもよい。
【0261】
[0496]実施形態では、操作が開始される文脈ノードからローカスノードへ向かって幅第一にトレースし、対応する位置にあるエンティティを一緒に一般化する構成であってもよい。対応関係は、正確なものである必要はなく、凡そであってもよい。特殊化についての反復同様（段落０４１７参照）、パス全体をコピー、または、例えば、詳細化対応関係により接続されたパスのセクションに対応する特定のノードのコピーの何れかをしてもよい。
【0262】
[0497]図１１３ないし図１１９に一般化機能の一例を示す。ここでは、災害予防にかんすうｒうプロジェクトを検討する。図１１３に特定の解決法「支柱に建物を建てよう！」を選択したプロジェクト画面を示す。図１１４に、「複数の反転ツリーの共通文脈を提示」に記載のように、この解決法と、他の解決法「レンガで建物を建てよう！」と共に開くリクエストを示す。共通の祖先が「災害時の人への影響を如何に軽減するか」が可視化され、「一般化解決法を提案」が選択されている図１１５に結果を示す。実施形態は、図１１６に進み、ユーザに、「災害時の人への影響を如何に軽減するか」を解決する新たな解決法「災害の影響を軽減しよう！」の名前の編集を許可し、共通の祖先かローカスノードへのパス上の次の非詳細化子である「山火事の影響を軽減しよう！」と「洪水の影響を軽減しよう」の両方を一般化する。新たなノードは、偶然にも、その既存の親の上にある「山火事の影響を軽減しよう！」の親として位置している。実施形態は、図１１７のローカスへのパスに沿ってノードを一般化していく。続くノード（ローカス）がその親をパスに沿って詳細化するので、図１１８に示す結果から明らかなように、新たなノード「災害に耐えるように適切なインフラを設置しよう！」が直前に生成されたノードを詳細化し、ローカス自体を一般化する。下記のように一般化において再言及を使用する実施形態では、「どのように山火事の際の人への影響を如何に軽減するか？」にナビゲーションする際に、不適切または訳に立たない支柱に関する提案を見ることができない。図１１９に示すように「どのように地震の際の人への影響を如何に軽減するか？」にナビゲーションすると、例えば「建物をスラブにボルト止めしよう！」などの次に詳細化する一般的解決法を見ることができる。
【0263】
[0498]特殊化したプロジェクト（ここでは、「洪水」）の管理者も、追加の一般化の利点を享受したいと願うかもしれない。図１２０に示すように「支柱に建物を建てよう」について「再言及への一般化」を選択し、図１２１に示すように一般化をタイプすることで、享受できる。他の実施形態では、これを他の形態、例えば、新たな、一般化されたエンティティから操作を始めることで、行う構成であってもよい。
【0264】
[0499]特殊化については、クロス種類関係により拡張された如何なるノードに加えて、詳細化されるノードを選択することを可能にする。そのようなノードのそれぞれが継承されていたかどうか、ローカスへのパスにそって、継承されたものが切ら課に特殊化される必要があるかどうかが彰であった。ここで、実施形態は、クロス種類関係により拡張されたノードからローカスノードへのパス上のいずれかのノードに加えて抽象化されるノードをユーザが選択できても、できなくてもよい。さらにノードを抽象化のために選択することができる場合、抽象化はノード自身に関係するか、または、ローカスノードからのパスの抽象化されたパスに関連するものであってもよく、またはユーザはどの処理が所望か特定することができてもよい。
【0266】
[0501]クロス種類拡張による抽象化の反復プロセスは以下のようになる。段落０４９６に提案するように、同じエンティティの種類の連結されたそれぞれのパスについてノードを１つコピーする。まだ到達されていないローカスノードのリストを維持する。第１に、以下の何れかに到達するまでベースノードの子孫の走査を行う。適用された同じクロス種類関係の発生‐実施形態では、この方法で到達された従属的ノードを収集する、適用されたものとは異なるクロス種類関係‐実施形態はフェイルする、ローカスノード‐まだ到達していないローカスノードのリストからこのノードを外す。各収集された従属的ノードにより、詳細化（該実施形態がサポートするなら再言及による詳細化）されると設定された新たな従属的ノードとの新たなクロス種類関係を生成する。各上記プロセスの繰り返しについて、クロスシュルに関係が最初に不定のままであり、子孫の走査において最初に遭遇した時に設定される点を覗いて、もし従属的ノードがあれば、それを独立的ノードと考慮する。このプロセスを図１３１に示す。なお、抽象化の再言及をこのプロセスで生成してもよいが、いくつかの実施形態では、インプレースな更新を行わない。
【0267】
[0502]関係するコンポーネント解決法が複数のセットある場合、上記プロセスをそれぞれについて一度実行してもよいが、ハイレベル解決法の一般化は、第１パスの際のみ実行され、その後再言及が判別される。
【0268】
[0503]明示的な再言及がない実施形態では、具体的なものにナビゲーションし、一般的なものからクロス種類拡張を始め、パスを介して反復する上記基本的な方法もまた適用可能である。
【0269】
特殊化と一般化の合体[0504]
いくつかの実施形態では、特殊化と一般化を完全に別個のものとして扱うが、他では詳細化済みのノードと詳細化対象のノードを共に受領し、クライアントは、個別の選択操作または単位各方向をチェックすることで、サーバは、各従属的ノードと共に方向を受け取るか、単に各方向をチェックする（例えば、検証で第１ステップがフェイルなら、他の方向を試してみる）。
【0270】
[0505]特殊化と一般化の合体により、ノードを詳細化関係にある２つの既存のノード間に配置することを可能にする。これは、段落０４９３に記載の「一般化して再言及する」操作について有効である。
【0271】
[0506]また、特殊化と一般化の合体は、構成（非継承の）ベースノードが変形や拡張され、１つ以上の継承済みのノードが、サブ構造を介してローカスノードに達するパス上で発生するケースについて反復の概念の拡張に有効である。実施形態では、ベースノード上での操作前にこれら継承済みノードのコピーや再言及が所望されるものであるかもしれない。そのようなパス上の構成ノードの直ぐ上の継承ノードのために作成された新たなノードにおけるエンティティは、継承済みエンティティの下かつ次の構成ノードにおけるエンティティの上に配置される必要がある。しかし、これらのケースでは、ベースノードは、常に同じローカスノードから、構成ノードのみを含むパスにより到達可能であり、よって、全ての実施形態でこのステップが必要とされるわけではない。
【0272】
[0507]このケースでは、新たなノードのオブジェクトは、詳細化対象ノードのオブジェクトのLUBではなく、それらのLUBにより詳細化されているだけであってもよく、詳細化済みノードのオブジェクトのGLBではなく、それらのGLBの詳細化をするだけのものであってもよい。実際に、我々の制約下のベースノードは、各詳細化済みノードのオブジェクトを詳細化し、各詳細化対象ノードのオブジェクトにより詳細化されるものである。
【0273】
既存エンティティのDAG詳細化[0508]
実施形態は、既存のエンティティについての詳細化関係の確立をサポートするものであてもよい。ここで１つの動機は、同時詳細化によるクロス種類拡張のプロセスの分解を可能にして、クロス種類拡張をまず行い、１つ以上の詳細化対応付けを後に付け加えることである。その他、社会的革新をサポートし、それにより詳細化対応関係が既存のプロジェクト間で作成されることである。
【0274】
[0509]クロス種類関係におけえる従属的朱里として参加しない種類のエンティティについて、実施形態は任意のノードにおいてエンティティ間の直セエツ的な詳細化対応関係を確立することができる。段落０３３１にて記載する頂上性対応関係の生成を最小限にするため、実施形態は、両方ともサブ構造もしくは両方とも文脈にあり、ローカスノードへのパスにより接続されていないノードにおけるエンティティ間のそのような直接的詳細対応関係を許す構成であってもよい。
【0275】
[0510]もし独立的エンティティが任意で従属的エンティティに割り当てられており、詳細化対象の従属的エンティティがそのようなオブジェクトを（間接的にも）有していない場合、詳細化対応関係の作成後、詳細化済み従属的エンティティのオブジェクト（該当するもがある場合）は、検証する必要なく詳細化対象従属的エンティティの間接的オブジェクトになってもよい。
【0276】
[0511]独立的エンティティが従属的エンティティに割り当てられており、段落０３３７もしくは段落０４６０の制約が適用されている場合は、詳細化対象の従属的エンティティが（間接的にも）オブジェクトを有する場合は、詳細化済みの従属的エンティティもオブジェクトを有し、連結されたノードのオブジェクト間に詳細化関係が、通常は同じ方向で、存在する必要がある。特別なケースとして、もし詳細化対象従属的エンティティと詳細化済み従属的エンティティが同じオブジェクトを有する場合は、詳細化対象従属的エンティティを直接的に、詳細化対象従属的エンティティのオブジェクトを間接的にする。サーバがそのような関係のプルーフを必要としてもよいもし間接的オブジェクトがあるのであれば、これを直接的詳細化対応関係を介してそれらのオブジェクトを接続するノードのシーケンスの形態を取ることができる。そうでない場合は、従属的ノードからそれらのオブジェクトが直接的に接続された祖先までの詳細化チェーンも必要としてもよい。サーバ側でのプルーフの検証は、その他のケースのものと大きく変わらない。
【0277】
[0512]クロス種類対応関係に対して詳細化対応関係を追加する場合（例えば、両方の従属的エンティティが同じクロス種類関係のオブジェクトを有する場合）、これは、詳細化済みの対応関係の独立的エンティティ（詳細化済みの従属的ノードのオブジェクト）、またはその先祖の内の１つ、ローカスを作成し、サブ構造の詳細化済みおよび詳細化対象の従属的エンティティを選択することで、ヒエラルキを用いてこれの特殊化を簡単に行うことができる（これらはしばしば明示的に識別または、例えば、詳細化対象のノードのオブジェクトからローカスまでのパス上の詳細化対象の従属的ノードとしてのそれらのオブジェクトの位置により識別することができる）。プルーフは、詳細化対象の従属的ノードのオブジェクトからローカスに向かって、詳細化対象の従属的ノードに達するまでのパスとして生成される。この公式は、詳細化対象の従属的エンティティは、団体のプロジェクトのエンティティ間、または、２つの団体が関与している場合は、様々な実施形態ではプロジェクトの１つは必ずローカスなので、詳細化されたプロジェクトの団体がから開始される場所に、オブジェクトを有している。この公式の利点は、継承済みのノード間の詳細化対応関係を、上記のように、「DAG拡張の反復」および「インプレース、DAG拡張の反復」により、反復コピー（インプレースまたはその他のもの）を行って生成することができる点である。
【0278】
[0513]独立的エンティティが従属的エンティティに割り当てられていない場合は、実施形態では、拡張について上述したように、ローカスへのパス上の従属的ノードの詳細化チェーンのすぐ後の最初の独立的ノードのになるサブ構造の従属的な詳細化済みノードのオブジェクトを推測する。また、実施形態では、詳細化対象ノードは、そのオブジェクト（上記のように特殊化操作の開始部分に対応するクロス種類対応関係を介して接続されている）の直ぐ下の位置から選ばれる必要があるとしてもよい。詳細化パスは、詳細化済みノードのオブジェクトに達するまで詳細化対象ノードのこのオブジェクトからサブ構造を介してローカスに向かうパスとして取得することができる。
【0279】
[0514]クロス種類対応関係への特殊化の追加の例を、ノード６１へのナビゲーションによる操作の前の状態で、図１３２に示す。ギザギザのラインの各セットは、任意の詳細化パスを示す。ユーザは、サブ構造を介して詳細化対象従属的ノード６６まで探査し、そのオブジェクト６２通り過ぎ、詳細化済み従属的ノード６４に達する。操作後のDAGは図１３３に示すもののようになる。
【0280】
[0515]このプロセス、既存のノード間（サブ構造内）の詳細化によるクライアントDAG拡張０１０６は、この公式を介してサブ構造中の既存のエンティティ間の詳細化対応関係を作成するものであり、図１３４および図１３６に図示する。詳細化対象の両ノードがサブ構造内にあるかを確認することで開始する（これは全てのケースで必要というわけではない）。必要であれば、詳細化済みのノードを詳細化対象のノードから区別する。反復にて上述したように、特殊化のための継承コピー２１０３または特殊化のための継承の再言及２１３３を用いて、継承済みのノードの代わりに新たな構成ノードを得る。次に図５９のプルーフパスの生成０１１３を用いて、詳細化対象のノードのオブジェクト（コピーされた状態）から詳細化済みのノードのオブジェクト（コピーされた状態）までの詳細化パスとしてプルーフを作成する。そして、既存ノード間の詳細化によるアトミックDAG拡張０１２６を用いて、対応関係の生成を行う。操作はサーバーからリクエストされ、もし成功したら、新たな対応関係がローカルのDAGの親子のリンクに記録される。また、詳細化対象ノードのオブジェクトは、上記段落０５１０に記載のように、調整を必要とする（これはサーバーでも同様に必要になる場合がある）。最後に実施形態では、私が詳細化済みノードの下に詳細化対象ノードの下のサブツリーを移動することにより、この操作の結果を明らかにする。
【0281】
[0516]または、他の公式をクロス種類拡張に対して詳細化対応関係を追加するのに使用することもできる。ユーザは、詳細化済みの従属的エンティティと詳細化対象の従属的エンティティに二重ローカスとしてナビゲーションすることができ、それぞれの文脈を探査することで共通の祖先（「複数の反転ツリーの共通文脈の提示」同様）、詳細化済みの従属的エンティティのオブジェクト、および、同じクロス種類関係の、詳細化対象の従属的エンティティのオブジェクトの詳細化の祖先を見つけることができる。プルーフの生成に資するため、詳細化対象の従属的エンティティは、そのオブジェクトを介して進む。この公式は、詳細化対象の従属的エンティティがオブジェクトを持っていない（よって探査では見つけられない）場合、または２つの団体が関与する場合は、対応関係にある択一的なプロジェクトからの２つのノードのへのナビゲーションをする増加的な方法を前提として、詳細化対象のプロジェクトの団体から開始場合に、最も好適または便利である。
【0282】
[0517]次に、図１３２からの同じ最初のDAGのための択一的公式を示す例を検討する（ここでは、詳細化済みの従属的ノード６４と、詳細化対象の従属的ノード６６による）。ユーザは、共通の祖先（６１）へオブジェクト（６２）を介して探査している。
【0283】
[0518]このプロセス、既存のノード（ローカスとして）間の詳細化によるクライアントDAG拡張０１１６は、この公式を介してローカスとしてある既存のエンティティ間の詳細化対応関係の作成をするものであり、図１３５および図１３６に図示されている。また、必要であれば、ここではローカスである詳細化対象のノードから詳細化済みのものを区別する。もしまだ露わにされていないなら、詳細化済みローカス（refinedLocus）と詳細化対象ローカス（refiningLocus）の共通の祖先として文脈中の詳細化済みローカス（refinedLocus）のオブジェクトを露わにすることを試みる。そして詳細化対象ローカス（refiningLocus）のオブジェクトが、詳細化済みローカス（refinedLocus）のオブジェクトへのパス上にあることを確認する。プルーフパスの生成０１１３を用いて、詳細化対象ノードのオブジェクト（コピーされた状態）から詳細化済みノードのオブジェクト（コピーされた状態）への詳細化パスとしてプルーフを生成する。そして、既存のノード間の詳細化を行うアトミックDAG拡張０１２６（拡張DAG連結詳細化クライアントサブ構造に記載）による対応関係の生成を行う。
【0284】
[0519]このアプローチにより、上記のクロス種類拡張と特殊化、または一般化は、２段階プロセスとして示されることができる。第１にクロス種類拡張を生成し、関連する詳細化を追加する。この時点で、実施形態では、拡張操作を、クライアントレベル、サーバレベルまたはその両方のレベルで、特殊化を含むことから排除しても、しなくてもよい。
【0285】
予備サイクル[0520]
任意のノードにおけるエンティティ間にリンクを生成する、もしくは、サブツリーを一方のノードから他方に移動させる（「カットアンドぺイスト」にて記載のように、移動は、１つのリンクを解消し、他のリンクを作成する必要がある）ので、サイクルのの生成の可能性がある。実施形態では、サブ構造や文脈のスクロールをしながら、同じエンティティをずっとスクロールする位置にユーザをあることを望まず、さまざまなステップでこれを回避しうる。
【0286】
[0521]リンクがサブ構造の子から、子からローカスまでのパス上または文脈中の親まで、または同様に、ローカスから親までのパス上またはサブ構造中のの子からの文脈中の親へ、生成されているケースでは、サイクルを生成する危険はない。また、もし両方のノードがオブジェクトを有する場合は、制約チェックでは、サイクルの生成を除外してもよい。しかし、これは、多くの目的の場合では、十分でないかもしれない。
【0287】
[0522]任意のノードにおけるエンティティの連結の際のサイクルの予防のアプローチの１つとしては、１つのノードから他方のノードへのリンクの生成のリクエストがあった時に、親になるノードの祖先または子になるノードの子孫を抹消し、他のノードを探すことにある。遭遇した場合、リンクはサイクルを形成するので、問題を解決する前にリンク操作をしてはならない。
【0288】
[0523]もしリンクされるエンティティがローカスノードであるなら、そのサブ構造や文脈は、すでに、少なくとも一部クライアントに渡されており（段落０３２８参照）、サーチを開始してもよい。もしDAGが非常に大きなものでないなら、このサーチを実行するのは好適であり、必要ならアクセスの延期をトリガするが、そうでない場合は不十分である。もしエンティティがローカスノードでないなら、サーバはサイクルのサーチを実行する必要がある。
【0289】
[0524]実施形態は、如何なるチェックをも行わず、よって、サイクルの形成を許す構成であってもよい。このケースでは、その後サイクルの検知を行ってもよい。ローカル（非延期）DAGに実際にサイクルを形成するのは望ましくないかもしれず、実施形態は、それを予防することを望ましいとしてもよい。これは、最初のDAGおよび展開していない延期ノード上に実際にサイクルがあるかチェックすること、およびリンク操作を許可する前にサイクルがあるかどうかを確認することを含む。実施形態は、これらのチェックをクライアントとサーバに対して行う構成としてもよい。
【0290】
[0525]最初のDAGGおよび延期ノードの展開時におけるチェックを処理するオプションの１つは、クライアントに展開プロセス時にサイクルについてチェックさせることである。クライアントは、文脈をローカスに対して展開する際に、サブ構造（ローカスを含む）またはローカスから展開されるノードまでのまたはその逆の文脈ないのパスの素子についてチェックしてもよい。これは、ノードがセッション中に展開された最初の時にのみ必要であってもよい。もしユーザがローカスノード間の接続をリクエストする場合は、クライアントは、段落０５２３に記載のように、ただし、延期されたノードを拡張することなく、サイクルがないか確認してもよい。クライアントがサイクルを見つけら、クライアントは問題のサーバに通知し、問題のパスを知らせる必要がある。そしてサーバは、グローバルDAG内でパスが本当にサイクルになっているか検証してもよい。いくつかの実施形態では、サーバにサイクルを解消させる構成であってもよいが、他の実施形態では、この操作を許可しない構成であってもよい。サーバは、解消するリンク、例えば、少なくとも信頼できるユーザにより作成されたものを選択する構成であってもよい。さまざまなプロジェクトについて管理者に通知し、問題がどこにあるかについて意見の一致をえることができるようにしてもよい。
【0291】
[0526]また、サーバが同様の初期化チェックをローカライズされたDAGをクライアントに送る前、または延期されたノードを展開した結果を送る前に行ってもよい。
【0292】
[0527]もし複数のクライアントが、介在するリンクなしに、同じ初期深さの同じローカスノードをリクエストする場合は、サイクルについての同じチェックを複数回する必要はない。これらのケースでは、サーバは各エンティティについて「安全な深さ」を保ち、サイクルがその深さにあるこを示すようにすることもできる。構造は、あらたなエンティティがリクエスト（または生成）されるたびに拡張されてもよく、ノードのがそのより深い深さで安全だと証明された後に、深度は増加される。もしリクエストされたノード／深さが安全だたと保証された場合は、サイクルチェックは必要ない。もし深度範囲内のノードがリンクされると、サーバは、両方のノードの従来の安全深度内の全てのローカス記録について安全深度を再設定してもよい。
【0293】
追加のプロジェクト構造[0528]
「一般データセット」にて、どのようにデータセットが、データベースのソース、選択されるデータアイテムについて保持される必要がある状態、およびそれらデータアイテムから抽出された属性値の表現で特殊化されるか、そしてそれらがどのようにユーザによるローカライズされたDAGの探査に基づいてプロジェクトと対応付けされ、集約されるかを説明する。またはデータセットを特定の問題とより密接に並べ、問題が全体的に特定の属性値の加減からなるようにしてもよい。ここでは、そのようなデータセットの特殊化をデータ測定と称す。データ測定により、上記のように、各ノードは、特定のデータアイテムの特定の属性値を返すであろうクエリに対応付けられている。しかし、詳細化対象のデータ測定のアイテムセットは、様々な実施形態では、詳細化済みのデータ測定のそれのサブセットである。よって１つのデータ測定は他を詳細化する場合は、このような実施形態では、それはより少ない選択されたアイテムと対応付けされた属性値を含む。例えば、特定のデータ測定値は、老人、マイノリティなどの特定の人口層の収入増に関係し、もしくは両方を詳細化し、マイノリティ層の老人の収入に関する。また、詳細化データ測定は、追加の属性値を抽出する。データ問題は、問題がその属性の加減を含むか特定する必要があるとしてもよい。上向きまたは下向きの矢印をこれらデータ測定問題のアイコンに組み込んでもよい。
【0294】
[0529]条件の許容できる構造の一例として、それらは、ここの属性値についての制約またはそれらのネスティングについて論理積または論理和でありうる。条件はデータベース、表、および属性を参照する。条件の構造は、実施形態により異なる。簡単な文法は以下のようになる。
【表3】
[この文献は図面を表示できません]
選言肢と連言肢の両方のリストは非秩序化されているが、標準的な秩序化を行ってもよい。論理和または条件として許容できる空値のシンボルを以下に説明する。
【0295】
[0530]いくつかの実施形態では、適用された秩序化の表記の数を減らすために追加の制約を適用してもよい。少なくとも２つの要素を有する論理和と論理積を必要とし、これらが交互になることを必要とする文法は以下のようになる。
【表4】
[この文献は図面を表示できません]
条件の定義は、上記から変化しない。
【0296】
[0531]そのような慣習の維持が望ましいが、ユーザがそれを違反する操作を行うことを許す実施形態では、以下のルールを適用して慣習を回復する。
【表5】
[この文献は図面を表示できません]
ここで、最後の２つのルール、動機付けされた問題2（MotivatedProblem2）は、動機付けされた問題１（MotivatedProblem1）を詳細化する。これらのルールは、シングルトンコレクション、非交互のネスティングのコレクション、埋め込み空条件、および冗長条件を取り除く。追加のルールは、条件リスト（ConditionLists）を上記のような標準の秩序化を用いて整理する。簡略化のため、ここでプランに対して使用される前置表記法に切り替える。これまたは上記文法を修正し、より自然な否定を一般的な条件と考える実施形態では、奇数の否定フォーム内において、詳細化条件が生成されるルールのために、論理和を論理積として扱う、またはその逆を必要とする。
【0297】
[0532]この方向に進むと、条件は論理和標準形（disjunctive normal form (DNF)）、論理積標準形（conjunctive norm form (CNF)）、その他の協定にて維持される。条件を上記のようなシンプルな文法にて入力し、維持することも可能であるが、一方の条件が他方を詳細化するか確認するさいに、それらを標準形に変換する必要がある場合がある。DNFの文法は以下のようになる。
【表6】
[この文献は図面を表示できません]
【0298】
[0533]データ測定問題は、同じ極性（または少なくとも延長された可能性のあるもの、および更なるデータ測定）にて他のデータ測定問題により特殊化される。詳細化データ測定問題は、いくつかの実施形態では、詳細化されたデータ測定問題のものと少なくとも同様に制限された選択されたアイテムを保持する必要がある条件を有する。
【0299】
[0534]「追加の解決法構造：プラン」で説明されたプランによる条件と状況には類似性がいくつかあり、同じ設計のオプションの多くは関連している。条件とは違い、プランには極性や否定表記もない。
【0300】
[0535]データ測定は、より一般的な問題を詳細化する特別な種類の問題であってもよいし、またはどのような問題もデータ測定を追加する可能性があってもよい。
【0301】
[0536]複数の解決法を詳細化する際には、実施形態は、その条件の一貫性についてチェックしてもよい。DAGを、既存の問題ノードを特殊化または一般化する新たな問題ノードで拡張する時、一実施形態は、理想的には、拡張された問題ノードの条件のGLBまたはLUBをそれぞれ提供し、ユーザにそれぞれ厳格性を加減するように編集させる。これは、GLBをＸ∧Ｘ'として、LUBをＸ∨Ｘ’とする条件を形成し、簡略化ルールを適用して好適なフォームを回復することで算出することができる。または、実施形態が採用する条件フォームによっては直接的な算出も導くことができる。例えば、実施形態では、段落０５３０のように、以下の条件を特殊化して、抗体を維持することができる。もしも１つ以上の条件が論理積または条件（シングルトン論理積）である場合、それらの条件の和集合の論理積を形成し、他の論理積からの条件を一般化するもの全てを除く。そして、各論理和を追加の論理積として追加し、他と同じまたは厳密にはより一般的なものであり、追加のまたはより一般的な論理和を有しし、ある論理積を有してなかったり、より具体的な他のものを有するものを除外する。段落０５３２に示すようにDNFを維持するために、前のステップをまず行うか否かに関わらず、実施形態では、各条件を論理積の論理和として取り扱うことができ、それらの論理和のタプルを形成することができる（条件をシングルトンの論理和として扱う）。長さが長くなる順番で整理し、前のタプルの連言肢の全て（または連言肢の一般化）を含むものを除く。条件は論理積の論理和として形成される、各タプルは連言肢のセットを提供する。条件を一般化するプロセスも同様であり、一般化と特殊化のように、論理積と論理和とを逆にしたものである。
【0302】
[0537]１つの可能性は、各データ測定問題とともに条件全体を保存することである。これによりダイナミックに条件を形成する上での複雑さを回避することができる。明白な短所は、必要となる空白の量である。また、条件修正にともない、条件間の必要となる詳細化関係（データ測定問題の詳細化ヒエラルキから導出）を保持するという問題がある。条件について関係は、単に違反してはならないと主張するだけで単純に維持できる。もし（例えば、以下の方法で）条件を編集してより特殊化する場合、結果をその詳細化子に対してチェックし、それらのそれぞれよりもまだ一般的であることを確認する必要がある。より一般的に編集する場合、詳細化親に対してチェックし、また、それらのそれぞれよりも特殊化していることを確認する必要がある。よって、もし条件（または条件の一部）がデータ測定問題への詳細化のシリーズにおいて固定され、後に各位置で変化される必要がある場合は、ユーザはこれらそれぞれを別個に、特殊化の場合は最も特殊化したものから最も一般化したものへ、一般化の場合は最も一般化したものから最も特殊化したものへ、修正する必要があり得る。おそらく、もっとも実際的なのは自動的にこのプロセスを行うことである。このアプローチを採る実施形態では、条件の特殊化の際、その特殊化をデータ測定問題の詳細化子孫を介して、リーフや既に条件が特殊化してるデータ測定問題に到達するまで、伝播させる。同様に、条件の一般化の際には、その一般化をデータ測定問題の詳細化祖先を介して、リーフや上限が既に一般化してるデータ測定問題まで伝播させる。一条件Ｘから他方の修正条件Ｘ’への変化を適用する際に、実施形態では、段落０５３６に記載のように、特殊化の場合、子孫の条件Ｘ’をＸとＸ’のGLBで置き換え、一般化の場合は、それらのLUBで置き換える。また、これは、どちらの方向の伝播でも詳細化済みの問題の条件を詳細化対象問題の条件が詳細化しない場合、既存のデータ測定問題間で詳細化対応関係を生成することを許す。どちらのアプローチでも条件変更はローカスノードについてのみ許可され、サブ構造と文脈DAGを利用可能にする、もしくは、操作はサーバのみにて実行されるものとし、クライアントには、詳細化関係の違反のみを通知、または必要な条件変更全てを通知することを必要とするであろう。
【0303】
[0538]別の訪欧は、条件成分を、お互いと関連し、データ測定問題と関連し、継承に依存するエンティティとして取り扱うことである。よって、エンティティは、論理積と各種の条件を含む（論理和は、論理和標準形が維持される場合は、暗黙的）。様々な種類の関係が、条件成分にてサポートされている：上記したように文法的構造を示す成分関係、条件成分の特殊化／一般化に対応する詳細化関係、詳細化済み条件のターゲットノードの下にサブツリーが再配置されたことを示す移動関係、および、特定の条件成分が明確に識別されていな条件成分を生ずるような方法で取り扱われていることを示す成分関係の一般化である、操作関係。特定のデータ測定問題における条件は、以下の成分子孫を辿ることにより構築されてもよい。全ての条件詳細化対応関係は、以下の点において（インプレース反復において説明したように）再言及として見なされる：もし詳細化対象条件が表示されたら、継承された詳細化済み条件を表示する必要はない、およびもし詳細化対象条件が関係のない問題のものの場合は、表示する必要はない。いくつかの実施形態では、どの問題がローカスであるかについて条件情報をローカルDAGに組み込む構成であってもよい。このケースでは、ローカス問題ノードの先祖や子孫に関係する再言及条件成分、移動対応関係、およびオペレータアプリケーションを表示するのが自然である構成であってもよい。いくつかの実施形態では、ローカル問題DAGをローカル状態DAGから分離し、後者がローカル問題DAG1のローカスの条件の成分のみを含むとしてもよい。実施形態では、以下の段落０５５６に記載のように出たのダイナミックな探査を可能にする目的で、統合したローカルDAGまたはその修正版を維持する構成であってもよい。
【0304】
[0539]暗黙的なGLBは、まとめて詳細化された問題の条件において実行されるので、特殊化操作は、条件の構造に配置されたマーカーにより通知されてもよい。特殊化の操作は以下のものであってもよい。
選言肢（論理積）の合成：この操作は、プランの順番の合成に関連し、ユーザが同じ論理和で継承済み論理積（ベースノードから操作を開始し、他を選択）を詳細化する形をとることができる。DNFでは、選言肢は常に論理積であるが、これは、より一般的な設定の場合でもある。ローカライズされたDAGでは、選択された論理和の連言肢はベースノード論理和に移動され、重複を除き、選択された論理和は除かれる。グローバルなDAGでは、新たな論理和は継承されたものそれぞれを再言及し、その子孫を継承できるようにする。
選言肢の除去：この操作は、プランと何の関連もない。これは、ユーザーが継承済み選言肢を削除する形態を取り得る。DNFでは、そのような選言肢は、常に論理積であってもよいが、より一般的な設定では、どのような条件表示であってもよい。グローバルなDAGでは、この選言肢tは、ローカス問題に関してユーザに表示する必要のない空値条件により再言及される。
連言肢（項）の追加：この操作は、プランについての非秩序化されたリーフの追加に関する。DNFでは、これは、新たな項を有する継承済みの論理積の拡張の形態をとる。実施形態は、単に新たな項を、ローカライズしたDAGの親の下に構造として配置するが、グローバルDAGでは条件は、ローカス問題に対してオリジナルを再言及する新たな論理積の下に構造として配置される。この新たな論理積は、その親のオペランドの継承に加え、新たな項において動作する。より一般的な設定では、関連する操作は、（論理積を生成する必要がない）空の条件下で初期条件を生成する、またはそれ自身の論理積と新たな条件で条件を置き換えるのに使用可能である。
項の特殊化：この操作は、プランについて、動機付けされた問題の再言及に関する。もし一方の項が他方と一致しており、少なくとも同様の情報を含んでいる場合は、一方の項が他方を詳細化する。項の詳細化は、以下のように定義できる。
【表7】
[この文献は図面を表示できません]
この操作は、継承された項をユーザが詳細化する形態を取ることができ、操作は何れかより継承され、他方を同じ論理積から選択する。ユーザは、継承されたベースノード項を編集し、それと、ローカルDAGの選択された条件とを詳細化対象の項と置き換えるが、グローバルDAGではそれらの項のそれぞれと再言及詳細化を生成する。親項のそれぞれでの詳細化は、サーバで検証する構成であてもよく、可能であればクライアントでも検証してもよい。もしクライアントが検証を行うなら、サーバにどの項詳細化ルールが適用されたがを示すこともできる。選言肢の結合：この操作は、プランについての、順番の適用に関し、論理和内の論理積を挿入するものである。連言肢追加のもの処理される自明なケースの場合を除き、DNF（最初の再公式化）には適用されない。ユーザが、この操作を結合する選言肢を選択した後に介する構成としてもよい。ローカルDAGでは、これらは、論理和の子として生成された新たな論理積の子になるように移動されてもよい。グローバルDAGでは、論理積は、ローカス問題に対してオリジナルを再言及する新たな論理和の下の構造として生成されてもよく、そして、「移動」アークは、新たな論理和からオペランド選言肢まで生成され、それらが論理積まで戻ると考慮される。これは、段落０４３８の再言及詳細化についてカッコ内に記載したように、操作が移動アーク上で実行されることに対するローカス問題を保存する実施形態ではより簡単であろう。
埋め込まれた論理積：この動作は、プランについて、埋め込まれた順番に関し、論理積選言肢を兄弟の選言肢の論理和子孫に押し込むものである。これは、DNF（第１再公式化なし）には適用されないが、より一般的な設定には適用される。ユーザは、操作を開始し、ともに論理積の親論理和の子孫としてサブ構造にあるオブジェクト論理積とターゲット論理和を特殊化する。ローカルDAGでは、オブジェクトは除かれて、ターゲットの子となる。グローバルDAGでは、いくつかの実施形態ではそれらの間に移動アークを形成し、ローカス問題を指す。
論理和の抽出：論理積の適切な祖先を有する論理積の論理和連言肢は、その論理積祖先の事して覗かれる。もしそのような祖先がない場合は、条件の根として生成してもよい。
【0305】
[0540]後者のつの操作は「移動」アークを含む。継承の記録２２５０は、図８７のものから変形されて、実施形態が再言及されたノードのを再言及で置き換える場合に移動アークのオブジェクトノードがその文脈から離され、ターゲットノードの下に置かれることを除き、移動アークが再言及同様に処理されてもよい。
【0306】
[0541]対応する一般化操作は以下のようになる：
選言肢の分離（論理積）：ユーザは、全ての連言肢が正である必要がないとするが、その様々な組み合わせがまとまっていることを要求する。これは、ユーザに、一般化される条件中の連言肢のセットをパーティションすることを許すように公式化されることができる。
選言肢の追加 (論理積）：これは、選言肢より開始することができる。ユーザは各連言肢を特定できる。
連言肢の除去：これは除く対象の連言肢から開始することができる。DNFでは、連言肢はつねに条件である。
連言肢の一般化（条件）：これは、同じ論理積からの他の条件を選んで、どの条件からでも開始可能である。
結合分離：論理和直下の論理積ノードは除くことができる。これは、連言肢の除去とは、連言肢が除かれず、論理積の親の論理和の選言肢に統合される点でことなる。
論理積の抽出：論理和の適切な祖先を有する論理和の論理積選言肢は、その論理和祖先の子として移動される。
論理和の埋め込み：この操作は、論理和連言肢を兄弟の連言肢の論理積子孫に押し込む。これはDNF（第１再公式化なし）には適用されないが、より一般的な設定では適用される。ユーザは操作を開始し、論理和の親論理積の子孫としてサブ構造にあるオブジェクト論理和とターゲット論理積を特殊化する。操作の認証に資するため、ターゲットから親論理積へのパスをサーバに渡してもよい。ローカルDAGでは、オブジェクトは移動されて、ターゲットの子となる。グローバルDAGでは、いくつかの実施形態では、移動アークをそれらの間に生成し、ローカス問題を示す。
【0307】
[0542]実施形態は、条件の表示の形式により操作を調整する必要があってもよい。しかし、全ての操作は、条件をより具体的なものとするものでなければならない。よって、特殊化の際の詳細化された条件の否（または一般化の際の詳細化対象条件の正）を保存する必要がある。
【0308】
[0543]操作は、その範囲をいくらか重複していてもよく、またはそのような重複を避けるよう制限されていてもよい。例えば、実施形態では、選言肢の結合をサポートする操作では、少なくとも１つの選言肢が条件である。これは、もしすべてが論理積であった場合は、選言肢の結合の適用と簡素化とは、そのオペレータの下、同じ結果をもたらし、もし論理和や否定があれば、１つはオペレータの適用前に簡素化するからである。同様に、実施形態は、論理積への選言肢の結合と結果の簡素化は選言肢の結合をサポートしなてくもよい。論理和と論理積が交互になる構成が適用された場合、選言肢の結合と、選言肢の合併は１つの操作と考えることができる。
【0309】
[0544]新たなデータ測定問題（データ測定を有する先祖がないもの）についてどのような条件を指定してもよい。データ測定問題を特殊化または一般化する問題は条件成分または、条件の同様に修正する操作を定義する。そのような成分または操作は、権限を有するユーザにより追加または除去されてもよい。特定のデータ測定問題へのナビゲーションは、さらに、様々な無関係の親からの様々な継承済み成分と操作を組み合わせ、そのデータ測定問題について１つのクエリを作成する条件を得ても良い。組み合わされる様々な操作が相互的なもの場合、これは簡単にできる。例えば、論理積は、論理和に埋め込まれる前後に合併または削除されてもよい。問題が複数の詳細化親を持つ詳細化子孫を有する場合、様々な実施形態ではユーザに祖先の問題条件を子孫の他の保谷の条件と衝突するような形で特殊化することを防いだり、子が不一致な条件を有するように作成されることを許容する必要がある。よって、実施形態では、詳細化子が存在している、または詳細化孫は複数の詳細化親を有している場合に問題条件尾修正を許可しないとしてもよく、または修正が他の親の条件と衝突しないときのみ問題条件を許可しないとしても良く、または全く許可しないとしてもよい。
【0310】
[0545]エンティティがデータ測定親を有する場合、関係するデータベースアイテムセットは、まず、詳細化済みのデータ測定のアイテムのセットの交差を取り、そして特定のデータ測定に特異の条件を追加で適用することで、直観的に形成されなければならない。それは、属性値が抽出されたアイテムセットからのものである。データ測定の一般化する際に、まず詳細化対象データ測定のアイテムのセットの集合をとり、そして特定のデータ測定のための条件を適用することで、関連するアイテムのセットを形成する必要がある。各ケースでは、適用される条件は、特殊化または一般化条件により修正されたそのノードまたはその祖先（論理ツーリ上のもの）において追加されたものである。この効果のシミュレーションを、何れかのパスを介して条件成分を継承することで行ってもよい。結果生ずるクエリは、実施形態により最適化されてもよく、直接またはデータソースにより最適されてもよい。
【0311】
[0546]データ測定およびそれぞれに対応付けられているエンティティとして状態を示している最初の例のDAGを図１３７に示す。ここでは、６つのデータ測定問題ノード（８０ないし８５）を有し、円形にて示しており、事前に定義され、２つの論理積の論理和からなる８０の条件を有し、第１には２つの項が、第２には１つ項がある。外側の論理和を暗黙的として処理し（DNFとしては自然に）論理積をそれらの標準シンボルで示し、条件をその内容を記載した長方形で示した。インデントの文字は、属性名を示す。条件ノードから論理積のノードへのアークは「論理積」を示して「Ｃ」とラベルされている。ノード８０は、条件（（ｘ≠５）∧（ｘ＞３））∨（ｙ＝２）。図１３９は、データ測定問題８１、詳細化対象問題８０を示し、両方の論理積を継承しているところを示している。もし２つの項（ｘ≠５）および（ｘ＞３）が、上記第１と第５項の詳細化ルールに則り項の特殊化により（ｘ＞６）に詳細化された場合、ローカライズされた結果は図１４０に示すもののようになる。ノード８１は、条件（ｘ＞６）∨（ｙ＝２）に対応付けされている。図１４１は、データ測定問題８２、詳細化問題８１を示し、修正された論理積を継承した状態を示している。もし、第１（ここでは、自明）論理積ｘ＞６が選言肢の除去を適用することにより除去された場合、ローカライズされた結果は図１４２に示すようになり、第１論理積は空値シンボルで置き換えられている。空値シンボルまたはその下の項もユーザにか可視ではない。ノード８２に対応付けられている条件は単位ｙ＝２である。もしその代わりに、ノード８０を詳細化するノード８３を、図１３９に類似の図１４３に示すように、詳細化するが、連言肢の追加ルールを第２論理積に適用し新たな項Ｚ≠３を生成する場合は、ローカライズされた結果は図１４４に示すようなものになる。ノー８３は、条件（（ｘ≠５）∧（ｘ＞３））∨（ｙ＝２）∧（ｘ≠３））と対応付けられている。図１４５に、データ測定問題８４、詳細化問題８３を示し、両方の論理積を継承している状態を示す。２つの論理積が選言肢の合併を適用することで合併される場合は、その結果は図１４７に示すようなものになる。ノード８４は、条件（ｘ／５）∧（ｘ＞３）∧（ｙ＝２）∧（ｚ／３）と対応付けられている。最後に、データ測定問題ノード８５が８２と８４を詳細化する。条件（ｘ＞６）∧（ｙ＝２）∧（ｚ≠３）が割り当てられらているが、各親の条件の下界ではあるが最大下界ではない。最大下界（ｘ／５）∧（ｘ＞３）∨（ｙ＝２）∧（ｚ≠３）も達成可能である。
【0312】
[0547]これらすべての操作の後のグローバルまたはノード８０からの結果は、図１４６に示すもののようになる。条件ノードが、（上記のルールの１つを用いて）詳細化データ測定についての前回の条件の再言及と考えられる場合は、条件ノード間のアークは「Ｒ」とラベルされる。ノード８２から第１論理積を除く際に、空値論理積を、ノード８２に対する第１論理積ノードの再言及として生成する。また、追加の項Ｚ≠３をノード８３からの第２論理積に生成する際にはノード８３に対して親論理積を再言及し、その下に新たな項が構築される中間論理積ノードがある。ここで、継承の記録２２５０を使って、図８７のもの同様に、ノード８１、８２、８３、８４、または８５の何れかへのナビゲーションすると図１４８、図１４９、図１５０、図１５1、図１５２それぞれに示すようなローカライズされたDAGサブ構造を示す。注目すべきは、このプロセスを介して組み合わされた条件成分は、条件詳細化ルールのローカルな適用からの得られたものと適合する点である。例えば、ノード８０は、「Ｃ」とのみラベルされた８０の子孫から構築されることができる条件（ｘ／５）∧（ｘ＞３）∨（ｙ＝２）とまだ対応している。ノード８２にはない削除された論理積は、８４を介して８５に継承され、ノード８５の条件は（ｘ／５）∧（ｘ＞３）∧（ｙ＝２）∧（ｚ≠３）を留める。
【0313】
[0548]他のDAGの最初の例を図１５４に示す。ここでは、項は、単にインデントの変数として示されており、論理和は明示的に特殊化かされている。ノード９０は条件（ｔ０∨ｔ１∨（ｔ２∧ｔ３）∨（（ｔ４∨ｔ５）∧ｔ６））と対応付けされている。図１５６にデータ測定問題９１、詳細化対象問題９０を示し、フル条件表現を継承している様子を示す。選言肢の結合を適用して、２つのトップレベルの選言肢t0およびｔ１が「結合」して（t0∧ｔ１）になった場合、ローカライズされた結果は図１５７に示すもののようになる。または、図１５６に類似の図１５８に示すように、ノード９０を詳細化するノード９２についての条件を特殊化するが、論理積を埋め込むルールを適用し、トップレベルの論理和の第１論理積子をソースとし、第２論理積子の論理和子をターゲットとする場合、ローカライズされた結果は図１５９に示すもののようになる。ノード９２は、条件（ｔ０∨ｔ１∨（ｔ４∨（ｔ２∧ｔ３）∨ｔ５）∧ｔ６））と対応関係にある。最後に、データ測定問題ノード９３は９１と９２を詳細化する。また、それは、２つの親の条件のGLBである条件（ｔ０∧ｔ１∨（ｔ４∨（ｔ２∧ｔ３）∨ｔ５）∧ｔ６））と対応関係にある。
【0314】
[0549]全ての操作の後のグローバルまたはノード９０からの結果は、図１６０に示すようなものになる。条件ノードのアークは、詳細化データ測定について事前の条件の再言及と考慮された場合は「Ｒ」とラベルされ、矢印の頭から矢印の尾のノードまでの条件表現サブツリーの移動（上記のルールの１つを使用）を示す場合、「Ｍ」とラベルされる。ノード９１から追加の論理和（ｔ０およびｔ１）を生成する際に、新たな論理積ノードのによりノード９１に対して再言及された中間空値項ノード（ユーザには見えない）がある。ここで、ノード９３へのナビゲーションは、継承の記録２２５０を使い、図８７のものと同様であるが、図１６２に示すようなローカライズされたDAGをもたらす。
【0315】
[0550]いくつかの実施形態では、段落０５２９または段落０５３０の文法や同様のものの形態でオペレータアプリケーションからえら得る追加の条件構造を、上記した標準再言及と移動アークそして空値ノードと共に保存してもよく、他の実施形態では、段落０５７０のものように、オペレータのアプリケーションを、条件成分としてより直接的に、それらのオペランドに対するアークと共に保存することを選んでもよい。この場合、条件オペレータアプリケーションノードも、それらが適用される問題を指摘し、各オペレータの語義は、継承の記録２２５０内に実装される。空値ノードφは、シングルオペランドへの削除オペレータの表示として閲覧される。図１６１は、図１６０のオペレータノードを有する代替
バージョンである。中間フォームは、移動自体を操作として扱い、そのようなノードを３つ含む。操作はオペランドなどのオペレータアプリケーションを指すことで直列になっている。そのようなオペレータアプリケーションのチェーンは、継承の記録２２５０により実行され、選択した文法にて表現を構築する。そして、解決方法の複数の継承（つまり多数対多数の関係refinesSolution）は、詳細化された解決法に秩序化が適用されることを必要とするか、好ましくは詳細化解決法のオペレータアプリケーションが、詳細化済み解決法のオペレータアプリケーションの実行順序に依存しないことを必要とする。上記第１例では、同じノードに関与するルール連言肢の除去とルール選言肢の合併を有した。いくらか直観に反して、ノード８５にて継承されたこれら操作を合併する際に、この実施形態では、削除された論理積を合併し、新たな合併された論理積は削除された親の連言肢を含んでいる。詳細化済みノードの条件が成功裏に解決できることが可能であるとはかぎらない（常に否だる条件以外は）。
【0316】
[0551]実施形態は、例えばこの例でノード８２および８４を特殊化する８５のように、複数の親を特殊化するノードのために、詳細化済みノードの条件の最大下界を得ることができる。継承された条件成分と操作を、それらが関係する問題ノードでマークすることにより、実施形態では、ノードを、全ての親により削除された時のみ特殊化ノードの条件で削除できる。同様に、実施形態では、ノードを削除したこれら親による場合のみ、項の特殊化を無視できる。
【0317】
[0552]段落０３８５に記載のように、継承する条件成分の結果は、一部の情報のみが活用可能であることであり、これはこの目的では許容できないものである。データ測定を有する如何なる問題も、継承プロセスの間に条件についてサーチされた文脈を有する必要があり、これは実際には、根条件がそのように認識できる限り過剰であってはならない。
【0318】
[0553]複数の属性抽出表現が存在する場合は、分けて表示してもよいし、何らかの方法で一緒にまたはまとめて表示してもよい。１つ以上の表現が位置としてタイプされた場合、残りの表現は、段落０７４２に記載するように、マップ上に提示することができる。もし、１つ以上の表現がタイムスタンプとタイプされている場合、残りの表現は、アニメーションを介して提示することができる。より一般的には、もし１つ以上の表現が連続する数量なら、その他は、これら表現を軸にしたグラフのプロットとして提示することができる。定量値は、とりわけ、カウント、合計、平均、最低値、および最大値などの標準の集合に依存するものであってもよい。これら標準は、導出された属性値を表現するのに使用できる。例えば、問題は、２つの人口層の間の収入ギャップを最小限化することに関する。これは、各層の平均収入の差として特殊化し、算出することができる。属性抽出表現の評価の結果は、しばしば、様々な周期性と共に、時間ベースの情報として提示するのが最もよい。
【0319】
[0554]同じアイテムを何度もカウントすることが望ましくない実施形態では、フロンティアにおいて定義、またはフロンティアにより継承されたデータベースのみ、つまり、サブ構造または文脈ツリーのリーフのセットのみが、集合に関連し、この集合はサブ構造や文脈ツリーとは別に実行されなければならない。それでも、複数のリーフノードを介して同じアイテムを２重にカウントしないように注意しなければならない。文脈とサブ構造の両方がデータ測定問題を含む場合、実施形態は、サブ構造フロンティアにより示されたアイテム、文脈フロンティアにより示されたアイテム、文脈フロンティアにより示されたものとサブ構造フロンティアにより示されたものとの間の際、またはこれらの組み合わせに関する属性値を算出し提示する構成であってもよい。
【0320】
[0555]データ測定親について抽出された属性値をどのように組み合わせるか、特にそれらが異なる属性に関する時にどのようにするかという問題が残る。これは、極性が合うならば
加算や乗算、極性が合わないのであれば、減算や除算などの含む様々な方法で行うことができる。加重平均のある態様もしばしば好適である。加重係数は自動的に決定され、ユーザが明示的に設定した、平均に対する様々な属性の効果（恐らく各属性値を維持することで）、またはその組み合わせを正規化する。
【0321】
[0556]各問題を有するフル条件を保存するか、または条件成分を保存し継承するかについては、各データ測定問題の条件を取得し、これは何れかのローカスノードに対応したデータを提供すれば十分である。増加的に提示を構築することもできる。例えば、上記第１例にて図１４８から図１４９、そして図１５２へ、または図１５０から図１５１そして図１５２へ進む時にクライアントに継承の記録２２５０を増加的に適用させ、結果を解釈するより、実施形態は、状態（選択されたアイテムについて必要な場合は減少reductionを表現）について差異がある問題間の詳細化対応関係をラベルするように構成されていてもよい。このラベリングは、詳細化対応関係が生成された時にサーバにて実行されてもよい。各データアイテムがそれが満足する選言肢のセットでラベルされている場合、もしある選言肢の項が詳細化対象問題により、その問題を暴露するためにサブ構造を拡張している際に、特殊化してデータアイテムセットを取得するなら、実施形態は、その選言肢を満足するだけの親データアイテムセットエンティティから除くことだけを考慮する必要がある（ただし、実施形態は、その選言肢を満足するエンティティを再計算してもよい）。同様に、サブ構造を縮小してその問題を隠して際に、実施形態は、どの追加のエンティティを含めるかを決定する際にその選言肢を考慮することのにを必要とする。各内部ノードまたは属性抽出結果についてのデータアイテムは、内部ノードについて維持し、サブ構造の縮小の際に素早く回復できるようにしてもよい。同様の概念文脈の探査に適用されう。図１５３は、第１条件の例のラベル付けされたグローバルDAGを示す。ノード８１における項の特殊化は、新たな項が満足されない限り、第１選言肢からのみ到達できる全てのアイテムを除去する命令につながる。ノード８２にいて選言肢の除去を適用すると、資格なしに第１選言肢からのみ到達できる全てのアイテムを除去する命令につながる。ノード８３にて連言肢の適用は、新たな項が満足されない限り、第２選言肢からのみ到達できる全てのアイテムを除去する命令につながる。ノード８４における選言肢の合併の適用は、実施形態はに選言肢を連言肢のように扱うことを強制し、両方の選言肢を満足しない全てのアイテムを除去する命令に繋がる。そのようなラベリングは、実際、新たなものが（一般化によりまたは既存尾エンティティリンクすることで）追加され、より一般的な問題に対する他のアークについて親の条件が子に対して詳細化されると、維持される構成であってもよい。複数の親データ測定問題が詳細化されると（この例のおけるノード８５の構築などで）、各詳細化対応関係は、選択されたアイテムの十分な減縮でラベルされ、理想的には各データ測定の問題から、その最大下界を生成してもよい。追加のオペレタータの場合、これは、任意の親について「抜けている」操作を埋めることを単に含むものであってもよい。連言肢ｚ≠３の追加の適用に対応する右側の縮小は、よって、ノード８５に到達する直前に左側にコピーされる。選言肢の除去は異なって処理される。左側のみに現れるが、右側には現れないので、当該選言肢は、右側で合併され、GLB条件を達成し、削除された選言肢は追加されて戻され、特殊化が削除済みの選言肢ものに関するので、それは含まれる必要がない。これは、これらアイテムがｘ≠５とｘ＞３の両方を満足していないことを資格なしで除去することに繋がる。
【0322】
[0557]これら増加操作は、クライアントまたはサーバ側にて実行されてもよく、ユーザの探査コマンドに応答して実行されても、その前に実行されてもよい。
【0323】
[0558]プラン同様、既存の問題間の詳細化対応関係を生成するために、実施形態はそれらの条件の論理詳細化（同じ方向）を検証してもよく、おそらく詳細化問題の冗長な条件を除去してもよい。その他の実施形態では、このリンキングが詳細化対象ノードに対して利用可能な詳細化済みノードの条件を（それらが相互に一致している限り）生成する意図であってよい。前者は、各問題とフル条件を保存するのにより好適であり、後者は条件成分を保存するに好適である。しかし、詳細化問題がデータ測定を有し、詳細化対象問題が新たなデータ測定を適宜する場合、状況は、フル条件を保存する時とより類似し、同様に処理される必要がある。
【0324】
追加解決法構造：プラン[0559]
いくつかの実施形態では、解決法により動機付けされた問題のいくつかについて秩序化を行う構成であってもよい。それらは、全く非秩序化された、完全に秩序化されている、または秩序化されたものおよびされていないもののコレクションのどのようなネスティングであってもよい。単純な文法の一例は以下のようになる。
【表8】
[この文献は図面を表示できません]
【0325】
[0560]いくつかのそのような実施形態では、適用された秩序化の表現の数を減らす追加の制約を適用してもよい。動機付けされた問題は、非秩序化された、秩序化されている、または２つ以上の要素の秩序化されたものと非秩序化されたもののコレクションの如何なる交互のネスティングとして考慮されてもよい。文法の一例は以下のようになる。
【表9】
[この文献は図面を表示できません]
簡略のため、上記文法は曖昧になっている。また、標準の秩序化を非秩序化されたプラン引数（UnorderedPlanArgss）に適用してもよい。
【0326】
[0561]そのような実施形態のいくつかでは、ユーザに秩序化されたプラン引数（OrderedPlanArg）または非秩序化されたプラン引数（UnorderedPlanArgs）に２つ以下のプランを残し、交互の制約等を違反するアクションを取ることを許す。これは、これら制約を回復する簡略化ルールを適用する。
【表10】
[この文献は図面を表示できません]
少なくとも２つのルールでは、動機付けされた問題2（MotivatedProblem2）は動機付けされた問題1（MotivatedProblem1）を詳細化する。これらルールは、シングルトンコレクション、交互でないネスティングコレクション、空のプランを埋め込み、冗長な動機付けされた問題を取り除く。追加のルールは、上記のように標準の秩序化を使って非秩序化されたプラン引数（UnorderedPlanArgs）を整理する。
【0327】
[0562]、なお、動機付けされた問題（MotivatedProblem）を解決する実施について選択された各解決法と時間的予想とを対応付けることで、ガントチャートを示すことができる構造を形成でき、そのように表示してもよい。
【0328】
[0563]明示的なプランがない解決法は、その動機付けされた問題の非秩序化されたプラン（UnorderedPlan）を有していると仮定される。
【0329】
[0564]解決法がプランを有するなら、様々な実施形態では、詳細化対象の解決法は、できるだけ具体的でないプランを有し、例えば、少なくとも詳細化済みの解消法の動機付けされた問題と、少なくとも同じ秩序化の制約を有しているが、それ以上でもよい。
【0330】
[0565]プラン間には類似性があり、「追加問題構造：データ測定」にて記載した状態と多くの同じオプションが関係している。プランとは違い、条件には順番はない。このセクションの多くの例は、プランに関して直観を提供するものである。
【0331】
[0566]プランは、より一般的な解決法を詳細化する特別な解決法であってもよく、または如何なる解決法がプランを追加する可能性を有していてもよい。
【0332】
[0567]複数の問題を詳細化する際には、実施形態では、それらのプランの一致性をチェックしてもよい。一方のプランが他方のプランを実施するのに特定の動機付け問題を有していたり、別のプランが他のものに従うのにその動機付け問題を必要とするならば、プランは一致しない。既存の解決法ノードを特殊化するまたは一般化する新たな解決法ノードにてDAGを拡張する場合、実施形態では、理想的には、拡張する解決法ノードのプランのGLBまたはLUBそれぞれを提供し、ユーザにそれらをそれぞれより厳格に、またはより厳格でないようにするように編集することを許す必要がある。いくつかの複数のプランのGLBは、いくつかの実施形態では、それら動機付けされた問題の集合（ただし、それらを詳細化する動機付けされた問題の代わりにより詳細化された動機付けされた問題を除く）と、問題に関する秩序化制約の集合とを有する。これは、シングルの非秩序化されたプランに、非秩序化されたプランの全ての要素を、秩序化されたプラントとに集めることで達成される。そして、表現は、共通のプレフィックスまたはサフィックスをファクター化することで向上できる。よって、プランが||(‡(Ａ、Ｋ．Ｘ），‡（B, K, Y)なら、‡（||（A、Ｂ）、Ｋ、||（Ｘ，Ｙ））を得ることができ、これは、もしＡおよびＢ、またはＸおよびＹが詳細化関係にあるなら、さらに簡略化できる。プラン||(‡（Ａ，Ｋ，Ｗ，Ｘ）、‡（Ｂ，Ｃ，Ｋ，Ｙ））なら、‡（||（Ａ，‡（Ｂ，Ｃ）），Ｋ，||（‡（Ｗ，Ｘ）、Ｙ））を得ることができる。
詳細化済みの動機付けされた問題を、それらの詳細化する動機付けされた問題をの代わりに除く際には、ローカルに詳細化チェックを行い、延期された問題ノードが拡張されるにつれそれを強化する点には、何も支障もない。複数のプランのLUBは、いくつかの実施形態では、それらの動機付けされた問題の交点を有し（ただし、それらを詳細化する動機付けされた問題の代わりに詳細化対象の動機付けされた問題を除く）、これらの問題に関して秩序化の制約の交点を有する。上記は、論理積として、非秩序化されたプランを暗黙的に取扱っているが、いくつかの実施形態では、段落０５３６の条件のように、論理積と論理和ともに明示的にサポートすることでより精度を高める構成であてもよいが、ただし、論理積は論理和を特殊化し、秩序化されたプランは論理積を特殊化している。
【0333】
[0568]１つの可能性は、段落０５３７に記載の条件を有する状況と同様に、各解決法と共にフルプランを保存することである。
【0334】
[0569]代替の構成としては、お互いと解決法と関連し、継承されているプラン成分をエンティティとして扱うことである。よってエンティティは、秩序化されたものと非秩序化されたものとのコレクションと、動機付けされた問題を含む。様々な種類の関係がプラン成分にてサポートされている：上記のような文法的構造を示す成分関係、プラン成分の特殊化／一般化に対応する詳細化関係、サブツリーが詳細化済みのプランのターゲットノードの下に再配置されたことを示す移動関係、および、特定のプラン成分がある方法で処理され、明確に識別されていないプラン成分を生成することができることを示す成分関係の一般化であるオペランド関係などがあげられる。特定の解決法のプランは、その成分子孫を辿ることで構築できる。全てのプラン詳細化対応関係は、継承された詳細化済みのプランは、もし、詳細化対象プランが表示される場合、表示されてはならない点、詳細化対象プランが、無関係の解決法についてのものなら、表示される必要がないという点について、（インプレース反復にて記載した通り）再言及として考慮される必要がある。いくつかの実施形態では、プラン情報を、解決法がローカスであるローカルDAGと結合させる構成であってもよい。このケースでは、ローカス解決法ノードの同じ祖先または子孫に関係した、再言及プラン成分、移動対応関係、およびオペレータアプリケーションを表示するのが自然であろう。いくつかの実施形態では、ローカルプランDAGからローカル解決法DAGを分離し、後者を、ローカル解決法DAGのローカスについてのプランの成分のみを含むものとしてもよい。
【0335】
[0570]まとめて詳細化されるアプローチのプランについて暗黙的なGLBが実行されるにつれ、特殊化操作は、プランの構造に置かれたマーカーによりマークされる。実施形態はユーザに、追加の構造を提供し、よって解決法を詳細化するプランを制御する特定の操作を提供してもよい。
秩序化の合併：これは、ユーザが、同じ非秩序化されたプランにおいて、継承された秩序化されたプラン（操作をベースノードから始め、他の選択する）を詳細化する形態をとる。対応する操作である選言肢の合併とは異なり、ユーザは、交互の秩序化されたプランから要素の、関連する秩序化に関する追加情報を提供してもよい。実施形態では、例えば、ユーザに、データノードの秩序化プランの要素間の位置に、それぞれ残りの秩序化られたプランの各要素を引き込むことを許してもよい。ローカルDAGでは、選択された秩序化されたプランの要素は、重複を避けつつベースノードの秩序化されたプランそれらの適切な位置に移動され、選択された秩序化されたプランが除かれる。グローバルDAGでは、新たな秩序化されたプランは、それらの継承されたものそれぞれを再言及し、それがそれらの子孫を継承できるようにする。このケースでは、追加の秩序化情報、例えば、詳細化された秩序化されたプランの各要素の、より大きな詳細化対象の秩序化されたプランを提供するために、再言及の特別なフォームが必要とされる。
非秩序化されたリーフの追加：プラン構造が空の場合、所定の問題で置き換える。もしプラン構造が動機付けされた問題（MotivatedProblem）または秩序化されたプラン（OrderedPlan）の場合、それを両方の要素を備えた新たな非秩序化されたプラン（UnorderedPlan）で置き換える。プラン構造が非秩序化されたプラン（UnorderedPlan）の場合は、ローカライズされたDAGにある親の下の構造としてその新たな項を単に配置するが、グローバルDAGの場合は、その項をローカス問題に対してオリジナルを再言及する新たな秩序化されたプランの下に構造物として配置する。この新たな秩序化されたプランは、その親のオペランドの継承に加えて、新たな項について動作してもよい。
動機付けされた問題の特殊化：この操作は、既に利用可能なので、明示的にする必要はない。ユーザは、動機付けされた問題を、詳細化対象解決法により継承されたものとして再言及すればよい。
順番の適用：この操作は、非秩序化されたプラン（UnorderedPlan）の要素に対して秩序化を適用するものである。ユーザは、この操作を、非秩序化されたプランの子を秩序化するために選択した後に開始してもよい。これは、ユーザに既存の非秩序化されたリストと、新たな、空の秩序化リストを閲覧させ、選択された要素を第１から第２へコピーするように構成することができる。要素は、コピーされた順番で第２リストに挿入されてよいし、ユーザは、それらを新たなリストの特定の位置にドラッグしてもよい。または、ユーザは、全ての要素が既にコピーされている新たなリストのみを閲覧し、要素を交換したり、順番を変えたり、要素を削除することができる構成としてよい。いずれの場合でも、いくつかの実施形態では、ローカルDAGでは、簡略化が必要なある要素をそれらの要素の秩序化されたプラン（OrderedPlan）と置き換えてもよい。グローバルDAGにおいては、秩序化されたプラン（OrderedPlan）は、（追加非秩序化されたリーフ（AddUnorderedLeaf）同様）ローカス問題に対してオリジナルを再言及する新たな非秩序化されたプラン（UnorderedPlan）の下に構造として生成され、そして「移動」アークが新たな秩序化されたプラン（OrderedPlan）から、非秩序化されたプラン（UndorderedPlan）の要素まで生成され、これが秩序化されたプラン（OrderedPlan）に戻ったと考慮されることを示す。これは、段落０４３８に再言及詳細化についてカッコ書きで記載されたように、移動アークについて操作が実行されるものに対してローカス解決法を保存する実施形態において、より簡単に実行可能だろう。
埋め込まれた順番：この操作は、既存の秩序化をいくつか取り、構造の奥に押し込む。これは、以下のように構成されることができる。ユーザは、オブジェクトとして、秩序化されたプラン（OrderedPlan）を選択し、ターゲットとして非秩序化されたプラン（UnorderedPlan）を選択する。両者は、秩序化されたプランの親の非秩序化されたプランの子孫としてサブ構造にあり（秩序化されたプラント非秩序化されたプランを交互にすると仮定。そうでない場合は、最も近くの非秩序化されたプランの祖先）、ターゲットは選択されたオブジェクト内に含まれていない。ローカルDAGでは、オブジェクトは、移動されてターゲットの子となる。グローバルDAGでは、いくつかの実施形態では、それらの間に移動アークを生成し、ローカス解決法を示す。もしターゲットの選択についての制約が緩和され、ターゲットが、オブジェクトの親として配置された非秩序化されたプラン（UnorderedPlan）からの子孫でなくてもよくなれば、操作は解決法の詳細化として機能しなくてもよい。
【0336】
[0571]後者の２つの操作は、段落０５４０に記載のように、「移動」アークを導入するものである。
【0337】
[0572]対応する一般化操作は以下のようになる。
秩序化の分離：ユーザは、秩序化されたプランの要素は、それぞれに対して秩序化されてはならないが、それらの様々な組み合わせは秩序化される必要がある。これは、ユーザに、一般化する秩序化されたプランの要素のセットをパーティションすることを可能にすることで構成される。
プランの除去：これは除去されるプランから開始される。
動機付けされた問題の一般化：問題の一般化の再言及は、既にサポートされている（「一般化、再言及および反復」参照）。
順番無視：非秩序化されたプランの直下の秩序化されているプランノードは、除去可能である。これは、秩序化されている要素が除去されないが、秩序化されたプランの親の非秩序化されたプランの要素に組み込まれる点でプランの除去とは事なる。
順番の抽出：非秩序化されたプラン内の秩序化されたプランで、秩序化されたプランの適切な祖先を有しているものは、移動されてその非秩序化されたプランの祖先の子となる。
【0338】
[0573]実施形態では、プランの提示の形態により操作を調整する必要があるとしてもよい。しかし、全ての操作は、プランをより具体的にするものでなければならない。よって、動機付けされた問題が秩序化の制約の充足の失敗を必ず保存する必要がある。
【0339】
[0574]操作は、その範囲がいくらか重複してもよいし、そのような重複を避けるように制限されていてもよい。例えば、秩序化の合併をサポートする実施形態は、もしすべてが秩序化されたプランの場合、順序の適用と簡素化は、そのオペレータの下の場合と同じ結果をもたらし、非秩序化されたものがあれば、オペレータの適用前に簡素化できるので、秩序化された少なくとも１つの非秩序化プランが項であると仮定してもよい。同様に、秩序化されたプランに対する順序の適用をサポートし、結果を簡素化する実施形態では、秩序化の合併をサポートする必要はない。秩序化したプランと非秩序化したプランを交互にすることで、順番の適用と秩序化の合併は１つの操作と考えることができる。
【0340】
[0575]プランを有する祖先がない解決法について、どのようなプランを特殊化してもよい。プランで解決法を特殊化、または一般化する解決法は、同様にプランを修正する条件成分または操作を定義するものであってもよい。特定の解決法へのナビゲーションは、さらに、様々な継承された成分と操作を組み合わせてその解決法に対するプランを得ることを含む。組み合わされる様々な操作が相互的なものの場合、これは簡単に行うことができる。例えば、秩序化されたプランは、非秩序化されたプランに埋め込まれる前後に合併されてもよい。解決法が複数の詳細化親を有する詳細化子孫を有する場合、様々な実施形態では、子孫の他の親と衝突するように祖先の解決法のプランを特殊化することをユーザにさせないか、子が不一致のプランを有してもよいとする必要がある。よって実施形態では、詳細化子が存在する解決法のプランや、詳細化子孫が複数の詳細化親を持つ解決法のプランに対する修正を許さない構成であってもよく、または修正が他の親のプランと衝突する場合のみ修正を許さない構成であってもよく、全く修正を許さない構成であってもよい。
【0341】
[0576]文法オブジェクトの構築方法は１つだけあることが好ましい。ユーザのインタフェースレベルでの操作については問題ではないので、これら操作はより表現的であってもよく、段落０５７０に記載のもののように翻訳されてもよい。例えば、ユーザインタフェースを介して、リーフを秩序化されたプラン引数（OrderedPlanArgs）の位置に直接追加することも可能である。
【0342】
[0577]いくつかの実施形態では、上記に概略を示したように、標準再言及と移動アークと空値ノードと共に、段落０５５９または段落０５６０の文法の形態、または同様のものの形態でオペレータアプリケーションの結果である追加のプラン構造を保存しても良い。他の実施形態では、段落０５７０に記載のような、オペレータのアプリケーションをより直接的にプランの「成分」として、それらのオペランドへのアークと共に保存することを選んでも良い。この場合、プランオペレータアプリケーションノードも、それらが適用される解決法を指し、各オペレータの動作も継承の記録２２５０内に実装される。空値ノードφは、削除オペレータの信号オペランドへの提示として提示される。操作は、そのようなオペレータアプリケーションノードをオペランドと示して、直列で行われてもよい。そのような継承されたオペレータアプリケーションのチェーンは、継承の記録２２５０により実行され、選択された文法での表現を構築する。その場合、解消法の複数の継承（つまり、多数対多数である関係詳細化解決法（refinesSolution））は、秩序化を詳細化済み解決法に適用することを必要とし、好ましくは、詳細化対象解決法のオペレータアプリケーションが、詳細化済み解決法のオペレータアプリケーションの実行の順番に依存しないことを必要とする。いくつかの実施形態では、秩序化されたプラン引数（UnorderedPlanArgs）の秩序化を標準化するのがこれを行うのに役立つであろう。詳細化済みノードのプランの解消が成功できるかどうかは確証がない。二要素の非秩序化されたプランに異なる秩序をことなるブランチが交互に適用する単純なケースを例に取ると、それらは合併できない。
【0343】
[0578]継承プランの成分の結果は、段落０３８５に記載のように部分的情報のみが活用かのうであるいうものであるが、これはこの目的では許容できるものではない。プランがある解決法は、どのようなものでも、継承プロセス中にプランの定義の検索する文脈とが必要であり、実際に、根プランがそのように識別可能である限り過度であってはならない。
【0344】
[0579]解決法詳細化をサポートする実施形態では、詳細化された解決法の構造と、全ての詳細化対象の解決法の構造が一致することが必要とされるかもしれない。もし、詳細化対象の解決法が既に、詳細化済みの解決法に追加されているものを繰り返す構造を提供するのであれば、詳細化対象構造は、余分なものとして削除してもよいし、または、その構造が詳細化済み解決法から除かれた時に効果を発揮するように残しても良い。もし詳細化対象解決法が、詳細化済み解決法について追加されたものと不一致な構造をすでに適用しているなら、操作を禁止してもよいし、または詳細化対象解決法を詳細化済み対象（およびその中間の子孫）と対応関係にないものとし、それら詳細化済み解決法の親を詳細化することを考えてもよい。
【0345】
他のトピックソーシャル革新のサポート
接続の招待と申請
[0580]
プロジェクトに対するプロジェクト拡張は、新たなエンティティと古いエンティティの間に「強い」対応関係を生ずる。拡張されたプロジェクトの管理者に提案がなされたと仮定する。寄稿者は、このプロセスの新たなプロジェクトに対する管理的な役割を担っていても、いなくてもよい。
【0346】
[0581]いくつかの実施形態では、既存のプロジェクト間の「弱い」対応関係もサポートしてもよい。これらは、段落０５１６に「既存のエンティティのDAG詳細化」にて記載した機構を使用できる。チェックンされたプロジェクトの管理者は、（プロジェクトのコンテンツにより）より具体的なプロジェクトを招待し、それを詳細化するか、（再びプロジェクトのコンテンツにより）一般的なプロジェクトの詳細化への適用をするオプション（例えば文脈メニューを介して）を有する。重要な点は、そのような弱い詳細化は、解決法の継承や他のプロジェクトコンテンツをサポートできる点である。
【0347】
[0582]これら対応関係の強度のばらつきは、プロジェクトだけでなく、他のエンティティの種類にも関連している可能性がある。実施形態では、例えば、同じ団体内のユーザ間の強い「詳細化」対応関係をサポートして、例えば、関係の報告や指導を示し、団体間のユーザの弱い対応関係をサポートして、例えば、指導のみを示す。
【0348】
[0583]システムは、弱い対応関係を考慮するためエンティティを推薦（「推薦」として）することもできる。
【0349】
[0584]いくつかの文脈では、プロジェクト管理者や他のユーザは、団体間の接続の「鳥瞰」図を利用できるかもしれない。団体の活動エリアは、団体間の弱いリンクにフォーカスし、強いリンクのシーケンスを凝縮することでハイライトできる。そのような領域は、追加的または代替的に、団体についてラベル付けおよび/または色または他の視覚的属性でコード化および／または異なる団体に対応付けられたエンティティの間の団体境界をマークするボーダーを有することもできる。他の団体から継承したエンティティは、継承対象の団体の領域内に「島」として現れる。
【0350】
[0585]この機能は、団体間でのシェアをサポートすると既に記載されている機能を活用するものであってもよい。しかし、ここでは、関係の第２形態を紹介し、実施形態は、どれを横切っているのか気が付いている必要がある。サーバは、「エコシステム」DAGの作成の際、例えば、他のプロジェクトに弱いリンクを有するノードに繋がるものを除いたローカスノードのからの強いリンク全てをスキップすることもできる。そして、同様に、後続の弱いリンクの何れかに凝縮し続けることができる。そのような「スキップ」は、DAGの短縮０２１０および継承の記録２２５０において親または子エンティティを凝縮する際に必ず起こる。エコシステム用DAGを、標準DAGと共にクライアントに渡しても良い。
【0351】
[0586]いくつかの文脈では、強い対応関係を介して関係付けされているエンティティのみが可視できるものであってもよい。他では、どのような対応関係を介して関係付けられているエンティティも可視できてもよい。実施形態は、標準DAGおよびエコシステムDAGにおいて、またはエコシステムDAGのみにおいて、弱いリンクで接続されたエンティティおよび／または弱いリンクを介して継承されたエンティティを含んでいてもよい。前者の場合、「DAGフィルタリング」において記載したものと同様のオプションを介して、ユーザが、標準DAGにおける弱いリンクにより接続されたエンティティの可視性を制御できる構成であってもよい。
【0352】
[0587]図１６７ないし図１７１にこの機能の一例を示す。図１６３は、「人々をどのように自立させるか」という問題についてのプロジェクト画面を示す。ここでは、「人々に商売をさせることを教えよう」という１つの解決法が挙げられている。図１６４は、他の問題である、「シングルマザーをどのように自立させるかという問題を示している。これは、他のユーザであるジョアンナ・ドウにより作成されており、彼女は管理者としてチェックインしている（段落０７５７においてチェックインの関連例）。図１６５は、ジョアンナが第１プロジェクト画面にナビゲーションし、彼女自身によりこのチャレンジを特殊化することを申請している。彼女の申請が（オンラインシステムやＥメールでのリンクを介して）受理された後、彼女のプロジェクト画面尾依存性タブからの画面は、この実施形態では、図１６６に示すようなものになる。ここでは文脈中の新たな一般化問題とその解決法は、サブ構造に継承されている。このアイデアにジョアンナは飛びつき、図１６７に示すような構造を構築し、最終的に「どのように商売を始めようとしているシングルマザーの間にコネクションを構築できるか」というものになる。ここんで、他の個人、ジェシカがより広い問題「どのように共通の興味を持つシングルマザーの間にコネクションを構築できるか」を考え始めている。図１６８に彼女ユーザ画面を示めす。ここでは彼女は管理者としてチェックインしている。図１６９では、詳細化するため、ジェシカのプロジェクトがジョアンナのプロジェクトを招待している。招待が受理された後、図１７０では、詳細化する問題のための依存かタブを示す。ここでは文脈が一方に到達し、結果他の外部の一般化問題にも到達している。図１７１にエコシステムタブからの画面を示す。なお、他の団体とも境界を接するエンティティのみが現れている。他の実施形態では、中間のエンティティを無視している場所を示してもよい。ここでは、同じ団体に対応する領域は同じ色でコード化されている。
【0353】
推奨[0588]
システムはプロジェクトをユーザに推奨したり、ユーザをプロジェクトに推奨したり、プロジェクトをお互いに推奨したり（問題を問題に、解決法を解決法に）、または（ユーザの対応関係が指導関係を示している場合）ユーザをお互いに推奨することもできる。プロジェクトに対する推奨は、そのプロジェクトの管理者に、彼らがプロジェクトにチェックインした時に示される。
【0354】
[0589]まず、例えば、（ある役割について）プロジェクトを人に推奨する場合を考える。これは、同様のプロジェクトを探し、そして、その役割を担えるのは誰かを考える。これは、他にこのプロジェクトでその役割をしているのは誰かを見つけ（誰かいればの場合）、そして同様の人を探しても良い。実施形態では、推奨の両方のソースを利用しても良く、また、両方のプロジェクトと個人について同様のマトリクスを適用して得られたものを利用してもよい。シチュエーションは、kind2の何れかのエンティティをkind1のエンティティに推奨する場合も同様である（これらが同じ種類の場合）。もし実際にこれらが同じ種類である場合、実施形態は、クロス種類関係の代わりに方向的詳細化関係（推奨したい方向を考慮した方向）を考慮してもよい。このプロセスを図１７２に示す。しかし、いくつかの実施形態では、両方の種類が一緒であれば、同様のエンティティを単に推奨してもよい。
【0355】
[0590]プロジェクトのランク付けされれたリストの構築について述べた３つの方法から選択するより、いくつかの実施形態では、３つ全ての方法を適用し、結果を合併する前に、どの方法が使用されたかにより最初に任意の重み付けを適用してもよい（恐らく、両方の類似性マトリクスの適用についてはペナルティを課す）。
【0356】
[0591]１つの役割に限定されるより、他の役割も考慮することもできる。それぞれ同様に低い（または任意の）重み付けをされる。
【0357】
[0592]特に、検索結果の場合であるが、推薦についても、一度結果リストが取得されると、詳細化により関連付けされた低いランクのプロジェクトをフィルタで排除するのが好ましいであろう。
【0358】
[0593]または、提案した手順は比較的標準のもので、いくつか改良点がある。上記の方法は両方とも、同様のエンティティを探すのに、ベクトルを構築し、類似性マトリクスを適用することを含む。類似性マトリクスは、同じ種類のエンティティのペアからのマッピングであり、それらがどれだけ類似しているかの予想を返すものである。ユーザが経歴が類似していたり、同様のプロジェクトに貢献している場合はそのユーザは類似していると考える。プロジェクトは、名前や説明が類似していたり、同様のユーザにより貢献されている場合は、そのプロジェクトは類似していると考える。任意のエンティティから同様のエンティティの秩序化されたリストを読み出すことをサポートするバランス化されたツリーなどのデータ構造のベクトルを使って類似性マトリクスを示すのが便利であろう。
【0359】
[0594]類似性マトリクスは、各エンティティについて生成されることができる特徴ベクトルから構築されてもよい。各類似性マトリクスのセル値は、両方ともフィルタされ、「驚く」値により調整され（驚くほど最も類似したプロジェクトを推薦したいので）、それぞれのノン‐ゼロエントリの数の平方根の積により除された点線として算出される特徴ベクトルにおける正の発生数の間の類似性の測定値とする。この特徴ベクトルに関する計算は、２つのベクトル間の角度のコサインに対応し、標準距離の測定値である。驚愕値は、TFIDFスコアとして測定できる。常法に対する改良は、それを、閾値としてに加え、線形調整としても扱う点である。
【0360】
[0595]問題または解決法について、特徴は、単語、必要なスキル（問題には必要なスキルはないが、下記に示すように、関連する解決法を考慮することができる）、寄稿者、および挙動であってもよい。ユーザについては、特徴は、単語、スキルの熟練度、貢献したプロジェクト、および挙動であってもよい。驚愕要素は、その特徴値が発生することの希少性に対応する。
【0361】
[0596]プロジェクトについての単語の特徴の特徴ベクトルの値は、それが、どれくらいの頻度で名前や説明、祖先や子孫プロジェクトの名前や説明に現れるかという測定値であり、全て一般の使用やサーバデータベースに現れる頻度に関し、例えば、名前対説明、および祖先と子孫でのいくつかのレベルのそれぞれについて重み付け係数を付し、最初は任意であるが、ファイルから読み出されたものである。後に、より高いレベルのプロセスで、重み付け係数を、推薦者を修正値でテストすることにより微調整してもよい。プロジェクトの寄稿者の特徴の値は、そのプロジェクトまたは祖先または子孫プロジェクトにおける寄稿者の役割（もしある場合）であり、その寄稿者がその役割、または何らかの役割を、何粗化のプロジェクトにおいて有することの頻度の希少性により調整され、ここでも祖先と子孫のいくつかのレベルのそれぞれについて重み付け係数を付されている。スキル特徴の値は、寄稿者特徴と同様に算出される（ただし、役割についての概念は除く）。
【0362】
[0597]ユーザ特徴の値も同様に算出されてもよい。
【0363】
[0598]このアプローチは、コラボ的なフィルタリングをおよびコンテンツベースの推奨を含む。
【0364】
[0599]推薦の品質を、例えば、プロジェクトについて、寄稿者特徴は、寄稿者の役割（もしある場合）またはそのプロジェクトにおける類似の寄稿者であり、類似性の度合いと共にあるとする。なお、その場合定義は循環するが、ダイナミックプログラミング用いてエンティティの特徴を暫時算出できる。
【0365】
[0600]特徴も、そのエンティティにとってどれくらい共通かまたは最近かを算出したシステム挙動を含んでいてもよい。
【0366】
[0601]システム挙動が行われると、特徴ベクトルや類似性マトリクスを暫時再計算する必要がある。
【0367】
[0602]その名前が暗示するように、システマティックなマトリクスは概してシステマティックなものであるが、いくつかの実施形態では、それらを一般化し、推奨の方法に基づいて区別することができる。
【0368】
[0603]人と解決法をそれぞれに推奨する特定のケースでは、実施形態は、推奨をユーザと解決法に限定し、ユーザが十分なスキルを有して、解決法の要求に応える資格があるようにしてもよい。いくつかの対応関係は好適であろうが、一般に、スキルの要件はユーザの組み合わせにより満たされる場合があるので、このフィルタリングは適切でない場合がある。スキル要件がリソース要件い結び付けられている実施形態（段落０６１９に記載のようなもの）では、推奨は修正されて個人をリソース要件に対して推奨するようにできる。その特徴ベクトルは根本的な解決法のベクトルとほぼシェアできるが、まあ、例えば、リソース要件の説明のおける単語の存在を反映してもよい。
【0369】
[0604]ユーザとプロジェクトの特徴ベクトルにおける従属的なプロジェクトのスキルを含む際に、そのプロジェクトに必要なスキルに熟達するのみならず、複数の従属的なより低いレベルのプロジェクトにより必要とされる詳細化対象スキルにも熟達した個人について、より高いレベルのプロジェクトに対するそのような個人の推奨を好ましいとする推奨アルゴリズムの重み付け係数を調整をすることもできる。
【0370】
第２DAG[0605]
実施形態は、ユーザがナビゲーションしたノードの祖先や子孫についての情報を提供する第１ローカライズ済みDAGと、例えば第１DAに示されたエンティティに関するエンティティの祖先や子孫についてのより限定的な情報を提供する第２DAG間を識別する構成であってもよい。そのような実施形態は、第１ローカライズ済みDAGの各エンティティと共に、直接的に関連するエンティティへの参照のリストを保存してもよい。これら参照は、クライアントにより、（サーバにより提供される）第２DAGへのアクセスに使用され、そのエンティティは、詳細化関係にて関係付けられる。
【0371】
[0606]サーバは、段落０４４８に記載のDAGの縮小0210の複数エンティティの実行を使用して、様々な選択された関係により、好適なクロス種類関係のにより、ユーザがナビゲーションした第１DAGのローカスエンティティに関連付けされたエンティティに関係付けられたエンティティの第２DAGを構築してもよい。
【0372】
[0607]基本的なアプローチは、第２DAGに、ローカスノードから詳細化により到達可能なノードを含ませることである。そのようなノードは、第１DAのローカスノードとクロス種類関係により対応付けられたものに対して設定されている。
【0373】
[0608]実施形態では、「ヒエラルキ構造とその文脈の表現の探査方法」に記載のように、集合の形態として、第１DAGがオープンの部分に基づいて第２DAGを表示することを好ましいとする。アクティブな集合、全体的な集合、および成分的な集合が維持される。
【0374】
[0609]これを達成する１つの方法は、第２DAGにそのローカスノードから詳細化により到達可能なノードを含ませることである。そのようなノードは、クロス種類関係により、第１DAGのローカスノードだけでなく、第１DAGにおいて現在可視の全てのノードに関連付けされたものに設定されている。第１DAGが拡張されると、ローカスノードが第２DAGに追加され、縮小されると、取り除かれる。
【0375】
[0610]これは第２DAG全体（第１DAGがフルに拡張されたと仮定）をサーバが、第１DAGの拡張状態への暫時のローカライズを担うクライアントに送ることで実施される。よって、クライアントは、第２ローカルDAGとそれが関連する画像提示の両方を修正する。
【0376】
[0611]よりスケーラブルに、クライアントは、追加のサブDAGを必要に応じてリクエストできる。DAGの共通部分を何度のも再送することを避けるために、サーバは、各ノードとエッジが既に送信済みであるかトラックしてもよい。
【0377】
[0612]第１DAGのどの部分がオープンであるかに基づいて第２DAGを表示する他の方法は、第２DAGに、第１DAGに示されたものに関係するエンティティ間の詳細化接続を示させることである。第２DAGのローカスノードは、第１DAGのローカスノードに、好適なクロス種類関係により関連付けされたエンティティとして固定されている。第１DAGが探査されるにつれ、第２DAGにアクセス可能なエンティティは、成長や縮小をし、それらは、第１DAGにおいてオープンなものに関連するエンティティを含むようになる。これは、現在アクセス可能かを示す第２DAGの各要素に対する二値インジケータを配置し、論理ツリーにおけるノードの子を判断する際にアクセス可能なノードのみを考慮することで実施できる。
【0378】
[0613]第１DAGフォルダがオープンである場合、実施形態は、暴露されたばかりのものに関連するが、第２DAGでは既にアクセス可能ではないエンティティを有するアクティブな第２DAGのアクセス可能な部分を拡張する構成でもよい。しかし、第１DAGフォルダがクローズの時、一実施形態では、隠れているものに関連するエンティティが、まだ可視状態の他のエンティティにより参照されているか否かが分からず、第２DAGのアクセス可能な部分を再演算する必要があるかもしれない。
【0379】
[0614]これを効率的に行うには、実施形態は、各第２エンティティについて、好適な関係によりそれが関係する第１エンティティを維持しても良い。第１DAGフォルダがクローズな時、第２DAG情報のアクセス可能な部分から、残りのオープンな第１DAGノードのからの直接的な対応関係を介してアクセスできないようになった関連するエンティティに関する情報を撤回する。
【0380】
[0615]例えば、段落０３０２に示すように、様々な解決法がスキルを必要とすると考慮する。そのようなスキルは、それ自身が、サブスキル関係により関連付けされていてもよく（段落０３０６のように）、より一般的な解決法がより一般的なスキルを要求している。こららスキルを第１プロジェクトの一部として見せるより（またはさらに見せるより）、実施形態では、第２DAGをこれらエンティティに限定するなり、これらエンティティをローカスノードとして扱うなりして、第１DAGにおいてオープンな解決法が必要とするこれらスキルをハイライトして第２DAGを提示してもよい。
【0381】
[0616]他の例としては、もし第１DAGが団体のヒエラルキを示している場合は、ヒエラルキの様々な領域内でスキルの熟練度を閲覧し、それらの間でサブスキル関係を探査することができる。または反対に、第１DAGがスキルヒエラルキを示している場合は、ヒエラルキの様々な領域内のスキルについて、それらスキルを必要とするプロジェクト、またはそれらスキルに熟練したユーザを閲覧し、それらの間の関係を探査することができる。
【0382】
リソース[0617]
実施形態は、解決法とリソースのタイプを関連付けてもよい。リソースは人、役所、またはその他、設備、コンピュータソフトウェア、または化学的または生物的解決法などのカスタマイズ可能な種類であってもよい。実施形態は、要件に対応するために、解決法に
対するリソースの割り当て（配分）をサポートするものであってもよい。
【0383】
[0618]そして、ユーザは、人材リソースとしって解決法に割り当てられていてもよい。そのような実施形態では、割り当てられたユーザは、役割上、協力者となる。現金も、提供者や投資家（段落０７２９）が提供し、プロジェクト内で送金されたリソースとして考慮することができる（「サポートの予算作成」にて説明）。
【0384】
[0619]人材のみをサポートする実施形態では（ほかのリソースと違い）、リソースの種類は、暗黙的であり、位置の数のみが関係している。多くの実施形態では、スキル要件は、人材についてのリソースタイプとして機能するものであってもよい。このケースでは、スキル要件は、上記のように解決法全体にではなく、人材リソース要件のそれぞれについて対応付けされているものであってもよい。コンピュータプログラムについては、リソース要件は、タイプ、UML図、またはプログラム使用の形態をとってもよい。分子リソースのタイプは、非化学量論的式などの、ポリマの繰り返し単位やイオンの帯電についての表記も含む凝縮された式（化学式）の形態、ルイス構造、骨格構造、立体化学式などの様々な形態の構造式（分子グラフ）、分子軌道図（原子価関係図）等の形態をとってもよい。または、これらに基づいて構築し、特別な濃度範囲の様々な成分を含む溶液を含んでいてもよい。
【0385】
[0620]リソース要件は、バックとして、例えば、それぞれ必要な数量がタグ付けされたリソースタイプのセットとして具体化されてもよい。人材リソースの要件については、数量は、正規社員（ＦＴＥ）の単位であってもよい。
【0386】
[0621]解決法の詳細化は、詳細化済みの解決法のそれを拡張または特殊化するリソース要件を有していてもよい。人材リソースの場合、詳細化対象解決法は、（詳細化済み解決法が必要としない）追加のスキルを有する人材リソース、詳細化済み解決法が必要とするこれらスキルのサブスキル、および／または詳細化済み解決法が必要とする以上の熟練度を必要とするかもしれない。UML図は、例えば、追加のサブクラスや方法で特殊化してもよい。明示性が低い分子仕様も、一貫したより明示性の高い仕様で特殊化できる。
【0387】
[0622]解決法に割り当てられたリソースうは、同様により低いレベルの解決法、例えば成分問題の解決法やそれらの低いレベルの解決法（例えば、段落０６３３などの実施のために選択されたもののみ）に割り当てられて、その解決法により動機付けされた問題に対応してもよい。もしプランが「追加の解決法構造：プラン」でサポートされたものである場合、リソースの最初の割り当ては、同じリソースが直列的に対処される問題の解決法に割り当てられることができるが、並列的に対処されうるものには割り当てられないという制約をもうけてもよい。解決法が完了したら（段落０６３３参照）、リソースは他の解決法に割り当てられるようにリリースされる。
【0388】
[0623]しかし、実施形態は、いくつかのリソースタイプの公表を消費的としてサポートし、解決法の実施の完了後にこれらリソースがリリースされないとしてもよい。ソフトウェアプログラムは一般に消費的と考えられないが、化学的または生物的解決法はそうであるかもしれない。消費的リソースは、解決法の実行時に発生しうるリソースの変換を示すために使用されてもよい。解決法実施時のプロジェクト協力者による経験は、人材リソースのスキルの増加として示されてもよい。
【0389】
[0624]高レベルから低レベルへのリソースの割り当てプロセスは、ハイレベルの解決法のリソース要件を、該ハイレベル解決法の成分問題に対する解決法の一貫性のあり、またより一般的でもあり得るリソース要件に対応付け、リソースがその解決法の実施に対して利用可能であることを示すことをサポートする実施形態により、何らかの形で自動化されてもよい。
【0390】
[0625]リソース要件タイプと利用可能なリソースタイプは、補助的プロジェクト情報として、「補助情報および集合」において記載されている。プランを有する解決法の統合的なリソース要件は、一実施形態では、そのプランの構造から算出できる。実施形態では、同時に起こる全ての並列的な操作を許す理想的な要件と、リソースのボトルネックのため並列成分間でも時に秩序化を強制しなければならない最低限の要件とを区別してもよい。いずれのケースでも成分問題のリソース要件は、それら問題に対する解決法の要件のGLBとして、例えば各必然のプランの（実施のために）選択された解決法を満足できる最低限の要件を満足するリソースタイプとして、算出されてもよい。並列の成分問題の最低限のリソース要件も、同様に、これら問題に対する選択された解決法の要件のGLBとして算出してもよいが、理想の要件は、これら問題に対する選択された解決法の要件の合計、例えば、各選言肢プランの選択された解決法の全てを満足するリソースタイプとして算出されてもよい。第１の計算は、必要なリソースタイプのDAGとそれらの詳細化関係における接続された成分を分離させ、必要なリソースそれぞれを、フルリソースタイプヒエラルキにおいて、必要なリソースタイプのGLBと同じタイプとしてもよいが、これは過度に正確するぎるかもしれない。その代わりに、いくつかの実施形態では、（詳細化により）関係するリソースタイプのチェーンを分離し、必要なリソースそれぞれをそのチェーンの最も低い要素のタイプとしてもよい。第２の計算は（並列の成分についての理想的な要件）は、個別のリソース要件のバック集合をとり、同じリソースタイプの数量を合計して算出してもよい。もし、解決法にプランがない場合は、成分問題の並列処理が仮定される。
【0391】
[0626]解決法のリソース要件の設定時に、実施形態では最も十分でないリソースが解決法のプランを満足することを必要とするとしてもよい。
【0392】
[0627]実施形態では、リソースタイプ（いくつかの実施形態では１つのリソースタイプ）と問題とを対応付けし、例えば、問題の解決法が、これらリソースを生成するという予測を示しても良い。この場合、その問題に対する何らかの解決法の完了は、対応付けられたタイプのリソースを生ずると仮定することができる。シーケンス（複数のネスティングされたシーケンス）のステップとして問題が存在している場合は、生成されたリソースは、後続の問題の解決法に割り当てられるように利用可能としてもよい。よって、より大きな問題に対する解決法の成分問題のリソースタイプは、該より大きな問題に対応付けされたタイプのリソースを生成する際に中間結果の特殊化として見ることができる。実施形態では、より高いレベルの問題に対する解決法の成分問題のリソース生成の予測を、該より高いレベルの問題の一貫した、より一般的でもあり得るリソース生成予想に対応付け、例えば、そのリソースが該より高いレベルの問題のリソース生成予想を満足することを示すことをサポートするものであってもよい。
【0393】
[0628]同様に、実施形態では、解決法の成分問題の一般化されたリソースタイプを、後続の成分問題に対する解決法の一貫した、より一般的であり得るリソース要件タイプに対応付けることをサポートするものであってもよい。このケースでは、上記段落０６２５での計算のように、生成されたリソースは、トータルで必要とされるリソースを限定する際に考慮する必要がある。特に、要件は、リソース要件を超えるリソース生成予想に対応する（任意の）ネガティブな要件でマークされていてもよい。シーケンスのリソース要件の算出は、複数の二値計算とされ、リソース生成予想は、それが満足しうる要件を省くことになるかもしれないし、または後続のリソース要件を下げるために引き継がれることが可能なネガティブ要件として記録される。並列プランの最低限の要求の算出は、リソース要件のがキャンセル不可としてマークされてなければ、従前のようであってもよい。並列プランの理想要件の算出は、秩序化が適用され、他の選言肢プランのリソース生成予想により満足される要件を有する選言肢プランを遅らせる必要がある。
【0394】
[0629]いくつかの実施形態では、問題に関して生成されると予想される解決法とリソースのリソース要件の全てまたは一部のそれぞれは、それらの実装について１つの追加の問題を提示し、それらの実装解除について他の問題を提示する（実装解除については、自明であったり省略される場合もある）、これら問題は、少なくとも一部は、関連するリソースのタイプにより判断されると、宣言してもよい。人材リソースの実装は、雇用および／または訓練を含むものであってもよい。ソフトウェアリソースの実装は、プログラミングおよび／または構築を含むものであってもよい。分子リソースは、所定の化学反応により生成されるものであってもよい。リソースが割り当てられ、実装されるまで、動機付けされた問題の解決法は実施可能ではない。リソースが実装解除されるまで、動機付けされた問題の解決法は完了していない。他の実施形態では、そのような実装および実装解除の問題は、明示的により高いレベルの解決法の他の成分問題として規定される必要があるとしてもよい。
【0395】
仮定の追加[0630]
一般化に対する一変形例として、解決法がそれほど一般的な状態で提示されていないと気が付くことがある、つまり、それが解決するとする問題には言及されていない仮定がある場合がある。実施形態では、ユーザに解決法の仮定を示すことを許し、その仮定をそれが対処する問題の詳細化として取り扱って、操作後、解決方法が詳細化済み問題を解決するように構成されていてもよい。
【0396】
相互除外の詳細化[0631]
いくつかのケースでは、２つ以上の特殊化が独立的で、範囲が重複している可能性がある。他のケースでは、それらは直角的で、よって離れている。例えば、明確に分かれた地理的エリアにより問題の特殊化は相互に除外するものとまず考慮できる。そのような関係を特殊化する上でユーザをサポートすることで、問題と解決法を例に取れば、段落０４３３により一般的に記載の、他の兄弟により、相互に除外した兄弟解決法の１つを詳細化する親問題に対する解決法の継承を制限することができる。また、解決法、スキル、当の相互除外的な詳細化をサポートすることもできる。いくつかの実施形態では、エンティティを作成する機構を提供し、同じ種類のより低いレベルの詳細化全てが相互に除外的なものとする構成であってもよい。
【0397】
厳格的詳細化の実施形態[0632]
いくつかの実施形態では、詳細化対象ノードの様々なタイプのサブ構造が、詳細化済みノードのサブ構造のからの継承または詳細化だけで取得可能であり、そのようなサブ構造が直接詳細化対象ノードに挿入されることを禁じる必要がある点で、上記の提示とは異なる。特に、詳細化済み解決法により動機付けされた問題を、詳細化対象解決法が動機付けした問題に詳細化させることで、上記のアプローチとは違い、クラスが現在プログラミング言語に拡張される方法により似ている理論的なコンピュータ科学のそれに近い解決法詳細化の概念に導かれる。まった、詳細化済み問題に対処する解決法を、詳細化対象問題に対処する解決法で詳細化することもできる。
【0398】
状態機械/ベイジアン・ネットワークの詳細化ヒエラルキにおける各ノードの対応付け[0633]
解決法状態の状態機械提示を考慮することもありえ、ここでは状態は、解決法の実施の発展レベルまたはそのような実施の事項についての承認レベルの何れかに対応する様々な起こり得る状態値についてのものである。例えば、ソフトバンクプロジェクトのインタラクションの古典的な状況値は、要件分析、設計、コード化、システムテストなどが挙げられる。承認についての状況値は、承認の様々な段階や実施可能性の評価などのが挙げられる。これらは、別々の状態機械において示されてもよく、または同じ状態機械で示されてもよい。状況の一般的なリストは、「オープン」であり、「実施のために選択」されているとは考慮されない。後者には、「未起動」「リソース開発中」「実装中」「リソース実装解除中」および「完了」がある。
【0399】
[0634]解決法が経験した実装／承認の状況があるとすると、次に適用され、新たな状況に導く様々な追加のプロセスを考えることができる。機械学習アプローチは、ある状況から他の状況へ解決法がどのように進んでいるかに関する統計的データに対してグラフ構造を適用するのに使用できる。そのような統計データには、問題や解決法の様々な性質を考慮することができる。そのようなアプローチの１つが、Rebane＆PearL, J. 著「The Recovery of Causual Poly-trees from Statistical Data」予稿集、第三回AIの不確実性についてのワークショップ（シアトル、ワシントン州）ページ２２２〜２２８、１９８７のものである。そのようなアプローチは、ネットワークを「鍛え」て状況間の適切な遷移をもたらす方法の１つである。
【0400】
[0635]所定の性質を有する解決法について訓練されたネットワークを、より具体的なサブ性質を有する解決法、例えば、そのネットワークがそのために訓練されたものを特殊化するある属性の値を受け取る解決法の出発点として使用してもよい。そのようなネットワークは別々に進化してもよい。
【0401】
[0636］もし問題が様々な状態間を遷移するものであれば、同様の技術を問題に適用することもできる。
【0402】
[0637]問題と解決法の我々の詳細化ヒエラルキは、ヒエラルキの各解決法がある状態から他の状態にどのように遷移するから定義する様々な状態機械を組織化するフレームワークとして使用することができる。問題と対応付けられた状態機械は、それら問題に対処する全ての解決法に適用可能である。問題の詳細化ヒエラルキが伝承されると、訓練データが各レベルの様々な子問題の間で分離され、よって、異なる状態機械が導出される構成であってもよい。よって、学習は、詳細化ヒエラルキの下方に伝播することができる。
【0403】
[0638]訓練データは、ユーザに、任意の解決法に対して好ましい次の状態はどのようなものか質問する形態を取ってもよい。または、ユーザに、任意の解決法に対してどのような前の状態が適切であったかを質問する形態をとってもよい（例えば、プロトタイプをユーザ候補者に確認して貰うなどの形態）。
【0404】
[0639]適切な移行データが収集される時間方向に関わらず、実施形態では、なぜ提案された状態移行が適切なのか、または適切だったのかを質問することも選択してもよい。回答は、修正した状態機械の移行をトリガする信号の基礎となってもよい（例えば、実施の労力には、４０人／時以上を必要とすると予測されたからなど）。
【0405】
[0640]情報は、ヒエラルキを上方に伝播することも可能である。例えば、任意の問題の解決法に対して移行が適切だと分かった場合、実施形態では、（いずれかの親の下の）兄弟問題に、その移行がそこでも適切かどうかを質問する構成であってもよい（これは兄弟問題にとある状態を構築することを必要とするものであってよい）。もし兄弟問題の解決法に対して移行が適切だった場合は、当該親問題への解決法に対してもそれを提案することができる。この戦略は、詳細化ヒエラルキを上方に学習を伝播させるのに使用でき、問題ヒエラルキや状態機械のみに関するものではない。
【0406】
[0641]または、詳細化対象問題の状態機械は、詳細化済み問題のそれらを、プロジェクト管理者による明示的な編集などの他の手段で覆すこともできる。
【0407】
[0642]また、解決法のヒエラルキは、ヒエラルキの状態機械と対応付けられ、ヒエラルキのネスティング状態とし、ネスティング状態の解決法も周囲の状態にあるようにしてもよい。
【0408】
[0643]そのようなヒエラルキの状態機械は、解決法に適用されるより深いネスティング状態がまず、様々な入力信号（承認、実施、試験、予算等の可否）がどのように扱われるかを定義する機会を得るように、適用されてもよい。
[0644]
または、そして好ましくは、ヒエラルキ状態機械は、新たな信号がヒエラルキのより深いレベルに関連し、これら新たな信号がより高いレベルでの状態のサブ状態間の遷移を決める構成であってもよい。
【0409】
[0645]問題の解決法ヒエラルキは密接に関連しているので（例えば、段落０３３７や段落０４６０の制約により）、詳細化済み解決法は、詳細化済み問題により適用された状態機械の修正の影響を自然に受ける。よって、一貫性と連続性のため、いくつかの実施形態では、詳細化対象問題についての状態機械の修正を、詳細化済み問題について存在している状態に詳細のより低い層を追加委で適用することに限定するものであってもよい。
【0410】
[0646]状態機械と、状態機械の追加の層は、解決法が存在している時に追加可能なので、どのようなレベルの状態機械も所定のデフォルト開始状態を有する必要がある。新たなまたは既存の解決法を、トップレベルの機械のデフォルト開始状態において配置される、または、より高いレベルの好適な状態に入った時に、より低いレベルの機械に配置される。終了状態は必要ではないが、外部にむけてのエリアがにと定義することで、終了状態を何個作成してもよい。
【0411】
[0647]ユーザインタフェースを介した状態間をどのような解決法が遷移してもよく、または所定の遷移が自動的に適用されるルールと対応付けされてもよい。前者の取り扱いについては、管理上の承諾または承諾拒否が適切であり、後者については、予算超過のまたは納期徒過の解決法が候補の例であろう。
【0412】
[0648]図１７３に、問題に状態機械を対応させるユーザインタフェースの例を示す。問題についての文脈メニューは、エンティティの編集や拡張のオプションに加え、「状態機械の閲覧」のオプションを有する。このオプションを選択すると、問題についての現状態聞きあの図が表示される構成であってもよい。ここでは、「追加資金の承認」という遷移を介して得られる「実施予算超過」と識別されるものを含むいくつかの状態を有している。どのような状態からも、文脈メニューは、「状態の分解」オプションを有している。これは、選択されると、より低いレベルの状態機械を示すものである（既存のものがないなら、作成する）。ここのノードの文脈メニューオプションは、状態レベルの編集、新たな状態の追加、および外へのoutgoing?状態遷移の追加をサポートしている。状況に無関係の文脈メニューは新たな状態の追加、デフォルト状態の設定、または次のより高いレベルの状態機械のウィンドウの表示をサポートしている。
【0413】
[0649]図１７４に、問題に状態機械を対応付けるユーザインタフェースの一例を示す。解決法の文脈メニューは、エンティティの編集や拡張のオプションに加え、「現状態の閲覧」のオプションを有する。ここでは、２レベルの状態が表示されており、上側のレベルが「実施ＯＫ］であり、下側の状態が「実施予算超過」である。他のオプション「状況繊維の適用」は、オプションとして状況機械の様々なレベルのからこのノードのついて利用可能な遷移と共に他の文脈メニューを提供する。解決法レベルの文脈メニューからの追加のオプション「次／前状態の推奨」は、どうやって解決法を処理すべきか、または処理すべきだったか、そしてそれは何故かに関する入力の取得を可能にする。これは、ここではユーザオプションとして提示されているが、実施形態では、このプロセスをランダム化し、自己選択を介した偏見を回避することを好ましいものとしてもよい。
【0414】
ヒエラルキ構造の探査とその文脈の表示の方法[0650]
一般的なアプローチは次のようなものである。DAGの一部をツリーとして提示。そして、ユーザに以下の行動の何れかを実行することを反復的に許可する。
DAGのクローズされたフロンティアの何れかのノードにおけるサブツリーを拡張
これを行うと、オープンであるサブツリーと「衝突」するこれまでオープンのサブツリーを自動的にクローズすること、例えば、DAGの他のノードで既に可視になっているオープンしているノードの子全部を隠すなど、および開かれたノードのいくつかの子孫をオープン自動的にすることの両方を行う。
DAGのクローズされたフロンティア内に厳密にある全てのノードにおけるサブツリーを折り畳む
これを行うと、折り畳まれたノードの厳密な子孫は全て隠され、折り畳まれたノードのはクローズされる。様々な実施形態では、これを、下記に記載するような戦略の組み合わせを用いて達成する構成であってもよい。どれだけのDAGが最初に可視の状態である必要があるか、ノードが開かれた時にどれくらい見せるかについて、関連する戦略にて取り決める。
【0415】
[0651］実施形態では、任意のエンティティと対応付けられた１つのノードだけが可視の状態にあるようにツリーを制約することを選択する構成でもよいので、同じエンティティ対応付けられた２つのノードは、「直接的に衝突」していると称することができる。ノードを隠すため、実施形態では、その親を折り畳んでもよい。ここで挙げる戦略は、最後の２つ以外は、ノードの子孫の数は無限なので、適切ではないかもしれない。
【0416】
[0652]第１に、初期化の戦略を提示する。これらは全て複数の直接的に衝突しているノードを表示することを防止する。
１．他のノードをオープンして可視のノードと衝突する子ノードが見えるまでできるだけ多くDAGをオープンする。該ノードの子は、どの順番で展開してもよい。可視になる衝突ノードは多くても１つである。
２．１つ以上の親によりエンティティが到達できるまでできるだけ多くDAGをオープンする。このケースでは、そのような親ノードをオープンしない。可視になる衝突ノードのはゼロである。
３．リーフではない子が１つだけである限り、ノードをオープンし続ける。
４．子が１つだけである限り、ノードをオープンし続ける。
５．ローカスノードのみをオープンする。
６．最初にどのノードもオープンしない。
【0417】
[0653]次に、明示的なノードの展開の戦略を提示する。ここで、実施形態では、リクエストされたノードをオープンするが、どれくらい追加でオープンするかは様々である。複数の直接的に衝突するノードの表示を禁ずる制約を維持するため、実施形態では、いくつかのノードを隠す構成であってもよいが、必要となる隠しの量は展開（開帳）の制約次第であってもよい。ノードの子孫の数は無限な場合、ここで挙げる戦略の内、最後のものだけが適切であるかもしれない。
１．展開されたノードの子と直接的に衝突する全てのノードを隠し、他のノードをオープンして可視のノードと衝突する子ノードが示されるまでできるだけ多くDAGをオープンする。ノードの子は、どのような順番で展開されてもよい。可視になる衝突するノードは多くても１つだけである。
２．展開されたノードの子と直接的に衝突する全てのノードを隠し、そして１つ以上のパスにより到達できるエンティティが示されるまでできるだけ多くDAGをオープンするが、そのノード自体はオープンしない。ノードの子はどのような順番で展開されてもよい。展開のリクエストされたものの子以外は、衝突するノードは可視化されない。
３．兄弟はどのようなものでも閉じ、リーフではない子が１つだけである限りノードを開き続ける。
４．兄弟はどのようなものでも閉じ、子が１だけである限りノードを開き続ける。
５．明示的に指示されたノードのみを開く。ノードのオープンの前にどれだけツリーを隠すかによりバリエーションがある。それぞれが示すノードと同じエンティティと対応付けられた可視のノードを全て隠し、または兄弟を全てクローズする。様々な実施形態では、初期化と展開の両方について関連する戦略を使用するが、いくつかの実施形態では、これらのケースや何れかのサブケースでは、適宜異なる戦略を使用する。
【0418】
[0654]他のセットの戦略は、クローズされているサブトリ―を再オープンする際にどのように反応するかについてものである。
１．いくつかの実施形態では、該サブツリーをを初期の位置に再オープンする構成であってもよい。
２．その他の実施形態では、クローズ前と同じ位置に再オープンする構成であってもよい。
[0655]
実施形態は、論理リーフノードをどのように扱うについて若干違いがある場合がある。いくつかの実施形態では、表示する子がなかったとしても、リーフノードがオープンやクローズできるように選択してもよい。これら実施形態では、ノードがオープンまたはクローズしているのを示す二値変数を１つノードに使用する構成であってもよい。最適化として、ノードが子を有しているか否かを直接示す二値変数を別途使用してもよい。他の実施形態では、子を有するノードがオープンかクローズかをトラックし、リーフについては、この情報を維持しない構成であってもよい。また、ノードが論理リーフであるか否かは、明示的に維持されてもよく、または論理子をカウントすることで判断されてもよい。展開、折り畳み、および展開の様々な戦略は、論理子を有するノードに対してのみ行われると仮定し、これらのチェックは図からは省略されている。
【0419】
[0656]２つの戦略は、ツリーノードの寿命を反映している。
１．いくつかの実施形態では、最初任、DAGからサブ構造全体を、エンティティによっては複数回示されるかもしれない１つの（場合により反転した）ツリーとして構築し、どのノードが表示されるかを上記戦略の選択により調整（し、どのエンティティも如何なる時も１つのノードでのみ表示されるように）する構成であってもよい。探査が行われるシチュエーションにより、実施形態では、明示的にノードを隠したり、表示したりする構成でもよく、またはブラウザなどの根本的な技術を活用して、ある状況におけるこれら属性を設定する構成であってもよい。
２．他の実施形態では、表示される度にDAGからノードを再構築し、隠される度にそれらを削除する構成であってもよい。
ツリーとしてのDAGサブ構造の提示
ここでは、ツリーは下向きに成長し、その目的はユーザがノードの子孫、つまりそのサブ構造の探査を行えるようにすることである。
【0420】
[0657]DAGをツリーとして提示するアプローチを図１７５に示す。ここではあるDAGがナビゲーションの対象となっている。ツリー構造（DAGへのスナップショットの例）は、DAG
構造と正確に対応しており、オープンノードの子（O:とマークされている）はインデントで示され、ノードの下に配置されている。
【0421】
[0658]戦略０６５６．１を実施する実施形態では、ノードが隠されている場合は、その子孫の全ても隠されていると推測でき、その状態を各子孫について明示的に維持しない構成であってもよいし、なくてもよい。
【0422】
[0659]ここで戦略０６５６．１の各操作について説明する。図１７６および１７７は、セットアッププロセスの２つのパーツを示すものである。図１７６は、ローカスノードから始まり、子孫を発見する、静的サブ構造構成１１１１００がインタラクティブにサブ構造を構築する様子をしめしている。様々なノードの構成間には秩序を定めていないが、もしポインタが何れかの方向に維持する場合は、まず参照ノードを構築し、それから参照するノードにポインタを設定するほうが便利である。図１７７は、静的サブ構造初期化１１１１０１がローカスノードを可視化することと、段落０６５２の戦略を適用することの両方をしているところを示す。戦略０６５２．６に記載の戦略については、展開すると単にローカスノードが折り畳まれるが、段落０６５２の他の戦略では、ローカスノードをオープンとマークし、段落０６５２において示される残りの様々な初期化戦略について図１８０、図１８１、図１８２、図１８３、または図１８４に示すプロセスを適用する。ソフトウェア開発の当業者には、各ノードが初期化前に構築されているなら、これらプロセスを合併することができることは明らかであろう。
【0424】
[0661]いくつかの実施形態では、隠されたノード（クローズのノードの下のもの）のオープン／クローズの状態をどのように維持するかについて仮定をしてもよい。実施形態は、クローズされるものを初期化し、隠し、また、（ノードを開いた時にその子が閉じていると仮定できるように）ノードを折り畳む際に、表示されている子孫がクローズで隠された状態に残るようにする構成であってよく、または、展開が止まった時に、リーフではないノードを折り畳むような構成であってもよい。図は後者を仮定している。これらは、各展開戦略について展開がそれぞれ止まった場合に、ノードの折り畳むこのステップを示している。明らかに、これをまとめることがabstract?できるが、展開止まってこれらノードをまとめて処理できるようになった場合に、これらを収集する必要があるであろう。
【0425】
[0662]段落０６５３の戦略は、図１７８のテンプレートを使用している。現ノードは、最初は展開するノードである。本プロセスは、このノードを展開についてオープンとマークし、続いて、展開戦略衝突を生ずるであろう全てのノードを、その親を下り畳むことで隠し、そして展開戦略（段落０６５３からのもの）をノードに適用する。隠れているノードについては、戦略０６５３．１と戦略０６５３．２が図１８５からの直接衝突する静的サブ構造を隠す１１２１１１を使用する、戦略０６５３．３と戦略０６５３．４は、図１８６からの静的サブ構造における兄弟の折り畳み１１２１００を使用し、そして戦略０６５３．５はこれらの何れかを使用してもよい。展開については、これらの戦略は、それぞれ図１８０、図１８１、図１８２、図１８３、および図１８４からの、静的サブ構造の最大展開１１１１１０、共通子孫までの静的サブ構造の展開１１０１２０、複数のリーフではない子までの静的サブ構造の展開１１０１３０、複数の子までの静的サブ構造の展開１１０１４０、および静的サブ構造の単項展開１１０１５０を使用する。
【0426】
[0663]上記は、戦略０６５４．１を説明した。戦略０６５４．２については、それらをオープンであるとマークし、ノードがマークされてない場合（そして可能であれば、もしその全ての子がクローズな場合）は、展開時に上記のように作業し、そうでなければ、オープンまたは空の子孫と、クローズな子孫の第１層を表示する。この戦略をさらに推し進め、セッションの後にツリー構造を保存し、そのような保存された構造が見つからない場合にのみ初期化を行うとしてもよい。
【0427】
[0664]図１７９に静的構造の折り畳み１１３１００のプロセス示す。ここでは、現ノードは、最初に、折り畳まれたノードである。様々な実施形態では、クローズなノードの下のノードは、可視にはならないので、隠す必要もない。しかし、隠れているというノードの性質が継承可能である限り（戦略０６５６．１）、折り畳まれているノードの直近の子を隠す必要がある。
【0428】
[0665]ここで、各戦略に関連する補助的操作を説明する。図１８０は、静的サブ構造の最大展開１１１１１０のプロセスを示す。これは、サブ構造のヒエラルキから伝承され、ノードをオープンとマークし、各ノードを表示して、他のパスを介して既に可視になっている共通子孫の表示を回避するためにのみ停止（およびノードをクローズとマーク）する。図１８１は、共通子孫までの静的サブ構造の展開１１０１２０のプロセスを示す。これは、静的サブ構造の最大展開１１１１１０と類似しているが、共通子孫の表示を、それらが、他のパスを介して既に可視であるかないかに関わらず、回避するために停止（およびノードをクローズとマーク）する。図１８２は、複数のリーフではない子までの静的サブ構造の展開１１０１３０のプロセスを示す。これもサブ構造を介して伝承され、ノードをオープンとマークし、各ノードを表示し、複数のリーフではない子を有するノードにおいて停止（そしてノードをクローズとマーク）する。図１８３は、複数の子までの静的サブ構造の展開１１０１４０のプロセスを示す。これは、複数のリーフではない子までの静的サブ構造の展開１１０１３０と類似してるが、リーフがあろうがなかろうが、複数の子があれば、伝承を回避するため停止（そしてノードをクローズとマーク）する。最後に、図１８４は、静的サブ構造の単項展開１１０１５０のプロセスを示す。これは、正に展開を１ステップで行う。
【0429】
[0666]これらの操作は戦略０６５６．２について、最初にローカスノードを作成し、上記のように、単にノードが可視になる時にノードを作成し、ノードが隠されるときは破壊することで実施できる。他のセクションがダイナミックなサブ構造と文脈を必要とするので、それ以上の説明は必要ではないであろう。
反転ツリーとしてのDAG文脈の準備
ここでは、ツリーが上方に成長し、その目的がユーザがノードの祖先について、それゆえ文脈について探査できるようにすることである。
【0430】
[0667]DAGは、上向きおよび下向きに延びるサブツリーを有していてもよい。２つのハイレベル戦略がサブ構造対文脈の概念に関連する。
１．ローカスノードの概念を有するいくつかの実施形態では、そのノードの祖先は、文脈の候補、そのノードの子孫はサブ構造の候補であると考えてもよい。変性のケースでは、DAG全体が、サブ構造または文脈と考えてもよい。この戦略により、所定のローカスノードのみがサブ構造または文脈について別途フォーカスされる（両方ともあると仮定）。サブ構造ノードは、他のサブ構造を展開したり折り畳んだりすることができ、文脈ノードは他の文脈を展開したり折り畳んだりすることができる。
２．他の実施形態では、サブ構造と文脈を関連する項だと考えてもよい。これは、構造や文脈について度のノードの別々に注目されるようにすることで達成できる。クローズのサブ構造フロンティア内のノードがサブ構造のために折り畳まれた場合は、適切な子孫は全て隠される。クローズのサブ構造フロンティア上のノードがサブ構造のために展開された場合は、その適切な子孫のいくつかが可視にされる。クローズのサブ構造フロンティア内のノードが文脈のために折り畳まれた場合は、その適切な祖先の全ては隠される。もしクローズのサブ構造フロンティア内のノードが文脈のために展開された場合は、適切な祖先のいくつかが可視にされる。
【0431】
[0668]１．いくつかの実施形態では、複数の親ノードが同時に展開することを可能にしてもよい（共通の祖先が１つ以上のノードで可視にならない限り）。ノードの順番は固定される。
２．他の実施形態では、展開を、親ノードのリストのトップノードが、少なくとも他のノードの所まで展開するように制約してもよい。もし、１回について展開する文脈兄弟が１だけの場合（戦略０６５３．３、戦略０６５３．４、または戦略０６５３．５により）、何れかのノードを展開する場合は、それはトップに移動される。複数の文脈兄弟が同時に展開される場合は（戦略０６５３．１または戦略０６５３．２により）、いくつかの実施形態では、展開プロセスは、どの文脈兄弟が最も大きい展開が必要かを判断し、その文脈兄弟がトップに移動するように好適に実行される必要がある。これは、後述の「複数の反転ツリーの共通文脈の提示」にて説明するように、共通の祖先との関係を可視化する目的であってもよい。
【0432】
[0669]DAGをツリーとして提示するアプローチを、戦略０６６７．１と戦略０６６８．２を仮定し、ナビゲーションされる所定のＤＡＧについて図１８７に示す。DAGのルート（ノード０）は、この図の底にあり、ツリーのルートは頂部にある。オープンのノードの上または左にあるノードは、まとめてそのノードの親である。ここで、ノード０．０ないし（ｎ０−１）は、ノード０の親であり、それらの内２つ（ノード０．０およびノード０．（ｎ０−２）はオープンでありそれぞれの親も表示されている。
【0433】
[0670]トップの文脈兄弟が他の文脈兄弟より展開を少なくすることを可能にする様々な実施形態では（戦略０６６８．１により）、字下げを明示的に管理したり、または不可視のリストノードを管理する（最も上のノードは最も左のものである必要はないので）構成であってもよい。これは、文脈兄弟を再秩序化することで避けることができる（戦略０６６８．２により）。ソフトウェア開発の当業者にとって、字下げや不可視のリストノードの管理は、退屈なだけなので、戦略０６６８．２に集中する。
【0434】
[0671]戦略０６６８．２を実施する様々な実施形態では、静的な秩序化は十分ではないので、戦略０６５６．２も実施するように制約されていてもよい。もしノードが隠れているなら、その子孫は全部隠れていると推測できるという慣習がある実施形態では、戦略０６５６．２も実施してもよい。なぜなら、この慣習は、祖先を隠すことなく子孫を隠すことができる反転ツリーとは適合しないからである。
【0435】
[0672]戦略０６５６．２を実施する実施形態では、構築と初期化には区別がない。図１８８は、図１７７と類似しているが、サブ構造の初期化において済んでいると仮定し、ローカスノードを示すのを省略している。ローカスエンティティと対応付けされたローカスノードの構築も、ダイナミックサブ構造（図示せず）の初期化において済んでいると仮定し、省略されている。
【0436】
[0673]図１８９に、一度に展開できる文脈兄弟は多くとも１つであるシチュエーションにおける明示的な展開のプロセスを示す。図１７８と類似しているが、２つのシチュエーションを扱う論理を備えている。ここでは、もしまだそこにないなら、展開されるノードを文脈兄弟のリストのトップに移動させる。また、展開するノードが文脈兄弟のリストの一番下であり、リストの少なくとも１つ他に要素がある場合、その子孫は新たな最後の文脈兄弟に移される。複数の文脈兄弟が一度に展開できるシチュエーションでは、まずこのノードの展開すると最も広く展開した文脈兄弟になるかどうかを判断する必要があり、そしてもしそうなら、上記論理を用いて、それをリストの一番上に持ってくる必要がある。
【0437】
[0674]図１９０は、ダイナミック文脈の折り畳み（単一のエンティティ）２１３２００のプロセスを示す。これは、現ノードの上に他に文脈がないかを繰り返しチェックし、もしそうなら、現ノードをその子孫と共に現ノードの祖父母に移動した後に、現ノードの親を解除する。現ノードの上に他に文脈がない場合は、文脈展開についてクローズととマークされる。
【0438】
[0675]文脈の展開についての様々な戦略の図（図１９１、図１９２、図１９３、図１９４、および図１９５）において、現ノードとは、最初はローカスノード（初期化の場合）を指し、または明示的な展開の場合は、展開されるノードを指す。現エンティティは、現ノードと対応付けされたエンティティを指す。これらはそれぞれダイナミックにノードのリストを割り当て、現エンティティの親それぞれに１つ割り当てる。これらを、現ノードから引いた状態で並べて表示するため、実施形態では、リストの最後のノードの子として現ノードを配置する構成であってもよい。どのような時も戦略は、新たに生成されたノードにおいて展開することを再度行う必要があり、この割り当てステップをそのノードのために繰り返してもよい。単一エンティティのDAGサブ構造の提示のための戦略との他の大きな違いは、ノードを文脈展開についてクローズとマークすればよく、それらの文脈子孫を隠す必要がない点である。これは、ノードがこれら子孫のために生成されていないからである。
【0439】
[0676]図１９６は、図１８５と同様であるが、エンティティとDAGに関する衝突について検索をする必要があり、DAG中のいくつかの親の内の１つであるノードを隠すために、それを考慮する必要があり、様々な実施形態では、シーケンスの最後の親を示すノードのサブストレートsubstrate?‐子として配置されたDAG-子を示すノードを折り畳む必要がある。図１９７は、図１８６の深く関連している。
複数の反転ツリーの共通文脈の準備
段落０４４４に記載するように、ユーザが複数のローカスノードへナビゲーションすることを可能にしてもよい。ここで、ユーザが先祖、つまりノードの文脈を探査するにつれ、ツリーは各ローカスノードから上方に成長する。我々の目的は、文脈探査の際に、共通の先祖に導く２つ以上のローカスノードからのパスを識別することである。
【0440】
[0677]文脈が展開されるにつれ、露わになる文脈と対応付けられているエンティティに対応付けられている文脈を隠すという方法がある。複数のローカスノードがある場合、もし同じエンティティが１つ以上のローカスノードの文脈を介してアクセス可能であるなら、以下のように進める。その共通の祖先エンティティが、各ケースの文脈兄弟の同じセットと共に可視にされるなら、パスを合併させて、この関係を明らかにする。もし共通のエンティティが文脈兄弟のセットと共に可視にされ、その文脈兄弟のセットの適切なサブセットと共にすでに表示されている場合、新たに表示された文脈兄弟の内の対応関係にあるエンティティの中には実際には、それらの共有の子として提示されるノードと対応付けられｒたエンティティの親ではないものもあるので、パスを合併させるのは正しくない。よって、代わりに、これまでに表示された文脈兄弟のセットを隠すことで、衝突を解消する。
【0441】
[0678]一方、もし共通エンティティが兄弟のセットと共に現れるが、既にその文脈兄弟のセットの適切なスーパーセットと共に表示されている場合、少なくとも２つのオプションがある。
１．１つのオプションは、適切なサブセットの場合のように正確に進行することである。表示されている親のセットは常に、正確でそのエンティティの親の完全なセットであるように実施される。
２．他のオプションは、展開するノードの文脈兄弟として親の適切なスーパーセットの子を合併し、その表示されている親のセットがそのエンティティの親のサブセットであるだけでよいように実施される。これは、関連するノードの「クランピング」が多くなるという利点があるが、いくつかのノードの親が隠れてしまうという欠点もある。
【0442】
[0679]実施形態がローカスノードに跨る共通子孫を示す点に注目する場合、ローカスノードの文脈を介して一度に１つ以上のパスを連続して露わすことをサポートする必要はなくてもよい。しかし、一実施形態では、共通祖先がまだ露わされていない別々のローカスノードからのパスを示し、他のローカスノードを有する共通の祖先に導く他のローカスノードのからのパスに対しては「スタブ」を露わし、それらが共通祖先へのパスよりも短くなるようにすることを可能にする構成であってもよい。よって、戦略０６５２．１、戦略０６５２．２、戦略０６５３．１、または戦略０６５３．２については考慮しなくてもよい。
【0443】
[0680]「反転ツリーとしてのDAG文脈の提示」では、共通祖先の表示を、同じローカスノードのからの別々のパスにより慎重に回避（戦略０６６７．１の場合）、または全く禁止した（戦略０６６７．２の場合）。これは、過度な複雑化を軽減する点で効果があるが、そうしない場合は、DAGのツリーベースの提示の利点を損なってしまう。しかし、いくつかのエンティティを扱い、それらの文脈を展開することを選んだ場合、これらパスにより到達可能な共通祖先を全て見ることに興味を持つ者もいるかもしれない。
【0444】
[0681]文脈ノードを展開する際に、一度に１つの親が展開できる場合は、いくかの実施形態では、ノードの文脈兄弟の順番を調整し、展開されるノードがリストの一番上になるようにする構成であってもよい。これにより、文脈は自然なツリー構造で外向きに成長することができる。他の実施形態では、それらの順番を調整せず、表示された親は、それらの直下でインデントになっているノードまたはオープン状態にあるノードに関連していると理解される構成であってもよい。
【0445】
[0682]次に、共有された文脈がどのようにサブストレートツリーにて提示、またはより抽象的に、それぞれのツリーが文脈フレームである、ノードリストの森、つまりツリーのリスト、として示されるかを説明する。森は、ノードリストとその子文脈フレームを交互にインデントにすることでサブストレートツリーにて提示できる。ナビゲーションされるあるDAGと戦略０６６８．２下についてのアプローチを図１９８に示す。この図には、２つのバラエティのリストのネスティングされたシーケンスが示されている。最も外側のサブDAGリストは、その要素が文脈フレームである単純なリストである。文脈フレームは、ノードリストを含み、そこでは、各ノードが異なるエンティティに関する情報を提供している。文脈フレームは、内部的であってもよいし、リーフであってもよい。リーフは、空のサブDAGリスト有する１つのノードを有し、ローカスノードを参照する。内部フレームは、空ではないノードリストと空ではないサブDAGリストを有し、リストアップされたノードがまとめて各サブDAG内の最も上にあるオープンノードの親であるようにすることを目的とする。サブDAGリストは最後の親の子として配置され、ツリー構造を可視化できるソフトウェアを利用する構成であってもよく、またはサブフレームが、親の単一の明示的にインデントにされた兄弟として、または親の個々に明示的にインデントにされた兄弟として考慮されてもよく、またはインデントは、フレームのネスティングの深さをトラッキングしてグローバルに明示的に管理されてもよい。最もトップの内部フレームは、全ての非孤児である親はクローズ状態である。外のフレームは、オープン状態の第１ノードと後続のノードのみがクローズでり、次の１つ上のレベルの親は、これら第１ノードをそれらの共有の子として有していることを示している（一方クローズノードに対応付けされているエンティティの親は露われていない）。簡略化のため、この表のフレームの番号については、次の最も外側のフレームの番号に続く番号を付し、ノードの番号については、含まれるフレームの番号に続く番号を付したが、文脈の探査のプロセスは、外側方向に向かって進む。フレームｆについてリストアップされた親ノードの数をｎｆとする。図１９８のフレーム０とフレーム１は、共有する文脈がない２つのDAGである。フレーム０は、そのルートがオープンであり、ルート（ノード０．０．０、０．１．０、０．２．０）であり、その対応するエンティティがすべて同じセットの親を有するサブDAGを示す３つのサブフレームが後に続く親ノードを有している（エンティティはそれらの親ノードのと対応付けされている）。各フレーム（「０」で終わらないもの）の後継的親はクローズである。この全体のサブDAGリストは、最後の親（ノード０．（ｎ０−１）の子として配置されてもよい。この構造はフレーム０．１および０．１の場合にも再帰的に繰り返されているのが見える。そのような再帰は、１つ以上のリーフにたどり着くかもしれない。フレーム０．２は、リーフであり、よってリストアップされた正に１つのノード（ローカスノード）であり、サブフレームではない。しかし、このノードは、対応するエンティティに対応付けられたサブ構造を有していてもよい。上記説明では、リストは、いくつかの実施形態では、明示的に示さないように選択してもよいものを抽出した物abstraction?であり、そのような実施形態では、上記リストへの参照を、そのリストの要素をまとめて参照していると単に考慮してもよい。
【0447】
[0684]図１９９ないし図２０２は、一実施形態のユーザが文脈の共有をどのように経験するかの一例を示す。これら画面は、ユーザがスキルのDAGを探査するプロセスを表示している。図１９９は、３つのローカスノード「訴訟」「法制化」および「ネットワーキング」によるDAの初期の提示を示す。それぞれ別個のトップレベルのフレーム中にある。もしこの位置からユーザが、「訴訟」のスーパースキルである「論争」の文脈をオープンする場合、その結果は図２００に示すようなものになる。「論争」には「コミュニケーション」と「分析」という２つの親がある。「分析」がない「コミュニケーション」は、「ネットワーキング」の親であるので、「ネットワーキング」はこの実施形態では、「論争」のオープン時にクローズされ、どの１つのスキルも１回のみ現れる不変条件を維持する。ここで、「面接」をオープンすると「論争」がクローズされ、図２０１に示すように、「ネットワーキング」どうよう、その単独の親は、「コミュニケーション」であり、これらは「コミュニケーション」の下、別々のフレームに存在する。「法制化」をオープンすると、次は「書面化」であり、図２０２の画面に示すように、これも「コミュニケーション」の下、第３のフレームである。「面接」のフォルダを閉じると、図２０３の画面に導かれ、「法制化」を含むフレームが離れ、トップレベルまで移動される。様々なフレームが、各フレームの親の最も上のフォルダーがオープンであり、他のフォルダーが空かクローズである点で区別されるが、実施形態では、他の方法でこれらを区別してもよい（例えば、それらの周りにボーダーを引くなど）。
【0448】
[0685]文脈を折り畳む時、折り畳まれるノードの外側のローカスノードにより共有されていない（たとえあ、他のフレームと共有されていない）文脈のみを除くことが望まれるかもしれない。よって、その子孫ノードと対応付けされているローカスエンティティに対する参照を各フレームやノードに対して維持するのは便利である。これはソフトウェア開発の当業者にとっては明らかな事項なので、この情報を維持することの詳細を示さない。
【0449】
[0686]図２０４の初期化プロセスの第１ステージでは、図１９８の構造は、各ローカスエンティティごとに１つのトップレベルのリーフフレームと共に構築される。ローカスノードは、複数エンティティのダイナミックサブ構造の初期化時に構築されていると仮定する。残りは、図１８８と同様であるが、各ローカスノードについて繰り返され、複数エンティティ間で共有される必要に対する補助的ルーチンのバージョンを使用する。
【0450】
[0687]複数エンティティのダイナミック文脈展開は図１８９に示されるようなものであるが、「現ノードの子孫を最後の文脈兄弟の隣に移動させる」で参照された子孫は、フレームのリストの形態であってもよい。
【0451】
[0688]図２０５は、ダイナミック文脈折り畳み（複数エンティティ）２２３２００のプロセスを示す。該プロセスは、図１９０の単一バージョンと同様に開始されるが、追加のステップが必要となる。現ノードを含むフレームリストが現ノードより多くのローカス子孫を有している場合、文脈を単純に動かすことができない。なぜなら、ローカスノードを落としてしまうからである。（なお、ここで子孫とは、サブ構造ツリーにおける子孫を文字通り意味せず、根本的なDAGにおける子孫に関する文脈祖先を意味する。これらは、サブ構造における現ノードの最後の兄弟の下フレームリストのコンテンツにより現ノードに対応している。その代わり、現ノードをそれ自身のトップレベルフレームに移動させ、これらが現ノードの文脈と関係がなくとも、これらノードが保存されるようにする。そうでない場合は、（文脈の次の層を除いてもローカスノードは落ちない）図１９０のように進行する。
【0452】
[0689]複数エンティティについてダイナミック文脈を展開する様々な戦略（図２０６の複数のリーフでない子までのダイナミック文脈の展開（複数エンティティ）２２０２３０、図２０７の複数子までのダイナミック文脈の展開（複数エンティティ）２２０２４０、図２０８ｎ単項のダイナミック文脈の展開（複数エンティティ）２２０２５０）は、ここで説明する戦略０６７８．１の複数ローカスノードようの方法を実施する共通論理を多量に含んでいる。実施形態は、現エンティティの親を参照し、それらがサブストレートツリーに兄弟のセットとして存在しているかを判断することで始まる構成であってもよい（いくつかの実施形態では、これを親ノードの空でないセットに限定してもよい。なぜなら複数の殻のセットを残しても衝突は生じないからである）。そうである場合、現ノードを、その兄弟のセットの下の新たなフレームに移動させてもよい。または、親ノードのそのリストを作成してもよいが、文脈兄弟の既存の重複しているセットが除かれるようにする。後者はさらに図２１０に示されている。ここで説明する文脈兄弟の重複しているセットの除くプロセスは、論理的には、ダイナミック文脈中の兄弟の折り畳み（複数エンティティ）２２２２００に属するが、現エンティティの親と対応付けられたノードの他のチェックと共にここに記載し、各反復と共に実行されてもよいとする。ここで示し、さらに図２１１で示す他のステップが推奨されるが、いくつかの実施形態では、省略してもよい。展開が進むにつれ、現在トップレベルにあり、折り畳まれていない同じ親セットを有するノード（ここでお、空のセットを除外してもよい）は、新たな展開ノードにより捉えられてもよい。それは、現エンティティの親と対応付けられたノードのフルリストを構築するのに残る。これは、現ノード（展開されているもの）は、最後のそのようなノードの子になるように行われる。
【0453】
[0690]図２１０に、衝突する可視のノードを、それらのDAG子孫をトップレベルに挙げることにより、衝突している可視のノードを隠すための論理を示す。文脈兄弟の重複セットは、これら親エンティティのいずれかに既に対応付けされているノードの位置を割り出すことで見つけ出することができる。重複セットを除く前に、その下の各フレーム（DAGの共有の子の１つに対応）をフレームのトップレベルのリストに移動する。なお、トップレベルにないどのフレームおいても、第１文脈兄弟は、オープンである（それが、その親が探査されている子に対応付けされていることを示す）。よって、この第１文脈兄弟は、ｓのフレームがトップレベルに移動すると、クローズになる。文脈兄弟の任意のサブセットの下の各フレームが移動された後、これらノードは取り除かれる。
【0454】
[0691]図２１１に、そのノードが展開しているエンティティのDAG兄弟と対応付けられたノードを捉えるための論理を示す。各トップレベルのフレームでは、そのフレームノードの何れかが、露われているエンティティと同じ親を有している場合、トップレベルから該フレームを移動させ、展開されているノードの兄弟とし、マッチングノードをフレームのトプに移動させ、該マッチングノードの文脈をオープンする。
【0455】
[0692]この時点で、段落０６５３の各戦略に特異の論理を実行するが、これは図１９３、図１９４、および図１９５に示したものと同様になる。実際に、これら図面のそれぞれの第１活動は、上記で説明した、親ノードの構築である。複数のローカスエンティティについてここで説明するプロセスは、複数のリーフではない子までのダイナミック文脈の展開（複数エンティティ）２２０２３０および複数の子までのダイナミック文脈の展開（複数エンティティ）２２０２４０の繰り返しを、段落０６８９にて説明した論理にて継続する点のみで違う。
複数ツリーの共通サブ構造の準備
ここで、ユーザが子孫、つまりノードのサブ構造を探査するにつれ、各ローカスノードからツリーは下向きに成長する。我々の目的は、サブ構造の探査の際に、同じ子孫に続く２つ以上のローカスノードからのパスを見つけることである。
【0456】
[0693]サブ構造を展開するにつれ、露わになったサブ構造と対応付けされているエンティティと対応付けられたサブ構造を隠すという方法がある。ここで、複数のローカスノードがある場合、同じエンティティが１つ以上のローカスノードのサブ構造を介してアクセス可能であるなら、以下のように進行する。それぞれのケースで、当該共通の子孫エンティティが同じセットの兄弟と共に露わになった場合、パスを合併しこの関係を明らかにする。もし共通エンティティが兄弟のセットと共に露わになったが、既に他の重複した兄弟と共に表示されている場合は、パスを合併するのは正しくない。これは、新たに露わになった兄弟の中には、それと対応付けされたエンティティが実際には、それらの共通の親として提示されるノードのと対応付けされたエンティティの子ではないようなものもあるからである。よって、その代わりに、既に表示されている兄弟のセットを隠すことで、衝突を解消する。
【0457】
[0694]一方、もし共通エンティティが文脈兄弟のセットと共に露わになり、その文脈兄弟のセットの適切なスーパーセットと共に表示されている場合は、少なくとも２つのオプションがある。
１．１つのオプションは、適切なサブセットの場合と全く同じように進行し、表示された子のセットが必ず該エンティティの子の正確かつ完全な子のセットであるように実施する。
２．他のオプションは、展開されるノードの兄弟としてこの適切なスーパーセットの親を合併し、表示された子のセットが、当該エンティティの子のサブセットであればよいように実施する。これは、関連するノードの「クランピング」が多くなるという利点があるが、いくつかのノードの親が隠れてしまうという欠点もある。
【0458】
[0695]実施形態がローカスノードに跨る共通子孫を示す点に注目する場合、１つのノードのサブ構造を介して一度に１つ以上のパスを連続して露わすことをサポートする必要はなくてもよい。しかし、一実施形態では、共通祖先がまだ露わされていない別々のローカスノードからのパスを示し、他のローカスノードを有する共通の祖先に導く他のローカスノードのからのパスに対しては「スタブ」を露わし、それらが共通祖先へのパスよりも短くなるようにすることを可能にする構成であってもよい。よって、戦略０６５２．１、戦略０６５２．２、戦略０６５３．１、または戦略０６５３．２については考慮しなくてもよい。
【0459】
[0696]「ツリーとしてのDAGサブ構造の提示」では、共通祖先の表示を、同じローカスノードのからの別々のパスにより慎重に回避（戦略０６６７．１の場合）、または全く禁止した（戦略０６６７．２の場合）。これは、過度な複雑化を軽減する点で効果があるが、そうしない場合は、DAGのツリーベースの提示の利点を損なってしまう。しかし、いくつかのエンティティを扱い、それらのサブ構造を展開することを選んだ場合、これらパスにより到達可能な共通祖先を全て見ることに興味を持つ者もいるかもしれない。
【0460】
[0697]サブ構造ノードを展開する際に、一度に１つの子が展開できる場合は、いくかの実施形態では、ノードの文脈兄弟の順番を調整し、展開されるノードがリストの最後になるようにする構成であってもよい。他の実施形態では、それらの順番を調整せず、表示された子は、それらの上でインデントになっているノードまたはオープン状態にあるノードに関連していると理解される構成であってもよい。
【0461】
[0698]次に共有されたサブ構造をどのように１つのサブツリーとして提示することができるかを説明する。このアプローチを、ナビゲーションされるDAGと戦略０６６８．２について、図２１２に示す。この図に２つのバラエティのリストのネスティングされたシーケンスを示す。最も外側の根サブDAGリストは、その要素が根サブ構造フレームであるシンプルなリストである。サブ構造フレームは、インデントされたデータ（サブストレートツリーにおける子）が後続するメインノードを有する。ノードはオープン、クローズ、または空でありうる（段落０２８９のコメントによる）。メインノードの状態によりフレームをオープン、クローズ、または空とする。最も外側の根サブDAGリストの要素のメインノードには、示された共通のサブ構造はない。もしメインノードがオープンであるなら、インデントデータは、最終子のサブ構造フレームにより後続されるクローズの子ノードののノードリストを含む（いくつかの実施形態ではオープンな子は最後の位置に移動されると仮定する）。メインノードの状態に関わらず、このデータは、根内部サブDAGリストにより後続される。もちろん、このデータは、実施形態において好適であれば、１つのリストであっても、リストのリストであってもよい。根サブ構造フレームは、メインノードがローカスノードであるサブ構造フレームである。サブ構造フレームは、それぞれサブ構造フレーム内の子ノードの有無により内部サブ構造フレームまたは、リーフサブ構造フレームである（なお、示されているエンティティは根本的なDAGにおいてリーフである必要はない）。様々な実施形態では、もっとも外側の根サブ構造フレームは、リーフまたは内部であってもよいが、他の根サブ構造フレームは、共有されたサブ構造に導くものであるので、内部でなければならない。フルサブDAGリストは、根内部サブDAGリストの要素により後続される最後の子サブ構造フレームにより形成されたリストと定義する。なお、オープンのサブ構造フレームは、メインノードがサブストレートツリーに子を有せず、根内部サブDAGリストが空のときは、空のフルサブDAGを有してもよい。フレームの高さを以下のように定義する。空のフルサブDAGリストを有するフレームの高さは１である。または、内部フレームの高さは、そのフルサブDAGリストの最後のフレームの高さより１高い。内部サブ構造フレームの終了フレームは、もしもフルサブDAGリストの最後のフレームの終了フレームがある場合は、そのフレームであり、ない場合は、内部サブ構造フレーム自身である。内部サブ構造フレームのフルサブDAGリストのフレームは、いくつかの実施形態では、高さが増加する。テイル位置を以下のように定義する。トップレベルの根サブDAGリストはすべてテイル位置にある。もしあるフレームがテイル位置にあり、空でないフルサブDAGリストを有している場合は、フルサブDAGリストの最後の要素がテイル位置にある。テイル位置にあるフレームの終了フレームはクローズされている。他のすべてのフレームの終了フレームはオープンであり、そのようなオープンフレームのすべてをサブストレートツリーの同じ深さで配列してもよい（根内部サブDAGリストはこの場合ように配列される）。上記から、いくつかの実施形態では、最後の子サブ構造フレームがクローズである内部サブ構造フレームは、空の根内部サブDAGリストを有する。最後の子サブ構造フレームがオープンである内部フレームは、空または空でない根内部サ
【0462】
[0699]ノードリストのノードと、最後の子サブ構造フレームのメインノードがまとめて包括的サブ構造フレームのメインノードの子であることが意図されている。（いつものように、クローズのノードに対応付けされているエンティティの子は露わになっていない）。また、最後の根内部サブDAGノードの任意の子孫の親は、サブストレートツリー内の中間親だけでなく、フルサブDAGリストの先行するあらゆる要素から伝承され、該中間親と並んでいる全てのオープンなリーフノードを含む。根内部サブDAGリスト（またはその要素のそれぞれ）は、メインノードの子として配置され、ツリー構造を可視化できるソフトウェアを活用したり、フレームのネスティングの深さをトラッキングすることで明示的にグローバルに管理できるインデンテーションを活用したりする構成であってもよい。簡略化のため、図２１２において、慣習に従い、次の最も外側のフレームのメインノードの番号に続く番号を付すことで、ローカスノードに対して順番に番号を付し、また子ノード（新たなフレームのメインノードでもある最後の子ノードを含む）にも番号を付している。ローカスノード０および１は、文脈を共有していない２つのトップレベルのDAGのメインノードであり、ノード３．１．０は、ローカスノード０、２および３の共通子孫である。ノード３．１．０により示されているエンティティの根本的なDAGの親は、ノード０．（ｎ０−１）．（ｎ０．（ｎ０−１）−１）、２および３．１により示されるエンティティを含む。上記の説明では、リストはいくつかの実施形態が明示的に示さないことを選択したものを抽出したものであり、そのような実施形態は、リストへの参照をそのリストの要素を単にまとめて参照するものと考えてもよい。
【0463】
[0700]共通の子孫の祖先である根サブ構造フレームは、トップレベルから根サブ構造フレームまでと根サブ構造フレームからその共通子孫ノードまでの合計の距離を均等にするように配置されることが意図される。これは、各サブ構造フレームノードを有する論理サブ構造ツリーでの深さを記録することで達成することができる。サブ構造ノードを展開する際に、露わになる子それぞれを、サブストレートに既存であるかどうか確認する。展開されるノードの深さ以上の深さで存在しているなら、必要に応じてノードを折り畳み、展開されたノードを含むトップレベルのフレームをフレームの際だけ下方に移動させる。展開されるノードの深さ以下の深さで存在しているなら、子を既存のノードから展開するノードに移動させ、フレームの順番を再調整して高さが増加する不変条件を維持する。
【0464】
[0701]最後に、どのように、文脈をサブ構造と共に１つのサブストレートツリーとして提示できるかについて提示する。単純なアプローチは、ノードをサブ構造について展開する場合、まず当該ノードの全ての文脈を折り畳み、ローカスノードで高さをカウントすることが開始できるようにする。しかし、高さの算出について文脈を含むことができ、共通の祖先の対応関係を解消する必要があるときにのみ文脈を折り畳むことができるのは、明白であろう。
【0465】
複数ノードの選択[0702]
この提示フレームワークはノードの選択をサポートでき、衝突するものを含み、同じツリーに全てを表示できないようなノードのセットの選択であってもサポートする。ノード表示の戦略が限定的であった場合、ユーザに一緒に可視にできるノードを選択することを可能にするだけで済ませてはならない。ノードが可視でなくなっても、そのノード、または識別子の全体、またはそこから根までのパスをノードまたはエンティティ識別子のシーケンスとして記憶することができる。クライアントのローカライズ済みDAG構造を前提とすると、これらはどのような目的にも十分である。クライアントが、可視でなくなった選択されたノードを再度表示することを必要とする場合、根までのそのパスを使用し、段落０４２６にて説明し、図２１３に図示したサブ構造によりパスを介してアクセス可能なノードの表示１１２２５０、または段落０４６６で説明し、図２１４に図示した文脈によりパスを介してアクセス可能なノードの表示２１２２５０を用いてこれを行うことができる。既存のツリーをクリアし、パスを辿ることで再オープンさせるより、表示済みのノードをトラッキングし（根は常に表示済みと仮定する）、パスにおいて可視ではないノードに達するまで根からパスを辿るほうが好ましい。そして、パス上の各ノードについて、衝突ノード（採用中の戦略に基づいて）とクローズし、そしてパス上の次のノードをオープン（展開）し、それを子のセットから選択する。一実施形態では、ノードの展開の際に任意の戦略を使用することを選択できる。もし一度に展開するノードが１つの場合、後続のノードは可視ではないと仮定でき、よって、その地点の直後のものを展開できる。
【0466】
[0703]ノードを選択し、そして、サブ構造を、選択したノードが可視でなくなるように改変してから他のノードからの操作を実行する一例を図１１３および１１４に示し、段落０４９７に説明している。
【0467】
補助情報と集約補助情報の集約
[0704]
様々な情報を、根本的なDAGにて関連付けされたエンティティと対応付けすることができる。プロジェクトのヒエラルキの探査時に、関連する補助情報を閲覧する直観的な方法を有ることが望ましい。補助情報は、DAG短縮プロセス時に収集することができ、各エンティティに関する個々の情報は、ローカライズされたDAGの該エンティティの記録に保存される。
【0468】
[0705]プロジェクトに関する補助情報の例としては、取引データ（段落０７２９に記載するように、資金の出資、またはプロジェクトへの貢献）、トータルの貢献、資金の利用可能な全額、プロジェクトの進捗報告、アップロードされたファイル、そしてプロジェクト活動のストリームなどが挙げられる。ファイルの場合、ファイル自体をローカルDAGを有するクライアントに提供せず、そのメタデータのみを提供してもよい。実施形態のサポートおよびユーザからの指示により、ファイルはダウンロードしても、遠隔からアクセスしてもよい。ユーザのプロジェクトにおける様々な役割（段落０８２２）や必要とされるスキルなど関連するエンティティについての情報を含んでいてもよい。ツリーサイズや最近の構築やアクセスなどの他の補助データも直接的に表示されず、所定のノードの、その兄弟と比較した、興味についての「ヒートマップ」を提供するのに使用されてもよい。また、実施形態は、ある問題の詳細化の優先度のスタンドアローン型測定のトップダウンの特殊化（親プロジェクトのプロジェクト管理者によるもの）または他のプロジェクトの子をサポートするものであってもよい。相互に排除的なプロジェクト詳細化の場合は、実施形態は、例えば、段落０７２８に記載の技術を使って、様々なプロジェクト詳細化間の関連する優先度の設定をサポートしていてもよい。
【0469】
[0706]実施形態は、あるエンティティに対応付けられた補助情報を、そのエンティティを参照するノードから、例えば、ユーザのリクエストがあった場合のみ、閲覧できるように構成されていてもよい。
【0470】
[0707]「アクティブ」な集約は、ユーザが注目するあるノードと対応付けられた補助情報を含む。実施形態は、アクティブ集約を、オープンおよび空のノードからなると考えてもよく、または好ましくは、全ての可視のノードからなると考えてもよい。より良い制御のため、集約は、可視のノードの、ユーザが選択したサブセットのみがアクティブな集約でると考えてもよく、それらは適宜影付きであったり、他の区別を付けられていてもよい。しかし、アクティブ集約は常にローカスノードを含む連続した領域からなる。そのような実施形態は、ユーザに適切なサブ構造または文脈の選択されていないノードを選択させて、含める構成であったり、それにより暗黙的にローカスまでの全てのノードを含めてもよい。逆に、ユーザに適切なサブ構造または文脈中の選択されたノードを選択から外させる構成であってもよく、これはそのノードに根がある論理ツリーを暗黙的に非選択にしてもよい。ヒエラルキ内のノードは展開され（選択された可視のノード）、新たに露わになった（選択された）ノードと対応付けされている補助情報がアクティブ集約に追加される構成であってもよいく、一方明示的な折り畳みで隠れているノードや、展開時に暗黙的に折り畳まれており隠れている（または選択解除された）ノードと対応付けられている補助情報はアクティブ集約から除かれる構成であってもよい。アクティブ集約は第１DAGと共に可視である必要がある。
【0471】
[0708]クローズな文脈添加をしている各文脈ノードは、それ自身を含め、その全ての祖先について集約、または好ましくは、その適切な祖先全てのについて集約しており、クローズなサブ構造展開をしているクローズなサブ構造ノードについては、それ自身を含めて、その全ての子孫、または好ましくは、その適切な子孫の全てについて集約していてもよい（前者を「全体的」後者を「構成要素的」と称す）。これを各クローズな展開について提示する代わりに（またはそれに加え）、いくつかの実施形態ではそれをローカスノードに対してのみ提示する構成であってもよい（この場合恐らくDAG探査の状況を考慮することなく、また恐らくローカスノードも含める）。これら集約は、ユーザにユーザのリクエストがあった時のみ提示されるものであってもよい。実施形態では、クローズなフロンティナにおける全てのノードのクローズな展開集約を維持することを望ましいとしたり、集約がリクエストされた時のみ、算出を行うことを望ましいとするかもしれない。これらをキャッシュして、ユーザのインタラクション時に度々再演算しなくてもよいように構成してもよい。クローズのフォルダにより示されるエンティティのいくつかは、段落０３２８に記載のように、クライアントに渡すのではなく保留されているものもあり、実施形態では、結果に「追加（more)」リンクを含み、ユーザにもっと補助情報あることを教え、起動（アクティベート）された場合は追加のオードのその補助データのローカルDAGへのロードをトリガする構成であってもよい。
【0472】
[0709]また、いくつかの実施形態では、アクティブ集約の他、フル全体的および／または構成要素的集約をサポートし、全ての全体的および構成要素的クローズ文脈展開の全てそれぞれからの情報を集約する構成をサポートするのを望ましいとするかもしれない。
【0473】
[0710]例えば、サブ構造展開を有したサブ構造ノードは、適切な子孫に関する取引データを集約する構成であってもよい。オープンされると、各子の取引データは、そのノードを介してアクセス可能になってもよく、各子ノードのサブ構造展開（クローズと仮定）は適切な子孫の取引の別々の集約と対応付けされる構成であってもよい。
【0474】
[0711]ファイルからなる補助情報について図２１５ないし図２１６の実施形態とインタラクトするユーザが経験する他の例を挙げる。これらファイルは、ユーザがアイコンんを適切な領域にドラッグしたり、該領域にからドラッグすることでアップロードやダウンロードされてもよい。関連するファイルは、「依存性」タブの第１DAGとのユーザのインタラクションに依存して表示される。ここでは、全ての可視ノードは、アクティブ集約に含まれていると仮定する。図２１５は、５つの可視のノードを有するプロジェクト画面を示す。ユーザがカーソルを可視のノードのメインアイコンの上に持ってくると、クリックでテキスト「補助」が現れる。よって、図２１６から図２２０に示すように、それぞれの個々のノードと対応付けられたファイルが現れ、アクティブ集約これらファイルの全てが含まれる。図２２１は、ローカスノードや可視の文脈と対応付けられたファイルを含むアクティブ集約を示す。図２２２は、ローカスノードと可視のサブ構造と対応したファイルを含む。そして図２２３は、ローカスノードのみに対応したファイルを含む。テキスト「補助」もユーザがクローズのフォルダーアイコンの上にカーソルを持ってくると現れる。図２２４と図２２５は、各クローズのフォルダがファイルが１つのプロジェクトを含む様子を示す。これらは両方とも図２２６の構成要素タブから見ることができる。
【0475】
集約補助情報の提示[0712]
ある集約については、特に、集約が、含まれる値をまとめたものよりスペースを取らない、例えばサブツリーサイズの測定値などのスカラや数量的値の場合、実施形態では、状態に関わらず、各ノードの集約を保存し、DAGが拡張された時に、必要に応じて調整することをすることを選択するかもしれない。
【0476】
[0713]アクティブ集約と「クローズ」集約の両方で、様々な実施形態では、１つ以上のパスにより到達できる祖先や子孫の補助情報を２重にカウントすることを回避することに留意する必要がある。集合集約では、二重カウントは不可能であり、よって懸念にはならないが、他の形態の集約では、懸念になりうる。
【0477】
[0714]フォルダをクローズする際に、その集約は、消える子孫ノードの個々の値（まさに様々な実施形態ではアクティブ集約から一度取り除いたもの）とその子孫展開の集約とを組み合わせてもよい。集約の各補助情報がオリジンの「ツリー」ノードの住在エンティティでタグ付けされている（または均等なものとして、DAGノードでタグ付けされている）場合、２重カウントすることなく、フォルダのクローズの際に集約を効果的に組み合わせることができる。さらに好ましくは、補助情報は、補助情報の起源であるエンティティから各データへのマッピングとして示すことができる。フォルダのクローズ時に集約を組み合わせるために、実施形態では、クローズのノードの個々のデータから始め、示される全てのエンティティのリストを保持する構成であっても良い。各子ノードと、該子ノードにデータを供給し、まだ遭遇されていない各エンティティについては、その実施形態では供給されたデータを新たな集約に合併する。
【0478】
[0715]この合併プロセスを標準化するため、実施形態では、あるエンティティから到達できる、集約中の情報のキー成分とバリュー成分とを分離する構成であってもよい。集約情報は維持され、キーにより整理して提示されてもよい。
【0479】
[0716]オープンされたフォルダーにおいて、様々な実施形態においては、各子ノードは、これまでクローズのフォルダの、該ノード自身と対応付けられているデータを得る。そしてそのデータはアクティブ集約に追加される。様々な実施形態において、各子ノード展開フォルダは、クローズの場合、ノードのこれまでクローズだった展開についての古い集約のサブセットである集約を得る。実施形態では、残りのデータ（オープンのノードのエンティティとは関係がないもの）の起源である各エンティティと、各子ノードについて、該エンティティが該子ノードの子孫であるかどうかを確認し、そうであれば、そのデータを該子の集約に含める構成であってもよい。または、実施形態では、各子の集約をその成分から再構築することを試みる構成であってもよい。
【0480】
[0717]ノードのオープンをより効率的に処理するため、クローズなノードの集約のデータは、起源のノードの住在エンティティからではなく、例えば、明示されたソースとシンクを有するDAGなどの、クローズのノードから起源のノードへの「フロー」の提示からのマッピングの形態を取ってもよい。これらフローは、詳細化関係に限定されず、他の関係を含んでいてもよい。
【0481】
[0718]以下のDAGの提示を提案する：
【表11】
[この文献は図面を表示できません]
【0482】
[0719]この文法は、フローが明示されたソースとシンクを有し、リンクの形態を取ったボディ、２つ以上のフローのシーケンス、または２つ以上のフローの集合を提供する。さらに、ここでは、シーケンスについて、第１フローがシーケンスフローのソースとマッチしたソースを有し、最後のフローがシーケンスフローのシンクとマッチしたシンクを有し、第１と最後のフローの間の各フローについては、ソースが前のフローのシンクとマッチし、シンクが次のフローのソースとマッチし、集合については、集合の各フローが、集合のフローのソースとシンクとマッチするソースとシンクを有しい、様々なフローはお互いを包含しないことを必要とする。
【0483】
[0720]シーケンスフローは、シーケンスフローは、同じ数のセグメントを有する同じソースとシンクの間のシーケンスを包含し、成分フローについて、そのセグメントフローにより包含されるフローの代理となるとする。集合フローは、そのコレクションにおける全てのフローを包含するとする。フローの包含関係は、過渡的で再帰的である。
【0484】
[0721]直感的には、フローは空（ソースとのリンクはシンクと同じ）、２つのノードの間の単純なアーク（またはリンク）、端同士を繋げるとソースからシンクへ導くフローのシーケンス、またはフローの集合であり、それらは全て交互のパスを介してソースからシンクへ導くものである。
【0485】
[0722]これらフローは、DAGをソースノードから走査して生成されることができ、毎回、あるノードと遭遇して、既存のフローに遭遇するパスを、そのバスがフローを介して既にアクセス可能でない限り、パスに沿って要素を接続するリンクのシーケンスを有する集合として追加し、その場合フローはそのままの状態で保たれることができる。
【0486】
[0723]パスを有するフローを拡張する他の方法は以下のようです。空のフローについては、パスを、空ではないリンクのシーケンスとして単に受け入れる。空でないリンクについては、空ではないリンクのシーケンスを有した集合を生成する。他のシーケンスについては、もしそれが中間のエンティティの同じリストを有している場合は、シーケンスを生成し、空ではないリンクを有するシーケンスの各フローを拡張する。または、２つのシーケンスの集合を生成する（また、共通のプレフィックスを抽出し、各シーケンスの残りの集合によりそれを辿ることも可能である）。集合については、もしパスがコレクションの要素の何れにも包含されていないなら、それを追加し、それが包含する要素を全て取り除く。空でないリンクを有する空でないリンクを拡張するためには、単にリンクを返送する。空でないリンクを有する集合を拡張するためには、もしそれがまだ集合に入っていないなら、追加する。
【0487】
[0724]そして、様々な実施形態では、クローズなノードがオープンされると、該ノードは、個々のデータとして、ノードからそれ自身（空の集合）までの空のフローに対応づけられているこれまでクローズのデータを受け取る。その子のそれぞれは、これまでクローズのノードのフローを、それぞれノード（子に対応）と該ノードからシンクまでのフローからなるペアのセットに分解することで得られたフローと対応づけられた集約データを割り当てられることができる。各子は、分解の結果であるフローの１つの下、それが分解の結果であるノードとマッチするフローのデータを割り当てられる。
【0488】
[0725]分解プロセスは以下のようである。リンクについては、結果は、シンクノードと空のフローのペアのシングルトンのセットである。シーケンスについては、シーケンスの第１フローを繰り返し、ペアのセットを得る。各ペアにおいて、ノードをそのままにし、フローを以下のように改変する。もしオリジナルのシーケンスの長さが２であり、ペアのフローが空の場合は、ペアのフローはシーケンスの第２セグメントである。そうでない場合、フローは、ペアのフローを第１セグメントで置き換えて形成されたシーケンスである。集合の場合、集合の各要素を繰り返し、ペアのセットを得る。ノードとして示される各エンティティについて、該エンティティのペアと各フローの集合を、そのエンティティとペアで形成する。
【0489】
[0726]情報リクエストがサーバにより保留になっている場合は、クローズのフォルダの集約はまだ完了していない可能性があり、追加のデータをリクエストして増強することができる。
【0490】
[0727]実施形態では、補助情報を集約する際に継承済みのノードを含めたり、除外したりしてもよく、それらは、ユーザに、例えばチェックボックを介して、その選択肢を提示する構成であってもよい。後者の場合、いくつかの実施形態では、各集約の２つのバージョンを維持し（少なくとも補助情報を有する継承されたノードが存在する場合）、それらの間を簡単にシフトできる構成であってもよいが、他の実施形態では、ユーザが選択を変更すると集約を再算出する構成であってもよい。継承されたノードが除外された場合、その補助情報は、様々な集約の何れにも加えられない。
【0491】
特別な補助情報兄弟プロジェクト間のパーセンテージの設定
[0728]
どのような場合であれ、時に、親プロジェクトに関する量的情報を子の間に割り当てるパーセンテージを設定する必要がある。これは、親プロジェクト自体から、トータルで１００になる数字を入力し、または、好ましくは、各子プロジェクトを示す領域にフィールドを分けラインの位置を調整することで行うことができる（いくつかのケースでは、ある種（問題または解決法）の子のみを選択することが好適であってもよい）。この分割プロセスについて、ノードの兄弟のツリーベース画面を重ねることも可能である。
【0492】
提供と支払[0729]
いくつかの実施形態では、システムのユーザによる資金の提供（おそらく、問題だけに対して）、または労力の提供（恐らく解決法のみに対して）をサポートする構成であってもよい。そのような提供は、そのプロジェクトを閲覧する際のユーザの文脈メニューにおけるオプションを介してトリガしてもよい。以下では、資金について注目するが、実施形態はこれらの概念を、例えば、解決法に対する労力の提供のサマリの表示の際に、労力について適応してもよい。
【0493】
[0730]システムは、資金がプロジェクト管理者を介して直接流れるか否かに関わらず、プロジェクトに提供される資金をトラックする構成であってもよい。もしそうでない場合は、システムの様々な実施形態は、プロジェクトのための支払いをトラックすることを希望するかもしれないが、そうである場合は、これは所望されても所望されなくてもよい。
【0494】
[0731]ローカスノードの文脈やサブ構造に提供された資金全額および支払われた資金全額を可視化することをサポートするのは便利であろう。実施形態では、このスカラデータ（段落０７１２に示すようなもの）を、ここのオープンノードについて表示し、「全体的」および「構成要素的」集約のために集約することを可能にする構成であってもよい。さらに、実施形態では、いくつかのシチュエーションでは、DAGノードの表示を、資金の提供元や資金の支払先に限定したり、そのようなノードが到達可能な者に限定する構成であってもよい。
【0495】
[0732]資金がプロジェクトに対して提供された場合、プロジェクト管理者は、それを任意のより低いレベルのプロジェクトに使用することが望ましいとするかもしれない。これは常にサポートされていなければならない。
【0496】
[0733]また、プロジェクト管理者は、それらを任意のより高いレベルのプロジェクトに使用することが望ましいとするかもしれない。これは、団体全体に資するインフラや共通閉扉であり、よって高いレベルにあるものかもしれない。プロジェクトの設定を介して、許可可能なパーセンテージは、提供物の上方移管について設定することができる。様々なチェックを、望ましいのであれば、実施し、兄弟プロジェクトへの下向きのフローから上方向への資金移動を防いだり、しないことを推奨したりすることもできる。例えば、下向きの移管に適切なものと適切でないもの、または、資金について、特定のプロジェクトへの下向きの資金移管について適切なものと適切でないものとの間を分割して維持しすることができる（使用かのうな資金の全額の各分割と適格なプロジェクトのセットを対応付けする）。より具体的には、システムは、特定の子プロジェクト間で上向きの資金移動（パーセンテージまたは全体）の予想を登録することもできる。
【0497】
[0734]賃料などのコスト情報を、それが依存する解決法の最も高いレベルにおける時間ベースの補助情報として適用し、トラックすることができる。または、不動産を、実施形態によっては、他のエンティティタイプとして、それ自体のヒエラルキの詳細（建物、階、等）や、解決法と位置との間の多数対多数のクロス種類関係と共に閲覧することができる。
【0498】
[0735]サラリー情報は、団体（ユーザ）ヒエラルキに結合された、時間ベースの補助情報である。
【0499】
[0736]これらのケースは両方とも、個人や場所が提供しているものを、様々な解決法間で割り当てる必要がある。これは、均等で分割することをデフォルトとしてもよいが、所望の割合で調整も可能である。サラリ情報のケースでは、分割は、時間でのトラッキングに基づいて、チェックインを介して行うことができる（段落０７５６参照）。
【0500】
予算サポート[0737]
上記（段落０７０５）で説明した進捗報告は、団体の中心または末端にいるかに関わらず、個人が、その業績を判断するのに使用可能な、広い目的の達成度に関する質的情報を提供する。また、そのような測定値は、それらプロジェクトにおける各人の責任を反映していてもよい。
【0501】
[0738]また、実施形態は、業績の測定値として、量的ゴールを設定することをサポートしてもよい。業績ゴールは、標準的なもの（収益、収入、コスト削減、顧客維持）でも、またはプロジェクトに特異なもの（例えば、学校の学生の標準試験の点数の向上）でもよい。後者をサポートするために、実施形態は、問題に対する業績測定値の定義をサポートしてもよい。時間ベースのゴールや予想を確立し、実際の結果に対して追跡してもよい。実施形態は、様々な周期性（年間、四半期、月間、等）をサポートし、例えば、経時的な増減率を選択しつつ、ゴールや予想の初期値を指定することを可能にしてもよい。問題について確立された指標は、プロジェクトのヒエラルキを介して継承され、低いレベルのプロジェクトが、親プロジェクトのレベルにおいて定義されたパーセンテージに基づき、結果の一部の責任について加えすることができるようにする。もちろん、低いレベルのプロジェクトもそれ自身の業績測定を確立することができる。業績測定が確立すると、そのプロジェクトのレベルまたはそれより低いレベルのプロジェクトのレベルで、対応する結果の入力が可能になる。所定のプロジェクトについて、様々な基礎値（ゴール、予想、実値）をお互いに対して表示するのは当然である。
【0502】
[0739]相互に排除的な詳細化をサポートする実施形態の場合（段落０６３１参照）、基礎値毎に１つのバーを当て、同じ長さであるかどうかについて標準化し、それぞれ各特殊化対象の問題（または解決法）の寄与または寄与予想によりコード化されたマルチバーチャートとして、目的に対する１つの測定値についての業績を閲覧することができる。ヒエラルキがある場合（標準のマルチレベルの部署やサブ部署の階層、または、問題と解決法の両方を含んだプロジェクトヒエラルキの場合）、結果について詳細を調べることができる。例えば、ある詳細化を示すバーの一部をクリックすることで、そのバーが拡張されて（それまでのバーを置き換えるまたはその横に形で）、プロジェクト構造の次の下層を反映した複数バーとなる構成であってもよい。
【0503】
[0740]そのような兄弟プロジェクトは、予想値を達成またはそれを超えた分で評価され、プロジェクトを目盛りの両端でハイライトする。それらがバーチャートの各マルチバーでリストアップされる順番は、その順番を反映したものであってもよい。
【0504】
[0741]いずれのユーザについても、そのようなチャートは、ユーザが管理者なり協力者である各プロジェクトについて閲覧できる。もし業績測定値が、それら全部に跨るものであるなら、それらを合併させ、上記のように、ユーザレベルから各プロジェクトに詳細を調べることができるようにしてもよい。
【0505】
一般的なデータセット[0742]
より一般的には、データセットは、プロジェクトと対応付けされ、ローカライズされたDAGのユーザによる探査に基づいて集約されてもよい。集約された数値データは、各選択した属性について（ここおよび下記では、直接的に保存され、算出されるデータ属性を考える）それぞれ、１本のバーや線からなるバーチャートやグラフとして提示されてもよい。地理的データは、マップとして提示され、別々のデータポイントがマークされたり、各領域が、それに関連する集約された値のレベルに基づいて影付きになっていてもよい。
【0506】
[0743]個々のプロジェクトを、SQL、URLの形態、または他の形態のデータセットへのクエリと対応付けることができる。特定のノードのデータは、クエリの解消の結果、例えば、関連するデータベースアイテム（論理的ジョイン演算により生成されたものを含む、記録）の特定とこれら記録から適切な属性値を抽出した結果である。データセットの仕様は、暗黙的、明示的に関わらず、データベースのソース、選択するデータアイテムについて保持される必要がある条件、そしてこれらデータアイテムから抽出される属性値の表現を含む。様々な選択されたデータアイテムの抽出されたデータ値を集約する手段は、後者の表現に含まれていてもよいし、別途提供されてもよい。上記のように、ユーザがノードを展開すると、新たに露わになったノードにおけるエンティティに関する追加のデータポイントを集約の表示に加え、ユーザがノードを畳むと、新たに隠れたノードにおけるエンティティに関するデータポイントを除く。
【0507】
[0744]ノードがアクセスされる度にデータベースの毎回開閉することを避けるため、実施形態は、ユーザが、データベースと、データベースへのクエリがなされるエンティティの最小上界とを対応付けすることを可能にする構成であってもよい。
【0508】
プロジェクトIP[0745]
解決法は、特許、特許出願、または特許または特許出願の特定の請求項と対応付けられていてもよい。
【0509】
[0746]特許と請求項は、実施形態ではエンティティとして取り扱われる。これにより、請求項の従属構造を解決法詳細化ヒエラルキに結び付ける機会を提供する。例えば、一実施形態では、請求項から解決法へのクロス種類関係やクレームに関する詳細化関係をサポートすることができる。そして、詳細化対象解決法は、詳細化済みの解決法の請求項を継承することができる。詳細化対象の解決法について継承された請求項を更新することで、新たな請求項が詳細化対象の解決法の説明と、継承済みの請求項の詳細化の両方を行うことを反映したダイアモンド構造を生成することができる。
【0510】
コードと解決法との対応づけ[0747]
従来のバージョンのコントロールシステムでコード記憶部とプロジェクトとを関連付けると、子孫解決法は、その記憶部からの（基礎の）ブランチと対応付けられ、詳細化対象解決法はみな、派生（おそらく間接的）なブランチと対応付けられるだろう。ブランチと対応付けられた複数の他の解決法を詳細化する解決法は、これらブランチの束を含むブランチと対応付けられてもよい。派生したブランチのコードが基礎のブランチのコードを詳細化する保証は、技術的な意味ではなく、そしてそれを意図していたとしても、基礎のブランチが派生的なブランチに再度継がれていく場合のみ可能であろう。
【0511】
[0748]解決法は、オブジェクト指向言語にて（基礎の）クラスと対応付けられていてもよい。この場合、詳細化対象解決法は、基礎のクラスから（恐らく間接的に）派生したクラスと対応付けられてもよい。または、解決法は、（基礎の）クラスの方法と対応付けられてもよい。その場合、詳細化対象の解決法は、基礎のクラスから（恐らく間接的に）派生したクラスと同じ方法と対応づけられてもよい。いずれの場合でも、派生したクラスのコードが基礎のクラスのコードを詳細化する技術的な保証はない。複数の継承をサポートする言語にてクラスやその方法と対応付けられた複数の他の解決法を詳細化する解決法は、これらクラスのそれぞれやそのクラスの方法から派生したクラスと対応付けられてもよい。
【0512】
DAGフィルタリング[0749]
ユーザが、ファセットブラウジングを介して、エンティティを選択し、DAGに、それらの性質／関係／ユーザ履歴によりローカスとして含めることを可能とする構成であってもよい。このDAGフィルタリングは、ユーザに、それぞれ可能性のある属性値や関係の種類についてのチェックボックス群として提供されることができ、それによりユーザは、どのエンティティを、それらが指定された値の何れかに設定されるか、アクティブユーザや第１DAGのローカスなど指定されたエンティティとの対応関係にあるかに基づいて、含めるかを示す。その場合、ユーザは、他の、関連する、エンティティを探査し、選択されたエンティティとの関係を見つける。フィルタする性質は、解決法状態（段落０６３３）を含んでいてもよい。関係によりフィルタする場合は、ユーザは、図４に示すように、そのためにプロジェクトを確認するかれらの１つ以上の役割を選択することができる。または、ユーザ経歴でフィルタする場合は、１つ以上の活動（プロジェクトのための資金調達やボランティア活動など）および１つの周期性またはデータ範囲を選択し、その期間においてこれら活動を行うプロジェクトを閲覧する構成であってもよい。貢献については、貢献量にてフィルタすることが可能としてもよい。
【0513】
[0750]プロジェクトにチェックインしたプロジェクト管理者については（段落０７５４）、含めるユーザを１つ以上の役割や時間および貢献の記述子を選択することが可能なように同様に構成してもよい。
【0514】
[0751]また、プロジェクト管理者は、比較のため、資金提供先のプロジェクトと、支払先のプロジェクトを選択し、または、労力の提供先のプロジェクトを選択することができるべきである。
【0515】
[0752]例えば、周期性（年間、四半期、月間など）により、または期間により、現在の情報ではなく過去の情報について、補助情報をさらにフィルタすることが可能な構成であってもよい。
【0516】
[0753]このDAGフィルタリングは、以下のように実施可能である。サーバは、可能性のあるエンティティ全てを含むが、デフォルトの選択またはユーザの以前の選択の記録に基づいて、その内の一部（およびその祖先や子孫）を、隠してマーキングしているローカルDAGを構築する構成であってもよい。様々なオプションが別々のデータベースフィールドとして（例えば、オブジェクト関係マッピング（ORM)システムでの別々のサブクラスのフィールドとして）保存されている場合、それらはそれぞれ、ローカスエンティティのリストを生成する際にアクセスされてもよい。サーバは、ファセット値から、そのような値に直接関係するエンティティｉｄへのマッピングを構築し、エンティティ記述子のセットと共に、あるエンティティがファセット値の選択に該当するか否かを各ファセット値の選択について判断するのに十分な情報を含めて、クライアントに渡す構成であってもよい。重要な事は、エンティティのヒエラルキ的提示では、もし直接的な対応関係が所定のエンティティと任意のエンティティ間にある場合や該任意のエンティティの適切な祖先がある場合は、任意のエンティティがしばしば、該所定のエンティティとの関係に対応するファセット値の選択に該当すると解釈される。実施形態では、そのような記述子をDAGローカライゼーション時に構築する際に、もしエンティティがファセット値に該当する場合は、その子孫は全てそうであり、もしエンティティがファセット値に該当しない場合は、その祖先の何れも該当しない点を考慮してもよい。そのような記述子は、段落０７５８に記載のように構築されたものを含んでいてもよい。様々な実施形態では、クライアントはこのマップと記述子を受け取り、文脈およびサブ構造（または戦略０６５６．１の場合はサーバ）を初期化し、初期に選択されたファセット値と記述子情報に基づいて要素を表示し、そして各ファセット値を選択または非選択のイベントを処理し、どのファセット値が表示されるものであるかの記録を保持する。いくつかの実施形態では、ローカスノードが関係していると認識されることを可能にするが、他の実施形態では、そうではない。ファセット値が選択された時に、クライアントは、その値に（マッピングを介して）直接対応付けられ、まだ表示されていない全てのローカスノードを表示する（またはそれらが既に表示され、実施形態で可能であれば、それらをローカスノードとしてハイライトする）。そして、それらの文脈やサブ構造を、既に表示されているノードが到達するところまで表示する。ファセット値が非選択されている場合、クライアントは、その値に（マッピングを介して）直接対応付けられ、それに対してエンティティがまだ表示されている他のファセット値に（エンティティ記述子を介して）該当しない全てのローカスノードを隠す。前者のみが満足される場合は、単にノードのハイライトを外す。いずれの場合も、それらの文脈やサブ構造を、ノードのエンティティがまだ表示されているファセット値に（エンティティ記述子を介して）該当するところまで隠す。前者のプロセスである、ファセット値の選択０２１２００を図２２７に示す。後者のファセット値の非選択０２４２００を図２２８に示す。
プロジェクトヒエラルキにおけるバージョニングと衝突解消をサポートする方法
別々のプロジェクト画面のサポート
プロジェクトチェックイン
【0517】
[0754]ここのユーザにプロジェクトにおける自身の役割の何れかをチェックすることを依頼することは、文脈の他の形態をサポートし、彼らの意図について洞察したシステムを提供し、実施形態が、個々のユーザに対してだけでなく、特定のプロジェクトの特定の役割に対する、個々のユーザに提供されるオプションのカスタマイズ（恐らく文脈メニューオプションを介して）と推奨のカスタマイズ（「推奨」と同様に）の両方を可能にする。
【0518】
[0755]実施形態は、公に提供される活動についてのどのようなユーザ文脈メニューオプションをも承認するものであってもよい。特定のプロジェクトと対応関係にあるが、その役割にはチェックインしていないユーザにも「役割へのチェックイン」オプションが提示されるてもよい。ユーザは、自身が対応関係にあるプロジェクトレベルや、それより低いレベルで役割にチェックインできる。実施形態は、恐らくユーザがシステムからログアウトする場合と同様に、ユーザに、グローバルな位置から、プロジェクトの役割についてチェックアウトをすることを可能にしてもよい。実施形態は、ユーザがシステムにログアウトし、またログインするsル時にユーザのチェックイン状況を復活させてもよいし、させなくてもよい。いくつかの実施形態では、ユーザが既に他の役割にチェックインしている場合でも、他のそのようなプロジェクトの役割にチェックインするオプションを与える構成であるが、他の実施形態では、ユーザに、ある役割にチェックインする前に、他の役割からはチェックアウトすることを求める構成であってもよい。前者の場合、実施形態では、暗黙的に、ユーザがある役割についてチェックインする際に、他の役割に対してチェックアウト状態であることを確認する必要がある。いくつかの実施形態ではユーザに複数の役割についてチェックインすることを許すが、その場合彼らは全ての関係する役割の文脈メニューオプションを提示されるが、特定の活動は、１つ以上の役割のもと許可できるものの場合もある。実施形態では、段落０５８１にて記載のように、詳細化コネクションが「弱い」リンクを横断することを含む場合に、ユーザが、それらが直接関与するものの詳細化子孫であるプロジェクトを確認することを可能にする。
【0519】
[0756]また、チェックインは、時間トラッキング情報であるため、コストトラッキングの面でも有用である。個人が様々な解決法（またはより一般的にはプロジェクト）に対して費やした時間を知ることで、彼らの時間を、彼らが参加した様々なプロジェクト間で割り当てることができる。
【0520】
[0757]図２２９は、アクティブユーザのユーザ画面を示している。該ユーザはどのプロジェクトにもチェックインしていない。ユーザはローカスプロジェクトを管理しているので、彼は、図２３０に示すように、管理人として、文脈メニューオプションを見て、その子プロジェクトにチェックインできる。このオプションを選択すると、図２３１に示すように、ユーザがその役割にチェックインする。画面のトップのプルダウンメニューにユーザの名前があるだけでなく、彼らの現在の役割とプロジェクトも見ることができる。ここで、このメニューのオプションには「チェックアウト」も含まれるようになる。チェックインした時、自分がナビゲーションで移動したどの画面上にもユーザは、プロジェクトにおける自分の役割に関した文脈メニューオプションと推奨を見るだろう。「チェックアウトを選択後、ユーザは図２２９の状態に戻る。
【0521】
[0758]この動作は、サーバに、各ユーザについて現プロジェクトと現役割を保存し、何れかのプロジェクトにユーザがチェックインしない場合は空とすることで、サポートできる。ローカルDAGは、各プロジェクトエンティティについて、ユーザが該プロジェクトエンティティのための各役割において権限を有するものであるか（例えば、アクティブユーザと当該プロジェクトまたはその適切な祖先プロジェクト間に直接的な参加対応関係があるか否か）について含めるように構成されていてもよい。これにより、ユーザは、ヒエラルキのどこにチェックインオプションを示すか判断することができる。実施形態では、もしチェックインオプションが何れかのノードについて利用可能である場合、全ての子孫プロジェクトノードについて利用可能である。新たなノードの作成時に、クライアントは、これのようなポリシーを維持する必要があり、恐らく、さらに、アクティブユーザは、何れかの新たなノードの管理者であると仮定するか、もしくはもし新たなノードが祖先を有していない場合は、アクティブユーザが管理者であり、サーバのポリシーに従うと仮定する。いくつかの実施形態では、サーバがどのユーザのチェックイン状態をも把握することを必要としなくてもよい。これら実施形態では、利用可能なメニューオプションをローカルに維持し、ユーザのチェックイン活動に基づいて推奨や時間トラッキングサービスをリクエストする。
【0522】
選択的知識の共有モデレーション
[0759]
いくつかの実施形態では、クラウドで提供される貢献は、承認前は貢献者とプロジェクト管理者だけに対して可視であり、その後、公開されたり、団体内で可視になったりしてもよい。変更が提出された時、承認を要するとマークされている。そのようなシステムは、少なくとも、承認を受けた変更や、承認を必要としない変更を反映したDAGの「グローバル」な画面、モデレータの承認待ちの変更を反映したDAGの、各ユーザに対するユーザ画面、および承認を必要とする全ての最新情報を何らかの形態で提示する「管理者」画面をサポートする構成であってもよい。ユーザは、承認された変更を反映したコンテンツと、提出されているか、または承認されているかに関わらず、該ユーザによるコンテンツを閲覧することができる。全てのユーザの変更が直ぐに承認のため提出されるという形でもよい。変更DAGのログを介して、どのユーザ画面に関する変更も承認待ちもプロジェクト管理者が見ることができる。プロジェクト管理者には、ユーザ画面を仮定する設備を供給し、グローバルな変更と当該ユーザが承認のために提出したものの両方を反映するコンテンツを閲覧できるようにしてもよい。データベース記録（変更記録と現記録の両方）は、承認済みか否かについてマークされてなければならず、少なくとも未承認の記録は、その変更を行ったユーザのｉｄを含み、可視性を制御できるようにする。ここでの意図は、記録が承認されれば、それは「グローバル」になるが、この指定は、実施形態がサポートし、団体が利用するアクセスモデルにより多くの意味合いを持つが、変更をしたユーザと、それを承認した者以外の人々に可視にしてもよい。
【0523】
[0760]いくつかの実施形態では、グローバルなDAGでは他のプロジェクトより低いプロジェクトの管理ショアのアクションが、より高いレベルのプロジェクトの管理者による承認を必要とするように構成されていてもよい。よて、承認のシーケンスが必要になるケースもある。
【0524】
[0761]管理者が、変更を閲覧する際、「承認」と「拒絶」のいずれかを選択できなければならなず、もし承認が承認レベルを選択できるのであれば（単純なケースでは、公開か団体内に限定か）。
【0525】
[0762]モデレーションに資するため、プロジェクトの管理者として活動しているユーザ（段落０７５４では、チェックイン）は、承認が必要な新たなプロジェクトなどの活動が必要なエンティティを容易に識別できる必要がある。
【0526】
[0763]どのユーザも、モデレーションが必要な公開エンティティにフラッグを立てることができなければならない。そして、一実施形態では、１つ以上のそのようなレポートの後、そして可能であれば、フラッグを立てたユーザの評判、最新の変更日時、およびプロジェクトのアクティビティレベルなどを含む他のファクタにも基づいて、最新の変更を当該エンティティにロールバックし、再検討を求めてもよい。
【0527】
プロジェクトアクセス設定[0764]
簡略化のため、ここでは、「パブリック」と「プライベート」のアクセスレベルを仮定するが、もちろんより細かい設定にすることも可能である。設定は、プロジェクトの役割（段落０８２２）により指定されてもよく、プロジェクトに対応付けされていないユーザのものも含む。団体やユーザレベルでの設定により、トップレベルのプロジェクトのデフォルトの可視性を決定してもよい。もしプロジェクトがプライベートなものなら、全てのより低いレベルのプロジェクトをプライベートと仮定してもよい。よって、プロジェクトの全ての親がパブリックでない限り、実施形態は、それをプライベートとし得る。もしプロジェクトの全ての親がパブリックの場合は、実施形態は、例えば関与する操作（例えば、解決法および問題の詳細化、解消、コンポーネント化、編集など）や他のファクタに基づいて、パブリック、プライベート、またはモデレーションをデフォルトしてもよい。
【0528】
他の選択的知識の共有[0765]
段落０７５４に記載のように、実施形態は、プロジェクトチェックインを利用し、ユーザが所定のプロジェクトの役割を担っている時のみその役割に関するアクセス権を有する構成であってもよい。
【0529】
[0766]段落０４３３に記載のように、プロジェクトの構造は、どの継承されたプロジェクト（または他のエンティティ）情報がユーザのリクエストに応じて含まれるかを制御するのに利用されてもよい。
【0530】
ヒエラルキバージョン制御交互ブランチにおける独立的変化の記録
[0767]
もしシステムの独立的部分が変化した場合、これらの変化は、DAGに別個のブランチとして記録される。利点は、どの独立的変化も、恐らく無関係の変化を妨害することなく、アンドゥできることである。そのよな「妨害」は、衝突の形態を取り、解消されなければならず、関与するユーザに負担を掛ける。どの変化が独立的であるか完全には分からないので、このアプローチの成功は、どれくらいこれを洞察できるかにかかっている。
【0531】
[0768]多くの目的については、異なるプロジェクト設定を独立的と考えることができる。
【0532】
[0769]テキストファイルはより難しい。修正された行を見つける標準版管理のように「diff」ファイル比較を使うことができる。「diff」は、変更された行を、その類似性により関連していると仮定された「ハンク（塊、hunks)」にグループ分けもするが、これは主観的なプロセスである。よって、行への全ての挿入、削除、変更を、独立的な変更として扱うことができ、または、どのよな「ハンク」の定義についても、各「ハンク」を独立的として扱うことができる。
【0533】
[0770]「diff」は一般に行毎で置き換えるレベルで作用するが、同じ技術を字毎で適用し、「diff」ファイルにどの字を置き換えるか認識させることもできる。これは、よりきめ細かい識別を差異や、もっと言えば、独立的変化に対して行うと思える。しかし、別個の変更が単位として行われ、一方をアンドゥして他方をしなかった場合、予想が付かないか有害な結果をもたらし得る例を挙げるのは難しくはない。同時に提出される変更の全て（同じ編集「セッション」の一部）は、１つの変更と考えてもよい。また、２つの、そうでなければ独立的な変化をリンクするのに１つの操作で行うこともあり、これらは１つの変化と考えられる。
【0534】
[0771]もし、提出時ではなく、入力時に変更を収集するなら、ユーザが利用可能な編集オプションを制限し、彼らの行動を記録することで、変化に関するユーザの意図についていくらか洞察することができ、段落０２９６に記載のような曖昧さを回避できる。全ての変更が専用のプラットフォーム上で起こっている場合、これは実現可能であろう。例えば、一実施形態では、選択したテキストの削除以外の削除を許さず、ブロックの除去をアトミックな作業と考えてもよい。これにより、システムは、より高いレベルの操作の一部であったかもしれない低レベルの操作で忙しくなることを回避できる。
【0535】
[0772]もし、後の変化が複数の前の変化を含むときは、これらブランチは合併される。より大きい、後の変化は、前のより小さい変化がロールバックされる前に、ロールバックされなければならない。エンティティの削除は、以前の変化を全て含む、全包含の変化でありうる。よって、DAGは、様々な変化のパスに導く挿入ノード形態を取り、全て削除ノードにて収束するようにしてもよい。
【0536】
[0773]もしエンティティが１つの親から他の親に移動した場合、例えば、解決法が１つの問題から他の問題に移動した場合、そのようなクロス種類関係が多数対一である実施形態では、これは解決法に対する変化として考えることができる。よって、「問題Ｐ１の下で作成された解決法Ｓ」と、それを追って２つのブランチ「解決法Ｓが問題Ｐ２に移動」および「解決法ＳテキストＴ１がテキストＴ２に文字型 範囲…」を含むパスを有するかもしれない。
【0537】
[0774]エンティティの移動が、システムにより記録されるアトミック操作の場合、それをこのように取り扱うことができる。
【0538】
[0775]テキストフィールのある部分から他の部分にコピーされたテキストは、当然挿入と考えられるが、具体的にコピーとして考える場合、オリジナルのテキストが修正された後再度適用された場合にその意図を保存しうる。
【0539】
[0776]もしテキストがテキストフィールドのある部分から他の部分に移動された場合、これもまたアトミック操作として考えられ、そうすることで、もし移動が、オリジナルテキストの修正後に再度適用された場合は、意図を保存する。さらなる利点としては、移動されたテキストをそのように扱うことで、それを別の独立の削除と挿入としてではなく、移動を１つの変化ブランチに置くことができる。
【0540】
[0777]そのよなアトミック操作は、標準のバージョン制御では、「コミット」として考えることができる。従来、バージョン制御では、各変化は、デフォルトで、現ブランチ上の次の可能性のあるコミットに貢献する。ワークを、順番のコミットと並行のブランチに明示的に分割し、そして明示的に合併させる必要がある。
【0541】
[0778]補助プロジェクトデータとしてアップロードされたファイルについては（段落０７０５）、従来のバージョン制御と統合される可能性がある。アップロードされたファイルの修正をサポートする実施形態は、ユーザの提出または他のユーザの変更の認識後、サーバにコミットを登録させる構成であってもよい。どのケースでも、コミットは、ファイルの各アップロード後に生成され、すでにアップロードされているファイルを置きかえることを含む。そのようなコミットのそれぞれは、１つの修正変更に対応する（各別個のファイルは、別個のセクタとして考えられる）。ロールバックにおいて、サーバは、従来のバージョン制御システムに、該コミットをアンドゥして破壊し、前のコミットに再設定するように指示することができる。
【0542】
[0779]ロールバックのアンドゥをサポートする実施形態（段落０８０２参照）は、コミットを破壊しないが、それようの新しいブランチを作成し、そのロールバックブランチを変化記録に記録する。マスタブランチは、前のコミットに設定を戻す。ロールバックをアンドゥすると、マスタブランチは、ロールバックブランチのコンテンツの所まで再設定され、ロールバックブランチは除去されてもよい。
【0543】
履歴および衝突[0780]
固定数のセクタ間で、起こり得る変化を分割する。セクタは、構成オプション選択の場合同様、別個のものであってもよく、または、例えば、フィールド内の、変更、除去、追加、コピー、または移動されたテキスト（段落０７７５および段落０７７６）など、範囲や範囲のペアやセットで示されるものであってもよい。別個のテキスト領域への編集は、共通の親に移動する異なる子なので（追加の構造が必要とされない限り）、お互いに適合する可能性もあるが、または別個の構成オプションを設定する。削除を記録する他の変化同様、同じセクタへの編集は衝突する可能性がある。全ての修正のシーケンシングの標準方法は、各エンティティを１つのセクタとして扱うことに対応する。
【0544】
[0781]システムにおけるあらゆる種類の変化されていない記録に記録されたあらゆる種類のユーザデータへの変化について、変化記録を保持する。これら変化は、セクタのセットに対応付けされており、DAGに配置された変化記録である。様々な実施形態において、変化記録は、一般に、古い記録から落ちたコンテンツのインジケータと、実装された新たなコンテンツのインジケータとを含む。各変化記録は、セクタのセットに影響する。影響を受けたセクタは、例えば、各ビットがセクタを定義する二値で提示することができるが、どのような数の提示することも可能である。変化記録ではなく、履歴記録全体を使用することも可能である。
【0545】
[0782]グローバルなログDAGを形成するため、各変化記録をエンティティとして扱い、同じセクタのいずれかに影響する、先行の記録（親として）を後続の記録（子として）接続する。この関係は、多数対多数であるが、各変化の後、セクタは効果的にパーティションされ、各パーティションについて、独自の従前または後続の変化記録がある。他のDAGの場合同様、グローバルログDAGは、ローカライズされて特定の変化になり、このケースでは、文脈における先行の状態とサブ構造における後継の状態を閲覧することができる。
【0546】
[0783]いくつかの実施形態では、別個のエンティティを、相互に関係していても、別々に取り扱う構成であってもよい。他の実施形態では、段落０７７２に記載のシンプルな構造からさらに改良した構成であってもよい。DAG拡張を記録の拡張（特殊化、一般化、まてゃ解決法などのクロス種類対応付け）への変化として考え、エンティティの生成を、派生したエンティティの生成をロールバックしないでロールバックすることができない構成としてもよい。そして、元々根ノードとして作成されたあるエンティティの変化ログは、その拡張の全て（直接および間接）およびエンティティおよびこれら拡張の何れかに対する修正を含む。これにより、様々な親の間をエンティティが移動するのをどのように扱うかという問題を生ずる。これにより、スタブ「移動」ノードを各ソース親の子として残すことができ、そして、移動された子を最後のターゲットの下にして「移動」ノードのシーケンスとして残す場合もある。
【0547】
[0784]この変化を行ったユーザ、またはプロジェクトによりログをフィルタできるようにする必要がある。いくつかの実施形態では、ログを第２DAG（段落０６０５参照）として担当のユーザやプロジェクトに提示し、含まれるログエントリが担当のユーザの範囲により変化するようにする構成であってもよい。ログを、ユーザやスキルなど他のエンティティに変化を示すのに使用する場合、担当ユーザの範囲の選択するためのユーザDAGへ、または、その変化が含まれるエンティティの範囲を選択するための適切なエンティティDAGへ、第２DAGSとして提示することもできる。
【0548】
[0785]第１エンティティの選択は、どれくらいエンティティが表示されるかに影響を及ぼす可能性がある。削除ノード（例えば、「×」とマークされている）は、常にリーフと設定されていてもよい。作成ノード（例えば「+」とマークされている）は常に、親がない、エンティティの根と設定されていてもよいが、または、論理ツリーにおいて、その親の何れかの生成ノードの子として設定されていてもよい。変化ノード（例えば「〜」とマークされている）は、根ではないノードとして設定されていてもよい。従属的なエンティティを閲覧するだけの場合、ログの根は、その生成ノードであってもよく、同じクロス種類関係下のある独立的ノードから他のものへの移動は、この関係下の直接オブジェクト専用のセクタに対応付けられた内部ノード（例えば「＞→」としてマークされている）として示されてもよい。そのようなノードは、複数の順番になった移動について直列であってもよい。異なるクロス種類関係下のある独立的ノードから他のものへの移動は、関与する両方の関係下の親のセクタに影響すると考えらる。詳細化または他の多数対多数の関係の下の親へまたは親からの移動は、関連する各親エンティティのそれぞれのセクタに影響するとして扱われてもよい。独立的エンティティの下の従属的エンティティを閲覧する場合は、生成ノードは、そのクロス種類関係下の親のセクタに影響する内部ノードとして設定されていてもよい。親ノードは、もし子エンティティが直接的に拡張として生成されている場合、該親ノードの生成ノードであってもよく、またはもし子エンティティが該親に移動された場合は、移動（move-from）ノード（例えば、「→」でマークされている）であってもよい。該親から離れた移動（そのオブジェクトへの変化）は、そのオブジェクトの下で従属的エンティティを閲覧する場合は、リーフ移動（leaf move-to)ノード（例えば、「＞―」とマークされている）として示されてもよい。実施形態では、他のマーキングやアイコンを使用することを選択してもよい。
【0549】
[0786]ロールバック操作は、DAGのどのノードからでも開始することができ、様々な実施形態では、そのノードに根があるサブツリー全体をアンドゥして、リーフから（どのような順番でも）始め、内側に向かって作用する。
【0550】
[0787]変化ヒエラルキそれ自身におけるリンクと同様に、「最新」の変化記録（ヒエラルキのリーフ）と結果である現記録はデータベースの対応関係で接続されている。これは、変化ヒエラルキをユーザがエンティティ出たを修正する際に延長するのに必要であってもよい。また、セクタは、効果的にパーティションされ、各パーティションについて、別個の最新の変化記録がある。エンティティを作成した初期の変化記録は全てのセクタに影響すると仮定される。
【0551】
[0788]単数または複数のユーザが、前の変化のセクタに重複するセクタに対する変更を提案した場合、これら変化は秩序化される。つまり、前の変化は、後続の変化により影響を受けたセクタのセットを除いた、前の変化により影響を受けたセクタのセット間のセットの差異のみについての「変化の記録」と考えられ、後続の変化は、それが影響する全てのセクタの「変化の記録」と考えられる。
【0552】
[0789]上述したように、分岐は単数または複数のユーザが、前の変化により影響を受け、セクタと重複しないセクタに対する変化を提案した時に起こる。この場合、様々な実施形態では、複数の子の変化記録が単一の親変化記録の下で、重複していないセクタに関して、作成される。
【0553】
[0790]また分岐は、個々のユーザ（または異なるセッションからの同じユーザ）が、同じ前の変化に続き、重複するセクタに影響する異なる変更を提案した時にも起こる。これは、２人のユーザ（または２つのセッションの同一のユーザ）のどちらかがページを更新する前にページからチェックアウトした時に起こる。そのような変化は、衝突と考えられる。
【0554】
[0791]また、衝突は、段落０７５９に記載のように、ユーザ変化が可視になる前にモデレータにユーザ変化を承認することを要求するシステムでも起こり得る。そのよなモデレーションでは、変化（修正だけでなく、拡張も含む）が提出された後で、変化に承認要とマークする。どのようなエンティティキー値や画面（グローバルまたは特定のユーザ用）にも現記録は１つだけ存在する。データベース記録に、その未承認の変化が反映された、ユーザの追加キーを与えてもよく、または、そのようなコンテンツを、該ユーザの未承認変化記録を適用することでグローバルコンテンツから、ページロード上に適宜導出することができる。どちらのケースでも、未承認の変化の変化記録は、ユーザによって識別される必要があり、最新のそのような記録は、どのようなユーザ、エンティティおよびセクタ選択についてアクセス可能であってもよい。
【0555】
[0792]合併は、ユーザが、複数の前の変化のセクタに影響する１つの変化を、直接（段落０７７２参照）または前の変化の衝突の解消として主張して、提案した時に起こる。衝突の解消は、それ自身が、解消される変化（同じ衝突の他の解消も含む）により影響を受けた同じセクタの何れかに影響する変化と衝突するものと考えられても、そうでなくてもよい。
【0556】
[0793]根エンティティの生成については、ユーザまたはグローバル変化記録を生成すればよく（承認が必要であるかによる）、全てのセクタを影響が受けたものとしてマークし、これをエンティティを示す新たなユーザまたはグローバル記録に対応付けする。
【0557】
[0794]サーバがクライアントについて既存のエンティティのロードリクエストを満足する場合、サーバは、クライアントにセクタから変化記録までのマッピングを渡すことができる。もしクライアントがエンティティを変化させることを依頼した場合は、その変化リクエストと共に、サーバにそのマッピングを送り返すか、またはその影響を受けたセクタについて、前の変化記録を算出し、これら記録の識別子だけを渡すこともできる。または、サーバは、どのクライアントセッションがどの変化記録から作業しているかトラッキングすることができる。サーバがクライアントから、ある変化をある記録に対して実行するリクエストを受けた場合、影響を受けたセクタについての変化記録を、重複するセクタの前の変更記録との任意の数の対応関係と共に生成し、現記録を更新し、それを新たな変化記録と対応付ける必要があるとしてもよい。
【0558】
[0795]変化記録を受領し、現記録が更新されても（承認済みの記録と未承認の記録の両方について）、前の変化記録から構築する(build off of a prior change)後続のリクエストを受け取るかもしれない。そのようなケースでは、実施形態では、事後衝突を作成し、介在する変更をロールバックして現変更が両方のシーケンスの共通状態を反映するようにする。いくつかのシチュエーションでは、最後の共通状態から、１つ以上の変化を作成することはできないかもしれない。
【0559】
[0796]衝突記録の作成により、グローバル画面の管理者またはユーザ画面のユーザに、素早く衝突を識別子、解消することを可能にする。それは、衝突する変化記録と影響を受けるセクタへの参照を（共通祖先状態についてなど、一時的なフォーマットで）含む。
【0560】
[0797]よって、まず、同じキー値のエンティティ、例えば、衝突セクタおよび別個の変化について、同じ前の変更記録から、もし承認済みの変更がユーザによって入力された場合、または、未承認の変更（承認を必要とする場合）が同じユーザにより入力された場合、いずれも明確な先行を有さず、該エンティティのキー値と該画面については、現記録は１つのみ存在しているかもしれない。よって、いくつかの実施形態では、そのような承認済みの変更を未承認としてマークする一方現としてのマークは外し、管理者が解消すべき衝突を生成する構成であってもよく、または、そのような未承認の変更を未承認としてマークする一方現としてのマークは外し、ユーザが解消すべき衝突を生成する。または、衝突が解消されるまで継承される変更を残すことも可能である。
【0561】
[0798]サーバは、編集が基づく変更記録が、影響を受けるセクタについてまだ現であるかを確認してもよい。承認が必要ない場合、編集が基づくグローバル記録がまだ現であるかを確認すればよい。そうでなければ、フラッグを立てるべき衝突がある。１つのアプローチは、最近の変更を、それを作ったユーザに所属する未初認の変更であると考え、グローバル記録を、編集が基づくグローバル記録が現になるまで、ロールバックすることで、グローバル記録を回復させる。そして、新たな未承認変化記録を作成し、これら変更を反映したユーザについての現記録を作成し、新たな変更記録と前の変更記録および新たな現記録とを対応付けする。他のアプローチは、グローバル記録をそのまま残し、このユーザ画面のための新たな未承認変化記録と未承認現記録記録を作成する。もし承認が必要であれば、サーバは、ユーザが他に最新の変化記録を有していないかと、ユーザ編集のシーケンスが基づくグローバル記録がまだ現であるかの両方を確認する必要がある。もしより最近のユーザ変更記録が見つかった場合は、上記のオプションの何れかをユーザに対して適用し、ユーザに衝突の解消を任せることができる。もしより最近のグローバル記録が見つかった場合は、何かをロールバックするのは適切ではない。ここでも、グローバル現記録をそのまま残し、新たな未初認変化記録と未承認言記録記録を、このユーザ画面について、作成する。変更リクエストの処理プロセスを図２３２に示す。
【0562】
[0799]ログを閲覧すると、管理者には、異なるセクタについて衝突のリストが提示され、解消するものを選択することができる。解消は、更新の何れか１つを選択するか、それらの間のテキストをコピーして貼り付け、そして変更を承認するか全ての変更を拒否することを可能にする。もし実施形態が、他の変更と衝突する変更の衝突や拒否を可能にするなら、新たな解消の変更を、変更のリクエスト００１を用いてリクエストする。
【0563】
[0800] グローバル画面へのユーザ変更リクエストを承認するために、サーバは、影響を受けたセクタについての後の変更記録から構成された後続のグローバル変更を確認する必要がある。もし存在しているなら、未承認の変更記録を作成し、衝突が適切に解消されたと確認が取れた後、これらを後続させる。そして、変更記録を承認済みとマークでき、現グローバル記録を更新して、変更を反映する。現グローバル記録は、この変更記録と対応付けされていなくてはならない。もし、これが該エンティティとユーザ画面について最後に残っている未承認の変更である場合、現ユーザ記録は必要ではなく、よって、削除してもよい。最後に、この承認が衝突を解消するなら、衝突フラッグも除去できる。変更リクエストの承認プロセスを図２３３に示す。ここでは、全ての進行の変更記録が承認されたと仮定する。未承認の進行変更記録を処理するために、プロセスを、早いものから順にそれらについて繰り返す必要がある。変更記録はDAGを形成するため、実施形態は訪問した記録を記録し、それを一度だけ処理するように構成されていてもよい。
【0564】
[0801]変更の拒絶はもう少しシンプルである。未承認の変更記録を削除し、該エンティティにういて、ユーザの現記録でそれが規定する変更をアンドゥする。ユーザ現記録は、前の変更記録と対応付けされる必要がある。残りのステップは、図２３３のものと同様である。変更リクエストの拒絶プロセスを図２３４に示す。ここでは、全ての進行変更記録が承認されたと仮定する。未承認の進行変更記録を処理するために、プロセスを、後のものから順にそれらについて繰り返す必要がある。変更記録はDAGを形成するため、実施形態は訪問した記録を記録し、それを一度だけ処理するように構成されていてもよい。
【0565】
[0802]また、ユーザは、ロゴを閲覧し、ロールバックする変更記録を選択してもよい。管理者は、承認済みの変更または、ユーザの未処理の変更を、ロールバックするために選択する。一方一般のユーザがロールバックするのに選択するのは、自身の未承認の変更のみである。まだロールバックされていない変更記録は、選択されロールバックされてもよい。交互のパスに跨る変更記録に規定された変更のアンドゥの操作は、可換的でなければならず、個々のパスへの変更は、お互いから独立したものであるので、そのようなアンドゥ操作は可能であるはずである。ユーザは、例えば、削除済みの記録を復活させ、前の状態のオフに基づいて現変子をにより更新できるようにしてもよい。これは、変更記録をロールバックとマーキングし、その表示がこれを示すようにし、ロールバック済みであるものとされることを含む。また、現記録で所定の変更をアンドゥし、現記録をロールバックされたものの前の変更記録の何れかと対応付けることを含む。ここでも、ユーザの現記録を、それがグローバル記録からもう判別できないときは、削除する。１つの変更記録をロールバックするプロセスを図２３５に示す。ここでは、全ての後続の変更記録は既にロールバックされ、先行の変更記録は、まだロールバックされていないと仮定する。まだロールバックされていない後続の変更記録を処理するため、プロセスを、後のものから順にそれらについて繰り返えす必要がある。変更記録はDAGを形成するため、実施形態は訪問した記録を記録し、それを一度だけ処理するように構成されていてもよい。
【0566】
[0803]もし変更の承認と拒絶が他の変更と共にログに現れたら、実施形態はそれらをロールバックすることを、明示的または後の衝突する承認のため、サポートしてもよい。
【0567】
[0804]好ましい実施形態は、ロールバックは永久的なものでなくてもよいとする（そうでなければ、不正や間違いのロールバックは非常にダメージがあるものになる）。ロールバックされた変更は、ログに灰色で表示されてもよい。よって、ロールバックそれ自身もアンドゥされることができる。ロールバックのアンドゥは、ロールバックがなされなかったかのようにおこなわれる（ロールバックのアンドゥをロールバックする必要はない）。
【0568】
[0805]ロールバックは、グローバルまたは個人の画面の管理者、または個人の画面のみの個々のユーザにより行われることができる。現ユーザ記録は、もしそれがまだ存在していないなら生成される必要があるとしてもよく、ロールバックは、ユーザに対して行われる。変更記録は、まだロールバックされていないとマークされ、変更が再生されると現記録からアクセス可能である必要がある。ロールバックのプロセスを図２３６に示す。ここでは、全ての前の変化記録はロールバックされていないと仮定する。ロールバックされた前の変更記録を処理するため、プロセスを、先のものから順にそれらについて繰り返えす必要がある。変更記録はDAGを形成するため、実施形態は訪問した記録を記録し、それを一度だけ処理するように構成されていてもよい。
【0569】
他の問題DAGの変更（mutating)
[0806]
一回目で構造が完璧に生成されるのはまれであるので、多くの実施形態では、DAGの構造を変更（mutate)する操作をサポートする構成であってもよい。これらの操作は、サブ構造や文脈において行われてもよいが、いくつかの実施形態では、サブ構造に限定する構成であってもよい。
【0570】
編集[0807]
編集は、構造をインプレースに残すので、DAGの変更(mutation）の最も簡略な形態である。ここのノードがインプレースの反復時に修正されるように、同じことを編集時に起こすが、暗黙的に新たなノードを作成するのではなく、クライアントとサーバは、あるノードにおける情報を本当に修正する。
【0571】
リンク解消[0808]
ノードのリンク解消は、それを論理ツリー上の親から離し、サブ構造や文脈を形成することを含む。それは他のリンクとまだ接続されていてもよい。しかし、そうでなければ、論理ツリーの他の部分と接続されていないノードとその全ての子孫を、破壊してもよい。これは、様々な実施形態では、これらは到達できないものになるからである。これは、ツリーを下り、親が１つだけのノードを除くことで実施できる。複数の親を有するノードに到達したら、そこに到達したリンクを外し、下るのを終える。
【0572】
[0809]クライアントは、この操作をローカルDAGにて実行してもよい。サーバは、グローバルDAGにてこれを繰り返す必要がある構成であってもよく、グローバルDAGでは到達できるがローカルDATでは到達できず、まだはないされていないノードを見つけるかもしれない。
【0573】
[0810]ローカスノードに対しては、リンク解消はできない。
【0574】
削除[0811]
ここでは、可能性のある操作は２つある。これらは、削除されるノードが、空でない展開されたサブツリーを有しているか、それが空またはクローズどであるかにより区別できる。
【0575】
[0812]もし空またはクローズなら、様々な実施形態では、ノードと（論理ツリー内の）その子孫を単に破壊する構成でもよい。実施形態では、下るにつれ、削除されるノードへの他のノードからのリンクを除く構成であってもよい。この操作は、クライアントとサーバの両方で行うことができ、サーバでは追加リンクも除いてもよい点だけが違う。
【0576】
[0813]ノードの展開フォルダがオープンの場合、実施形態では、ノードを１つだけ破壊し、その親の子リストのそれぞれにで置き換え、ノードはアクセス元の破壊されたノードの子のリストの各要素と共に破壊され、アクセス元の親ノードの子のリストで置き換えられ、ノードは、破壊されたノードの子のリストの要素と共に破壊されるようにすることができる。
【0577】
[0814]追加の操作を行いローカスノードを削除してもよい。これは、上記のようにオープン、クローズ、または空の文脈とサブ構造の様々なケースを処理する。
【0578】
[0815]オープンの展開フォルダへの操作は、どの２種類のエンティティの間にも関係が１つだけあるシチュエーションに対して、最も好適である。そうでなければ、ユーザは、削除したノードにおけるギャップに橋掛けするのに使用したい関係について、クエリをする必要があるだろう。
【0579】
カットおよびペースト[0816]
ノードを選択し、カットし、他の場所にペースとできることは便利である。これもまた、カットされるノードの展開フォルダがオープンであるか、クローズ／空であるかにより複数の操作の形態を取りえる。
【0580】
[0817]もしカットされるノードがクローズの展開フォルダである場合、意図は、サブツリー全体を他の場所に移動することである。カットされるノードからローカスへのパスを捉えて、保存され、（常法のように）カットノードの画像が若干薄くなって、それがカットされたことを示す。もし続いてペースト操作がなければ、（また常法のように）、カットノードは、変化なしに回復される。もしペースト操作があれば、カットノードはリンクを外され（そのノードのみであり、破壊されない）、アクセス元の親が、ペースト先のノードで置き換えられる。
【0581】
[0818]間接的オブジェクトが保存され、段落０３３７や段落０４６０の制約が適用される場合は、上記「既存エンティティのDAG詳細化」のケースと同様、詳細化対応関係が作成され、移動される根ノードがオブジェクトのローカルDAGの子であるとき、プルーフが必要となる。
【0582】
[0819]その展開フルだがオープンであるノードをカットすることは、そのノードを引き抜き（splicing out）（上記オープンノードの削除同様）、そしてペースト地点で子として挿入すると解釈できる。いくつかの実施形態では、もし、ペースト地点の展開フォルダがオープンの場合は、ペーストポイントノードの下であるが、その子の上の１つのノードを引き抜く構成であってもよいが、全体のサブツリーについて同様に引き抜き抜く操作はない。
【0583】
[0820]オープン展開フォルダからのカットの操作も、削除について上述した同じ理由により、どの２種類のエンティティの間にも関係が１つだあるシチュエーションに対して最も好適である。
【0584】
詳細化済みとの差異としての詳細化テキスト[0821]
編集対象または破棄対象になる、詳細化済みエンティティのテキストを特殊化対象エンティティ用のデフォルト初期テキストとして、または詳細化対処エンティティのテキストを一般化対象エンティティのデフォルト初期テキストとして単に使用するのではなく、実施形態では、新たなテキストとのテキスト上の差異を保存することを選択してもよい。そして、もし変更していないテキストの部分をオリジナルのエンティティにて修正する場合、新たなエンティティの差異の仕様を調整し、そのテキストを再演算して、その変更をオリジナルのエンティティに組み込む。例えば、もし特殊化で５字のテキストがある場所に追加される場合は、ストリングには１０字追加し、詳細化済みノードに対する後の更新では３字を除き（第４番目〜第６番目）、差異の仕様は、位置に対して５字のテキストを追加し、７字をストリングに追加し、これら３字は詳細化対象テキストからも削除されたというように修正される。これは、既存のエンティティの特殊化対象または一般化対象エンティティを記録すること、または各詳細化対応関係をそれが適用される方向でマーキングして、修正時に、どの特殊化対象または一般化対象エンティティ（直接または詳細化のシーケンスを介するもの）も適切に調整できるようにする必要がある。
【0585】
プロジェクトのガバナンス[0822]
個人は、様々な役割（例えば、管理者、アドバイザ、協力者、投資家など）の下プロジェクトと関連していてもよい。管理者はプロジェクト活動の調整を担う。アドバイザは、提出されたアイデアについてフィードバックをする。協力者は、プロジェクトの実施（おそらく解決法のみ）を援助する。投資家（資金提供者）はアドバイザとして取り扱われても、されなくともよい。
【0586】
[0823]集中型や分散型の様々なプロジェクトのガバナンスの態様が、この技術を使って可能であり、その効果を比較するのには理想的なフレームワークである。集中型の構造は、全てのコンテンツに調整（moderate）する固定の管理者を有するであろう。より集中度が低い構造では、より一般的な問題や解決法に対応付けられた（またはこれらを作成した）個人にこれらプロジェクトについて決定を下すことを許可するが、プロジェクトヒエラルキの高位がヒエラルキの下位に優先するとする。プロジェクトヒエラルキに対する拡張は、これら拡張される単数または複数のエンティティの担当者により検討されるだろう。また、プロジェクトを拡張するユーザによる任意または選択された活動は、管理者が見過ごすことが適切でないと思った場合は、拡張されたプロジェクトの管理者が検討できる。
【0587】
[0824]または、投票機構を確立してもよい。プロジェクト内の推測される影響に基づいて票を調整する場合もありうる。一部の個人は、必然的に、他の者に比べプロジェクトの詳細により深く関与しているかもしれないが、多くはプロジェクトについて誰を信頼し、敬意を払えるかを知っているだけなので、多くの実施形態では、代理によるガバナンスをサポートする構成であってもよく、そこでは、人々は他の者に権限を委託し、自分たちの代理に投票して、いつ解決法を実施する、どのようにプロジェクト構造の修正における衝突を解決するなどの懸案に答える。そのような権限の委託は、所定のプロジェクトについてなされ、そのプロジェクトのサブ構造を介して継承されてもよいが、サブ構造とその子孫の何らかの要素によって覆される場合もある。様々な実施形態では、代理の任命のチェーン化をサポートする構成であってもよい。
【0588】
[0825]プロジェクトに対する影響は、その個人により作成および／または編集されたプロジェクト構造に関する後続の活動により推測することができ、そのような活動は、それらプロジェクト構造の拡張を含むが、それに限定されない。
【0589】
エンジン、コンポーネント、および論理[0826]
実施形態のあるものは、本明細書において、論理を含むまたは多数のコンポーネント、エンジン、または機構を含むと説明した。エンジンは、ソフトウェアエンジン（例えば、機械読み取り可能媒体に埋め込まれたコードなど）またはハードウェアエンジンを構成してもよい。「ハードウェアエンジン」は、ある操作を実行可能な有体のユニットであり、任意の物理的方法で構成または配列されていてもよい。様々な例示的な実施形態では、１つ以上のコンピュタシステム（例えば、スタンドアロンコンピュータシステム、クライアントコンピュータシステム、またはサーバコンピュータシステムなど）、またはコンピュータシステムのハードウェアエンジン（例えば、１つのプロセッサまたはプロセッサ群）をソフトウェア（例えば、アプリケーションまたはアプリケーションの一部）により、本明細書にて記載した任意の操作を実行するように機能するハードウェアエンジンとして、構成してもよい。
【0590】
[0827]いくつかの実施形態では、ハードウェアエンジンは、機械的、電子的、またはその如何なる好適な組み合わせにて実装されてもよい。例えば、ハードウェアエンジンは、ある動作を実行するように永久的に構成された専用の回路やロジックを備えていてもよい。例えば、ハードウェアエンジンは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）などの特殊用途プロセッサであってもよい。また、ハードウェアエンジンは、ある動作を実行するように、ソフトウェアにより一時的に構成されたプログラマブルロジックまたは回路を備えていてもよい。例えば、ハードウェアエンジンは、汎用プロセッサや他のプログラマブルプロセッサにて実行されるソフトウェアを備えていてもよい。そのようなソフトウェアにて構成されると、ハードウェアエンジンは、構成された機能を実行するように特別にカスタマイズされた特別な機器（または機器の特別な部品）となり、汎用プロセッサではなくなる。ハードウェアエンジンを専用の永続的な構成の回路によるか、一時的に構成された回路（例えば、ソフトウェアにて構成されたもの）により、機械的に実装するという決定は、コストや時間を考慮して検討されてもよい。
【0591】
[0828]よって、「ハードウェアエンジン」という表現は、ある様式で作動したり、本明細書で記載したある動作を実行するように物理的に構築されたり、永続的に構成されたエンティティ（例えば、ハードワイヤードのもの）や、一時的に構成された（例えば、プログラムされた）エンティティである有体エンティティを包含すると解釈されるものである。本明細書では、「ハードウェア実装エンジン」とは、ハードウェアエンジンを指す。複数のハードウェアエンジンが一時的に構成された（例えば、プログラムされた）実施形態を考慮すると、各ハードウェアエンジンは、一度に構成されたり、具現化されなくてもよい。例えば、ハードウェアエンジンが、ソフトウェアにて特殊目的プロセッサに構成される汎用プロセッサを備えている場合、該汎用プロセッサは、それぞれ異なる特殊目的プロセッサ（例えば、異なるハードウェアエンジンを備えるもの）として、異なる時間に構成されてもよい。よって、ソフトウェアは、特定の単数または複数のプロセッサを構成し、例えば、一度に１つの特定のハードウェアエンジンを構成し、別々の時間に異なるハードウェアエンジンを構成する。
【0592】
[0829]ハードウェアエンジンをは、他のハードウェアエンジンから情報を受け取ったり、他のハードウェアエンジンに情報を渡したりできる。よって、記載のハードウェアエンジンは、通信可能なように接続されたものと考えてもよい。複数のハードウェアエンジンが同時に存在する場合、通信は、２つ以上のハードウェアエンジン間の信号送信（例えば、適切な回路やバスを介したもの）で達成されてもよい。複数のハードウェアエンジンが別々の時間に構成または具現化されている実施形態では、そのようなハードウェアエンジン間の通信は、例えば、ハードウェアエンジンがアクセス可能なメモリ構造の保存と読み出しを介して実行されてもよい。例えば、１つのハードウェアエンジンが動作を実行し、その動作の出力を、該ハードウェアエンジンが通信可能に接続された記憶装置に保存する構成であってもよい。別のハードウェアエンジンが、後に、記憶装置にアクセスして、保存された出力を処理してもよい。また、ハードウェアエンジンは、入力または出力装置と通信する構成であってもよく、リソース（例えば、情報のコレクション）に基づて動作してもよい。
【0593】
[0830]本明細書に記載の例示的な方法の様々な動作は、少なくとも部分的に、１つ以上のプロセッサにて実行されてもよく、該プロセッサは、該関連する動作を実行するように一時的に構成（例えば、ソフトウェアにて）、または永久的に構成されたものである。一時的に構成されたものであれ、永久的に構成されたものであれ、そのようなプロセッサは、本明細書で記載した１つ以上の動作や機能を実行するように動作するプロセッサ実装エンジンを構成するものであってもよい。ここで使用するように、「プロセッサ実装エンジン」は、１つ以上のプロセッサを用いて実装されるハードウェアエンジンを指す。
【0594】
[0831]同様に、本明細書に記載の方法は、ハードウェアの一例である特定の単数または複数のプロセッサを備えて、少なくとも部分的にプロセッサが実装されたものであってもよい。例えば、方法の動作の少なくともいくつかは、１つ以上のプロセッサまたはプロセッサ実装エンジンにて実行されてもよい。また、該１つ以上のプロセッサも、「クラウドコンピューティング」環境において、または、「サービスとしてのソフトウェア（software as a service SaaS）として該関連する動作の実行をサポートするように動作するものであってもよい。例えば、ネットワーク（例えば、インターネット）や１つ以上の適切なインタフェース（例えば、アプリケーションプログラムインタフェース（ＡＰＩ））を介してアクセス可能な少なくともいくつかの動作が、一群のコンピュータ（例えば、プロセッサを備えた機器の例）にて実行されてもよい。
【0595】
[0832]ある動作の実行を、複数のプロセッサ間で分配し、１つの機器に留まるだけでなく、複数の機器に分かって展開してもよい。いくつかの例示的な実施形態では、プロセッサまたはプロセッサ実装エンジンは、１か所の地理的位置（例えば、住宅環境、オフィス環境、またはサーバファームなど）に配置されていてもよい。他の例示的な実施形態では、プロセッサまたはプロセッサ実装エンジンは、多数の地理的位置に分散して配置されていてもよい。
【0596】
言語[0833]
本明細書において、複数インスタンスは、単数インスタンスとして記載された部品、動作または構造を複数で実しうる。１つ以上の方法の個々の動作は、別々の動作として図示され、記載されているが、１つ以上の個々の動作は、同時に実行されてもよく、動作は図示された順番で実行される必要はない。例示的な構成で別々のコンポーネントとして提示された構造や機能は、合体した構造や機能として実施されてもよい。どうように、１つのコンポーネントとして提示された構造や機能は、別々のコンポーネントとして実施されてもよい。これらおよび他の変形、修正、追加、および改良は、本明細書の主題の範囲の範疇である。
【0597】
[0834]主題の概要を具体的な例示的実施形態を参照しながら説明したが、様々な修正や変更も、本開示の実施形態のより広い範囲から逸脱することなく、これら実施形態に対して行うことができる。そのような主題の実施形態を、本明細書では、個々にまたはまとめて、「発明」という用語で称すが、これは単に簡略化のためであり、本願の範囲を、もし実際には１つ以上の開示や概念がが開示されている場合、何れか１つの開示や概念に自主的に限定する意図はない。
【0598】
[0835]本明細書に記載の実施形態は、開示された教示を当業者が実施できるように十分に詳細に記載されている。他の実施形態も使用でき、それらから導出されてもよく、構造や論理的代替や変更も、本開示の範囲を逸脱することなく可能である。よって、詳細な説明は、限定的な意味で解釈されるものではなく、様々な実施形態の範囲は、該請求項が享受する均等物の最大範囲と、貼付の請求項にのみ定義されるものである。
【0599】
[0836]「エンジン」、「システム」、「データストア」および／または「データベース」は、ソフトウェア、ハードウェア、ファームウェア、および／または回路を備えていてもよい。一例では、プロセッサが実行可能な命令を１つ以上のソフトウェアプログラムは、本明細書に記載のエンジン、データストア、データベース、またはシステムの１つ以上の機能を実行してもよい。他の例では、回路は、同じまたは同様の機能を実行してもよい。代替の実施形態では、より多い、より少ない、または機能的に均等のエンジン、システム、データストア、またはデータベースを備えていてもよく、その場合も本実施形態の範囲内である。例えば、様々なシステム、エンジン、データストア、および／またはデータベースの機能は、組み合わされても、別々に分割されてもよい。
【0600】
[0837]本明細書に記載のデータストアは、どのような好適な構造のものでもよく（例えば、アクティブデータベース、関係的データベース、自己参照データベース、表、マトリックス、アレイ、フラットファイル、ドキュメント指向型記録システム、非関係的Ｎｏ−ＳＱＬシステム等）、クラウドベースや他の形態でもよい。
【0601】
[0838]本明細書では、用語「または」は、包括的または排除的意味で解釈されうる。また、複数のインスタンスを、本明細書では単数のインスタンスとして記載されたリソース、動作、または構造について設けてもよい。また、様々なリソース、動作、エンジン、エンジン、およびデータストア間の境界は、若干任意であり、特定の動作を具体的で例示的な構成の文脈にて示している。機能の他の配分も想定され、本開示の様々な実施形態の範囲に該当し得る。一般に例示的な構成で別々のリソースとして提示された構造と機能は、組み合わされた構造または機能として実施してもよい。同様に、１つのリソースとして提示された構造や機能は、別々のリソースとして実施してもよい。これらおよび他の変形、修正、追加、および改良は、貼付の請求項にて示された本開示の実施形態の範囲の範疇である。よって、本明細書と図面は、限定的ではなく、説明的なものとして考慮されるべきものである。
【0602】
[0839]上記セクションにて記載した各プロセス、方法、アルゴリズムは、コンピュータハードウェアを備えた１つ以上のコンピュータシステムまたはコンピュータプロセッサにより実行されるコードモジュールに埋め込まれ、完全または部分的に該コードにより自動化されていてもよい。プロセスとアルゴリズムは、特定用途向け回路に部分的または全体的に実装されていてもよい。
【0603】
[0840]上記に説明した様々な構成やプロセスは、それどれと独立して使用されてもよく、または、様々な形で組み合わされてもよい。可能な組み合わせとサブ組み合わせの全ては、本開示の範囲に含まれることを意図したものである。また、任意の方法ブロックやプロセスブロックは、いくつかの実施においては、省略されてもよい。本明細書に記載の方法やプロセスも、如何なる特定の順番に限定されるものではなく、それらに関連するブロックや状態は、適宜、他の順番で実行可能である。例えば、記載のブロックや状態は、具体的に開示されたものとは違う順番で実行されてもよいし、複数のブロックや状態は、組み合わされて１つのブロックまたは状態とされてもよい。例示的なブロックまたは状態は、直列、並列、または他の形で実行されてもよい。ブロックや状態は、開示された例示的な実施形態に対して追加されても良いし、該実施形態から削除されてもよい。本明細書で記載した例示的なシステムとコンポーネントは、記載とは異なるように構成されてもよい。例えば、開示された例示的実施形態と比べて、構成要素を足したり、削除したり、再配置したりしてもよい。
【0604】
[0841]条件的用語、例えば、特に、「できる」「してもよい」（can, could, might, またはmay）は、特に別途記載がない限り、または使用される文脈内にて解釈されない限り、一般に、ある実施形態が、他の実施形態が含まないある構成、要素、および／またはステップを含むことを伝える意図である。よって、そのような条件的用語は、構成、要素、および／またはステップがどのような形であれ１つ以上の実施形態において必須であることや、１つ以上の実施形態が、これら構成、要素、および／またはステップが含まれているか否かまたは特定の実施形態において実施されるか否かを、ユーザ入力または指示の有無に関わらず、判断するロジックを含む必要があるということを暗示する意図は一般にない。
【0605】
[0842]本明細書にて記載および／または貼付の図面にて図示したプロセスの説明、要素、ブロックは、可能性のあるモジュール、セグメントまたはコードの一部を示し、プロセスの特定のロジック機能やステップを実施する１つ以上の実行可能な命令を含むものとして解釈されるべきである。当業者が理解するように、代替の実施も本明細書で記載した実施形態の範囲に含まれ、そこでは、関連する機能に依存して、要素または機能は、削除されたり、実質同時や逆の順番も含む、図示または記載した順番以外の順番で実行されたりしてもよい。
【0606】
[0843]なお、多くの変形や修正を上記実施形態に行っても良く、その要素は、他の許容できる例であると理解されるものである。全てのそのような変形例や修正例は、本明細書において、本開示の範囲に含まれることを意図する。前記記載は、本発明のある実施形態を詳細に説明した。しかし、前記が文言上どのように詳細であったとしても、本発明は様々な形態で実施可能であることは理解されよう。上述したように、本発明のある構成や態様を説明する際にある用語を使用したとしても、その用語が本明細書において再定義され、その用語が関連する本発明の構成や態様の何らかの具体的な特徴点を含むと限定されることを暗示するものと解釈されるべきではない。よって、本発明の範囲は、貼付の請求項とその全ての均等物により解釈されるべきものである。
【図1】
[この文献は図面を表示できません]
【図2】
[この文献は図面を表示できません]
【図3】
[この文献は図面を表示できません]
【図4】
[この文献は図面を表示できません]
【図5】
[この文献は図面を表示できません]
【図6】
[この文献は図面を表示できません]
【図7】
[この文献は図面を表示できません]
【図8】
[この文献は図面を表示できません]
【図9】
[この文献は図面を表示できません]
【図10】
[この文献は図面を表示できません]
【図11】
[この文献は図面を表示できません]
【図12】
[この文献は図面を表示できません]
【図13】
[この文献は図面を表示できません]
【図14】
[この文献は図面を表示できません]
【図15】
[この文献は図面を表示できません]
【図16】
[この文献は図面を表示できません]
【図17】
[この文献は図面を表示できません]
【図18】
[この文献は図面を表示できません]
【図19】
[この文献は図面を表示できません]
【図20】
[この文献は図面を表示できません]
【図21】
[この文献は図面を表示できません]
【図22】
[この文献は図面を表示できません]
【図23】
[この文献は図面を表示できません]
【図24】
[この文献は図面を表示できません]
【図25】
[この文献は図面を表示できません]
【図26】
[この文献は図面を表示できません]
【図27】
[この文献は図面を表示できません]
【図28】
[この文献は図面を表示できません]
【図29】
[この文献は図面を表示できません]
【図30】
[この文献は図面を表示できません]
【図31】
[この文献は図面を表示できません]
【図32】
[この文献は図面を表示できません]
【図33】
[この文献は図面を表示できません]
【図34】
[この文献は図面を表示できません]
【図35】
[この文献は図面を表示できません]
【図36】
[この文献は図面を表示できません]
【図37】
[この文献は図面を表示できません]
【図38】
[この文献は図面を表示できません]
【図39】
[この文献は図面を表示できません]
【図40】
[この文献は図面を表示できません]
【図41】
[この文献は図面を表示できません]
【図42】
[この文献は図面を表示できません]
【図43】
[この文献は図面を表示できません]
【図44】
[この文献は図面を表示できません]
【図45】
[この文献は図面を表示できません]
【図46】
[この文献は図面を表示できません]
【図47】
[この文献は図面を表示できません]
【図48】
[この文献は図面を表示できません]
【図49】
[この文献は図面を表示できません]
【図50】
[この文献は図面を表示できません]
【図51】
[この文献は図面を表示できません]
【図52】
[この文献は図面を表示できません]
【図53】
[この文献は図面を表示できません]
【図54】
[この文献は図面を表示できません]
【図55】
[この文献は図面を表示できません]
【図56】
[この文献は図面を表示できません]
【図57】
[この文献は図面を表示できません]
【図58】
[この文献は図面を表示できません]
【図59】
[この文献は図面を表示できません]
【図60】
[この文献は図面を表示できません]
【図61】
[この文献は図面を表示できません]
【図62】
[この文献は図面を表示できません]
【図63】
[この文献は図面を表示できません]
【図64】
[この文献は図面を表示できません]
【図65】
[この文献は図面を表示できません]
【図66】
[この文献は図面を表示できません]
【図67】
[この文献は図面を表示できません]
【図68】
[この文献は図面を表示できません]
【図69】
[この文献は図面を表示できません]
【図70】
[この文献は図面を表示できません]
【図71】
[この文献は図面を表示できません]
【図72】
[この文献は図面を表示できません]
【図73】
[この文献は図面を表示できません]
【図74】
[この文献は図面を表示できません]
【図75】
[この文献は図面を表示できません]
【図76】
[この文献は図面を表示できません]
【図77】
[この文献は図面を表示できません]
【図78】
[この文献は図面を表示できません]
【図79】
[この文献は図面を表示できません]
【図80】
[この文献は図面を表示できません]
【図81】
[この文献は図面を表示できません]
【図82】
[この文献は図面を表示できません]
【図83】
[この文献は図面を表示できません]
【図84】
[この文献は図面を表示できません]
【図85】
[この文献は図面を表示できません]
【図86】
[この文献は図面を表示できません]
【図87】
[この文献は図面を表示できません]
【図88】
[この文献は図面を表示できません]
【図89】
[この文献は図面を表示できません]
【図90】
[この文献は図面を表示できません]
【図91】
[この文献は図面を表示できません]
【図92】
[この文献は図面を表示できません]
【図93】
[この文献は図面を表示できません]
【図94】
[この文献は図面を表示できません]
【図95】
[この文献は図面を表示できません]
【図96】
[この文献は図面を表示できません]
【図97】
[この文献は図面を表示できません]
【図98】
[この文献は図面を表示できません]
【図99】
[この文献は図面を表示できません]
【図100】
[この文献は図面を表示できません]
【図101】
[この文献は図面を表示できません]
【図102】
[この文献は図面を表示できません]
【図103】
[この文献は図面を表示できません]
【図104】
[この文献は図面を表示できません]
【図105】
[この文献は図面を表示できません]
【図106】
[この文献は図面を表示できません]
【図107】
[この文献は図面を表示できません]
【図108】
[この文献は図面を表示できません]
【図109】
[この文献は図面を表示できません]
【図110】
[この文献は図面を表示できません]
【図111】
[この文献は図面を表示できません]
【図112】
[この文献は図面を表示できません]
【図113】
[この文献は図面を表示できません]
【図114】
[この文献は図面を表示できません]
【図115】
[この文献は図面を表示できません]
【図116】
[この文献は図面を表示できません]
【図117】
[この文献は図面を表示できません]
【図118】
[この文献は図面を表示できません]
【図119】
[この文献は図面を表示できません]
【図120】
[この文献は図面を表示できません]
【図121】
[この文献は図面を表示できません]
【図122】
[この文献は図面を表示できません]
【図123】
[この文献は図面を表示できません]
【図124】
[この文献は図面を表示できません]
【図125】
[この文献は図面を表示できません]
【図126】
[この文献は図面を表示できません]
【図127】
[この文献は図面を表示できません]
【図128】
[この文献は図面を表示できません]
【図129】
[この文献は図面を表示できません]
【図130】
[この文献は図面を表示できません]
【図131】
[この文献は図面を表示できません]
【図132】
[この文献は図面を表示できません]
【図133】
[この文献は図面を表示できません]
【図134】
[この文献は図面を表示できません]
【図135】
[この文献は図面を表示できません]
【図136】
[この文献は図面を表示できません]
【図137】
[この文献は図面を表示できません]
【図138】
[この文献は図面を表示できません]
【図139】
[この文献は図面を表示できません]
【図140】
[この文献は図面を表示できません]
【図141】
[この文献は図面を表示できません]
【図142】
[この文献は図面を表示できません]
【図143】
[この文献は図面を表示できません]
【図144】
[この文献は図面を表示できません]
【図145】
[この文献は図面を表示できません]
【図146】
[この文献は図面を表示できません]
【図147】
[この文献は図面を表示できません]
【図148】
[この文献は図面を表示できません]
【図149】
[この文献は図面を表示できません]
【図150】
[この文献は図面を表示できません]
【図151】
[この文献は図面を表示できません]
【図152】
[この文献は図面を表示できません]
【図153】
[この文献は図面を表示できません]
【図154】
[この文献は図面を表示できません]
【図155】
[この文献は図面を表示できません]
【図156】
[この文献は図面を表示できません]
【図157】
[この文献は図面を表示できません]
【図158】
[この文献は図面を表示できません]
【図159】
[この文献は図面を表示できません]
【図160】
[この文献は図面を表示できません]
【図161】
[この文献は図面を表示できません]
【図162】
[この文献は図面を表示できません]
【図163】
[この文献は図面を表示できません]
【図164】
[この文献は図面を表示できません]
【図165】
[この文献は図面を表示できません]
【図166】
[この文献は図面を表示できません]
【図167】
[この文献は図面を表示できません]
【図168】
[この文献は図面を表示できません]
【図169】
[この文献は図面を表示できません]
【図170】
[この文献は図面を表示できません]
【図171】
[この文献は図面を表示できません]
【図172】
[この文献は図面を表示できません]
【図173】
[この文献は図面を表示できません]
【図174】
[この文献は図面を表示できません]
【図175】
[この文献は図面を表示できません]
【図176】
[この文献は図面を表示できません]
【図177】
[この文献は図面を表示できません]
【図178】
[この文献は図面を表示できません]
【図179】
[この文献は図面を表示できません]
【図180】
[この文献は図面を表示できません]
【図181】
[この文献は図面を表示できません]
【図182】
[この文献は図面を表示できません]
【図183】
[この文献は図面を表示できません]
【図184】
[この文献は図面を表示できません]
【図185】
[この文献は図面を表示できません]
【図186】
[この文献は図面を表示できません]
【図187】
[この文献は図面を表示できません]
【図188】
[この文献は図面を表示できません]
【図189】
[この文献は図面を表示できません]
【図190】
[この文献は図面を表示できません]
【図191】
[この文献は図面を表示できません]
【図192】
[この文献は図面を表示できません]
【図193】
[この文献は図面を表示できません]
【図194】
[この文献は図面を表示できません]
【図195】
[この文献は図面を表示できません]
【図196】
[この文献は図面を表示できません]
【図197】
[この文献は図面を表示できません]
【図198】
[この文献は図面を表示できません]
【図199】
[この文献は図面を表示できません]
【図200】
[この文献は図面を表示できません]
【図201】
[この文献は図面を表示できません]
【図202】
[この文献は図面を表示できません]
【図203】
[この文献は図面を表示できません]
【図204】
[この文献は図面を表示できません]
【図205】
[この文献は図面を表示できません]
【図206】
[この文献は図面を表示できません]
【図207】
[この文献は図面を表示できません]
【図208】
[この文献は図面を表示できません]
【図209】
[この文献は図面を表示できません]
【図210】
[この文献は図面を表示できません]
【図211】
[この文献は図面を表示できません]
【図212】
[この文献は図面を表示できません]
【図213】
[この文献は図面を表示できません]
【図214】
[この文献は図面を表示できません]
【図215】
[この文献は図面を表示できません]
【図216】
[この文献は図面を表示できません]
【図217】
[この文献は図面を表示できません]
【図218】
[この文献は図面を表示できません]
【図219】
[この文献は図面を表示できません]
【図220】
[この文献は図面を表示できません]
【図221】
[この文献は図面を表示できません]
【図222】
[この文献は図面を表示できません]
【図223】
[この文献は図面を表示できません]
【図224】
[この文献は図面を表示できません]
【図225】
[この文献は図面を表示できません]
【図226】
[この文献は図面を表示できません]
【図227】
[この文献は図面を表示できません]
【図228】
[この文献は図面を表示できません]
【図229】
[この文献は図面を表示できません]
【図230】
[この文献は図面を表示できません]
【図231】
[この文献は図面を表示できません]
【図232】
[この文献は図面を表示できません]
【図233】
[この文献は図面を表示できません]
【図234】
[この文献は図面を表示できません]
【図235】
[この文献は図面を表示できません]
【図236】
[この文献は図面を表示できません]
【国際調査報告】
[この文献は図面を表示できません]