CN109121436B - 增广、探索、和维护项目分层结构的方法 - Google Patents

增广、探索、和维护项目分层结构的方法 Download PDF

Info

Publication number
CN109121436B
CN109121436B CN201680080066.3A CN201680080066A CN109121436B CN 109121436 B CN109121436 B CN 109121436B CN 201680080066 A CN201680080066 A CN 201680080066A CN 109121436 B CN109121436 B CN 109121436B
Authority
CN
China
Prior art keywords
entity
inheritable
entities
item
dag
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201680080066.3A
Other languages
English (en)
Other versions
CN109121436A (zh
Inventor
S·甘兹
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Teamifier Inc
Original Assignee
Teamifier Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teamifier Inc filed Critical Teamifier Inc
Publication of CN109121436A publication Critical patent/CN109121436A/zh
Application granted granted Critical
Publication of CN109121436B publication Critical patent/CN109121436B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9027—Trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2246—Trees, e.g. B+trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
    • G06F3/04845—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range for image manipulation, e.g. dragging, rotation, expansion or change of colour

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • User Interface Of Digital Computer (AREA)
  • Stored Programmes (AREA)
  • Auxiliary Devices For Music (AREA)
  • Human Computer Interaction (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

提供了一种以图形方式将有向无环图的一部分表示为分层树结构的方法，以便促进通过网络的用户协作，该方法包括通过通信网络获得多个用户共享的协作项目，该项目用有向无环图结构表示，包括多个实体和多个关联，多个实体包括一个或多个本地实体，每个本地实体与一个本地节点相关联，由该节点出发，每个本地实体的有向无环图的祖先实体被遍历为倒置树结构，倒置树中的每个子节点指示一个对应实体，作为有向无环图中的双亲与其在倒置树中的双亲实体相联系；并展开以倒置树的一个叶节点为根的子树，以响应用户的输入。

Description

增广、探索、和维护项目分层结构的方法
背景
本公开涉及代表项目信息的分层结构的布局和增广，包括项目本身和相关信息；通过分层结构进行探索；并在协作环境中修改时维护这些结构。
概要
在一些实施例中，本公开提供了增广一个DAG(可能是树)时的一种方法，该DAG呈现至少两种实体，并且第一种类(独立)的一个实体可以直接为与第二种类(依赖)的一个实体相关联，用于扩展这种关系，使得第二类的每一个实体与第一类的一个实体间接关联。
在一些实施例中，本公开提供了一种方法，当导航一个DAG时使得一个或多个本地节点是中心的，用于提供对以下信息的访问，这种信息既不严格地位于本地节点的子结构中，也不严格地在其上下文中，而是通过与上下文的关联被继承到子结构中。此外，这种继承结构自上而下的增广意味着该结构对一个或多个继承该结构的本地节点细化，将以我们更精确地定义的方式进行。这可能对通过与子结构的关联将信息继承到上下文中也是合适的。同样，这种继承结构的自下而上的增广意味着该结构相对于继承该结构的一个或多个本地节点细化。或者，在上下文中一个节点的自上而下的增广可能意味着前面的上下文相对于有关的本地节点的泛化。
这里描述的一些实施例首先表示DAG作为一个或一对逻辑树(一个用于子结构，另一个倒置的用于上下文)的导航状态，如最初在“用于探索分层结构的方法及其上下文的表示”中所做的，或使用维恩图或任何其他方式，然后用从上下文继承的附加信息来增广子结构(反之亦然)。在增广这种继承结构时，本地子结构被构建，根据需要对继承结构细化，最初是关于本地节点，并且相对于最近添加的本地子结构递增地继续。该过程类似于用从子结构继承的信息来增广上下文。
本公开包括呈现项目信息及其增广DAG的其他相关方面.
此外，本公开提供了一种在导航DAG时用于约束subDAG及其上下文，使得它们可以可视化并且集中于树的方法，使得任何实体在任何时刻在可视化中只用单个节点表示。在一些实施例中，我们描述三种操作：树的初始化，节点展开和节点折叠。树初始化和树构建的初步过程与策略0656.1相关；策略0656.2将节点构建整合到初始化过程中。后两种操作支持对层次结构的探索，并可能适用于子结构节点或上下文节点。从本地节点或任何可见的子结构节点，例如，我们可能会展开或折叠以分别查看或隐藏更深的子结构，并且可能会从本地节点或任何可见的上下文节点分别展开或折叠以查看或隐藏更深刻的上下文。本公开还提供了一种通过选择和取消筛选值，并揭示各个本地节点的共同祖先和后代来调节本地节点组的方法。
本公开首先在简化的阐述中，把DAG的导航状态表示为一对逻辑树(子结构和上下文)，然后在基底树中表示这些。然后，在更复杂的阐述中，它首先将DAG森林的导航状态表示为一对逻辑树(子结构和上下文，子结构可能与上下文重叠，上下文可能与子结构重叠)，然后在底层树中表示这些。
一些实施方案保持子结构或上下文或两者均完全展开的边界状态，使得应用于子结构节点(连同本地节点)的单个用户动作，可以展开或折叠该节点的子结构，并且单个用户动作被应用于上下文节点(连同本地节点)可以展开或折叠该节点的上下文。
一个关键的见解是，在展开一个节点的子结构或上下文时，必须分别自动折叠任何有潜在冲突的子结构或上下文。另一个关键的见解是，子结构和上下文可以被表示为二者列表的嵌套序列，以分别促进共同后代和祖先的可视化，如将在本文中描述的。
对实体的双亲和子代的引用参考作为其基础的DAG。特别提到的子结构或上下文对双亲和子代的引用通常参考相应的逻辑树。对父节点和子节点的引用否则参考一颗抽象的底层树，并且必须改写以便用于HTML或任何其他特定的底层树。
另外，一些实施方案维护系统历史记录的方法是通过将变更记录安排在DAG中，而不是通过显式的分支和合并指令，而是通过基于每个更改影响的内容进行分支和合并，以使得不同的内容在单独的分支中被修改而相同的内容必须按顺序修改。
一些实施方案还可以保持系统数据的可见性，提供全局DAG的不同视图，取决于用户在一个项目(或层次中的相关项目)中的作用，或用户涉及的创建或修改实体的先前历史。系统数据的配置取决于用户之间可能形成的关系。
在各种实施方案中，提供了一种方法，允许用户安全且有效地共同专门化DAG中的一个或多个节点，其中每个节点与本地节点共享共同的祖先，同时将新的细化节点与本地节点相关联，将被细化的节点呈现为所述本地节点的遗传后代；一种用于允许用户安全且有效地联合推广DAG中的一个或多个节点的方法，其中每个节点都与一个节点共享共同的祖先，同时，关联新的细化节点于共同祖先，通过把细化节点视为本地节点，并从共同祖先初始化操作。
在各种实施例中，提出了一种允许用户以有向无环图的形式探索其中分层结构的方法，使得一个或多个节点被区分为本地。本地节点的后代可以作为一颗树来探索，本地节点的祖先则作为倒置树探索。随着一些节点的展开，其他节点被折叠，使得任何实体仅由单个可见节点表示。虽然同一实体可以通过多个当地节点的祖先或后代到达，该实体只由单个节点表示。
在各种实施例中，提出了一种方法，允许各种用户协调他们对项目结构的访问和修改，该项目结构允许通过基于层次的相继变更的用户界面，回滚到特定独立生成的内容而不干扰其他内容，并支持冲突变更凭直觉的合并。
各种实施例提供给系统、方法和非暂时性计算机可读介质，用有向无环图的一部分作为分层树结构的图形表示，以方便用户通过通信网络进行协作。系统、方法和计算机可读介质可以被配置为通过通信网络获得在多个用户之间共享的协作项目，由有向无环图结构表示的协作项目包括多个实体和多个关联，所述多个实体包括一个或多个本地节点，所述一个或多个本地节点中的每一个与一个本地节点相关联，由该节点，每个本地节点的子代实体在有向无环图中遍历为树结构，树中的每个子节点在有向无环图中标识为与子代相关的相应实体，对应于树中双亲的实体；并展开一个以树的叶节点为根的子树，响应用户输入。
各种实施例提供给系统、方法和非暂时性计算机可读介质，用有向无环图的一部分作为分层树结构的图形表示，以方便用户通过通信网络进行协作。系统、方法和计算机可读介质可以被配置为通过通信网络获得在多个用户之间共享的协作项目，由有向无环图结构表示的协作项目包括多个实体和多个关联，所述多个实体包括一个或多个本地节点，所述一个或多个本地节点中的每一个与一个本地节点相关联，由该节点，每个本地节点的祖先实体在有向无环图中遍历为倒置树结构，树中的每个子节点在有向无环图中标识与子代相关的相应实体，对应于树中双亲的实体；并展开一个以树的叶节点为根的子树，响应用户输入。
在一些实施例中，系统、方法和计算机可读介质被配置为用于折叠树中的至少一个其他节点为根的子树，以响应多个用户的输入，允许多个实体中的特定实体被多个节点中的单个可见节点图形化表示。
在一些实施例中，系统、方法和计算机可读介质被配置为用于折叠倒置树中的至少一个其他节点为根的子树，以响应多个用户输入，允许多个实体中的特定实体由多个节点中的最多被单个可见节点图形化表示。
在一些实施例中，一些实体与一个或多个文件中的任何一个、一个或多个各自覆盖一个时间段的进度报告、一个或多个对项目的贡献记录相关联，相关的实体可以被设置为本地节点，其子结构或其他辅助数据可以被用户探索，；而系统，方法和非暂时性计算机可读介质被配置为显示以下内容的集成：一个或多个文件中的任何部分、各自覆盖一个时间段的进度报告，一个或多个对项目的贡献记录，或任何其他与每个可见节点指示的特定实体相关联的辅助数据。
在一些实施例中，每个实体各自属于一个特定种类，并且每种关联各自属于一个特定种类，一种这样的关联是细化；并且那里至少有一个或多个本地实体的一个适当的细化祖先，进一步与一个或多个其他后代(不是对应的一个或多个本地实体的后代)相关联，并且一个或多个其他后代明显地被相应的一个或多个本地节点的继承后代所表示，指明相应的一个或多个本地实体。
在一些实施例中，每个实体各自属于一个特定种类，并且每种关联各自属于一个特定种类，一种这样的关联是细化；系统，方法和非暂时性计算机可读介质被配置为通过第一次操作引起有向无环图的增广，第一次操作添加一个新节点到多个节点中，第一次操作从多个节点中的特定节点开始，新节点作为特定节点的子代出现；并创建一个新实体与新节点关联，以及新实体与特定实体之间的一个关联，新节点和关联的种类基于第一次操作。
在一些实施例中，每个实体各自属于一个特定种类，并且每种关联各自属于一个特定种类，一种这样的关联是细化；系统，方法和非暂时性计算机可读介质被配置为，当一个用户从多个节点(通过由继承节点组成的路径连接到一个本地节点)中的一个起始继承节点启动时，执行一个重述操作或对路径的最终重述节点执行一个第二次操作，且作为对第二次操作的前驱，对于来自本地节点的路径上的每个继承节点，但不包括本地节点：创建一个重述实体，创建重述实体与本地节点指示的实体之间的第一关联，第一关联的种类，与被继承节点指示的实体和被其父节点指示的实体之间的关联相同，如果本地节点不是继承节点的双亲；在重述实体和继承的重述实体之间创建第二个关联，其中重述实体细化被重述的继承实体。
在一些实施例中，每个实体各自属于一个特定种类，并且每种关联各自属于一个特定种类，一种这样的关联是细化；系统，方法和非暂时性计算机可读介质被配置为，当一个用户从多个节点(通过由继承节点和非继承节点组成的路径连接到一个本地节点)中的一个起始继承节点启动时，执行一个重述操作或对路径的最终重述节点来执行一个第二次操作，且作为对第二次操作的前驱，对于来自本地节点的路径上的每个继承节点，但不包括本地节点：创建一个重述实体，如果路径节点的双亲是继承的，在重述实体和本地节点指示的实体之间创建一个第一关联，如果路径节点的双亲是继承的或是本地节点，其中第一关联的类型，与路径节点和适当细化祖先之间关联的类型相同,如果本地节点是路径节点的父节点或重述路径节点沿着路径的结果，其中第一关联的类型，与被路径节点指示的实体与其父节点指示的实体之间关联的类型相同,如果本地节点不是；路径节点的父节点并创建第二个关联，如果是路径节点继承的，在重述实体和被重述的继承实体之间，其中重述实体细化被重述的继承路径实体。
在一些实施例中，一种这样的关联是细化；系统，方法和非暂时性计算机可读介质被配置为，当一个用户从多个节点(通过由继承节点和非继承节点组成的路径连接到一个本地节点)中的一个起始继承节点启动时这样执行：每个继承的起始节点通过相应的路径(由重述操作的继承节点组成)连接到本地节点，或在以下条件下执行第二个操作：对多条路径中任一条上的每个节点，除开本地节点：创建一个重述实体；创建在重述实体和被本地节点指示的实体之间的第一关联，其中第一关联的类型，与继承节点和适当细化祖先之间关联的类型相同,或者在重述实体和沿相应路径重述继承节点的父节点之间的结果，其中第一关联的类型，与本地节点指示的实体和其父节点指示的实体之间的关联的类型相同,如果本地节点不是继承节点的父节点；在重述实体和被重述的继承实体之间创建第二个关联，其中重述实体细化被重述的继承实体。
在一些实施例中，至少一个其他子代可以与一个或多个后代相关联，它们不是本地节点的后代，并且一个或多个后代明显地被表示为本地节点的继承后代；并且至少一个其他子代与一个或多个并非本地节点的后代相关联，后代可以包括一个重述细化结果；而重述节点及其后代可以从本地节点的继承后代中排除。
在一些实施例中，至少一个其他子代与一个或多个并非本地节点后代的后代相关联，并且一个或多个后代可以被明确地表示为本地节点的继承后代；并且至少一个其他子代可以由本地节点的一个后代重述；和其他子代可以被排除在本地节点的继承后代之外。
在一些实施例中，一种这样的关联是细化；系统，方法和非暂时性计算机可读介质被配置为，通过第一次操作引起有向无环图的增广，第一次操作将新节点添加到多个节点，第一次操作从多个节点中的特定节点开始，新节点作为特定节点的倒置树内的子代出现；并创建一个新实体与新节点相关联，以及新实体与特定实体之间的关联，新节点的种类与特定节点的种类相同，并且关联的类型是细化，特定节点细化新节点。
在一些实施例中，每个实体为一个特定的类型，且每个关联为一个特定的类型，一个此类关联即为细化；以及当用户从来自所述多个节点中的起始上下文节点启动一个操作时，所述指令进一步使所述系统对所述起始上下文节点和所述对应的本地节点之间的路径上的多个上下文节点中的每一个(除所述起始上下文节点外)进行以下操作：创建归纳实体，所述新实体的类型与所述上下文节点的类型相同；创建所述归纳实体和所述起始上下文节点指示的所述实体之间的第一关联，其中，如果所述上下文节点是所述起始上下文节点的所述倒置树中的所述父节点，则所述第一关联与所述上下文实体和所述起始上下文节点指示的所述实体之间的关联的类型相同，其中，如果所述上下文节点不是所述起始上下文节点的所述倒置树中的所述父节点，则所述第一关联与所述倒置树内的所述上下文节点指示的所述实体和其子节点指示的所述实体之间的关联的类型相同；以及创建所述归纳实体和所述上下文节点指示的所述实体之间的第二关联，其中，所述上下文节点指示的所述实体对所述归纳实体进行细化。在一些实施例中，倒置树结构在包括多个树结构的森林结构中形成，使得每个树结构包括两个通过相互嵌套呈现在基底树中的列表：由树结构组成的第一列表，由节点组成的第二列表，其中：任一第二列表中除最后一个节点外的所有节点在所述基底树中都没有子节点；本地节点在所述基底树中都没有兄弟节点或子节点；任一第二列表中的每个节点指示的实体在所述第二列表中的所述最后一个节点的基底树的第一列表中的每个子节点的基底树的第二列表中的所述第一子节点的有向无环图中为父实体。
在一些实施例中，树结构在包括多个树结构的森林结构中形成，使得每个树结构包括两个通过相互嵌套呈现在基底树中的列表：由包括指定节点的树结构组成的第一列表由节点组成的第二列表其中：任一第二列表中的每个节点指示的实体都没有子实体，并且在所述基底树中其父树结构的所述指定节点指示的所述实体的有向无环图中是子实体，所述最外面的树结构具有仅由本地节点组成的列表；任一第一列表中的每个树结构的所述指定节点指示的所述实体在所述基底树中其父节点的父节点的所述指定节点指示的所述实体的有向无环图中为子实体。
在一些实施例中，每个实体为一个特定的类型，且每个关联为一个特定的类型，一个此类关联即为细化；以及当用户从来自所述多个节点中的起始上下文节点启动操作时，所述指令进一步使所述系统对所述起始上下文节点和本地节点之间的所述基底树中的任一路径上的多个上下文节点中的每一个(除所述起始上下文节点外，包括除包含所述起始上下文节点的第一列表外的每个第一列表的第一元素)进行以下操作：创建归纳实体；创建所述归纳实体和所述起始上下文节点指示的所述实体之间的第一关联，其中，如果所述上下文节点是所述起始上下文节点的所述倒置树中的所述父节点，则所述第一关联与所述上下文实体和所述起始上下文节点指示的所述实体之间的关联的类型相同，其中，如果所述上下文节点不是所述起始上下文节点的所述倒置树中的所述父节点，则所述第一关联与所述倒置树内的所述上下文节点指示的所述实体和其子节点指示的所述实体之间的关联的类型相同；以及创建所述归纳实体和所述上下文节点指示的所述实体之间的第二关联，其中，所述上下文节点指示的所述实体对所述归纳实体进行细化。
所述创建的归纳细化包括重述。
在一些实施例中，创建的归纳细化包括重述。
各种实施例提供给系统、方法和非暂时性计算机可读介质，用有向无环图的一部分作为分层树结构的图形表示，以方便用户通过通信网络进行协作。系统、方法和计算机可读介质可以被配置为通过通信网络获得在多个用户之间共享的协作项目，由有向无环图结构表示的协作项目包括多个实体,每个实体具有特定种类和多种关联，每种特定种类，其中之一是细化，多个实体包括至少一个本地实体，至少本地实体中的每一个与一个本地节点相关联，由这个节点，每个本地节点的子代实体在有向无环图中遍历为树结构，树中的每个子节点在有向无环图中标识为与子代相关的相应实体，对应于树中双亲的实体；这里一个或者多个本地实体至少有一个适当的细化祖先，它进一步与更多其他后代相关联，它们不是对应的一个或多个本地实体的后代，并且至少一个其他后代中的每一个明显地表示为相应的至少一个本地节点的继承后代，指示那个至少是一个本地实体；并展开以树的一个叶节点为根的树，响应用户的输入。
附图的简要说明
数据流程图中的箭头指示从尾部处理单元到头部处理单元的信息流。数据流程图使用双箭头指示流入可能导致组件状态的改变,而单个箭头则表示没有改变。
过程流程图使用椭圆形中的各种指令，包括START，STOP，CONTINUE和FAIL指令。声明块显示为矩形，决策点显示为菱形。对数据结构的迭代由“for”块表示，该块显示为包含要为每次迭代执行的指令的大矩形。
工艺流程图中的箭头表示从尾部处理单元到头部处理单元的控制流程。如果线在箭头处遇到处理单元，则控制流向该处理单元，否则它从处理单元流出。当多线离开处理单元时，所有路径将以任何顺序或同时进行，并适当注意任何共享资源，如软件开发领域的技术人员所熟悉的。异常可能是来自菱形节点的分叉，在该分叉处，在其指定条件下成功的所有路径将以任何顺序或同时采用相同的警告。上述惯例仅用于表达关于各种处理步骤之间的关系的直觉，而不是提供所有处理步骤的详尽说明或者可以实现实施例的这些步骤的所有可能的顺序。
过程流程图可以利用箭头到步骤的集群来指示对组件数据的子例程调用，包括递归子例程调用。如果在递归调用之后还有其它工作要做，则可以通过CONTINUE指令或使用STOP指令隐式指示执行此类剩余工作。这种递归是一种说明性机制。可以使用递归，迭代，宏扩展等来实现基础计算。
从处理单元内部到外部的弧可以被解释为任何其它箭头，尽管这些箭头是通过递归调用实现的候选者。为了帮助直觉，我们非正式地使用递归语言来描述文本描述中的这样的箭头，尽管实施例可能或可能不选择如此执行。当描述引用堆栈时，通常情况是大多数编程语言假定的系统堆栈就足够了。
分支处的析取符号(∨)表示应该采用恰好一条路径。分支处的合取符号(∧)表示所有路径都是独立采用的，除了在较低实施级别的共享资源强加的分支之外，对分支的相应流没有约束。我们打算所有这些计算在进行之前在连接点处相遇。
块结构图中的箭头表示头部的模块是使用尾部的模块实现的。
在多于一个地方出现但指定相同代码的绘图元素被假定为在所呈现的实施例中指代相同的事物，尽管其它实施例可以区分它们。
图1是根据一些实施例的初始用户屏幕。
图2是根据一些实施例的在点击“创建新挑战”之后的用户屏幕。
图3是根据一些实施例的在键入初始问题名称之后的用户屏幕。
图4是根据一些实施例的在创建初始问题的动作之后的用户屏幕。
图5是根据一些实施例的选择对根问题的具体化动作的项目屏幕。
图6是键入细化问题名称后的项目屏幕。
图7是根据一些实施例的选择对根问题的解决动作的项目屏幕。
图8是根据一些实施例的在键入解决方案名称之后的项目屏幕。
图9是根据一些实施例的在解决根问题的动作之后的项目屏幕。
图10是根据一些实施例选择对解决方案的组件化动作的项目屏幕。
图11是根据一些实施例的在键入组件问题名称之后的项目屏幕。
图12是根据一些实施例的通过细化问题显示项目继承的项目屏幕。
图13是根据一些实施例的由细化解决方案继承项目的项目屏幕。
图14是根据一些实施例选择对两个问题的具体化动作的项目屏幕。
图15是根据一些实施例选择对继承项目的具体化动作的项目屏幕。
图16是根据一些实施例的在原位重述继承的解决方案的项目屏幕。
图17是根据一些实施例的原位重述遗留问题的项目屏幕。
图18是根据一些实施例的改进重述问题的项目屏幕。
图19是根据一些实施例的在重新继承项目之后的项目屏幕。
图20是根据一些实施例重述继承项目而产生的项目的双亲的项目屏幕。
图21是根据一些实施例的祖代项目屏幕，显示出了重述的项目及其重述。
图22是如[0315]中描述的一个实施例的从上而下数据流程图。
图23是如[0316]描述的一个实施例的若干用例的交互序列图。
在示例DAG和树中，为了具体起见，我们假设圆表示问题而正方形表示解，并且顺序地对这些表进行编号。我们没有指出关联的种类，因为根据关联的来源和目标的种类，这对于该实施例是显而易见的。所选节点以边框显示，并且启动操作的节点以边框和四个均匀间隔的凹口显示。
图24是显示根据一些实施例的表示问题和解空间的示例DAG图。
图25是根据一些实施例，显示来自图24的示例DAG的subDAG的图。导航以一个节点(1)为中心导航。
图26是根据一些实施例，以图25的一个节点(1)为中心显示示例DAG的subDAG的图。图25中的导航和一些结构(包括节点9,11,12和15)被继承。从节点10到节点1的链接已被拼接出来。
图27是根据一些实施例，显示来自图26的示例DAG的subDAG的图。图26示出了的探索节点4和10的树。
图28是根据一些实施例，显示来自图27的探索。图27示出了以一个节点(1)为中心导航，使用新的解决方案节点(13)显着地细化来自子结构(4)和(10)的解决方案节点的过程，呈现为树。
图29是根据一些实施例，利用如图28所示的新解决方案节点13对解决方案节点4和10进行显式细化之后显示示例DAG的图。
图30是根据一些实施例，显示来自图27的探索的图。图27中导航以一个节点(1)为中心，在明确地从子结构(4)中细化解决方案节点的过程中，以及一个继承的解决方案节点(10)，其中新的解决方案节点(16)解决了问题节点5，同时表示为树。
图31是根据一些实施例，在解决方案节点4和10用新解决方案节点16显式细化之后显示示例DAG的图，该解决方案节点16解决了如图28所示的问题节点5。
图32是根据一些实施例，显示来自图24的示例DAG的subDAG的图。导航以一个节点(5)为中心。
图33是根据一些实施例，显示示例DAG的subDAG的图，其中导航以图32中的一个节点(5)为中心。由图32和一些继承的结构(包括节点4,7,8,9,10,11,12和15)。
图34是根据一些实施例，显示来自图33的示例DAG的subDAG的图。图33示出了根据一些实施例的探索节点4和8的树。
图35是根据一些实施例，显示图34的探索的图。在解决该问题节点的过程期间导航以一个节点(5)为中心并且用新解决方案节点(14)细化两个继承的解决方案节点(4和8)，同时呈现为树。
图36是根据一些实施例，在解决问题节点5并用如图35所示的新解决方案节点14细化解决方案节点4和8之后显示示例DAG的图。
图37是根据一些实施例，显示来自图26的示例DAG的subDAG的图。图26示出了根据一些实施例的探索节点12和15的树。
图38是根据一些实施例，显示来自图37的探索的图。图37示出了用一个新的解决方案节点(17)细化两个继承的解决方案节点(12和15)的迭代过程，导航以一个节点(1)为中心，同时呈现为树。
图39是根据一些实施例，利用如图38所示的新解决方案节点17细化问题节点12和15之后显示示例DAG的图。
图40是根据一些实施例，显示来自图37的探索的图。图37示出了用一个新的解决方案节点(17)细化两个继承的解决方案节点(12和15)的就地迭代过程，导航以一个节点(1)为中心，同时呈现为树。
图41是根据一些实施例，显示来自图37的探索的图。根据一些实施例，在使用新的解决方案节点(17)细化两个继承的解决方案节点(12和15)的就地迭代过程之后，导航以一个节点(1)为中心。
图42是如[0323]中所述的用于没有继承的具体化的实施例的方框结构图。
图43是根据一些实施例，如在[0327]中描述的DAG简化过程的实施例的过程流程图。
图44是根据一些实施例，如在[0332]中描述的冗余细化消除过程的实施例的过程流程图。
图45是根据一些实施例，如在[0350]中所描述的，在没有继承的情况下执行DAG的单个具体化增广的客户端动作的过程流程图。
图46是根据一些实施例的计算细化节点的对象相对于没有继承的子结构和上下文树的最大下界的过程流程图。
图47是根据一些实施例的关于上下文和子结构树二者计算节点的最大下界的过程流程图。
图48是根据一些实施例的关于树(上下文或子结构)计算节点的最小上界的过程流程图。
图49是根据一些实施例的关于树(上下文或子结构)计算节点的最大下界的过程流程图。
图50是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成一个证明：DAG的具体化增广被简化为子结构和上下文树而没有继承并且间接对象满足约束。
图51是根据一些实施例的服务器动作的过程流程图，用于验证具有间接对象的DAG的具体化增广满足约束。
图52是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成一个证明：DAG的具体化增广被简化为子结构和上下文树而没有继承并且仅有直接对象满足约束。
图53是根据一些实施例的服务器动作的过程流程图，用于验证仅具有直接对象的DAG的具体化增广满足约束的证据的服务器动作的过程流程图。
图54是根据一些实施例的显示以节点51为中心的导航的示例DAG的图。
图55是根据一些实施例，显示来自图54的示例DAG的图，在解决问题节点52并用新解决方案节点55细化解决方案节点54之后。
图56是根据一些实施例，如[0362]中所描述的，在没有继承的情况下执行DAG的单个跨种和具体化增广的客户端动作的过程流程图。
图57是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成证明DAG的跨种和具体化增广被简化为子结构和上下文树而没有继承并且仅有直接对象满足约束。
图58是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成证明DAG的跨种和具体化增广减少到子结构和上下文树而没有继承但有间接对象满足约束。
图59是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成证明DAG的增广简化为子结构和上下文树满足约束的证据的一部分。
图60是根据一些实施例的服务器动作的过程流程图，该服务器动作用于验证具有间接对象的DAG的跨种和具体化增广满足约束的证明。
图61是根据一些实施例的服务器动作的过程流程图，该服务器动作用于验证仅具有直接对象的DAG的跨种和具体化增广的证据满足约束。
图62是如[0367]中所述的用于具体化的实施例的框结构图。
图63是根据一些实施例的DAG定位过程的实施例的过程流程图。
图64是根据一些实施例的如[0372]所述的继承过程的实施例的过程流程图。
图65是根据一些实施例的继承过程的组件的不确定实施例的过程流程图，它收集要继承的结构，如[0374]所述。
图66是根据一些实施例的将继承结构连接到DAG的继承过程的实施例的组件的过程流程图，如[0375]中所述。
图67是根据一些实施例的继承过程的最浅首先实施例的组件的过程流程图，它通过前序遍历收集待继承的结构，如[0378]中所述。
图68是根据一些实施例的继承过程的最深首先实施例的组件的过程流程图，它通过前序遍历收集待继承的结构，如[0379]中所述。
图69是根据一些实施例的继承过程的备选的最深首先实施例的组件的过程流程图，它通过前序遍历收集待继承的结构，如[0379]中所述。
图70是根据一些实施例的连接继承结构到DAG的继承过程的最深首先实施例的组件的过程流程图，如[0379]中所述。
图71是根据一些实施例的收集被继承结构和它被继承的路径的继承过程组件的最深首先实施例的组件的过程流程图，如[0394]中所述。
图72是根据一些实施例的收集被继承结构和它被继承的流(DAG)的继承过程组件的最深首先实施例的组件的过程流程图，如[0398]中所述。
图73是根据一些实施例的客户端实现一个DAG)的单一具体化增广动作的过程流程图，如[0399]中所述。
图74是根据一些实施例的客户端动作生成一个证明过程流程图，该证明显示一个DAG的具体化增广简化为子结构和上下文树带有继承和间接对象满足约束。
图75是根据一些实施例的客户端动作生成一个证明过程流程图，该证明显示一个DAG的具体化增广简化为子结构和上下文树带有继承和只有直接对象满足约束。
图76是根据一些实施例的客户端动作生成一个证明的独立节点路径的过程流程图，该证明显示一个DAG的具体化增广简化为子结构和上下文树带有继承和间接对象满足约束。
图77是根据一些实施例的客户端实现一个DAG)的单一跨种和具体化增广动作的过程流程图，如[0408]中所述。
图78是根据一些实施例的客户端动作生成一个证明过程流程图，该证明显示一个DAG的跨种和具体化增广简化为子结构和上下文树带有继承和间接对象满足约束。
图79是根据一些实施例的客户端动作生成一个证明过程流程图，该证明显示一个DAG的跨种和具体化增广简化为子结构和上下文树带有继承和只有直接对象满足约束。
图80是根据一些实施例的客户端实现一个DAG的具体化增广动作的过程流程图，如[0421]中所述。
图81是根据一些实施例的客户端实现一个DAG的具体化增广动作的过程流程图的一个替代版本，该DAG处理单个继承节点的细化，作为复制细化祖代过程的一部分，如[0421]中所述。
图82是根据一些实施例的客户端实现一个DAG的跨种和具体化增广动作的过程流程图，如[0422]中所述。
图83是根据一些实施例的客户端复制节点的继承祖代，具体化于本地节点的过程流程图，如[0422]中所述。
图84是根据一些实施例的用于图38的情况的增广过程的一个实施例的本地节点跟踪。
图85是被修改为处理“不连续示例的事件参数继承过程跟踪”的增广过程的一个实施例的跟踪图。
图86是根据一些实施例的继承过程的组件的最浅首先实施例的组件的过程流程图，它通过重述来收集要继承的结构和它被继承的路径，如[0435]中所述。
图87是根据一些实施例的继承过程的实施例的组件的过程流程图，它在跳过不相关的重述时将继承的结构连接到DAG，如[0438]中所述。
图88是根据一些实施例的继承过程的实施例的组件的过程流程图，该过程将继承的重述连接到DAG，同时跳过不相关的重述，如[0438]中所述。
图89是根据一些实施例的用于执行具体化增广的客户端动作的过程流程图，该具体化增广甚至在重述之后细化单个继承的节点。
图90是根据一些实施例的客户端动作的过程流程图，该客户端动作用于重述一个当地节点继承的祖代，如[0439]中所述。
图91是根据一些实施例的执行DAG的单个专门重述增广的客户端动作的过程流程图。
图92是根据一些实施例的执行DAG的单个跨种和专门重述增广的客户端动作的过程流程图，如[0440]中所述。
图93是根据一些实施例的显示第二示例DAG的图。
图94是根据一些实施例的显示来自图93的示例DAG的subDAG的图，图93以两个节点(22和23)为中心导航。
图95是根据一些实施例的显示以图94中的两个节点(22和23)为中心的示例DAG的subDAG的图。图94具有继承的一些结构(包括节点24和25)。
图96是显示来自图95的示例DAG的subDAG的图。图95示出了根据一些实施例的探索节点24和25的树。
图97是根据一些实施例的显示来自图96的探索的图。根据一些实施例，在解决那些问题节点的过程期间导航以两个节点(22和23)为中心并且使用新的解决方案节点(26)细化两个继承的解决方案节点(24和25)，同时呈现为树。
图98是根据一些实施例的显示来自图97的示例DAG的图。在解出问题节点22和23以及用新的解决方案节点26细化解决方案节点24之后，如图97所示，在图93中示出了解决方案。
图99是根据一些实施例的显示以节点31为中心的导航的第三示例DAG的图。
图100是根据一些实施例显示来自图99的示例DAG的图。图99示出了探索节点36和37的子结构树。
图101是根据一些实施例的显示来自图100的探索的图。导航以节点31为中心，在使用新的从属节点(38)泛化两个从属节点(36和37)的过程中，并且呈现为树。
图102是显示来自图99的示例DAG的图。在增广独立节点31并使用新的从属节点38增广从属节点36和37之后，如图101所示。
图103是根据一些实施例的显示以节点46和47为中心的导航的第四示例DAG的图。
图104是根据一些实施例的显示来自图103的示例DAG的图。图103示出了展开节点41的一对重叠上下文树。
图105是根据一些实施例，显示来自图104的探索的图。在增广节点41的过程期间导航以节点46和47为中心，同时将两个从属节点(48和49)与新的从属节点(50)一起推广，同时呈现为树。
图106是显示来自图105的示例DAG的图。在增广独立节点41并且使用新的从属节点50泛化从属节点48和49之后，如图103所示。
图107是根据一些实施例的显示以节点74和75为中心导航的第五示例DAG的图。
图108是根据一些实施例，显示来自图107的示例DAG的图，在利用新解决方案节点78解决问题节点70之后，通过现有解组件的泛化来对其进行组件化。
图109是一个用于无继承的泛化的实施例的框结构图，如[0469]中所述。
图110是执行DAG的单个泛化增广的客户端动作的过程流程图，如[0477]中所述。
图111是根据一些实施例的计算细化节点的对象相对于没有继承的子结构和上下文树的最小上界的过程流程图。
图112是根据一些实施例的关于上下文和子结构树计算节点的最小上界的过程流程图。
图113是根据一些实施例的项目屏幕，用于选择一个解决方案作泛化。
图114是根据一些实施例的项目屏幕，用于选择第二个解决方案作泛化。
图115是根据一些实施例的项目屏幕，用于选择泛化解决方案操作。
图116是根据一些实施例的项目屏幕，用于解一个问题，同时抽取其它的。
图117是根据一些实施例的项目屏幕，用于细化一个解，同时抽取其它的。
图118是根据一些实施例的项目屏幕，在迭代抽取解以后。
图119是根据一些实施例的项目屏幕，由替代的具体化问题，迭代抽取解以后。
图120是根据一些实施例的项目屏幕，用于选择泛化到重述操作。
图121是根据一些实施例的项目屏幕，用于输入新的泛化解决方案。
图122是根据一些实施例的项目屏幕，用于生成一个证明：一个DAG的泛化增广简化之为子结构和上下文树，没有继承和有间接对象满足约束。
图123是根据一些实施例的用于验证具有间接对象的DAG的泛化增广满足约束的证据的服务器动作的过程流程图。
图124是根据一些实施例的用于验证仅具有直接对象的DAG的泛化增广满足约束的证据的服务器动作的过程流程图。
图125是根据一些实施例的项目屏幕，用于执行DAG的单个种间和泛化增广的客户端动作的过程流程图，如[0491]中所描述。
图126是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成证明DAG的跨种和泛化增广减少到子结构和上下文树而没有继承并且间接对象满足约束。
图127是根据一些实施例的客户端动作的过程流程图，该客户端动作用于生成证明DAG的跨种和泛化增广简化到子结构和上下文树，没有继承并且仅有直接对象满足约束。
图128是根据一些实施例的服务器动作的过程流程图，该服务器动作用于验证具有间接对象的DAG的跨种和泛化增广满足约束。
图129是根据一些实施例的服务器动作的过程流程图，该服务器动作用于验证只有间接对象的DAG的跨种和泛化增广满足约束。
图130用于迭代泛化的实施例的框结构图，如[0500]中所描述。
图131是根据一些实施例的执行跨种和泛化DAG的增广的客户端动作的过程流程图，如[0501]中所描述的。
图132是根据一些实施例的显示以节点61或64和66为中心的导航的示例DAG的图。
图133是根据一些实施例的显示来自图132的示例DAG的图，在创建从现有节点66到现有节点64的细化关联之后。
图134是根据一些实施例的的用于执行具有子结构中的节点之间的细化关联的DAG增广的客户端动作的过程流程图，如[0515]中所描述。
图135是根据一些实施例的用于执行具有本地节点之间的细化关联的DAG的增广的客户端动作的过程流程图，如[0518]中所描述。
图136是根据一些实施例的通过在现有实体之间添加细化关联来执行DAG的单个增广的客户端动作的过程流程图。
图137是根据一些实施例的用于描述数据测量问题中的条件表示的初始全局示例DAG。
图138是根据一些实施例的图137的示例的局部条件DAG，在节点80处的导航中使用。
图139是根据一些实施例的图137的示例的局部条件DAG，在节点81处的导航中使用，在应用“具体化术语”之前。
图140是根据一些实施例的图137的示例的局部条件DAG，在节点81处的导航中使用，在应用具体化术语(以及稍后的操作)之后。
图141是根据一些实施例的图137的示例的局部条件DAG，在节点82处的导航中使用，在应用移除分离之前。
图142是根据一些实施例的图137的示例的局部条件DAG，在节点82处的导航中使用，在应用移除分离(以及稍后的操作)之后。
图143是根据一些实施例的图137的示例的局部条件DAG，在节点83处的导航中使用，在应用Add Conjunct之前。
图144是根据一些实施例的图137的示例的局部条件DAG，在节点83处的导航中使用，在应用Add Conjunct(以及稍后的操作)之后。
图145是根据一些实施例的图137的示例的局部条件DAG，在节点83处的导航中使用，在应用Merge Disjuncts之前。
图146是根据一些实施例的图137的示例的最终全局DAG。
图147是根据一些实施例的图137的示例的局部条件DAG。在节点84处的导航中使用，在应用Merge Disjuncts(以及稍后的操作)之后。
图148是根据一些实施例的图137的示例的最终本地DAG，在节点81处的导航中使用。
图149是根据一些实施例的图137的示例的最终本地DAG，在节点82处的导航中使用。
图150是根据一些实施例的图137的示例的最终本地DAG，在节点83处的导航中使用。
图151是根据一些实施例的图137的示例的最终本地DAG，在节点84处的导航中使用。
图152是根据一些实施例的图137的示例的最终本地DAG，在节点85处的导航中使用。
图153是图137的示例的最终全局DAG。根据一些实施例，图137中的弧标记有用于简化数据项集的指令。
图154是根据一些实施例的用于描述数据测量问题中的条件表示的第二初始全局示例DAG。
图155是根据一些实施例的图154的示例的局部条件DAG，在节点90处的导航中的。
图156是根据一些实施例的图154的示例的局部条件DAG，在应用嵌入连接之前，在节点91处的导航中。
图157是根据一些实施例的图154的示例的局部条件DAG，在应用嵌入连接(以及稍后的操作)之后，在节点91处的导航中。
图158是根据一些实施例的图154的示例的局部条件DAG，在应用嵌入连接之前，在节点92处的导航中。
图159是根据一些实施例的图154的示例的局部条件DAG，在应用嵌入连接(以及稍后的操作)之后，在节点92处的导航中。
图160是根据一些实施例的图154的示例的最终全局DAG。
图161是根据一些实施例的图154的示例的最终全局DAG的替代版本，应用移动的操作员节点。
图162是根据一些实施例的图154的示例的最终本地DAG，在节点93处的导航。
图163是根据一些实施例的具有初始问题和解决方案的社交创新示例的项目屏幕。
图164是根据一些实施例的具有与第一问题尚未相关的具体化问题的用户屏幕。
图165是根据一些实施例的选择应用于具体化问题操作的项目屏幕。
图166是根据一些实施例的出现在相关的外部泛化问题和继承的解决方案的项目屏幕。
图167是根据一些实施例在重新申请继承的解决方案并应用附加增广之后的项目屏幕。
图168是根据一些实施例的具有尚未相关的泛化问题的用户屏幕。
图169是根据一些实施例的项目屏幕选择邀请另一个问题具体化的操作。
图170是根据一些实施例的社交创新示例之后的具体化项目屏幕附属按钮。
图171是根据一些实施例的社交创新示例之后的专门项目屏幕生态系统按钮。
图172根据一些实施例呈现了推荐过程的高层次结构。
图173根据一些实施例展示了用于将机器与问题状态相关联的示例用户界面。
图174呈现了根据一些实施例的用于基于其状态与解决方案接口的示例用户界面。
图1至图174中的绘图元素参照图14，它们可以被分配如下的四位代码：
·第一个数字表示细化增广的方向以及实施例是否处理继承。
1：主要支持非继承节点和显式增广的专业化
2：主要支持继承节点和隐式增广的专业化
3：主要支持专业化而不考虑继承
4：主要支持非继承节点和显式增广的泛化
5：主要支持继承节点的泛化和隐式增广
6：主要支持泛化而不考虑继承
0：适用于不考虑继承或细化增广的方向
·第二个数字指的是该元素是否主要与所呈现的实施例中的客户端或服务器相关。
1：主要面向客户
2：主要用于服务器
0：二者
·第三个数字是顺序。
·最后一个数字表示相关操作。
0：初始化
1：细化增广
2：细化/跨种增广
3：任何增广
4：删除/取消链接
5：移动/复制
6：通过细化链接
编号系统旨在帮助直觉并且参考这里给出的特定实施例。它并不旨在限制任何例程的适用性。
图175是显示一个实施例中的单个实体的子结构信息的表示的图。
图176是根据一些实施例的一个子结构构造过程的实施例的过程流程图，如策略0657.1中描述的。
图177是根据一些实施例的一个子结构初始化过程的实施例的过程流程图，如策略0657.1中所描述的。
图178是根据一些实施例的一个子结构展开过程的实施例的过程流程图，如策略0657.1中所描述的。
图179是根据一些实施例的子结构折叠过程的实施例的过程流程图，如[0665]中所描述的。
图180是根据一些实施例的在子节点不会冲突的假设下的最大子结构展开过程的实施例的过程流程图，策略0657.1，策略0653.1和策略0654.1中描述的。
图181是根据一些实施例的一个最大子结构展开，直到达到任何共同后代的展开过程的实施例的过程流程图，如在策略0657.1，策略0653.2和策略0654.2中所描述的。
图182是根据一些实施例的在假设子节点不会冲突的情况下打开单个非叶子代的子结构展开过程的实施例的过程流程图，如在策略0657.1，策略0653.3和策略0654.3中所描述的。
图183是根据一些实施例的在假设子节点不会冲突的情况下打开单个子代的初始化的子结构展开过程的实施例的过程流程图，如在策略0657.1，策略0653.4和策略0654.4中所描述的。
图184是根据一些实施例的在子节点不会冲突的假设下用于初始化的一元子结构展开过程的实施例的过程流程图，如策略0657.1，策略0653.5和策略0654.5中描述的。
图185是根据一些实施例的隐藏冲突的可见节点的最大子结构展开过程的一部分的实施例的过程流程图，如策略0657.1和策略0654.1和策略0654.2中所描述的。
图186是根据一些实施例的隐藏冲突的可见节点的某些子结构展开过程(打开单个子代或单个无叶子代)的一部分的实施例的过程流程图，如策略0657.1，策略0653.4和策略0654.4中所描述的。
图187是显示实施例中的单个实体的上下文信息的表示的图。
图188是根据一些实施例的单个实体的上下文初始化过程的实施例的过程流程图，如策略0657.2中所描述的。
图189是根据一些实施例的上下文扩展过程的实施例的过程流程图，如策略0657.2和策略0669.2中所描述的。
图190是根据一些实施例的单个实体的上下文折叠过程的实施例的过程流程图，如策略0657.2和[0674]中所描述的。
图191是根据一些实施例的在子节点不会冲突的假设下的最大上下文展开过程的实施例的过程流程图，如策略0657.2，策略0653.1和策略0654.1中描述的。
图192是根据一些实施例的，展开直到达到任何共同祖代的子结构展开过程的实施例的过程流程图，如在策略0657.2，策略0653.2和策略0654.2中所描述的。
图193是根据策略0657.2，策略0653.3和策略0654.3中所描述的，在假设子节点不会冲突的情况下打开单个非叶子项的单个本地实体的上下文展开过程的实施例的过程流程图。实施例。
图194是根据一些实施例的如在策略0657.2，策略0653.4和策略0654.4中所描述的在假设子节点不会冲突的情况下打开单个子代的上下文展开过程的实施例的过程流程图。
图195是根据一些实施例的在假设父节点不会冲突的情况下一元上下文展开过程的实施例的过程流程图，如策略0657.2，策略0653.5和策略0654.5中所描述的。
图196是根据一些实施例的隐藏冲突的可见节点的最大上下文展开过程的一部分的实施例的过程流程图，如策略0657.2和策略0654.1和策略0654.2中所描述的。
图197是根据一些实施例的隐藏冲突的可见节点的某些上下文展开过程(打开单个双亲或单个非孤儿双亲)的一部分的实施例的过程流程图，如策略0657.2，策略0653.4和策略0654.4中所描述的。
图198是显示在一个实施例中可以跨多个实体共享的上下文信息的表示的图。
图199是根据一些实施例的具有多个本地技能的屏幕，示出了对其共享上下文的探索。
图200、图201和图202是根据一些实施例的具有多个本地技能的屏幕，示出了具有共享上下文的上下文文件夹的打开。
图203是根据一些实施例的具有多个本地技能的屏幕，示出了根据一些实施例的具有共享上下文的上下文文件夹的关闭。
图204是根据一些实施例的用于多个实体的上下文初始化过程的实施例的过程流程图，如策略0657.2中所描述的。
图205是用于多个实体的上下文折叠过程的实施例的过程流程图，如策略0657.2和[0688]中描述的。
图206是根据一些实施例，在假设子节点不会冲突的情况下打开单个非叶子实体的多个轨迹实体的上下文展开过程的实施例的过程流程图，如策略0657.2，策略0653.3和策略0654.3中所描述的。
图207是根据一些实施例的在假设子节点不会冲突的情况下打开单个子代的多个轨迹实体的上下文展开过程的实施例的过程流程图，如在策略0657.2，策略0653.4和策略0654.4中所描述的。
图208是根据一些实施例的在假设父节点不会冲突的情况下一元上下文展开过程的实施例的过程流程图，如策略0657.2，策略0653.5和策略0654.5中所描述的。
图209是根据一些实施例的如策略0657.2，策略0653.4和策略0654.4中所描述的隐藏冲突的可见节点的某些上下文展开过程(打开单个双亲或单个非孤儿双亲)的一部分的实施例的过程流程图。
图210是根据一些实施例的如策略0657.2中所描述的，通过将其DAG后代提升到顶级来隐藏冲突的可见节点的多个本地实体的上下文展开过程的一部分的实施例的过程流程图。
图211是根据一些实施例的用于多个本地实体的上下文展开过程的一部分的实施例的过程流程图，该多个本地实体捕获其双亲集合在展开期间被揭示的顶级节点，如策略0657.2中所描述的。
图212是显示在一个实施例中可以跨多个实体共享的子结构信息的表示的图。
图213是根据一些实施例的一个例程的实施例的过程流程图，该例程接受从子结构中的点到根的实体标识符的路径，并确保沿着该路径的节点并未折叠，如[0427]所述。
图214是根据一些实施例的一个例程的实施例的过程流程图，该例程接受从上下文中的点到根的实体标识符的路径，并确保沿着该路径的并未折叠，如[0466]所述。
图215是根据一些实施例的具有与上下文和子结构相关的活动辅助信息的项目屏幕
图215是根据一些实施例的具有与上下文和子结构相关的活动辅助信息的项目屏幕。
图216是根据一些实施例的具有与上下文节点相关的辅助信息的项目屏幕。
图217是根据一些实施例的具有与本地节点相关的辅助信息的项目屏幕。
图218是根据一些实施例的具有与第一子结构节点相关的辅助信息的项目屏幕。
图219是根据一些实施例的具有与第二子结构节点相关的辅助信息的项目屏幕。
图220是根据一些实施例的具有与第三子结构节点相关的辅助信息的项目屏幕。
图221是根据一些实施例的具有与上下文相关的活动辅助信息的项目屏幕。
图222是根据一些实施例的具有与子结构相关的活动辅助信息的项目屏幕。
图223是根据一些实施例的具有与本地节点相关的活动辅助信息的项目屏幕。
图224是根据一些实施例的具有与第二子结构节点相关的组成辅助信息的项目屏幕。
图225是根据一些实施例的具有与第三子结构节点相关的组成辅助信息的项目屏幕。
图226是根据一些实施例的具有与子结构相关的组成辅助信息的项目屏幕。
图227是根据一些实施例的客户端过程的实施例的过程流程图，该客户端过程用于选择筛选值，通过该筛选值将实体包括在本地节点中。
图228是根据一些实施例的客户端过程的实施例的过程流程图，该客户端过程用于取消选择把实体包括在本地节点中的筛选值。
参照图175至图228的每个绘图元素被分配到如下六位代码：
·第一个数字表示相对位置。
1：子结构
2：上下文
·第二个数字指的是相对于导航状态活跃的节点。
1：单个本地节点
2：多个本地节点
3：规格一致的节点
0：与多个操作相关
·第三个数字指的是与元素关系最密切的操作。
1：创建
2：展开
3：折叠
4：删去除
0：与多个操作相关
·第四个数字指的是节点是静态还是动态分配的(如[0656]中所述)。
1：静态
2：动态
·第五个数字是指多少内容，或对于任何为0或N/A应显示的策略，按照[0653]或[0654]中列出的顺序：
·最后一位是编号。
编号系统旨在帮助直观和参考这里给出的特定实施例。它并不旨在限制任何例程的适用性。
图229是根据一些实施例的用户屏幕并未登录任何项目角色
图230是根据一些实施例的一个用户屏幕选择登录新项目角色的运算操作
图231是根据一些实施例的一个用户界面选择从当前项目角色退出的操作。
图232是根据一些实施例的一个处理变更请求的过程的实施例的过程流程图。
图233是根据一些实施例的一个核准变更过程的实施例的过程流程图。
图234是根据一些实施例的一个拒绝变更的过程的实施例的过程流程图。
图235是根据一些实施例的一个回滚变更的过程的实施例的过程流程图。
图236是根据一些实施例的一个撤消回滚的过程的实施例的过程流程图。
详细说明
把一个项目的“问题空间”与“解空间”分离的价值已得到认可。问题空间的元素可称为“问题”或“挑战”而解空间的元素可称为“解”或“方法”。通过允许挑战性建议和针对那些挑战的潜在解法，不同的系统使得合作和/或创新容易实现。
我们在宽泛的意义上理解问题和解，应用于任意领域包括广泛的社会问题和使之缓和的解，技术或工程问题和满足它们的解，以及通过市场行销确定的顾客的“痛”点和可以使之减轻的新产品。
人们可以在程序语言理论中搜寻问题和解空间的类比。例如，问题可能对应于类型，而解对应于表达，指定一种类型于表达对应于所面临问题的解。这一类比不能令人满意，因为虽然一个解肯定解决了它所面临问题的任何特殊情况，属于一种类型的表达不一定属于这一类型的任何子类型。并非因为类型理论不适用，而更是因为其间的关系是逆变的。特别当一个问题细化为另一个，我们指的是可以把后一个问题看作在更特殊领域中的函数类型。例如，在都市环境中减少贫困细分了更一般的减少贫困的问题，因为都市环境比一般环境更特殊，人们可以利用这种环境的特点来构思一个解。
面向对象语言为这种情况提供了一个类比，因为类处于细化分层结构中，其中一个方法参数(通常称为“this(这个)”或“self(自)”)与分层结构中的位置相关，因此在较低分层上变得更具体。就像超类的方法可以被任何子类调用一样，对精化问题的解决方案适用于任何细化问题，但反过来(从超类调用子类的方法)通常不安全。请注意，我们一贯使用“细化”来指代更专业化的实体，而“细化”则指的是它细化的更一般的实体，这可能与一些常见用法不同。
在编程语言理论中，有一种表达式细化的概念，即一旦表达式完成并具有相同的结果，一个表达式就会终止。还有一种通过从细化表达的状态图到细化表达的状态图的同态映射来表达细化的概念。
在项目方面，细化问题可以对应于识别问题的特殊情况，并且解决方案的细化可以对应于具有更多细节的解决方案的细化。除了解决问题的解决方案之外，我们还考虑解决激励问题的关系，通过解决激励问题来解决激励问题。我们通过问题的细化关系来考虑解决方案的继承问题，并通过解决方案上的细化关系来解决问题的继承问题。通过问题细化关系解决方案的继承认识到，问题的解决方案也与该问题的任何细化有关，尽管细化解决方案可能更合适。通过关于解决方案的改进关系来解决问题的承认意识到，解决方案对于实施激励解决方案来说是必需的问题也与实施该解决方案的任何改进有关，并且必须加以解决，尽管可能以改进问题的形式出现。一般来说，问题的精化关系和解决方案的关系都是多对多的关系，即不仅可以用多种方式来完善相同的问题或解决方案，而且给定的问题或解决方案可以细化多种其它问题或解决方案，分别。处理和激发问题的解决方案之间的关系也可能是多对多的关系。
常常是这样的情况，但并不了解解决方案就问题而言是细化的，即所提供的附加细节与细化解决方案解决细化问题的事实有关。或者从另一个角度来看，问题的解决方案可以利用较不具体的解决方案来解决更普遍的问题。同样，情况往往是这样，但并没有意识到问题在解决方案方面有所改进，即所确定的特殊情况与细化问题是由细化解决方案激发的事实有关，该解决方案更紧密地定义了需要的东西实现。或者，由解决方案激发的问题可能会增加对由较不具体解决方案驱动的更普遍问题的限制。
除了解决由解决方案激发的问题和问题的解决方案外，实施例保持关于项目信息的其它元素的信息，其可以包括但不限于技能，论据，个人和资金。例如，可以保持解决方案所需的技能，更具体的解决方案需要更具体的技能，类似的论点支持或反对问题(它们的相关性)，解决方案(它们的正确性)或其它论证(它们的有效性)。所需技能可通过解决方案的细化关系继承。此外，技巧可以针对解决方案进行改进。项目信息的各种元素支持自然细化关系和沿着各个方向的细化关系继承项目信息。例如，要求项目和熟练的个人可以通过单项细化关系向上继承。
通过提供对已存在问题或解的专业化，针对已存在问题的解，以及由已存在的解引发的问题，可以支持自上而地增广分层结构。反过来，层级可以以自下而上的方式增广。有一个直观的方法来增广代表项目的DAG，这个项目可以隐含地捕捉事实，例如可以针对细化问题的解决方案定义问题的解决方案，并且问题动机可以根据细化的问题动机来定义，我们将称之为相对DAG增广。这样的设施也可以保持协会之间的完善对应关系，以便后续对项目结构的修改可以得到适当的处理。
信息通常可以针对实体之间的非循环双亲关系进行呈现。双亲关系的反面是子代的关系。这里的实体可能是物理的或概念的。通过非循环，我们的意思是，任何实体的关系的一个或多个应用程序链都不会产生相同的实体。例如，这种关系可以表示一个实体或概念占主导地位，包含或引发另一个。作为一些更具体的例子：可以将集合看作是具有更少元素的集合的父代；传统面向对象语言中的接口或类，或基于委托的面向对象语言中的实例与继承有关
结构体；个体(或其基因组的一部分)与其生物学亲本有关；在一个大纲结构中
文件中，文件的任何声明部分都可以看作是其每个细分的父项；a版本文档是开发它们的先前版本的子代。树是一个实体最多只有一个父代的分层结构。更一般地说，有向无环图(DAG)是一个分层结构，其中一个实体可以有任意数量的双亲。对于传统的面向对象的语言，Java程序中的类形成树结构，而Java程序中的接口以及C++和Python程序中的类都支持多继承，从而形成DAG结构。非空树具有单个根节点，没有父节点。非空DAG具有一个或多个根节点，没有双亲。没有子代的节点被称为叶；没有双亲的节点被称为孤儿。多个非空树或DAG分别被称为森林或DAG森林。DAG或树节点的兄弟姐妹是其双亲的其它子代。DAG节点的反兄弟姐妹是其子女的其它双亲。为避免混淆，我们将上下文树中的同胞称为底层DAG和底层树中的反兄弟，作为上下文兄弟。对于本说明的其余部分，我们将仅使用节点树并考虑底层DAG是实体之间的概念关系。
分层结构可能很大，因此观察者很难将其定位于最相关的内容。树可以通过在双亲下方缩进的子节点进行可视化。通过折叠和展开各种节点，有一些标准的和普遍接受的方式专注于树的部分。这些节点可以用表示树的该部分的当前焦点状态的图标来表示，例如打开，关闭或可能是空的文件夹。打开的文件夹可能表示该节点已展开，以便其子节点可见；一个关闭的文件夹，该节点已被折叠，以便其子项被隐藏；一个空的或颠倒的文件夹，该节点表示一个没有子女的实体。我们将打开或关闭节点的上下文或子结构作为适当的标记，以表示与该分层相关的适当焦点。一些实施例可以选择仅支持打开和关闭图标，允许表示没有后代的实体的节点处于打开或关闭状态。
DAG可以被视为其基础图，使得所有边指向相同的总体方向。例如，这用于支持各种版本文件系统演变的可视化的开源工具，包括版本的分支和合并。但是，DAG可能很复杂并且分散注意力以代表视觉。树在概念上比DAG简单，并且可能是在任何时间点DAG中只有一个或几个子树是相关的。通过指定用户可以导航的一个或多个本地节点并且关于它们可以折叠并展开节点，使得任何实体仅仅是一棵树，如同它是树一样，有一种聚焦在DAG中的方式是有用的在任何时间点由可视化中的单个节点表示。树表示的另一个优点是它能够使用常见的习惯用法，例如复制，剪切和粘贴部分DAG。
我们给出了与描述支持导航到本地节点的一些实施例相关的各种定义。以树中的节点为根的完整子树由通过子关系从该节点可到达的所有节点组成；其上下文是从节点到根的路径。类似地，以DAG内的节点为根的完整的subDAG由通过子关系从该节点可达到的所有节点组成；其上下文是以该节点为根的倒置树，并且包含可由父关系的任意数量的应用程序访问的节点。如果我们希望排除本地节点，我们通常认为上下文包含本地节点并引用适当的上下文。完整子树或完整子DAG的子结构是其中包含的所有节点。如果我们希望排除本地节点，我们通常认为子结构包含本地节点并引用适当的子结构。子结构和上下文都构成逻辑树；他们的组件也被称为逻辑。这将它们与它们所代表的基质树区分开来，它们的组分也被称为基质。上下文增长，而下层结构向下增长。基质树总是向下生长。这些定义仅用于说明目的。必须以某种形式明确存在于实施例中的唯一树是由能够探索它们的用户可视化的树。这样的树可以通过适当地缩进节点来创建，放弃所有这些中间表示。
支持树导航并在树内具有本地节点概念的系统通常提供对以该父节点中的一系列节点为根的该子节点的上下文的访问，直到该树的根。例如，操作系统shell(贝壳)可能会在其提示符中显示返回某个指定的根目录或主目录的父目录序列。有一种方法可以将DAG中的subDAG的上下文进行可视化和聚焦，这样任何实体在任何时间点都只能由可视化中的单个节点表示。一种方法是单独显示子结构树和上下文树，两者都向下生长，并且允许将两者作为简单树来操纵，但是这不令人满意，因为它不向用户提供位置实体的位置如现有的子结构和上下文。
HTML非常适合将树表示为嵌套列表，而浏览器对这样的树结构具有标准的可视化方式。其它表示语言(包括JSON)同样非常适合表示树。通过排除不在子树中的任何节点或通向根的路径，显然可以将整棵树内的子树及其上下文表示为具有与完整树相同的根的单个树。若能找到一种方法做以下工作，那会是很有用的：把DAG内subDAG的部分子结构和上下文可视化为单颗树，它可以在诸如HTML之类的底层内呈现的。
此外，考虑到多个subDAG(每个都根植于不同的本地节点)，看到它们呈现以便与共同的祖代和后代的各种连接显现是有用的。
版本控制系统可能是顺序的，因为它们将修订历史记录视为一系列“提交”。这些提交中的每一个都可以包含对相同或各种文件的多个更改。通过识别文件的旧版本和新版本之间的差异来识别文件内的更改。这些改变是一起承担的，虽然以后总是可以将它们拆分成单独的提交，但这不是预期的用途。相反，提交意图是按照与其建立相反的顺序逐个撤消。提交被记录为“diff”结果，用于表明文件的哪一行将被替换为其它行。因此很容易将差异应用于原始文件以使其与修改后的文件一致，反之亦然。将“差异”应用于任一文件的修改版本会更困难，并且此过程可能导致必须由用户解决的冲突。
标准的“差异”文件在某种程度上是随意的，因为可能有多种记录变更的方式到一个文件。在一个极端的例子中，初始文件包含1000条相同的行和修改后的这999行中的任何一行，可以假定任何一行已被删除。如果稍后将diff文件应用于原始文件的修改版本，则差异可能很重要。
此外，标准版本控制中的提交链形式可以在DAG中分割和合并。因此，用户可以建立具有不同更改的并行分支，并分别撤销这些更改。但是每个分支只包含一组更改，并且如果分支最终被合并，我们再次有一个线性序列的提交来处理
有可能在标准版本控制的序列中间更新提交，然后回放后续提交，此过程中可能引发冲突。这种冲突可能很难管理和解决，但若要求以相反于被施加的顺序取销修改，当变更相互独立时限制过分。
有一个具版本控制的分层系统是有用的，它会自然地安排变更，不是在线性序列中，而是在DAG中。
对于数据库记录的冲突性变化，标准做法通常会拒绝除提议的一个变更之外的所有变更。有一个版本控制的分层系统可以维护和组织相互冲突变更的有序解决。
使用继承来支持扩展项目分层结构的方法
包括问题和解决方案空间分离的项目管理实体和关系
实施例基于各种给定的直觉非循环关系构造DAG(可能是树)。对于多种实体，存在自然的细化关系，如下所示：
directlyRefinesProblem(直接改善问题)对于一个问题，从它的一个细化问题，例如，第一个问题的特例。
directlyRefinesSolution(直接优化解决方案)对于一个方案，从其细化解决方案之一，例如，与该解决方案一致的另一解决方案中获得解决方案，但添加更多细节。
directlyRefinesSupportingArgument(直接细化支持论据)从一个支持性论点来看，例如，另一个支持论点与第一个一致，但增加更多细节或采取更强硬的立场。
directlyRefinesOpposingArgument(直接改善反对的论点)对于相反的论点，从其细化的反对论点之一，例如，另一个与第一个相反的反对论点，但增加更多细节或采取更强硬的立场。
directlyRefinesSkill(直接细化技能)对于一项技能，从其炼制技巧之一，即，第一技能的专业化(即，亚专业或小技能)，例如从冠状动脉手术到手术。
directlyRefinesUser(直接优化用户)对于一位用户来说，来自其一位细化用户，例如，组织中的受指导者或下属第一个用户的图表。
实体之间也经常存在自然的跨种类关系，例如:
directlyAddresses(直接处理)从解决方案到问题，要求每个解决方案至少解决一个问题是很自然的(但不是必须的)。
directlyMotivatedBy(直接激励)从问题到激发它的解决方案(问题的解决方案将有助于实现给定的解决方案。
directlySupports(直接支持)从支持它的论证来看问题，解决方案，或支持或反对的论点。
directlyOpposes(直接反对)从一个反对它的观点看问题，解决方案，或支持或反对的论点。
directlyRequiredBy(直接需要)从技能到需要它的解决方案。
directlyProficientInSkill(直接熟练技能)从精通技能的用户到该技能。这种关系下的协会可以用熟练程度进行注释。任何这些关系都可以作为创建DAG结构的基础。
各种实施例可以使用更多或更少的关系，包括这些或任何其它自然非循环关系。这些关系可能是多对多的，或者它们中的任何一个都可能被限制为多对一。如果所有这些关系都受到限制，那么DAG的一般性是不必要的，因为一棵树就足以满足这种关系，尽管几个这样的关系的联合仍然可以是多对多关系。
在一些情况下(特别是后两种情况下)，实施例可能希望基于所述关系或其相反来构建DAG。
在一个跨种的关系如directlyAddresses，directlyMotivatedBy，directlySupports，directlyOpposes，或者directlyRequiredBy，我们将第一个参数称为依赖实体，将第二个参数称为独立实体，其意图是可以通过独立实体的精化链来继承依赖实体。我们将与这种关系相关的独立实体称为该独立实体的对象。
我们使用“细化关系”来指代任何可以支持继承的关系(通常是从属实体的继承，也可能是它们的后代)，从一个完善的独立实体到它的任何炼制实体。我们将在[0435]中看到，作为重述的细化关系也可以支持在该细化关系或另一细化关系下继承细化实体。我们使用“跨种”关系来指代任何非细化关系，而不管相关实体的类型是否实际相同。实施例可以仅支持相同类型的实体之间的一个细化关系，或者多个这样的细化关系。使得只有一对类型的实体(不一定是不同的)之间存在关系的实施例可以假定这些类型的实体之间的所有这种关联都是由于该关系。
然后我们可以生成各种派生关系。我们从派生关系的一些标准技术定义开始：
·我们使用中缀操作符；以指示两个关系的组成，即，使得一对元素是相关的如果存在第三元素使得第一元素通过第一关系与第三元素相关并且第三元素通过第二关系与第二元素相关。如果两者的关系构成不超过一对一关系是一对一的。如果构成的关系是一对多或一对一的关系，组成关系的数量不会超过一对多。如果组成的关系是多对一或一对一，那么关系的构成数量不会超过多对一。关系的组成可能只有当至少有一个关系组成是一对多和多对一，或者至少有一个关系组成是多对多关系时才是多对多关系。
·我们使用后缀运算符Kleenestar(_*)来指示所提供关系(从一种到另一种)的零个或多个应用程序的组合。Kleene明星手术的结果与其论点相同。
·我们使用后缀逆运算符(_-1)来表示与自变量反转的所有箭头的关系关系(对于一种跨种关系，输入和输出种类是相反的)。
以自然的方式扩展这些直接定义的关系是有用的。显然，对于具体化关系：
refinesProblem(具体化问题):＝directlyRefinesProblem*(直接具体化问题)
refinesSolution(具体化解决方案):＝directlyRefinesSolution*(直接具体化解决方案)
refinesSupportingArgument(具体化支持论证):＝directlyRefinesSupportingArgument*(直接具体化支持论证)
refinesOpposingArgument(具体化反对论证):＝directlyRefinesOpposingArgument*(直接具体化反对论证)
refinesSkill(具体化技能):＝directlyRefinesSkill*(直接具体化技能)
refinesUser(具体化用户):＝directlyRefinesUser*(直接具体化用户)
refinedByProblem(由问题具体化):＝refinesProblem-1
refinedBySolution(由解决方案具体化):＝refinesSolution-1
refinedBySupportingArgument(由支持论证具体化):＝refinesSupportingArgument-1
refinedByOpposingArgument(由反对论证具体化):＝refinesOpposingArgument-1
refinedBySkill(由技能具体化):＝refinesSkill-1
refinedByUser(由用户具体化):＝refinesUser-1
在某些情况下，我们可能要求每个依赖实体与一个或多个独立实体相关。例如，我们可能会要求每个解决方案都解决一个或多个问题，或者每个参数支持或反对一个或多个对象。我们不可能要求每个问题都是由一个或多个解决方案激发的，或者每个技能都需要一个或多个项目。在某些情况下，我们可能会要求每个依赖实体与一个独立实体相关。根据实体的种类和所代表的关系，我们可能希望对关系强加各种其它限制。
对于跨种关系，我们从显而易见的开始：
directlyAddresses(直接地址)
Figure GDA0003513598160000311
addresses(地址)
directlyMotivatedBy(直接由激励)
Figure GDA0003513598160000312
motivatedBy(由激励)
directlySupports(直接支持)
Figure GDA0003513598160000313
supports(支持)
directlyOpposes(直接反对)
Figure GDA0003513598160000314
opposes(反对)
directlyRequiredBy(直接由要求)
Figure GDA0003513598160000316
requiredBy(由要求)
然后注意以下继承基础：
addresses；refinedByProblem
Figure GDA0003513598160000315
addresses被一个解求取答案的任何问题也被这个解的具体化求取答案。一个解对由其具体化的解求取答案的任何问题求取答案。
motivatedBy；refinedBySolution
Figure GDA0003513598160000317
motivatedBy任何激发问题的解决方案都会激发问题的具体化。任何解决方案都会激发问题，从而激发它所具体化的问题。
supports；refinedByObject
Figure GDA00035135981600003110
supports参数支持的任何对象也支持参数的具体化。一个参数支持它所具体化的参数所支持的任何对象。
opposes；refinedByObject
Figure GDA0003513598160000318
opposes任何反对论证的对象也会被论证的具体化所反对。一个论点反对任何反对它的论点的对象。
requiredBy；refinedBySolution
Figure GDA0003513598160000319
requiredBy任何需要技能的解决方案都需要技能的概括。任何解决方案所需要的一个技能需要一个技能去把它具体化。
当一个实体对另一个实体细化时，与被细化的实体相关联的从属实体也与细化实体相关联。因此，当用户导航到特定实体时，向他们显示直接依赖它们所细化实体的实体是合理的。我们称这些为继承的实体。例如，“我们如何才能减少贫困？”这个问题可以作为一个根本问题创建，并细化为“我们如何才能减少农村贫困？”以及“我们如何才能减少身体健全的人群的贫困？”“参照图1至图6示出了支持这些动作的实施例。图1是具有按钮的初始Teamifier用户页面(当活跃用户查看他们自己的页面时)以创建新的“挑战”(系统对“问题”使用“挑战”而对“解决方案”使用“方法”)。点击按钮提供(如图2)中的输入字段，供用户输入他们问题的关键部分，例如，他们想要看到的建立。在图3中，字段被填充。在离开输入字段时，将事务发送到服务器，并且如果接收到指示成功的响应，则创建到挑战页面的链接，如图4所示。单击为根问题创建的链接将用户带到该问题的页面，可能会产生细化问题。图5显示了具体化操作的选择以及图6第一个具体化问题的输入：“让我们教会急需技能的人一种技能！”，可能会被添加为解决问题的解决方案，“我们怎么能减少贫困？”，因此解决方案必然也适用于这些细化问题，尽管我们将看到，细化解决方案可能会有所帮助。图7至图9展示了用户如何提出解决方案(两者之后，具体化问题已经创建)。图7示出了求解运算操作的选择，图8为此解决方案的输入，图9显示了创建解决方案后的页面。图10示出了对新解决方案的组件化运算操作的选择。图11“我们如何建立人们已经知道的东西？”作为组件问题的条目。现在，点击其中一个细化解决方案的链接，用户将看到如图12中所示解决方案及其组件作为继承的后代(此处用灰色图标表示)以及作为上下文的一般问题(此处也用灰色图标表示)。同样，一个解决方案，“让我们将货物运送到他们需要的地方！”可以改进为“让潜水艇运输物资！”和“让太空船运输物资！”。“我们如何在运输过程中建立对供应的保护？”可能是解决方案所带来的问题，“让我们将物资运送到需要的地方！”，因此解决这个问题必然会有助于解决那些细化解决方案，尽管正如我们将要看到的，细化问题可能会有所帮助。图13显示了点击第二个解决方案具体化的结果，其中一般问题的组件问题是继承的子节点。
我们进一步注意到继承细化目标对象的以下基础：
refinesSolution；addresses
Figure GDA0003513598160000324
addresses
任何由解决方案解决的问题，也可以由解决方案的细化解决。解决方案解决它所细化的解决方案所解决的任何问题。
refinesProblem；motivatedBy
Figure GDA0003513598160000323
motivatedBy
任何激发问题的解决方案也会激励问题的细化。任何解决方案激发的问题都可以激发它所细化的问题。
refinesSupportingArgument；supports
Figure GDA0003513598160000321
supports
任何由实参支持的目标对象同样支持实参的细化。实参支持任何它所细化的实参支持的对象。
refinesOpposingArgument；opposes
Figure GDA0003513598160000322
opposes
任何实参反对的对象也遭到实参细化的反对。实参反对任何它的细化的反对的目标对象。
refinesSkill-1；requiredBy
Figure GDA0003513598160000331
required
任何需要技能的解决方案也需要技能的泛化。被任何解决方案需要的某种技能都需要一种能对它细化的技能。
可以注意到具体化关系在由一个包括技能要求的解决方案中相反方向起作用。通过对需要该技能的解决方案进行改进，必然需要超级技能而不是技能的副技能。
当用户导航到特定的实体时，我们向他们展示不仅直接依赖于它们细化的实体的实体，还细化依赖实体的实体，而是通过任何一系列直接依赖关系和具体化来依赖的实体。
实施方案基于实体和关系在开发和扩展DAG时协作地支持用户或多个用户。
问题的解决方案可以针对一个或多个具体化问题的解决方案来定义。同样，由解决方案激发的问题可以针对由其激发的一个或多个问题来定义具体化解决方案。对于“让贫困的人们学习技能！”这个例子来解决这个问题：“我们如何建立一个减少贫困的体系？”，“让贫困的人教育我们！”都细化出“让困难的人学习技能！”和直接解决了“我们如何建立减少农村贫困的问题”和“我们如何建立健全的个人之间的贫困减少”这些具体化问题。进一步说，“我们怎样才能确定人们已经能够种植什么农作物？”是“让我们教育有需要的人去耕种！”的一个组成部分，并且专门研究“我们如何建立人们已经知道的东西？”。例如“我们如何在运输过程中建立对供应品的保护？”是一个由解决方案驱动的问题“让我们将供应品运送到需要的地方！”，“我们如何通过不同的压力在运输途中保护供应品条件？“既改善了”我们如何在运输过程中建立对物资的保护？“，并且直接由具体化解决方案”让我们通过潜艇运输物资！“和”让我们用太空船运输物料！“来激励我们。这种增广操作可以由用户明确或隐含地指定。对于第一个例子，图14至图21展示了创建这些项目实体及其结果的用户行为的演示。图14显示了用户发起相互具体化的操作：“我们如何确定减少农村贫困？”和“我们如何建立减少健康人之间的贫困？”。用户选择前者，用绿色边界标记，并从后者开始专业化操作。我们假设用户创建具体化问题并导航到该问题，然后展开上下文。“我们如何确定人们已经知道的东西？”被显示为新问题的继承后代。我们将呈现各种形式的创建跨种型的关联以及一个或多个具体化关联。图15显示了从继承后代开始的专业化操作，隐含地也要求其继承双亲的专业化，“让我们教导有需要的人一种技能”。图16显示了用户在“就教有需要的人一种技能！”到“教有需要的人耕种！”作为该问题的解决方案的就地重申。然后，系统由“我们如何建立人们已经知道的东西？”的用户到“我们如何确定人们已经可以种植什么农作物？”的用户在图17中进行就地重述。如果用户然后导航到新的解决方案并适当地扩展上下文，我们在图20中看到新问题是它的解决方案的组成部分，新解决方案既是它改善的问题的子代，“我们怎么能建立人们已经知道的东西？”以及它的解决方案，“让我们教导有需要的人去耕种！”我们也看到，后一种解决方案既是解决方案的一个子代，“让我们教导有需要的人一种技能！”及其解决的问题，“我们如何才能在健全的个体中减少农村贫困？”。如果用户导航到最初的一般问题：“我们如何建立减少贫困？”并适当扩展子结构，我们在图21中看到解决方案“让我们教导有需要的人一种技能！”仍然存在，就像它的子代一样，“我们如何建立人们已经知道的东西？”，并且每一个都有一个子代的新重述。
图22显示出了数据如何流过实施方案。DOM树仅存在于客户端上，而完整DAG仅存在于服务器上。本地化的DAG由服务器创建以供客户端使用。它包含从客户端导航的一个或多个实体角度来看全DAG信息的子集。所有三个数据存储都基于通过客户端UI生成的用户操作进行维护。
图23显示出了在一个实施方案下客户端与服务器系统之间的交互的可能顺序。可以有任意数量的客户端系统与服务器进行交互，并且客户端或服务器可能分布在许多计算和存储设备上。我们摒弃了任何对传输值的序列化和解集，因为这个要求对于软件开发领域的技术人员来说是熟悉的。客户端可能首先向服务器提交搜索查询。服务器可能会响应零或多个搜索结果，客户端可能会从中选择一个或多个本地实体。或者，客户端可能会浏览整个DAG的表示以选择一个或多个本地实体。这个选择被传送到服务器，服务器通过Localize DAG2200将DAG本地化到这些实体。产生的DAG被发送到客户端，在那里它被设置为由用户使用Present DAG 0100来探索。现在任何时候，服务器都可能通知客户端由其它会话生成的本地DAG实体的更新，可通过网络套接字实现。用户可以选择一个或多个实体，在服务器端重复该处理。或者，用户可以在DAG上执行操纵操作。如果用户增广DAG，除了在其自己的DAG副本(包括用户的可视化)上实现该操作的客户端(通过Client SpecializingDAG Augmentation 2101和Client Cross-kind and Specializing DAG Augmentation2102)之外，父实体ID并将新的实体信息发送给服务器，服务器在服务器的DAG上进行相应的操作(Specializing DAG Augmentation 3201和Specializing Cross-kind DAGAugmentation3202)。增加DAG可能涉及增加继承节点，在这种情况下可能需要CopyInheritance for Specialization 2103。我们在这里假设自上而下的增广，但自下而上可以类似地处理。如果用户删除了DAG删除DAG部分0104的一部分，则应通知服务器该部分，或许通过列举要删除的实体ID。客户端和服务器可以删除这些实体删除实体0204和任何连接关系删除关系0214(继承实体不会被删除)。如果被删除节点的双亲和子代保留在DAG中，则可以通过新建关系Create Relationship 0213。如果用户将子代与他们的双亲UnlinkEntity 0114断开链接，则向服务器通知实体ID及其父实体ID。客户端和服务器可以删除他们自己的DAG删除关系0214副本上的关系(继承的实体不会与其双亲断链)。如果用户将DAG的一部分移动到新的双亲和子代，替换现有的关系，Move DAG Portion 0105，服务器被通知移动的DAG的部分，其旧双亲和子实体ID以及它的新双亲和子代实体ID。客户端和服务器可以删除将DAG的这部分链接到其双亲的关系。删除关系0214并创建将其链接到其新双亲的关系Create Relationship 0213。同样，如果被删除节点的双亲和子代在DAG中保持不变，他们可能会通过新的关系连接起来。这些行动的定义很广泛；一个实施例可以提供其中任何一个的特殊情况。用户可以通过客户端表达任何数量的其它操作；每个都在DAG的客户端和服务器副本上执行。在每种情况下，操作都可以在任何抽象级别传送给服务器；例如，高级操作的分析可能仅发生在客户端上，或者发生在客户端和服务器上。后者重复工作，但可能会降低运输成本并提供更安全的界面。例如，一些实施例可能使每个服务器操作仅创建单个实体或关系，这是底层操作。
项客户端和服务器将被广义解释。客户端和服务器在某些情况下可能是同一台机器。而且，全球DAG可以分为任意数量的服务器系统。作为一种极端情况，每个用户可以托管他们在自己的机器上管理的项目的内容。
通过具体化作显式DAG增广
一些实施例给用户提供全部DAG的全局视图，或它的任何限制版。从这个DAG，他们可以选择他们希望由之延伸DAG的节点。
用户可以选择同样类型的几个实体一起细化。考虑图24中的DAG，圆圈代表独立类型的实体，方块代表从属类型的实体(我们假设这里和下面，为了具体起见但不失一般性，圆圈和方块分别代表问题和解决方案，同样形状之间的链接代表细化，圆圈和方块之间的链接或者代表针对问题的一个解，或者代表受一个解启发的问题，取决于方向)。这里，我们看到问题中的一个“钻石”形细化模式。如果用户一起对节点4和10细化，图29中的DAG是一个可能的结果。
用户可以代之显式地既选择一个独立实体以方案关联延伸，又对任意数量的从属实体细化。例如，用户可以选择一个问题和一组解，从中推导出针对该问题的一个细化解，或者，用户可以选择一个解和一组问题，从中导出受这个解启发得到的细化问题。如果用户对图24中的DAG采取行动，再次细化解节点4和10，并与求解节点5同时进行，图36中的DAG是一个可能的结果。
在这个模型中，没有必要识别不同种类节点和不同关系之间的差别，只是保留这一信息，并将其呈现给用户。
以下各节在讨论的隐式增广也可以用于显式场合。此外，我们将看到，采用基于树视图的DAG，例如在“探索分层结构和其上下文表示一种方法”，这些显式操作可以完全地在子结构中，完全地在上下文中，或在二者中进行，以一种得以强制适当约束的方式。
图42显示不考虑继承的一个实施例的分层结构。该实施例由一个客户端系统，一个服务器系统，以及它们之间的网络连接组成。客户端系统运行一个浏览器，它有一个接口，用户可以通过它浏览或增广DAG。客户端的增广过程应用一般常规来增广一个节点，生成一个证明和触发与服务器的通信。这些的底层是一个操作系统，它控制对系统硬件的使用。服务器运行一个系统数据库管理系统(DBMS)服务器和一个网络服务器。网络服务器协调相对于一个特定的本地节点或客户端使用的多个节点而建立的本地化DAG版本的例程，以及修改DAG的服务器表示的例程。前者利用例程来简化服务器的完整DAG版本。修改DAG的服务器表示的例程和简化服务器DAG对数据库访问的例程，通过数据库管理系统(DBMS)的客户端访问数据库。各种例程使用操作系统，它控制对系统硬件的访问。网络浏览器(客户端)通过超文本传输协议(HTTP)与网络服务器通信，该协议应用传递控制协议(TCP)和互联网协议(IP)传输。
可以假定用户特别关注他们导航节点所表示的实体。这对因各种原因减少DAG的大小很有用。这些包括：只呈现最相关的信息，降低信息传递到一个单独机器的成本，在该机器上探索和增广有可能发生，并减少后续处理可能发生的图的大小。又，在执行该操作时，DAG自然分段为本地节点，它的上下文和它的子结构，那么探索的任何点都可以被呈现为一对树。我们将看到，这种表示对增广操作也是有用的。然而，有可能对于实施例避免简化DAG。这样的实施例仍允许通过一个DAG导航，并且可以对上下文和子结构有等价的概念，基于沿着圆弧趋向和离开轨迹。
给定一个DAG Dag，对任意实体E我们定义DAG〖Dag〗_E^1以区别〖Dag〗_E^1中的只是Dag除开任何节点既不能从Dag中的E达到，又不能从Dag中可以达到E处。
图25显示出自图24的DAG Dag，已经过以节点1为中心的导航简化，即〖Dag〗_1^1，而图32显示以节点1为中心的导航简化，即〖Dag〗_5^1。
通过包括本地节点从Dag获取〖Dag〗_E^1会从试图，并扫描和包括它的祖代和子代。由于许多一对多的关系，必须保持被访问节点的数据结构，以避免多次包括任何常见的子代，如同精通计算机算法艺术的人士所熟悉的。图43显示这个例程。
不一定需要处理整个DAG，它可能是相当大的，特别是如果附加信息同步收集，实施例可以基于深入程度、必需的累积存储或任何其它机制作出限制。若用户表示需要在分层结构中进入更深(从本地化DAG的构建已被搁置的任何节点，请求或者更多子结构，或者更多上下文)，附加的节点可以由服务器获取。在传递到客户端的本地化DAG结构中，信号值可以插入到每颗逻辑树的子代名单(子结构中细化和相关的从属实体，以及上下文中泛化和相关的独立实体)这些名单已被推迟或者，对其信息尚未从服务器检索的实体，在本地化DAG中可能留下不确定的引用。
以下可通过服务器实现，当已达到一个极限值时，对每个节点存储一个延续，在此节点DAG的扫描暂停和把这个延续与URL关联，该客户端可以通过它恢复扫描DAG的那部分。然而许多实施例不喜欢让用户保持这样的延续，可能更喜欢通过由客户端为延续的自由变量提供数值，以恢复DAG的扫描，很可能包括在此该扫描暂停的实体。通过这种方法，为了防止服务器获取所有子代，包括早已位于在客户端的本地化DAG的那些，客户端将需要传递那个信息连同它对附加信息的请求。
不一定对所有应用设定深人程度限制，实施例可以允许它在参数中设定，由客户端请求对实体信息的初始访问。
如果细化关系是多对多，一些实施例中可能希望防止以下情况：直接细化关联在非直接细化关联已经存在之处创建，这可以通过检验细化实体的不同被建议双亲之间的非直接细化做到。其它实施例可以保持这些不变，在防止它们的基础上，需要检验预先设定的细化关联，这可能是昂贵的操作(尤其是如果深入程度极限于当地化时被加在DAG上，如0328所描述)。
作为替代方案，可以允许这些冗余关联形成，但是以后在一个分离的过程中识别并去除它们，或者例如，在Reduce DAG 0210中。我们打算识别并除掉长度为1的一条细化路径，但在相同实体之间还存在较长的细化路径。当我们通过细化的子结构下行，映射每个被研究的细化节点的兄弟到它所包含的细化关联中时，累积地保持关联列表或哈希表就足够了。如果遇到字典中的实体，我们可以安全地因为冗余性去除相应的关联。当然，类似的例程可在扫描上下文时被应用。一个独立的版本示于图44。
多重同时细化
我们从如0319中呈示的一个例子的实施开始。用户再次导航到一个特定的节点，从所得到的子结构或上下文中选择节点(尽管一些实施例可以限制此选择于适当的子结构)，并且，如果可能的话，给出机会来定义一个新节点(和实体)，以所选择的节点(实体)为具体的双亲。又，在节点选择中的精确约束可能取决于该实施例作出的选择，但所选择的节点被认为是同一种类的，并且预期的子女也是同一种类的。为了具体起见，我们下面假定，操作从这些被期待双亲(parentNode)之一开始，但是选择可以用任何方式开始。
经常有很好的理由把每个从属实体与一个突出独立实体相关联，如一个解决方案针对的问题，或者支持或反对意见针对的解决方案。这样做意味着，所导出的关系，如针对(addresses)、支持(supports)或反对(opposes)都是多对一的，例如对一个问题提出了许多解决方案，但每个解决方案只针对一个问题。
如果一个具体关系(例如directlyRefinesSolution)是多对多(从而支持多重继承)，则对之的跨种关系为从属种类(例如，针对[addresses])可以是多对多的，即使它由之生成的给定关系(directlyAddresses)是多对一的，由于具体解决方案可以直接针对不同问题，所有这些都必须通过细化解决方案来针对。
于是出现了这样的附加关注，其中给定的(直接分配)跨种关系是多对一的，而我们要分配给每一个从属实体一个突出独立实体与之联系，取决于由导出的跨种关系(如在0308和0310中)。特别是对否则未(例如通过一个直接跨种关联)分配的从属实体，和用这样的分配细化了的一个从属实体，对独立实体有各种不同的选项。
但是，也有很好的理由用约束来限制这些选项(见0407和计算GLB中的优势，0345)。根据一个跨种关系分配一个从属实体于一个新的独立实体，其中该从属实体对一个或多个现有的从属实体细化，实施例可以要求，对每个被细化的从属实体，独立实体的某个细化祖代，直接通过相同的跨种关系(有直接对象)，与该从属实体的某个细化祖代相联系，这表明新的和一些已存在的跨种关联，细化了一个(例如针对一个被细化问题的被细化的解)。一些实施例可以放松这个约束，之要求每个被细化的从属实体、该从属实体的一些祖代(不一定是细化的)直接以同样的跨种关系联系到(有直接对象)该从属实体的一个祖代(不一定是细化的)。为了考虑这种修改，下面描述的用于核实证明的例程，在保持的约束在某些情况下，检验被提供的任意路径，而不仅是要求细化路径。其它实施例可以更进一步，只要求每个被细化的从属实体与独立实体分享一个祖代。
导航到一个感兴趣的节点(也许是正在细化的从属实体节点的一个祖代)并彻底探索，例如，那些节点的子结构的用户，可能留下子结构甚至上下文树作为对他们意图的有效的可揣度的指南。当分配独立节点于新的从属节点时，实施例能够从这个纪录中受益。对此的替代方法是以subDAG的身份搜索子结构寻找共同的子代，或以subDAG的身份搜索上下文寻找共同的祖代。但除了效率低，这种方法不能令人满意是因为，这样的共同祖代可能根本不存在，或者有几个可供选择。利用树，至少肯定可以在子结构树中对共同祖代有访问权，和在上下文树中对共同子代有访问权，虽然不是反之亦然，而且不一定都要通过必需的细化祖代和子代。不同本地节点的共同祖代可以在上下文中做成显式的，利用在“多重倒置树共同内容的展示”中提出的技术，以及不同本地节点的共同子代可以在子结构中做成显式的，利用在“多重树共同子结构的展示”中提出的技术。于是祖代可以位于或者子结构中，或者上下文中，其目的是满足0337的约束。
我们想要使从属实体尽可能一般地应用，例如，我们想要关联每一个从属实体于一个尽可能一般的独立实体。这样，实施例可以试图关联细化从属实体于单个最细化的独立实体，它是被分配给每个被细化从属实体(即关于用户导航具有最小上界(LUB)的被细化从属实体的对象)的独立实体。事实上，例如解决方案确实在一定程度上，与它们针对的一个问题的任何细化祖代相联系。
考虑例如图24中的DAG。用户导航到节点1后，DAG简化为图25。图27表示用户正在探索节点4和10。如果用户然后用一个新节点13细化节点4和10如图28，对于本实施例所得到的全局DAG将如图29。如果突出的独立的实体被分配(见0334)如像在0339，节点1被分配给新节点13，作为节点3和1的最小上界。如果相反，节点4和8被细化，2将被分配给新节点作为3和6的最小上界节点。
把被细化节点的LUB分配给新的细化节点的实施例，可能难以使用户的知识有所改变，他们专注于本地节点，以决定把哪一个独立实体分配给新的从属实体。当被细化节点的实体对象出现在上下文中时，如果他们希望有利于本地节点，这样做可以有效地分配给新节点本地节点的GLB和被细化节点对象的LUB。
最大下界(GLB)的自然替代方案可以提供更好的匹配于从属实体，并且因此可能被一些实施例看中。LUB计算将因此被推迟到泛化的讨论。例如，我们可能希望每一个解决方案与一个突出的问题相关联，它细化了它解决的任何问题，或者，支持或反对突出对象的每个论点，细化了它针对的任何对象。不幸的是，如[0338]所指出，子结构树对最大下限提供了相当有限的访问权。与继承结合可以提供更通用的解决方案。
使用GLB设置从属实体的间接对象，也导致相应于0341更自然的决定。即是否要拓宽GLB输入到包括本地节点(假设它在上下文中细化正在被细化节点的所有对象)。如果本地节点是一个从属
节点，也可能拓宽GLB输入到包括本地节点的对象。二者任取其一都会彰示用户的导航已经以该位置作为相关性信号的重要性。
用于分配独立实体到给从属实体的如上所述的最大下界，可以通过选择与解决方案相关问题(通过address联系)中最特殊的来实现(例如，在directlyRefinesSolution的情况下)，如果存在一个唯一的(即由address与解决方案相联系的严格地细化了任何其它这样的问题一个问题)，或者通过创建一个，如果基于某个跨种关系(directlyRefinesProblem)而产生的细化关系得到是多对多(通过自动导出公共子代问题，并令细化解决方案直接针对之)。单纯的实施例可以在不同方向检验与被细化从属实体关联的各种不同独立实体，但可能被视为低效的。其它实施例可以多少削减这个成本，通过允许用户在一定程度上选择或创建问题，并让系统确认它事实上确实细化了其它被针对解决的问题，代价是强制用户来处理这种复杂性。这里展示的技术可以降低成本。
我们继续描述独立节点的计算与新的细化从属节点就子结构和上下文树在GLB下的联系。在没有从子结构选择的正在细化的从属节点(所有都来自适当的上下文中)的情况下，强制执行0337的约束的实施例可以保险地把LUB(在倒置上下文树中，应用关于树0101计算LUB得到)分配给它们的对象，如果LUB对新的细化节点存在的话，否则失败。但优选的实施例可以跳过这个步骤而简单地使用本地节点，按照0343。或在任何正在细化的从属节点选自子结构的情况，如果它们在子结构树有一个GLB，强制执行0337约束的实施例，可以保险地分配GLB的对象给新的细化节点。在正在细化的从属节点有相同对象的情况下，实施例可以分配该对象到新的细化节点(这个步骤可以提高效率，但也可能被忽略而如下所述)。否则(或对于更喜欢直接进入这一做法的实施例)，它们可以依赖于子结构或上下文树中正被细化的从属节点的对象的存在，并在其中检验一个GLB，使用Calculate GLB wrtSubstructure and Context Trees 1111计算GLB方法。关于子结构和上下文树1111计算细化节点对象GLB的显式3121示于图46。实施例可以替代之检验是否所有细化节点并翻转枝干。这样做是正确的；但如果只有来自合适上下文的位置和节点被细化则效率稍低。
Calculate GLB wrt Substructure and Context Trees 1111假定其输入到达一个节点列表，并首先确认所有成员或在子结构或在上下文，否则失败。若任何节点都在子结构中，客户端关于子结构树计算那些GLB，采用Calculate GLB wrt a Tree 0111，并忽略在适当上下文的那些。当所有节点都在上下文树(我们尚未颠倒而使用位置)，这需要取它们自己的LUB关于颠倒的上下文树，使用“关于树0101计算LUB”。一些实施例可能当立即失败时上面所指出的，试图在DAGs中通过其它手段寻找GLB，例如更详尽的搜索。
我们现在展示关于单一树(子结构或上下文)计算LUB或GLB的基本例程。在每一种情况下，我们只考虑细化路径！LUB可以通过考虑从每个节点(从左到右)朝向本地节点细化路径实现，并取该实体为这些路径的共同后段的最左边节点所代表。该算法示于图48中。GLB可以通过考虑从每个节点朝向(从左到右)本地节点的细化路径实现，并检验所有这些路径以最长的这样的路径为后段——最大下界是最长路径的最左节点。该算法示于图49。
示例中在GLB下被分配给新节点13的独立节点是3。
虽然使用这种算法的客户可以得到独立实体到从属实体的合理分配，取决于实体，服务器可能不愿意相信所有客户都遵循这些规则(有些人可能使用不受支持的代码)，因此可能期望核实，例如，正在具体化的每个实体的对象本身被被新节点提供的对象具体化(现在所有这样的对象声称的GLB)，即新节点的对象至少是被细化节点对象的下界。但这种对细化关联链的检验被认为是低效的。因此，服务器可能需要以下形式的援助，一条与细化相联系的实体的链(为了具体起见，我们假定从最专门的到最不专门的)，从新节点的对象，到正在具体化的从属实体的对象，在确立每个从新的细化节点
到已存在节点的关联之前。当然，序列中的次序系按约定俗成。这样的链可以使用项目结构基于树的叙述提供。对于每个正在细化的节点，客户可以建立基于一个或几个案例的路径。对于这两种GLB和子结构中正在细化的节点的对象，客户端由GLB跟踪路径向上，追随细化过程，通过子结构树向上直到到达实体的对象正被细化的一个节点。对于子结构和上下文树中正被细化的节点对象的GLB，我们可以采取提到的路径直达轨迹，然后把从对象节点开始，通过倒置上下文树的路径的反向联系在一起。不是隐式包括GLB计算中本地节点(如0342中描述)的实施例，可以添加一个对上下文中的GLB(和目标节点)，并在这种情况下使用开始于对象节点，下降通过倒置上下文树路径的反向，直至到达GLB。
由与对象节点开始和虽然直到上下文中获取的路径的反向。没有这种附加的情况下的证明生成过程的一个实施例示于图50，应用图59的Generate Proof Path 0113。在我们的例子中，如果用户细化节点是4和10，为该实施例的证明将组成如下，对于4，从GLB的一个空路径，3，到它本身，对象4；而对10，路径[2，1]从GLB，3，到1，对象10。注意按照惯例，我们处理初始节点(分别为3和1)为隐式的和不包括它们在路径中。该客户端可能无法建立从属于子结构和上下文树的当前状态的正确核实。
将这些碎片拼合一起，客户端可以使用Calculate GLB wrt a Tree 0111来生成一个单个新节点作为现有节点的细化。图45描述了以下情况的序列，其中每个从属实体被分配一个独立实体的对象，作为相对于正在细化的节点对象的子结构和上下文的GLB。首先，对于正在被细化的每个节点，识别由它的对象出发，经过子结构或上下文朝向本地节点相联系的节点序列(隐式包括GLB中本地节点的实施例可能限制自身于子结构)。这可以使用当前子结构或上下文树或来自先前子结构或上下文树保存的任何路径完成。也有可能使用一条本地子结构或上下文DAG的路径，但多于一个这样的路径也是有可能的。然后，计算细化节点对象的GLB如图46。在该GLB不存在的情况下，失败和提供一条错误消息。使用GLB及其细化路径生成服务器的证明如图50。同时，提示用户存储新实体的信息。然后访问服务器请求增广操作，发送证明。如果失败，清理已部分创建的节点。否则，更新客户端信息包括新实体(创建新实体的记录，包括用户输入的数据及其对象，并更新正在细化的节点实体的记录，包括作为附加子代的新实体)。服务器返回数据库新实体的标识符，它可以由客户端使用，例如对新节点建立一个URL。
每个从属实体被分配到一个对象的验证核实过程(Validate Proof forSpecializing DAG Augmentation with Indirect Objects 3211)如图51。服务器可以确认，对每个正在被细化的实体，给定的路径实际上是一条细化链，始于提供的新的细化实体的对象(一般是细化实体的GLB)，结束于正在被细化实体的一个对象。它遵循通过全局DAG提供的路径，核实每一步都是一个细化。
即使只有直接对象与从属实体被存储，客户端可能有时仍可以访问一个间接对象，如果它在子结构中每个细化节点以上，或如果它在上下文中，则需要较多的努力。虽然一般说来无需计算细化节点对象的GLB，与产生证明相关的从这些对象导出路径的第一步，仍然可以通过追随以下路径来完成，从每个被细化节点到轨迹，搜寻一个直接对象。在这种更一般情况下的证明，可能既需要如前一样识别独立实体的链，也需要识别导致其双亲是独立实体(对象)的从属实体的链。针对这一情况的证明生成过程，“对只带直接对象的显式具体化DAG增广证明生成1151”如图52。针对这种情况的证明核实过程，“对只带直接接对象的具体化DAG增广的核实证明3221”如图53。服务器可以对每个正在细化的实体确认，给定的独立路径实际上是一条细化的链，从被提供的新的细化实体对象(一般地，被细化实体对象的GLB)开始，以已被细化的实体结束，最后，声称的细化实体的直接对象是真实的。
当一个突出的独立实体被分配给每个从属实体时，存储对那个被分配的实体连同从属实体(或一个补白，如果我们在那里选择推断所分配的独立实体用于细化，如在[0365])的一个参照是合理的，这使得跨种关联无需直接表示。否则，可能希望直接表示这样的关联，例如一对实体。在无论哪种情况下，实施例可以选择记录不仅是对独立实体的参考，并有对应于细化关联的证据，以相同的形式如上述(和下述)的证明。其优点是，如果从属实体的细化关联消失，就可以使细化实体之间的跨种关联消失。
带多重同时细化的单一跨种增广
我们现在转向如0320所示的实施例。用户导航到一个特定节点，从导致的子结构或上下文中选择节点，并从一个特别的父节点(基节点)发起跨种操作。如果可能的话，用户将有机会定义一个新的节点(和实体)，连同所选择的节点(实体)作为细化双亲，以及在基节点的实体作为相关关系下的双亲(独立实体)。对节点选择的精确约束可以取决于实施例做出的选择如以下所示。一般情况下，我们假设选择的节点是同一种类的，预期的子代也是该种类，或者至少是一致的种类。实施例，特别是那些隐式地包括在GLB的当地节点计算的(如在0343中所述)，可能需要基节点在子结构中和选择的细化双亲在适当的子结构上。
现在，因为实施例分配一个独立实体到每个从属实体，我们自己无需做这一选择，我们的好处是有来自用户的指示。但是，许多实施例可能仍然希望加上来自0337的约束。
我们现在希望展示一条路径，从该新节点的对象(并不一定是GLB)到每个被定义节点的对象。有关被细化节点的被细化节点对象的GLB与被增广独立节点(基节点)之间的联系，出现了几个问题。如果基节点对被细化节点对象的GLB细化，我们保证有一条从基节点到每个被细化节点对象的路径，满足0337的约束。反之若没有这样的证据，我们有违反约束的风险。且如果基节点被细化但不等于被细化节点对象的GLB，我们不能设置新对象指向基节点而不造成这样的情况，细化实际上与请求方向相向而行。举一个例子来帮助理解这一点。图54表示在问题节点51导航的一个DAG，如果一个用户要用把解决方案54节点具体化的一个新的解决方案节点55，解决其子代问题节点52，其中52是53的双亲，被精化节点54的对象的平凡GLB，情况将如图55。梯形压扁为一个矩形，很容易看到这两个细化在相反的方向运行。但为了某种目的，可能想要这种逆变关系来代替协变。可以选择实施协变约束的实施例，在该情况基节点不能被看作细化被细化节点对象的GLB，要么处理这种情况作为一个简单的细化或认为这是一个用户错误。其它实施例可无视以上情况而允许操作。为了强制约束，GLB计算可以如前一样地进行，但把其结果相对于基节点比较。
识别子结构或上下文中两个节点之间路径的例程如图59。请注意，我们在这里指的是寻找refiningNode和refinedNode之间的路径；这些名字在这里，并无其它用途，尤其是这些节点被用户具体化或泛化。如果refiningNode在适当的上下文和refinedNode在适当的子结构，则立即失败。如果refiningNode和refinedNode二者都在子结构中，遵循从refiningNode朝向本地的细化路径，直至到达refinedNode。如果refinedNode被找到，返回路径，否则失败。如果refiningNode和refinedNode均在上下文中，遵循从refiningNode朝向本地的反向细化路径，直至到达refinedNode。如果refinedNode被找到，返回路径的反向，否则失败。最后，如果refinedNode在上下文中和refiningNode在子结构中，把从refiningNode朝向本地的细化路径与从refiningNode朝向本地的反向细化路径的反向联系起来，失败如果两个都没有达到本地。这里要注意，一个实施例可避免检验第一种情况而只要求refinedNode处于子结构作为第二种情况，且只有refiningNode在上下文中的第三种情况，让失败发生在处理过程中。我们显示Generate Proof Path 0113为单个例程，但一些实施例可以做出假设，在某些情况下减少案例的数量。
如果基节点与正在细化节点对象的GLB相同，它是冗余的和实施例可以考虑选择这样的增广作为简单的细化。
在每个从属实体与一个独立实体关联，且0337的约束被强制执行之处，我们可以应用0349和0351描述的机制证明。一种优化可获得，因为在基节点和GLB之间现在有一个区别(对隐式GLB与本地实体也是如此)。因为所有细化路径分享从基节点到被细化节点对象GLB的一个公共前段，该前段可以被分离，使得它只需要被产生和核实一次。然后，为了得到从基节点到细化节点对象的一条路径，我们把前段与独立路径联系在一起。这种形式的生成和证明由Generate Proof for Explicit Cross-kind and Specializing DAGAugmentation with Indirect Objects 1112，使用Generate Proof Path 0113，示于图57。它们的核实用Validate Proof for Cross-kind and Specializing DAGAugmentation with Indirect Objects 3212，示于图60。
相反，如果directlyAddresses(0335中的例子)是多到多或实施例无意把它延伸至多到一的addresses，并因此不分配给从属实体对象如0334，它们可能仍然想要区分与address联系的问题的一个子集，足以通过应用refinesProblem达到其它的。即使不区别任何独立实体，实施例可以允许指定这种“受尊重的”关联，例如，允许在一个从属实体(B)和一个独立实体(A)之间形成跨种关系关联，使得(B)细化另一个从属实体，它与一个被(A)细化的独立实体关联。特别是，它们可以允许通过directlyAddresses的关联，以利用另一个这样的关联，使得第一个解决方案和问题分别细化第二个的。同样，它们可以允许通过directlyMotivatedBy的关联来利用另一个这样的关联，使得第一个解决方案和问题分别细化第二个的。此外，它们还可以要求，任何跨种关系只允许从属实体细化另一个实体，如果从属实体的一些细化祖代与独立实体的细化祖代相联系。使用验证的上述方法可以支持受限制形式的这样的要求，它把从属节点的对象考虑为在趋向本地节点路径上的细化关联之后，第一个遇到的跨种关联的独立实体。
在这种情况下，除了0359，对0349的验证核实的另一种修改是有用的。验证现在采取从基节点到GLB的预定路径的形式，并且，对于每个被细化的从属实体，有两条细化路径：一条始于从属实体和另一条始于GLB，每个都终止于又由相同跨种关系关联的实体。独立路径的计算又使用图59。对子结构中的细化节点，从属路径只是朝向本地节点的细化链。验证生成过程如图58。对0320的例子，对实施例的验证有两对路径，每个节点被细化(如果间接对象可以获得，只需要提供独立的(问题)路径)。在这里的每种情况下，追随从细化解决方案节点分层朝向本地节点，并在以下对象问题停止，它产生一对细化问题/解决方案，相应于由当前操作创建的一对新的问题/解决方案。对于节点4，对于本实施例的从属路径为空，因为它直接与从属节点3联结(它们之间没有细化解决方案)，和对于本实施例的独立路径将是[3]，因为由新节点16的对象5到达对象4只需要一步。对节点10，从属路径对于本实施例又是空的，因为它直接与独立节点1关联，和对本实施例的从属路径将是[6，2，1]，因为追随这些节点从新节点16的对象5导向10的对象1。请注意，按照惯例我们把初始节点作为隐式的，不包括它们在路径中。
处理单一跨种具体化DAG增广的步骤类似于那些Calculate GLB wrt a Tree0111如图45。它们的区别在于使用旨在支持跨种和具体化增广的上述例程，包括GenerateProof for Explicit Cross-kind and Specializing DAG Augmentation with IndirectObjects 1112，Specializing DAG Augmentation with Direct Objects Only 1132，和Specializing Cross-kind DAG Augmentation 3202，以及添加一步转化为相应的细化操作(例如正在被具体化的那些节点)，如果GLB(用图46计算得到)与基节点相同。由于潜在的转换，我们包括了Generate Proof for Explicit Specializing DAG Augmentation withIndirect Objects1131和Specializing DAG Augmentation 3201于潜在步骤中。该例程示于图56。
只有直接对象的验证核实过程如图61。服务器可以确认每个实体正在细化，独立的路径开始于提供的新细化实体的对象至实体的一个对象，对之开始于该正在细化的实体的从属路径引导至。
我们强调，虽然任何种类的实施例可能需要如上规定的验证，其它的可能用其它方式进行验证，或者完全予以忽略。
注意如0362所述，一些实施例可以仅使用形式细化操作，若分配的独立实体，其实就是GLB。这样，从属实体的细化可能关联一个独立实体，它基于正在细化从属实体的关联(的GLB)。我们可以选择或者存储这个独立实体连同从属实体，或者当需要时计算它。如果是显式存储，该信息是立即可用的，但必须在各种实施例下保持作为独立实体节点，添加或移除细化关联。
利用继承实现具体化
利用结构中根植于一个从属节点，经过独立节点的一条细化链，继承实施例可以得到许多好处。这样的结构可以在有可能相关处呈现给用户。用户不仅可以查看这样的继承结构，还可以增广它，并在这样做时仍然专注于他们目前的导航状态。
图62是图42支持继承的实施例的另一个版本。客户端增广过程包括编排继承节点复制的高分层例程(Client Specializing DAG Augmentation 2101和Client Cross-kindand Specializing DAG Augmentation 2102)以及复制通过一个节点的祖代的继承路径的一个例程。服务器的初始化过程引入了一个高分层例程Localize DAG 2200它应用了Reduce DAG0210和新例程Inherit Structure 2230，它又使用了新例程CollectInheritance 2240和Inherit Structure 2230，从用户的上下文中收集准备继承的节点，并把这些分别纳入本地化DAG中。
利用继承于DAG探索
一些实施例允许继承的从属实体出现在本地节点的子结构。继承结构实际上可能是subDAGs，而那些继承结构可以通过任何关联与子结构中的当地(非继承)节点相连接。这样继承以后，得到的DAG可以作为一棵树继续探索。
图63展示了例程Localize DAG 2200它首先应用Reduce DAG 0210把DAG简化为仅包括某些节点和它们的子结构及上下文和然后，来自上下文的继承结构，应用InheritStructure 2230。
一个特别的实施例应用对DAG的进一步修改。〖Dag〗_E^2与〖Dag〗_E^1的不同只在于包括了被E继承的E实体的子代，例如一个实体，它从属于被E细化的一个实体。
图26显示来自图25的DAG Dag。其结构包括继承节点9，11，12和15，即〖Dag〗_1^2。图33显示来自图32的DAG Dag。其结构包括继承节点4，7，8，9，10，11，12和15，即〖Dag〗_5^2。图26从10到1的链接已被剪掉，如下面0375末尾所建议的。
接下来我们考虑从〖Dag〗_E^1获得〖Dag〗_E^2。对于本地节点，调用CollectInheritance 2240和然后Record Inheritance 2250对每个inheritedEntity，设置parentId于entityID。图64展示这个例程的一般结构。例如，如果本地节点是一个问题，我们可以收集和记录由本地问题细化的问题的解决方案。需要注意的是，虽然InheritStructure2230可用于所有种间关系，实施例可以对发生继承的每个关系创建一个独立版本。
直观地，Collect Inheritance 2240应该只对继承收集最一般的(细化)继承实体，因为更专门的那些，会在记录那些实体的可继承子代的过程中被计入。我们对CollectInheritance 2240和Record Inheritance 2250的最初实施就是基于这种直观方法。
Collect Inheritance 2240扫描实体的细化祖代。这包括避免重复计算任何共同祖代。扫描时，我们收集如0308定义的可继承实体并保持它们可以到达的最近的根。这涉及检视每个遇到的可继承实体，是否细化一个已经被收集到的，反之亦然。注意如所描述的，当一个继承的实体被另一个继承的实体包含(即，出现在关系的左边，而其它继承实体在右边)，该算法包括二者(通过由Collect Inheritance 2240返回的包含实体)。一些实施例可以选择只包括这种情况下的实体(由Collect Inheritance 2240返回该被包含的实体)，因为包含的继承的实体可能往往显得无关紧要。这可以通过保持继承的实体的叶而不是根来实现。原方法的优势是，它保留了从细化实体推导新的替代物的可能性。图65示出这个例程。注意用某些约束，我们可以替代以上被包含/包含实体为细化/被细化实体。
Record Inheritance 2250涉及将收集到的继承的实体和它们的子代结合到〖Dag〗_E^2中，但这一过程必须终止对任何已经在〖Dag〗_E^1中的任何子代终止。recordInheritance开始于通过加入继承的节点作为接收实体的子代。取决于inheritedEntity是否已经在〖Dag〗_E^2中或第一次遇到，有不同的案例。如果第一次遇到，我们把它添加到〖Dag〗_E^2中，在其双亲之下，重现于它的子代们。否则，我们把这对双亲添加到〖Dag〗_E^2中。如上所述，本过程可能留下本地节点的直接子代于适当的位置，即使他们可从继承的节点达到。优先实施例可以分割出这样的节点，以使它们只能通过经由继承的节点的较长路径达到。图66显示这一例程。
在技巧要求正在通过解决方案细化被继承的情况下，Record Inheritance 2250成为平凡的。这是因为，如在0311所描述的，当解决方案的细化需要技巧时，需要的是高超技巧而不是次级技巧。但Record Inheritance 2250跟踪历经次级技巧，因此是没有必要的。被一个解决方案继承的技巧简单地被作为孤儿继承节点附加其中。在同一DAG中展示一个次级技巧分层作为计划分层，对加深我们的理解并无多大帮助。
检验节点是否相互细化可能是低效的，幸运的是直觉算法可以用几种方式改进来避免这些检验。在每一种这样的改进算法中，我们不要求Collect Inheritance 2240来筛选最一般的继承实体，而是由它返回所有可直接继承的实体。我们确实用它来处理这类实体的排序，以便Record Inheritance 2250可以加工它们，或者最一般的首先，或者最专门的首先。
在图67我们展示了Collect Inheritance 2240的一个版本，以确保序列中列出的可继承项，与它们从本地节点出发的细化路径上节点的位置一致，例如，更专门的在更一般的之前。用递归编程语言，这可以用前序树遍历实现。例如我们可以期待RecordInheritance2250包括这些浅层实体的可继承子代，然后包括深层实体的可继承子代。一些较前的子代可能被包含在较后的子代中。这种已经形成的节点，应该被处理为犹如任何遇到的节点，完全没有继承而只是原子结构的一部分。因此，Record Inheritance 2250可以应用而无需变动。
但是我们甚至可以做得更好。通过记录可继承的(翻转Collect Inheritance2240最浅首先版本的输出，或插入到继承实体与列表的开头而不是末尾(图68中)，实施例可以完全避免Record Inheritance 2250过程如果可继承实体是已知的，已经被用更递增的方式记录而可以达到。事实上，不同的实施例中必须检验这种情况，以避免调用RecordInheritance2250于较浅的实体生成多余的链接，因为它们在记录较深实体的过程中已被添加到subDAG。Record Inheritance 2250然后也被修改(如图70)，以等待直到正好在重现于每个子代之前，来检验节点在subDAG上的存在。这也可以用递归语言来实现(图69)，作为后序树遍历插入在列表的末尾，如图67。
对于扫描本地节点的上下文生成subDAG的实施例，另一种可能的优化可以利用这一事实的优点，同时收集可继承的。
对于包括重述细化的实施例，我们更喜欢最浅-首先版本，因为重述可以加入到subDAG中，同时给予机会避免添加重述实体。如果更深分层的实体首先记录，且它被另一个继承实体重述，前者将需要从subDAG中除去。
即使当可继承者被记录在前序中(未对细化过滤)，如果继承的跨种关系是多对多，有可能通过多条细化路径达到同一个可继承实体。在这种情况下，上述检验可能仍然起作用，以防止重复记录，但更有效地，实施例可以返回可继承的作为一组(使得我们在插入Collect Inheritance 2240之前，通过检验会员资格而防止重复)。
对于一些实施例，在技术上无需检验被记录的第一个可继承实体是否已经在subDAG中(其实不会)。对那些精于软件技术发展的人员，如何调整过程以避免首次检验应该是很清楚的。
图27和图37示出对图26这样的树，前者探索节点4和10，后者探索节点12和15。图34示出了探索节点4和8之后，对图33这样的树。
如在0328所述，一些实施例可能希望对DAG的一些部分提供延迟的访问。这样的实施例可能把上述各例程并入两个例程，一个用于上下文和另一个一个用于子结构，通过如同砍伐森林的技术，如那些精通软件工程的本领域的在熟悉本领域技术人员所做的。在这种情况下，并非所有继承节点都将立即可为用户获得。当一个用户试图从本地的细化祖代——对之(和细化祖代和有联系的独立节点)的继承收集被延迟进一步探索上下文，附加继承节点(包括直接继承和它们的子代)可被记录在客户端的本地化DAG，大体上如同在Record Inheritance 2250中描述的对服务器的步骤。用户也可以被提供“更多”链接，如在[0708]所描述，以指明有附加继承节点可用，并且如果被激活，触发加载附加节点及其继承到本地DAG。
利用继承和树视图于DAG增广
用户可以增广表示项目信息的DAG。DAG(与树不同)结构可能是因为：多对多细化关系(多重继承)；跨种关系，其中从属实体也细化一个或多个现有从属实体；或一种跨种关系是多对多。每一种都有自己的挑战和机遇。
如果用户已导航到被增广节点上下文中的一个节点，用户可以显式地选择那些节点，其方式与上述显式DAG增广并无不同。在其它情况下，有可能在增广过程在利用继承。
再次考虑图24的DAG。用户导航到节点5后，DAG局部化于图33。图34示出用户探索节点4和8，节点4和7现在继承到节点5，而节点8细化7。如果然后用户用新节点14细化节点4和8，如图35，所产生的全局DAG对这个实施例将如图36。对于本实施例，新节点14将不仅细化节点4和8，还隐式地与本地节点5通过跨种关系(例如解决一个问题)关联。因为5是3(4的对象)和6(8的对象)的GLB，实施例可以选择认为这是一个细化。但如果用户已经导航至节点5的细化子代和执行相同的操作，它显然被记录为直接跨种关联。注意，仅通过表达对节点5的兴趣，用户通过继承可以立即访问那些节点，它们可以被扩展，以便与该节点相联系，而不是被限制于以下事实：节点5只是3和6在全局DAG的GLB，而并不关于任何子树。
利用继承和树视图于多重同时细化
对于一些实施例，当用户选择多个节点细化时，出现多重同时细化的标示，并非所有这些都是同样种类的继承跨种关联，而是可以有所不同，或者至少一个被细化节点是子结构的一部分。(我们这里所说的“跨种关联”，更可以简单地说是“节点”，因为多重跨种关系可以共享相同的附属种类。)我们将看到，如果所有被选择进行细化的节点，都是同样跨种关联的继承，我们更愿意把这个操作视为一个相似的跨种增广。
现在我们可以假定，不细化一个直接继承的节点的继承的节点，不能被选择用于细化，但是对实现迭代增广的实施例，这可能有所不同。
再次考虑图26中带继承节点的局部DAG。如果被突出的独立实体细化的节点4和10正在被分配如0342，节点3现在被分配给新的节点，如最大下界节点3和1。类似地，如果节点8(通过7)和10被细化和突出独立的实体正在被分配如[0342]，节点6被分配给新的节点，作为节点6和1的最大下界。如果节点4和8被细化，实施例可能失败，可以搜索子结构，寻找是否存在一个唯一的最大下界(这里是节点5)，如果不存在，创建一个，或如果存在多个，允许选择一个。失败不是一个坏的选择，因为如下所述，用户可以导航到他们喜欢作为下界的节点来完成这个行动。
同样，隐式包括GLB计算中本地节点的实施例(如在0342中)，当继承存在时，可以不包括来自计算的任何继承节点的对象，因为被分配给它们的独立实体，将是本地节点的细化祖代，从而由被分配给代表非继承节点的实体的独立节点细化。如果所有的被细化实体都是继承的(且它们细化直接继承的实体)，更受欢迎的实施例可以把本地节点与细化从属节点相联系，但其它人也许会选择包括该情况下计算中的继承节点，应用上述LUB算法选择上下文中的一个节点(由于上下文分层被反转)。
再者，服务器可能希望核实客户端请求的细化操作，那里一个间接对象被设置为当请求时可用于任何新的从属实体、每个被细化的从属实体、被细化联系的实体从最大下界到该从属实体的对象的一条链(为了具体起见，我们假定从最特殊的到最不特殊的)。我们以前看到，这样的链可以由客户端基于项目结构阐述的树来生成。但如果被细化节点的对象在上下文DAG中，它必须在上下文树中披露，以便产生必要的细化链。如果被细化节点是继承的，它可以利用继承机制和项目结构基于树的阐述，生成必要的细化链为一条路径，对非继承的节点为从最大下限向上通过子结构树，只要它跟踪细化关联，直至到达正在被细化节点的对象，或者对继承的节点，取这条路径朝向本地节点，然后，当路径到达本地时，把它与通过全局DAG的路径相联系，在此正被细化的节点是继承的。修改后的验证生成过程如图74，应用图76中Generate Single Independent Path of Proof for SpecializingDAG Augmentation 2113。在来自0388的我们的例中，如果用户细化节点是4和8，对于本实施例验证将包括，对于4，继承路径[3]，和对于8，继承路径[6](初始节点5在此按照惯例假定为隐式的)。如果用户已经导航到节点1和被细化节点4和11，验证将包括，对4，空路径(从GLB，3到自身，4的对象)；和对11，路径[2,1，0]，作为来自GLB 3的路径通过子结构至1，跟随着继承路径0(初始节点3按照惯例再次假定是隐式的)而得到。
客户端如何得到这样的继承路径呢？可以由服务器在Collect Inheritance 2240中导出并传递到客户端，连同本地化DAG，以便于跟踪，并最终返回服务器。我们示出Collect Inheritance 2240的一个版本，它收集图71中的继承路径。它在保持一条继承路径上与图68的不同，在进一步扩展中延伸到上下文后撤回。
作为一种优化，实施例可以选择，不采用由直接可继承实体到路径的直接映射，而采用映射的组合，首先由直接可继承实体到它们被继承的独立实体，其次从那些独立实体到来自本地的路径。
验证核实过程示如图51。服务器可以确认，对每一个正在实体被细化的实体，给定的路径实际上是一条细化链，开始于新的细化实体所提供的对象(通常是被细化实体对象的GLB)，结束于正被细化实体的对象。
称带有指定的源节点和汇节点的DAG为一个“流”。对精通软件开发的人员，一个DAG或一般图的表示，为了这个目的是可以接受的，虽然具体化的表示是可能的，包括在“探索上下文及有关的分层结构和表示的一种方法”中建议的。虽然只有一条继承路径需要其增广核实，一个提升可以是，替代继承路径发送给客户端一个继承流，使得在一个节点可能被几条继承路径中的任一条继承的情况，客户端可以保持，和服务器收到的不只是一条任意的这样的路径，而是这些路径的流。其优点是，如果许多但并非所有这样的路径被删除节点破坏，细化操作可以有最好的成功机会。
这种方法需要Collect Inheritance 2240返回带有每个被收集实体的流，而不仅仅是一条路径。对每个独立节点，存储从继承的实体至它们可以到达的流的一个映射。对每个细化实体递归以得到这样的映射(如果不是已经访问过)，然后将当前节点添加到每个映射的每个流的前面(例如创建一个有新的开始节点的流，它指向老的开始节点)。如果到达一个实体不止一次，对以后的次数无需进一步递归，但需要展开添加一个不同的新的前方节点。加工所有细化实体后，合并它们各自的映射(例如，创建一个新的映射，其域是对每个细化实体映射域的并，并且对于出现多于一次的任何实体，合并其流)。合并具有相同的开始和结束节点的流，使用标准的图表示，简单地取实体集的并和边界的并。该方法显示在图72中，仍然应用inheritancePath对一个堆栈建模。0395中描述的优化，在这里也适用。在图76的Generate Single Independent Path of Proof for Specializing DAGAugmentation2113，包含在验证中的独立节点的路径然后要么取节点的序列(路径到本地节点)的形式，要么取一个可能是空的表示继承路径的流，或者这两个元件可以被组合成单个流。图51的Validate Proof for Specializing DAG Augmentation with IndirectObjects 3211，很容易然后地修改为尝试替代路径，而不是当通过给定流的第一条路径不成功时立即失败。
包括继承，用于处理单个具体化DAG增广的步骤如图73。它与0350中CalculateGLB wrt a Tree 0111的不同点在于应用图74和图78例程的继承-察觉版本，如上所述。隐式包括GLB中本地节点的实施例，可以完全避免对继承细化节点的处理，因为它们的对象可以在上下文中。那里本地节点对一个被细化节点的所有对象细化，且所有被细化节点都是继承的，一些实施例可以隐式地包括本地节点于GLB操作中，把细化操作转换为以本地节点作为基准节点的一个跨种操作。我们将看到的迭代复制或被细化节点重述可以提供更可靠的解决方案。
对于只有直接对象可获得的实施例和实体种类中，生成进程的验证(对于仅有直接对象具体化DAG增广的生成验证2121)，由图52修改为应用图76的Generate SingleIndependent Path of Proof for Specializing DAG Augmentation 2113来处理继承，如图75。
利用继承和树视图于单个跨种增广连同多重同时细化
许多实施例利用继承，既减少用户的认知负担，又减少DAG增广对系统的要求。如果用户导航到细化最多的独立节点，把它作为本地，对于一些实施例，作为继承的节点他们将只看到可用来选择细化的各种从属节点，使得本地节点代表了对新创建的细化从属实体的突出独立实体。
更一般地，对于一些实施例，跨种增广被标示，当用户选择一个节点作这种增广，或当他们选择节点来细化，所有这些都继承了同样种类的跨种关联。对于从属实体也细化了一个或多个现有从属实体的跨种关系，有几点考量。
首先是使创建这样的关联成为直观的和自然的。我们已经看到，对一个或多个现有的从属实体，定义一个从属实体是适当的，例如对一个或多个细化问题解决方案的一个解决方案，或者对一个或多个被细化解决方案启发的问题的一个问题，且在这些情况下，可以让用户手动选择延伸哪些实体和细化哪些实体。但许多实施例取决于认知：这样的关联可以直觉地通过细化一个从属继承实体而形成。这种技术可以延伸到细化不只对一个直接继承的节点，也对该节点的任何继承子代。
可以演绎简单地细化任何显式选择的被本地节点继承的从属节点(这里的从属关系是直接的)，因为用户已经导航到一个特定的本地节点，创建了一个新的从属节点，它不仅细化了由所选择的继承从属节点表示的实体，也形成了与本地实体(作为独立节点)的直接跨种关联。
本段和以下部分，提供创建这样细化的方法，我们也称之为重述。小节“就地DAG迭代增广”介绍了各种实施例和重述的应用，任何数量的应用都可以，无需引入就地迭代DAG增广。
继承的从属实体细化，对从属和独立路径都跟踪细化关系向上穿过子树，遵循细化关联。如果独立路径引导到本地节点，把从属节点的继承路径(或DAG)连接到独立路径。图78与图57的不同在于使用来自图76的继承感知过程Generate Single IndependentPath of Proof for Specializing DAG Augmentation 2113于Generate Proof forCross-kind and Specializing DAG Augmentation with Indirect Objects 2132。对于0388的例子，对一些实施例的验证将是两双路径，每一用于每个被细化的节点。在这里的每一种情况下，客户需要遵循解决方案细化分层由被细化解决方案节点朝向本地节点，并遵循问题细化分层从正在求解的问题(本地节点)，通过解决方案被继承的路径。对本实施例的独立路径来自[0393]不变。对于节点4，对本实施例的从属路径为空，因为它有一个直接对象。对于节点8，对本实施例的从属的路径是[7]，其细化双亲的独子，它确实有一个直接对象。请注意，按照惯例，我们再次把初始节点作为隐式的，不包括它们在路径中。
即使我们不要求每个从属实体与单一细化独立实体相关联，还有另外一个原因使实施例可能选择约束一个可以被细化的从属节点，连同一个独立节点的增广。这是为了避免与继承的不一致。创建与现有的独立实体相联系的从属实体的操作，且细化现有从属实体一般可能导致以下情况：继承后各种关系的并实际上可能是循环的。作为一个简单的例子，考虑用一个解决方案开始解决这个问题，并引入一个问题，它细化正被解决的问题，并受到这个解决方案的启发。更一般地，我们希望避免这样的情况，其中被细化实体可以通过追随对象的关联(由跨种关系)达到。这些不一定是直接对象关联，也可能涉及细化。上述约束足以防止这种循环，且实施例可以确定它是否也排除了被认为是有用的项目结构。但是这些循环也可以不被认为是一个问题。唯一的不规则性是，同样的实体既可能出现在上下文，也可能出现在子结构。实施例中可以安排对崩溃为必需的分层结构，以防止与同一实体相关联的一个以上的节点在同一时间可见。
又把这些线索连一起，客户端可以产生一个单一的新节点作为一个跨种增广的基节点，同时细化其它现有节点。示于图77个的例程，与在0362所描述的例程之不同，只在于使用了如上所述的图74和图78中的例程继承感知版本。又，实施例中隐式包括在GLB的本地节点可以完全避免处理继承的被细化节点，因为他们的对象将在上下文中。
从到目前为止所展示的，在一个本地节点(只包括本地的)的子结构中，用户可以对继承的或非继承的节点进行操作，除非如果用户指定了一个继承的节点的增广，它既是也不细化一个直接继承的节点，实施例可能需要发出错误消息。这种情况可以通过下节介绍的增广迭代来处理。
迭代DAG增广
如果从属关系是间接的(各种从属跨种关联和细化关联的组合)，有可能由0388迭代这个过程。复制继承的结构，使每个新节点保持连接到先前创建的节点，最终到达本地节点。任何对多个节点公共的继承结构，应该只复制一次。实际上没有必要重新创建整个结构；例如，一些实施例可以满足于只是重新创建跨种关联，省略细化关联而通过考虑跨种关联来联系大多数实体。
给定DAG如图24，用户可以执行一系列操作序列，首先导航到节点1和细化节点9至9’相对于节点1，然后导航到新节点9和细化节点15至15'和11至11'，每个都相对于节点9’，导航到11'和细化12至12'相对于11’，最后导航回到图9和细化12'和15'至17相对于11’。图39中的DAG，是一个可能的结果。我们这里展示了如何自动化类似这样的序列。回想一下，图25、图26和图37展示了处理DAG被局部化于节点1为一颗树的各个阶段，通过它用户可以探索节点12和15。
注意在此迭代中，用户可以选择增广继承的节点，甚至那些本身既不是也不细化一个直接继承的节点。这在以前是一个问题，因为这样的节点不能隐式地连接到本地。因为在到本地的路径上的前行继承节点将依次复制，到本地的连接每次只生成一个增广。
图38示出用一个新的问题节点(17)细化问题节点12和15的过程，它相对于节点1处理这个问题。图39再次显示了这个过程后产生的全部DAG。
一般说来，我们希望新的实体既从正在增广的继承节点，也最终从接收到该继承性的节点下降。如图38所示，实施例可以创建一个相应的结构并细化从本地下行到被增广节点的任何路径上的继承的结构。这可以涉及复制(但允许用户重新命名和以其它方式调整)在由本地到通过跨种关系正在被增广基节点路径上的任何继承的节点，以及在从本地到正在被细化节点路径上的节点，但注意只复制任何公共节点一次。复制继承的结构后，可能有附加步骤来创建最终节点增广细化结构。
一些实施例(包括我们在下面描述的一个)提示用户定义增广节点以自上向下的方式，开始于接收到继承的节点的子代。其它实施例提示用户定义增广节点以自下向上的方式，开始于正在增广的继承节点的子代。
当利用细化关系增广一个节点时，一些实施例可以呈现被细化节点的值作为对细化节点的默认初始值，其它实施例在这些情况下，可以不提供任何这样的默认初始值。
一些实施例(包括我们在下面说明的一个)允许用户细化继承节点的每个继承祖代。其它实施例更喜欢不细化被增广继承节点的每一个这样的继承祖代，而更是在那些祖代中的任何细化链，只细化最终细化祖代，并考虑直接参与下一个与不同种类节点的关联(例如或者是针对一个问题的解决方案，或者是被这个解决方案启发的问题)。
实施例可如下面0421所述，允许操作直接对继承节点进行，但在这样的操作进行之前，向用户请求对每个继承参数祖代的新信息，以便复制和修改它们识别在本地节点下它们的位置。替代之，实施例可能只支持继承节点的重述，而不是其它操作，从而使用户没有选择，只能在继续之前明确地重述每个参数。
注意虽然一个任意复杂的DAG结构可以由本地实体继承并与其子代整合，当用户在子结构中探索，从本地节点到达一个继承节点来增广，对于不同的实施例，将有不同的路径返回到本地节点，重新跟踪那些步骤，子结构节点形成根植于本地节点的树。
还要注意的是，我们可以(但不是必须)假设第一继承节点与其双亲有不同的类型，因为，例如，一个问题通过解决方案的一条细化链被继承，而一个解决方案通过问题的一条细化链被继承。
现在，我们可以展示整合该迭代于显式细化操作的高分层处理流程。我们开始于通过初始化一个数据结构来保存复制继承节点的结果。它可用于避免复制任何节点超过一次。实现中把父节点(细化由之启动)只是作为另一个被细化的点(这里的不同之处仅在于应用于最终增广的定位)，而不是用作跨种增广的基节点。数据结构也被初始化，用于收集新节点和通过新节点的路径(如果尚未到位)，通过调用Copy Inheritance forSpecialization 2103于每个被细化的节点和存储在所述的结构中。在调用CopyInheritance for Specialization2103于每个细化节点之前，我们生成从该节点到本地的路径(如果尚未到位)，以便应用于那个例程。复制继承结构被增广后，我们可以进而提示用户关于显示增广节点的信息，并创建它应用Atomic Specializing DAG Augmentation2141。各种实施例可以有所不同，取决于单一节点的显式细化是通过对该节点的复制过程进行，还是隐式复制完成后的显式增广。前一选项示于图80，鉴定最终增广的资格，确保它不是单一继承节点的一种细化。后一选项，与0417和概述于图81仅复制最后细化的继承节点的方法相一致，替代求证复制继承细化节点的资格，避免单个节点的情况。其它实施例可以执行两次细化，并且实际上这可能是优选的就地迭代方法，如在“就地迭代DAG增广”中。
用于跨种(和细化)增广的方法概述于图82。它与图80和图81的不同在于省略了把parentNode作为细化的步骤，在于复制基节点的继承祖代以及细化节点的继承祖代，和当然，在于最终的增广的形式(应用“原子跨种和具体化DAG增广2142)。
图84显示用于图38例子的例程的跟踪。
增广继承节点的过程可以涉及复制每个那样的节点的继承祖代结构。例程CopyInheritance for Specialization 2103负责迭代再生正在被增广的单一继承节点(无论是基节点或正在被细化的节点)的祖代们。其结果是一个指向该新节点(它然后指向其双亲)的指示器，以及在服务器需要对增广核实的实施例，一条从正在被增广节点朝向本地的路径，它可用于生成那些验证。该例程显示于图83。我们假设在这个描述中有一个堆栈。进入每个堆栈的内容可以被假设为包括一个继承节点和由其衍生的操作。在该操作可以被推断是来自这种类型节点的实施例，只保持继承节点可能就足够了。连同或在继承节点中整合是到达该节点的双亲节点的一种方法。堆栈可能显式地这样实施，系统堆栈可用于(通过推动将参数传递给例程，通过弹出返回)建立一个延续，处理在以前建立的延续被到处推动的数值，或通过其它由精通实现堆栈人士熟悉的计算过程。例程由顺序执行的两个回路组成：第一个通过祖代下降，向上扫描通过正在被增广节点的祖代，同时建立堆栈，而后者馈送堆栈，同时复制继承的节点。对于第一个回路，推动遇到的每个继承节点，直到或者一个节点已经被复制，或者达到了一个非继承祖代。在前一种情况，用存储的值开始第二个回路。在后一种情况，使用非继承祖代作为newParentNode，并前置parentPath与inheritedNode作为第二循环开始时的newPath。对于各种实施例，第一个这样复制的节点(最后一个继承节点的副本)总是取newParentNode跨种增广的形式(inheritedNode的双亲),如同在“原子跨种和具体化DAG增广2142”中，由于节点是作为跨种关联继承的。否则，实施例可以推迟inheritedNode和parentPath供以后使用，并通过祖代分层前进，通过设置inheritedNode为其双亲，并把parentPath替换为没有第一个元素通过第一回路继续迭代的版本。复制最后一个继承节点作为newNode后，实施例可以建立finalPath(用于验证生成)，通过预先计划newNode到newPath。这里，它们可以记录newNode和finalPath于已经复制节点的数据结构，并确保newNode位于inheritedNode和parentPath以下，使得GLB计算可以进行而没有错误。最后，实施例可以正式开始第二个回路，通过检验堆栈是否为空，如果使用预先计算的值，它们将在那里取值。如果是这样，它们就完成了；否则，它们可以弹出堆栈以获得第二最浅的继承祖代节点和parentPath，设置newParentNode为第二最深祖代的副本。在这里，实施例可以复制inheritedNode。如果inheritedNode是其双亲的跨种增广，实施例可以如前继续进行“原子跨种和具体化DAG增广2142”。但是，如果inheritedNode是其双亲的细化，它们可以替代之使用Atomic Specializing DAG Augmentation 2141，以inheritedNode和newParentNode作为refinedNodes，并在相应节点创建步骤之后继续进行。
我们注意到，直到所有节点事实上都被复制的程度，我们可以关于多对多细化关系简化上述(0399至0335)细化继承节点事项。由于我们复制每一个被细化的从属节点，各种实施例的最终多重细化会细化这些“复制品”，其中的每一个不与关联于继承从属节点的独立节点相关联而是与本地节点。因此，在这种情况下，应该有可能对任何从属实体的多重细化，要求它们与相同的独立实体关联。一个中间步骤会要求一个这样的被细化的从属实体，至少与一个独立实体相关联，而后者对与其它被细化从属实体相关联的独立实体细化。
在需要自动化增广DAG的实施例中，延伸逻辑子结构树后有时可能发现所需的DAG节点是不可见的，因为DAG的一个不同部分可能已经扩张。这可以通过重新安排显示以显露期望的节点处理。对子结构中节点做到这一点的过程示如图213。它接受一条路径，并通过首先扫描已可见操作路径的一部分但没有找到所需的节点，首先关闭任何冲突的兄弟姐妹，然后开始展开路径，一次一个节点。
中对Copy Inheritance for Specialization 2103的描述是有局限性的，因为它假设路径从被增广(或否则作用于)的节点到本地节点将完全由继承节点(除了本地节点)组成。逻辑子结构树有可能在继承的和非继承的节点之间通过。如果一个钻石形是继承的和通过它的一条路径被复制，但用户随后又探索另一条路径，这种情况可能出现。但是在本地DAG中总会有一条路径，从任何继承节点到每个通过它继承的本地节点，因此一些实施例可以认为这已经足够了。对于其它，Copy Inheritance for Specialization 2103可以适应这种场合作修改。不是简单地回到任何非继承的节点，或已经被复制的节点，它们转向只为了本地节点或已经被复制的节点。在实施例返回到从本地节点出发的路径中，当它们到达继承节点之后的第一个非继承节点，不是创建节点与复制的双亲实体相关联，它们可以替代之创建一个在该实体关联和它们在路径上跟踪的一个实体之间的关联，传递它们自己的节点到路径上的下一个节点相链接，如果它是继承的。任何后续非继承的节点，当它们返回继承的到子代们时，将简单地用自己的节点替代双亲节点。图85修改了图84，假设节点11+和12+不是继承的。作为一种优化，实施例可以确定，当它们沿着路径上升时，哪些节点要求返回到一个节点，甚至哪些需要被复制，以减少回程所需的工作。
就地，迭代DAG增广
在跨种种类关系是多对一的情况下，可以使该迭代更直观。我们可以就地修改继承的结构，而不是创建与继承结构相对应的并行结构。这可能看起来很奇怪，因为在层次结构中看起来低于另一个的结构在全局DAG中实际上并不低于它(如果只有后者被继承)。但是，一旦被接受，它就可以提供简洁直观的表示。
给定图24中的DAG，用户可以就地执行[0411]中描述的操作序列。图39中的DAG是可能的结果。它与图39的不同之处仅在于某些细化弧标有字母“R”用于“重述”，如下所述。再次回想一下，图25，图26和图37呈现了各种处理阶段，以将在节点1处定位的DAG呈现为树，用户可通过该树探索节点12和15。
图40示出了使用对继承节点的迭代的就地重述来利用新问题节点(17)来细化问题节点12和15的过程，该新问题节点(17)针对节点1对其进行寻址。图39再次显示了该过程之后的完整结果DAG。
与标准迭代复制所描述的类似的变化也与迭代复制就地相关。
这提出了如何以避免显示如上所述由用户重述的信息的方式向用户呈现初始的本地化DAG的问题。一些实施例可以基于DAG结构隐式地这样做，使得至少那些用就地重述构建的结构可以被认为是本地化中的重述。例如，它们可能需要，如果解决方案直接解决了某些问题节点并且还改进了其他解决方案节点，则可以将细化解决方案视为重述，以使其可以代替细化节点而可见。这类似于细化和细化实体的要求不同的对象。其他实施例(包括下面进一步概述的实施例)可以明确地创建重述，例如仅在修改继承节点时，以便在定位时可以不同地处理标记的细化。此类重述将连接修改后的继承节点与原始节点以及继承节点祖先与原始节点的任何重新创建副本。可以限制重述的创建，使得任何实体最多重申一个其他(更一般)实体。
在任何一种情况下，重述也可以形成控制访问的基础。一些实施例可能希望防止不相关的重述，例如，解决不在子结构或上下文中的节点的重述。通过隐式重述，实施例可以避免继承直接解决问题的解决方案，除非该问题出现在解决方案的继承路径上。或者，如[0631]中所述，实施例可以支持互斥改进的定义，并且避免继承解决替代细化问题的解决方案的后代。我们将在下面看到一种通过显式重述在本地化期间控制访问的方法。目标是避免向用户展示与他们无关的解决方案，并确保只有那些应该看到他们的人才能看到解决方案(可能是组织的资助者，他们有更广泛的目标，而不是同一个资助者的兄弟组织)。
这种使用重述的方式不仅涉及控制访问，还涉及相关性。考虑依赖于项目层次结构的组织层次结构。因为用户主要关注项目，如果这些下属被分配给不相关的项目(在这种情况下，分配关系)，他们可能没有兴趣看到分配给项目的个人的下属。用户到解决方案可能是多对多的。
由于对于各种实施例，将出现继承的重述以代替重述的实体，对于实施例来说，将重申的实体的其他(非重述)后代置于其重述之下可能是方便的。同样，这可能看起来很奇怪，因为本地DAG偏离全局DAG，并且一些实施例可以选择避免采取该步骤，特别是在非重述改进的情况下。为了与这种方法保持一致，在图86中，我们修改Collect Inheritance 2240以通过重述继承其他细化节点。
建议的就地迭代方法触发沿着从启动操作的节点到轨迹节点的路径重新继承的节点。在“菱形”配置的情况下，例如，其中启动操作的节点具有两个父母，两者都共享一个共同的祖父母，可以相对于通过钻石的单个路径启动操作，导致一个父母要重述而不是另一个。如果从通过另一个父节点访问的同一节点或后代启动后续操作，则一些实施例可以重新创建轨迹路径上的所有继承节点，而其他实施例可以仅重新创建该路径的任何继承前缀。前一种方法可能需要注意，在向本地开始工作时，节点是否是其父项被继承的组成部分，一直持续到本地，并且当返回工作时，仅重新继承节点但重置那些组成节点的父节点其父母被重述。
我们允许重述作为同类实体之间的一种特殊的细化关联。服务器上的本地化过程可以聚合它遇到的任何重述，因为客户在制定适当的服务器请求时可能需要这些重述。
首先，我们可能希望隐藏由子结构中的节点重新声明的继承实体。为了使这更容易，一些实施例使用Record Inheritance 2250的变体，其将继承的节点添加到DAG自底向上(即，首先添加最接近子结构的继承节点)。为方便起见，实施例可以使用最浅的第一版本的Collect Inheritance 2240。代替要接收继承的单个父节点或目标节点，我们维护一堆目标节点，并将继承的直接接收者称为顶级目标节点。现在，辅助例程将返回在继承后续子句的过程中是否到达subDAG，以及放置在顶部目标节点下的子项。另一个例程RecordRestating Child 2270记录了currentEntity的每个重新生成的子代。大部分工作，包括检查适当的祖先，旨在防止存在冗余的细化链接，并且可以像[0331]中那样解决。在这些例程中，我们根据子节点是否重述进行分支。重要的是，我们以忽略一些重述的方式执行此确定，当子节点上的某些操作对象生成轨迹节点或子节点的对象位于继承路径上时(相反，考虑在每个重述上存储先前的重述)迭代扩充，它构建并检查这些序列是否导致轨迹节点-它对应于在跨种扩充的就地重述的情况下的对象)，如果在其中将它们视为非重述subDAG或完全忽略它们。此外，为了按照[0433]中的建议使用重述来控制访问，我们使继承路径可用于Record Inheritance2250。通过此修订，该例程可以跳过不相关的重述。在这里，如果继承路径上没有父节点，我们认为重新继承的节点是不相关的。这在图87中示出。
在客户端侧，一些实施例用图89替换图80和图81中呈现的替代高级处理流程，如果适当的话，其重新表述然后细化单个继承节点，但是其他实施例可以使用这些其他例程的变体。在这种情况下我们使用的图90与图83的不同之处主要在于它使用执行重述的原子例程。它还保留了先前重述的记录。图91显示了一个过程流，该过程流增广了DAG，同时就地显示了可视化节点以进行显式细化操作。接下来，我们将提出与图73的差异。在识别从每个精制节点的对象到轨迹的细化路径时，我们将对象的重述链与原始重新实现的细化分开。然后，在计算GLB时，我们使用细化路径。如果GLB本身是继承的，则重复使用RestateInheritance for Specialization 2133来重述它及其祖先。然后，将GLB替换为细化实体的细化路径上的重述，并将GLB重述添加到每个相应的重述路径。在生成DAG增广的证明时，将每个重述路径从重置节点连接到重新设置的节点，并具有从重置节点到轨迹的相应细化路径。否则，继续使用Atomic Specializing DAG Augmentation 2141。
图92呈现了具有跨种以及专门化DAG增广的相同例程。
多种跨种增广
多对多的跨种关系并非绝对必要，因为如果独立实体类型的细化关系是多对多的，则可以集体细化任意数量的独立实体并仅关联新的从属实体与炼油独立实体。
在一些情况下，实施例可能希望支持多对多的跨种关系。考虑图93中的DAG，了解它如何工作的示例。在这里，我们有一个带有四个子节点的问题节点，两个解决它的问题和两个改进它的问题。图。图94示出了在继承之前具有以两个子问题为中心的导航的相同DAG。在两个子问题继承两个解决方案之后，我们在图95中具有DAG。从图96中的探索，我们对两种解决方案进行了细化，如图97所示。如图98所示，除了细化之外，还存在与每个子问题的隐式跨种关联。显然，通过这里的假设，没有为每个解决方案分配单个问题。
直接支持多对多跨种关系的实施例可以考虑如何约束与多个独立实体相关联的从属实体的创建并且细化多个其他从属实体。一种方法是要求每个独立实体被扩充，并且对于每个被细化的从属实体，要求祖先跨种型关联，使得独立实体被增广的独立实体细化并且从属实体由从属实体细化被细化。但是，也可以在独立实体之间对依赖实体进行分区(或者等效地，在独立实体之间对独立实体进行分区)，以便只需要为同一分区中的每个依赖和独立实体存在祖先跨种型关联。
上述用于使相对DAG增广直观且有效的技术可以适于通过具有相同的跨种关系来创建与多个独立实体相关的从属实体，以及通过具有多个轨迹节点来细化多个从属实体。多个本地节点可用于其他目的，包括用于泛化(在“DAG概括”下描述)。
这可以通过把我们的DAG稍作一般化来实现。给定一个DAG Dag，对于任何实体E|，我们将DAG DagE|1定义为与Dag的不同仅在于，DagE|1不包括从Dag中的E|中的某些E不能到达的任何节点，也不包括在Dag中不能由之到达E|中的某些E的任何节点。
一个特定实施例使用对DAG的进一步修改。DagE|2与DagE|1的不同之处仅在于包括了中被E继承的E|实体的每个E的子代，例如，依赖于被E细化的实体的一个实体。
该实施例给出了具有公共上下文的DAG DagE|2。现在，如果用户选择E|中一个或多个被某些E继承的节点(其中每个都细化由E直接继承的节点)，由之导出一个细化实体，一个跨种关联隐式地形成于正在被细化的继承节点的上下文中的每个E和新细化实体之间。
DagE|1从Dag的获得，类似于[0327]中的〖Dag〗_E^1，但是从开始搜索的多个实体开始，包括在公共的简化DAG中遇到的所有结构，并且保持跨越E|的被访问节点的公共集合。
DagE|2从DagE|1获得，类似于[0372]中的〖Dag〗_E^2，但是对于每个本地节点调用Collect Inheritance 2240”。因为各种本地节点可以共享公共上下文，所以有用的是维护一个在E|中的任何E上被每个上下文节点继承的节点集合，而后在遇到实体使用预计算继承。为被任何本地节点继承的每个实体调用Record Inheritance 2250。
在我们使用“本地节点”来满足跨子结构和上下文的界限的情况下，在支持多个轨迹节点的实施例中，可能需要寻找树的底层边界(它们的共享子结构用于GLB或它们的LUB的共享上下文)。
许多实施例可以确保本地节点不是彼此的祖先或后代，至少不是在局部DAG中，因为这会使子结构和上下文的概念复杂化。
在多对多关系的情况下并且没有存储间接对象的情况下，所有本地都是相同类型的，用户可以联合细化由不同本地遗传的多个节点，轻松创建“钻石”结构每个除了最后的细化。
所有本地具有相同类型的另一个潜在益处是，对于概括(如下所述)，用户可以创建与每个本地细化的从属实体的跨种型关联。
在存在多个本地节点的情况下，实施例可以省略辅助信息(在“辅助信息和聚合”下描述)或者可以提供与“任何”本地实体或“所有”本地实体相关的信息中的任一个或两者。在辅助信息是离散的情况下，这可能仅涉及各种轨迹实体的辅助信息上的并集或交集。在辅助信息是分层的情况下，如在[0605]中，在通过各种轨迹实体将相关实体包括在辅助信息中的情况下，实施例可以在获取与各种轨迹实体相关的实体的并集之后，删除那些辅助其他本地实体的实体的祖先。或者对于“所有”而不是交集，只考虑对于每个其他本地节点，它们通过细化与该本地节点的辅助节点相关，然后仅包括最一般的这样的辅助节点，而不是跨种点。因此，如果一个本地用户精通Java编程和产品管理，另一个用于Python编程和产品管理，第三个用于编程和敏捷产品管理，所有选定用户都熟练掌握的技能包括：产品管理和编程，而任何用户精通的技能都包括Java编程，Python编程和敏捷产品管理。
实施方案通常可能希望使所有本地具有相同种类，但也有例外。为了帮助用户匹配项目角色，用户池和项目池都可以成为本地。然后，直接包括跨职业关系，包括直接细化关系(至少直接调整技能)，以及直接细化关系(至少直接调整技能)，可以很容易地看到特定用户如何通过技能连接到特定项目角色。
为了满足仅在满足所有技能要求而不仅仅满足一个技能要求时将个体与项目匹配的需要，实施例可以将直接处理的技能和技能直接处理为多对一而不是多对多并隐式地创建技能。改进了解决方案所要求的或用户熟练的每一个。
这对于技能要求与资源需求相关的实施例(如[0619]中所述)是有帮助的，但可能不(如[0603]中所述)与技能要求与整个项目相关的实施例相关。
然后，对于如此创建的每个多技能，DAG还可以包括作为该技能的父母的相同技能的每个较小组合，直到也将包括在DAG中的单身技能。为了避免这么多DAG条目的混乱和低效，最好只包括refinesSkill关联来代替directRefinesSkill关联，只需要连接现有的DAG技能实体而不需要冗余。索引可以从各个技能实体构建到它们参与的DAG中的多实体。然后，对于每个多实体，可以查找与其每个联合体相关联的其他多实体，消除自身和任何包含单一技能而不是其自身组成部分的多项技能，并通过子集关系对其余技能进行排序。相邻技能组应在DAG中连接。
在多个实体与主DAG的本地相关，或者如果用户明确导航到多个节点的情况下，可以查看具有多个本地的DAG，所述DAG是次要DAG(参见[0605])。
DAG概括
我们已经集中在上述项目结构的自上而下的增广中。但是从下到上增加项目也很有用。专业化的自然补充是泛化。一个特别有用的案例涉及从更具体的问题创建更一般的问题和解决方案。对于不需要充当任何其他实体的从属实体的某类实体，实施例不需要限制这种向上细化。
为了证明维持细化实体的对象分配，一些实施例可以强制执行类似于[0337]的约束以用于特化。在通过一种或多种现有依赖实体来细化依赖实体的跨种类关系下将独立实体分配给新的依赖实体时，实施例可以要求对于每个细化依赖实体，独立实体的某些细化后代通过以下方式关联：与(作为直接对象)相同的跨种关系(该作为直接对象)该依赖实体的细化祖先，表示新的跨种关联与一些先前存在的关联之间的对应形式(比[0337]的约束更松散)。因此，如果以独立实体作为其对象创建新的细化(概括)依赖实体，则每个细化依赖实体的对象必须在各种实施例下细化该独立实体。
对于可能与零个或一个独立实体相关联的种类的从属实体(示例可能是可能是零或一个解决方案的组件的问题)，一些实施例可能要细化实体应该都具有对象，或者没有人应该。在前一种情况下，可以为新的一般化实体分配这些对象的LUB。在后一种情况下，可能不会为新的一般化实体分配任何对象。其他实施例可以允许这种从属实体的任何概括不具有对象，并且允许任何数量的细化实体具有或不具有对象，但仍然要求如果将对象分配给新的精制实体，则它是炼油实体的任何对象的LUB。
对于必须与独立实体相关联的从属实体，如果我们可以将其对象的LUB计算为新的，推广的从属节点的对象，则可以概括若干从属节点。如果被推广的节点和子对象一样在子结构中，则这可能是特别但不排他的。否则，可以从与之相关的独立实体的节点发起跨种操作泛化将被关联，称为基本节点。如果存在基本节点并且它与LUB不同，则可以认为从属节点与其对象的关联是直接的，否则可以将其视为间接的。实施例，尤其是在LUB计算中隐含地包括轨迹节点的实施例(如在[0471]中所述)可能要求基节点在上下文中。
因此，用户可能想要在保持或生成跨种的同时概括从属实体与独立实体的关系。好处是，在被推广以应用于更一般的问题之后，该通用解决方案可以由其他专用节点继承并且如前所述被细化到它们。对于上下文中的基础(独立)节点(用户可能打算向下扩充)，而不是允许用户选择新的从属节点应该细化的从属节点，实施例可以允许用户选择该从属节点。相同或至少一致的类型(一些实施例可以将这些限制于上下文)将改进新的从属节点。然后，新节点插入在被扩充的节点和细化节点。这意味着如果该细化节点在其中，则新节点可以位于细化节点上方如果基节点在子结构中，则在上下文中或在基节点下面。如果基节点处于适当的上下文中并且细化节点位于正确的子结构中，则某些新精化节点将不会显示。因此，实施例可以将细化节点限制到上下文。
用户可以选择相同种类的若干实体来联合概括。考虑图99中的DAG。这里，有两个长度为3的问题细化链，最常见的是31，每个终止用一个解决方案(36和37)。如果用户导航到31并探索到36和37，如图4中所示。然后，如图101所示，图102中的DAG是可能的结果，然后启动36和37的联合概括。
用户可以改为明确地选择独立实体以用跨种类关联来扩展和任意数量的从属实体进行概括。例如，用户可能想要概括解决方案以解决特定的，更一般的问题。考虑图103中的DAG。它与图99的不同之处在于，直接寻址独立节点(46和47)的每个从属节点已经由另一个从属节点(分别为48和49)推广，并且对象节点的LUB 41具有细化父节点40。从图104中的探索中，我们选择概括两个从属节点(48和49)并从根独立节点40发起跨种类操作，如图10所示。如图105所示。如图106所示，新节点50现在位于它所寻址的独立节点40和它所概括的从属节点48和49之间。
在以上示例中，由用户明确选择的要概括的节点由轨迹节点细化，轨迹节点的对象细化基节点。在存在更复杂的依赖序列的情况下，类似于针对迭代特化所描述的过程可能与按顺序处理若干泛化和跨种型增广操作相关，再次自上而下地进行。与那种情况一样(在[0426]中描述)，可能有必要在上下文中显示节点。用于实现该程序的类似程序在图214中示出。
当在上下文中执行基本节点的跨种增广时，有可能实施例隐式地将来自本地(或多个本地)的路径处理为但不包括基本节点作为序列(或多个序列)到
被复制和推广(通过迭代)，最上面复制的节点由新的扩充节点推广。作为示例，考虑图107。它具有一个问题的结构，一个细化问题又有两个子解决方案，每个解决方案都有一个组件问题。我们假设我们已经导航到两个组件问题，74和75作为轨迹节点。如果我们从根问题70开始解决方案，则这可以由实施例解释，使得该解决方案由上下文的复制部分细化。特别是，我们从loci开始，将两个组件问题(如前所述，允许用户修改信息)复制到一般化，然后将这些问题组件化为一个新的解决方案，该解决方案概括了两个现有解决方案并解决了根本问题。得到的DAG在图108中。
泛化的许多方面类似于专业化，但是子结构和上下文相反(尽管我们在这两个案例中集中于自上而下的跨种增广)。
图109示出了类似于图42的分层分解。
多个同时细化
对于将独立实体与特定种类的每个从属实体相关联的实施例，其中几个从属实体被概括，将一般化的节点的对象的最小上界分配给新实体是合理的。例如，我们可能希望每个解决方案都与一个可以解决它所解决的任何问题的区别问题相关联，或者每个参数都支持或反对一个优化它解决的任何对象的区分对象。不幸的是，如[0338]所示，上下文树提供了对最小上限的非常有限的访问。在某些特定情况下，合并继承(向上方向)可以提供可能的解决方案。
在计算LUB时，类似于[0343]中的GLB的情况，必须考虑是否隐含地扩宽LUB输入以包括轨迹节点(假设它被子结构中的所有对象细化)，被细化的节点)。这样做将再次认识到用户导航到轨迹的重要性作为相关信号。
我们继续描述独立节点的计算，以将新精化的从属节点作为关于子结构和上下文树的LUB。如果没有从子结构中选择任何依赖的细化节点(它们是从适当的上下文中选择的)，那么强制执行[0460]约束的实施例可以安全地分配其GLB的对象(在反向上下文树中，使用Calculate GLB wrt
a Tree 0111)，如果该GLB存在，则到新的细化节点。或者在从子结构中选择所有细化依赖节点(被概括)的情况下，实施PARA约束的实施例。0460可以安全地将其LUB的对象(使用Calculate LUB和树0101获得)(如果该LUB存在)分配给新的细化节点。但是，根据[0471]，一些实施例可以跳过该步骤并简单地使用轨迹节点。在被细化的从属节点具有相同的对象的情况下，我们可以将该对象分配给新的细化节点(同样，该步骤可以提高效率但是可以省略，因为它被以下内容覆盖)。否则(或者对于喜欢直接采用这种方法的实施例)，我们可以依赖于子结构或上下文树中细化依赖节点的对象的存在，并检查它们之间的LUB，使用计算LUB和子结构和上下文树4101。计算子结构和上下文树的显式节点的对象的LUB明确5111在图111中示出。
计算LUB，子结构和上下文树4101假设其输入到达节点列表并且首先确认所有成员都在子结构或上下文中，否则失败。在任何节点在上下文中的情况下，客户端使用Calculate GLB wrta Tree 0111来计算关于反向上下文树的GLB，并忽略那些在适当的子结构中的GLB。在所有节点都在子结构树中(并且我们还没有恢复使用轨迹)的情况下，使用计算LUB和树0101来获取关于子结构树的LUB。一些实施例可以代替在指示的地方立即失败在上面，尝试通过其他方式在DAG中找到LUB，例如更详尽的搜索。
在[0464]的示例中，31被指定为38作为34和35的LUB，节点的对象被细化。注意，在图101中，在问题节点31下创建新的解决方案节点38，如[0463]中所建议的。
服务器现在可能需要验证所推广的每个实体的对象本身是一般化的通过新节点的提供对象(现在是所有这些对象的LUB)，即新节点的对象是至少细化节点的对象的上限。服务器可能要求对每个从属实体进行概括，通过细化(我们假设具体性从最具体到最少)与该从属实体的对象被推广到最小上限相关联的实体链。可以使用基于树的项目结构展示来提供这样的链。对于要细化的每个节点，客户端可以基于几种情况之一构建路径。对于上下文中的LUB和细化对象，客户端反转从LUB跟踪上下文树根的路径的结果，然后进行细化，直到在细化节点处与实体的对象到达节点。对于上下文中的LUB和子结构中的细化节点的对象，它可以连接从细化实体的对象节点到具有从LUB到轨迹的反向路径的轨迹的路径。在LUB计算中不隐含地包括轨迹节点的实施例(通过类比于[0341])可以在子结构中添加GLB(和对象节点)的情况，并且在那种情况下使用通过从对象节点开始并且提升而获得的路径。虽然子结构直到达到LUB。使用来自图59的Generate Proof Path 0113，在图122中呈现证明生成过程的实施例。在我们的例子中，如果用户概括了节点36和37，则该实施例的证明将包括36个路径[32,31]从其对象34到LUB，31；同样地，对于37，[33,31]从其对象35，到LUB，31。
在概括上下文中的节点时，优选实施例将首先将节点移动到其父节点列表的顶部(参见[0682])。如果启动操作的节点是最重要的节点在DAG中，实施例将整个DAG放置在(在基板中)新节点下方，在新帧内建立。否则，新节点可以放置在封闭帧的节点列表的顶部。
将这些片段放在一起，客户端可以使用原子显式推广DAG增广4141来生成由现有节点细化的单个新节点。图110描述了针对细化节点的对象的子结构和上下文将每个从属实体分配为对象独立实体作为LUB的情况的序列。首先，对于每个细化节点，识别通过从其对象通过子结构或上下文到轨迹的细化相关的节点序列。注释适用于[0350]中的注释。然后，如图111中那样计算细化节点的对象的LUB。如果LUB不存在，则失败并提供错误消息。使用LUB及其细化路径生成服务器的证明，如图122所示。同时，提示用户将信息与新实体一起存储。然后访问服务器以请求扩充操作，发送证据。如果失败，请清理部分创建的节点。否则，更新客户端信息以包括新实体(为新实体创建记录，包括用户输入的数据及其对象，以及更新正在被细化的节点的实体的记录以将新实体包括为附加子实体)。服务器返回新实体的数据库标识符，客户端可以使用该标识符来构建新节点的URL。
证明验证过程，其中每个从属实体被分配对象，如图123中所示。服务器可以确认对于每个细化实体，给定路径实际上是一系列改进，从中开始细化实体的对象，以新细化实体的提供对象结束(通常是细化实体的对象的LUB)。它遵循通过全局DAG提供的路径，验证每个步骤都是一个改进。
仅使用直接对象，证明验证过程，用于推广DAG增广的验证证明仅使用DirectObjects5231，如图53中所示。服务器可以确认每个细化实体，给定的独立路径实际上是细化链，从细化实体的声称直接对象开始，并以新细化实体的提供对象结束(通常是对象的LUB)(细化实体)，给定的依赖路径实际上是一个改进链，从细化实体开始，以新细化实体结束，最后细化实体的声称直接对象是真实的。
继承节点的推广
实施[0337]的约束的实施例可以安全地允许继承到子结构中的节点仅在如“迭代DAG增广”和“就地，迭代DAG增广”中所述首次复制时才被推广。但是，此操作不会概括继承节点本身，而只是对其进行特化。只有在与从中继承该节点的节点或其上下文中的一个祖先创建跨种关联时，才能直接概括继承节点。考虑来自图24的示例DAG，其中我们为每个从属节点分配独立节点。如果我们在直接推广继承节点10的同时导航到节点2并从该节点启动跨种增广，那么10和新的细化从属节点将分别具有1和2的对象，但是细化以相反的方向运行，2细化1但10细化新节点。我们可以在上下文中从节点1或0执行操作，但我们也可以先导航到这些节点中的任何一个，然后启动操作，其中10不是继承节点。如果节点10首先被复制到细化100，那么100将具有对象2.当在扩充2时概括100时，我们将处于上面在PARA中描述的情况。0485并可以相应地进行。
然而，如果实施例支持某些种类的实体向上传递到上下文中，则这样做
可以使用先前提出的用于专门化子结构中的继承节点的相同技术来推广节点。
具有多个同时细化的单跨种增广
为了能够进一步重用解决方案，用户可以概括它们，以便它们解决更普遍的问题。然后，通用解决方案可以由其他专门问题继承(然后专门针对这些问题)。更抽象地，为了能够进一步重用从属实体，用户可以从所选择的独立节点(基节点)发起跨种增广。然后，一般依赖实体可以由其他专门的独立实体继承(并专门用于)。\
类似于[0356]中GLB的情况，LUB对基节点的细化保证了路径从每个细化节点的对象到基节点，从而满足[0460]的约束。如果不能确定这样的路径，则强制该约束的实施例具有类似的选项。要强制执行约束，可以像以前一样执行LUB计算，但是将结果与基节点进行比较。
如果基节点与细化节点的对象的LUB相同，则它是冗余的，并且实施例可以选择将这种增广视为简单的改进。
在请求独立节点的跨种增广以及其已经是对象的从属节点的概括的情况下，仍然可以在它们之间插入新节点，但是当独立节点是作为新的从属节点的直接对象，独立节点应该仅仅是现有从属节点的间接对象。
在每个从属实体与独立实体相关联并且强制执行[0460]的约束的情况下，我们可以使用[0475]和[0351]中描述的证明机制，对[0475]进行一次修改。现在基本节点和LUB之间存在区别，因此对于独立路径，各种实施例有效地将从细化节点的对象到LUB的每条路径与从LUB到基节点的路径连接起来。同样，我们将后缀路径作为证明的一部分传递给服务器，因此只需要检查一次。使用Generate Proof Path 0113来获得从LUB到基础的细化路径(或者如果不成功则失败)的例程在图126中示出。
诸如[0360]中所述的问题也适用于此。
此外，除了之外，对[0475]的证明结构的另一种修改是有用的[0486]。证明现在采用从LUB到基本节点的后缀路径的形式，并且对于每个细化依赖实体，具有两个细化路径：一个到细化依赖实体，一个到LUB，每个从依次开始的实体开始由相同的跨种关系相关联。证明生成过程如图127中所示。对于[0465]中的示例，一些实施例的证明将是两对路径，每个路径一个被细化(如果间接对象可用，则只需要提供独立(问题)路径)。在这里的每种情况下，遵循从细化解决方案节点到轨迹节点并停止在对象问题的解决方案细化层级，产生对应于由当前操作创建的新问题/解决方案对的现有问题/解决方案对。对于节点48，对于该实施例，从属路径将是空的，因为它与独立节点42直接相关(其间没有精化解决方案)，并且对于该实施例，独立路径将是[41,40]，因为遵循这些步骤48的对象42导致新节点50的对象40。同样，按照惯例，我们将初始节点视为隐式节点，并且不将它们包含在路径中。
仅具有直接对象的证明验证过程如图129中所示。服务器可以确认对于每个细化实体，导致新细化实体的提供对象的独立路径从实体的对象开始，从该对象开始通向细化实体的从属路径。
对于间接对象，图126中的证明生成和图128中的服务器验证仅需要在间接路径上操作。
处理单个跨种和概括DAG增广的步骤类似于图110中的原子显式推广DAG增广4141的步骤。与[0362]中的讨论类似，它们的区别在于使用上述例程来支持跨种和泛化扩充，包括用于显式跨种的生成证明和用间接对象推广DAG扩充4122，为显式生成证明跨种和通用DAG增广，仅使用直接对象4132，并推广跨种DAG增广5202，以及添加步骤以转换到相应的细化操作(例如，被推广的节点类型)，如果LUB(用图111和图112计算)与基节点相同。
泛化，重述和迭代
在下面的讨论中，我们使用问题和解决方案，对于独立和依赖类型，分别为“解决”(和反向，“组件化”)的跨种关系，仅用于呈现的具体性。
如果要使用重述来控制访问，如[0433]中所述，以便可以在不同组织之间选择性地共享解决方案，我们需要创建重述，不仅在专门化一般解决方案时，而且在概括特定解决方案时。在专业化的情况下，针对更具体的问题重新给出解决方案，然后任何进一步的改进或组件化对于更具体的问题是私有的。在概括时，可能会应用相同的两个步骤，但我们需要给予(或其他负责的用户)管理员更一般的问题余地，以便在重述的特定问题方面进行概括，以便过多的信息不会被特定的问题。实现此目的的一种方法是分别执行这两个步骤。首先，更一般的问题的管理员将能够“解决和概括”：直接提出他们问题的最一般解决方案作为特定解决方案的概括，被视为重述(尽管差异可能超过重述)可以通过导航到特定解决方案并从一般问题启动此操作来替换特定术语的一般术语。在第二种情况下，管理员可以从特定问题启动“概括重述”：创建对特定问题的域的最通用解决方案的逻辑重述，但因为技术上已经创建了重新优化，所以此操作用于散布新解决方案代替特定解决方案作为最通用解决方案的重述，同时通过特定解决方案创建这种新重述解决方案的非重新改进。
更一般的问题的管理员可能想要联合概括几个单独的解决方案，可能由不同的组织构建以响应一般问题的不同特化。在这种情况下，管理员可以集体导航到这些解决方案。上面的第一个“解决和概括”步骤将执行一次，产生最通用的解决方案和技术重述与每个特定解决方案的关联，这可能增加相当大的普遍性。然后，对于每个特定解决方案，可以执行第二次“概括到重述”步骤。
现在，考虑这样一种情况：更普遍的问题的管理员不仅想要概括问题的高级解决方案，而且想要针对每个特定问题单独建议的组件问题的解决方案。
这可能涉及导航到几个组件解决方案，并从如所示示例中的一般问题开始，而不考虑[0467]中的重述。实施例可以遍历从一般问题节点到轨迹节点的路径上的各种节点，首先创建最一般的高级解决方案(和几个重述关联)，然后是最一般的组件问题(以及几个重述)，最后(对于这个例子)一个最通用的组件解决方案(以及几个重述)。在存在多个轨迹节点的情况下，实施例不仅仅迭代来自基节点的单个路径，而是将树从基节点追踪到每个轨迹节点。虽然一些实施例可以从基节点开始并且朝向轨迹节点工作，但是其他实施例可以从每个轨迹节点开始并且朝向基节点工作，从而避免已经遍历的子路径。利用[0682]中描述的表示，一种方法涉及在基节点的上下文后代中迭代遍历每个父节点列表所遇到的每个上下文帧。然后，可以执行第二步骤，从每个专用组件解决方案启动，并通过它与一般问题之间的路径生成另一次迭代。
实施例可以跟踪从发起操作的上下文节点到基于广度优先的轨迹节点的各种路径，其中相应位置中的实体被一起概括，对应不需要精确但仅近似-如同迭代一样对于专业化(参见[0417])，我们可以复制整个路径或特定节点，例如对应于由细化关联连接的路径部分。
图113至图119呈现了概括功能的示例。我们这里有一个与备灾有关的项目。图113示出了具有特定解决方案的项目屏幕，“让我们在高跷上构建建筑物！”，被选中。图114示出了如下“多个倒置树的共同上下文的呈现”中所描述的一起打开该解决方案以及另一个“让我们从砖块构建建筑物！”的请求。结果在图115中，其中普通祖先“我们如何建立减少人类遭受灾害的痛苦？”是可见的并且选择了“提出一般化解决方案”的操作。该实施例在图116中进行以允许用户编辑新解决方案的名称“让我们减轻灾难的影响！”，其解决“我们如何建立减少人类遭受灾难的痛苦？”并概括“让我们减轻影响”野火！“和”让我们减轻洪水的影响！“，这是从共同的祖先到本地节点的路径上的下一个非细化儿童。新节点碰巧被放置为“让我们减轻野火的影响！”的父节点，高于其现有父节点。该实施例继续沿着到图117中的轨迹的路径概括节点。由于以下节点(loci)沿着这条路径改进了它们的父节点，新节点“让我们确保有足够的基础设施来抵御灾难！”改进刚刚创建的节点，同时推广本地本身，这从结果中可以看出在图118中。对于如下所述使用重述概括的实施例，在导航到“我们如何建立减少人类遭受野火的痛苦？”时，我们看不到关于高跷的建议，这是不合适或有帮助的。在导航到“我们怎样才能减少人类遭受地震的痛苦？”之后，如图119所示，我们可以看到一般化的解决方案，这些解决方案可能接下来会被改进，例如“让我们确保建筑物用螺栓固定在平板上！”。
专门项目的管理员(我们在这里使用“洪水”项目)也可能希望采取
附加概括的优点，并且可以通过在“让我们在高跷上构建建筑物”上选择“概括重述”来实现，如图120中所示，并且键入概括，如图121中所示。其他实施例可以不同地形成这一点，例如通过从新的通用实体的节点发起操作。
为了专业化，除了通过跨种型关系增广的任何节点之外，我们还允许用户选择要细化的节点。很清楚每个这样的节点是否是遗传的，并且显然需要专门的遗传节点以及它们到轨迹节点的路径。这里，除了通过与轨迹节点的跨种关系来增广的节点上的路径上的任何节点之外，实施例可以允许或不允许用户选择要抽象的节点。如果允许选择附加节点用于抽象，则可以假设抽象涉及节点本身或者来自轨迹节点的路径的抽象副本，或者可以允许用户指定期望哪种处理。
图130示出了用于专门化的类似于图62的迭代概括的分级细分。
用跨种增广来迭代抽象的过程如下。我们为同一实体类的每个连续路径复制一个节点，如[0496]中所建议的那样。保留尚未到达的轨迹节点的列表。首先扫描基节点的后代，直到达到以下任何一个：发生相同的跨种型关系-该实施例收集以这种方式到达的从属节点；与所应用的不同的跨种关系-该实施例失败；本地节点-从尚未到达的本地节点列表中删除此节点。通过每个收集的从属节点创建与新的从属节点的新的跨种型关联，该新的从属节点被设置为被细化(如果实施例支持，则使用重述细化)。如果存在任何从属节点，现在将它们视为独立节点，并且每次重复上述过程，除了跨种关系最初保持不确定并且在扫描后代中首次遇到时设置。该过程在图131中描述。注意，尽管可以通过该过程生成重述抽象，但是一些实施例可能不会就地执行更新。
如果存在多组相关组件解决方案，则可以针对每一个执行上述过程一次，但是高级解决方案的推广将仅在第一次通过期间执行；稍后将重新确认重述。\
在没有明确重述的实施例中，仍然可以应用上面描述的导航到特定然后从一般情况开始跨种增广的基本方法，迭代通过路径。
结合专业化和泛化
虽然一些实施例可以将专业化和概括视为彼此完全独立，但是其他实施例可以一起接受细化和细化节点：客户端，通过不同的选择操作或仅仅检查每个方向；服务器，或者通过接受每个从属节点的方向，或者仅仅检查每个方向(例如，在验证第一步失败时，尝试另一个方向)。
组合特化和概括允许以细化关系在两个现有节点之间插入节点。这对[0493]中描述的“概括重述”操作很有用。
组合特化和泛化对于将上述继承节点上的迭代概念扩展到修改或扩充组成(非继承)基节点并且通过子结构到轨迹节点的路径上发生一个或多个继承节点的情况也是有用的。然后，实施例可能希望在操作基节点之前复制或重述那些继承的节点。为紧接在这样的路径上的组成节点之上的继承节点创建的新节点处的实体将需要被放置在继承实体之下并且位于以下组成节点处的实体之上。然而，在这些情况下，基本节点也总是可以通过仅包括组成节点的路径从相同的轨迹节点到达，因此并非所有实施例都认为该步骤是必要的。
在这种情况下，新节点的对象可能不是细化节点的对象的LUB，而是仅
由他们的LUB改进，可能不是细化节点的对象的GLB，但只改进他们的GLB。
实际上，我们约束下的基节点将细化每个细化节点的对象，并由每个细化节点的对象细化。
DAG细化现有实体
实施例可以支持在现有实体上建立某种细化关系。这里的一个目的是允许跨种型的增广过程和与之同时发生的过程被分开，以便跨种型的增广首先发生，然后一个或多个细化关联随后发生。另一个目的是支持社会创新，由此细化关联创建于现有项目之间。
在跨种型关联中不作为非独立型参与其中的实体，实施例可以在任意节点的实体间建立直接细化关联。为了减少在[0331]讨论的重复关联的发生，实施例可以允许在节点的实体间的直接细化关联，这些节点(实体)对不与本地节点路径连接、或者二者都在子结构中、或者二者都在上下文中。
如果独立型实体被可选性的分配给非独立型实体，并且，细化非独立型实体没有这种直接或间接的目标对象，那么在细化关联创建之后，(如果有任何)被细化的非独立型实体的目标对象可以成为细化非独立型实体的间接目标对象，而不需要任何验证要求。
如果独立实体被分配给非独立实体，并且，[0337]或[0460]的约束条件被执行，又如果细化非独立实体有一个目标对象(甚至是间接的)，那么我们要求被细化非独立实体也有一个目标对象，并且在相互连接的节点的目标之间要存在一个细化关系，通常是在相同的方向上。作为特殊情况，如果细化非独立实体和被细化非独立实体具有相同目标(对象)，且细化非独立实体直接指向该目标对象，则细化非独立实体的目标(对象)会被设为间接。服务器可能需要证明这种关系；如果间接目标对象可用，则它们会以通过直接细化关联连接目标对象的节点序列形式出现；否则，也会要求目标(对象)直接关联的从非独立节点到祖辈节点的细化链。服务器端证明的验证与其它案例的验证没有多大区别。
在添加与跨种型关联相关的细化关联的情况下(例如，在两个非独立实体都具有相同跨种关系下目标对象的情况下)，这种情形用层级通过建立被细化关联的独立实体来定义,(该实体是refined非独立节点的目标对象)，或者是通过该独立实体的祖辈-本地，并同时选择子结构中的被细化和细化非独立实体(这二者通常可以明显的被区分开来；或者是通过它们的目标对象的位置被区分开来，比如，区分在路径上的被细化独立节点的目标对象与指向本地的细化非独立节点的目标对象)。可以生成一个证明，将其作为从细化非独立节点的对象到本地的路径，直至达到refined非独立节点的目标对象。这种公式最适合或便于创建细化关联，其中细化非独立实体有一个目标对象；(这种细化关联)或存在于一个组织的项目范围内的两个实体之间；或如果涉及两个组织，则是从被细化项目的组织开始，因为其项目之一必须对于各种实施例是本地。该公式的一个优点是可以通过执行迭代副本(就地或其它方式)来创建继承节点之间的细化关联，如上所述在“迭代DAG增广”和“就地，迭代DAG增广”两种增广之下。
如果独立实体没有被分配给非独立实体，那么实施例可以像以前关于增广一样，将子结构中的非独立被细化节点的目标对象推断为，在通往本地的路径上，紧随非独立节点的细化链之后的第一独立节点。实施例还可以要求从紧靠其目标对象下方的位置选择细化节点(目标对象通过如上所述的对应于具体化操作的初始部分的跨种型关联相连接)。细化路径可以作为从细化节点的目标对象通过子结构指向本地的路径，直至到达被细化节点的目标对象。
在图132中，在节点61进行导航操作之前，图示了向跨种型关联加以具体化(细化)的示例。
每一组锯齿线代表一个任意的细化路径。用户已经探索了整个指向细化非独立节点66和指向被细化非独立节点64的子结构，并经过66节点的目标对象62。操作之后的DAG如图133所示。
图134和图134，图示了为了通过这个公式在子结构中创建现有实体间的细化关联，现有节点0106(在子结构中)之间细化的DAG客户增广的过程。这个过程从检查两个被细化节点都在子结构中开始的(尽管这不是对所有案例严格必须的)。如果有必要，将被细化节点与细化节点区分开来。与以前的迭代一样，使用Copy Inheritance forSpecialization 2103或Restate Inheritance for Specialization 2133，得到新的构成节点替代继承节点。接下来，使用来自图59的Generate Proof Path 0113生成证明，作为从细化节点的目标对象(被复制)到被细化节点的目标对象(被复制)的细化路径。然后，用现有节点0126之间的细化原子DAG增广，继续创建关联。操作是从服务器请求的，如果成功，则可以将新关联记录在本地DAG的父链接和子链接中。如[0510]以上中所述(这也需要在服务器上发生)，细化节点的目标对象也可能需要调整。最后，实施例可以通过将子树移到被细化节点下的细化节点下面来显示该操作的结果。
或者作为另一种选择，可以使用另一个公式将对应的细化关联加入跨种型增广。用户可以作为双本地导航到被细化的和细化的非独立实体，并通过它们各自的上下文来探索以找到共同的祖辈(如在“多重倒置树结构的公共上下文的表示”中所示)，既，被细化的非独立实体的目标对象，以及，在相同的跨种型关系下、细化非独立实体的目标对象的细化祖代。为了帮助生成证明，来自细化非独立实体的路径应该贯穿其目标对象。这种公式最适合或最便于创建细化关联，其中细化非独立实体没有目标对象(因此不能通过搜索来定位)；或者如果牵涉到从特点项目的组织初始的两个组织，假定是以渐进方式从关联的替代项目导航到两个节点。
接下来，为图132所示的同一个初始DAG，我们修改示例以演示这种替代公式(这次用在refined非独立节点64和细化非独立节点66之间的导航)。用户已经通过66的目标对象(62)探索了共同的祖代(61)，以及64的目标对象。操作之后得到的DAG仍然如图133所示。
图135中和图136展示的是，为了通过该公式创建作为本地的现有实体间细化关联而实现的现有节点0116(作为本地)之间的细化客户方DAG增广的过程。再次重申一下，如有必要，将被细化节点与细化节点区分开来，这里是指作为本地的节点。如果此前尚未阐明，要尝试在上下文中揭示被细化本地节点的目标对象，作为被细化本地节点和细化本地节点的共同祖代，然后确认细化本地的目标对象在它指向的被细化本地的目标对象的路径上。使用Generate Proof Path 0113来生成作为细化路径的证明，这个细化路径是从细化节点(被复制)的目标对象到被细化节点(被复制)的目标对象。然后继续使用现有节点0126之间的细化原子DAG增广来创建关联(如在增广DAG链接细化客户端子结构中所述)。
通过这种方法，上面提出的同时跨种型增广和专业化或泛化通常可以作为两部分过程来指导：首先创建跨种型增广，然后添加相关的细化。此时，实施例可以选择或不选择从包括具体化的过程中阻止增广操作，无论是在客户方还是服务器方或两者兼有的层面。
防止发生闭环
如果通过在任意节点处的实体之间创建链接，或者将子树从一个节点移动到另一个节点(如“切割和粘贴”中所述，这种移动需要剥离一个链接并创建另一个链接)，就可能制造一个环。实施例不希望用户在探索子结构或上下文时处于通过相同实体无休止滚动的状态，于是可能采取各种步骤来阻止它发生。
当链接是由子结构中的子代到指向本地(节点)或上下文的路径上的父代创建的情况下，或者类似情况下，由1)位于本地(节点)至父代的路径上或2)位于子结构中的子代到位于上下文中的父代，则没有制造环的危险。另外，如果两个节点都有目标对象，则约束检查可以阻止环发生。然而，这些保证在其它情形下可能不起作用。
当在任意节点处链接实体时，用于防止循环的一种方法是，在请求创建从一个节点到另一个节点的链接时，寻找其它节点的同时，对将要作为父节点的节点的祖辈进行搜索，或者对将要作为子节点的节点的后代进行搜索。如果遇到了，建立链接会制造一个环，所以链接操作不应该在没有纠正问题的情况下进行。
如果要链接的实体位于本地节点处，则它们的子结构和上下文已经至少部分地被传递给客户(参见[0328])，以便可以发起搜索。如果DAG不是很大，那么执行此搜索是比较合理的，在必要时触发延迟访问，但否则可能不是很有效。如果实体不在本地节点上，则服务器需要执行环搜索。
实施例可能会不执行任何检查，因此导致造成环。在这种情况下，环可以在事后被检测。可能不希望在本地(非延迟的)DAG中造成环，因此实施例可能想要防止这些。这涉及检查初始DAG中实际的环，以及展开延迟节点，并且在允许任何链接操作之前检查潜在的环。实施例可以安排在客户端或服务器上执行这些检查。
处理初始DAG过程中和展开延期节点时的检查的一个选项是让客户端在展开过程中检查环。客户端可以通过下述检测环：在展开关于本地节点的上下文时，检查从本地节点到被展开节点的子结构的元素(包括本地节点或对应的实体)或上下文中路径，反之亦然。这只是在这期间第一次展开节点时是必需的。如果用户端请求本地节点之间的连接，则客户可以像在[0523]中那样但不扩展任何延迟节点而检查潜在的环。如果客户端识别出任何环，它应该将问题通知服务器，并将违规路径传给服务器。然后，服务器可以验证该路径确实是全局DAG中的一个环。一些实施例可能让服务器中断环，而另一些可能会禁止该操作。服务器可能会选择一个由最不信任的用户创建的链接来中断。它也可能会通知各个项目的管理员，以便他们就问题的出处达成共识。
服务器也可以在向客户端发送本地化的DAG之前，或者在发送扩展延迟节点的结果之前，执行类似的初始化检查。
如果多个客户端在相同的初始深度处请求相同的本地节点而没有中间链接，则不需要多次进行相同的环检查。在这些情况下，服务器可以为每个实体保留一个“安全深度”，以指示在该深度内是否有可能发生环。每次请求(或创建)新实体时，增广该结构；并且在该节点已经证明在更大深度处安全之后，递增深度。如果所请求的节点/深度已经被确保安全，则不需要检查环。如果深度范围内的节点已链接，则服务器可以重置两个节点旧的安全深度内所有轨迹记录的安全深度。
附加的项目结构
附加的问题结构：数据度量
在“通用数据集”中讨论了如何使用数据库的源、备选的数据项必须具备的条件、以及从这些数据项提取的属性值的表达式来定义数据集，以及数据集如何可能与项目相关联、并根据用户对本地化DAG的探索进行并集。或者，数据集可以更密切地与特定问题对齐，使得问题完全由增加的或减少的特定属性值组成。我们将这种数据集的规范称为数据度量。如上所述，使用数据度量，每个节点与一个可以返回特定数据项的特定属性值的查询相关联。然而，细化的数据量度的项目集合对于各种实施例将是被细化的数据量度的子集。因此，如果一个数据测量细化另一个，则这些实施例将包括与较少的选定项目相关联的属性值。例如，特定的数据衡量问题可能与提高特定人口群体的收入有关，例如老年人，少数民族，或者同时细化两者，即少数群体老年人的收入。细化数据度量也可能提取附加属性值。数据问题可能需要说明问题是涉及增加还是减少该属性。向上和向下指向箭头可分别并入这些数据度量问题的图标中。
作为条件的可允许结构的示例，它们可以是对个体属性值的限制或这些的任何嵌套的合取或析取。术语可以引用数据库，表格和属性。条件的结构可以在各实施例之间变化。一个简单的语法如下：
Figure GDA0003513598160000771
Figure GDA0003513598160000781
或和与的列表是无序的，但是可被施以标准排序。下面尽快解释一下允许的空标识作为一个连接或一个术语。
一些实施例可以灌输额外的约束来减少任何施加的排序的表示的数量。一个要求与和或具有至少两个元素并要求提供它们的替代的语法如下：
Figure GDA0003513598160000782
以上语法中术语的定义并没有改变。
希望维持这种约定但允许用户执行违反它的操作的实施例可以如下应用规则来恢复约定：
Figure GDA0003513598160000783
在最后两条规则中，MotivatedProblem2细化了MotivatedProblem1。这些规则删除了单例集合、非交集的嵌套集合、嵌入的空条件、和冗余术语。其它规则可能会使用上述标准排序对ConditionLists进行排序。为了方便，我们在这里切换到用于计划的前缀说明。
修改此或上述语法使之更自然地将取反视作通常条件的实施例需要在奇数的反式内将与作为或处理，反之亦然，以达到通过其生成细化条件的规则。
在这个方向上进一步研究，可以以析取范式(DNF)、合取范式(CNF)、或任何其它规范来维护条件。允许以上述简单语法形式进入并维护条件，但检查一个条件是否细化另一个条件可能需要将它们转换为正常范式。一个析取范式DNF的语法如下：
Figure GDA0003513598160000791
数据度量问题只能通过另一同极数据度量问题(或至少具有可能扩展，以及可能更多的数据度量)来说明。对各种实施例，细化的数据度量问题要具备约束所选项目的条件，其至少与被细化的数据度量问题一样具有限制性。
“附加解决方案结构：计划”中描述的计划的条件与状况之间存在一些相似性，并且许多相同的设计选项是相关的。与条件不同，计划没有极性，也没有取反的概念。
数据度量可以是一种特殊类型的问题，可以细化一般的问题，或细化任何可能有潜力添加数据度量的问题
当细化多个解决方案时，实施例可以很好地检查其条件的一致性。当用具体化或概括化现有问题节点的新问题节点来增广DAG时，实施例应理想地分别提供被增广问题节点的条件的GLB或LUB，允许用户分别编辑它们令其更为严格或更为宽松。这些可以通过将GLB表达为X∧X'的形式或将LUB表达为X∨X'的形式并应用简化规则来恢复适当的形式来计算。或者，可以根据实施例要求的条件形式导出直接计算。例如，如[0530]所示,实施例可以以如下方式将条件具体化以保持交替。如果多个条件是一个合取或一个项(单例合取)，形成其合项的合取，则去掉任何从另一个合取中泛化项的条件。然后，将每个析取包括进来，作为一个附加的合取，去掉任何同等或比其它更严格宽泛的析取，具有额外或更多的一般析取或者缺少某些合取或具有其它更具体的。按照532维护析取范式(DNF)无论是否先采取先前步骤，实施例都可以将每个条件视为合取中的析取，并形成其合取的元组(将术语视为单个合取)。按照增加长度的顺序排序，并去掉任何包含早期元组的所有合取(或合取的概括)。条件可以形成为合取的析取，每个元组提供一组合取。泛化条件的过程类似，颠倒合取和析取，以及泛化和专业化。
一种可能性是存储具有每个数据度量问题的完整条件。这避免了动态形成条件的一些复杂性。一个明显的缺点是需要的空间量。然而，还存在一个问题，即在条件被修改的情况下，维持条件间所需的细化关系(从数据度量问题的细化层级结构导出)。只要简单地坚持不得违反条件，就非常容易保持条件的关系。如果一个条件被编辑为更具体(可能使用下面的操作)，则要用其细化子代来检验，以确保它仍然比子代中的每一个都更宽泛；如果它被编辑为更宽泛，则需要根据其细化父代验证结果，以确保它仍然比父代中的每一个更具体。因此，如果条件(或条件的一部分)在对数据度量问题的一系列细化中被设定，且稍后需要在每个位置中被改变，则用户可能需要分别修改其中的每一个：如果是具体化的规程，则从最具体的到最宽泛的；或者，如果是泛化过程，则从最宽泛的到最具体的。使该过程自动化可能更实际。在具体化某个条件时，采用这种方法的实施例可以通过数据度量问题的细化后代传播该具体化过程，直至其条件至少已经足够具体的叶端或数据度量问题。类似地，在对条件进行泛化时，它们可以通过数据度量问题的细化祖代来传播该泛化过程，直至到达其条件至少足够泛化的叶节点或数据度量问题。在将对一个X项做出的改变应用于另一个术语X'时，在专业化的情况下，实施例可以用X和X'的GLB或者在推广的情况下用它们的LUB替换后代术语X'。和一样。这也将允许在现有数据度量问题之间创建细化关联，其中细化问题的条件，通过在任一方向上传播，都不会来细化被细化问题的条件。这些方法中的任何一种都可能需要更改仅为本地节点才允许的条件，以便子结构和上下文DAG可用，或者要求仅在服务器上执行操作，并通知客户端任何违反细化关系的操作或所有发生于条件的必要变化。
替代方案是将条件组件视为实体，彼此相关并且与数据度量问题相关，并且遵循继承。因此，实体可以包括合取和每种项(如果保持析取范式，则可以隐含析取)。条件组件可能支持各种关系：组件关系，表示上面提到的语法结构；细化关系，对应于条件组件的特化/泛化；表示在细化条件下在目标节点下重新定位子树的运动关系，以及操作数关系，表示可以某种方式操纵特定条件组件以产生一些未明确识别的条件组件的组件关系的概括。特定数据度量问题的条件可以通过跟随其组件后代来构造。所有条件细化关联应该被认作重述(如在原地迭代中所描述的)，因为如果显示细化条件则不需要显示继承的被细化条件，并且如果对无关的问题，则不需要显示细化条件。一些实施例可以将条件信息与问题是本地节点的本地DAG集成。在这种情况下，显示与本地问题节点的祖代或后代相关的重述条件组件，移动关联和操作员应用程序是自然的。一些实施例可以将局部问题DAG与局部条件DAG分开，后者仅包含局部问题DAG的本地节点的条件的分量。这些实施例仍然可以维持集成的本地DAG或其修改版本，以便能够如下面[0556]中所描述的那样实现数据的动态探索。
由于在被集体细化的问题条件下执行隐式GLB，可以通过放置在条件结构中的标记来发信号通知具体化操作。专业化操作可能如下：
Merge Disjuncts合并析取算子(合取)这个与计划的合并排序有关的操作，可以是用户在同一析取中细化继承的合取(从基节点启动操作并选择其它)的形式。在析取范式(DNF)中，析取算子的形式总是合取，但在更一般的设置中也是如此。在本地化DAG中，所选合取的合取算子将被移至基节点合取，删除重复，然后选定的合取被删除。在全局DAG中，一个新的连接重新声明每个继承的连接，以便它可以继承它们的后代。
Remove Disjunct删除析取算子此操作与计划无关。这可以采取用户删除继承的析取算子的形式。在析取范式DNF中，这种析取算子可能总是合取，但在更宽泛的设置中，它们可以是任何条件表达。在全局DAG中，对于本地节点问题，该析取算子由一个空项重述，无需向任何用户显示。
Add Conjunct(terms)添加合取算子(项)此操作与计划的Add Unordered Leaf(添加无序叶节点)相关。在DNF中，这可以采用用户使用新项来增广继承连接的形式。实施例简单地将新项作为其父项下的构造放置在本地化DAG中，但是在全局DAG中，将该项设为根据本地问题重述原始项的新合取下的构造。除了继承其父代的算子之外，这个新合取可以在新项上运行。在更宽泛的设置中，相关运算操作可以用于在空状态(不需要创建一个合取)中生成初始项，或者用自身的合取和新项来替换一个项。
Specialize Terms细化项此操作涉及重述计划的启动问题。如果一个项与第二个项一致并且包含至少同样多的信息，那么这个项就会细化另一个。项的细化可定义如下：
a>m refines a>n如果m>＝n
a<m refines a<n如果m<＝n
a＝m refines a>n如果m>n
a＝m refines a<n如果m<n
a>m refines a≠n如果m>＝n
a<m refines a≠n如果m<＝n
这个运算操作可以采用用户优化继承项的形式，运算操作从其中任何一个项开始，同时从同一个合取中选择任何其它项。用户将编辑继承的基本节点项，将本地DAG中的选定项替换为细化项，但在全局DAG中创建每个项的重新优化。每个父项的细化可以由服务器以及可能的客户端验证。如果客户端执行验证，它可以向服务器指示应用了哪些项细化规则。
Conjoin Disjuncts合并析取算子此操作与计划的Impose Order(强化秩序)相关，在析取中键入合取。它不适用于析取范式DNF(无首先重新制定)，除非是在AddConjunct下处理的简单案例。用户可以在选择要合并的析取后启动此运算操作。在本地DAG中，这些可以被移去作为新合取的子代节点，该新合取是作为析取的子节点创建的。在全局DAG中，可以将合取创建为新析取下的构造，该析取根据本地问题重置原始问题(与AddConjunct一样)，然后从新合取创建“移动”弧直到析取算子，表示他们是退回到合取。对于存储关于在运动弧上执行操作的本地问题的实施例，这可能更直接，如[0438]中对于重置细化的说明所示。
Embed Conjunction嵌入合取此运算操作与计划的Embed Order嵌入顺序相关，将一个合取式的析取算子推到同源析取算子的析取后代里。它不适用于析取范式DNF(在没有首先重塑)，但适用于更宽泛的设置。用户启动运算操作，指定对象合取和目标析取，这两者在子结构中，用作父代析取的合取后代。在本地DAG中，对象被移动成为目标的子代。在全局DAG中，一些实施例可以在它们之间创建指向本地问题的移动弧。
Extract Disjunction提取析取具有适当合取祖代的合取中的析取式算子可以被移去作为该合取祖代的子项。如果没有这样的祖代，可以将其创建为条件的根项。
后两个运算引入“移动”弧。Record Inheritance 2250可以从图87中的修改，以便除了在实施例用重述替换重建节点的情况下，移动弧可以被处理为类似于重述，移动弧的对象节点从其上下文分离并放置在目标节点下。
相应的泛化操作将是：
Split Disjunct分离析取算子(合取)用户可能要求并非所有合取算子必须一起为真，而是它们的各种组合必须在一起。这可以表述为允许用户在被泛化的条件中划分该组合取算子。
Add Disjunct添加析取算子(合取)可以从析取算子开始。用户可以指定每个合取算子。
Remove Conjunct删除合取算子这可以从要删除的合取算子初始。在析取范式DNF中，合取算子一直都是一个项。
Generalize Conjuncts(terms)泛化合取算子(项)这可以从任意项初始，同时从同一个合取中选择任何其它项
Disjoin脱离可以删除紧接在析取下的合取节点。这与Remove Conjunct的不同之处在于，不删除算子，而是将它变成合取的父代析取之中的算子。
Extract Conjunction提取合取具有适当析取祖代的析取中具有合取形式的算子可以被移动为该析取祖代的子代。
Extract Disjunction嵌入析取此运算操作将析取形式的合取算子推入同源合取算子的合取后代。它不适用于析取范式DNF(没有首先重新制定)，但适用于更宽泛的设置。用户启动运算操作，指定对象析取和目标合取，这两者在子结构中都用作析取的父代合取的后代。从目标到父代合取的路径可以传递给服务器，以帮助它验证操作。在本地DAG中，对象被移动成为目标的子代。在全局DAG中，一些实施例可以在它们之间创建指向本地问题的移动弧。
实施例可能需要根据条件的表示形式来调整运算。但是，所有运算必须使条件更具体。因此，他们必须在具体化过程中保留任何假的被细化条件(或在泛化过程中保留细化条件的真)。
运算操作可能在其范围内在一定程度上重叠或被限制以避免这种重叠。例如，支持Merge Disjuncts(合并析取算子)的实施例可以假设至少一个析取算子被结合的是项，因为如果所有都是合取，则应用Conjoin Disjuncts(合并析取算子)和简化将产生与该运算符下相同的结果；并且如果有任何是析取或取反，在应用算符之前可以简化。同样，在合取上支持Conjoin Disjuncts并简化结果的实施例不需要支持Merge Disjuncts。如果强调合取和析取的交替，则可以将Conjoin Disjuncts和Merge Disjuncts视为单个操作。
可以为新的数据度量问题指定任何条件(没有具有数据度量的祖代)。具体化或概括数据度量问题的问题可以定义类似地修改其条件的条件组件或运算操作。授权用户可以添加或移除这些组件或操作。导航到特定数据度量问题涉及将来自各种不相关父项的各种继承组件和运算操作相加地组合以获得用于针对该数据度量问题制定单个查询的条件。在组合的各种运算操作是可交换的情况下，这可以以直接的方式完成。例如，可以在嵌入析取之前或之后合并或删除合取。如果问题一个具有多个细化双亲的细化后代，则各种实施例必须或者防止用户以与后代的其它双亲条件冲突的方式来具体化祖代问题的条件，或者接受子代可以具有不一致的条件。因此，实施例可以不允许修改下列情形的问题条件：1)存在细化子项，或者2)细化后代具有多个细化父项，或者3)仅在修改与其它双亲条件冲突的情况下，或者4)根本不存在
在实体具有多个数据度量父项的情况下，其相关数据库项集应直观地通过首先获取被细化数据度量的项集合的跨种，然后对特定数据度量采用任何具体的附加条件来形成。它是从那组项中提取属性值的。在泛化数据度量时，应首先采用细化数据度量的项集合，然后应用特定数据度量的条件来形成相关项目集。在每种情况下，应用的条件是在该节点或其祖代(在逻辑树中)引入的条件，通过具体化或泛化条件进行修改。可以经任一路径以继承条件组件来模拟此效果。查询结果可以直接通过实施例或通过数据源来得到优化。
用于将条件表示为与数据度量相关的实体并且彼此相关的初始示例DAG如图137所示。它有六个数据度量问题节点(80到85)，表示为圆形，预定义以点80的包含两个合取的析取组成的条件，第一个有两个项，第二个有一个项。我们将外部析取视为隐式(对于DNF而言可能是自然的)，并用它们的标准符号和带有包含其内容的矩形的项表示合取。小写字母表示属性名称。从项节点到合取节点的弧用“c”标记为“构造”。节点80与条件((x＝5)∧(x>3))∨(y＝2)相关联。图139示出了数据度量问题81，细化问题80，继承两个合取。如果通过使用上面的第一和第五项细化规则,应用专业术语将第一个合取的两个项(x≠5)和(x>3)细化为(x>6)，则局部化结果如图140中所示。节点81与条件(x>6)∨(y＝2)相关联。图141示出了数据度量问题82，细化问题81，继承修改后的合取。如果第一个合取(现在是微不足道的)x>6是通过应用Remove Disjunct删除，本地化结果如图142所示，第一个合取用空符号替换。空符号和其下的项都不会对用户可见。与节点82相关的条件是简单的y＝2。相反，如果我们条件细化为节点83细化节点80，如图143所示，类似于图139，但是应用规则AddConjunct到第二个合取以创建新项z≠3，局部结果如图144所示。节点83与条件相关((x≠5)∧(x>3))∨((y＝2)∧(z＝3))。图145示出了数据度量问题84，细化问题83，继承两个合取。如果通过应用规则Merge Disjuncts合并两个合取，则结果如图147中所示。节点84与条件相关联(x≠5)∧(x>3)∧(y＝2)∧(z≠3)。最后，数据度量问题节点85细化82和84。它被赋予条件(x>6)∧(y＝2)∧(z≠3)，其下限但不是最大下限的条件各自的双亲。我们会看到最大下界((x≠5)∧(x>3))∨((y＝2)∧(z≠3))也可以获得。
在所有这些操作之后，从全局或从节点80得到的结果如图146中所示。条件节点之间的弧标记为“R”，如果它们被认为是对细化数据度量的先前条件的重述(使用上述规则之一)。注意，在从节点82移除第一个合取时，创建空合取节点作为关于节点82的第一个与节点的重置。还要注意，在节点83的第二个合取中创建附加项z≠3时，有一个中间合取节点，它重置对节点83的父代合取，并在其下构造新的项。现在，使用Record Inheritance2250导航到节点81,82,83,84或85中的任何节点，类似于图87的记录,给出了如图148,149,150,151,或152中的局部DAG子结构。重要的是，通过此过程组合的条件组件与条件细化规则的本地应用所产生的条件组件相匹配。例如，节点80仍然与条件((x＝5)∧(x>3))∨(y＝2)相关联，其可以由仅用“c”标记的80的后代构成。在节点82处不可用的删除的合取由85到84继承，因此节点85处的条件保持为(x≠5)∧(x>3)∧(y＝2)∧(z≠3)。
另一个初始示例DAG在图154中呈现。这里，项简单地表示为下标变量，并析取定义明确。节点90与条件(t0∨t1∨(t2∧t3)∨((t4∨t5)∧t6))相关联。图156示出了数据度量问题91，细化问题90，继承完整条件表达。如果通过应用Conjoin Disjuncts将两个顶级解析项t0和t1“联合”到(t0∧t1)，则局部化结果如图157中所示。如果相反，我们将节点92细化节点90的条件具体化，如图158中所示(与图156类似)，但将合取嵌入规则应用于顶层析取的第一个子合取作为源，并应用于其第二个子合取的子析取作为目标，本地化结果如图159所示。节点92与条件(t0∨t1∨((t4∨(t2∧t3)∨t5)∧t6))相关联。最后，数据度量问题节点93细化91和92。它还与条件((t0∧t1)∨((t4∨(t2∧t3)∨t5)∧t6))相关联，即两个双亲条件的最大下界GLB。
在所有这些操作之后，从全局或从节点90得到的结果如图160中所示。条件节点之间的弧标记为“R”，如果它们被认为是对细化数据度量的先前条件的重述，或者如果它们表示基于从箭头开头指向箭头尾部节点的条件表达的子树的一种运动(使用上述规则之一)，则标记为“M”。注意，在从节点91创建附加合取(t0和t1)时，存在中间空项节点(对于用户不可见)，其由新合取节点于节点91重述。现在，使用Record Inheritance 2250导航到节点93，类似于图87，如图162给出局部DAG。
一些实施例可以以[0529]或[0530]或相似的的语法的形式存储由算符应用产生的附加条件结构,也存储如上概述的标准重述、移动弧、和空节点；而其它实施例可以选择存储如[0570]中的算符的应用，更直接地作为条件组件，具有到它们的运算数的弧。在这种情况下，条件运算符应用节点也指向它们所应用的问题，并且每个运算符的语义将在RecordInheritance2250中实现。空节点
Figure GDA0003513598160000851
可以被视为对单个运算数的删除运算符的表示。图161是一个具有算符节点的图160的替代版本。中间形式将运动本身视为一种运算操作，并包括三个这样的节点。运算操作可以指向运算符应用节点作为运算数来完成级联。运算符应用链可以通过Record Inheritance 2250构建在所选语法中表达式来执行。解决方案的多重继承(即，关系细化解决方案是多对多的)将要求对被细化解决方案进行排序，或者优选地，细化解决方案的算符应用不依赖于被细化解决方案算符应用的执行顺序。在上面的第一个示例中，我们有规则Remove Conjunct和规则Merge Disjuncts涉及同一节点。有点违反直觉，当在集成这些由节点85继承的运算操作时，该实施例合并了一个删除合取，新的组合合取包括删除的父节点的合取运算数。绝对不能确定能成功找到被细化节点的条件的解决方案(除了条件总是假)。
实施例可以获得具体化多个父节点的节点，例如在具体化节点82和84中的85，既被细化节点条件的最大下界。通过标记与它们相关的问题节点的继承条件组件和操作，只有在被所有父节点删除时，实施例在可以在专用节点的条件下删除节点。类似地，如果仅由删除该节点的父代进行，则实施例可以忽略该项特化。
如[0385]中所述，继承条件组件的一种结果是仅部分信息可用，这样的事实是无法接受的。数据度量的任何问题都可能需要在继承过程中搜索其上下文以查找条件定义，只要根条件可以如此识别，实际上不应该过多。
如果存在多个属性提取表达式，则它们可以单独显示或以某种方式组合/聚合。如果将一个或多个表达式键入为位置，则其余表达式可以以地图形式呈现，如[0742]所述。如果其中一个表达式被输入为时间戳，则可以通过动画显示其余表达式。更一般地，如果表达式中的一个或多个是连续量，则其它表达式可以在图表上呈现为具有这些表达式的值作为轴的图。定量值可以受标准聚合，例如计数，总和，平均值，最小值和最大值等。这些表达式可用于表示派生属性值。例如，问题可能涉及最小化两个人口群体之间的收入差距。这可以指定并计算为每组平均收入之间的差异。评估属性提取表达式的结果通常最好地表示为具有各种周期性的基于时间的信息。
对于不想多次计算相同项目的实施例，仅边界定义或由边界继承的数据集(即，子结构或上下文树的叶子集合)与聚合相关，并且该聚合应该是为子结构和上下文树单独执行。即使这样，也可以注意避免通过多个叶节点重复计算相同的项目。如果上下文和子结构都包括数据度量问题，则实施例可以计算和表达与下列项目相关的属性值：1)与由子结构边界指示的项目，2)由上下文边界指示的项目，3)由上下文边界指示的项目与由子结构边界指示的项目之间的差异，或4)这些的任何组合。
问题仍然是如何组合为数据度量父项而提取的属性值，尤其是当它们涉及不同属性时。这可以通过各种方式完成，包括如果极性匹配则求和或相乘，如果不匹配则减去或除。某种形式的加权平均值通常是合适的。可以自动确定加权系数以正常化各种属性对平均值的影响(可能通过维持代表性属性值)，由用户或某种组合明确设置。
无论是存储每个问题的完整条件还是存储和继承条件组件，我们都会获得每个数据度量问题的条件，这足以提供与任何本地节点相关的数据。可以逐步构建演示文稿。而不是让客户端递增地应用Record Inheritance 2250，例如从图148到图149到图152，或者从图150至图151至图152在上面的第一个例子中，然后解释结果，实施例可以安排将问题之间的细化关联标记为它们的条件的差异(表示为对所选项目的必要减少)。创建细化关联时，服务器可以执行此标记。如果每个数据项都用它满足的析取集标记，那么如果特定析取中的项由细化问题具体化，则在扩展子结构以揭示该问题时，为了获得其数据项集，实施例需要仅考虑从仅满足该分离的父数据项集实体中删除(尽管实施例可以重新计算满足该析取算子的任何实体)。类似地，在签订子结构以便隐藏该问题时，实施例仅需要考虑在决定包括哪些附加实体时的析取算子。还可以为内部节点维护为每个内部节点选择的数据项或属性提取结果，以便在签订子结构时可以快速恢复它们。类似的概念适用于上下文的探索。图153给出了第一个条件示例的标记全局DAG。在节点81处应用具体化术语会导致删除从第一个析取算子唯一可到达的所有项目的指令，除非不满足新项。在节点82处应用RemoveDisjunct会导致指令从第一个析取中删除所有可以无限制地访问的项目。在节点83处应用Add Conjuct会导致删除从第二个析取算子唯一可到达的所有项目的指令，除非不满足新项。在节点84处应用Merge Disjuncts迫使实施例将析取作为合取处理，导致指令丢弃不满足两个析取的所有项目。这样的标记可以保持，因为双亲的条件相对于子代被细化，并且实际上，对于其它弧，当添加新的时候(通过概括或通过链接现有实体)更一般的问题。当多个父数据测量问题被细化时(如该示例中的节点85的构造)，每个细化关联可以用所选项的充分减少来标记，以理想地从每个数据度量问题中产生它们的最大下限。在加法运算符的情况下，这可能只涉及填写任何给定父级“缺失”的操作。因此，对应于应用Add Conjunct forz≠3的权限的减少被复制到左边，就在到达节点85之前。删除析取算子的处理方式不同。由于它只出现在左边而不是右边，并且所讨论的析取物在右边合并，为了达到GLB条件，可以加回删除的析取物的合取，并且因为具体化仅与删除的析取物有关。它不需要包括在内。这导致不符合资格的那些不满足x≠5和x>3的项目。
这些增量操作可以在客户端上或在服务器上执行，并且响应于用户探索命令或者在它们之前执行。
与计划一样，为了在现有问题之间创建细化关联，实施例可以验证它们的条件之间(在相同方向上)的逻辑细化并且可能丢弃细化问题的任何冗余条件。其它人可能希望这种链接使被细化节点的条件可用于细化节点(只要它们相互一致)。前者更适合存储每个问题的完整条件，后者存储条件组件。但是，在问题具有数据度量并且细化问题定义新数据度量的情况下，情况更类似于存储完整条件的情况，并且应该如此处理。
其它解决方案结构：计划
一些实施例可以对由解决方案驱动的一些问题施加排序。它们可以被认为是完全无序的，完全有序的，或任何有序和无序集合的嵌套。一个简单的语法如下：
Figure GDA0003513598160000881
一些这样的实施例可以引入额外的约束以减少任何强加的排序的表示的数量。动机问题可能被认为是无序的，或者是有序的，或者是两个或更多元素的有序和无序集合的交替嵌套。语法如下：
Figure GDA0003513598160000882
对于简洁，上述语法是模糊的。也可以对UnorderedPlanArgss施加标准排序。
一些这样的实施例可以允许用户采取使得OrderedPlanArgs或UnorderedPlanArgs具有少于两个计划，违反交替约束等的动作。他们可以施加简化规则来恢复这些约束：
Figure GDA0003513598160000883
Figure GDA0003513598160000891
在最后两条规则中，MotivatedProblem2改进了MotivatedProblem1。这些规则删除单件集合，非交替嵌套集合，嵌入空计划和冗余动机问题。附加规则可以使用如上所述的标准排序对UnorderedPlanArgs进行排序。
应当注意，将时间估计与为实现而选择的每个解决方案相关联以解决MotivatedProblem使得该结构能够表示甘特图并且可以如此显示。
如果解决方案没有明确的计划，则假设其具有其动机问题的无序规划。
如果解决方案具有计划，则对于各种实施例，细化解决方案将具有至少具体的计划，例如至少具有被细化解决方案的动机问题和至少相同的排序约束，并且可能更多。
在“附加问题结构：数据度量”下描述的条件下，计划与情况之间存在一些相似性，并且许多相同的设计选项是相关的。与计划不同，条件没有任何排序。该部分中的广泛示例应提供有关计划的直觉。
计划可能是一种改进更一般解决方案的特殊型解决方案，或者任何可能有潜力有添加计划的解决方案。
当细化多个问题时，实施例可能检查其计划的一致性。如果一个计划要求一个特定的动机问题先于另一个,同时另一个计划要求一个特定动机问题跟随另一个，则计划是不一致的。当使用具体化或泛化现有解决方案节点的新解决方案节点来增广DAG时，实施例应理想地分别提供增广解决方案节点的计划的GLB或LUB，允许用户分别编辑它们达到或多或少地严格。对于一些实施例，多计划的GLB将具有其动机问题的结合(但是在细化的动机问题处，略去更多被细化动机问题)以及对这些问题的排序约束的结合。这可以通过在单个无序计划中收集无序计划的所有元素以及有序计划本身来实现。然后可以通过分解公共前缀或后缀来改进表示。因此，给定一个计划
Figure GDA0003513598160000901
可以得到
Figure GDA0003513598160000902
K,∥(X,Y)),这可以如果A和B,或X和Y处于细化关系中，则进一步简化。给定一个计划
Figure GDA0003513598160000903
Figure GDA0003513598160000904
可以得到
Figure GDA0003513598160000905
在抛弃的动机问题而不是改进它们的动机问题时，在本地执行细化检查并且随着延迟问题节点的扩展而逐步增广它们并没有太大的危害。对于一些实施例，多个计划的LUB将具有它们的动机问题的跨种(但是减少了动机的问题而不是它们改进的动机问题)以及这些问题的排序约束的交集。上面将无序计划隐含地视为合取，但是一些实施例可以通过明确地支持合取和析取来获得更高的精度，就像[0536]中的条件一样，但是合取具体化析取以及有序计划具体化合取。
一种可能性是用每个解决方案存储完整计划，类似于具有[0537]条件的情况
替代方案是将计划组件视为实体，彼此相关并与解决方案相关，并且可以继承。因此，实体可以包括有序和无序的集合以及有动力的问题。计划组成部分可能支持各种关系：组成关系，表示上面提到的语法结构；细化关系，对应于计划组成部分的具体化/泛化；表示在计划中的目标节点下重新定位子树的运动关系，以及操作数关系，表示可以某种方式操纵特定计划组件以产生一些未明确识别的计划组件的组件关系的概括。特定解决方案的计划可以通过遵循其组件后代来构建。所有计划细化关联应被视为重述(如在就地迭代中所述)，因为如果显示细化计划，则不应显示继承的细化计划，并且如果是用于细化计划，则不需要显示细化计划。无关的解决方案。一些实施例可以将计划信息与解决方案是轨迹的本地DAG集成。在这种情况下，显示与轨迹解决方案节点的祖代或后代相关的重述计划组件，移动关联和操作员应用程序是自然的。一些实施例可以将本地解决方案DAG与本地计划DAG分离，后者仅包含本地解决方案DAG的轨迹的计划的组件。
由于对集体被细化的方法的计划执行隐式GLB，可以用在计划结构中的标记来通知具体化运算操作。实施例可以向用户提供用于操作计划的特定运算，该计划施加额外的结构并因此用于细化解决方案：
Merge Orderings合并订单这可以采用用户在同一个无序计划中细化继承的有序计划(从基节点启动操作并选择其它计划)的形式。与条件中的相应操作Merge Disjuncts不同，用户可以提供关于来自备选有序计划的元素的相对排序的附加信息。例如，实施例可以允许用户拖动到基本节点有序计划的元素之间的位置，剩余有序计划的每个元素。在本地DAG中，所选订购计划的元素将移动到基本节点订购计划中的适当位置，从而避免重复，并删除所选的已排序计划。在全局DAG中，新的有序计划重新声明每个继承的计划，以便它可以继承它们的后代。在这种情况下，需要一种特殊形式的重述，以提供额外的订购信息，例如细化订购计划的每个要素的较大的细化订购计划中的位置。
Add Unordered Leaf添加无序叶如果计划结构为空，请将其替换为给定的问题。如果计划结构是MotivatedProblem或OrderedPlan，则将其替换为包含两个元素的新UnorderedPlan。如果计划结构是无序计划，只需将新术语作为其父项下的构造放在本地化DAG中，但在全局DAG中安排该术语作为新的有序计划下的构造放置，以重新尊重原始到了轨迹问题。除了继承其父级的操作数之外，这个新的有序计划可以在新术语上运行。
Specialize Motivated Problem具体化的动机问题该操作不需要明确，因为它已经可用。用户只需重述细化解决方案继承的动机问题。
Impose Order强加顺序此操作对UnorderedPlan的元素进行排序。用户可以在选择要订购的无序计划的子项后启动此操作。这可以表述为允许用户查看现有的无序列表和新的空的有序列表，并拖放，将所选元素从第一列表复制到第二列表中。可以按照复制的顺序将元素插入到第二个列表中，或者用户可以将它们拖动到新列表中的特定位置。或者，用户可能只查看包含已复制的所有元素的新列表，并允许交换或重新排序元素，以及删除元素。在任何情况下，一些实施例可以在本地DAG中用这些元素的单个OrderedPlan替换某些元素，这可能需要简化。在全局DAG中，可以将OrderedPlan创建为新的UnorderedPlan下的构造，该构造根据轨迹问题重新设置原始问题(与AddUnorderedLeaf)一样，然后从新的OrderedPlan创建“移动”弧到UnorderedPlan的元素，表示他们被认为是向下移动到OrderedPlan。对于存储对运动弧执行操作的轨迹解决方案的实施例，这可能更直接，如[0438]中的重述改进所示。
Embed Order嵌入顺序此操作采用一些现有的排序并将其更深入地推入结构中。这可以如下表述。用户可以选择OrderedPlan作为对象，然后选择作为目标的UnorderedPlan，它们在子结构中都可用作有序计划的父无序计划的后代(假设有序和无序计划的更改，否则是最近的无序计划祖代)，以及目标未包含在所选对象中。在本地DAG中，对象被移动成为目标的子对象。在全局DAG中，一些实施例可以在它们之间创建指向轨迹解决方案的移动弧。如果放宽对目标选择的约束，不再要求目标从作为对象父级定位的UnorderedPlan下降，则该操作可能不再用作解决方案细化。
后两个操作引入“移动”弧，如[0540]中所述。
相应的泛化操作将是：
Split Ordering拆分顺序用户可能要求不必相对于彼此对有序计划的元素进行排序，而是必须对它们的各种组合进行排序。这可以表述为允许用户将有序计划的元素集划分为泛化。
Remove Plan删除计划这可以从要删除的计划开始。
Generalize Motivated Problem泛化动机问题已经支持重述问题的泛化(参见“泛化，重述和迭代”)。
Forget Order忽略顺序可以删除紧接在无序计划下的有序计划节点。这与删除计划的不同之处在于，有序元素不会被删除，而是被生成为有序计划的无序父代计划的元素。
Extract Order提取顺序无序计划中的有序计划具有无序计划适当的祖代可能会被移动为该无序计划祖代的子代。
实施例可能需要根据计划的表示形式来调整计算操作。但是，所有操作必须有助于使计划更具体。因此，他们必须保持有动力的问题的任何失败，以满足排序限制
运算操作可以在一定程度上在其范围内重叠或者被限制以避免这种重叠。例如，支持合并排序的实施例可以假设被排序的无序计划中的至少一个是条款，因为如果所有都是已排序的计划，则应用强制排序并且简化将产生与该运算符下相同的结果，并且如果任何是无序的计划，可以在应用运算符之前简化。同样，在有序计划上支持Impose Order并简化结果的实施例不需要支持Merge Orderings。如果强制执行有序和无序计划的更改，则可以将Impose Order和Merge Orderings视为单个操作。
可以针对没有祖代具有计划的解决方案指定任何计划。使用计划具体化或概括解决方案的解决方案可以定义类似地修改其计划的条件组件或运算操作。导航到特定解决方案涉及将各种继承的组件和操作相加地组合以获得该解决方案的计划。在组合的各种运算操作是可交换的情况下，这可以以直接的方式完成。例如，有序计划可以在嵌入无序计划之前或之后合并。在解决方案具有具有多个细化父级的细化后代的情况下，各种实施例必须防止用户以与后代的其它双亲的计划冲突的方式具体化祖代解决方案的计划或者接受可以使子代具有不一致的方式。计划。因此，实施例可以不允许对存在细化子项的解决方案的计划进行修改，或者细化后代具有多个细化父项，或者仅在修改将与其它双亲的计划冲突或者根本不与其它双亲的计划冲突的情况下进行修改。
可能优选的是，只有一种构造任何语法对象的方式。这对于用户界面级别的运算操作不是问题，因此这些操作可能更具表现力，并且可以转换为[0570]中的操作。例如，可以通过用户界面将叶子直接添加到OrderedPlanArgs中的位置。
虽然一些实施例可以以[0559]或[0560]或类似的的语法的形式存储由运营商应用产生的附加计划结构。如上所述,以及标准重述和移动弧和空节点，其它实施例可以选择存储运营商的应用，例如[0570]中的运算符的应用。更直接作为计划“组件”，弧与其操作数。在这种情况下，计划运算符应用程序节点也指向应用它们的解决方案，并且每个运算符的语义将在Record Inheritance 2250中实现。空节点
Figure GDA0003513598160000931
可以被视为对单个操作数的删除运算符的表示。可以通过将这样的操作符应用程序节点指向操作数来级联操作。可以通过Record Inheritance 2250执行此类继承的运算符应用程序的链，以在所选语法中构造表达式。解决方案的多重继承(即，关系细化解决方案是多对多的)将要求对被细化的解决方案进行排序，或者从优选择，细化解决方案的算符应用程序不依赖于对被细化解决方案的算符应用的执行顺序。一些实施例可以发现标准化UnorderedPlanArgs的排序有助于实现这一点。绝对不能确定成功解析被细化节点的计划是可能的。举一个简单的例子，备用分支对两元素无序计划施加不同的排序，它们不能合并。
继承计划组件的结果是仅部分信息可用，如[0385]中所述。这可能是不可接受的。任何带有计划的解决方案都可能需要在继承过程中搜索其上下文以查找计划定义，只要根计划可以识别，实际上这不应该过多。
支持解决方案细化的实施例可能要求所有细化解决方案的结构与被细化解决方案的结构一致。如果细化解决方案已经强制复制为被细化解决方案添加的结构，则可以将细化结构删除为多余的，或者如果从被细化解决方案中移除结构，则可以保持生效。如果细化解决方案已经施加了与添加给被细化解决方案的不一致的结构，则可以禁止运算操作、或者可以将细化解决方案与被细化解决方案(和任何中间后代)分离并且考虑细化任一被细化解决方案的双亲代。
其它主题
邀请和应用程序连接
支持社会创新
在项目中，项目增广在新实体和旧实体之间会创建“强”关联。应该会生成可以被增广项目的管理员使用的建议，尽管在此过程中，建议的贡献者可能会或不会在新项目中获得管理员角色。
一些实施例还可以支持现有项目之间的“弱”关联。可以使用0516中“DAG细化现有实体”中描述的机制。一个切入点项目管理员可以选择(例如，通过其上下文菜单)邀请更具体的项目(基于项目内容)来细化它或应用于细化更宽泛的项目(再次基于项目内容)。至关重要的是，这种弱细化能够支持解决方案或其它项目内容的继承。
这些关联强度的变化不仅可以涉及项目，还可以涉及其它种类的实体。例如，实施例可以支持组织内的用户之间的强烈“细化”关联，表示例如报告关系或监控指导；(也可以支持)组织之间的用户间弱关联，例如，仅表示监控指导。
系统可以推荐(如“推荐”下)实体以考虑进行弱关联。
在某些情况下，项目管理员或其它用户可以受益于连接组织之间的“鸟瞰”视图。通过关注组织之间的弱链接和凝聚强链接序列，可以突出组织活动领域。这些区域可以附加地或替代地用组织标记，和/或用颜色或其它视觉元素编码，和/或用一条边界线标记与不同组织关联的实体间的组织边界。然后，从其它组织继承的实体可以在继承组织的区域内显示为“岛”。
该功能可以连同已经描述的功能共同作用来支持组织之间的共享。然而，这里引入了第二种形式的关系，并且实施例需要知道它们正在遍历哪种形式。例如，服务器在创建“生态系统”DAG时，可以跳过来自本地节点的所有强链接，除了那些导致与其它项目弱链接的节点的链接。然后，同样地，它可以继续冷凝到任何后续的薄弱环节。在考虑Reduce DAG0210和Record Inheritance 2250中的父或子实体时，应该进行这种“跳过”。这些面向生态系统的DAG可以与标准DAG一起传递给客户端。
在一些上下文中，仅可以看到通过强关联相关的实体。在其它情况下，通过任何关联相关的实都可见。实施例可以包括由弱链连接的实体和/或通过标准DAG及生态系统DAG中的弱链以继承的实体连接的实体，或者仅包括在生态系统DAG中。如果是前者，则用户可以通过类似于“DAG过滤”中描述的选项来控制由标准DAG中的弱链接连接的实体的可见性。
图参照图163至图171是该功能的示例。图163显示了一个问题的项目屏幕“我们如何在人与人之间建立自给自足？”，列出了一个单独的解决方案，“让我们教他们经营企业！”。图164示出了另一个问题的用户屏幕，“我们如何在单身母亲之间建立自给自足？”，由不同的用户Joanna Doe创建，她以管理员身份登录(登录签到的相关示例在0757中)。图165显示Joanna导航到第一个项目屏幕并申请由她自己来说明这个问题。在她的申请被接受之后(通过在线系统或电子邮件中的链接)，对于该实施例而言，来自她的项目屏幕的非独立选项键的视图，随着上下文中的新泛化问题及其继承到子结构中的解决方案，将如图166所示。接下来，Joanna跳出了一个想法，并构建了如图167所示的结构，将问题进一步提升为：“如何在单身母亲之间建立联系开始创业？”。现在，另一个人，Jessica，已经开始考虑一个更广泛的问题，“我们如何在具有共同利益的单身母亲之间建立联系？”。图168显示她的用户屏幕，以管理员身份登记。在图169中，我们让Jessica的项目邀请Joanna来进一步说明它。在接受邀请之后，图170显示了待说明问题的非独立选项键，其中上下文指向一个并最终达到另一个外部泛化问题。来自生态系统键的视图在图171。请注意，只有与其它组织接壤的实体才会出现。其它实施例可以指示中间实体已被省略的位置。这里，对应于相同组织的区域用相同的颜色编码。
建议
系统可以向用户，用户到项目，项目彼此的项目(问题到问题和解决方案到解决方案)或者(在用户关联表示指导的情况下)用户彼此推荐项目。当项目的管理员签入项目时，对项目的建议会被显示他们。
作为示例，首先考虑向人们推荐项目(针对特定角色)。这可以通过找到类似的项目，然后考虑他们在该角色中的身份来完成。也可以通过查看该项目中还有哪些其它人(如果有人)在那个角色中，然后找到类似的人来完成。实施例可以利用两种推荐源，以及通过对项目和个人应用相似矩阵而获得的推荐源。这种情况类似对于kind1实体推荐任何类型kind2的实体(可能是同一种实体)。如果它们实际上是相同种类，则实施例可以考虑方向细化关系(取决于我们想要推荐的方向的方向)来代替跨种型关系。该过程如图172所示。但是，如果两种类型相同，则一些实施例可能仅仅推荐类似的实体。
与其从刚刚提到三种方法中择一用于构建项目排名，某些实施例则更倾向于使用所有这三种方法，并且在合并结果前，基于某一种所用方法(假定是惩罚两种相似性矩阵的应用)采用初始任意加权。
与其仅限于一个角色，也可以考虑其它角色，每个角色同样具有较低(但是否则是任意的)加权。
特别是在搜索结果的情况下，但是同样对于推荐，一旦获得结果列表，过滤出由细化相关联的低等级项目可能是有益的。
否则，建议的过程是相对标准的，具有一些增广。在上述任一方法中，找到类似实体涉及构建向量并应用相似性矩阵。相似性矩阵是来自相同类型的一对实体的映射，其返回它们的相似程度的估计。如果用户具有类似的传记或对类似项目做出贡献，请考虑类似用户。如果项目具有相似的名称或描述或由类似用户提供，则考虑类似的项目。使用诸如支持从任何给定实体检索相似实体的有序列表的平衡树之类的数据结构的向量来表示相似性矩阵可能是有用的。
可以从可以为每个实体生成的特征向量构建相似性矩阵。假设每个相似度矩阵单元格值是特征向量中正向出现之间相似性的度量，这些特征向量既可以过滤也可以通过“惊讶”值进行调整(因此我们希望推荐最令人惊讶的类似项目)，计算为虚线产品除以每个的非零项数的平方根的乘积。对特征向量的这种计算对应于两个向量之间的角度的余弦，并且是标准距离度量。惊讶值可以作为TF.IDF评分来测量。除了作为阈值之外，对标准实践的唯一修改是将其视为线性调整。
对于问题或解决方案，特征可以是单词，所需技能(问题没有所需技能，但如下所述，我们可以考虑相关解决方案)，贡献者和行为。对于用户而言，功能可以是单词，技能熟练程度，贡献的项目和行为。惊讶元素对应于特征值出现的程度。
一个项目中，单词特征的特征向量值是对其在祖代和后代项目(们)的名称(们)和描述(们)中出现的频率(以什么速率)的度量，所有这些都相对于其通常使用中出现的频率或跨越服务器数据库时出现的频率，以诸如名称与描述为加权因子、或以诸如每一个最初任意但读取自文件中的祖代和后代的几个级别为加权因子。之后，高级过程可以通过以修改值测试推荐者来微调加权因子。项目的贡献者特征的价值是项目贡献者或祖代或后代项目的角色(如果有的话)，通过在任何项目中具有此角色或任何角色的贡献者的稀缺性进行调整，以及再次对几个级别的祖代和后代中的每一个的加权因子。技能特征的值与贡献者特征(没有任何角色概念)类似地计算。
用户特征值将用类似方法计算。
该方法整合了协同过滤以及基于内容的推荐。
我们可以举例说明如何改善推荐质量，比如对于项目来说，贡献者特征是指贡献者或类似贡献者在项目中的角色(如果有的话)，以及相似程度。请注意，这些定义是循环的，但我们可以使用动态编程来逐步计算实体特征。
特征还可以包括系统行为，由它们对该实体的共同性和近期性来计算。
当系统行为发生时，应该递增地重新计算特征向量和相似性矩阵。
如其名称所暗示的，对称矩阵通常是对称的，但是一些实施例可以概括它们以基于推荐的方向进行区分。
在相互推荐人和解决方案的特定情况下，实施例可以限制对用户和解决方案的推荐，以使用户具有足够的技能来满足解决方案的要求。尽管某些回应当然是适当的，但是这种过滤可能不合适，因为一般而言，解决方案的技能要求可以通过用户的组合来满足。对于技能要求与资源需求相关的实施例(如[0619]中所述)，可以修改建议以向个人推荐资源需求，其特征向量将与底层解决方案的向量共享很多，但也可能反映-比如说-资源需求描述中出现的词。
在将用户和项目的特征向量中的依赖项目的技能包括在内时，我们赋能在推荐算法中调整加权因子，以优先考虑向高级项目推荐不只是精通该项目所需技能，也精通多个非独立低层项目所需的细化技能的人。
辅助DAG
实施例可以区分主要本地化DAG(提供关于用户已经导航到的节点(们)的祖代和后代的信息)和次要DAG(提供关于与任何主要DAG表示的实体相关的祖代和后代的可能更有限的信息)。这样的实施例可以存储与主要本地化DAG中的每个实体的直接相关实体的引用列表。客户端可以使用这些引用来访问辅助DAG(也由服务器提供)，其实体将通过细化关系相关联
服务器可以使用如[0448]中所讨论的Reduce DAG 0210的多实体扩展，用于构建由各种所选实体关系相关的辅助DAG实体，所述实体与用户已导航到的主DAG的轨迹实体的适当跨种关系相关的实体相关联
基本方法是使辅助DAG包括通过从其本地节点进行细化而可到达的节点，其被设置为与主要DAG的本地节点的跨种关系相关联的节点。
如“用于探索分层结构的方法和其上下文的表示”中所述，实施例可能希望基于主DAG的哪个部分是打开的来显示辅助DAG，作为聚合的形式。可以维持活动，整体和组成聚合。
一种实现此目的方式是使辅助DAG包括通过从其本地节点细化而可到达的节点，其被设置为与不仅是主DAG的本地节点的跨种关系相关联的节点，而是所有节点目前在主要DAG中可见。随着主要DAG的扩展，本地节点被添加到辅助DAG，并且当它被缩略时，它们会被删除
这可以通过服务器将完整的辅助DAG(假设主DAG完全扩展)发送到客户端来实现，该客户端将负责将其逐步定位到主DAG的扩展状态。因此，客户端将修改辅助本地DAG及其相关的视觉展示
更可靠地，客户端可以根据需要请求额外的子DAG。为了避免多次重新发送DAG的公共部分，服务器可以跟踪那些已经发送了的节点和边缘。
基于主DAG的哪个部分是开放来显示辅助DAG的另一种方式是使辅助DAG显示与主DAG中表示的实体相关的实体之间的细化连接。辅助DAG的本地节点被固定为通过与主DAG的本地节点的适当跨种关系相关的实体。在探索主要DAG时，辅助DAG中可访问的实体会增长和缩小，使得它们包括与主DAG中打开的实体相关的实体。这可以通过在辅助DAG的每个元素上放置表示其当前是否可访问的二进制指示符来实现，并且仅在确定逻辑树中的节点的子节点时考虑可访问节点。
当打开主DAG文件夹时，实施例可以用与刚刚显示的实体相关的实体来扩充活动辅助DAG的可访问却还没被访问的部分。但是当主DAG文件夹关闭时，实施例将不知道与隐藏的实体相关的实体是否也被仍然可见的其它实体引用，因此可能需要重新计算辅助DAG的可访问部分。
为了有效地处理这一点，实施例可以通过适当的关系为每个次要实体维持与其相关的主要实体的关系。当主DAG文件夹关闭时，从辅助DAG信息的可访问部分收回有关相关实体的信息，将不再可通过其余开放主DAG节点的直接关联访问。
例如，考虑各种解决方案需要的技能。这些技能本身可能与子技术有关，更一般的解决方案需要更多的一般技能。除了将这些技能作为主要项目DAG的一部分之外，实施例可以呈现辅助DAG，突出显示在主DAG中打开的解决方案所需的技能，或者通过将辅助DAG限制为那些实体或者通过处理那些实体作为轨迹节点。
作为另一个示例，如果主DAG表示组织层次结构，则可以查看层次结构的各个区域内的技能熟练度并探索它们之间的子技术的关系。或者相反，如果主要DAG代表技能层次结构，则对于层次结构的各个区域内的技能，可以查看需要这些技能的项目或精通这些技能的用户并探索它们之间的关系。
资源
实施例可能将资源需求类型与解决方案相关联起来。资源可以是人，组织机构或其它可定制的种类，例如设备，计算机软件或化学或生物解决方案。实施例也支持根据需求向解决方案分配资源。
这样一来，用户可以作为人力资源被分配给解决方案。对于这样的实施例，分配的用户将承担协作者的角色。现金也可作为捐助者或投资者([0729])提供的资源，并在项目内转移(如“预算支持”中所述)。
对于仅支持人力资源(与其它资源相对)的实施例，资源的种类不需要非常明确，只有位置的数量是关注的重点。对于许多实施例，技术需求可以作为人力种资源的一种。在这种情况之下，技术需求可以不与上述的整个解决方案相关联，而是与其每个人力资源的需求相关联。对于计算机程序，资源需求可以是以UML图或其它程序规范的形式存在。分子资源的类型可以是简化的程式(化学式)的形式，包括非化学计量的形式以及化合物中重复单元或离子的电荷的记号；各种形式的结构式(分子图)，包括路易斯结构，骨架形式和立体化学式；分子轨道图(化合价相互作用的形式)等。或者在这些基础上，它们可能包括含有特定浓度范围的各种成分的溶液。
资源需求可以被指定为包，例如，一些资源类型的集合，每个资源类型标记有所需要的数量。对于人力资源需求，数量可以是全职人力工时(FTE)。
对解决方案的具体化可能有对扩展或具体化细化解决方案的资源要求。在需要人力资源的情况下，正在进行细化的解决方案可能需要具有额外技能(已经细化的解决方案所不需要的)的人力资源，以及细化解决方案需要的技能的子技能，和/或比细化解决方案所需的技能更高的技能。UML图就可以更具体化，例如，使用额外的子类或方法。不太明确的分子规范也可以通过一致的，更明确的规范来具体化。
分配给解决方案的资源可以依次分配给较低级别的解决方案，例如子问题的解决方案，或者解决由这些较低级别解决方案(也许只包括那些已经被实现的，如[0633]所述)驱动的问题。如果计划像在“附加解决结构：计划”中收到支持，那么可以约束资源的初始分配，使得可以将相同资源分配给必须按顺序处理的问题的解决方案，而不是需要并行处理的问题的解决方案。但是，一旦完成某个解决方案(参见[0633])，就会释放其资源来分配给其它解决方案。
然而，实施例可以支持将一些资源类型声明为消耗品，使得在完成解决方案的实现之后不会释放那些资源。虽然软件程序通常被认为是不可消耗的，但化学或生物的解决方案却可能是可消耗的。可消耗资源可用于表示在实施解决方案的过程中可能发生的资源转换。项目合作者在解决方案实施过程中获得的经验甚至可以表示为这些人力资源的技能的提高。
从较高级别解决方案到较低级别解决方案的资源分配过程可以通过支持将较高级别解决方案的资源需求与一致且可能更一般的子问题的解决方案的资源需求相关联的实施例来自动地实现，以指示应该使资源可用于实施该解决方案。
资源需求类型和可用资源类型可以作为辅助项目信息呈现，如“辅助信息和聚合”中所述。具有计划的解决方案的整体资源需求可以通过来自该计划的结构的实施例来计算。实施例可以区分理想需求和最小需求，前者允许所有并行操作同时发生，后者在某些情况下甚至会由于资源瓶颈而强行使并行操作进行排序。无论在哪种情况下，序列中子问题的资源需求可以计算为对这些问题的解决方案的要求的GLB，例如，指定能够满足每个计划流程的所选(用于实现)解决方案的最少需求的资源类型。并行子问题的最小资源要求同样可以计算为这些问题所选解决方案的需求的GLB，而理想的资源需求可以计算为这些问题所选解决方案的需求的总和，例如，资源类型指定每个析取算子计划的所有选定的解决方案。第一个计算可以将所需资源类型的有向无环图中的连接组件及其细化关系分开，使每个所需资源的类型等于完整资源类型层次结构中所需资源类型的GLB，但这可能过于严格。相反地，一些实施例将分开与资源类型(通过细化)相关的链，并使每个所需资源具有该链的最低元素的类型。第二个计算(并行组件的理想资源需求)可以通过将析取算子的资源需求进行合并，对相同资源类型的数量求和来完成。如果解决方案没有计划，则假定对子问题进行并行处理。
在设置解决方案的资源需求时，实施例可能需要至少足够的资源来满足解决方案的计划。
实施例还可以将几种资源类型(对于一些实施例来说是单个资源类型)与问题相关联，比如说对问题的解决方案将生成那些资源的期望。在这种情况下，该问题的解决方案的完成可以假设成生成相关种类的资源。如果问题是作为一个序列的一部分(包括多个嵌套序列)，那么生成的资源就可以被分配成为子问题解决方案的资源。因此，可以将针对较大问题的解决方案的子问题的资源类型视为生成其类型与该较大问题相关联的资源的中间结果的规范。实施例可以支持将更高级别的问题的解决方案的子问题的资源生成期望与这个更高级别的问题的一致的可能更通用的资源生成期望相关联。就是说，该资源可用于满足更高级别问题的资源生成期望。
类似地，实施例会支持将解决方案的组件问题的生成资源类型与针对后续组件问题的解决方案的一致且可能更宽泛的资源需求类型相关联。在这种情况下，在限制所需的总资源时需要考虑生成的资源，如在上述[0625]中计算的那样。特别是，要求可以被指定，其中(任意)反要求对应于超出资源要求的资源生成期望。序列的资源需求的计算可能会减少到多个二进制计算，任何资源生成期望用于消除它们可能满足的任何要求，或者被记录为可以继续以减少后续资源需求的取反要求。除非资源要求被指定不允许取消，否则计算并行计划的最低要求将如前所述。在计算并行计划的理想要求时，应该采用一种顺序来延迟析取算子计划，其中可能满足其它析取计划的资源生成期望的要求。
一些实施例声明：某个解决方案的每一个部分或所有资源需求以及预期为某一问题生成的资源，对于它们的安装提出一个额外的问题而对它们的拆除(尽管拆解可能是微不足道的或被省略的)提出另一个额外问题，这些问题至少部分取决于所涉及的资源类型。安装人力资源可能涉及雇用和/或培训。软件资源的安装可能涉及编程和/或配置。分子资源可以通过特定的化学反应产生。在分配和安装资源之前，动机问题的解决方案是不可实现的。在资源被拆除之前，动机问题的解决方案尚未完成。其它实施例可能要求将这种安装和拆卸问题明确地指定为更高级解决方案的任何其它组件问题。
添加假设
一种通常的误解情况，是人们注意到解决方案并不像所呈现的那样一般，换句话说，它声称要解决的问题有未提及的假设。实施例可以允许用户识别解决方案的假设，其可以被视为其解决的问题的改进，使得在操作之后，使解决方案解决细化的问题。
互斥细化
在某些情况下，两个或多个具体化是独立的，因此可能在范围上重叠。在其它情况下，它们是正交的，因此是离散的。例如，可以安全地将不同地理区域的问题具体化视为互斥。通过支持用户指定这样的关系，可以限制继承，采取问题和解决方案，例如，父代问题的解决方案，其通过任何其它这样的兄弟细化其中一个互斥的同源兄弟姐妹解决方案，在[0433]有更通用的介绍。还可以支持解决方案，技能等的互斥细化。一些实施例可以提供用于标记实体的机制，使得相同类型的所有较低级别细化是互斥的。
严格的细化实施例
一些实施例可以与上面的描述不同，要求仅通过从被细化节点的子结构继承或细化来获得各种类型的细化节点的子结构，并且禁止将这种子结构直接引入细化节点。特别是，由细化解决方案激发的任何问题来细化被细化解决方案所激发的问题导致解决方案改进的概念更接近于理论计算机科学的概念，而不是上面提出的类似于现代编程语言延伸课堂的方式。针对细化问题的任何解决方案也可以用来细化针对被细化问题的解决方案。
在细化分层结构下把每个节点关联一个状态机/贝叶斯网路
可以考虑用状态机来表示解的状态，其中包含各种可能状态值的状态，对应于解决方案实现的开发级别或进行此类实现的授权级别。例如，软件项目迭代的经典状态值包括需求分析，设计，编码和系统测试。授权的状态值可包括批准或可行性评估的各个可能阶段。这些可以在单独的状态机或单个状态机中表示。一般的状态列表可以是“打开”，“未被考虑”，“选择实现”，在后者中还包括“尚未开始”，“资源正在开发”，“正在实施”，“资源被拆除”，和“完成”。
给定解决方案所经历的实现/允许的状态，可以考虑可能在其后应用的各种附加流程的概率导致新状态。机器学习方法可用于对有关解决方案如何从一种状态进展到另一种状态的统计数据给出图形结构。这种统计数据可以考虑到问题或解决方案的各种特征。其中一种方法是Rebane，G.&Pearl，J.，提出的名为“从统计数据中恢复因果多树”的论文，发表在1987年第3届关于人工智能的不确定性讨论会的会刊(西雅图，华盛顿州)的第222-228页。这些方法是“训练”网络以在各状态之间提供适当转换的方式之一。
已经被具有特定特征的解决方案训练过的网络可以用作具有更具体的子特性的解决方案的起点，例如，接收这类网络已经被训练过的特定属性值的解决方案。这种网络可以接着单独进化。
如果要在各种状态之间传递，类似的技术可以应用于问题上面。
我们的问题和解决方案的细化分层可以用作组织各种状态机的框架，定义分层结构中如何从一个状态传递到另一个状态的解决方案。与问题相关的状态机可以应用于解决这些问题的所有解决方案。当一个问题的细化分层结构下降时，训练数据可以在每个级别的各种子问题之间被隔离，从而导出一个不同的状态机。因此，学习可以通过细化分层结构向下传播。
训练数据可以采取以下形式：询问用户什么是适合给定解决方案的下一个状态。或者，它可以采取以下形式：向用户询问先前状态中哪个是适合于给定解决方案的(例如，原型应该由潜在的用户审查)。
无论收集到的适当的转换数据的时间方向如何，实施例都可以选择同时询问为什么建议的状态转换是或者会是合适的。答案可能是可能触发修订状态机转换的信号的基础(例如，因为预计实施工作需要超过40个工时)。
信息也可能通过分层结构向上传播。例如，如果发现转换适合于给定问题的解决方案，则实施例可能会询问兄弟问题(在任何父级下)关于转换是否也适合(这可能还需要在兄弟问题中建立某些状态)。如果转换继续适用于兄弟问题的解决方案，我们可以建议取其父问题的解。此策略可用于产生任何通过细化分层结构向上的学习，而不仅仅与问题的分层结构或状态机相关。
或者，细化问题的状态机可以覆盖那些通过任何其它方式细化问题的状态机，例如项目管理员的显式编辑。
此外，解决方案的分层结构可以与分层状态机相关联，具有分层嵌套状态，由此嵌套状态的解决方案也处于周围状态中。
这样的分层状态机可以被应用于，使得应用于解决方案的更深层嵌套状态首先获得定义如何处理各种输入信号(诸如授权，实现，测试，预算等过程的成功或失败)的机会。
或者，最好的话，分层状态机可以被应用于，使得新信号涉及更深层级，并且那些新信号决定更高级别的状态的子状态之间的转换。
由于问题和解决方案分层结构密切相关(例如，通过[0337]和[0460]的约束)，被细化的解决方案会自然的受到被细化问题所修改的状态机的影响。为了保证一致性和连续性，一些实施例因此可以限制状态机修改以用于改进问题以对存在的被细化问题的状态施加额外的较低细节层。
因为在存在解决方案时可以添加状态机和状态机的附加层，所以任何级别的状态机都应具有指定的默认启动状态。任何新的或现有的解决方案都处于上级机器的默认启动状态，或者当它们进入较高级别的适当状态时处于较低级别的机器。不需要结束状态，但可以通过定义没有传出弧来创建任意数量的结束状态。
任何特定解决方案可以通过用户界面在状态之间转换，或者可以将特定转换与自动应用的规则相关联。管理层批准或不批准适用于前一种处理方式，而超出预算或超过期限的解决方案会成为后者待选的例子。
图173显示出了用于将状态机与问题相关联的可能的用户界面。除了用于编辑或增广实体的选项之外，问题的上下文菜单还包含“查看状态机”选项。选择此选项可能会显示问题的当前状态机图表。这里有各种各样的状态，包括一个被称为“实施超预算”的状态，这是通过过渡“增加额外资金”来实现的。两个传出转换标记为“授予额外资金”和“暂停项目实施”。从任何给定状态，上下文菜单包括“分解状态”选项，当选择该选项时，显示较低级别的状态机(如果它尚不存在则创建一个)。各个节点的上下文菜单选项支持编辑状态标签，删除状态和添加传出状态转换。与状态无关的上下文菜单支持添加新状态，设置默认状态或使用下一个更高级别的状态机启动窗口。
图174显示了用于将状态机与问题相关联的可能用户界面。除了用于编辑或增广实体的选项之外，解决方案的上下文菜单还包含“查看当前状态”选项。这里显示两级状态，上级为“已清除可以实施”，下级为“实施超预算”。另一个选项“应用状态转换”提供了另一个上下文菜单，其中包含这个节点可从状态机的各个级别转换的选项。解决方案级上下文菜单“推荐下一个/上一个状态”中的附加选项允许获得有关应如何或已经如何处理解决方案以及原因的输入。尽管这在此处作为用户选项呈现，但是实施例可能更倾向于使该过程随机化以通过自选择来避免偏差。
一种探索分层结构及其上下文表示的方法
一般方法如下。作为树呈现DAG的一部分。然后反复允许用户采取以下任一操作：
展开DAG封闭边界上任何节点上的子树
这样做既应该自动关闭与打开的子树“冲突”的任何先前打开的子树，例如，应该隐藏在DAG的另一个节点处已经可见的打开的节点的任何子节点；并打开正在扩展的节点的一些子代。
严格地在DAG的封闭边界内的任何节点处折叠子树
这样做应该隐藏正在折叠的节点的任何严格的子代，并且应该关闭折叠的节点。如下所述，各种实施方案可以使用策略的一些组合来实现这一点。
相关的策略集处理DAG应该初始可见的多少，以及节点扩展时显示的多少。
因为实施方案可以选择限制树使得只有与任何给定实体相关联的一个节点可见，所以我们调用与相同实体相关联的两个节点直接冲突。为了隐藏节点，实施方案可以折叠其父节点。如果节点的子代数量不是有限的，那么除列出的最后两种策略之外的所有策略都可能不合适。
首先，我们提出初始化策略。它们全部阻止显示多个直接冲突的节点。
1.尽可能多地打开DAG，直到打开另一个节点将显示与可见节点冲突的子节点；不要打开这些节点。节点的子代可以按任何顺序展开。
最多只有一个冲突节点可见。
2.尽可能多地打开DAG，直到一个实体可以被多个父节点访问；在这种情况下不要打开任何这样的父节点。没有冲突节点可见。
3.只要有一个非叶子子代，继续打开节点。
4.只要只有一个子代，继续打开节点。
5.只打开本地节点。
6.最初不要打开任何节点。
接下来，我们介绍显式节点扩展的策略。这里，实施方案可以打开请求的节点；然而，额外打开多少，可能会有所不同。为了保持禁止显示多个直接冲突节点的约束，实施方案可以隐藏一些节点，尽管所需的隐藏量可能取决于扩展(展开)策略的限制性。如果节点的子代数量不是有限的，那么只列出最终的策略可能是合适的。
1.隐藏与正在扩展的节点的子节点直接冲突的任何节点，然后尽可能多地打开DAG，直到打开另一个节点将显示与可见节点冲突的子节点；不要打开这些节点。节点的子代可以按任何顺序展开。最多只有一个冲突节点可见。
2.隐藏与正在扩展的节点的子节点直接冲突的任何节点，然后尽可能多地打开DAG，直到显示可以通过多条路径到达的实体；不要打开这些节点。节点的子节点可以按任意顺序扩展。
除了请求扩展的子节点之外，没有可见的冲突节点可见。
3.只要有一个非叶子子代，关闭任何兄弟姐妹并继续打开节点。
4.只要只有一个子代，关闭任何兄弟姐妹并继续打开节点。
5.只按照明确指示打开节点。根据在打开节点之前隐藏多少树来存在变化：隐藏与每个显示节点相同的实体关联的任何可见节点或关闭任何兄弟姐妹节点。各种实施方案使用相关策略来进行初始化和扩展，但是一些实施方案在这些情况下或在他们认为合适的任何子情况下使用不同的策略。
另一组策略处理如何在已关闭的子树重新打开时作出反应。
1.一些实施例可以将该子树重新打开到其初始位置。
2.其它人可能将其重新开放至与关闭前相同的位置。
实施方案可能在它们处理逻辑叶节点的方式上表现出细微的差异。一些实施方案尽管事实上没有子代可以显示，但可以选择允许打开和关闭叶节点。这些实施方案可以在节点上使用单个二进制变量来表示它们是打开还是关闭。作为优化，它们可以使用单独的二进制变量来直接表示节点是否有子节点。其它实施方案可以跟踪具有子代的节点是打开还是关闭，并且树叶不维护这个信息。同样，节点是否是逻辑叶节点可以明确维护或通过对其逻辑进行计数来确定子代。我们假设扩展，崩溃和展开的各种策略只发生在具有逻辑子代的节点上，尽管这些检查从图中省略。
一对策略反映了树节点的生命周期。
1.一些实施方案可以首先将来自DAG的整个子结构(或上下文)构建为其中可以多次表示某些实体的单个(可能倒置的)树，然后根据以下选择来调整要显示的节点上述策略(使得任何实体在任何时间仅在一个节点上显示)。取决于探索发生的情况，实施方案可以独占地显式地隐藏和显示节点，或者在某些情况下利用诸如浏览器的基础技术来设置这些属性。
2.其它实施方案可以在每次显示时从DAG重建节点，并且当它们要被隐藏时将其删除。
将DAG子结构呈现为一棵树
这里树向下生长，其目的是允许用户探索节点的后代，即其子结构。
在图175中示出了用于在导航下的特定DAG将DAG表示为树的方法.树结构(DAG中可能的快照)完全对应于DAG结构，开放节点的子节点(用“o：”标记)缩进并在该节点下面。
实现策略0656.1的实施方案可以使用或不使用约定，如果节点被隐藏，则其所有后代都可以被推断为隐藏，而不用为每个后代明确地维护该事实。
我们现在描述战略0656.1的每个操作。图176和图177描述了建立过程的两个部分。图176示出静态子结构构造111100以本地节点开始并发现子代迭代地构建子结构。在构建各个节点之间没有指定顺序，但是如果指针保持在任一方向上，则在将参考节点设置为引用它的节点之前构造所引用的节点可能是方便的。如果指针在两个方向上都维护，则顺序可能是任意的，因为在分配两个节点后可能需要设置其中一个指针。图177显示出了静态子结构初始化111101都使本地节点可见并应用来自[0652]的策略。对于策略0652.6中描述的策略，扩展简单地折叠本地节点但是对于[0652]中的其它策略，它将本地节点标记为打开并且应用图180，图181，图182，FIG183或FIG184分别用于[0652]中的各种剩余列出的初始化策略。软件开发领域的技术人员应该清楚，只要每个节点在其初始化之前被构造，这些过程就可以被合并。
正如在[0658]中提到的，如果节点的隐藏属性是可继承的，则可能不需要通过后代下降来隐藏节点。我们在图179中做出这个假设。
在一些实施方案中，可以做出关于如何维持隐藏节点(在闭合节点下方的那些)的打开/关闭状态的假设。实施方案可以将这些初始化为关闭和隐藏，并且还在折叠节点时确保已经显示的所有后代都处于关闭和隐藏状态(以便在打开节点时我们可以假定其子节点关闭)，否则折叠扩展停止的非叶节点。这些数字假定后者。他们描述了这种折叠节点的步骤，其中扩展单独停止每个扩展策略。显然，这可能是抽象的，但是这需要收集扩展停止的那些节点，以便可以集体处理它们。
来自[0653]的策略使用图178的模板。CurrentNode最初是正在扩展的节点。该过程将该节点标记为可扩展，并依次隐藏扩展策略将通过折叠父节点而产生冲突(定义广泛)的任何节点，然后将该扩展策略(从[0653])应用到该节点。对于隐藏节点，策略0653.1和策略0653.2使用图185中的隐藏直接冲突静态子结构112111；策略0653.3和策略0653.4使用图186的静态子结构112100中的折叠兄弟；而战略0653.5可能会使用其中任何一个。为了扩展，这些策略使用最大展开静态子结构111110，展开静止子结构直到共同子代110120，展开静态子结构直到多个非叶子子代110130，展开静态
分别从图180，图181，图182，图183和图184中看到子结构直到多个子110140和一元展开静态子结构110150。
前面描述了策略0654.1。对于策略0654.2，我们将节点标记为打开状态，然后在展开时如果节点没有如此标记(并且可能所有子节点都关闭了)，则按照上面的方式操作，否则显示任何打开或空的子节点，以及第一层封闭的后代。可以通过在会话结束时存储树结构并仅在未找到这样的存储结构时进行初始化来进一步采取该策略。
图179描述了过程静态子结构折叠113100。这里，currentNode最初是节点正在崩溃。在各种实施方案中，节点必须被标记为扩展并隐藏任何可见的后代节点。在各种实施方案中，封闭节点下方的节点将不可见，因此不需要隐藏。但只要节点的隐藏属性是可继承的(策略0656.1)，则只有节点的直接子节点需要被隐藏。
我们现在描述与每个策略相关的辅助操作。图180示出了过程最大展开静态子结构111110。它通过子结构分层结构下降，将节点标记为打开并显示每个节点，仅停止(并将节点标记为关闭)，以防止显示已通过另一路径可见的任何常见后代。图181示出了展开静态子结构直到共同子代110120的过程。它类似于最大展开静态子结构111110，但会停止(并将节点标记为关闭)，以防止显示任何常见的后代，无论它们是否已通过另一条路径变得可见。图182示出了展开直到多个非叶子子代110130的静态子结构的过程。
它也通过子结构分层结构下降，将节点标记为打开并显示每个节点，但在具有多个非叶子节点的节点上停止(并将节点标记为关闭)。图183示出了展开直到多个子代110140的静态子结构的过程。它类似于展开多个非叶子子代110130之前的静态子结构，但是在有多个子代的时候停止(并且标记节点关闭)以防止下降，不论是否有叶子。最后，图184示出了一元展开静态子结构110150的过程。它只需要一步展开。
这些操作可以通过最初创建本地节点以及创建可见的节点或者在上述描述中隐藏它们的位置来实现，以实现策略0656.2。进一步的描述不应该是必要的，因为其它部分需要动态子结构和上下文。
将DAG上下文呈现为倒置树
这里树向上增长，其目的是允许用户探索节点的祖代，即其上下文。
DAG可能有向上和向下延伸的子树。两个高分层的策略涉及子结构与环境的概念。
1.具有本地节点概念的一些实施方案可以认为该节点的祖代是潜在的上下文并且该节点的后代是潜在的子结构。在退化情况下，整个DAG可能被视为子结构或上下文。采用这种策略，只有指定的位点节点可以分别针对子结构或上下文进行聚焦(假设两者都可用)。子结构节点可能会扩展或折叠更多子结构，并且上下文节点可能会扩展或折叠更多的上下文。
2.其它实施方案可以将子结构和上下文视为相对术语。这可以通过允许任何节点针对结构或上下文单独聚焦来实现。如果封闭子结构边界内的节点因子结构而折叠，则其所有正确的后代都隐藏起来；如果封闭子结构边界上的节点扩展为子结构，则其一些适当的后代将暴露。如果上下文关闭的上下文边界内的节点被折叠，则其所有正确的祖代都隐藏起来；如果封闭上下文前沿上的节点针对上下文进行扩展，一些适当的祖代被暴露。
1.一些实施方案可以允许同时扩展多个父节点(只要没有公共祖代在多于一个节点处暴露)。节点的顺序保持不变。
2.其它实施方案可以限制扩展，使得父节点列表的顶部节点至少扩展到任何其它节点。如果一次仅扩展一个上下文兄弟(根据策略0653.3，策略0653.4，或策略0653.5)，因为任何节点将被展开，它可能会移动到顶部。如果可以同时扩展多个上下文兄弟(根据策略0653.1或策略0653.2)，对于各种实施方案，扩展过程必须充分执行以确定哪个上下文兄弟需要最大扩展并且上下文兄弟可以移动到顶部。这可以用于可视化与共同祖代的关系，如下面的“多个倒置树的通用上下文的表示”中所述。
假设策略0667.1和策略0668.2被示出用于图187中的导航下的特定DAG，用于将DAG表示为树的方法。DAG(节点0)的根位于该图的底部，而树的根位于顶部。上面列出的节点和任何打开节点的左边的节点共同为该节点的父节点。这里，节点0.0到(n0-1)是节点0的父节点，其中两个节点(节点0.0和节点0(n0-2))打开并显示父节点。
允许(根据策略0668.1)顶级上下文兄弟比任何其它上下文兄弟更少展开的各种实施例可以明确地管理缩进或管理不可见列表节点(因为最上面的节点不一定是最左边的节点)；这可以通过重新排序上下文兄弟(每策略0668.2)来避免。对于软件开发领域的技术人员来说，管理缩进或不可见列表节点只涉及乏味，所以我们专注于策略0668.2。
实施策略0668.2的各种实施方案可能被限制为也实施策略0656.2
因为没有静态排序就足够了。对于存在惯例的实施方案，如果节点被隐藏，则其所有后代可以被推断为隐藏，也可以被约束为也实施策略0656.2，因为这种约定与其应该是倒置的树不兼容可能隐藏后代而不隐藏祖代。
对于实施策略0656.2的实施例，构造和初始化之间没有区别。图188类似于图177，不同之处在于省略了显示本地节点，因为假定这已经在子结构的初始化期间完成。与本地实体相关联的本地节点的构建也被省略，因为假定它已经在动态子结构的初始化期间完成(未示出)。
图189示出了在至多一个上下文兄弟可以是的情况下显式扩展的过程
一次扩大。它类似于图178，但包括处理两种情况的逻辑。它将被扩展的节点移动到上下文兄弟节点列表的顶部，如果它尚未在那里的话。另外，如果被扩展的节点位于上下文兄弟节点列表的底部，并且该列表中至少有一个其它元素，则其后代将被转移到新的上一个上下文兄弟节点。对于一次可以扩展多个上下文同胞的情况，必须首先确定展开此节点是否使其成为扩展最大的上下文兄弟，如果是这样，则继续使用上述逻辑将其移至列表顶部。
图190示出了过程动态上下文折叠(单个实体)213200。它会重复检查currentNode上面是否有更多上下文，如果是，则在将currentNode及其后代移动到currentNode的祖父节点之后，取消分配currentNode的父节点。当currentNode上面没有更多的上下文时，它将被标记为关闭以进行上下文扩展。
在用于展开上下文的各种策略的图(图191，图192，图193，图194和图195)中，currentNode最初指代locusNode(用于初始化)或者用于显式扩展到正被展开的节点。currentEntity指的是与currentNode关联的实体。其中每个节点都动态分配节点列表，currentEntity的每个父节点都有一个节点列表。为了使这些显示对齐，但是从currentNode后退，实施例可以将currentNode放置为列表中最后一个节点的子节点。每当策略需要重新展开以在新创建的节点上展开时，可以为该节点重复该分配步骤。与呈现单实体DAG子结构的策略的另一个主要区别在于，将节点标记为上下文扩展是足够的，而不需要隐藏它们的上下文后代，因为尚未为这些后代创建节点。
图196与图185类似，但是必须根据实体和DAG来搜索冲突，并且必须考虑到为了隐藏DAG中的若干双亲之一的节点，各种实施例必须折叠代表其DAG的子节点定位为表示序列中最后一个父节点的节点的基板子节点。图197与图186紧密对齐。
多个倒置树的共同上下文的表示
如[0444]中所述，用户可能导航到多个本地节点。这里，当用户探索其祖代，即节点的上下文时，树从每个本地节点向上增长。我们的目标是在上下文探索过程中识别来自两个或多个本地节点的通向共同祖代的任何路径。
我们有一种方法，在上下文展开时，我们也隐藏与实体相关的任何上下文与任何背景有关。现在我们有多个本地节点，如果同一个实体可以通过多个本地节点的上下文访问，我们继续如下。如果这种共同的祖代实体在每种情况下都会以相同的上下文兄弟姐妹集合显示出来，我们会合并这些关系以使这种关系变得明显。如果公共实体将使用一组上下文兄弟显示，但已经显示了该组上下文同级的适当子集，则合并路径将是不正确的，因为与一些新显示的上下文同级相关联的实体实际上并不是与将作为其集体子项呈现的节点相关联的实体的父项。因此，我们通过隐藏先前显示的一组上下文兄弟来解决冲突。
另一方面，如果公共实体将使用一组上下文兄弟显示，但已经显示了该组上下文兄弟的适当超集，则我们至少有两个选项：
1.一种选择是按照正确的子集情况进行，其含义是显示的双亲集合始终是该实体双亲的确切完整集合。
2.另一种选择是合并双亲的正确超集的子节点作为被扩展节点的上下文兄弟节点，暗示所示的父节点集只需要是该实体的父节点的子集。这具有以下优点：相关节点存在更多“聚集”，但缺点是节点的一些父节点被隐藏。
在实施方案涉及指示跨越本地节点的共同祖代的情况下，可能不必通过任何本地节点的上下文一次支持多于一个路径的持续暴露。然而，一个实施方案可以暴露来自不同本地节点的路径，在这些路径之间尚未暴露共同祖代，并且甚至暴露来自本地节点的任何路径的“存根”而不是那些导致具有其它本地节点的共同祖代的路径，可能确保这些被修剪得比通往共同祖代的路径短。因此，我们不再关注战略0652.1，战略0652.2，战略0653.1和战略0653.2。
在“将DAG上下文呈现为倒置树”中，我们仔细地防止了常见的显示
(根据策略0667.1)，或者根本(根据策略0667.2)来自相同本地节点的不同路径。这对于减少过多的复杂性是有效的，否则可能会打败DAG的基于树的表示的好处。但是，如果我们对几个实体感兴趣并选择扩展其环境，则可能会对看到这些路径所达到的任何共同祖代非常感兴趣。
在扩展上下文节点(其中一次只能扩展一个父节点)中，一些实施方案可以操纵节点的上下文兄弟节点的顺序，使得被扩展的节点首先在列表中。这使上下文在一个自然的树状结构中向外生长。其它实施方案可以不重新排列它们的顺序，从而可以理解，所显示的双亲与直接在其下面缩进或处于打开状态的节点相关。
接下来我们将展示如何在底层树中呈现共享上下文，或者如何更抽象地呈现节点列表中的森林(即树的列表)，每棵树称为上下文帧。通过交替缩进节点列表和它们的子上下文帧，可以在基底树中呈现森林。该方法在图198中针对导航和策略0668.2下的特定DAG示出。我们可以在该图中看到两个变种列表的嵌套序列。最外面的subDAG列表是一个简单的列表，其元素是上下文框架。上下文帧包含一个节点列表，其中每个节点提供有关不同实体的信息。
上下文框架可以是内部或叶子。树叶具有带有空的subDAG列表的单个节点，并引用一个本地节点。内部帧具有非空节点列表和非空子节点列表，意图是所列节点共同是每个子节点中最高开放节点的父节点。subDAG列表可以被定位为最后一个双亲的子代以利用可以可视化树结构的软件，或者子帧可以被认为是双亲的单个明确缩进的兄弟姐妹，或者双亲的单个明确缩进的兄弟姐妹，或者可以通过跟踪帧的嵌套深度来明确地全局管理缩进。对于最顶部的内部框架，所有非相关双亲都处于关闭状态。对于其它帧，只有第一个节点处于打开状态，后续节点关闭，表明这一点在下一级别的双亲将这些第一个节点作为他们的集体子节点(而与封闭节点相关联的实体的父节点不被暴露)。为方便起见，我们遵循这个编号帧图的约定，通过附加一个序列号到下一个最外面的帧的编号和编号节点。顺序编号到封闭框架的编号，但应记住，探索背景的过程是向外进行的。我们将帧f列出的双亲数量称为nf。图198中的第0帧和第1帧是两个没有共享上下文的DAG。帧0具有列出的父节点，随后是三个代表其子节点(节点0.0.0,0.1.0和0.2.0)打开并且其关联实体都具有相同父节点集合的子节点的子帧(与这些节点相关联的实体父节点)。每个框架中的后继双亲(不以“.0”结尾)关闭。这整个subDAG列表可能被定位为最后一个父节点的子节点(节点0(n0-1))。可以看出，这种结构在帧0.0和0.1的情况下递归地重复。每个这样的递归可能会达到一个或多个叶子。帧0.2是一个叶子，所以它只有一个节点(一个本地节点)被列出并且没有子帧。但是，该节点可能携带与相应实体相关联的子结构。在以上描述中，列表是一些实施方案可能选择不明确表示的抽象；这样的实施方案可以将对以上列表的引用视为统一地简单地引用该列表的元素。
在图198中，帧0的闭合上下文边界由父0.0到父0(n0-1)加上全部组成任何嵌入式框架的继承双亲。
图199到图202呈现了如何由实施方案的用户体验共享上下文的示例。这些屏幕显示用户探索DAG技能的过程。图199示出了具有三个本地节点的DAG的初始呈现，“诉讼”，“立法”和“网络”。每个都在一个单独的顶级框架中。如果从该位置开始，用户打开“辩论”的上下文，即“诉讼”的超级技能，我们将看到如图200中的结果。“辩论”有两个双亲，“沟通”和“分析”。由于没有“分析”的“通信”是“网络”的双亲，因此在打开“辩论”时，“网络”必须关闭，保持任何单一技能仅出现一次的不变量。现在，打开“采访”关闭“辩论”，我们在图201中看到，像“网络”一样，其唯一的双亲是“通信”，并且这些存在于“通信”下的单独帧中。打开“立法”然后“写作”，我们在图202中看到它也属于第三帧“通信”。关闭用于“采访”的文件夹可能导致图202中的屏幕，其中包括“诉讼”的框架被分离并移动到顶层。各种帧的区别在于，每个帧的父项中最上面的文件夹是打开的，而其余文件夹是空的或关闭的，但是实施方案也选择以其它方式区分它们(例如，通过在它们周围绘制边框)。
在折叠上下文时，我们现在可能只想删除未与外部本地节点共享的上下文被折叠的节点(例如，不与其它帧共享)。因此，相对于每个帧或节点对与其后代节点相关联的本地实体的引用进行维护是方便的。我们没有显示维护该信息的细节，因为这些对于软件开发领域的技术人员来说应该是清楚的。
在图204中的初始化过程的第一阶段中，图198的结构被设置为每个本地实体具有一个顶级叶框。假设本地节点是在多个实体的动态子结构初始化期间构造的。其余部分类似于图188，但是针对每个本地节点重复，并且使用特定于需要跨多个实体共享的辅助例程的版本。
多个实体的动态上下文扩展如图189所示，但是“将currentNode的后代移动到最后一个上下文同级”的后代可以是帧列表的形式。
图205呈现了动态上下文折叠(多个实体)223200的过程，其类似于图190中的单个实体版本开始，但是需要另外的步骤。如果包含currentNode的帧列表具有比currentNode更多的本地后代，那么我们不能简单地删除上下文，因为这会丢弃本地节点。请注意，这里的后代我们并不是指底物树中的文字后代，而是上下文祖代，与底层DAG中的后代相关。这些对应于currentNode以及currentNode在衬底中的最后一个兄弟节点下的framelist的内容。)相反，我们将currentNode移动到它自己的顶级帧，以便保留那些本地节点，尽管它们与currentNode的上下文无关。否则(移除下一层上下文不会丢弃任何本地节点)，我们继续如图190所示。
用于展开多个实体的动态上下文的各种策略(图206中的展开动态上下文直到多个非叶子项(多个实体)220230，图207中的展开动态上下文直到多个子项(多个实体)220240，以及一元展开动态上下文(多个实体)图208中的220250)包含实现策略0678.1的多个本地节点的方法的大量公共逻辑，这在此处描述。实施例可以通过查找currentEntity的父亲并且确定它们是否作为衬底树中的一组兄弟节点存在而开始(一些实施例可以将其限制为非空的父节点集，因为留下多个空集可能不会产生冲突)。如果是这样，他们可能只是将currentNode移动到该兄弟姐妹下的新帧。否则，他们可能会创建父节点列表，但也会确保删除任何现有的重叠上下文同级集。后者在图210中进一步描述。清除刚刚描述的重叠上下文兄弟集合的过程在逻辑上可能属于动态上下文(多个实体)222200中的折叠兄弟姐妹，但是我们将其放在此处与其它与currentEntity父项相关联的节点进行检查，以便它可能需要每次迭代的地方。建议在此指示并在图211中进一步描述的另一步骤，但是一些实施例可以省略它。随着扩展的进行，新扩展的节点可以捕获当前处于顶层但具有与被展开的父集相同的父集(再次，可能排除空集)的节点。仍然需要构建与currentEntity的父节点关联的节点的完整列表。这样做使得currentNode(被扩展)是最后一个这样的节点的子节点。
图210示出了通过将其DAG后代提升到顶层来隐藏冲突的可见节点的逻辑。可以通过定位已经与这些父实体中的任何一个相关联的节点来识别重叠的上下文同级组。在删除重叠集之前，其下的每个帧(对应于DAG中的一个子集)将移动到顶级帧列表。回想一下，在不在顶层的任何框架中，第一个上下文兄弟是打开的(表明它与正在探索双亲的子代相关联)。因此，当第一个上下文兄弟的框架移动到顶层时，它将被关闭。在移动了上下文兄弟的给定子集下的每个帧之后，应该移除这些节点。
图211示出了用于捕获与其节点正被扩展的实体的DAG兄弟相关联的节点的逻辑。对于每个顶级框架，如果该框架的任何节点具有与要显示的实体相同的父级，则将该框架从顶级移动为要扩展的节点的兄弟，将匹配节点移动到顶部框架，并打开该匹配节点的上下文。
此时，[0653]的每个策略特有的逻辑起作用，并且类似于图193，图194和图195中描述的逻辑。实际上，每个图中的第一个活动是父节点的构造，我们刚刚描述过。这里针对多个轨迹实体描述的过程的不同之处仅在于，展开动态上下文直到多个非叶子项(多个实体)220230和展开动态上下文直到多个子项(多个实体)220240的递归继续[0689]中刚刚描述的逻辑。
多树共同子结构的表示
这里，当用户探索其后代(即节点的子结构)时，树从每个本地节点向下生长。我们的目标是在子结构探索期间识别来自两个或多个本地节点的任何路径，这些路径通向共同的后代。
我们有一种方法，当子结构展开时，我们隐藏与实体相关的任何子结构，该实体也与所揭示的任何子结构相关联。现在我们有多个本地节点，如果同一个实体可通过多个本地节点的子结构访问，我们按以下步骤操作。如果在每种情况下使用相同的兄弟姐妹组显示该公共后代实体，我们合并路径以使这种关系显而易见。如果公共实体将与一组兄弟姐妹一起显示，但已经显示了一组不同但重叠的兄弟姐妹，那么合并路径是不正确的，因为与一些新发现的兄弟姐妹相关联的实体实际上并不是子代与将作为其集体父项呈现的节点关联的实体的。因此，我们通过隐藏先前显示的兄弟姐妹来解决冲突。
另一方面，如果公共实体将使用一组上下文兄弟显示，但已经显示了该组上下文兄弟的适当超集，则我们至少有两个选项：
1.一种选择是完全按照适当的子集情况进行，暗示所显示的子集始终是该实体的完整和完整的子集。
2.另一个选择是合并子代的正确超集的双亲作为正在扩展的节点的兄弟姐妹，暗示所示的子代集只需要是该实体的子集的子集。这具有这个优点，相关节点存在更多“聚集”，但缺点是节点的一些子节点被隐藏。
在实施例涉及指示跨越本地节点的共同后代的情况下，可能不必通过任何单个节点的子结构一次支持多于一个路径的持续暴露。然而，一个实施例可以暴露来自不同本地节点的路径，在这些路径之间尚未暴露公共后代，甚至暴露来自本地节点的任何路径的“存根”而不是那些导致与其它本地节点共同后代的路径，可能确保这些被修剪得比通往共同后代的路径短。因此，我们不再关注战略0652.1，战略0652.2，战略0653.1和战略0653.2。
在“将DAG子结构呈现为树”中，我们小心地阻止了来自同一本地节点(在策略0667.1下)或根本不在(在策略0667.2下)的不同路径显示共同后代。这有效地减少了过多的复杂性，否则可能会破坏DAG基于树的表示的好处。但是在我们对几个实体感兴趣并且选择扩展其子结构的情况下，人们可能非常有兴趣看到这些路径所达到的任何共同后代。
在扩展子结构节点中，其中一次只能扩展一个子节点，一些实施例可以操纵节点的兄弟节点的顺序，使得被扩展的节点在列表中是最后的。其它实施例可以不重新排列它们的顺序，从而可以理解所显示的子代涉及它们上面的同源，它们是缩进的。
接下来，我们将展示共享子结构如何作为单个基板树呈现。该方法在图212中针对导航下的特定DAG和策略0668.2示出。我们可以在该图中看到两个变种列表的嵌套序列。最外面的根subDAG列表是一个简单列表，其元素是根子结构帧。子结构框架具有主节点，后跟缩进数据(基板树中的子节点)。节点可以是打开，关闭或空的(参见[0289]中的注释)。我们根据主节点的状态调用框架打开，关闭或清空。最外面的根subDAG列表的元素的主节点没有指示的共享子结构。如果主节点是打开的，则缩进数据包括闭合子节点的节点列表，其后是最终子节点的子结构帧(一些实施例假定任何打开的子节点被移动到最后位置)。无论主节点的状态如何，此数据后跟根内部子DAD列表。当然，该数据可以被组织为单个列表或列表列表，如实施例所方便的那样。根子结构框架是子结构框架，其中主节点是一个本地。子结构框架被认为是内部子结构框架或叶子结构框架，这取决于在基板树中是否存在任何子节点(注意，所表示的实体不必是底层DAG中的叶子)。对于各种实施例，最外根的子结构框架可以是叶子或内部，但是其它根子结构框架必须是内部的，因为它们导致共享的子结构。将完整的子标签列表定义为由最终子子结构框架形成的列表，后跟根内部子标签列表的元素。注意，如果主节点在基板树中没有子节点并且根内部子标签列表为空，则开放子结构帧可以具有空的完整子标签列表。如下定义框架的高度。具有空的完整subDAG列表的帧的高度是一。否则，内部框架的高度比其完整子标签列表中最后一帧的高度多一个。将内部子结构帧的终端帧定义为其完整subDAG列表中最后一帧的终端帧(如果有)，或者内部子结构帧本身。对于一些实施例，内部子结构框架的完整子标签列表中的帧将具有增加的高度。定义尾部位置如下。任何顶级根子标记列表都处于尾部位置。如果帧处于尾部位置并且具有非空的完整子标记列表，则完整子标记列表的最后一个元素位于尾部位置。尾部位置的框架的终端框架是关闭的。任何其它帧的终端帧是开放的，并且所有这些开放帧可以在基板树中的相同深度处对齐(根内部子DAG被布置成使得情况就是这样)。从上面可以得出，对于各种实施例，其中最终子子结构框架关闭的内部子结构框架将具有空的根内部子DAG列表。最终子子结构框架打开的内部框架可能具有空的或非空的根内部子标签列表。
目的是节点列表中的节点和最终子子结构帧的主节点共同是封闭子结构帧的主节点的子节点。(与往常一样，与封闭节点关联的实体的子节点不会公开)。此外，最终根内部subDAG节点的给定后代的父节点不仅包括其在基板树中的直接父节点，还包括来自完整subDAG列表的任何先前元素的任何开放叶节点，并且与该直接父节点对齐。根内部subDAG列表(或其每个元素)可以被定位为主节点的子节点以利用可以使树结构可视化的软件，或者可以通过跟踪帧的嵌套深度来明确地全局管理缩进。为方便起见，我们遵循图212的顺序编号本地节点的约定，并且通过以下方式编号子节点(包括用作新帧的主节点的最终子节点)的编号。将序号附加到下一个最外帧的主节点的编号。本地节点0和1是两个顶级DAG的主节点，没有共享上下文，而节点3.1.0是本地节点0,2和3的公共后代。实体的底层DAG中的父节点由节点3.1.0包括由节点0(n0-1)。(n0。(n0-1)-1)，2和3.1表示的实体。在以上描述中，列表是一些实施例可以选择不明确表示的抽象；这些实施例可以将对上面的列表的引用视为简单地共同引用该列表的元素。
目的是放置作为公共后代的祖代的根子结构帧，以便均衡从顶层到根子结构帧以及从根子结构帧到公共后代节点的组合距离。这可以通过在每个子结构节点的逻辑子结构树中存储深度来实现。在扩展子结构节点时，我们检查每个显露的子代是否已经存在于基质中。如果它的深度大于正在展开的节点的深度，则根据需要折叠节点，然后将包含展开节点的顶层框架向下移动帧的差异。如果存在的深度等于或小于正在展开的节点的深度，则将子节点从现有节点移动到正在展开的节点，并对帧重新排序以保持增加高度的不变量。
仍然需要解释如何将上下文与子结构一起呈现为单个基板树。一个简单的方法是，当为子结构扩展节点时，我们首先折叠该节点的任何上下文，以便我们可以开始用本地节点计算高度。然而，应该清楚的是，可以在高度计算中包括上下文，并且仅在必要时折叠上下文以解除共同的祖代。
多节点选择
该表示框架可以支持节点的选择，甚至选择一组节点，其中一些节点冲突，因为它们不能全部显示在同一个树中。如果显示节点的策略是限制性的，我们不应该仅仅允许用户选择可以一起看到的节点。即使节点不再可见，我们也可以将其节点或实体标识符或从其路径存储到根节点作为节点或实体标识符序列。鉴于客户端的本地化DAG结构，这些应该足以满足任何目的。如果客户端需要重新显示不再可见的所选节点，则可以使用其到根的路径来执行此操作，使用通过[0426]中讨论的路径到子结构112250可访问的节点，并在图213中示出或显示可访问节点的节点。在[0466]中讨论并在图214中示出的路径通过上下文212250。不是清除现有树并通过遵循路径重新打开，而是最好遵循来自根的路径，跟踪已经显示的任何节点(我们可以假设根始终显示)，直到到达路径中的节点那是不可见的。然后，对于路径上的每个节点，关闭冲突的节点(基于有效的策略)并打开(展开)路径上的下一个节点，从子集中选择它。实施例可以选择在展开节点中使用任何特定策略。如果它一次只展开一个节点，则可以假设后续节点不可见，因此可以快速连续地在该点之后展开每个节点。
在图119和图114中提供了在重新布置子结构之后选择节点然后从另一节点执行操作以使得所选节点不再可见的示例，在[0497]中讨论过。
辅助信息和聚合
辅助信息的汇总
各种信息可以与底层DAG相关的实体相关联。期望在探索项目层级时具有查看相关辅助信息的直观方式。可以在DAG减少过程期间收集辅助信息，并且可以在本地化DAG中存储在该实体的记录中的每个实体的个体信息。
与项目有关的辅助信息的例子包括交易数据(资金的贡献或项目的努力，如[0729]中所述)，总捐款，可用资金总额，项目进度报告，上载文件和项目活动流。对于文件，文件本身可能不会通过本地DAG提供给客户端，而只能提供给元数据。如实施例所支持并且由用户指导，可以远程下载或访问文件。它还可能包括有关相关实体的信息，例如项目中各种角色的用户([0822])或所需技能。
诸如树大小和构造或访问的新近度之类的其它辅助数据可以不直接显示，而是用于提供与其兄弟姐妹相比在特定节点中感兴趣的“热图”。实施例还可以支持自上而下的规范(由父项目的项目管理员)对特定问题细化或其它项目子项的优先级的独立测量。在互斥项目改进的情况下，实施例可以支持在各种项目改进之间设置相对优先级，可能使用[0728]中描述的技术。
实施例可以允许从任何参考该实体的节点查看与任何一个实体相关联的辅助信息，可能仅在用户请求时。“活动”聚合包含与用户正在考虑的某些节点相关联的辅助信息。实施例可以将活动聚合视为由开放节点和空节点组成，或者优选地由所有可见节点组成。为了提供更多控制，聚合可以仅考虑用户选择的可见节点子集在活动聚合中，并且这些可以被适当地着色或以其它方式区分。但是，活动聚合应始终由包含本地节点的连续区域组成。这样的实施例可以让用户在适当的子结构或上下文中选择未选择的节点以包含并且可以隐含地包括沿着到轨迹的路径的所有节点。相反，它可能让用户在适当的子结构或上下文中取消选择所选节点，这将隐式取消选择以该节点为根的逻辑树。随着分层结构中的节点被扩展(或选择可见节点)，与新显示(选定)节点相关联的辅助信息可以被添加到活动聚合，而与显式崩溃期间隐藏的节点相关联的辅助信息以及隐藏在其上的节点扩展(或取消选择)期间的隐式折叠可能会从活动聚合中删除。主要DAG旁边应显示活动聚合。
对于具有封闭上下文扩展的每个上下文节点，可以对其所有祖代(包括其自身)进行聚合，或者优选地，对其所有适当的祖代进行聚合，并且对于具有封闭子结构扩展的每个封闭子结构节点，对所有祖代进行聚合。它的后代，包括它自己，或者，最好是它的所有适当的后代(我们称前者为“整体”，后者称为“成分”)。不是(或除了)为每个闭合扩展呈现这一点，一些实施例可以仅针对一个或多个本地节点呈现它(在这种情况下可能不考虑DAG探测的状态，并且可能包括本地节点本身)。这些聚合可能仅在用户请求时呈现。实施例可能想要为封闭边界上的所有节点维护闭合的扩展聚合，或者仅在请求聚合时计算它们。它们可以被缓存，以便在用户交互期间不需要经常重新计算它们。如果封闭文件夹所代表的某些实体已被延期而不是传递给客户端，如[0328]，则实施例可在结果中包括“更多”链接，以通知用户可能存在更多辅助信息，如果激活，触发将其它节点及其辅助数据加载到本地DAG中。
一些实施例可能还希望与活动聚合一起支持完整的整体和/或组成聚合，其分别合并来自所有整体和组成的封闭上下文扩展的信息。
例如，具有封闭子结构扩展的子结构节点可以聚合与其适当后代相关的事务数据。当它被打开时，每个子节点的事务数据可以通过其节点被访问，并且每个子节点的子结构扩展(假设它们被关闭)可以与其适当后代的事务的单独聚合相关联。
我们呈现了与图215至图226中的实施例交互的用户所经历的另一个示例，用于由文件组成的辅助信息。这些文件可以由用户将其图标拖入或移出适当的区域来上载或下载。根据用户与“依赖关系”选项卡中主DAG的交互，显示相关文件。我们假设所有可见节点都包含在活动聚合中。图215示出了具有五个节点可见的项目屏幕。当用户将光标悬停在可见节点的主图标上时，如果单击该文本，则显示“Aux”文本。因此，我们可以在图216到图220中看到与每个单独节点相关联的文件，并且活动聚合包括所有这些文件。图221具有活动聚合，包括与本地节点相关联的文件以及可见上下文；图222包括与本地节点相关联的文件以及可见子结构；图223包括仅与本地节点相关联的文件。当用户将光标悬停在已关闭的文件夹图标上时，也会显示文本“Aux”。图224和图225示出了每个关闭的文件夹包含具有单个文件的项目。从图226中的组成标签可以看出这两者。
介绍聚合辅助信息
对于某些聚合，特别是标量，定量值，其中聚合占用较少的空间
除了所包括的值(包括子树大小的度量)之外，实施例可以选择将聚合与每个节点一起存储，而不管其状态如何，并且当DAG被增广时根据需要调整这些聚合。
对于活动聚合和“封闭”聚合，各种实施例必须注意避免重复计算可由多于一条路径到达的祖代或后代的辅助信息。对于联合聚合，重复计算是不可能的，因此不是问题，但对于其它形式的聚合，它可能是。
当关闭文件夹时，其聚合可以组合消失的后代节点的各个值(对于各种实施例必须从活动聚合中删除恰好一次)以及它们的后代扩展的聚合。如果聚合中的每条辅助信息都标记为驻留其“树”源节点的实体(或等效地，用DAG节点标记)，可以在关闭文件夹时有效地组合聚合而无需重复计算。更好的是，辅助信息可以表示为每个数据的映射，来自它所源自的实体。为了在关闭文件夹时组合聚合，实施例可以从关闭的节点的各个数据开始，维护所表示的所有实体的列表。对于每个子节点和向该子节点贡献数据但尚未遇到的每个实体，该实施例可以将所贡献的数据合并到新的集合中。
为了标准化该合并过程，实施例可以在聚合中分离信息的密钥和值组件，可以从某个实体到达。可以维护聚合信息并按密钥排序。
在打开文件夹时，在各种实施例中，每个子节点获得先前关闭的文件夹
与节点本身关联的数据，并将该数据添加到活动聚合中。在各种实施例中，每个子节点的扩展文件夹(如果关闭)获得聚合，该聚合是该节点先前关闭的扩展的旧聚合的子集。实施例可以检查剩余数据的每个实体(与正在打开的节点的实体无关)发起，并且对于每个子节点，该实体是否是子节点的后代，如果是，则将其数据包括在该子节点的聚合中。或者，实施例可以尝试从其组成部分重建每个子代的聚合。
为了更有效地处理开放节点，封闭节点的聚合中的数据可以采用a的形式映射不是来自其原始节点的驻留实体，而是来自“流”的表示，例如，具有区分源和宿的DAG，从闭合节点到原始节点。这些流程不仅限于细化关系，还可以包括其它关系。
建议使用以下DAG表示：
流程
Figure GDA0003513598160001201
流量(源，汇，流体)
流体
Figure GDA0003513598160001202
链接()|顺序(流量，流量，流量，......)|关节(流量，流量，流量，......)
该语法强制流具有区分源和宿，以及采用链接形式的体，两个或更多个流的序列，或两个或更多个流的并集。我们在此还要求对于序列，第一个流具有与序列流的源匹配的源，最后一个流具有与序列流的宿相匹配的接收器，并且对于第一个和最后一个流之间的每个流，源匹配序列流的接收器。前面的流程和接收器匹配后续流程的源；对于一个联合，联合中的每个流都有源和接收器与联合流的匹配，并且各种流都没有相互包含。
我们说序列流包含具有相同数量的段的相同源和接收器之间的任何序列，其替代任何组件流被该段流包含的流。我们说联合流程包含其集合中的任何流程。流动的包含关系是传递和反思的。
直觉是流是空的(源与链接相等的链路)，两个节点之间的简单弧(否则是一个链路)，一系列流，当端到端连接从源到源时汇流，或流的联合，所有这些都通过从源到汇的备用路径引导。
可以通过从源节点扫描DAG并且每次遇到特定节点来生成这些流，将遇到它的路径添加到现有流中，作为与沿路径连接元素的链接序列的并集，除非路径已经可以通过流程访问，在这种情况下，流量可以保持不变。
用路径增加流量的另一种方法如下。对于空流，只需将路径作为非空链接序列接受。对于非空链接，请创建一个非空链接序列的联合。对于另一个序列，如果它具有相同的中间实体列表，则创建一个序列，使用非空链接增广序列中的每个流。否则，创建两个序列的并集(也可以提取任何公共前缀，并通过每个序列的其余部分的并集来跟随它)。对于联合，如果路径未被集合的任何元素包含，请添加它并删除它包含的任何元素。要使用非空链接增广非空链接，只需返回链接即可。要使用非空链接增广联合，如果它尚未在联合中，请添加它。
然后，对于各种实施例，当打开关闭节点时，该节点获得与从节点到其自身(空联合)的空流相关联的先前关闭的数据作为单独数据。可以为每个子节点分配与通过将先前关闭的节点的流解构为一组对而获得的流相关联的聚合数据，每个对包括节点(对应于子节点)和从该节点到接收器的流。在解构结构产生的一个流下，为每个子项分配与解构所产生的节点匹配的流的数据。
解构过程如下。对于链接，结果是一对汇聚节点和空流的单例集。对于序列，重复序列中的第一个流以获得一组对；在每对中保持节点不变并按如下方式修改流：如果原始序列的长度为2且对的流为空，则对中的流是序列的第二段。否则，该流是通过将该对流替换为第一段而形成的序列。对于联合，重复联合的每个元素以获得一组对。对于表示为节点的每个实体，形成一对该实体以及与该实体成对的每个流的并集。
如果服务器延迟了信息请求，则关闭文件夹的聚合可能不完整，可以通过请求其它数据来增广。
实施例可以在聚合辅助信息中包括或排除继承的节点，或者它们可以通过复选框向用户提供对该问题的选择。在后一种情况下，一些实施例可以维护每个聚合的两个版本(至少当存在具有辅助信息的继承节点时)，使得它们可以容易地在它们之间转换，但是其它实施例可以在用户改变其选择时重新计算聚合。如果排除了继承的节点，则它们的辅助信息不会合并到任何各种聚合中。
特殊辅助信息
设置同级项目中的百分比
在下文中，在不同时间需要设置百分比以在其子女之间分配关于父项目的定量信息。这可以从父项目本身完成，输入总数为100的数字，或者最好通过调整将字段划分为代表每个子项目的区域的行的位置(在某些情况下，可能适合仅选择特殊类型的子代(问题或解决方案)。甚至可以将该除法过程叠加在节点兄弟的基于树的视图上。
贡献和支付
一些实施例可以支持资金的贡献(可能仅针对问题)或努力(可能仅仅是由系统用户提供的解决方案。在查看此类项目时，可以通过用户上下文菜单中的选项触发此类贡献。下面我们将重点放在资金上，但实施例也可以将这些概念应用于努力，例如显示努力对解决方案的总结贡献。
系统可以跟踪贡献给项目的资金，无论这些资金是否直接流入项目管理员。如果不是，系统的各种实施例也将想要跟踪用于项目目的的支付，但如果是，则这可能是或可能不是期望的。
支持在本地节点的上下文或子结构中为项目分配的总资金和总资金的可视化可能是有用的。实施例可以允许针对各个开放节点显示该标量数据(如在[0712]中)并且针对“整体”和“组成”聚合进行聚合。在一些情况下，实施例可以进一步将显示的DAG节点限制为为其提供资金或者为其分配资金的DAG节点，或者将那些节点通过哪些节点可访问。
如果资金是为项目提供的，项目管理员可能会发现将它们用于某个较低级别的项目是可取的。这应该始终得到支持。
项目管理员可能还会发现将它们用于某个更高级别的项目是可取的。这可能会使基础设施或管理费用为整个组织服务，从而在更高分层上进行。通过项目设置，可以为向上转移的捐款设置允许的百分比。如果需要，可以采取各种检查措施，以防止或阻止向上转移的资金向下流向兄弟项目。例如，可以在有资格进行向下转移的资金之间维持一个部门，或者甚至是否有资格向下转移到特定项目(将可用资金总额的每个划分与合格项目集合相关联)。更严格的是，该系统可以记录特定子代项目中向上转移(百分比或绝对值)的预期。
租金等成本信息可以作为依赖于它的最高解决方案级别的基于时间的辅助信息进行应用和跟踪。或者，房地产可以被实施例视为另一种实体类型，具有其自己的分层细分(通过建筑物，楼层等)并且具有解决方案和位置之间的多对多跨种关系。
工资信息是基于时间的辅助信息，与组织(用户)分层结构相关联。
这两种情况都需要在个人或位置可能服务的各种解决方案之间进行分配。这可以默认为均匀分割，但可以调整到任何所需的分割。在工资的情况下
信息，该划分可以基于通过签到的时间跟踪(参见[0756])。
预算支持
上文提到的进展报告([0705])提供了关于实现广泛目标的定性信息，无论是在组织的核心还是在其周边，个人可以在判断其绩效时使用这些目标。这些措施也反映了负责这些项目的个人。
实施例还可以支持将量化目标设置为性能度量。绩效目标可以标准化(收入，收入，成本降低，客户保留)或特定于问题(可能提高学校内学生的标准化考试成绩)。为了支持后者，实施例可以支持关于问题的性能度量的定义。在任何一种情况下，都可以建立基于时间的目标或预测，并根据实际结果进行跟踪。实施例可以支持各种周期性(年度，季度，月度等)并且允许指定目标或预测的初始值，可能与选择用于增加或减少超时的功能一起。为问题建立的指标通过项目分层结构(不仅仅是改进)继承，以便较低级别的项目可以在某种程度上承担责任。结果，基于在父项目级别定义的百分比。当然，较低级别的项目也可以建立自己的绩效衡量标准。建立绩效衡量指标可以在该项目或更低级别的项目层面输入相应的结果。为特定项目显示各种基础(目标/预测/实际)是很自然的。
在支持互斥改进的实施例的情况下(参见[0631])，可以将针对目标的单个度量的性能视为多条形图，每个基数一个条(目标/预测/实际)，归一化长度是否相同，每个长度由每个专业问题(或解决方案)的贡献或预期贡献编码。如果存在分层结构(如标准的多级部门和子部门细分，或者包括问题和解决方案的项目分层结构)，则可以深入查看结果。也许通过单击代表特定细化的条形部分，该条形可能会扩展(替换或与前一个条形图一起)使用自己的多条形图，反映项目结构的下一个较低的下划分。
这样的兄弟项目可以根据他们达到或超过预期的程度进行评级，突出显示规模两端的项目。它们在条形图中的每个多条形图中列出的顺序可以反映该顺序。
对于任何用户，可以为他们是管理员或协作者的每个项目查看此类图表。如果所有这些都采用了相同的性能指标，则可以合并它们，这样，如上所述，可以从用户级别向下钻取到每个项目。
通用数据集
更一般地，数据集可以与项目相关联并且基于用户对本地化DAG的探索来聚合。汇总的数字数据可以条形图或图形表示，分别带有一个条形或一条线，对于每个选定的属性(此处和下方，我们考虑直接存储和计算的数据属性)。地理数据可以在地图上显示，标记的离散数据点或基于的每个区域着色
与其相关的汇总价值水平。
单个项目可以与SQL，URL或任何其它形式的数据集查询相关联。特定节点的数据是解析查询的结果，例如识别相关数据库项(记录，包括由逻辑连接操作创建的那些)并从那些记录中提取适当的属性值。数据集的规范将隐式或显式地包括数据库的源，必须为要选择的数据项保持的条件，以及从这些数据项中提取的属性值的表达式。跨越各种所选数据项的提取数据值的聚合方式可以包括在后面的表达式中或单独提供。当用户扩展节点时，与新暴露节点处的实体相关的附加数据点被添加到聚合的视觉呈现中，并且当用户收缩节点时，移除与新隐藏节点处的实体相关的数据点，如上所述。
为了避免每次访问节点时必须打开和关闭数据库，实施例可以允许用户将数据库与将从中发生对数据库的查询的实体的最小上限相关联。
项目IP
解决方案可以与专利，专利申请或专利或专利申请的特定权利要求相关联。
专利和权利要求可以通过实施例作为实体来对待。这将提供将权利要求的依赖性结构与解决方案细化分层结构联系起来的机会。例如，实施例可以支持从权利要求到解决方案的跨种关系，以及对权利要求的细化关系。然后，细化解决方案可以继承细化解决方案的主张。更新细化解决方案的继承声明可以创建钻石结构，反映新声明既描述了细化解决方案又改进了继承的声明。
将代码与解决方案相关联
如果项目与传统版本控制系统下的代码存储库相关联，则后代解决方案可以与来自该存储库的(基本)分支相关联，并且任何细化解决方案可以是与衍生(可能是间接的)分支相关联。细化与分支相关联的多个其它解决方案的解决方案可以与包括这些分支的合并的分支相关联。无法保证衍生分支中的代码在任何技术意义上都会细化基本分支中的代码，即使这是意图，只有在基本分支不断重新引入衍生分支时，它才可能成立。
解决方案可以与面向对象语言中的(基础)类相关联。然后，细化解决方案可以与从该基类派生(可能是间接)的类相关联。或者，解决方案可以与(基础)类的方法相关联。然后，细化解决方案可以与从该基类派生(可能是间接)的类的相同方法相关联。在任何一种情况下，无法保证派生类中的代码在任何技术意义上都会优化基类中的代码。一种解决多种其它问题的解决方案与支持多继承的语言中的类或其方法相关联的解决方案可以与从这些类中的每一个派生的类或这种类的方法相关联。
DAG过滤
用户可以通过分面浏览选择实体以将DAG中的实体包括在其中作为本地特征/关系/用户历史。该DAG过滤可以作为复选框的集合呈现给用户，每个可能的属性值或关系类型，用户通过该集合基于它们是否被设置为任何指定值或参与任何实体来指示要包括哪些实体。与标识实体的指定关联，例如主DAG的活动用户或本地。然后，用户可以通过其它相关实体进行探索，并找到所选实体之间的关系。过滤的特征可能包括解决方案状态([0633])。为了按关系过滤，用户可以选择他们想要看到项目的一个或多个角色，如图4所示。或者，要按用户历史记录进行过滤，他们可以选择一个或多个操作(例如项目的资金或志愿服务)以及一个周期或日期范围，并查看他们在该时间段内执行这些操作的项目。对于捐款，也可以按捐款金额进行过滤。
对于签入项目的项目管理员([0754])，可以类似地通过选择一个或多个角色或时间和贡献描述符来选择要包括的用户。
项目管理员还应该能够选择为其提供资金的项目和为其进行支付的项目，以进行比较，或者为其付出贡献的项目。
有可能进一步过滤辅助信息，例如通过周期性(例如，年度，季度，月度)或时间段来过滤辅助信息，用于历史而不是当前信息。
该DAG过滤可以如下实现。服务器可以构建包含所有可能实体的本地DAG，但是根据默认选择或用户先前选择的记录将其中一些(以及它们的一些祖代和后代)标记为隐藏。如果各种选项存储为单独的数据库字段(例如，作为对象-关系映射(ORM)系统中的不同子类的字段)，则可以在创建轨迹实体列表时访问它们中的每一个。服务器可以构造并向客户端传递从构面值到与每个这样的值直接相关的实体id的映射，以及实体描述符集，包括足够的信息以确定每个构面值选择是否特定实体在那个方面的价值选择下。重要的是，对于实体的分层表示，如果在区分实体和给定实体之间存在直接关联，或者任何适当的祖代，则给定实体通常被解释为属于分面值选择，该分数对应于与区分实体的关系。给定实体。在DAG定位期间构造这样的描述符时，实施例可以考虑如果实体属于方面值，其所有后代也是如此，并且如果实体不属于方面值，则其任何祖代都不属于方面值。这些描述符可包括如[0758]中所述构建的描述符。在各种实施例中，客户端应该接收该映射和实体描述符，并初始化上下文和子结构(或者服务器，如果策略0656.1)以基于最初选择的方面值和描述符信息显示元素，然后处理事件选择或取消选择每个方面的值，记录要显示的方面值。一些实施例可以允许本地节点被识别为相关，而其它实施例可以不相关。当选择构面值时，客户端显示与该值直接关联的所有本地节点(通过映射)并且尚未显示(或者如果它们已经显示则突出显示为本地节点，并且实施例允许这样做)，并显示其上下文和子结构，直到达到已显示节点的点。当取消选择构面值时，客户端会隐藏与该值直接关联的所有本地节点(通过映射)，并且实体不会落入仍在显示的另一个构面值(通过实体描述符)。仅仅去除仅满足前者的节点。在任何一种情况下，将其上下文和子结构隐藏到节点实体属于仍然显示的方面值的点(通过实体描述符)。前一过程Select a Facet Value 021200在图227中。后者，取消选择方面值024200在图228中。
项目分层结构中支持版本控制和解决冲突的一种方法
对不同项目视图的支持
项目登录
要求个人用户登录到他们在项目中的任何一个角色，以便支持上下文结构中的另一种形式，使系统得以领悟他们的意图，使实施例能够在两个可能选项中为用户选定其一(也许通过上下文菜单选取)，以及提供建议(在“建议”中)，不仅针对个人用户，而且针对特定项目的特定角色。
实施例可以在上下文菜单中，使任何用户获得公众可用的行动选项。对与某一个特定项目相关联，但未登录到这个角色的用户，也可以显示“请登录到该角色”的选项。用户可以登录到与他有关联项目的项目级别角色，或任何较低级别角色。实施例可以允许用户从某个全局位置退出项目角色，类似于他如何退出整个系统。当用户退出后又重新返回系统时，实施例可以或可以不恢复他的登录状态。一些实施例可能允许用户登录到某一个项目角色，即使他已登录到另一个这样的角色，另一些可能要求用户在进入另一个之前退出当前的角色。在前一种情况下，当用户登录到另一个角色时，实施例应当隐式地使用户退出当前的角色。一些实施例可以允许用户同时登录到多个角色，用户会看到对所有相关角色的上下文菜单选项，这时，可能允许对不止一个角色可以采取的特定操作。实施例可能不允许用户登录到某些子代细化的子项目，如果它们直接涉及[0581]中描述的那些有交互“弱”链接的细化关。
从成本跟踪的角度来看，登录也是有用的，因为它提供了时间跟踪信息。关于每个个人在各种解决方案(或更一般地，项目)中所花费时间的知识可以用来分配他们在所涉及各项目之间的时间。
图229显示活跃用户的用户屏幕，这里该用户没有登录到任何项目。但因为该用户主管本地项目，他看到的一个上下文菜单选项，使他能以管理员角色登录到其子代项目，如图230所示。采取这个选项导致用户登录到那个角色，如图231所示。在屏幕顶部的下拉菜单中不仅能看到用户的名称，我们也能看到他当前的角色和项目。该菜单的选项现在包括“退出”。在登录状态下，在任何他导航的屏幕上，该用户都可以看到与他在这个项目中的角色有关的上下文菜单选项和建议。选择“退出”之后，用户将回到图229的状态。
通过在服务器上保持当前项目和每个用户的当前角色，可以支持这种行为，它将是空的，如果用户并未登录到任何项目。本地DAG可以构造成包括在每个项目实体中，无论用户在那个项目实体中的每个角色下是否有权利(例如，在活跃用户与那个项目或它的任何适当的前驱项目节点之间，是否有直接参与关联。这将允许客户确定是否在分层结构中显示登录选项。实施例可以认为，如果登录选项对任何节点都存在，它对所有子代项目的节点也都存在。当创建新节点时，客户应当保持同样的政策，或者认为活跃用户是任何新节点的管理员，或者，如果一个新节点没有前驱，活跃用户便是一个管理员，与服务器的政策保持一致。当一个变更出现在当前项目时，实施例可以或可以不重新加载客户端页面。一些实施例甚至可以不要求服务器知道任何用户的登录状态。这些实施例将在当地保持可获得的菜单选项，并基于用户的登录状态，要求建议或时间跟踪服务。
选择性知识共享
仲裁
一些实施例采取这样的安排，群众提供的贡献在被核准前，只为贡献者和项目管理员可视，核准后成为公开可视或组织内部可视。当一个变更被提交时，它被标记为需要核准。这样的系统至少可以支持反映已经核准或无需核准变更的一个DAG“全局”视图，反映等待核准的变更的每个用户的用户DAG视图，以及以某种形式使所有需要核准的变更在其中可视的一个“管理员”视图。用户既可以查看已经核准的变更，也可以查看他自己的变更，无论它是否已被提交核准。通过DAG的变更日志，项目管理员可以看到与任何用户视图相关并等待核准的变更。也可以提供一种设施，使得项目管理员可以获得用户视图，查看反映全局变更和由该用户提交核准的内容。数据库记录(既包括变更记录也包括当前记录)，于是应该有是否已经核准的标记，连同至少还有未核准记录，包括做更改用户的ID，以便控制可视性。这样做的目的是，一旦某条记录得到核准，它就成为“全局性”的，不过这一名称可以有多种可能的含义，取决于实施例支持的访问模型和所在组织的使用；不过它也有可能成为对作变更用户和核准者以外的个人是可视的。
一些实施例可以允许，在全局DAG中级别较低项目管理员的行动，需要更高级别项目管理员的核准。于是在某些情况下可能需要一个核准序列。
在审查变更中，管理员应该能够在“接受”和“拒绝”之间选择，对于“接受”，应该能够选择访问级别(在简单的情况下，或是公开的或是只在组织内部)。
为了便于仲裁，代理项目管理员的用户(如在[0754]中那样登录)需要能够容易地识别那些需要采取行动的实体，例如需要核准的新项目。
任何用户应该能够标示一个公开实体需要仲裁。一个实施计划可以然后，在收到一个或多个这样的报告后，并且可能取决于其它因素，包括作标示用户的信誉，最近变更的新旧程度和项目的活跃程度，回滚到该实体的最后一次变更，等待进一步审查。
项目访问的设置
为了简单起见，我们在这里假设只有“公开”和“内部”两种访问级别，当然可以有更细致的设置。设置可以根据项目角色确定([0822])，包括未与本项目关联的用户。在组织或用户级别的设置可以确定项目顶级的默认可视性。如果一个项目是内部的，所有较低级别的项目都可以被认为是内部的。如果一个项目的所有双亲都是公开的，实施例可以默认其为公开的、内部的或需要仲裁的。也许这取决于所涉及的操作(例如，细化的解决方案或问题、求解过程、组件化和编辑)或其它因素。
其它选择性知识共享
实施例可以利用如[0754]中所描述的项目登录，使得用户只能访问与他们所在特定项目角色相关的部分。
如在[0433]所述，项目结构可被用于控制继承项目(或其它实体)包括哪些用于响应用户请求的信息。
分级版本控制
记录替代分支中的独立变更
如果有系统变更的独立部分，那些变更应当被记录在DAG的一个单独分支中。其优点是，任何单个独立变更可以被撤消而不至于干扰被认为是不相干的变更。这样的“干扰”将以冲突的形式出现而必须予以解决，给涉及的用户增加了负担。我们并不完美地知道什么样的变更是独立的，所以这种方法的成功很可能取决于我们的洞察力。
对于大多数目的，不同的项目设置可以被认为是独立的。
文本文件的处理较为困难。可以使用“差异(diff)”文件比较，如在标准版本控制中那样识别修改过的行。“差异”文件甚至可以根据相似性把修改过的行分为若干“大块”，虽然这带有很大的主观性。这样，或者行的每次插入、删除或修改可以被看作是独立的变更，或者每一大块可以根据无论哪一种定义独立地处理。
尽管“差异”一般在替换整行的级别起作用，同样的技术可以应用于逐个字符的替换，用“diff”文件识别哪些字符曾被替换过。这无疑将提供更细致地鉴定差异和从而更多看起来是独立的变化。但不难举例说明，许多单独变更旨在作为一个单元，撤消其一而未撤消另一可能会导致不可预测或不利的结果。所有在同一时间提交的变更(同一“会话”编辑中的部分)可以被视为单个变更。也可以提供一种操作，连接两个不然是独立的变化，使它们被视为单个变更。
如果变更在输入时，而不是在提交时收集，通过限制用户可获得的编辑选项，和记录他们的行动，我们可以得到他们对变更意图的一些洞察，也可以避免歧义，如在[0296]所提及。当所有变更都发生在一个专用平台时，这也许是可行的。例如，一个实施例可以，除开选定的文本，禁止删除其它的，所以去除一块文字可以被认为是一种原子操作。这使得系统无需纠结于看起来可能是高级别操作一部分的那些低级别操作。
如果一个后来的变更包括了多个以前的变更，那些分支会合并。较大较后的变更也许不得不回滚，以使任何较早较小的变更可以回滚。删除实体会是一个牵涉很广的变更，因为它会包括所有以前的变更。因此，一个DAG可能采取插入节点的形式，使各种变更的路径全部会聚到一个删除节点。
如果一个实体从一个双亲转移到另一个，例如，一个解决方案从一个问题移用到另一个，如果在一个实施例中，这种交互关系是多个对一个，它可以被看作是修改了该解决方案决方案。因此，我们可能有一条途径包括“解决方案S在P1问题产生”的路径，子代两个分支：“解决方案S移转到P2问题”和“解决方案S的文本T1被文本T2在字符范围内替换……”。
由于移动实体是系统记录的一个原子操作，我们可以如是处理。
从文本场的一部分，把文本复制到另一部分，会被自然地认为是插入，但如果特别地把它看作是一个副本，那么如果原始文本被修改后重新应用，我们就可以保持那种看法。
从文本场的一部分，把文本移动到另一部分，也可以被认为是一个原子操作，如果原始文本被修改后重新应用，我们就可以保持那种看法。这样处理文本移动的附加优点是，我们可以把移动置于单独的变更分支，而不是把它当作分离和独立的删除和插入。
每一个这样的原子操作可以被认为是版本控制下的“提交”标准。在传统的版本控制下，每一个变更都被默认为贡献于当前分支的下一个可能出现的提交。工作必须显性地分为串行提交和并行分支，然后显性地合并。
对于已上载作为项目附加数据的文件([0705])，存在着与传统版本控制整合的潜力。支持上传文件在线编辑的实施例，可以要求服务器在用户提交或识别出其它用户变更后，记录一个提交。在任何情况下，可以在每一次文件上传(包括更换已经上传的文件)后生成一个提交，每个这样的提交对应于单一修改变更(每个不同的文件被看作一个单独的部门)。当回滚时，服务器可以直接指示传统版本控制系统，撤消当前提交而恢复到以前的提交。
支持撤消回滚的实施例(见[0802])，将不会破坏提交而只是为它创建一个新的分支，并存储那个回滚分支的变更记录。主分支将被重新设置为以前的提交。一旦撤消回滚，主分支将被重置为回滚分支内容，而回滚分支可以被删除。
历史和冲突
把可能的变更分配到数目固定的各部门中。各部门可以是离散的，如同配置的可选选项，或者它们可以用范围或一对范围或范围集合表示，例如在一个场中文本的变更、去除、复制、或移动(见[0775]和[0776])。对不同文本区域的编辑，潜在地彼此兼容，如不同的子代移至公共的双亲(除非需要附加结构)，或设置不同的配置选项。对同样部门的编辑有冲突的潜在可能，正如任何其它变更与记录删除。所有修改编序的标准实践，然后对应于把每个实体作为单个部门来处理。
保持任何类型用户数据对系统中任何类型非变更记录的变更的变更记录。这些变更与一组部门相关联，正是这些变更记录被安排在一个DAG中。对于各种实施例，变更记录通常将含有一个指示任何内容从旧记录中被丢弃的标记，以及指示新内容被安置的另一个标记。每一个变更记录影响到一组部门。这些受影响的部门可以，例如用一个二进制数表示，每个被定义的部门是一个比特，尽管也可以有多种其它表示方式。也可以使用完整的历史记录，而不只是变更记录。
为了形成全局日志DAG，将每个变更记录作为一个实体，并连接影响任何相同部门的前驱记录(作为双亲)和子代记录(作为子代)。这种关系是多对多的，但在每次变更后，各部门被有效地分区，使得每个分区都有一个唯一的前驱或子代变更记录。与其它DAG一样，全局日志DAG可以被定位到一个特定的变更，在这种情况下，查看上下文中的前驱状态和子结构中的子代状态。
一些实施例可以单独处理不同的实体，即使它们是相互关联的。其它方案可能超越[0772]中描述的简单结构。它们可以认为DAG增广是对增广记录(具体化、泛化或不同类型间的关联如在解决方案之间)的变更，以致在回滚衍生物实体到创建状态之前，不可能回滚一个实体到创建状态。一些最初作为根节点创建的实体的变更日志，然后包括所有它的增广(直接的和间接的)以及对实体和任何那些增广的修改。这就提出了如何处理实体在不同双亲之间移动的问题。这样做可能会留下一小段“移动”节点，作为每个源双亲的子代，和潜在的一系列“移动”节点，带着子代朝向最终目标移动。
应该可以按照做过变更的用户或项目过滤日志。一些实施例可以把日志作为次要DAG(见[0605])呈现给负责的用户或项目，包括负责用户范围的变化。如果日志被用来表示对其它实体的变更，例如用户或技能，那么也可以将这些作为次要的DAG呈现，或是一个用户DAG，用于选择负责用户的范围，或是一个合适的实体DAG，用于选择的变更应该包括在内的实体范围。
对主要实体的选择很可能影响日志条目如何显示。一个删除节点(也许标以“×”)总可以被设置为叶。一个创建节点(也许标以“+”)总可以被设置为没有双亲实体的根，否则可以在逻辑树中设置为其任何一个双亲的创建节点的子代。一个变更节点(也许标以“～”)可以被设置为一个非根节点。如果仅仅观察非独立实体，日志的根可以是其创建节点，而在相同的跨种关系下从一个独立节点移动到另一个，可以用关联于这种关系下专注于直接对象部门的一个内部节点(也许标以
Figure GDA0003513598160001311
)来表示。这样的节点可以被级联为多个相继移动。在不同跨种关系下从一个独立节点移动到另一个，可以被看作在涉及的不同关系下影响双亲部门。在细化中去到或来自双亲的移动和其它多对多的关系，可以被视为影响所涉及的每个双亲实体的单独部门。如果在一个不独立实体下看独立实体，其创建节点可以被设置为内部节点，在跨种关系下影响双亲部门。父节点可以是该双亲实体的创建节点，如果子实体是直接创建的一个增广，或者是一个移动-自节点(也许标以“→”)，如果子实体移动到双亲。移离该双亲(对象的变更)，若在其对象下看独立实体，可以用一个移动-到叶节点(也许标以“>—”)表示。实施例可以选择使用其它标记或图标。
回滚操作可以从DAG的任何节点发起，并对各种实施例撤消根值于该节点的整个子树，从叶子(以任意次序)开始，向内推进。
变更分层结构本身的链接是类似的，‘最新的’变更记录(分层结构中的一叶)和导致的当前记录，由一个数据库关联相连接。当用户修改实体数据时，这可能对延展变更分层结构是必要的。又，部门被有效地分区，使得每个分区都有一个不同的最新变更记录。最初变更记录创建的实体被认为影响所有部门。
当一个用户或多个用户对各部门提议的变更，与先前的变更有所重叠时，需把它们整理有序；先前的变更被认为是属于对先前变更影响的部门组，减去子代变更影响的部门组的“记录的变更”，而子代变更被认为是对所有受影响部门的“记录的变更”。
正如我们已经看到的，当一个用户或多个用户对各部门建议的变更，与先前的变更不相重叠时，将出现分支。在这种情况下，对于不同的实施例中多个子代的变更记录，将在一个与非重叠部门相关的家长变更记录下创建。
当不同用户(或来自不同会话的相同用户)提议不同的变更来追随相同的先前变更时，也会发生分支，影响重叠的部门。这当两个用户(或来自不同会话的相同用户)，未更新页面即退出时也会发生。这样的变更被认为是冲突。
冲突也有可能发生在变更可视前需要核准的用户系统，如[0759]中所述，采用这样的仲裁，任何变更(包括增广，不只是修改)被提交后，该变更被标记为需要核准。对任何实体咨询值和视图(全局的或对特定用户的)，只有一个当前记录可以存在。由数据库记录可以给出用户的一个咨询值，反映其未经核准的变更，或者这样的内容可以通过应用对该用户的未经核准的变更记录，当必要时由全局内容引入页面加载。在两种情况下，对未经核准变更的变更记录，应该对用户标识，最新的这样的记录可以为任何用户、实体和选定部门获得。
合并发生在用户提议的变更影响许多有以前更改的部门，或者是直接的(如在[0772])，或者当判断为是以前的变更发生冲突时的解决方案。冲突的解决本身可能会或可能不会被视为，与影响任何同样部门变更的冲突，这些部门受到正在解决方案决(包括同一冲突的其它解决方案)中的这些变更的影响。
为了创建根实体，只需要创建一个用户或全局变更记录(取决于是否需要核准)，所有部门标记为受到影响，并把它与新用户或代表实体的全局当前记录相关联。
当服务器就已有实体对客户端满足负载请求时，它可以把从部门对变更记录的映射传递给客户端。如果客户端然后要求实体的变异，它可以把这种变更请求传回做映射的服务器，或者它可以计算以前的变更，得到受影响的部门，并传递那些记录的ID。替代之，服务器可以跟踪，哪些客户端会话正在处理哪些变更记录。当服务器从客户端接收到对特定记录作特定变更的请求时，它可能需要对受影响的部门，连同与对重叠部门以前的变更记录的任意数量的关联，创建一个变更记录，更新当前记录，并将其与新的变更记录关联。
即使一个变更记录已被接受和当前记录(核准或未经核准的记录)已被更新，仍可能收到建立以前变更记录的一个子代的请求。在这种情况下，实施例可以创建一个事实上的冲突，回滚居间的变更，使当前记录反映了两个序列的最后共同状态。在某些情况下，也许不可能从最后的公共状态以后，作超过一个的单一变更。
一个冲突记录的创建，允许全局视图管理员或用户视图的用户，得以快速识别和解决冲突。它包含对冲突变更记录和受影响部门的参考(以一些明确的格式，诸如共同祖代状态)。
因此，首先，如果对相同咨询值的实体，任何已经核准的变更由任何用户输入，或未经核准的任何变更由相同的用户输入(这里需要核准)，可能有冲突的部门，来自相同的以前变更记录的变更，没有任何明确的优先级，且对该实体的咨询值和该视图，只有一个当前记录可能存在。因此一些实施例可以标记这样的已经核准的变更为未经核准的、不再是当前的，和创建一个冲突由管理员来解决，或把这样的未经核准的变更标记为不再是当前的，创建一个冲突由该用户来解决。替代之，也可以搁置这个变更视为已经成功，直到冲突得到解决。
服务器可确定其编辑基于的变更记录对受影响的部门是否仍然是当前的。如果不需要核准，只需要检查赖以编辑的全局记录是否仍然是当前的。如果不是，也许要标示一个冲突。一种方法是把近期的变更看作未经核准的变更，并把它们回滚，直到赖以编辑的全局记录是当前的。然后创建一个新的未经核准变更的记录，创建一个对用户的当前记录，反映那些变更，并把新的变更记录与先前的变更记录和新的当前记录相关联。另一种方法是不触及全局当前纪录，为该用户端视图创建新的未经核准变更记录和未经核准变更当前记录。如果核准是需要的，服务器应既检查用户是否有任何更近的变更记录，也检查和用户编辑所基于的任何序列是否仍然是当前的。如果找到更近的用户变更记录，或者任何提到的选项可应用于该用户，且该用户可以留下来解决方案决冲突。如果找到更近的全局记录，回滚任何东西回去是不合适的。再次不触及全局当前记录，并创建新的未经核准变更纪录和未经核准的当前记录作为该用户的视图。处理变更请求的一个过程见图232。
查看日志时，管理员应能看到对不同部门冲突的列表，并获准选择一个来解决。解决方案应允许选择一个更新或在其间复制和粘贴文本，然后核准这种变更，或拒绝所有变更。如果实施例允许核准和拒绝与其它变更发生冲突的变更，应用请求变更(RequestChange)001请求新的变更解决方案。
为了对全局视图核准一个用户变更请求，服务器应检查后续对受影响部门建立一个以后的变更记录的全局变更。如果有任何一个存在，应该确保当冲突妥善解决后，使未经核准的变更记录遵循之。然后，变更记录可以被标记为已经核准，更新当前全局记录以反映这些变更。当前全局记录应当关联这个变更记录。如果这是对该实体和用户视图最后剩余的未经核准的变更，对当前用户记录并无需要，可以将其删除。最后，如果该核准用以解决冲突，冲突标志可以去除。一种用于核准变更请求的流程见图233。我们这里假设所有前驱变更记录都已被核准。为了也能对未经核准的前驱变更记录进行操作，这个过程应当对之反复，最早的首先进行。由于变更记录形成一个DAG，实施例可以记录访问记录，以便每个只处理一次。
拒绝一个变更较为简单。删除未经核准的变更记录，然后在对该实体的用户当前记录中，撤消它指定的变更。用户运行记录应与以前的变更记录相关联。其余步骤类似于图233中的那些。用于拒绝变更请求的过程如图234。我们在这里假设所有前驱变更记录均已被核准。为了操作未经核准的前驱变更记录，这个过程应当对之反复，最早的首先进行。由于变更记录形成一个DAG，实施例可以记录访问记录，以便每个只处理一次。
用户还可以查看日志记录来选择要回滚的变更。管理员选择一个已经核准的变更或用户的未经核准的变更进行回滚，而一般用户只能选择他们自己的未经核准的变更进行回滚。可以选择尚未回滚的变更记录进行回滚。撤消在一个变更记录中所指定的跨越替代路径变更的操作应该是可交换的，这应该是可能的，因为在不同的路径上的变更应该是彼此独立的。用户可以，例如，恢复已被删除的记录，使得它们可以由基于根据先前状态的当前变更来更新。这涉及把变更记录标记为已回滚，使得其显示可以指示这一点，进而使它可以用于撤消回滚。它还涉及撤消当前记录中的特定变更，并关联当前记录于正在进行的回滚之前的任何变更记录。又，如果用户当前记录不再与全局记录有所不同，我们将予以删除。回滚单一变更记录的一种过程见图235。我们在此假设任何后续变更记录已经被回滚，但前驱变更记录没有被回滚。为了操作尚未被回滚的子代后续记录，应当对之反复，最晚的首先进行。由于变更记录形成一个DAG，实施例可以记录访问记录，以便每个只处理一次。
如果变更的核准和拒绝，出现在带有其它变更的日志中，实施例可以支持把它们回滚回来，显性明示或推迟，与核准的冲突。
在首选的实施例中，做回滚不一定是永久性的(否则，无理或错误的回滚可以是非常有害的)。被回滚的变更可以在日志中显示为灰出(可视但不可操作)。因此回滚可以自行撤消。撤消回滚将使它仿佛从未发生过(从而无需回滚一个回滚的撤消)。
回滚既可以由管理员对全局视图撤消，也可以由个人用户仅对个人视图撤消。一个当前用户记录可能需要被创建，如果它不存在，且回滚是对一个用户撤消的。变更记录应该被标记为未回滚，并使之可从重现变更的当前记录中得到。用于变更回滚的一种过程示于图236。我们这里假设任何以前的变更记录并未回滚。要操作以前变更记录的回滚，这个过程应该对之反复，最早的首先进行。由于变更记录形成一个DAG，实施例可以记录访问记录，以便每个只处理一次。
其它问题
DAG的变异
因为结构很少一次性完美创建通过，许多实施例可以支持DAG结构的变异操作。这些操作可能发生在子结构或上下文，但一些实施例可能将其限制为仅在子结构。
编辑
编辑是DAG变异的最直截了当的形式，因为它保持子结构不变。正如个别节点在就地反复中修改，相同的发生在编辑过程中，只不过替代隐式创建新节点，客户端和服务器确实修改在特定节点的信息。
取消链接
取消一个节点的链接涉及把它与其双亲分离，在逻辑树中形成子结构或上下文。它仍然可以通过其它链接联系。但如果并非如此，不与该逻辑树其它部分相连接的节点及其所有子代可能被破坏，而使它们在其它实施例中成为不可达到的。这可以通过在树中下降，删除只有一个双亲的节点来实现。删除链接终止于到达有多个双亲的节点之前，并停止下降。
客户端可以进行对本地DAG的操作。服务器可能需要在全局DAG中重复它，并可能会发现，在本地DAG中不可能达到的节点，实际上在全局DAG中可以达到，因而并未被破坏。
本地节点的链接不能被去除。
删除
这里实际上有两个潜在的操作，区别方法是根据节点是否被删除而扩展了一个非空的子树，或者它是否或为空或闭合。
如果它是空或闭合的，各种实施例可以简单地破坏该节点和它的所有子代(在逻辑树中)。当实施例下降时，它们可以去除其它节点到正被删除节点的任何链接。这一操作既可以在客户端也在服务器上执行，唯一的区别是，服务器可以去除其它链接。
节点的扩展文件夹是打开的，实施例可以只破坏那一个节点，在每个它的子代的双亲列表中替换正在被破坏的节点和被它使用的父节点，在它使用的父节点的子代列表中，替换正在被破坏的节点连同正在被破坏的节点的子代列表中的每一个元素。
可以提供附加操作删除本地节点，它可以处理其上下文和子文件夹是如上的打开、关闭或空的各种情况。
在打开的扩张文件夹上的操作，最适合于任何两种实体之间只有一个关系的情况。否则，用户可能需要查询他们希望使用的关系，桥接被删除节点之间的间隙。
剪切和粘贴
能够选择一个节点，切割它和粘贴在其它地方是有用的。这可以再次采取多个操作的形式，取决于被切割节点的扩展文件夹是打开或关闭/空。
如果被切割节点有一个关闭的扩展文件夹，意向是移动整个子树到别处。从被切割节点到所在地的路径被捕捉并保存，以及(如同标准实践)被切割节点的图像略显模糊，表明它已被切割。如果没有后续粘贴操作，(又如同标准实践)被切割节点恢复原样。如果有后续粘贴操作，被切割节点的链接取消(只是那个未破坏的节点)，而它使用的双亲被替换为它被粘贴的节点。
如果间接对象被存储，且约束[0337]或[0460]被强制执行，当细化关联被创建中和被移动的根节点是其对象的本地DAG的一个子代时，需要一个类似于上述“现有实体DAG的细化”案例的证明。
切割一个其扩展文件夹打开的节点可以诠释为去除那个节点(类似于上面删除一个开放节点)，并把它作为子代插入粘结点。一些实施例可以，如果扩展文件夹在粘结点是打开的，去除单一节点低于过去的节点，但高于其子代，不过对于整个子树没有类似的去除操作。
从打开的扩展文件夹作切割的操作，最适合在任何两种类型的实体之间只有一个关系的情况。其理由与上面对删除的相同。
细化文本与被细化文本的差异
不是用一个细化实体的文本作为特定实体的默认初始文本，或一个具体化实体的文本作为泛化实体的默认初始文本，加以编辑并丢弃，实施例更可以选择存储文本中的差异连同新文本。然后，如果文本未经变更的部分在原始实体中修改，我们可以通过调整新实体差异的规范，重新计算其文本，以使变更合并到原始实体。例如，如果在特定文本中把5个字符加入到字符串的第10个字符位置，并且稍后到被细化节点的更新去除了3个字符(第4到第6)，差异规范会被修改为以下陈述：5个字符的文本添加到字符串中字符7的位置，而那3个字符也从细化文本中删除。这需要记录任何现有实体的特定或一般实体或标记或把每个细化关联到它被应用的方向，使得在每一次修改中，任何特定或一般实体(不论是直接的或经由一个细化的序列)，可以被适当地调整。
项目治理
个人可在不同的角色下(潜在地包括管理员，顾问、合作者，投资者)与项目相关联。管理员负责审查项目活动；顾问提供对提出想法的反馈；帮助实现他们的项目；合作者帮助实施项目(也许只是解决方案决方案)。投资者可以或可以不被视为顾问。
使用这些技术，项目的各种各样集中和分散治理方式是可能的。所以这是一个用来比较它们的效果的理想框架。集中式结构，将有一组固定的管理员来审查所有内容。一个不太集中的结构将允许个人关联(或创建)更一般的问题和解决方案决方案，代表那些项目决策，那些在项目分层结构中地位较高者支配地位较低者。项目分层结构的增广然后将会由正在增广过程中的一个或多个实体的负责人审查。此外，用户增广项目的任何或选择的行动，可以由被增广项目的管理员复审，只要项目管理员视这种监督为宜。
取代之，可以确立一种投票机制，很可能基于项目中的推断影响力分摊票权。某些个人可能必须比其它人更多地参与项目的细节，但很多人可能知道在一个项目中他们信任谁和尊重谁，许多方案可以支持代理投票治理，其中人们授权别人代表他们回答诸如，何时实施解决方案决方案和修改项目结构中的冲突如何解决方案决。这样的授权可以对一个特定项目做出，并通过项目的子结构继承，但可能会对子结构及其子代的任何特定元素改写。多种实施例可以支持委派的链接。
对一个项目的影响，可以通过与项目结构的创建和/或被那个个人编辑相联系的后续行动，包括但不限于那些项目结构的增广，来加以推断。
本文所述的某些实施例包括析取多个组件、引擎或者机构。引擎可以构成软件引擎(例如，机器可读的媒体包含的代码)或硬件引擎。“硬件引擎”是可执行某些操作的有形单元，并且可以以某种物理方式配置或设置。在不同的示例性实施例中，可通过软件(例如，应用程序或应用程序的一部分)将一个或多个计算机系统(例如，独立的计算机系统、客户端计算机系统或服务器计算机系统)或计算机系统的一个或多个硬件引擎(例如，一个处理器或一组处理器)配置成运行来执行本文所述的某些操作的硬件引擎。
在一些实施例中，硬件引擎可以以机械、电子或其任何合适的组合方式实施。例如，硬件引擎可包括永久配置来执行某些操作的专用电路或逻辑。例如，硬件引擎可以是专用处理器，如现场可编程门阵列(FPGA)或特定用途集成电路(ASIC)。硬件引擎还可以包括通过软件临时配置来执行某些操作的可编程析取电路。例如，硬件引擎可包括由通用处理器或其它可编程处理器执行的软件。一旦经这种软件配置，硬件引擎就成为专门定制来执行配置好的功能的专用机器(或机器的专用组件)，而不再是通用处理器。必须注意的是，在决定是通过永久配置的专用电路还是通过临时配置的电路(例如，通过软件进行配置)用机械方式实施硬件引擎时，必须考虑成本和时间。
因此，应当将术语“硬件引擎”理解成包括有形实体，即物理构造的、永久配置(例如，硬线连接)或临时配置(例如，编程)来以某种方式运行或执行本文所述的某些操作的实体。正如本文所采用的，“硬件实施的引擎”指的是硬件引擎。对于其中硬件引擎是临时配置(例如，编程)的实施例来说，无需在任何一个实例中立刻对每个硬件引擎进行配置或实例化。例如，在硬件引擎包括通过软件配置成专用处理器的通用处理器的情况下，所述通用处理器可在不同时间被配置成各不相同的专用处理器(例如，包括不同的硬件引擎)。因此，软件可将一个特定的处理器或多个处理器配置成，例如在一个时间实例中构成一个特定的硬件引擎以及在另一个不同的时间实例中构成另一个不同的硬件引擎。
硬件引擎可向其它硬件引擎提供信息，并且可从其它硬件引擎接收信息。因此可以认为所述硬件引擎相互之间是通信连接的。在多个硬件引擎同时存在的情况下，可通过所述硬件引擎中的两个或多个硬件引擎之间的信号传输(例如，经由合适的电路或总线)进行通信。在其中多个硬件引擎在不同时间被配置或实例化的实施例中，可通过，例如在被所述多个硬件引擎访问的存储结构中存取信息来实现这些硬件引擎之间的通信。例如，某个硬件引擎可执行一项操作，并将该操作的输出存入与之通信连接的存储设备中。随后，另一个硬件引擎访问该存储设备，检索和处理所述存储的输出。硬件引擎还可以与输入或输出设备进行通信，并且可对资源(例如，信息集合)进行操作。
本文所述的示例性方法的各种操作至少部分是由一个或多个被临时配置(例如，通过软件)或永久配置来执行相关操作的处理器执行的。不管是被临时或是永久配置，这些处理器可构成运行来执行本文所述的一个或多个操作或功能的处理器实施的引擎。正如本文所采用的，“处理器实施的引擎”指的是使用一个或多个处理器实施的硬件引擎。
同样地，本文所述的方法至少部分是处理器实施的，一个特定的处理器或多个处理器为一个硬件实例。例如，一个方法中的至少部分操作可以由一个或多个处理器或处理器实施的引擎执行。并且，所述一个或多个处理器还可以运行来支持所述相关操作在“云计算”环境内或作为“软件即服务”(SaaS)的执行。例如，至少部分操作可由一组计算机(如包括处理器的机器实例)来执行，可通过网络(例如，互联网)和一个或多个合适的界面(例如，应用程序界面(API))对这些操作进行访问。
某些操作可以在多个处理器中进行分布式执行，这些处理器不但可以位于单个机器内，还可以部署在多个机器内。在一些示例性实施例中，处理器或处理器实施的引擎可以位于单个地理位置(例如，位于家庭环境、办公室环境或服务器场内)。在其它示例性实施例中，处理器或通过处理器实施的引擎可以分布在多个地理位置。
语言
在整个说明书中，可在多个实例中实施作为单个实例描述的组件、操作或结构。尽管一个或多个方法的各个操作是作为单独操作来说明和描述的，但是所述操作中的一个或多个可以并行执行，并且，没有要求所述操作必须按照所说明的顺序执行。示例性配置中作为多个独立组件呈现的结构和功能可以作为组合结构或组件来实施。同样地，作为单个组件呈现的结构和功能可以作为多个独立组件来实施。这些及其它变化、修改、增加和改进都落入本文主题的范围内。
尽管已经根据具体的示例性实施例对本主题的概要进行了描述，但是在不脱离本公开的实施例的更大范围的前提下，可以对这些实施例进行各种修改和变化。出于方便，同时在并非意在将本申请的范围限制为任何单个公开或概念(如果实际上不止一个被公开的话)的前提下，本主题的这些实施例可以仅以术语“发明”在本文中单独或统一命名。
为了让本领域的技术人员能够实践所公开的内容，对本文中说明的实施例进行了充分详细的描述。可以使用并从中衍生出其它实施例，以便在不脱离本公开范围的前提下可对结构和逻辑进行替换和更改。因此，具体描述不应被视为限制，同时，仅通过附加的权利要求书以及所述权利要求书享有的全部等效内容对各种实施例的范围进行定义。
必须注意的是，“引擎”、“系统”、“数据存储”和/或“数据库”可以包括软件、硬件、固件和/或电路。在一个例子中，一个或多个包括可被处理器执行的指令的软件程序可执行本文所述的引擎、数据存储、数据库或系统的功能中的一个或多个。在另一个例子中，电路可执行相同或相似的功能。可选实施例可包括较多，较少或者功能上等效的引擎、系统、数据存储或数据库，并且仍然在本实施例的范围。例如，可对所述各种系统、引擎、数据存储和\或数据库的功能进行结合或划分。
本文所述的数据存储可以是任何合适的结构(例如，动态数据库、关系数据库、自参考数据库、表格、矩阵、数组、平面文件、面向文档的存储系统、非关系型No-SQL系统等)，并且可基于云或其它方式。
正如本文所采用的，可以将术语“或”理解为包括或排除。并且，本文中作为单个实例所述的资源、操作或结构可以有多个实例。此外，各种资源、操作、引擎和数据存储之间的界限不是那么严格，而且特定的操作在特定的说明性配置的背景下进行说明。其它设想的功能配置都可落入本公开的各种实施例的范围内。通常，示例性配置中作为独立资源呈现的结构和功能可以作为组合结构或资源来实施。同样地，作为单个资源呈现的结构和功能可以作为独立资源来实施。这些及其它变化、修改、增加和改进都落入如附加的权利要求书所代表的本公开的实施例的范围内。因此，本说明书及附图应被视为是说明性的而非限制性的。
前面所述的每一个过程、方法和算法都可以包含在由一个或多个包括计算机硬件的计算机系统或计算机处理器执行的代码模块中，并全部或部分通过所述代码模块自动化。所述过程和算法可部分或全部在特定用途电路中实施。
上述各种特征和过程可以彼此独立地被采用，也可以以各种方式相结合。所有可能的组合和次组合都落入本公开的范围内。此外，在一些实施方式中可以忽略某些方法或过程块。本文所述的方法和过程也不限于任何特定的顺序，并且与之相关的块或状态可以按照其它合适的顺序执行。例如，所述块或状态可以按照除具体公开的顺序以外的顺序执行，或者多个块或状态可以结合在单个块或状态中。所述示例性块或状态可以顺次、并行或者以其它方式执行。可以在所述公开的示例性实施例中增加或去除块或状态。本文所述的示例性系统和组件的配置可与上述配置不同。例如，相较于所述公开的示例性实施例，可以增加、去除或重新设置元素。
除非另有特别说明或者在所使用的上下文中有其它的理解，“能够”、“可”、“也许”或者“可以”等条件语言通常指的是某些实施例包括某些特征、元素和/或步骤，而其它实施例则不包括。这样，此类条件语言通常没有暗示特征、元素和/或步骤在任何情况下对于一个或多个实施例来说是必须的，或者一个或多个实施例必须包含在有或没有用户输入或提示的情况下决定这些特征、元素和/或步骤是否包含或者要在任何特定的实施例中执行的逻辑。
本文所述的流程图中的和/或在附图中描绘的任何过程描述、元素或者块应当被理解成可能代表代码的模块、分段或者区段，其中包括一个或多个用于实施特定逻辑功能或者过程步骤的可执行指令。候选实施方式包括在本文所述的实施例的范围内，其中，可以不采用所显示或讨论的顺序来删除元素或功能，包括大体上并行的顺序或倒序，正如本领域的技术人员所能够理解的，这取决于所涉及的功能。
需要强调的是，可以对上述实施例做出许多变化和修改，其中的元素应当理解为包含在其它可接受的实例中。所有这些修改和变化都旨在包含在本公开的范围内。上述描述对本发明的某些实施例进行了详细说明。然而，必须注意的是，无论上述内容在文中是多么的详细，本发明可以以许多方式实施。正如上面所叙述的，应当注意的是，在描述本发明的某些特征或方面时所使用的特定术语不应当理解为是暗示本文对所述术语进行了重新定义，以限定包括与所述术语相关的本发明的所有特征或方面的任何具体特点。因此，本发明的范围应当按照所附权利要求书及其任何等效内容来理解。

Claims (66)

1.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
耦合到处理器实现的引擎的显示器，
其中处理器实现的引擎根据存储在存储器中的指令，针对一个或多个输入树的每个输入树，该输入树包括根节点，并且针对每个其他节点，该其他节点的父节点，由有向无环图(DAG)包含的一个或多个输入树，其中该输入树被反转，使得另一个节点作为DAG中的父节点与该输入树中该另一个节点的父节点相关，以嵌入该输入树的相应显示的子树，该子树包括该输入树的根节点并由该输入树的根节点的后代的连接集合组成，在以不同于第一方向的方向生长的基底树内，以第一方向生长的各个显示的子树，每个显示的子树的每个显示的节点由基底树的各个基底节点指示，通过:
a)接收一个或多个输入树；
b)对于一个或多个输入树中的每个输入树，通过基底树在显示器上呈现该输入树的相应显示的子树；和
c)在一个或多个输入树的给定输入树的相应显示子树中展开没有子节点的给定显示节点，并且至少一个父显示节点作为DAG中的父节点与给定显示节点相关，嵌入给定输入树的扩展显示子树，该扩展显示子树包含给定显示节点的相应显示子树并且包括基底树内的至少一个父显示节点，所述至少一个父显示节点作为扩展显示子树中的子节点与给定显示节点相关，通过:
i)在基底树中为给定的显示节点动态地分配至少一个父基底节点的相应列表，至少一个父基底节点的相应列表的每个父基底节点指示至少一个父显示节点的父显示节点，至少一个父基底节点的相应列表包括第一父基底节点和最后一个父基底节点；和
ii)从给定显示节点的至少一个父基底节点的相应列表的最后一个父基底节点，移动指示给定显示节点在基底树中下降的相应基底节点，
从而使用户能够探索给定输入树的相应显示的子树，该子树在第一方向上生长，嵌入在基底树内，在与第一方向不同的方向上生长。
2.根据权利要求1所述的设备，其中子显示节点作为子节点在DAG中与给定的显示节点相关，并且给定的显示节点在给定的输入树中比作为父节点在DAG中与子显示节点相关的任何其他父显示节点具有更高的高度，并且给定的显示节点还没有被子显示节点的至少一个父基板节点的相应列表的第一父基板节点指示，并且处理器实现的引擎还被指向:
移动相应的基底节点，该基底节点指示要排序的给定显示节点作为子显示节点的至少一个父基底节点的相应列表的第一父基底节点，
从而保持至少一个母衬底节点的每个列表的第一母衬底节点的扩展，至少扩展到至少一个母衬底节点的列表的任何其他母衬底节点。
3.根据权利要求2所述的设备，其中，所述给定的显示节点最初由所述子显示节点的至少一个父基底节点的相应列表的最后一个父基底节点指示，并且所述处理器实现的引擎还被指向:
从最初指示给定的显示节点在基底树中从父基底节点下降的相应基底节点移动在基底树中下降的多个后代节点，该父基底节点现在被排序为子显示节点的至少一个父基底节点的相应列表的最后一个父基底节点，
从而在指示给定输入树中的给定显示节点的父节点的相应基底节点的上下文探索内，维护指示给定输入树中的给定显示节点的父节点的相应子节点的每个基底节点。
4.根据权利要求2所述的设备，所述一个或多个输入树的每个输入树的多个根节点在所述DAG中共享共同的祖先，其中:
a)基底树包括至少一个基底节点的多个列表，至少一个基底节点的多个列表中的至少一个基底节点的每个列表包括最后一个基底节点，以及多个上下文框架森林，至少一个基底节点的多个列表中的至少一个基底节点的内部列表嵌套在基底树中的多个上下文框架森林的外部上下文框架森林的上下文框架树中，并且多个上下文框架森林的内部上下文框架森林包括嵌套在基底树中的至少一个基底节点的多个列表中的至少一个基底节点的外部列表中的至少一个上下文框架树，其中:
i)至少一个衬底节点的多个列表中的至少一个衬底节点的相应列表在衬底树中从衬底树的每个上下文帧森林的每个上下文帧树下降；和
ii)内部上下文框架森林在基底树中从至少一个基底节点的外部列表的最后一个基底节点下降；
b)至少一个基底节点的外部列表包括基底节点，该基底节点指示在DAG中作为父节点与由嵌套在内部上下文框架林中的每个上下文框架树内的至少一个基底节点的列表的第一基底节点指示的显示节点相关的每个父显示节点，至少一个基底节点的外部列表是嵌套在内部上下文框架林中的第一上下文框架树内的至少一个基底节点的列表中的第一基底节点的至少一个父基底节点的相应列表；和
c)多个上下文框架森林中的每个上下文框架森林表示来自该上下文框架森林的每个上下文框架树的至少一个基础节点列表的每个第一基础节点的DAG上下文探索，最外面的上下文框架森林表示处于挂起状态的DAG上下文探索，而内部上下文框架森林表示处于活动状态的DAG上下文探索，
从而显示来自一个或多个输入树的每个输入树的多个根节点的DAG中的共同祖先的DAG上下文探索的单个表示。
5.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
耦合到处理器实现的引擎的显示器，
其中处理器实现的引擎根据存储在存储器中的指令被引导:
a)接收包括多个本地实体和多个本地关联的本地化DAG，所述多个本地实体包括至少一个场所实体，所述多个本地关联的每个本地关联涉及多个本地实体的子实体和父实体，所述多个本地实体的每个本地实体在本地化DAG中从该本地实体的至少一个场所实体的相应至少一个源场所实体上升或下降；
b)在显示器上可视地呈现至少一个轨迹实体的每个轨迹实体，该轨迹实体由下式表示:
i)从轨迹实体沿第一方向生长相应上下文树的上下文根节点，在相应上下文树的每个节点处扎根的相应上下文子树，相应上下文树是上下文根节点的相应上下文子树；或者
ii)各个子结构树的子结构根节点，该子结构树从该轨迹实体沿与第一方向不同的方向生长，各个子结构子树扎根于各个子结构树的每个节点，各个子结构树是子结构根节点的各个子结构子树，
上下文根节点和子结构根节点重合，两者都指示该轨迹实体；和
c)折叠和展开:
i)在给定上下文实体的相应至少一个源轨迹实体的相应上下文源轨迹实体的相应上下文树内，给定上下文节点的相应上下文子树指示多个本地实体的给定上下文实体，其中在扩展给定上下文节点时，在呈现从给定上下文实体在本地化DAG中提升的多个所呈现的给定上下文实体祖先实体之前，所呈现的多个给定上下文实体祖先实体包括至少一个已经可见的适当上下文实体，由给定上下文源轨迹实体的相应上下文树的相应已经可见的适当上下文节点指示的至少一个已经可见的适当上下文实体的每个已经可见的适当上下文实体，相应已经可见的适当上下文节点作为相应已经可见的父上下文节点的子节点已经在显示器上可见，该设备选择性地折叠至少一个已经可见的适当上下文实体的每个已经可见的父上下文节点；或者
ii)在给定子结构实体的相应至少一个源轨迹实体的给定子结构源轨迹实体的相应子结构树内，给定子结构节点的相应子结构子树指示多个本地实体的给定子结构实体，其中在扩展给定子结构节点时，在呈现从给定子结构实体在本地化DAG中下降的多个所呈现的给定子结构实体后代实体之前，所呈现的多个给定子结构实体后代实体包括至少一个已经可见的适当子结构实体，由给定子结构源轨迹实体的相应子结构树的相应的已经可见的适当子结构节点指示的至少一个已经可见的适当子结构实体的每个已经可见的适当子结构实体，相应的已经可见的适当子结构节点作为相应的已经可见的父子结构节点的子节点已经在显示器上可见，该设备选择性地折叠至少一个已经可见的适当子结构实体的每个已经可见的父子结构节点，
从而使用户能够分别经由该轨迹实体的相应上下文树或该轨迹实体的相应子结构树，从该至少一个轨迹实体的每个轨迹实体探索在本地化DAG中上升或下降的多个本地实体，其中该多个本地实体的每个实体由至多一个可见节点指示。
6.根据权利要求5所述的设备，其中，所述处理器实现的引擎进一步针对:
a)其中所述至少一个轨迹实体包括不同于给定上下文源轨迹实体的第二给定上下文源轨迹实体，在给定上下文节点扩展时:
i)对于多个所呈现的给定上下文实体祖先实体中的第一个所呈现的给定上下文实体祖先实体，作为本地化DAG中的父实体与第一个所呈现的给定上下文实体祖先实体相关的每个父实体由第一个相应的已经可见的子适当上下文节点指示，该子适当上下文节点是第二个给定上下文源轨迹实体的相应上下文树的公共已经可见的父上下文节点的子节点，在显示器上排列第一个呈现的给定上下文实体祖先实体，以共享第一个相应的已经可见的子适当上下文节点，该子适当上下文节点以公共已经可见的父上下文节点作为上下文来指示每个父实体；和
ii)对于多个所呈现的给定上下文实体祖先实体中的第二所呈现的给定上下文实体祖先实体，在显示器上呈现多个所呈现的给定上下文实体祖先实体内的多个待显示父实体之前，将多个待显示父实体中的每个待显示父实体关联为第二所呈现的给定上下文实体祖先实体的父实体的本地化DAG的相应关联，由作为第二给定上下文源轨迹实体的相应上下文树的已可见父上下文节点的子节点的第二相应已可见子适当上下文节点指示的多个待显示父实体的至少一个已可见父实体的每个已可见父实体，以及由显示器上任何已可见节点指示的多个待显示父实体的至少一个尚未可见父实体的每个尚未可见父实体，选择性地折叠显示器上的已可见父上下文节点；或者
b)当至少一个轨迹实体包括不同于给定子结构源轨迹实体的第二给定子结构源轨迹实体时，在给定子结构节点扩展时，
i)对于多个所呈现的给定子结构实体后代实体中的第一个所呈现的给定子结构实体后代实体，作为本地化DAG中的子与第一个所呈现的给定子结构实体后代实体相关的每个子实体由第一个相应的已经可见的子适当子结构节点指示，该子适当子结构节点是第二个给定子结构源轨迹实体的相应子结构树的公共已经可见的父子结构节点的子，在显示器上排列第一个呈现的给定子结构实体后代实体，以共享第一个相应的已经可见的子适当的子结构节点，该子适当的子结构节点用公共的已经可见的父子结构节点指示每个子实体作为子结构；和
ii)对于多个所呈现的给定子结构实体后代实体中的第二所呈现的给定子结构实体后代实体，在显示器上呈现多个所呈现的给定子结构实体后代实体中的多个要显示的子实体之前，将多个要显示的子实体中的每个要显示的子实体关联为第二所呈现的给定子结构实体后代实体的子实体的本地化DAG的相应关联，由作为第二给定子结构源轨迹实体的相应子结构树的已可见父子结构节点的子的第二相应已可见子适当子结构节点指示的多个待显示子实体的至少一个已可见子实体的每个已可见子实体，以及由显示器上任何已可见节点未指示的多个待显示子实体的至少一个尚未可见子实体的每个，选择性地折叠显示器上的已可见父子结构节点，
从而向用户呈现来自给定上下文源轨迹实体的相应上下文树和第二给定上下文源轨迹实体的相应上下文树的公共上下文探索，或者来自给定子结构源轨迹实体的相应子结构树和第二给定子结构源轨迹实体的相应子结构树的公共子结构探索，多个本地实体中的每组本地实体在显示器上由最多一组可见的子节点表示。
7.根据权利要求5所述的设备，所述设备实现项目管理系统的各方面，所述多个本地实体包含多个本地项目，所述至少一个地点实体是至少一个地点项目，所述多个本地项目中的多个贡献本地项目的每个贡献本地项目与有序辅助项目信息相关联，所述有序辅助项目信息包括多个项目，所述多个项目被维护为按照由关键字排序的顺序被访问，其中所述处理器实现的引擎还被指向:
a)通过多个本地项目内用户当前可见的多个可见本地项目的合并过程动态地聚集有序辅助项目信息，生成包括多个项目内聚集的多个项目的动态变化的聚集；和
b)向用户呈现动态变化的集合，
从而使用户在探索作为定制项目集合的多个本地项目时，当在本地化DAG中从至少一个场所项目上升或下降时，能够可视化多个可见本地项目上的有序辅助项目信息的动态变化的集合，当从显示中移除指示现在隐藏的项目的节点时，与多个贡献本地项目的现在隐藏的项目相关联的有序辅助项目信息从动态改变的聚集中移除，聚集的多个项目中的特定项目是与多个贡献本地项目的共同祖先项目相关联的辅助项目信息，共同祖先项目在本地化的DAG中从所述至少一个地点项目的第一地点项目和所述多个本地项目的第二至少一个地点项目的第二地点项目上升，所述特定项目出现在所述多个项目的相邻项目旁边的第二动态变化聚集中，但不出现在所聚集的多个项目中。
8.根据权利要求5所述的设备，所述设备实现项目管理系统的方面，所述多个本地实体包含多个本地项目，所述至少一个场所实体是至少一个场所项目，所述设备实现社交网络的方面，所述设备包括网络硬件，所述网络硬件支持所述处理器实现的引擎充当与一个或多个计算设备通信的客户端，其中所述处理器实现的引擎还被指示从服务器请求和接收本地化的DAG，所述本地化的DAG由所述服务器从全局DAG中提取，多个关联包括:
a)社交细化关联，指示社交细化关联的子实体细化社交细化关联的父实体，社交细化关联的子实体和父实体是多个本地项目中的一个，社交细化关联的子实体由第一用户创建并与第一组织相关联，社交细化关联的父实体由第二用户创建并与第二组织相关联，社交细化关联是相互认可的定向连接；和
b)非社会关联，该非社会关联的子实体和父实体是多个本地项目中的一个并且由第二用户创建并且与第二组织相关联，该非社会关联不需要相互批准，
从而使得用户能够经由该轨迹项目的相应上下文树、包括社交细化关联和非社交关联的相应上下文子树、或者该轨迹项目的相应子结构树，从该至少一个轨迹项目的每个轨迹项目探索在本地化的DAG中上升或下降的多个本地实体，相应子结构子树分别包括社交细化关联和非社交关联。
9.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的服务器的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导:
a)从包括多个实体和多个关联的全局DAG中提取定位于多个项目的至少一个轨迹项目的相应局部有向无环图(DAG)，多个局部DAG的相应局部DAG，多个实体包含多个项目，多个关联的每个关联涉及多个实体的子实体和父实体；
b)在相应的本地化DAG上执行重新配置；和
c)将相应的本地化DAG传送到客户端，
相应的本地化DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中从多个项目的至少一个轨迹项目的相应至少一个源轨迹项目通过相应至少一条路径上升或下降，至少一个组成轨迹项目对应于至少一个轨迹项目；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，其中:
i)多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化了该细化关联的父实体，
所述重新配置使得对于所述至少一个轨迹项目的多个实体中相应的至少一个可继承实体的每个可继承实体，该可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且在全局DAG中借助于所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径提升，不是相应可继承子实体的相应至少一个可继承实体的深度可继承组件，对应于相应继承轨迹项目的至少一个组成轨迹项目的相应组成继承轨迹项目:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述多个本地实体包括对应于非基因座遗传实体的相应遗传实体；和
II)所述多个本地关联包括与相应的继承实体的相应继承关联，所述继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在来自父本地实体的至少一个轨迹项目的相应本地化DAG中上升；和
B)当该可遗传实体是基因座下降可遗传成分时，对应于该基因座下降可遗传成分的已经遗传的或组成成分在该至少一个基因座项目的相应局部DAG中从该可遗传实体的相应组成继承基因座项目下降:
I)所述多个本地关联包括各自的合并关联，所述合并关联具有作为子本地实体的已经继承或组成的组件，并且具有与作为父本地实体的沿着各自的可继承实体路径的轨迹下降的可继承组件的父相关的父可继承实体相对应的父可继承实体，
从而支持客户端使客户端的用户能够可视化为相应组成继承轨迹项目的后代，并且在与深度可继承组件的相应可继承实体路径上的可继承父实体相对应的父实体和不与深度可继承组件的相应可继承实体路径上的任何可继承父实体相对应的至少一个其他父实体的集成层次结构内，对相应于深度可继承组件的相应可继承实体发起操作。
10.根据权利要求9所述的设备，所述设备实现社交网络的各方面，所述相应的至少一个可继承实体的自动共享的可继承实体的相应继承路径包括:
a)社交细化关联，社交细化关联的子实体由客户端的第一用户创建并与第一组织相关联，社交细化关联的父实体由客户端的第二用户创建并与第二组织相关联，社交细化关联是相互认可的定向连接；和
b)非社交细化关联，非社交细化关联的子实体和父实体由第二用户创建并与第二组织相关联，非社交细化关联不需要相互批准，
从而通过社交细化关联和通过非社交细化关联继承自动共享可继承实体作为对应于自动共享可继承实体的相应继承实体。
11.根据权利要求9所述的设备，其中:
a)多个项目包含多个问题和多个解决方案，多个问题和多个解决方案中都没有项目；
b)多个细化关联包括:
i)问题细化关联，其将多个问题中的子问题和多个问题中的父问题联系起来，指示子问题专门处理父问题；或者
ii)解决方案细化关联，其将多个解决方案的子解决方案与多个解决方案的父解决方案相关联，指示子解决方案详述了父解决方案；和
c)相应的至少一个可继承实体包括多个项目中的可继承项目，其中:
i)可继承项目是多个解的可继承解，对应于可继承解的相应继承实体是多个本地实体的继承解，用于可继承解的相应继承轨迹项目是多个问题的相应继承轨迹问题，用于可继承解的相应适当精化祖先项目是多个问题的相应适当精化祖先问题；或者
ii)可继承项目是多个问题的可继承问题，对应于可继承问题的相应继承实体是多个本地实体的继承问题，用于可继承问题的相应继承轨迹项目是多个解的相应继承轨迹解，用于可继承问题的相应适当精化祖先项目是多个解的相应适当精化祖先解，
从而支持客户端使用户能够将来自相应组成继承轨迹项目的至少一个轨迹项目的相应本地化DAG中的后代可视化，并启动对对应于可继承解决方案的继承解决方案的操作，该可继承解决方案解决相应的适当细化祖先问题、比相应继承轨迹问题更一般的问题或对应于可继承问题的继承问题，该可继承问题分解相应的适当细化祖先解决方案、比相应继承轨迹解决方案更不复杂的解决方案。
12.根据权利要求11所述的设备，所述至少一个轨迹项目是所述多个问题中的至少一个轨迹问题，所述多个实体包含多个条件分量，相应的至少一个可继承实体是所述多个条件分量中相应的至少一个可继承条件分量，其中:
a)所述多个问题中的至少一个基于数据的上下文问题是相应的至少一个可继承条件组件的每个可继承条件组件的相应适当细化祖先项目，所述至少一个基于数据的上下文问题与多个数据库中的相应数据库隐式或显式相关联，每个基于数据的上下文问题的相应数据库包括被排列为多个属性的数据，至少一个基于数据的继承轨迹问题是相应的至少一个可继承条件组件的每个可继承条件组件的相应继承轨迹项目；
b)多个条件分量包含多个项，这些项表示多个数据库中至少一个数据库的至少一个属性上的等式或不等式，并且包括至少一个布尔运算符；
c)由所述多个条件组件中的每个条件组件的术语引用的每个属性是针对与基于数据的上下文问题相关联的数据库的，所述基于数据的上下文问题是从该条件组件在全局DAG中提升的；和
d)处理器实现的引擎进一步指向:
i)制定与至少一个轨迹问题相关的查询，该查询包括包含相应的至少一个可继承条件成分的条件，该查询支持结果的聚集；
ii)在查询的每个条件成分的相应数据库上解析查询，以获得查询结果；和
iii)将查询结果传送给客户端，
从而将对应于相应的至少一个可继承条件成分的相应的至少一个继承实体的结构与至少一个已继承的或组成的条件成分的结构整合，所述至少一个已继承的或组成的条件成分在相应的局部DAG中针对来自相应的至少一个可继承条件成分的至少一个组成继承轨迹项目的至少一个轨迹问题而下降，所述至少一个继承的条件成分和所述至少一个已经继承的或组成的条件成分是所述多个条件成分中的一个，支持客户端通过呈现查询结果来激励和跟踪解决所述至少一个地点问题的进展，所述查询结果用作量化所述至少一个地点问题的度量，所述查询由所述至少一个地点问题的相应的至少一个可继承的条件成分公式化，所述至少一个地点问题被收集为与所述至少一个基于数据的继承地点问题相关。
13.根据权利要求12所述的设备，其中:
所述至少一个基于数据的继承轨迹问题的精炼基于数据的问题精炼所述至少一个基于数据的上下文问题的至少一个精炼基于数据的问题的每个精炼基于数据的问题，所述至少一个精炼基于数据的问题的每个精炼基于数据的问题在全局DAG中具有各自的至少一个条件成分后代，并且精炼基于数据的问题的条件被公式化为合取条件，作为为至少一个精炼的基于数据的问题的每个精炼的基于数据的问题制定的相应条件的结合，所述至少一个精炼的基于数据的问题来自该精炼的基于数据的问题的相应的至少一个条件成分后代，
从而支持客户端使得用户能够在导航到精炼基于数据的问题时隐式地将结合条件与精炼基于数据的问题相关联。
14.根据权利要求12所述的设备，其中:
所述至少一个基于数据的继承轨迹问题的精炼的基于数据的问题通过所述多个问题中的至少一个精炼的基于数据的问题的每个精炼的基于数据的问题来精炼，所述至少一个精炼的基于数据的问题的每个精炼的基于数据的问题在全局DAG中具有各自的至少一个条件成分后代，并且精炼的基于数据的问题的条件被公式化为析取条件，作为为至少一个精炼基于数据的问题的每个精炼基于数据的问题制定的相应条件与该精炼基于数据的问题的相应至少一个条件成分后代的分离，
从而支持客户端使用户能够在导航到精细的基于数据的问题时隐式地将分离条件与精细的基于数据的问题相关联。
15.根据权利要求12所述的设备，所述查询结果包括多个数据项，其中:
服务器用该细化关联的子项目所需的至少一个约束来标记对应于多个细化关联的每个细化关联的组成关联的至少一个标记的本地细化关联，超出该细化关联的父项目所需的任何约束，
从而支持客户端在由用户确定的定制项目集合中增量地呈现动态变化的数据项集合。
16.根据权利要求11所述的设备，所述多个实体包含多个状态机组件，相应的至少一个可继承实体是所述多个状态机组件中相应的至少一个可继承状态机组件，其中:
a)多个项目中的至少一个基于状态的上下文项目是相应的至少一个可继承状态机组件的每个可继承状态机组件的相应适当细化祖先项目，至少一个基于状态的继承轨迹项目是相应的至少一个可继承状态机组件的每个可继承状态机组件的相应继承轨迹项目；
b)多个状态机组件包含多个状态机状态；和
c)处理器实现的引擎进一步指向:
i)制定与至少一个轨迹项目相关的状态机，该状态机包括相应的至少一个可继承状态机组件；和
ii)将状态机的形式传送给客户端，
从而将分层状态机关联起来，分层在至少一个轨迹项目的相应本地化DAG上，作为问题和解决方案的分层结构，从至少一个轨迹项目的相应至少一个可继承状态机组件中公式化，收集为与至少一个基于状态的继承轨迹项目相关，以及将对应于相应的至少一个可继承状态机组件的相应的至少一个继承实体的结构与在相应的本地化DAG中从相应的至少一个可继承状态机组件的至少一个组成继承轨迹项目下降的至少一个已经继承或组成状态机组件的结构集成，该至少一个继承状态机组件和至少一个已经继承或组成状态机组件是多个状态机组件中的一个。
17.根据权利要求16所述的设备，其中，所述处理器实现的引擎进一步针对:
a)收集多个记录，每个记录包括相应至少一个可继承状态机组件的可继承状态机组件的相应适当精化祖先项目的至少一个属性值，以及多个有序状态对，多个有序状态对的可继承状态的有序对的每个可继承状态是相应至少一个可继承状态机组件的状态，对于由该记录的至少一个属性值描述的项目，多个有序状态对中的每个有序状态对指示从该有序对的第一状态到该有序对的第二状态的相应转变；和
b)从多个记录的每个记录的多个有序状态对中公式化状态机作为训练数据，
从而使得能够从多个记录中导出不同的状态机作为与至少一个轨迹项目相关的训练数据的定制组合，该训练数据包括有序的可继承状态对的相应转变。
18.根据权利要求9所述的设备，其中:
基于用户对原始继承实体的修改从客户端发出指示，原始继承实体是对应于至少一个轨迹项目的相应至少一个可继承实体的给定可继承实体的相应继承实体，产生修改的继承实体，对应于给定可继承实体的原始继承实体在至少一个轨迹项目的相应本地化DAG中通过相应的继承关联从给定可继承实体的相应组成继承轨迹项目下降，服务器通过在全局DAG中创建，将给定可继承实体与给定可继承实体的相应继承轨迹项目相关联，产生结果全局DAG:
a)重新启动实体，其中重新启动实体被创建为多个实体中的实体，并且修改的继承实体对应于重新启动实体；
b)与作为子实体的再现实体和作为父实体的给定可继承实体的相应继承轨迹项目的第一关联，其中第一关联被创建为多个关联中的关联；和
c)与作为子实体的重启实体和作为父实体的给定可继承实体的第二关联，其中第二关联被创建为多个细化关联中的细化关联，
从而创建重述实体，以相对于给定可继承实体的相应继承轨迹项目重述给定可继承实体，支持客户端实现原始继承实体对修改后的继承实体的就地修改。
19.根据权利要求18所述的设备，其中，所述服务器从第二客户端接收所述多个项目中的第二至少一个轨迹项目的标识，并且向所述第二客户端传送所述第二至少一个轨迹项目的相应本地化DAG，所述至少一个轨迹项目是第一至少一个轨迹项目，所述第二至少一个轨迹项目包括在全局DAG中从给定可继承实体的相应适当细化祖先项目下降的另一细化后代项目，所述另一细化后代项目没有在全局DAG中从给定可继承实体的相应继承轨迹项目上升或下降，其中:
该再现实体不在第二至少一个场所项目的相应的至少一个可继承实体中，
从而支持客户端避免分散用户导航到第二至少一个轨迹项目的注意力，该第二至少一个轨迹项目具有重新启动实体，相对于给定可继承实体的相应继承轨迹项目重新启动，与其他细化后代项目无关。
20.根据权利要求18所述的设备，其中，所述服务器从第二客户端接收所述多个项目中的第二至少一个轨迹项目的标识，并且向所述第二客户端传送所述第二至少一个轨迹项目的相应本地化DAG，所述至少一个轨迹项目是第一至少一个轨迹项目，所述第二至少一个轨迹项目的细化后代轨迹项目在全局DAG中通过来自所述细化后代轨迹项目的连续继承路径，通过所述多个细化关联的一个或多个细化关联的连续序列，从所述给定可继承实体的第一至少一个轨迹项目、第一继承轨迹项目的相应继承轨迹项目下降，其中:
给定的可继承实体不在第二至少一个场所项目的相应的至少一个可继承实体中，
从而支持客户端避免分散用户导航到具有给定可继承实体的第二至少一个轨迹项目的注意力，该第二至少一个轨迹项目通过到相应可继承子实体的相应可继承实体路径与给定可继承实体的相应适当细化祖先项目相关，该重新启动实体在第二至少一个轨迹项目的相应至少一个可继承实体中，并细化给定可继承实体，该重启实体通过第一关联与第一继承轨迹项目相关联，在全局DAG中通过相应的继承路径从相应的适当细化祖先项目下降。
21.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中所述处理器实现的引擎根据存储在所述存储器中的指令被引导以从服务器请求和接收本地化的有向无环图(DAG)，所述本地化的DAG由所述服务器从全局DAG中提取，所述全局DAG包括多个实体和多个关联，所述多个实体包含多个项目，所述多个关联的每个关联涉及所述多个实体的子实体和父实体，其中所述本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从多个项目的至少一个轨迹项目的相应至少一个源轨迹项目上升或下降，对应于至少一个轨迹项目的至少一个组成轨迹项目，对应于相应的至少一个源轨迹项目的至少一个组成轨迹项目的相应的至少一个源组成轨迹项目；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
所述本地化的DAG已经被所述服务器重新配置，向导航到所述至少一个场所项目的用户呈现通过相关实体进行探索的方式，其中:
a)多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化了该细化关联的父实体；和
b)用户能够在本地化的DAG中从至少一个组成轨迹项目的相应组成继承轨迹项目中看到对应于多个实体中的至少一个可继承实体的每个可继承实体的多个本地实体的相应继承实体的后代，至少一个可继承实体的每个可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且在全局DAG中借助于所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径提升，所述相应的继承轨迹项目对应于相应的组成继承轨迹项目，所述至少一个可继承实体的深度可继承组件不是相应的可继承子实体，所述本地化DAG已经被重新配置，使得对于所述至少一个可继承实体的每个可继承实体:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述多个本地实体包括对应于非基因座遗传实体的相应遗传实体；和
II)多个本地关联包括与相应的继承实体的相应继承关联，该继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在本地化DAG中从父本地实体上升；和
B)当该可继承实体是基因座后代可继承成分时，对应于该基因座后代可继承成分的已经遗传的或组成成分在本地化DAG中是该可继承实体的相应组成继承基因座项目的后代:
I)所述多个本地关联包括各自的合并关联，所述合并关联具有作为子本地实体的已经继承的或组成的组件，并且具有对应于作为父本地实体的沿着各自的可继承实体路径作为父可继承组件的父可继承实体的父可继承实体，
从而使用户能够看到是相应组成继承轨迹项目的后代，并在相应的继承实体上启动操作，该继承实体对应于集成层次结构内的深度可继承组件，其父实体包括至少一个继承的父实体，该父实体对应于深度可继承组件的相应可继承实体路径上的可继承父实体，以及至少一个不对应于深度可继承组件的相应可继承实体路径上的任何可继承父实体的其他父实体。
22.根据权利要求21所述的设备，所述多个项目中的多个贡献项目的每个贡献项目与有序辅助项目信息相关联，所述有序辅助项目信息包括被维护为按照由关键字排序的顺序被访问的多个项目，对应于每个贡献项目的本地实体与也与该贡献项目相关联的有序辅助项目信息相关联，其中:
处理器实现的引擎还被指示通过合并过程生成并向用户呈现有序辅助项目信息的集合，该集合包括集合的多个项目:
a)跨越多个局部实体内的多个子结构项目，多个子结构项目的每个子结构项目在局部DAG中从该子结构项目的相应的至少一个源组成轨迹项目下降，并且对应于多个项目的全局子结构项目；或者
b)跨越多个子结构项目和多个本地实体内的多个上下文项目，多个上下文项目的每个上下文项目在本地化DAG中从该上下文项目的相应的至少一个源组成轨迹项目上升，并且对应于多个项目的全局上下文项目，
所述多个子结构项目包括对应于所述至少一个可继承实体和所述多个贡献项目的可继承贡献项目的相应继承实体，
从而使用户能够可视化多个子结构项目上的有序辅助项目信息的聚集或者多个子结构项目和多个上下文项目上的有序辅助项目信息的聚集，多个子结构项目包括对应于集成层次结构内的可继承贡献项目的相应继承实体，所聚集的多个项目中的第一项目是与在全局DAG中从可继承贡献项目提升的第一可继承贡献祖先项目相关联的有序辅助项目信息，可通过第一可继承贡献祖先项目的相应适当细化祖先项目继承，并且所聚集的多个项目中的第二项目是与第二可继承贡献祖先项目相关联的有序辅助项目信息，该第二可继承贡献祖先项目在全局DAG中从可继承贡献项目提升，可通过第二可继承贡献祖先项目的相应适当细化祖先项目继承。
23.根据权利要求21所述的设备，所述多个项目中的多个贡献项目的每个贡献项目与有序辅助项目信息相关联，所述有序辅助项目信息包括被维护为按照由关键字排序的顺序被访问的多个项目，对应于每个贡献项目的本地实体与也与该贡献项目相关联的有序辅助项目信息相关联，其中所述处理器实现的引擎还被指向:
a)通过在多个本地实体内由用户选择的连续的多个本地项目上的合并过程动态地聚集有序的辅助项目信息，所述多个本地项目包括连续的多个本地项目中每个项目的相应的至少一个源组成点项目和相应的继承实体，所述继承实体对应于所述至少一个可继承实体和所述多个贡献项目的可继承贡献项目，生成包括所述多个项目内聚集的多个项目的动态变化聚集；和
b)向用户呈现动态变化的集合，
从而使用户在探索多个本地项目的同时，当在本地化DAG中从至少一个组成地点项目上升或下降时，能够可视化连续的多个本地项目上的有序辅助项目信息的动态变化的聚集，所述多个本地项目是包括对应于集成层级内的可继承贡献项目的相应继承实体的项目的定制集合，当从连续的多个本地项目中移除对应于现在被排除的项目的本地项目时，与多个贡献项目中现在被排除的项目相关联的有序辅助项目信息被从动态变化的聚合中移除，聚合的多个项目中的第一个项目是与在全局DAG中从可继承贡献项目提升的第一可继承贡献祖先项目相关联的有序辅助项目信息，可通过第一可继承贡献祖先项目的相应适当细化祖先项目继承，并且所聚集的多个项目中的第二项目是与第二可继承贡献祖先项目相关联的有序辅助项目信息，该第二可继承贡献祖先项目在全局DAG中从可继承贡献项目提升，可通过第二可继承贡献祖先项目的相应适当细化祖先项目继承。
24.根据权利要求21所述的设备，所述设备实现社交网络的各方面，所述相应的至少一个可继承实体的自动共享的可继承实体的相应继承路径包括:
a)社交细化关联，社交细化关联的子实体由第一用户创建并与第一组织相关联，社交细化关联的父实体由第二用户创建并与第二组织相关联，社交细化关联是相互认可的定向连接；和
b)非社交细化关联，非社交细化关联的子实体和父实体由第二用户创建并与第二组织相关联，非社交细化关联不需要相互批准，
从而使用户能够将相应的组成继承轨迹项目的后代可视化，并启动对相应于自动共享的可继承实体的相应继承实体的操作，该可继承实体是通过社交细化关联和非社交细化关联继承的。
25.根据权利要求21所述的设备，其中:
当用户对原始继承实体进行就地修改时，原始继承实体是对应于至少一个可继承实体的给定可继承实体的相应继承实体，产生修改后的继承实体，对应于给定可继承实体的原始继承实体在本地化DAG中通过相应继承关联从给定可继承实体的相应组成继承轨迹项目下降，客户端通过请求服务器在全局DAG中创建，将原始继承实体与给定可继承实体的相应组成继承轨迹项目相关联，产生结果全局DAG:
a)重启实体，其中所述重启实体被创建为所述多个实体中的实体，并且所述修改的继承实体对应于所述重启实体；
b)与作为子实体的再现实体和作为父实体的给定可继承实体的相应继承轨迹项目的第一关联，其中第一关联被创建为多个关联中的关联；和
c)与作为子实体的重启实体和作为父实体的给定可继承实体的第二关联，其中第二关联被创建为多个细化关联中的细化关联，
从而使用户能够将对应于给定可继承实体的原始继承实体与给定可继承实体的相应组成继承轨迹项目相关联，服务器在重新启动实体中保持原位修改，并且保持给定可继承实体不变。
26.根据权利要求25所述的设备，其中:
a)多个项目包含多个问题和多个解决方案，多个问题和多个解决方案中都没有项目；
b)多个细化关联包括:
i)问题细化关联，其将多个问题中的子问题和多个问题中的父问题联系起来，指示子问题专门处理父问题；或者
ii)解决方案细化关联，其将多个解决方案的子解决方案与多个解决方案的父解决方案相关联，指示子解决方案详述了父解决方案；和
c)给定的可继承实体是多个项目中的给定的可继承项目，并且重新启动实体是多个项目中的重新启动项目，其中:
i)给定的可继承项目是多个解决方案的给定的可继承解决方案，对应于给定的可继承解决方案的相应继承实体是多个本地实体的给定的继承解决方案，给定的可继承解决方案的相应继承轨迹项目是多个问题的相应继承轨迹问题，并且给定的可继承解决方案的相应适当细化祖先项目是多个问题的相应适当细化祖先问题，并且重新排序项目是作为多个解决方案中的解决方案创建的重新排序解决方案；或者
ii)给定的可继承项目是多个问题的给定的可继承问题，对应于给定的可继承问题的各个继承实体是多个本地实体的给定的继承问题，给定的可继承问题的各个继承轨迹项目是多个解决方案的各个继承轨迹解决方案，给定的可继承问题的各个适当的精化祖先项目是多个解决方案的各个适当的精化祖先解决方案，并且重启项目是作为多个问题中的问题创建的重启问题，
从而使用户能够在本地化的DAG中看到来自相应组成继承轨迹项目的后代，并启动对对应于给定可继承解决方案的给定继承解决方案的就地修改，给定可继承解决方案解决相应的适当精化祖先问题，比相应继承轨迹问题更一般的问题，以及重新启动解决方案解决相应继承轨迹问题，服务器保持在重新开始解决方案中的原地修改并且保持给定的可继承解决方案不变，或者给定的可继承问题对应于给定的可继承问题，给定的可继承问题分解相应的适当的细化祖先解决方案，比相应的继承轨迹解决方案更不精细的解决方案，以及重新开始问题分解相应的继承轨迹解决方案，服务器保持在重新开始问题中的原地修改并且保持给定的可继承问题不变。
27.根据权利要求26所述的设备，所述至少一个轨迹项目是所述多个问题中的至少一个轨迹问题，所述至少一个轨迹问题是所述多个问题中的至少一个基于数据的上下文问题在全局DAG中的下降，所述至少一个基于数据的上下文问题的每个基于数据的上下文问题与多个数据库中的相应数据库隐式或显式相关联，每个基于数据的上下文问题的相应数据库包括被排列为多个属性的数据，其中:
a)多个实体包含多个条件成分，这些条件成分包含多个术语，这些术语表示多个数据库中的至少一个数据库的至少一个属性上的等式或不等式，并且包括至少一个布尔运算符；
b)给定的可继承实体是多个条件组件中的给定的可继承条件组件，对应于给定的可继承条件组件的相应继承实体是多个本地实体的原始继承条件组件；
c)用户的就地修改包括在与至少一个轨迹问题相关联的条件的表示内对应于给定可继承条件分量的原始继承条件分量的表示上执行的条件专门化操作；和
d)重启实体是多个条件组件中的重启条件组件，
从而使用户能够通过将条件特殊化操作就地应用于对应于给定可继承条件组件的原始继承条件组件来特殊化条件，服务器保持在重新启动条件组件中的就地修改，并且保持给定可继承条件组件不变。
28.根据权利要求27所述的设备，其中:
a)多个条件成分包括析取删除操作符；
b)给定的可继承条件组件是给定的可继承的待删除析取项；
c)条件是分离，并且用户的就地修改包括删除操作；和
d)重启实体是析取删除操作符，
从而使得用户能够通过从析取条件中就地移除给定的可继承的待删除析取来专门化与至少一个轨迹问题相关联的析取条件。
29.根据权利要求26所述的设备，其中:
a)多个实体包含多个状态机组件；
b)给定的可继承实体是多个状态机组件中的给定的可继承状态机组件，对应于给定的可继承状态机组件的各个继承实体是多个本地实体的原始继承状态机组件；
c)用户的就地修改包括在与至少一个轨迹项目相关联的状态机的表示内对应于给定可继承状态机组件的原始继承状态机组件的表示上执行的状态机精化操作；和
d)重启实体是多个状态机组件中的重启状态机组件，
从而使用户能够通过将状态机精化操作就地应用于原始继承的状态机组件来精化状态机，服务器维护重启实体中的就地修改以参与较低级别的状态机，并且保持给定的可继承实体不变以参与较高级别的状态机。
30.根据权利要求29所述的设备，其中:
a)多个状态机组件包含多个状态机状态和多个状态机；
b)给定的可继承状态机组件是多个状态机状态中给定的可继承状态机状态；
c)用户的就地修改包括状态分解操作；和
d)重启实体是低级状态机，
从而使用户能够通过将分层状态机从给定的可继承状态机状态就地扩展到更低的级别来精心设计与至少一个轨迹项目相关联的分层状态机。
31.根据权利要求21所述的设备，其中:
对于多个本地实体中的至少一个所选继承实体的每个所选继承实体，该所选继承实体对应于相应的所选可继承实体，该所选继承实体在本地化DAG中通过继承实体路径从相应的所选可继承实体的相应组成继承轨迹项目下降，该继承实体路径是包括多个本地实体中的至少一个原始继承路径实体的序列，对于至少一个原始继承路径实体中尚未被访问的每个原始继承路径实体，该原始继承路径实体是对应于至少一个可继承实体的相应给定可继承路径实体的相应继承实体，提示用户进行就地修改，以将该原始继承路径实体重述给相应选择的可继承实体的相应组成继承轨迹项目，产生修改的继承路径实体，并请求服务器在全局DAG中创建，产生结果全局DAG:
a)重述原始继承路径实体的相应给定可继承路径实体的重述实体，其中重述相应给定可继承路径实体的重述实体被创建为多个实体中的实体，并且修改的继承路径实体对应于重述相应给定可继承路径实体的重述实体；
b)与重述实体的第一关联，所述第一关联将相应的给定可继承路径实体重述为子实体，并且如果相应的给定可继承路径实体的相应继承轨迹项目作为父项与沿着继承实体路径的修改的继承路径实体相关，则与相应的给定可继承路径实体的相应继承轨迹项目作为父项，或者用重述父实体的重述实体，该父实体作为父实体沿着继承实体路径与修改的继承路径实体相关，其中第一关联被创建为多个关联中的关联；和
c)与重述实体的第二关联，其重述相应的给定可继承路径实体作为子实体，并且与相应的给定可继承路径实体作为父实体，其中第二关联被创建为多个细化关联中的细化关联，
从而使用户能够通过沿每个继承实体路径就地修改每个继承路径实体，将每个选择的继承实体与相应选择的可继承实体的相应组成继承轨迹项目相关联，服务器在每个重新启动的实体中保持就地修改，并且保持每个原始继承路径实体的相应给定可继承路径实体不变。
32.根据权利要求21所述的设备，其中:
对于多个本地实体中的至少一个所选继承实体的每个所选继承实体，该所选继承实体对应于相应的所选可继承实体，该所选继承实体在本地化DAG中通过继承实体路径从相应的所选可继承实体的相应组成继承轨迹项目下降，该继承实体路径是包括多个本地实体中的至少一个原始继承路径实体的序列，客户端通过对于至少一个原始继承路径实体和一个或多个要重述的继承实体中尚未被访问的每个原始继承路径实体，将所选择的继承实体与相应选择的可继承实体的相应组成继承轨迹项目相关联，要重述的一个或多个继承实体包括来自沿着继承实体路径的任何连续实体序列中的至少一个继承实体，该连续序列内的任何相邻实体对通过细化相关，至少一个不被重述的继承路径实体是至少一个原始继承路径实体的一部分，并且不是要重述的一个或多个继承实体的一部分，该原始继承路径实体是对应于至少一个可继承实体的相应给定可继承路径实体的相应继承实体，提示用户进行就地修改，以将该原始继承路径实体重述给相应选择的可继承实体的相应组成继承轨迹项目，产生修改的继承路径实体，并请求服务器在全局DAG中创建，产生结果全局DAG:
a)重述原始继承路径实体的相应给定可继承路径实体的重述实体，其中重述相应给定可继承路径实体的重述实体被创建为多个实体中的实体，并且修改的继承路径实体对应于重述相应给定可继承路径实体的重述实体；
b)与重新声明实体的第一关联，其将相应的给定可继承路径实体重新声明为子实体，并且如果沿着继承的实体路径在该原始继承的路径实体之后没有后续的原始继承的路径实体在要被重新声明的一个或多个继承的实体中，则与相应的所选可继承实体的相应继承轨迹项目作为父实体，或者以沿着继承的实体路径重述最近的后续可继承路径实体的重述实体作为父实体，在对应于最近的后续可继承路径实体的要重述的一个或多个继承的实体中，沿着继承的实体路径朝着相应选择的可继承实体的相应组成继承轨迹项目的最近的后续原始继承路径实体，其中第一关联被创建为多个关联中的关联；和
c)与重述实体的第二关联，其重述相应的给定可继承路径实体作为子实体，并且与相应的给定可继承路径实体作为父实体，其中第二关联被创建为多个细化关联中的细化关联，
从而使用户能够通过在沿着每个继承实体路径的细化关联的每个序列中就地修改至少一个代表性继承路径实体，将每个选择的继承实体与相应选择的可继承实体的相应组成继承轨迹项目相关联，服务器在每个重新声明的实体中保持就地修改，并且保持至少一个代表性继承路径实体中的每个的相应给定可继承路径实体不变，避免创建实体和关联来重新声明至少一个不被重新声明的继承路径实体。
33.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的服务器的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导:
a)从包括多个实体和多个关联的全局DAG中提取定位于多个实体的至少一个轨迹实体的相应局部有向无环图(DAG)，多个局部DAG的相应局部DAG，多个关联的每个关联涉及多个实体的子实体和父实体，以及；
b)将相应的本地化DAG传送到客户端，
相应的本地化DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从至少一个位置实体的相应至少一个源位置实体上升或下降，至少一个组成位置实体对应于至少一个位置实体；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
其中:
i)多个实体包含多个项目，多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化该细化关联的父实体；和
ii)对于所述多个本地实体的所选上下文项目，并且对应于所述多个项目的所选项目，所述服务器通过对于上下文集合序列中的每个上下文集合，概括所选上下文项目的相应的至少一个路径，所述上下文集合序列包括第一上下文集合和最终上下文集合，所述上下文集合包括所述多个本地实体的一个或多个上下文实体序列，相同序列内的上下文实体通过各自的本地化DAG中的细化而相关，相同上下文集合内的不同序列内的任何两个上下文实体在各自的本地化DAG中不彼此上升或下降，第一上下文集合的每个上下文实体序列的第一上下文实体对应于至少一个位置实体的各自的位置实体，上下文集合的上下文实体序列的最后一个上下文实体作为全局DAG中的子代与后续上下文集合的上下文实体序列的第一个上下文实体相关，在全局DAG中创建，产生结果全局DAG:
a.概括该上下文集合的概括实体，其中该概括实体被创建为多个实体中的实体；
b.与概括实体的第一关联，该概括实体将该上下文集合概括为子实体，并且与概括实体关联，该概括实体概括上下文集合序列中该上下文集合之后的父上下文集合，或者在该上下文集合是上下文集合序列中的最终上下文集合的情况下，将所选择的上下文项目作为父实体，其中第一关联被创建为多个关联中的关联；和
c.对于该上下文集合中的每个上下文实体序列，与作为子实体的该序列的上下文实体以及作为父实体的概括实体的相应第二关联，其中相应的第二关联被创建为多个细化关联中的细化关联，
从而概括上下文集合序列中的每个上下文集合，支持客户端使客户端的用户能够概括所选上下文项目的相应的至少一个路径。
34.根据权利要求33所述的设备，其中，所述服务器向第二客户端传送所述多个项目中的至少一个地点项目的相应本地化DAG，所述上下文集合序列是单个上下文集合，所选择的项目的相应至少一个源地点实体是一个源地点实体，来自所选项目的一个源轨迹实体的相应至少一个路径的路径，该路径包括细化后代项目，该细化后代项目在全局DAG中借助于多个细化关联中的一个或多个细化关联的序列从所选项目通过细化路径下降，所述至少一个轨迹项目包括细化后代轨迹项目，所述细化后代轨迹项目在全局DAG中通过第二细化路径从所选项目下降，所述细化后代轨迹项目不在全局DAG中从所述细化后代项目上升或下降，其中:
所述处理器实现的引擎还被指示对所述至少一个轨迹项目的相应本地化DAG执行重新配置，对于所述至少一个轨迹项目的所述多个实体中相应的至少一个可继承实体的每个可继承实体，所述可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且通过所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径在全局DAG中提升，所述至少一个组成轨迹项目的各自组成继承轨迹项目对应于各自继承轨迹项目:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述至少一个基因座项目的相应本地化DAG的多个本地实体包括对应于非基因座后代可遗传实体的相应遗传实体；和
II)所述至少一个轨迹项目的相应本地化DAG的多个本地关联包括与相应的继承实体的相应继承关联，所述继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在所述至少一个轨迹项目的相应本地化DAG中从父本地实体上升；和
B)当该可遗传实体是基因座下降可遗传成分时，对应于该基因座下降可遗传成分的已经遗传的或组成成分在该至少一个基因座项目的相应局部DAG中从该可遗传实体的相应组成继承基因座项目下降:
I)所述至少一个轨迹项目的相应本地化DAG的多个本地关联包括与作为子本地实体的已经继承或组成的组件以及与对应于作为父可继承实体的父可继承实体的父可继承实体的相应合并关联，所述父可继承实体作为父可继承实体沿着作为父本地实体的相应可继承实体路径，
其中所述一个源地点实体不在所述至少一个地点项目的相应至少一个可继承实体中，
从而支持客户端避免分散用户导航到具有一个源轨迹实体的至少一个轨迹项目的注意力，相对于精化后代项目重新开始，而不是在全局DAG中从精化后代轨迹项目上升或下降。
35.根据权利要求33所述的设备，其中，所述服务器向第二客户端传送所述多个项目中的至少一个地点项目的相应本地化DAG，所述上下文集合序列是单个上下文集合，所选择的项目的相应至少一个源地点实体是一个源地点实体，所选择的项目和所述一个源轨迹实体的相应的至少一个路径的路径，所述一个源轨迹实体包括细化后代项目，所述细化后代项目通过多个细化关联的一个或多个细化关联的序列在全局DAG中从所选择的项目下降，所述至少一个轨迹项目包括在全局DAG中从细化后代项目下降的细化后代轨迹项目，作为所述一个源轨迹实体的父实体，通过所述多个细化关联中的一个或多个细化关联的连续序列，通过连续细化路径与所述一个源轨迹实体相关，其中:
所述处理器实现的引擎还被指示对所述至少一个轨迹项目的相应本地化DAG执行重新配置，对于所述至少一个轨迹项目的所述多个实体中相应的至少一个可继承实体的每个可继承实体，所述可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且通过所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径在全局DAG中提升，所述至少一个组成轨迹项目的各自组成继承轨迹项目对应于各自继承轨迹项目:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述至少一个基因座项目的相应本地化DAG的多个本地实体包括对应于非基因座后代可遗传实体的相应遗传实体；和
II)所述至少一个轨迹项目的相应本地化DAG的多个本地关联包括与相应的继承实体的相应继承关联，所述继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在所述至少一个轨迹项目的相应本地化DAG中从父本地实体上升；和
B)当该可遗传实体是基因座下降可遗传成分时，对应于该基因座下降可遗传成分的已经遗传的或组成成分在该至少一个基因座项目的相应局部DAG中从该可遗传实体的相应组成继承基因座项目下降:
I)所述至少一个轨迹项目的相应本地化DAG的多个本地关联包括与作为子本地实体的已经继承或组成的组件以及与对应于作为父可继承实体的父可继承实体的父可继承实体的相应合并关联，所述父可继承实体作为父可继承实体沿着作为父本地实体的相应可继承实体路径，
其中所述概括实体不在所述至少一个位点项目的相应的至少一个可继承实体中，
从而支持客户端避免分散用户导航到具有概括实体的至少一个轨迹项目的注意力，所述概括实体与通过第一关联选择的项目相关，所述一个源轨迹实体在用于所述至少一个轨迹项目的相应的至少一个可继承实体之中，并且细化所述概括实体，所述一个源轨迹实体作为子代通过所述关联与所述细化后代项目相关，所述细化后代项目在全局DAG中通过所述细化路径从所选择的项目下降。
36.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中所述处理器实现的引擎根据存储在所述存储器中的指令被引导以从服务器请求和接收本地化的有向无环图(DAG)，所述本地化的DAG由所述服务器从全局DAG中提取，所述全局DAG包括多个实体和多个关联，所述多个关联的每个关联涉及所述多个实体的子实体和父实体，其中所述本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从多个项目的至少一个轨迹项目的相应至少一个源轨迹项目上升或下降，对应于至少一个轨迹项目的至少一个组成轨迹项目，对应于相应的至少一个源轨迹项目的至少一个组成轨迹项目的相应的至少一个源组成轨迹项目；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
其中:
i)多个实体包含多个项目，多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化该细化关联的父实体；和
ii)对于多个本地实体的所选上下文项目并且对应于多个项目的所选项目，该设备通过对于上下文集合序列中的每个上下文集合，该上下文集合序列包括第一上下文集合和最终上下文集合，该上下文集合包括多个本地实体的一个或多个上下文实体序列，来概括所选上下文项目的相应的至少一个路径，相同序列内的上下文实体通过本地化DAG中的细化而相关联，相同上下文集合内不同序列内的任何两个上下文实体在本地化DAG中不彼此上升或下降，第一上下文集合的每个上下文实体序列的第一上下文实体对应于至少一个轨迹实体的相应轨迹实体，上下文集合的上下文实体序列的最后一个上下文实体作为全局DAG中的子实体与后续上下文集合的上下文实体序列的第一个上下文实体相关，请求服务器在全局DAG中创建，产生结果全局DAG:
a.概括该上下文集合的概括实体，其中该概括实体被创建为多个实体中的实体；
b.与概括实体的第一关联，该概括实体将该上下文集合概括为子实体，并且与概括实体关联，该概括实体概括上下文集合序列中该上下文集合之后的父上下文集合，或者在该上下文集合是上下文集合序列中的最终上下文集合的情况下，将所选择的上下文项目作为父实体，其中第一关联被创建为多个关联中的关联；和
c.对于该上下文集合中的每个上下文实体序列，与作为子实体的该序列的上下文实体以及作为父实体的概括实体的相应第二关联，其中相应的第二关联被创建为多个细化关联中的细化关联，
从而概括上下文集合序列中的每个上下文集合，使得用户能够概括所选上下文项目的相应的至少一个路径。
37.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的服务器的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导:
a)从包括多个实体和多个关联的全局有向无环图中提取局部有向无环图，所述多个实体包含多个项目，所述多个关联的每个关联涉及所述多个实体的父实体和子实体；和
b)将本地化的DAG传送给客户端，
该本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从多个项目的至少一个轨迹项目的相应至少一个源轨迹项目上升或下降，对应于至少一个轨迹项目的至少一个组成轨迹项目，对应于相应的至少一个源轨迹项目的至少一个组成轨迹项目的相应的至少一个源组成轨迹项目；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
其中:
i)服务器生成并向客户端传送服务器证明，该服务器证明执行关于至少一个场所项目的给定场所项目的操作的用户不会导致任何形式的不一致的发生，或者该用户被授权通过其作为授权祖先项目的管理员、顾问、合作者或出资者的角色来执行该操作，该授权祖先项目是从给定场所项目提升到全球DAG中的；和
ii)根据来自客户端的关于多个本地实体中的目标实体执行操作的指示，伴随着由客户端基于本地化DAG的用户从目标实体的相应的至少一个源组成轨迹项目的源组成轨迹项目到目标实体的展示从服务器证明生成的客户端证明，服务器在执行关于全局DAG中的目标实体的操作之前验证客户端证明，
从而支持客户端利用本地化DAG的用户的展示来根据全局DAG为服务器生成客户端证明。
38.根据权利要求37所述的设备，其中:
a)服务器证明包括在全局DAG中从给定轨迹项目提升的祖先项目的相应至少一个路径的路径；和
b)当用户在本地化DAG中遍历对应路径时，通过包括添加或减去全局目标实体的相应至少一个路径的前缀路径的步骤，从服务器证明适配客户端证明，该目标实体对应于全局目标实体，
从而支持客户端利用本地化DAG中的目标实体的用户的展示来根据全局DAG为服务器生成客户端证明。
39.根据权利要求38所述的设备，所述多个关联包含多个细化关联，所述多个细化关联中的每个细化关联指示该细化关联的子实体细化该细化关联的父实体，其中:
a)处理器实现的引擎还被指示对本地化DAG执行重新配置，该重新配置使得对于至少一个轨迹项目的多个实体中的相应的至少一个可继承实体的每个可继承实体，该可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且通过所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径在全局DAG中提升，所述至少一个组成轨迹项目的各自组成继承轨迹项目对应于各自继承轨迹项目:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述多个本地实体包括对应于非基因座遗传实体的相应遗传实体；和
II)所述多个本地关联包括与相应的继承实体的相应继承关联，所述相应的继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在本地化DAG中从父本地实体上升；和
b)目标实体是目标继承实体，相应的继承实体对应于相应的至少一个可继承实体的目标可继承实体；和
c)服务器证明包括各自的继承路径，
从而支持客户端利用用户对本地化DAG中的目标继承实体的展示，该目标继承实体与全局继承轨迹项目相关，但不从全局DAG中的全局继承轨迹项目上升或下降，以根据全局DAG为服务器生成客户端证明。
40.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中所述处理器实现的引擎根据存储在所述存储器中的指令被引导以从服务器接收本地化的有向无环图(DAG)，所述本地化的DAG由所述服务器从全局DAG中提取，所述全局DAG包括多个实体和多个关联，所述多个关联的每个关联涉及所述多个实体的子实体和父实体，其中所述本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从多个项目的至少一个轨迹项目的相应至少一个源轨迹项目上升或下降，对应于至少一个轨迹项目的至少一个组成轨迹项目，对应于相应的至少一个源轨迹项目的至少一个组成轨迹项目的相应的至少一个源组成轨迹项目；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
其中:
i)客户端从服务器接收服务器证明，该服务器证明执行关于至少一个场所项目的给定场所项目的操作的用户不会导致任何形式的不一致的发生，或者该用户被授权通过他们作为从给定场所项目提升到全球DAG中的授权祖先项目的管理员、顾问、合作者或出资者的角色来执行该操作；和
ii)在来自用户的关于多个本地实体中的目标实体执行操作的指示下，客户端基于用户从目标实体的相应的至少一个源组成轨迹项目的源组成轨迹项目到目标实体的本地化DAG的展示，从服务器证明生成客户端证明，要验证的客户端证明和服务器关于全局DAG中的目标实体执行的操作，
从而利用本地化的DAG的用户的展示来根据全局DAG为服务器生成客户端证明。
41.根据权利要求40所述的设备，其中:
a)服务器证明包括在全局DAG中从给定轨迹项目提升的祖先项目的相应至少一个路径的路径；和
b)当用户在本地化DAG中遍历对应路径时，通过包括添加或减去全局目标实体的相应至少一个路径的前缀路径的步骤，从服务器证明适配客户端证明，该目标实体对应于全局目标实体，
从而利用本地化DAG中的目标实体的用户的展示来根据全局DAG为服务器生成客户端证明。
42.根据权利要求41所述的设备，所述多个关联包含多个细化关联，所述多个细化关联中的每个细化关联指示该细化关联的子实体细化该细化关联的父实体，其中:
a)本地化的DAG已经被服务器重新配置，使得对于至少一个轨迹项目的多个实体中的相应的至少一个可继承实体的每个可继承实体，该可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承子实体下降，所述多个项目包括各自适当的细化祖先项目，所述细化祖先项目作为全局DAG中的父项目与各自可继承的子实体相关联，并且通过所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹项目的各自继承轨迹项目通过各自的继承路径在全局DAG中提升，所述至少一个组成轨迹项目的各自组成继承轨迹项目对应于各自继承轨迹项目:
A)如果可遗传实体是非基因座遗传的可遗传实体，其在全局DAG中不是至少一个基因座项目的任何基因座项目的后代:
I)所述多个本地实体包括对应于非基因座遗传实体的相应遗传实体；和
II)多个本地关联包括与相应的继承实体的相应继承关联，该继承实体对应于非轨迹下降的可继承实体作为子本地实体，并且该可继承实体的相应组成继承轨迹项目在本地化DAG中从父本地实体上升；和
b)目标实体是目标继承实体，相应的继承实体对应于相应的至少一个可继承实体的目标可继承实体；和
c)服务器证明包括各自的继承路径，
从而利用用户对本地化DAG中的目标继承实体的展示，该目标继承实体与全局继承轨迹项目相关，但不从全局DAG中的全局继承轨迹项目上升或下降，以根据全局DAG为服务器生成客户端证明。
43.一种设备，包括:
处理器实现的引擎；和
耦合到处理器实现的引擎的存储器，
其中处理器实现的引擎根据存储在存储器中的指令被引导以在数据库中维护多个数据库记录，多个数据库记录中的每个数据库记录包括至少一个扇区，该数据库包括:
1)多个当前记录，由多个当前记录的相应当前记录存储的多个数据库记录的每个数据库记录的内容；
2)日志有向无环图(DAG)，该日志DAG包括多个变更记录和多个日志关联，多个变更记录中的每个变更记录指示数据库的相应变更，并且影响多个数据库记录中的至少一个受影响数据库记录的至少一个受影响扇区，多个日志关联中的每个日志关联涉及父变更记录和子变更记录，该日志关联的子改变记录的至少一个受影响扇区的至少一个重叠扇区也是该日志关联的父改变记录的至少一个受影响扇区，该日志关联的子改变记录所指示的数据库的相应改变发生在该日志关联的父改变记录所指示的数据库的相应改变之后；和
3)将多个数据库记录的每个数据库记录的每个扇区与多个改变记录的相应当前改变记录相关联的当前改变记录映射，该扇区不属于在日志DAG中从该扇区的相应当前改变记录下降的任何后代改变记录的至少一个受影响扇区，
通过:
a)通过以下步骤改变至少一个改变的数据库记录的至少一个改变的扇区:
i)为所述至少一个改变的数据库记录的每个改变的数据库记录创建、修改或删除相应的当前记录；
ii)在所述多个改变记录内创建改变记录，所述改变记录从由所述至少一个改变的数据库记录的至少一个改变的扇区的每个改变的扇区的当前改变记录映射指示的相应的当前改变记录在日志DAG中下降，所述改变记录影响所述至少一个改变的数据库记录的至少一个改变的扇区，所述改变记录包括足够的内容来反转所述改变；和
iii)将所述至少一个已改变数据库记录的至少一个已改变扇区的当前改变记录映射设置为所述改变记录；和
b)通过以下方式回滚日志DAG中的给定更改记录:
i)在多个当前记录中，深度优先地撤销从日志DAG中的给定变更记录下降的每个受影响的变更记录所指示的相应变更；和
ii)将受给定变更记录的任何后代变更记录影响的每个扇区的当前变更记录映射设置为日志DAG中影响该扇区的给定变更记录的至多一个父记录，
从而能够对由第一改变记录指示的数据库进行第一改变，然后对由第二改变记录指示的数据库进行第二改变，第一改变记录和第二改变记录影响不重叠的扇区，然后回滚第一改变记录，将第二改变留在数据库中。
44.根据权利要求43所述的设备，其中:
a)用于创建当前记录的改变记录包括当前记录的初始内容；
b)用于修改当前记录的改变记录包括替换修改的内容；
c)至少一个未撤销的变更记录被标记为已撤销；和
d)处理器实现的引擎还被指示向前滚动到至少一个撤消的变更记录的给定撤消的变更记录，由给定撤消的变更记录指示的相应变更已经被撤消，通过:
i)在多个当前记录内深度优先地重做由从给定未完成的改变记录上升的每个未完成的改变记录指示的相应改变，对于每个扇区遇到相应的最浅的改变记录；和
ii)将受每个撤消的变更记录影响的每个扇区的当前变更记录映射设置为该扇区遇到的相应最浅的变更记录，
从而实现第二变更记录的回滚，然后第一变更记录或第二变更记录的前滚，将变更留给由回滚的另一个变更记录指示的数据库。
45.根据权利要求43所述的设备，其中:
a)多个数据库记录被安排在包括多个数据库记录和多个关联的DAG中，多个关联的每个关联涉及多个数据库记录的子数据库记录和父数据库记录；
b)所述DAG被扩充，使得所述多个数据库记录的新数据库记录作为子记录经由所述多个关联的关联与先前创建的数据库记录相关联；和
c)用于创建新数据库记录的改变记录包括至少一个受影响扇区的至少一个重叠扇区，并且作为日志DAG中的子记录与用于创建先前创建的数据库记录的改变记录相关，
回滚对应于先前创建的数据库记录的创建的变更记录，从而涉及撤销新数据库记录的创建。
46.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的服务器的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导以在数据库中维护多个数据库记录，多个数据库记录中的每个数据库记录包括至少一个扇区，该数据库包括:
1)多个当前记录，由所述多个当前记录的相应当前记录存储的所述多个数据库记录的每个数据库记录的内容，所述多个当前记录包含多个用户当前记录，所述多个用户当前记录的每个用户当前记录指示在多个用户中需要审核的多个用户的相应用户，并且存储所述多个数据库记录的数据库记录的内容；
2)日志有向无环图(DAG)，该日志DAG包括多个改变记录和多个日志关联，多个改变记录中的每个改变记录指示数据库的改变并且影响多个数据库记录中的至少一个受影响数据库记录的至少一个受影响扇区，多个日志关联中的每个日志关联涉及父改变记录和子改变记录，该日志关联的子改变记录的至少一个受影响扇区的至少一个重叠扇区也是该日志关联的父改变记录的至少一个受影响扇区，该日志关联的子改变记录所指示的数据库的相应改变发生在该日志关联的父改变记录所指示的数据库的相应改变之后，多个变更记录包含多个用户变更记录，所述多个用户变更记录中的每个用户变更记录指示需要审核变更的相应负责用户，需要审核的相应负责用户是需要审核的多个用户中的一个；
3)将多个数据库记录的每个数据库记录的每个扇区与多个改变记录的相应当前改变记录相关联的当前改变记录映射，该扇区不属于在日志DAG中从该扇区的相应当前改变记录下降的任何后代改变记录的至少一个受影响扇区；和
4)用户当前变更记录映射，其将需要审核的多个用户中的一个或多个需要审核的每个用户以及多个数据库记录中的每个数据库记录的每个扇区与多个用户变更记录中的相应用户当前变更记录相关联，该扇区不是该用户的任何后代用户变更记录的至少一个受影响扇区，该用户的后代用户变更记录是从该扇区的相应当前变更记录在日志DAG中下降的，
通过在至少一个客户端通知至少一个改变时，所述至少一个改变的每个改变影响相应的至少一个改变的数据库记录的相应的至少一个改变的扇区，所述相应的至少一个改变的数据库记录包括由要求对该改变进行审核的相应编辑用户进行的公共改变的数据库记录的特定公共改变的扇区，所述要求审核的相应编辑用户是需要审核的多个用户中的一个，通过以下步骤执行所述至少一个改变的每个改变:
i)对于相应的至少一个改变的数据库记录的每个改变的数据库记录:
a.在所述多个用户当前记录不包括指示需要审核的相应编辑用户的用户当前记录的情况下，创建指示需要审核的相应编辑用户的用户当前记录，并在所述多个用户当前记录内存储已更改数据库记录的内容；或者
b.其中所述多个用户当前记录包括用户当前记录，所述用户当前记录指示相应的编辑用户需要审核并存储该改变的数据库记录的内容，修改用户当前记录；
ii)在多个用户变更记录中为该变更创建相应的用户变更记录，要求审核的相应编辑用户是要求审核相应用户变更记录的相应负责用户，使相应的用户改变记录在日志DAG中从由需要审核的相应编辑用户的用户当前改变记录映射和相应的至少一个改变的数据库记录的相应的至少一个改变的扇区的每个改变的扇区指示的任何相应的当前改变记录下降，或者从由相应的至少一个改变的数据库记录的相应的至少一个改变的扇区的每个改变的扇区的当前改变记录映射所指示的相应的当前改变记录，相应的用户改变记录影响相应的至少一个改变的数据库记录的相应的至少一个改变的扇区，相应的用户改变记录包括足够的内容来反转该改变；和
iii)为需要审核的相应编辑用户和相应的至少一个改变的数据库记录的相应的至少一个改变的扇区设置用户当前改变记录映射到该改变的相应用户改变记录，
从而对于所述至少一个改变的每一个改变，支持所述至少一个客户端向要求对该改变进行审核的相应编辑用户呈现包括共同改变和该改变的数据库视图，以及向另一用户呈现包括共同改变和排除该改变的数据库视图。
47.根据权利要求46所述的设备，其中:
处理器实现的引擎还被指示，在管理客户端通知多个用户中的管理用户批准至少一个变更的待批准变更的动作时，以管理员角色的管理用户通过以下方式批准待批准变更:
i)对于要被批准的改变的相应的至少一个已改变的数据库记录的每个已改变的数据库记录，将要被批准的改变应用于该已改变的数据库记录的相应的当前记录，并且在多个用户改变记录中没有剩余的未批准的改变记录影响该已改变的数据库记录的情况下，指示需要对要被批准的改变进行审核的相应的编辑用户，移除指示需要对要被批准的改变进行审核的相应的编辑用户的用户当前记录，并且从多个用户当前记录中存储该已改变的数据库记录的内容；
ii)从用于待批准的变更的相应用户变更记录中创建多个变更记录中的变更记录，对于用于待批准的变更的相应至少一个已变更数据库记录的相应至少一个已变更扇区的每个已变更扇区，使该变更记录从由当前变更记录映射指示的相应当前变更记录下降到日志DAG中，该改变记录影响用于待批准的改变的相应的至少一个改变的数据库记录的相应的至少一个改变的扇区，该改变记录包括足够的内容来反转待批准的改变，并且从多个用户改变记录中移除用于待批准的改变的相应的用户改变记录；和
iii)为要被批准的变更的相应的至少一个变更数据库记录的相应的至少一个变更扇区设置当前变更记录映射到变更记录，并且其中需要审核的相应的编辑用户的用户当前变更记录映射和要被批准的变更的相应的至少一个变更数据库记录的相应的至少一个变更扇区被设置到要被批准的变更的相应的用户变更记录，为需要审核的相应编辑用户和要批准的变更的相应至少一个变更数据库记录的相应至少一个变更扇区重置用户当前变更记录映射，
从而支持所述至少一个客户端为每个变更向要求审核该变更的相应编辑用户呈现包括该变更的数据库视图，直到待批准的变更被批准，之后向要求审核该变更的相应编辑用户呈现包括该变更和待批准的变更的数据库视图。
48.根据权利要求46所述的设备，其中:
处理器实现的引擎还被指示，在客户端通知由多个用户中的一个用户进行的要逆转的至少一个改变的要逆转的改变的动作时，通过以下方式逆转要逆转的改变:
i)对于要撤销的改变的相应的至少一个已改变的数据库记录的每个已改变的数据库记录，其中多个用户改变记录中没有剩余的未批准的改变记录影响该已改变的数据库记录，并且指示需要对要撤销的改变进行审核的相应编辑用户，从多个用户当前记录中移除指示需要审核的相应编辑用户的用户当前记录并且存储该已改变的数据库记录的内容，否则撤销对存储该已改变的数据库记录的内容并且指示需要审核的相应编辑用户的用户当前记录的改变；和
ii)其中用于需要审核的相应编辑用户的用户当前变更记录映射和用于待撤销变更的相应至少一个已变更数据库记录的相应至少一个已变更扇区被设置为用于待撤销变更的相应用户变更记录，重置用于需要审核的相应编辑用户的用户当前变更记录映射和用于待撤销变更的相应至少一个已变更数据库记录的相应至少一个已变更扇区，
从而支持所述至少一个客户端将包括要反转的改变的数据库视图呈现给需要对要反转的改变进行审核的相应编辑用户，并将不包括要反转的改变的数据库视图呈现给多个用户中的另一个用户，直到要反转的改变被反转，之后将不包括要反转的改变的数据库视图呈现给需要对要反转的改变进行审核的相应编辑用户和另一个用户。
49.根据权利要求46所述的设备，其中:
当管理客户端通知多个用户中的管理用户通过解析包括所述至少一个改变的每个改变的至少一个元素的改变来解析所述至少一个改变的动作时，处理器实现的引擎还被指示以管理员的角色执行解析改变，通过:
i)对于所述至少一个改变和解析改变中的每一个的相应的至少一个改变的数据库记录的每个改变的数据库记录，将所述至少一个改变和解析改变中的每一个应用于该改变的数据库记录的相应的当前记录，并且对于所述至少一个改变的每个改变，其中所述多个用户改变记录中没有剩余的未批准的改变记录影响所述改变的数据库记录，并且指示需要对该改变进行审核的相应编辑用户，移除指示需要对该改变进行审核的相应编辑用户的任何用户当前记录，并且从所述多个用户当前记录中存储该改变的数据库记录的内容；
ii)针对所述至少一个改变的每个改变，从该改变的相应用户改变记录，在所述多个改变记录中创建改变记录，对于该改变的相应至少一个改变的数据库记录的相应至少一个改变的扇区的每个改变的扇区，所述改变记录在日志DAG中从由当前改变记录映射指示的相应当前改变记录下降，该改变记录影响该改变的相应的至少一个改变的数据库记录的相应的至少一个改变的扇区，该改变记录包括足够的内容来反转该改变，从多个用户改变记录中移除该改变的相应的用户改变记录，并且在多个改变记录中创建用于解决改变的解决改变记录，使解析改变记录在日志DAG中从用于至少一个改变中的每一个的改变记录和由用于解析改变的相应的至少一个改变的数据库记录的相应的至少一个改变的扇区的每个改变的扇区的当前改变记录映射指示的相应的当前改变记录下降，解析改变记录影响用于解析改变的相应的至少一个改变的数据库记录的相应的至少一个改变的扇区，改变记录包括足够的内容来反转解析改变；和
iii)对于所述至少一个改变的每个改变，将该改变的相应至少一个改变的数据库记录的相应至少一个改变的扇区的当前改变记录映射设置为该改变的相应用户改变记录，除了为相应的至少一个改变的数据库记录的相应的至少一个改变的扇区设置当前改变记录映射，用于解决改变到相应的用户改变记录的解决改变，并且其中用于需要审核的相应编辑用户的用户当前改变记录映射和用于该改变的相应的至少一个改变的数据库记录的相应的至少一个改变的扇区被设置到相应的用户改变记录对于该改变，为需要审核的相应编辑用户和该改变的相应至少一个改变的数据库记录的相应至少一个改变的扇区重置用户当前改变记录映射，
从而支持客户端向相应的编辑用户呈现包括解析改变的数据库视图，要求对至少一个改变的每个改变进行审核。
50.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；
耦合到处理器实现的引擎的显示器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导以提供对数据库中的多个数据库记录的访问，
多个数据库记录中的每个数据库记录包括至少一个扇区，通过:
a)当用户改变至少一个改变的数据库记录的至少一个改变的扇区时，请求服务器执行该改变；
b)根据用户的数据库查询，从服务器获得并提供包括变化的数据库视图；
c)从服务器获得并在显示器上向用户呈现日志有向无环图(DAG)的视图，日志DAG包括多个变更记录和多个日志关联，多个变更记录中的每个变更记录指示数据库的相应变更并影响多个数据库记录中的至少一个受影响数据库记录的至少一个受影响扇区，多个日志关联的每个日志关联涉及父变化记录和子变化记录，该日志关联的子变化记录的至少一个受影响扇区的至少一个重叠扇区也是该日志关联的父变化记录的至少一个受影响扇区，该日志关联的子变化记录所指示的数据库的相应变化发生在该日志关联的父变化记录所指示的数据库的相应变化之后；
d)当用户在显示器上指示多个改变记录中的改变记录的节点上发起撤销操作时，该改变记录指示该改变，请求服务器撤销该改变以及日志DAG中该节点的适当后代所指示的任何改变；和
e)在用户随后的数据库查询时，从服务器获得并呈现数据库的视图，排除日志DAG中该节点的适当后代所指示的改变和任何改变，
从而使用户能够可视地识别并启动撤销操作，以撤销改变和覆盖在改变上的任何后续改变。
51.根据权利要求50所述的设备，所述改变是未撤销的改变，所述显示区分指示所述多个改变记录中的未撤销的改变记录的未撤销节点，所述未撤销的改变记录指示已经撤销的未撤销的改变，其中:
处理器实现的引擎根据存储在存储器中的指令，在用户发起对撤消节点的重做操作时，请求服务器重做撤消的改变和由撤消节点的适当祖先节点所指示的任何撤消的改变记录所指示的任何撤消的改变，所述撤消的改变记录在日志DAG中从撤消节点经由包括至少两个节点的路径上升，
从而使用户能够可视地识别并启动重做操作来重做该改变以及覆盖该改变的任何先前的、先前撤消的改变。
52.根据权利要求50所述的设备，所述用户是需要节制的用户，其中:
处理器实现的引擎根据存储在存储器中的指令被引导，以提供对数据库中的多个数据库记录的定制访问，在请求服务器执行改变之后并且在请求服务器撤销改变以及由日志DAG中的节点的适当后代指示的任何改变之前:
当另一用户进行数据库查询时，从服务器获得并呈现排除该变化的数据库视图，
从而向需要审核的用户呈现包括该改变的数据库视图，向另一用户呈现排除该改变的数据库视图，直到该改变被撤消，并且此后向需要审核的用户和另一用户呈现排除该改变的数据库视图。
53.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；
耦合到处理器实现的引擎的显示器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中所述处理器实现的引擎根据存储在所述存储器中的指令被引导以提供对数据库中的多个数据库记录的访问，所述多个数据库记录中的每个数据库记录包括至少一个扇区，通过:
a)从服务器获得日志有向无环图(DAG)的视图并在显示器上呈现给管理用户，管理用户以管理员的角色，日志DAG包括多个改变记录和多个日志关联，多个改变记录中的每个改变记录指示数据库的相应改变并影响多个数据库记录中的至少一个受影响数据库记录的至少一个受影响扇区，多个日志关联的每个日志关联涉及父变化记录和子变化记录，该日志关联的子变化记录的至少一个受影响扇区的至少一个重叠扇区也是该日志关联的父变化记录的至少一个受影响扇区，该日志关联的子变化记录所指示的数据库的相应变化发生在该日志关联的父变化记录所指示的数据库的相应变化之后；和
b)当管理用户在显示器上的至少一个节点上启动指示多个改变记录中的至少一个改变记录的操作时，该至少一个改变记录指示至少一个用户的至少一个改变需要审核，请求服务器执行该操作，该操作更新为至少一个更新的数据库记录的至少一个更新的扇区存储的内容，该至少一个更新的扇区是至少一个变更记录的至少一个受影响数据库记录的至少一个受影响扇区的扇区，
从而使管理用户能够可视地识别并启动至少一个变化的操作。
54.根据权利要求53所述的设备，其中:
a)该至少一个改变是一个改变，并且该至少一个需要审核的用户是该一个改变需要审核的用户；
b)该操作是批准操作，请求服务器批准一个改变；
c)处理器实现的引擎根据存储在存储器中的指令，在另一用户的后续数据库查询时，从服务器获得并向另一用户呈现包括一个变化的数据库视图，
从而使管理用户能够可视地识别并启动批准操作以批准该一个改变，向需要审核的用户呈现包括该一个改变的数据库视图，向另一用户呈现排除该一个改变的数据库视图，直到该一个改变被批准，并且此后向需要审核的用户和另一用户呈现包括该一个改变的数据库视图。
55.根据权利要求53所述的设备，其中:
a)该至少一个改变是一个改变，并且该至少一个需要审核的用户是该一个改变需要审核的用户；
b)该操作是拒绝操作，请求服务器拒绝该一个改变；
c)处理器实现的引擎根据存储在存储器中的指令，在用户随后要求审核的数据库查询时，从服务器获得并向另一用户呈现数据库的视图，不包括一个变化，
从而使管理用户能够可视地识别并启动拒绝操作以拒绝该一个改变，向需要审核的用户呈现包括该一个改变的数据库视图，直到该一个改变被拒绝，并且此后向需要审核的用户呈现排除该一个改变的数据库视图。
56.根据权利要求53所述的设备，其中:
a)该操作是解析操作，请求服务器解析该至少一个改变；
b)处理器实现的引擎根据存储在存储器中的指令被引导:
a.从管理用户获得解析改变，该解析改变包括至少一个改变的每个改变的至少一个元素，并且影响至少一个重叠数据库记录的至少一个重叠扇区，该至少一个重叠扇区是至少一个改变记录的至少一个受影响数据库记录的至少一个受影响扇区；
b.当所述至少一个用户的后续数据库查询需要审核时，从服务器获得并向另一个用户呈现包括解析变化的数据库视图，
从而使得管理用户能够可视地识别并启动解决操作，以针对每个改变解决至少一个改变，向需要对该改变进行审核的用户呈现包括该改变的数据库的视图，直到该改变被解决，并且此后向需要对该改变进行审核的用户呈现包括解决改变的数据库的视图。
57.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的服务器的网络硬件，
其中处理器实现的引擎根据存储在存储器中的指令被引导:
a)从包括多个实体和多个关联的全局有向无环图中提取定位于多个实体的至少一个轨迹实体的局部有向无环图，多个关联的每个关联涉及多个实体的子实体和父实体；
b)在本地化的DAG上执行重新配置；和
c)将本地化的DAG传送到客户端，
该本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从至少一个位置实体的相应至少一个源位置实体上升或下降，至少一个组成位置实体对应于至少一个位置实体；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，其中:
i)多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化了该细化关联的父实体，
所述重新配置使得对于所述至少一个场所实体的多个实体中相应的至少一个可继承实体的每个可继承实体，所述可继承实体在全局DAG中通过相应的可继承实体路径从相应的可继承父实体上升，所述多个实体包括各自适当的细化后代实体，其作为全局DAG中的子实体与各自可继承的父实体相关联，并且在全局DAG中通过各自的继承路径，借助于所述多个细化关联的一个或多个细化关联的各自序列，从所述至少一个轨迹实体的各自继承轨迹实体下降，所述至少一个组成轨迹实体的各自组成继承轨迹实体对应于各自继承轨迹实体:
其中可继承实体是非轨迹提升可继承实体，其没有从至少一个轨迹实体的任何轨迹实体在全局DAG中提升:
I)多个本地实体包括对应于非轨迹提升可继承实体的相应继承实体；和
II)所述多个本地关联包括与相应的继承实体的相应继承关联，所述相应的继承实体对应于非轨迹提升的可继承实体作为父本地实体，并且该可继承实体的相应组成继承轨迹实体在本地化DAG中从子本地实体下降，
从而支持客户端使客户端的用户能够想象从相应的组成继承轨迹实体提升，并在对应于非轨迹提升的可继承实体的相应继承实体上启动操作，非轨迹提升的可继承实体与非轨迹提升的可继承实体的相应继承轨迹实体相关，但不是从非轨迹提升的可继承实体的相应继承轨迹实体提升或下降。
58.根据权利要求57所述的设备，所述相应的至少一个可继承实体的深度可继承组件不是所述相应的可继承父实体，所述重新配置还使得对于所述相应的至少一个可继承实体的每个可继承实体:
在可继承实体是轨迹提升可继承组件的情况下，对应于轨迹提升可继承组件的已继承或组成组件在本地化DAG中从该可继承实体的相应组成继承轨迹实体提升:
I)所述多个本地关联包括各自的合并关联，所述合并关联具有作为父本地实体的已经继承的或组成的组件以及作为子本地实体的对应于沿着各自的可继承实体路径的轨迹提升的可继承组件的子的子继承实体，
从而支持客户端使用户能够将从相应的组成继承轨迹实体的提升可视化，并在已经继承或组成的组件上启动第二操作，轨迹提升的可继承组件是集成层次结构内的深度可继承组件，子组件包括对应于深度可继承组件的相应可继承实体路径上的可继承子实体的至少一个继承子实体，以及不对应于深度可继承组件的相应可继承实体路径上的任何可继承子实体的至少一个其他子实体。
59.根据权利要求57所述的设备，其中:
多个实体包含多个技能；和
所述至少一个轨迹实体是多个技能中的至少一个轨迹技能，相应的适当细化后代实体是多个技能中相应的适当细化后代技能，相应的继承轨迹实体是相应的继承轨迹技能，并且相应的组成继承轨迹实体是相应的组成继承轨迹技能，
从而支持客户端使用户能够想象从相应的组成继承轨迹技能提升，并在对应于非轨迹提升的可继承实体的相应继承实体上启动操作，非轨迹提升的可继承实体与非轨迹提升的可继承实体的相应继承轨迹技能相关，但不是从非轨迹提升的可继承实体的相应继承轨迹技能提升或下降。
60.根据权利要求59所述的设备，其中:
所述至少一个可继承实体是多个项目中的可继承项目，并且相应的可继承父实体是相应的可继承父项目，其直接需要相应的适当细化后代技能，
从而支持客户端使用户能够想象从各自的组成继承轨迹技能提升，并启动对继承项目的操作，这需要适当的细化后代技能，一种比继承轨迹技能更具体的技能。
61.根据权利要求59所述的设备，其中:
该至少一个可继承实体是多个实体内的多个用户的可继承用户，并且相应的可继承父实体是直接精通相应的适当细化后代技能的相应的可继承父用户，
从而支持客户端使用户能够想象从各自的组成继承轨迹技能提升，并启动对继承用户的操作，该用户精通适当的细化后代技能，这是比继承轨迹技能更具体的技能。
62.一种设备，包括:
处理器实现的引擎；
耦合到处理器实现的引擎的存储器；和
支持处理器实现的引擎充当与一个或多个计算设备通信的客户端的网络硬件，
其中所述处理器实现的引擎根据存储在所述存储器中的指令被引导以从服务器接收本地化的有向无环图(DAG)，所述本地化的DAG由所述服务器从全局DAG中提取，所述全局DAG包括多个实体和多个关联，所述多个关联的每个关联涉及所述多个实体的子实体和父实体，其中所述本地化的DAG包括:
1)多个本地实体，包括对应于多个实体内的多个特定可达实体的每个实体的组成实体，多个特定可达实体的每个实体在全局DAG中通过相应的至少一条路径从多个实体的至少一个轨迹实体的相应至少一个源轨迹实体上升或下降，至少一个组成轨迹实体对应于至少一个轨迹实体；和
2)多个本地关联，包括对应于多个特定可达实体的每个实体的相应至少一条路径上的多个关联的每个关联的组成关联，该组成关联将对应于该关联的子实体的组成实体关联为子本地实体，并将对应于该关联的父实体的组成实体关联为父本地实体，
所述本地化的DAG已经被所述服务器重新配置，向导航到所述至少一个地点实体的用户呈现通过相关实体进行探索的方式，其中:
a)多个关联包含多个细化关联，多个细化关联中的每个细化关联指示该细化关联的子实体细化了该细化关联的父实体；和
b)使用户能够在本地化DAG中从至少一个组成位置实体的相应组成继承位置实体将对应于多个实体的至少一个可继承实体的每个可继承实体的多个本地实体的相应继承实体可视化为提升，至少一个可继承实体的每个可继承实体通过相应的可继承实体路径从相应的可继承父实体在全局DAG中提升，所述多个实体包括相应的适当的细化后代实体，其作为全局DAG中的子实体与相应的可继承父实体相关联，并且在全局DAG中借助于所述多个细化关联的一个或多个细化关联的相应序列，通过相应的继承路径从所述至少一个轨迹实体的相应继承轨迹实体下降，所述相应的继承轨迹实体对应于相应的组成继承轨迹实体，所述至少一个可继承实体的深层可继承组件不是相应的可继承父实体，所述本地化DAG已经被重新配置，使得对于所述至少一个可继承实体的每个可继承实体:
A)当可遗传实体是非轨迹提升可遗传实体时，该可遗传实体不是从该至少一个轨迹实体的任何轨迹实体在全局DAG中提升的:
I)多个本地实体包括对应于非轨迹提升可继承实体的相应继承实体；和
II)多个本地关联包括与相应的继承实体的相应继承关联，该继承实体对应于作为父本地实体的非轨迹提升的可继承实体，并且该可继承实体的相应组成继承轨迹实体在本地化DAG中是子本地实体的后代，
从而使用户能够想象从相应的组成继承轨迹实体提升，并在相应于非轨迹提升可继承实体的相应继承实体上启动操作，非轨迹提升可继承实体与非轨迹提升可继承实体的相应继承轨迹实体相关，但不是从非轨迹提升可继承实体的相应继承轨迹实体提升或下降。
63.根据权利要求62所述的设备，所述相应的至少一个可继承实体的深度可继承组件不是所述相应的可继承父实体，所述本地化DAG已经被进一步重新配置，使得对于所述相应的至少一个可继承实体的每个可继承实体:
在可继承实体是轨迹提升可继承组件的情况下，对应于轨迹提升可继承组件的已继承或组成组件在本地化DAG中从该可继承实体的相应组成继承轨迹实体提升:
I)所述多个本地关联包括各自的合并关联，所述合并关联具有作为父本地实体的已经继承的或组成的组件以及作为子本地实体的对应于沿着各自的可继承实体路径的轨迹提升的可继承组件的子的子继承实体，
从而使用户能够将从相应的组成继承轨迹实体的提升可视化，并在已经继承的或组成的组件上启动第二操作，轨迹提升的可继承组件是集成层次结构内的深度可继承组件，其中子组件包括对应于深度可继承组件的相应可继承实体路径上的可继承子实体的至少一个继承子实体，以及不对应于深度可继承组件的相应可继承实体路径上的任何可继承子实体的至少一个其他子实体。
64.根据权利要求63所述的设备，其中:
多个实体包含多个技能；和
所述至少一个轨迹实体是多个技能中的至少一个轨迹技能，相应的适当细化后代实体是多个技能中相应的适当细化后代技能，相应的继承轨迹实体是相应的继承轨迹技能，并且相应的组成继承轨迹实体是相应的组成继承轨迹技能，
从而使用户能够想象从相应的组成继承轨迹技能提升，并在相应于非轨迹提升可继承实体的相应继承实体上启动操作，非轨迹提升可继承实体与非轨迹提升可继承实体的相应继承轨迹技能相关，但不是从非轨迹提升可继承实体的相应继承轨迹技能提升或下降。
65.根据权利要求64所述的设备，其中:
所述至少一个可继承实体是所述多个实体内的多个项目的可继承项目，并且相应的可继承父实体是直接需要相应的适当细化后代技能的相应的可继承父项目，
从而使用户能够想象从各自的组成继承轨迹技能提升，并启动对继承项目的操作，这需要适当的细化后代技能，一种比继承轨迹技能更具体的技能。
66.根据权利要求64所述的设备，其中:
该至少一个可继承实体是多个实体内的多个用户的可继承用户，并且相应的可继承父实体是直接精通相应的适当细化后代技能的相应的可继承父用户，
从而使用户能够想象从各自的组成继承轨迹技能提升，并对继承的用户启动操作，该用户精通适当的细化后代技能，这是比继承轨迹技能更具体的技能。
CN201680080066.3A 2015-11-25 2016-11-25 增广、探索、和维护项目分层结构的方法 Active CN109121436B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562260072P 2015-11-25 2015-11-25
US62/260,072 2015-11-25
PCT/US2016/063789 WO2017091821A1 (en) 2015-11-25 2016-11-25 Methods for the augmentation, exploration, and maintenance of project hierarchies

Publications (2)

Publication Number Publication Date
CN109121436A CN109121436A (zh) 2019-01-01
CN109121436B true CN109121436B (zh) 2022-06-21

Family

ID=58721690

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201680080066.3A Active CN109121436B (zh) 2015-11-25 2016-11-25 增广、探索、和维护项目分层结构的方法

Country Status (6)

Country Link
US (2) US11222074B2 (zh)
JP (1) JP6858983B2 (zh)
CN (1) CN109121436B (zh)
GB (1) GB201810392D0 (zh)
SE (3) SE2251384A2 (zh)
WO (1) WO2017091821A1 (zh)

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10630686B2 (en) 2015-03-12 2020-04-21 Fornetix Llc Systems and methods for organizing devices in a policy hierarchy
US10560440B2 (en) 2015-03-12 2020-02-11 Fornetix Llc Server-client PKI for applied key management system and process
US10965459B2 (en) 2015-03-13 2021-03-30 Fornetix Llc Server-client key escrow for applied key management system and process
GB201810392D0 (en) 2015-11-25 2018-08-08 Teamifier Inc Methods for the augmentation, exploration, and maintenance of project hierarchies
US10650045B2 (en) 2016-02-05 2020-05-12 Sas Institute Inc. Staged training of neural networks for improved time series prediction performance
US10650046B2 (en) 2016-02-05 2020-05-12 Sas Institute Inc. Many task computing with distributed file system
US10795935B2 (en) 2016-02-05 2020-10-06 Sas Institute Inc. Automated generation of job flow definitions
US10331495B2 (en) * 2016-02-05 2019-06-25 Sas Institute Inc. Generation of directed acyclic graphs from task routines
US10642896B2 (en) 2016-02-05 2020-05-05 Sas Institute Inc. Handling of data sets during execution of task routines of multiple languages
US10880281B2 (en) 2016-02-26 2020-12-29 Fornetix Llc Structure of policies for evaluating key attributes of encryption keys
US10931653B2 (en) * 2016-02-26 2021-02-23 Fornetix Llc System and method for hierarchy manipulation in an encryption key management system
US10268345B2 (en) * 2016-11-17 2019-04-23 General Electric Company Mehtod and system for multi-modal lineage tracing and impact assessment in a concept lineage data flow network
US20180173805A1 (en) * 2016-12-16 2018-06-21 Sap Se Application programming interface for detection and extraction of data changes
US20180181676A1 (en) * 2016-12-22 2018-06-28 Google Inc. Nodes in directed acyclic graph
WO2018152319A1 (en) * 2017-02-16 2018-08-23 North Carolina State University Spreadsheet recalculation algorithm for directed acyclic graph processing
CN108305306B (zh) * 2018-01-11 2020-08-21 中国科学院软件研究所 一种基于草图交互的动画数据组织方法
US10838698B2 (en) * 2018-09-24 2020-11-17 Salesforce.Com, Inc. Providing a reuse capability for visual programming logic within a building tool
CN109740127B (zh) * 2019-01-08 2023-05-26 武汉益模科技股份有限公司 一种基于三维模型的无序拆装方法
US10997192B2 (en) 2019-01-31 2021-05-04 Splunk Inc. Data source correlation user interface
CN109885259B (zh) * 2019-02-21 2022-05-06 缀初网络技术(上海)有限公司 基于有向无环图的轻量级容量证明方法及存储介质
CN109918876A (zh) * 2019-03-18 2019-06-21 京东方科技集团股份有限公司 权限过滤方法和权限过滤装置
US11593353B2 (en) 2019-04-03 2023-02-28 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
CN110190983B (zh) * 2019-04-18 2022-05-10 网宿科技股份有限公司 一种网络问题分析方法及装置
US10754638B1 (en) 2019-04-29 2020-08-25 Splunk Inc. Enabling agile functionality updates using multi-component application
US11023465B2 (en) * 2019-05-07 2021-06-01 Optum, Inc. Cross-asset data modeling in multi-asset databases
CN110263458B (zh) * 2019-06-25 2020-12-08 中国汽车工程研究院股份有限公司 一种基于大数据的汽车工程信息平台
US11175914B2 (en) * 2019-06-28 2021-11-16 Aras Corporation Calculation engine for performing calculations based on dependencies in a self-describing data system
CN110377894B (zh) * 2019-07-19 2023-09-15 广联达科技股份有限公司 下钻-上钻显示控制方法、系统、装置与存储介质
CN112256656B (zh) * 2019-07-22 2023-04-18 金篆信科有限责任公司 事务回滚方法及装置、数据库、系统、计算机存储介质
CN110659284A (zh) * 2019-08-20 2020-01-07 北京清红微谷技术开发有限责任公司 基于树图结构的区块定序方法及系统、数据处理终端
CN110781313A (zh) * 2019-09-29 2020-02-11 北京淇瑀信息科技有限公司 一种图存储优化方法、装置和电子设备
CN110727834A (zh) * 2019-09-30 2020-01-24 北京百度网讯科技有限公司 有向无环图的获取方法、装置、电子设备和存储介质
US11151125B1 (en) 2019-10-18 2021-10-19 Splunk Inc. Efficient updating of journey instances detected within unstructured event data
CN110795444B (zh) * 2019-10-25 2022-12-02 北京小米移动软件有限公司 Dom数据更新方法、页面更新方法及装置
EP4052123A4 (en) * 2019-10-28 2023-07-26 Services Pétroliers Schlumberger DRILLING ACTIVITY RECOMMENDATION SYSTEM AND PROCEDURES
US11169979B2 (en) * 2019-12-31 2021-11-09 Intuit, Inc. Database-documentation propagation via temporal log backtracking
US11507623B2 (en) * 2020-03-05 2022-11-22 Sap Se Inheritance in dynamic hierarchical systems
CN111444254B (zh) * 2020-03-30 2023-03-28 北京东方金信科技有限公司 一种skl系统文件格式转换方法和系统
US11809447B1 (en) * 2020-04-30 2023-11-07 Splunk Inc. Collapsing nodes within a journey model
US11630826B2 (en) * 2020-05-29 2023-04-18 Rn Technologies, Llc Real-time processing of a data stream using a graph-based data model
US20220027409A1 (en) * 2020-07-23 2022-01-27 Vmware, Inc. Entity to vector representation from graphs in a computing system
US11442964B1 (en) * 2020-07-30 2022-09-13 Tableau Software, LLC Using objects in an object model as database entities
US11741131B1 (en) 2020-07-31 2023-08-29 Splunk Inc. Fragmented upload and re-stitching of journey instances detected within event data
CN111930768B (zh) * 2020-09-10 2021-01-01 腾讯科技（深圳）有限公司 增量数据获取方法、发送方法、装置及其计算机存储介质
CN112148710B (zh) * 2020-09-21 2023-11-14 珠海市卓轩科技有限公司 微服务分库方法、系统和介质
CN112347103B (zh) * 2020-11-05 2024-04-12 深圳市极致科技股份有限公司 数据同步方法、装置、电子设备及存储介质
US20220156393A1 (en) * 2020-11-19 2022-05-19 Tetrate.io Repeatable NGAC Policy Class Structure
CN112633853A (zh) * 2020-12-31 2021-04-09 北京达佳互联信息技术有限公司 项目管理方法、装置及电子设备
US11567998B2 (en) * 2021-03-25 2023-01-31 Databricks, Inc. Dataflow graph processing
US20230006814A1 (en) * 2021-06-30 2023-01-05 Scality, S.A. Method and apparatus for implementing changes to a file system that is emulated with an object storage system
CN113742538A (zh) * 2021-07-16 2021-12-03 深圳云天励飞技术股份有限公司 基于图层级的业务分析方法、装置、电子设备及存储介质
CN113794579A (zh) * 2021-07-26 2021-12-14 奇安信科技集团股份有限公司 标签创建方法、装置、设备、系统与存储介质
US11888824B2 (en) * 2021-12-31 2024-01-30 Huawei Technologies Co., Ltd. Methods, apparatuses, and computer-readable storage media for secure end-to-end group messaging among devices using dynamic grouping
CN115378789B (zh) * 2022-10-24 2023-01-10 中国地质大学（北京） 一种多层次协作的流资源管理方法及系统
CN116257659A (zh) * 2023-03-31 2023-06-13 华中师范大学 一种智能导学系统的动态图嵌入方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515487A (en) * 1993-05-28 1996-05-07 International Business Machines Corporation Displaying partial graphs by expanding and collapsing nodes
US6711585B1 (en) * 1999-06-15 2004-03-23 Kanisa Inc. System and method for implementing a knowledge management system
CN1552072A (zh) * 2001-07-06 2004-12-01 ������������ʽ���� 记录设备与方法和通信设备与方法
CN101128825A (zh) * 2005-01-25 2008-02-20 特博数据实验室公司 树的检索、合计、排序方法、信息处理装置以及树的检索、合计、排序程序
CN101378325A (zh) * 2007-08-31 2009-03-04 华为技术有限公司 一种重叠网络及其构建方法
CN103262481A (zh) * 2010-12-17 2013-08-21 思科技术公司 有向无环图（dag）中的动态重路由调度

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701137A (en) * 1995-05-24 1997-12-23 Microsoft Corporation Method for separating a hierarchical tree control into one or more hierarchical child tree controls in a graphical user interface
JP3484096B2 (ja) * 1999-03-03 2004-01-06 インターナショナル・ビジネス・マシーンズ・コーポレーション 有向グラフの論理的ズーム装置における論理的ズーム方法
US7305401B2 (en) * 2000-03-09 2007-12-04 The Web Access, Inc. Method and apparatus for performing a research task by interchangeably utilizing a multitude of search methodologies
US6760721B1 (en) * 2000-04-14 2004-07-06 Realnetworks, Inc. System and method of managing metadata data
US7203701B1 (en) * 2002-02-20 2007-04-10 Trilogy Development Group, Inc. System and method for an interface to provide visualization and navigation of a directed graph
US7036044B1 (en) * 2002-11-15 2006-04-25 Microsoft Corporation Identifying appropriate undo during a forward pass through a log
US7308682B2 (en) * 2003-04-25 2007-12-11 Intel Corporation Method and apparatus for recovering data values in dynamic runtime systems
US7242413B2 (en) * 2003-05-27 2007-07-10 International Business Machines Corporation Methods, systems and computer program products for controlling tree diagram graphical user interfaces and/or for partially collapsing tree diagrams
JP4637113B2 (ja) 2003-11-28 2011-02-23 キヤノン株式会社 階層データの好ましいビューを構築するための方法
US7089511B2 (en) * 2003-12-10 2006-08-08 International Business Machines Corporation Framework for hierarchical VLSI design
US7818679B2 (en) * 2004-04-20 2010-10-19 Microsoft Corporation Method, system, and apparatus for enabling near real time collaboration on an electronic document through a plurality of computer systems
US7954083B2 (en) 2004-08-26 2011-05-31 Siemens Corporation System and method for specifying functional and non-functional requirements for a project
US7814427B2 (en) * 2005-01-05 2010-10-12 Microsoft Corporation Object model tree diagram
US7580918B2 (en) 2006-03-03 2009-08-25 Adobe Systems Incorporated System and method of efficiently representing and searching directed acyclic graph structures in databases
US9195665B2 (en) * 2006-04-28 2015-11-24 Hewlett-Packard Development Company, L.P. Method and system for data retention
US8312389B2 (en) * 2007-08-31 2012-11-13 Fair Isaac Corporation Visualization of decision logic
US8209211B2 (en) * 2008-03-18 2012-06-26 International Business Machines Corporation Apparatus and methods for requirements decomposition and management
US8677279B2 (en) 2009-05-06 2014-03-18 Business Objects Software Limited Visual hierarchy explorer
US8689180B2 (en) * 2009-11-03 2014-04-01 International Business Machines Corporation Systems and methods for resource leak detection
US9467344B2 (en) * 2010-03-26 2016-10-11 Bmc Software, Inc. Mechanism to display graphical IT infrastructure using configurable smart navigation
US8810576B2 (en) * 2010-04-13 2014-08-19 Microsoft Corporation Manipulation and management of links and nodes in large graphs
WO2012047201A1 (en) * 2010-10-05 2012-04-12 Hewlett-Packard Development Company, L.P. Acyclic graph navigator
US8788556B2 (en) * 2011-05-12 2014-07-22 Microsoft Corporation Matrix computation framework
US9336137B2 (en) * 2011-09-02 2016-05-10 Google Inc. System and method for performing data management in a collaborative development environment
US9053079B2 (en) * 2011-12-12 2015-06-09 Microsoft Technology Licensing, Llc Techniques to manage collaborative documents
US10268709B1 (en) * 2013-03-08 2019-04-23 Datical, Inc. System, method and computer program product for database change management
US9355088B2 (en) * 2013-07-12 2016-05-31 Microsoft Technology Licensing, Llc Feature completion in computer-human interactive learning
US9892185B2 (en) * 2014-08-19 2018-02-13 Projectwizards Gmbh Method and system for syncing data structures
US20160139901A1 (en) * 2014-11-18 2016-05-19 Qualcomm Incorporated Systems, methods, and computer programs for performing runtime auto parallelization of application code
US10409770B1 (en) * 2015-05-14 2019-09-10 Amazon Technologies, Inc. Automatic archiving of data store log data
GB201810392D0 (en) 2015-11-25 2018-08-08 Teamifier Inc Methods for the augmentation, exploration, and maintenance of project hierarchies

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5515487A (en) * 1993-05-28 1996-05-07 International Business Machines Corporation Displaying partial graphs by expanding and collapsing nodes
US6711585B1 (en) * 1999-06-15 2004-03-23 Kanisa Inc. System and method for implementing a knowledge management system
CN1552072A (zh) * 2001-07-06 2004-12-01 ������������ʽ���� 记录设备与方法和通信设备与方法
CN101128825A (zh) * 2005-01-25 2008-02-20 特博数据实验室公司 树的检索、合计、排序方法、信息处理装置以及树的检索、合计、排序程序
CN101378325A (zh) * 2007-08-31 2009-03-04 华为技术有限公司 一种重叠网络及其构建方法
CN103262481A (zh) * 2010-12-17 2013-08-21 思科技术公司 有向无环图（dag）中的动态重路由调度

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DAG-based multipath routing for mobile sensor networks;Ki-Sup Hong 等;《IEEE》;20111118;第261-266页 *
上下文认知计算技术研究;林祥涛;《中国博士学位论文全文数据库 信息科技辑》;20120115;I138-112 *

Also Published As

Publication number Publication date
WO2017091821A1 (en) 2017-06-01
US20170147709A1 (en) 2017-05-25
SE2251384A1 (en) 2022-11-28
US11222074B2 (en) 2022-01-11
JP6858983B2 (ja) 2021-04-14
SE2251384A2 (en) 2023-04-18
CN109121436A (zh) 2019-01-01
JP2019505877A (ja) 2019-02-28
SE1850784A1 (en) 2018-06-25
US20220058221A1 (en) 2022-02-24
GB201810392D0 (en) 2018-08-08
US11989170B2 (en) 2024-05-21
SE544816C2 (en) 2022-11-29
SE2251212A1 (en) 2022-10-15

Similar Documents

Publication Publication Date Title
CN109121436B (zh) 增广、探索、和维护项目分层结构的方法
Wang et al. Data x-ray: A diagnostic tool for data errors
Mäder et al. Towards automated traceability maintenance
US20050289524A1 (en) Systems and methods for software based on business concepts
Tupper Data architecture: from zen to reality
López et al. Modelset: a dataset for machine learning in model-driven engineering
Jayapandian et al. Expressive query specification through form customization
CN116097241A (zh) 使用语义角色的数据准备
US20190324767A1 (en) Decentralized sharing of features in feature management frameworks
Achichi et al. Automatic key selection for data linking
Elmeleegy et al. Leveraging query logs for schema mapping generation in U-MAP
Miao et al. ModelHUB: lifecycle management for deep learning
Oliveira et al. XChange: A semantic diff approach for XML documents
Peña et al. Ontology-quality Evaluation Methodology for Enhancing Semantic Searches and Recommendations: A Case Study.
CN115668127A (zh) 面向用户的电子表格编程语言
US20150066883A1 (en) Managing versions of cases
Zhu et al. Metadata Management with IBM InfoSphere Information Server
Koop Managing provenance for knowledge discovery and reuse
Carriero et al. Empirical ontology design patterns and shapes from Wikidata
Wątróbski Towards standardization in frameworks, tools and approaches dedicated to ontology building and management
Klein Architecture Practices for Complex Contexts
Biswas Modeling, analysis and simulation of near real-time ETL processes of big data in cloud
Bai Collaboration Support for the Distributed Development of Ontologies
Jasser et al. Reusing security solutions: a repository for architectural decision support
Manes Studying the Change History of Code Snippets on Stack Overflow and GitHub

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant