APECKS：支持活体本体的工具

1.1本体服务器

本体服务器提供了通过Internet在知识密集型应用程序中通用的本体。本节从处理服务器和用户之间交互的方式以及交互方式方面详细介绍和检查了许多这些本体服务器之间处理用户。

1.2协作知识

一些人认为，对于知识工程师来说，构建本体的主要目的是创建一个可用于所有可能的知识密集型应用程序的单一本体。然后，可以对这个完美的本体进行裁剪，以使用以下描述的技术来提供适合于特定任务或领域的知识库Swartout等人（1996年）是否可以建立单一的本体仍然是一个悬而未决的问题：或者，可以将较小的本体聚集在一起创建知识资源。无论使用哪种方法正确性和一致性需要支持为创建本体而进行的大规模协作。

理想情况下，实现一致且全面的本体的最简单方法是基于单个专家的知识。然而，在许多情况下，如果不是大多数情况下，一名专家是不够的，因为他们的知识可能是专业的、过时的或文化特定的，具有局限性。因此，需要多位专家来创建更大、更准确的图片。

不幸的是，专家们在目标、优先事项、意见和信念方面存在分歧。在创建“正确”本体论时，知识工程师的任务是从虚构的谷壳中筛选出事实上的小麦，并提取出有用知识的核心。总的来说对的知识被认为等同于双方同意的知识，因此知识工程师的任务变成了在专家的不同知识中找到共识。这导致了以下断言类型：Farquhar等人（1996年）根据定义，本体论代表共识知识：领域内使用的技术术语的单一公认定义。

可以说，知识工程师的专长在于根据许多专家的知识构建这些共识本体的艺术，并且有许多技术可以用于比较专家知识，例如Shaw&Gaines（1989）共识/冲突/通信/对比分类和男孩（1996）小组启发法。当专家之间出现分歧时，知识工程师充当谈判者，或者根据估计的可靠性选择要信任的来源。通过这种方式，知识工程师在构建一致的本体论中发挥着至关重要的作用。

然而，互联网上可访问的知识工程工具，以及在较小程度上通常是计算机辅助的工具，所期望的结果之一是，知识工程师需要的直接干预较少。专家可以在自己的时间内完成这些工作，而不是由知识工程师带领专家完成许多知识获取技术。本体服务器通常是为知识工程师设计的：它们也能被专家直接使用吗？

虽然允许专家直接访问本体为知识工程师节省了时间，但它也可能在创建共识本体时引发问题。如果没有知识工程师扮演中间人的角色，如何在这些系统中达成共识？不同的知识工程师如何就他们创建的本体达成共识，毕竟，这些本体可能是不同的？目前可用的本体服务器中的答案从免费的，任何用户都可以进行更改，到协商一致的系统，所有用户必须在进行更改之前达成一致。

在多用户本体的最基本管理级别上，可以通过使用本体所有者设置的用户和组读写权限来限制对本体的访问，就像在Ontolingua服务器中一样。这些权限可以通过使用概述的通信技术来支持在上面这使用户能够跟踪其他人正在进行的更改。

在Ontosaurus浏览器中(Swartout等人，1996年)，只有当更改与本体的其余部分一致时，才能由单个用户进行更改。这是因为LOOM表示语言内置的推理功能，可以防止构建不一致的本体。该工具不仅适用于多用户本体构建，还可用于检查单个用户的知识一致性。

有限公司₄（尤泽纳，1996年a&1996年b)在构建在同一本体上工作的个体之间的交互方面更进一步。本体构建在一个组知识库的层次结构中，每个知识库代表订阅该组的用户的共识知识。在层次结构的底部，每个用户都可以拥有许多知识库，他们可以随意更改这些知识库。当对组库提出更改建议时，订阅该建议的每个用户都会收到该建议的通知，并且可以接受或拒绝该建议。如果所有用户都接受该建议，则会更改组知识库，但如果单个用户反对，则不会以其当前形式进行更改。该程序模仿学术期刊的提交程序。个人用户也可以选择不接受对其个人知识库的任何更改，即使这些更改在组级别上被接受。

在Swartout等人（1996年）通过协作本体服务器，知识工程师能够熟悉领域，并从预先存在的本体构建初始知识库。这个本体可以被翻译成许多格式，例如KIF、LOOM或C++，供他们正在构建的系统使用。如果知识工程师有知识要添加到本体中，他们可以“签出”部分本体，更新它，然后“签回”。在这一点上，系统本身评估新知识与本体的先前版本的兼容性。其他用户可以查看知识库发生的更改的记录。

我们认为，专家直接使用这些系统的问题在于避免考虑原因他们之间缺乏共识。如前所述，个别专家的特征可能会对他们的决策产生隐性影响。做出这些隐含的差异明确的可以增强对领域的理解，而这是知识工程师的任务之一。在知识工程师不可用的情况下，如在这些本体服务器中，专家可能会争论一个特定的观点，因为更改被阻止或持续更改回来，而无法理解它们之间的真正差异。

我们的方法旨在使专家能够解决分歧的根源，并以富有成效的结果进行辩论。希望这种方法也能让使用本体服务器的知识工程师讨论他们的差异更加彻底，从而更好地理解本体设计所依据的标准。该方法在名为APECKS（协作知识结构自适应表示环境）的本体服务器中进行了实例化。

2.1个人本体

现有的本体服务器持有不相关的本体，这些本体只能被明确授予权限的人访问以进行更改。除此之外，优先考虑现有的事务状态，更改必须满足某些限制，例如与其他代表的一致性或所有其他合作者的同意。我们认为，这可能导致停滞和受限的本体论。

另一方面，APECKS基于个人本体，代表个人对领域的理解。创建这样的本体既快捷又容易，支持复制和修改其他人的全部或部分本体，任何人都可以创建它们。本体可以以不一致的状态存在于自身内部，也可以与其他个体的本体存在不一致，因此可以探究这些不一致的原因。在APECKS中创建本体的重点是改变和探索：头脑风暴过程。我们认为，这将导致动态和多样的本体论。

2.2网络资源的使用

虽然用户可以通过超文本界面或编程方式访问当前的本体服务器，但顾名思义，他们的重点是服务信息：他们不访问其他网络资源。另一方面，APECKS被视为客户以及访问网络可访问的知识获取应用程序和其他本体服务器的服务器。目前，它使用WebGrid（Gaines&Shaw，1996年a&1996年b)支持知识获取。未来，可以预见，APECKS将访问由其他本体服务器保存的本体，并像APECKS保存的其他个人本体一样使用这些本体。通过这种方式，APECKS将自己定位于互联网知识网络的中心。

2.3知识获取支持

现有本体服务器支持知识工程师在本体论的构建中。APECKS旨在支持领域专家，他们不一定是本体论构建方面的专家。APECKS目前自行进行基本知识获取。其他更复杂的技术可以在互联网可访问的工具中使用后，插入到APECKS中。WebGrid（Gaines&Shaw，1996年a&1996年b)例如，已经被用于支持APECKS内的剧目网格。

2.4设计原理

在线性通信媒体中，用户很容易知道什么时候发生了更改，什么时候向新闻组添加了帖子，什么时候有人说了什么。在超通信媒体中，通信是在评论和注释的超文本网络中构建的，用户很难识别哪些地方发生了更改。

已经开发出了时序感知工具，可以生成有关超文本结构变化的信息(Chen&Gaines，1996年)可以是客户端或服务器端。服务器端按时间顺序识别工具，如CHRONO(陈，1996)跟踪服务器上文件结构中文档的更改，并创建列出这些更改的页面。

更改在APECKS中非常重要，因此需要支持记录更改，记录原因并向用户提供明确的基本原理。当用户离开一段时间后返回系统时，系统会通知用户与个人本体相关的更改。可以对这些更改进行注释，给出更改背后的原因。其他用户稍后可以搜索此基本原理，以回答有关为什么采取某些操作的问题。

2.5结构化通信

然而，APECKS的真正创新在于通过比较用户的个人本体支持用户之间的协作。APECKS根据以下人员提出的共识/冲突/对应/对比分类，自动比较用户构建的个人本体Shaw&Gaines（1989）本体论不仅仅是从它们是否一致的角度进行比较，而是从它们之间的一致程度进行比较。

APECKS的用户会被提示在个人本体之间进行比较的基础上采取行动或相互交流。例如，如果一个本体根据岩石的“石英含量'而另一个以完全相同的方式这样做，但使用了术语'二氧化硅含量'，APECKS将这视为一种对应状态（同一概念使用不同的术语）。构建这些本体的用户将被提示要么更改术语以使其与另一个一致，要么开始讨论为什么使用不同的术语。

基于本体比较的讨论有两个有用的结果。首先，与域相关的详细信息被发现。在“石英含量“与”二氧化硅含量'，讨论将揭示较高的二氧化硅含量原因岩石中石英含量较高，否则可能会丢失细节。通过这种方式，构建了更丰富、更详细的本体。

讨论的第二个结果是，本体构建中使用的标准变得明确。在本例中，使用术语“石英含量“这可能是一种假设，即对现场地质学家来说，确定石英含量的程度更容易，从而估算出二氧化硅的百分比，这可能导致明确构建一个前提，例如“KBS的用户将是现场地质师”本体构建所依据的标准的明确陈述提供了关于其目的的元信息，而这些信息通常是隐含的。

3.1技术

APECKS基于可访问的多用户文本虚拟环境MOO（multi-user-domain-oriented；柯蒂斯，1992年). MOO的最初和主要目的是提供一种比重播聊天（IRC）更环保、比多用户地下城（MUD）更面向冒险的通信设施。这种有点不合常规的系统被用作APECKS的基础，原因如下：

面向对象数据库

MOO由两部分组成：定义每个MOO的面向对象数据库和解释并运行数据库文件的服务器程序。MOO的面向对象特性意味着面向对象表示，就像知识工程中使用的框架表示一样，使用起来非常简单。

互联网接入

MOO可以使用telnet协议通过互联网访问。用于打开、关闭和维护本体服务器所需计算机之间的连接的机制内置于MOO服务器程序中。一些MOO开发人员在此基础上构建了可用的MOO数据库，允许通过WWW查看和操作其中的对象。

可编程性和快速原型

MOO是编程环境。MOO数据库中的任何对象都可以编程为与用户或其他对象交互。因为这些程序是数据库本身的一部分，所以不必编译它们，从而实现快速原型制作。为了充当WWW服务器，可以对MOO进行编程以动态生成HTML。

多用户同步通信

MOO允许多个用户连接到它们，并使用基于文本的同步通信进行交互。内置于标准LambdaMOO数据库(柯蒂斯，1992年)是便于用户建模的用户表示，以及其他通信方法，如异步邮件。

对于APECKS，对标准LambdaMOO数据库进行了三次修改(柯蒂斯，1992年). 首先，APECKS数据库理解HTTP，因此既可以充当WWW服务器，也可以充当代理或网关角色时的WWW客户端。其次，APECKS数据库生成普通HTML（没有任何Java小程序或ECMAScript[6])动态地基于其内部对象表示，使用户能够使用WWW浏览器与对象交互。最后，向数据库中添加了许多“通用”对象，这些对象构成了知识表示模式APECKS使用。

3.2知识表示模式

APECKS是一个框架表示系统，它以框架本体定义的方式表示本体(Karp&Gruber，1997年). 使用框架本体定义的框架表示知识意味着APECKS系统内的表示与其他框架表示系统中的表示之间的转换可以通过本体语言和通用框架协议来实现(卡普、迈尔斯和格鲁伯，1995年,Karp&Gruber，1997年). 由于框架本体被用作Ontolingua中知识表示的基础，这也意味着网络可访问的Ontolingua本体可以无缝地结合到APECKS本体表示中。

APECKS知识表示的基础是个人它们分为类并且有插槽，它定义了值并且有刻面。它通过类层次结构处理多重继承，以便单个插槽的值可以从其类型（类）继承。插槽可以容纳许多不同类型的值，并且可以同时容纳多个值。APECKS中存在一些限制，因为知识表示仅用于概念证明：类层次结构主要由个人对类的成员身份决定，而不是由用户直接定义；用户无法定义方面或公理。总的来说，这些限制有助于非知识工程师的用户更容易理解和使用系统。

存储在APECKS数据库中的知识分为以下几个部分域这一划分是必要的，因为APECKS代表了许多由单个用户定义的本体，而不仅仅是一个域的单个本体。任何用户都可以在单个域中定义多个本体，表示域的不同方面或可能在其中执行的不同任务角色。没有一个定义的本体以Ontolingua共享会话的方式或Ontosaurus中的方式共享。相反，每个角色几乎都是完全独立的，与Co中的独立知识库类似₄.

然而，角色之间有一些重叠，因为相同的个人可以被划分为许多不同的角色。每个人都有唯一定义自己的信息槽，如姓名和描述，但个人的类成员身份、继承的槽以及这些槽的值可能因角色而异。两个或多个角色之间的相似性和差异的表示称为比较：有关这些方面的详细讨论，请参阅本体比较，如下所示。

在对本体进行编码的对象之上，还有便于讨论的对象。这些对象有两种类型：标准是关于特定事态原因的简短、笼统的断言；和注释这是一个较长的讨论，有时会有多个作者参与。有关这些方面的详细讨论，请参阅APECKS内部的通信，如下所示。

3.3本体浏览

存储在APECKS中的本体可以通过WWW浏览，也可以在将来通过MOO中基于文本的虚拟环境界面浏览。

4.1播种

播种过程是一个简短的阶段，在此阶段，系统将使用信息来启动协作过程。用户社区可以在这个阶段获得身份，或者稍后自动创建自己的身份。下一步是创建一个对象来保存整个域的信息。

然后创建域中的个人，并为其提供姓名、描述以及个人图像的URL（如果适用）。这些构成了系统其他用户构建角色的基础。其他用户可以根据需要创建个人来提供额外的示例：初始集只是一个起点。

如果播种域的用户对如何设计域中的角色有很好的想法，他们也可以创建一组标准来向该方向提示其他用户。有关标准目的的更多信息，请参阅以下章节讨论本体论.

4.2本体构建

第二个阶段是个体用户构建本体的阶段，它贯穿于系统的整个生命周期。用户首先构造一个角色来表示他们对域及其内个人的个人视图。在该角色中，他们可以根据自己的视图自由地对域内的任何或所有个人进行分类。

APECKS通过允许知识工程师显式创建新的个人、类和槽并为其分配属性，支持知识工程师的本体构建过程。然而，由于APECKS也旨在供非本体构建专家使用，因此在内部和外部都会以WebGrid的形式提供额外的知识获取支持（Gaines&Shaw，1996年a&1996年b).

4.3本体比较

一旦角色至少部分构建好，就可以开始比较它们以找出专家之间的差异。角色之间的比较是使用以下人员阐述的共识/冲突/对应/对比分类进行的Shaw&Gaines（1989）表1显示了概念结构之间关系的四种分类。

表1：专家之间的共识、冲突、通信和对比。发件人Shaw&Gaines（1989）.

		术语
		相同	不同
属性	相同	共识 专家以同样的方式使用术语和概念	通信 专家对相同的概念使用不同的术语
	不同	冲突 专家对不同的概念使用相同的术语	对比度 专家们在术语和概念上有所不同

上述分类旨在用于储备网格，该网格具有扁平结构，其中每个元素对每个构造都有评级。本体之间的关系比网格之间的关系更复杂。首先，本体中定义的一些槽可能不包含适合比较的值：这些是唯一定义个体的“关键”值，例如个体的名称或描述。其次，更重要的是，本体中的元素不仅由它们在插槽中的值定义，还由它们在类层次中的位置定义。

在不同的角色中表示类结构有两种方式可以比较：

1. 根据角色或布尔评级量表中所代表的个人的分类槽来重新记录阶级结构，布尔评级量表代表个人是否是阶级的成员。
2. 根据实例比较本体中定义的类。与槽（术语）的名称及其在个人（属性）上的值一样，它们可以表示专家之间的共识、冲突、通信或对比，类（术语）及其实例（属性）的名称也可以表示一致性、冲突、对应或对比。如果在两个角色中，有两个类的名称相同，并且与成员具有相同的实例，则表示专家之间的通信。如果在两个角色中，有两个类不命名相同，但与成员具有相同的实例集，这表示专家之间的通信。类似地，如果有两个类的名称相同，并且作为成员的实例集不同，则表示冲突。术语或实例集没有重叠表示对比。

APECKS支持这两种比较类层次结构的方法，并支持通过将角色转换为网格并使用WebGrid-II来比较插槽和插槽值，其方式与上面在使用WebGrid获取知识.

这些比较的结果是显示了多个页面，这些页面指示了角色之间的比较，并提示用户采取行动来探索角色之间的任何差异。目前，在WebGrid或其他类似系统对其比较进行编程分析之前，用户只会得到有关被比较角色中类层次结构的提示。然后，他们可以更改自己角色中类的名称或实例，或者编写注释来证明他们选择使用的层次结构的合理性。

图2显示了页面的一部分，其中详细说明了两个角色之间的类结构差异。图3显示了两个角色的WebGrid-II比较。这两个数字都来自两个角色的比较：一个基于为西西弗斯三世实验（“金本位“角色”），另一个在示例中使用的相同材料上盖恩斯和肖（1996a）（“WebGrid示例'角色）。

共识类 以下类具有相同的名称并包含相同的实例，显示了共识在角色之间。 岩石 在这两个角色中WebGrid示例（由RJP公司)和金本位（由珍妮)，rocks类包含以下实例： 安山岩 玄武岩 闪长岩 辉长岩 花岗岩 花岗闪长岩 橄榄岩 流纹岩 操作： 编辑金标准中的岩石名称 更改金标准中的岩石实例 比较金标准和WebGrid示例下的岩石实例分类 对应的类 以下类包含相同的实例，尽管它们具有不同的名称，显示了通信在角色之间。 细晶粒度（英寸WebGrid示例通过RJP公司)和小颗粒（英寸金本位通过杰尼) 这些类都包含实例： 安山岩 玄武岩 流纹岩 操作： 编辑小颗粒的名称 创建注释，解释为什么使用“小颗粒”这个名称。 更改小颗粒的实例 …从示例中剪切的其他相应类。。。 对比类 以下类与其他类没有相同的名称，也没有相同的实例，显示了对比在角色之间。 酸性岩石（英寸金本位通过杰尼) 不与所比较角色中的任何类共享名称或实例。 操作： 编辑酸性岩石的名称 更改酸性岩石的实例 移除酸性岩石（回收） …从示例中剪切出的其他对比类。。。 图2：从比较两个角色中的类结构的页面中提取，删除链接目标。

如图所示图2，向用户提供角色中类之间相似程度的分类。此处未显示的分类是，当比较角色中的类共享相同的名称但具有不同的实例时，会发生“冲突”。当发生这种情况时，会向用户显示一个表，其中显示了每个角色中类中的实例以及这两个角色中的实例。无论类属于哪一类，都会提示用户更改其名称或实例，或者在必要时开始讨论差异。在上面的示例中，单击提示“创建一个注释，解释为什么使用“small grain”这个名称。”金本位'要启动的角色异步非结构化通信关于类的命名。

图3：从通过APECKS生成的两个角色的WebGrid比较中提取。（单击可查看完整图像。）

图3说明了通过WebGrid-II对相同角色之间的通信进行分析的结果。它还有效地说明了在APECKS维护的更丰富的知识结构和WebGrid使用的更平坦的知识结构之间进行转换所涉及的问题。为了使用WebGrid，将类成员和具有多个值的槽转换为布尔评级尺度。网格中的以下行特别说明了所涉及的问题：

• 第一行图3显示类之间的通信细粒度'在'WebGrid示例'角色和类'小颗粒'在'金本位'角色。如上述页面摘要所示，该信函也由APECKS识别(图2).
• 第八排图3显示了表示相同信息的不同方式是如何相互对应的。在“WebGrid示例“作用，硅含量在1（高硅含量）到9（低硅含量）的评级范围内进行编码，而在”金本位'角色，相应的信息表示为三个独占子类，'酸的', '中间的'和'基本的'.
• 第九行和第十三行说明了用户如何选择不同的插槽编码方式。在'WebGrid示例“角色，岩石的颜色按照从1（“浅色的'）至9（'黑暗-黑社会'）而在'金本位‘角色，对应的槽是明确的，有三个可能的值’黑手党的（黑暗的）', '中庸（中等）'和'浅色（光）'.
• 第十行说明了以这种方式比较角色如何表明可能会丢失的因果知识。碱性长石的存在，编码于金本位“角色与岩石的颜色有关，编码在”WebGrid示例'角色。
• 这两个角色之间的一些对应关系表明“金本位'角色。例如，第二行可能表明斑状结构的岩石被归类为“细晶粒度'在'WebGrid示例'角色。
• 然而，许多行，如第三行到第七行，提供的信息对进一步理解该领域没有多大用处。这些行显示了对应关系，这些对应关系似乎是将具有多个值的插槽转换为WebGrid构造的方式以及用于比较它们的技术的人工制品。在'金本位'角色，插槽'存在矿物质'列出了岩石中的矿物。为了进行比较，将槽转换为多个布尔评级尺度结构，以指示岩石中是否存在每种矿物。这导致构造在所有元素中都具有相同的值。

4.4讨论本体

由于APECKS旨在促进用户之间的通信，因此它支持一系列协作方式尤为重要。个体之间的通信可以分为异步通信或同步通信，其中同步通信要求参与者至少在时间上是共存的，而异步通信则不然。沟通也可以根据结构强加给参与者的程度进行分类。在结构化沟通中，如协调员中(温诺格拉德，1988年)每个话语的目的都是由参与者指定的，他们被要求遵循通常基于言语行为理论的交流方式。在The Coordinator中，系统提示其用户相互发送特定类型的电子邮件，以响应发送给他们的类型。系统进行结构化通信不作为一个中介，要求参与者理解管理他们交流的显性或隐性规则，例如在文字游戏或婚礼上。

APECKS中的讨论通常是两个角色之间比较的结果：用户应该为以他们现有的方式创建本体而争论。APECKS支持存档通信中同步性和结构的四种组合中的三种(非结构化同步通信,非结构化异步通信、和结构化异步通信)通过使用注释或条件对象将对象彼此关联。