protege系列（⼀）：本体开发101：创建第⼀个本体的指南
protege作为领域本体编辑⼯作⼀直为⾃然语⾔处理和语义⽹、知识图谱等⾏业⼈⼠喜爱，但是还没有⽐较完整的官⽅Protege中⽂⽂档，本系列旨在通过对protege官⽅⽹站上教程等内容的翻译和再现，为⼴⼤⽹友提供⼀个全⾯的、权威的protege教程。
本体开发101：创建第⼀个本体的指南
娜塔莉亚·诺伊（Natalya F. Noy） 和黛博拉·麦坚尼斯（Deborah L.
斯坦福⼤学，斯坦福，CA，94305
noy@smi.stanford.edu 和 dlm@ksl.stanford.edu
1 为什么要开发⼀个本体？
近年来，本体的发展（对领域中术语的明确规范以及它们之间的关系（Gruber 1993））已经从⼈⼯智能实验室的领域转移到领域专家的桌⾯。本体在万维⽹上已经很普遍。Web上的本体包括从对⽹站进⾏分类的⼤型分类法（例如在Yahoo!上）到要销售的产品及其功能的分类（例如在Amazon上）。WWW联盟（W3C）正在开发资源描述框架（Brickley和Guha，1999年），该语⾔⽤于对⽹页上的知识进⾏编码，以使电⼦代理商可以轻松地搜索信息。 国防⾼级研究计划局（DARPA）与W3C⼀起，通过扩展RDF并使⽤更具表现⼒的结构来开发DARPA代理标记语⾔（DAML），旨在促进Web上的代理交互（Hendler和McGuinness 2000）。现在，许多学科都在开发标准化的本体，领域专家可以使⽤它们来共享和注释其领域中的信息。例如，医学已经产⽣了⼤型的，标准化的，结构化的词汇，例如SNOMED （Price和Spackman 2000）和统⼀医学语⾔系统的语义⽹络（Humphreys and Lindberg 1993）。⼴泛的通⽤本体也正在兴起。例如， 联合国开发计划署和Dun＆Bradstreet共同努⼒，开发了UNSPSC本体，该本体为产品和服务提供了术语
（）。
本体为需要在域中共享信息的研究⼈员定义了通⽤词汇表。它包括领域中基本概念的机器可解释的定义以及它们之间的关系。
为什么有⼈要开发⼀个本体？⼀些原因是：
· 在⼈员或软件代理之间共享对信息结构的共识
· 能够重⽤领域知识
· 明确领域假设
· 将领域知识与运营知识区分开
· 分析领域知识
在⼈或软件代理之间共享对信息结构的 共识是开发本体论的较常见⽬标之⼀（Musen 1992； Gruber 1993）。例如，假设⼏个不同的⽹站包含医疗信息或提供医疗电⼦商务服务。如果这些⽹站共享并发布它们全部使⽤的术语的相同基础本体，则计算机代理可以从这些不同的⽹站中提取和聚合信息。代理可以使⽤此汇总信息来回答⽤户查询或作为其他应⽤程序的输⼊数据。
启⽤领域知识的重⽤是最近本体研究激增的驱动⼒之⼀。例如，许多不同领域的模型需要表⽰时间的概念。此表⽰形式包括时间间隔，时间点，时间的相对度量等概念。如果⼀组研究⼈员详细开发了这种本体，那么其他研究⼈员可以简单地将其重新⽤于他们的领域。另外，如果我们需要构建⼀个⼤型
本体，我们可以集成⼀些描述⼤型域各部分的现有本体。我们还可以重⽤通⽤的本体，例如UNSPSC本体，并将其扩展以描述我们感兴趣的领域。
如果我们对领域的了解有所变化，则在实现基础上进⾏明确的领域假设就可以轻松更改这些假设。关于编程语⾔代码世界的硬编码假设使这些假设不仅难以发现和理解，⽽且难以更改，尤其是对于没有编程专业知识的⼈。此外，明确的领域知识规范对于必须了解领域术语含义的新⽤户很有⽤。
将领域知识与操作知识分开是本体的另⼀种常见⽤法。我们可以描述根据所需规范从其组件配置产品的任务，并实现⼀个独⽴于产品和组件本⾝进⾏此配置的程序（McGuinness和Wright 1998）。然后，我们可以开发PC组件和特性的本体，并应⽤该算法来配置定制PC。如果我们将电梯组件本体“馈⼊”到电梯中，我们也可以使⽤相同的算法来配置电梯（Rothenfluh et al。1996）。
⼀旦可以使⽤术语的声明性规范，就可以分析领域知识。 当试图重⽤现有本体并扩展它们时，术语的形式分析⾮常有价值（McGuinness et al。2000）。
通常，领域的本体本⾝并不是⽬标。开发本体类似于定义⼀组数据及其结构以供其他程序使⽤。解决问题的⽅法，与领域⽆关的应⽤程序和软件代理使⽤从本体构建的本体和知识库作为数据。例如，在本⽂中，我们开发了葡萄酒和⾷物的本体以及葡萄酒和餐⾷的适当组合。然后，可以将此本体⽤作⼀套餐厅管理⼯具中某些应⽤程序的基础：⼀个应⽤程序可以为当天的菜单创建葡萄酒建议或回答服务
员和顾客的查询。另⼀个应⽤程序可以分析酒窖的库存清单，并建议扩展哪些酒类别以及为即将来临的菜单或菜谱购买哪些特定酒。
关于本指南
我们基于Protégé-2000 （Protege 2000），Ontolingua （Ontolingua 1997）和Chimaera （Chimaera 2000）作为本体编辑环境的经验。在本指南中，我们以Protégé-2000为例。
我们在本指南中始终使⽤的葡萄酒和⾷品⽰例⼤致基于本⽂中描述CLASSIC的⽰例知识库-基于描述逻辑⽅法的知识表⽰系统（Brachman 等，1991）。CLASSIC教程（McGuinness等，1994）进⼀步开发了此⽰例。Protégé-2000和其他基于框架的系统以声明⽅式描述了本体，并明确说明了类层次结构以及个⼈所属的类。
本指南中的⼀些本体设计思想源于有关⾯向对象设计的⽂献（Rumbaugh等，1991； Booch等，1997）。但是，本体开发不同于⾯向对象程序设计中的类和关系设计。⾯向对象的程序设计主要围绕类的⽅法—程序员根据类的操作属性做出设计决策，⽽本体设计者则根据类的结构属性做出决策。结果，本体中的类结构和类之间的关系不同于⾯向对象程序中类似域的结构。
⽆法涵盖本体开发⼈员可能需要解决的所有问题，因此我们在本指南中并未尝试解决所有问题。相反，
我们尝试提供⼀个起点。可以帮助新的本体设计者开发本体的初始指南。最后，如果领域需要它们，我们建议地⽅寻对更复杂的结构和设计机制的解释。
最后，没有⼀种正确的本体设计⽅法，我们也没有尝试定义⼀种⽅法。我们在这⾥提出的想法是在我们⾃⼰的本体开发经验中发现有⽤的想法。在本指南的最后，我们建议了替代⽅法的参考列表。
2 本体是什么？
⼈⼯智能⽂献包含本体的许多定义。其中许多相互⽭盾。在本指南中，本体是对话语领域（类（有时称为概念））中的概念的正式显式描述，每个概念的属性描述了概念的各种特征和属性（插槽 （有时称为⾓⾊或属性） ）以及对插槽的限制（构⾯（有时称为⾓⾊限制））。本体与⼀组单独的类实例⼀起构成⼀个知识库。实际上，在本体结束和知识库开始之间存在⼀条界限。
类是⼤多数本体的重点。类描述领域中的概念。例如，⼀类葡萄酒代表所有葡萄酒。特定的葡萄酒是此类的实例。阅读本⽂时，杯中 的波尔多葡萄酒是波尔多葡萄酒的⼀个实例。⼀个类可以具有表⽰⽐超类更具体的概念的⼦类。例如，我们可以将所有葡萄酒分为红葡萄酒，⽩葡萄酒和桃红葡萄酒。另外，我们可以将所有葡萄酒分为起泡酒和⾮起泡酒。
槽⼝ 描述了类和实例的属性： 拉菲堡罗斯柴尔德波雅克酒具有完整的酒体；它由拉菲酒庄（Château
Lafite Rothschild）酒庄⽣产。在此⽰例中，我们有两个描述葡萄酒的位置：具有完整值的位置主体和具有ChâteauLafite Rothschild酒庄价值的位置制造商。在类级别，我们可以说，Wine类的实例 将具有描述其味道， 主体， 糖 ⽔平， 葡萄酒制造商等的位置。[1]
Wine类及其⼦类Pauillac的所有实例都有⼀个⽼虎机制造者， 其值是Winery类的⼀个实例（图1）。Winery类的所有实例都有⼀个插槽产品 ，该插槽引⽤了该酿酒⼚⽣产的所有葡萄酒（Wine及其⼦类的实例）。
实际上，开发本体包括：
· 在本体中定义类，
· 以分类（⼦类-超类）层次结构安排类，
· 定义插槽并描述这些插槽的允许值，
· 填写实例的插槽值。
然后，我们可以通过定义这些类的各个实例来填充特定的插槽值信息和其他插槽限制，从⽽创建知识库。
图1。 葡萄酒领域中的某些类，实例以及它们之间的关系。 我们将⿊⾊⽤于类，将红⾊⽤于实例。直接链接表⽰插槽和内部链接，例如instance-of和subclass-of。
3 ⼀种简单的知识⼯程⽅法
正如我们之前所说，没有⼀种“正确”的⽅法或⽅法来开发本体。在这⾥，我们讨论要考虑的⼀般问题，并提供了⼀种开发本体的可能过程。我们描述了⼀种⽤于本体开发的迭代⽅法：我们从对本体的初步了解开始。然后，我们修改和完善不断发展的本体，并填写详细信息。在此过程中，我们讨论了设计⼈员需要做出的建模决策，以及不同解决⽅案的利弊。
⾸先，我们想强调本体设计中的⼀些基本规则，我们将多次参考这些规则。这些规则似乎很教条。但是，它们可以在许多情况下帮助您做出设计决策。
1） 没有⼀种正确的域建模⽅法-总是有可⾏的替代⽅案。最佳解决⽅案⼏乎总是取决于您所考虑的应⽤程序和预期的扩展。
2） 本体开发必然是⼀个迭代过程。
3） 本体中的概念应与您感兴趣的领域中的对象（物理或逻辑）和关系紧密。这些最有可能是描述您的域的句⼦中的名词（宾语）或动词（关系）。
开发网站需要什么软件
也就是说，决定我们将使⽤本体的⽬的以及本体的详细程度或通⽤程度将指导许多建模决策。在⼏种可⾏的选择中，我们将需要确定哪种⽅法更适合计划的任务，更直观，更可扩展且更易于维护。我们还需要记住，本体是世界现实的模型，本体中的概念必须反映这⼀现实。在定义了本体的初始版本之后，我们可以通过在应⽤程序或解决问题的⽅法中使⽤它或与本领域的专家进⾏讨论，或者两者兼⽽有之，来对其进⾏评估和调试。结果，我们⼏乎肯定会需要修改初始本体。
步骤1. 确定本体的范围和范围
我们建议通过定义领域和范围来开始开发本体。也就是说，回答⼏个基本问题：
· 本体将涵盖的领域是什么？
· 对于 我们将使⽤本体的东西？
· 对于哪种类型的问题，本体中的信息应提供答案？
· 谁将使⽤和维护本体？
这些问题的答案可能会在本体设计过程中发⽣变化，但是在任何给定的时间，它们都有助于限制模型的范围。
考虑⼀下我们前⾯介绍的葡萄酒和⾷物的本体。⾷物和葡萄酒的表⽰是本体论的领域。我们计划将此本体⽤于建议葡萄酒和⾷品良好搭配的应⽤程序。
⾃然地，描述不同类型的葡萄酒，主要⾷物类型，葡萄酒与⾷物的良好组合以及不良组合的概念将成为我们的本体。同时，本体不⼤可能包含⽤于管理酒⼚或饭店员⼯库存的概念，即使这些概念在某种程度上与葡萄酒和⾷物的概念相关。
如果我们正在设计的本体将⽤于协助葡萄酒杂志中⽂章的⾃然语⾔处理，则在本体中包含概念的同义词和词性信息可能很重要。如果本体将⽤于帮助餐厅客户决定订购哪种酒，我们需要包括零售定价信息。 如果将其⽤于购酒者库存酒窖，则可能需要批发价格和供货情况。 如果维护本体的⼈员使⽤与本体⽤户的语⾔不同的语⾔来描述域，则可能需要提供这些语⾔之间的映射。
能⼒问题。
确定本体论范围的⼀种⽅法是草绘⼀系列基于本体论的知识库应该能够回答的问题，即能⼒问题 （Gruninger和Fox 1995）。这些问题将在稍后⽤作⽯蕊测试：本体是否包含⾜够的信息来回答这些类型的问题？答案是否需要特定级别的细节或特定区域的表⽰形式？这些能⼒问题仅是⼀个草图，不需要详尽。
在葡萄酒和⾷品领域，以下是可能的能⼒问题：
· 选择葡萄酒时应考虑哪些葡萄酒特性？
· 波尔多是红葡萄酒还是⽩葡萄酒？
· ⾚霞珠与海鲜搭配得很好吗？
· 烤⾁⽤葡萄酒的最佳选择是什么？
· 葡萄酒的哪些特性会影响其对菜肴的适合性？
· 特定年份的酒⾹或酒体会随着年份的变化⽽变化吗？
· 纳帕仙粉黛的最佳年份是什么？
从这个问题列表中判断，本体将包括有关各种葡萄酒特性和葡萄酒类型，年份（好坏）的信息，这些葡萄酒的分类对选择合适的葡萄酒⾄关重要，推荐的葡萄酒和⾷物组合。
步骤2. 考虑重⽤现有的本体
⼏乎总是值得考虑别⼈做了什么，并检查我们是否可以针对特定领域和任务优化和扩展现有资源。如果我们的系统需要与已经承诺使⽤特定本体或受控词汇表的其他应⽤程序进⾏交互，则可能需要重⽤
现有本体。 许多本体已经可以电⼦形式获得，并且可以导⼊到您正在使⽤的本体开发环境中。表⽰本体的形式主义通常并不重要，因为许多知识表⽰系统可以导⼊和导出本体。即使知识表⽰系统不能直接⽤于特定形式主义，将本体从⼀种形式主义转换为另⼀种形式主义的任务通常也不是⼀件容易的事。
例如，法国葡萄酒的知识库可能已经存在。如果我们可以导⼊此知识库及其基础知识，那么我们不仅将获得法国葡萄酒的分类，⽽且还将获得⽤于区分和描述葡萄酒的葡萄酒特征分类的第⼀步。葡萄酒属性列表可能已经可以从商业⽹站（例如www.wines）上获得 ，客户可以将其⽤于购买葡萄酒。
但是，对于本指南，我们将假定不存在相关的本体，并从头开始开发本体。
步骤3. 列举本体中的重要术语
写下所有我们希望对⽤户做出陈述或向⽤户解释的术语的列表很有⽤。我们想谈什么？这些条款具有哪些属性？我们想对这些条款说些什么？例如，与葡萄酒有关的重要术语将包括葡萄酒，葡萄，酿酒⼚，位置，葡萄酒的颜⾊，酒体，风味 和含糖量；不同类型的⾷物，如鱼和红⾁ ; 葡萄酒的亚型，例如⽩葡萄酒， 等等。最初，重要的是要获得术语的全⾯列表，⽽不必担⼼它们表⽰的概念之间的重叠，术语之间的关系或概念可能具有的任何属性，或者这些概念是类还是插槽。
接下来的两个步骤（开发类层次结构和定义概念（插槽）的属性）紧密地交织在⼀起。很难先做⼀个，然后再做另⼀个。通常，我们在层次结构中创建⼀些概念定义，然后 继续描述这些概念的属性，依此类推。这两个步骤也是 本体设计过程中最重要的步骤。我们将在这⾥简要描述它们，然后在接下来的两个部分中讨论需要考虑的更复杂的问题，常见的陷阱，做出的决定等等。
步骤4. 定义类和类层次结构
建⽴类层次结构有⼏种可能的⽅法（Uschold和Gruninger 1996）：
· ⼀个⾃上⽽下的发展过程开始的域和的概念，随后专业化的最⼀般的概念的定义。例如，我们可以从创建Wine 和Food的⼀般概念的类开始。然后，我们 通过创建其⼦类来专门研究Wine类：⽩葡萄酒，红葡萄酒，桃红葡萄酒。我们可以将红酒 类进⼀步分类，例如，西拉，勃⾉第红葡萄酒，⾚霞珠等。
· ⼀个⾃下⽽上的发展过程从最具体的类别，层次结构的叶⼦，这些类的后续分组定义成更⼀般的概念。例如，我们⾸先定义波雅克 和玛歌 葡萄酒的类。然后，我们为这两个类（Medoc）创建⼀个公共超类，⽽该类⼜是Bordeaux的⼦类。
· ⼀个组合的发展过程是⾃上⽽下和⾃下⽽上的⽅法的组合：我们⾸先定义了更加突出的概念，然后概括和适当的专门它们。我们可能从⼀些顶级概念（例如Wine）和⼀些特定概念（例如Margaux）开始 。
然后，我们可以将它们与诸如Medoc之类的中级概念相关联。 然后，我们可能想从法国⽣成所有区域葡萄酒类，从⽽⽣成许多中级概念。
图2 显⽰了不同普遍性级别之间的细分情况。
图2。葡萄酒 分类的不同层次：葡萄酒， 红葡萄酒，⽩葡萄酒，桃红葡萄酒是更⼀般的概念，即最⾼层次。波雅克 和玛歌 是层次结构中最具体的类别，即最底层。
这三种⽅法在本质上都不⽐其他任何⼀种更好。采取的⽅法在很⼤程度上取决于域的个⼈观点。如果开发⼈员对域有系统的⾃顶向下视图，则使⽤⾃顶向下⽅法可能会更容易。对于许多本体开发者来说，组合⽅法通常是最简单的，因为“中间”的概念往往是该领域中更具描述性的概念（Rosch 1978）。
如果您倾向于先区分最⼀般的分类来考虑葡萄酒，那么⾃上⽽下的⽅法可能会更好。如果您希望从具体⽰例⼊⼿，那么⾃下⽽上的⽅法可能更合适。
⽆论选择哪种⽅法，我们通常都从定义类开始。从步骤3中创建的列表中，我们选择描述具有独⽴存在的对象的术语，⽽不是描述这些对象的术语。这些术语将成为本体中的类，并将成为类层次结构中的基础。[2]通过询问是否作为⼀个类的实例，该对象是否必然（即根据定义）是某个其他类的实例，从⽽将这些类组织为分层分类法。
如果类A是类B的超类，则B的每个实例也是A的实例
换句话说，B类代表的概念是A的“⼀种”。
例如，每种⿊⽐诺葡萄酒都⼀定是红酒。因此，⿊⽪诺（Pinot Noir）类是红酒类的⼦类。
图2 显⽰了Wine本体的部分类层次结构。第4节 详细讨论了在定义类层次结构时要寻的内容。
图3。Wine类的插槽 和这些插槽的构⾯。⼚商 插槽旁边的“ I”图标表⽰该插槽具有反字符（第5.1节）
步骤5. 定义类的属性-插槽
仅这些课程将⽆法提供⾜够的信息来回答步骤1中的能⼒问题。⼀旦定义了⼀些类，就必须描述概念的内部结构。
我们已经从步骤3中创建的术语列表中选择了类。其余⼤多数术语可能是这些类的属性。这些术语包括，例如，葡萄酒的颜⾊，酒体，风味和糖分含量以及 酒⼚的位置。
对于列表中的每个属性，我们必须确定其描述的类。这些属性成为附加到类的插槽。因此，Wine 类将具有以下位置：颜⾊，主体， 风味和糖。酒庄 课程将有⼀个位置 栏。
通常，有⼏种类型的对象属性可以成为本体中的插槽：
· “内在”特性，例如 葡萄酒的味道；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。