Ontology的概念最初起源于哲学领域，可以追溯到公元前古希腊哲学家亚里士多德（384-322b.c.）尝试对世界上的事物分类，在哲学中定义为“对世界上客观存在物的系统地描述，即存在论”[1]。牛津英语词典定义为“存在的科学或研究”。当不同的理论家提出本体的不同建议，或者不同的知识领域谈论本体建议时，应该使用本体的复数即本体论（ontologies）以便表示总的本体集合[21]。
信息系统和哲学之间的关系好像永远是两个不同的国度，每个都有自己的语言和文化。事实上两者各自的研究方向是相互正交的，但今天，哲学的分支――本体论可以充当连接信息系统和哲学之间的桥梁，尽管本体论在信息系统中的作用好像与哲学中的作用完全不同[79]。信息系统需要推理世界模型，因此研究者采用术语‘本体’在程序中描述表示世界的信息。
信息系统本体论是表述特殊知识领域的形式语言；而哲学本体论解释世界某些领域不依赖于任何特定语言的特殊分类系统，尽管运用语言的概念机制作为描述手段，但却既不可约也不等同于语言或形式体系。与信息系统本体论相似，哲学本体论确实解释研究领域的知识和概念框架，主要目的是预先忠实的描述，即寻求真理。无论存在着何种区别，哲学本体论仍能对概念化的框架和信息系统本体论的开发做出一定的贡献，最大贡献是发现研究领域中某些事实，即领域的本性、范围、边界和独特性[79]。
为了澄清信息系统领域对本体的概念，1995年意大利Padova大学的Guarino等人[129]对不同概念解释进行深入分析，给出基本得到领域认同的概念，即“某些方面概念化的明确解释或表示”。此定义不是最终的标准定义，但却符合大多数普通的标准用法，对信息系统具有理论指导意义。
1998年Guarino[76]认为Gruber的本体定义仅指出了领域中普通的数学关系，即反映事物特殊状态的外延关系，却没有清楚地区别本体和概念化。为了明确独立于事物状态的关系的意思，需要引入统称为概念关系的内涵关系。并把本体定义为“解释形式词汇的指定意思的逻辑理论”，也就是世界的特殊概念化，这里的概念化指的是领域空间定义的一组概念关系，包含着领域空间中对象之间所有可能关系的意思解释。
但是这两种本体定义都没有涉及跨学科，况且Gruber的本体定义太含糊，而Guarino的本体定义对推理原理又模棱两可。这就需要在‘形式化’和‘逻辑理论’之间进行折衷，因此信息系统本体论应该是“特定的形式语言产生的清晰公理理论”[79]，本体论的粒度越细含有的公理也就越多。该本体论至少用于一个特殊且实际的应用，并能描绘特定对象领域的结构，还能解释研究领域中系统使用的形式词汇或协议的指定意思。
尽管信息系统中各领域对术语‘本体’的理论解释还存在着很多矛盾和问题，但是本体论已成为信息系统专业语言的必要组成部分，并在信息交换时起到至关重要的作用，因此信息系统研究者在多数情况下已经基本认同这种歧义状况的存在，并用其表示系统中隐含（或不明确的）信息，以便使能知识的共享和复用。
通过把术语‘概念化’指定到哲学领域，使得信息系统和哲学领域的本体论尽管都共享同一概念化，但却使用不同的词汇。本体和概念化的清晰分离有助于表达本体的共享、熔合和转换等问题，这暗示存在着多种表示语言和多角度的世界观，因此就需要适当的形式化定义[76]以便使得本体（指定模型）和概念化之间的关系更清楚。
定义1：域空间结构，其中D是领域，W是D中最大事物状态（或可能世界）的集合。
定义2：n元概念关系，域空间上的n元概念关系是从集合W到域D中所有n元关系集合的映射，即全函数。
定义3：概念化，域D的概念化是一个有序三元组，其中是域空间中概念关系的集合。
定义4：逻辑语言L的内涵解释，其中概念化，而函数是把域D的元素赋予语言词汇V的常量符号，并把集合的元素赋予词汇V的谓词符号。
语言L的内涵解释也称为本体论承诺。如果K是语言L的本体论承诺，那么语言L通过K承诺概念化C。语言L的预计模型通常不必反映特殊的世界，没有真正描述词汇的意思，因此只能表达世界概念化的外延关系，没法从模型集合中重构L的内涵关系，即本体论承诺K。给定带有本体论承诺K的语言L，L的本体论是解释形式词汇的指定意思的逻辑公理集，此集合使得L的模型集合尽可能完美地近似于L依据K的预计模型。事实上很难发现合适的公理集，因此语言L的本体论近似于世界的概念化C，如果存在一个本体论承诺K，使得L依据K的预计模型被包含于本体论模型之中。
任何逻辑理论都隐含自身的本体论，该本体论包含理论假定存在的所有事情，因此逻辑理论是本体中所有实体存在的本体论承诺。Quine[99]首先从逻辑和哲学的角度研究本体论承诺，规定在逻辑理论中的每个术语都将成为该理论的本体；Guarino[100]把本体论承诺表述成在语言和被称为本体的某些事物之间的映射。
基于Quine的观点，每个逻辑理论都有其自己显式或隐式的本体，然而从知识工程的角度，涉及本体的很多知识基都能达到：轻便式本体[101]。把知识基限定到存在于外部本体中的术语，这显然是不实际，因此知识工程师的本体论承诺定义应该不同于哲学的定义，即应定义为在知识基中的术语和在本体中同一或等同的术语之间的形式映射[102]。
概念之间有四种最基本的关系：part-of、kind-of、attribute-of和instance-of，其中part-of表达概念之间整体和局部的关系；kind-of表达概念之间的继承关系；attribute-of表达某个概念是另外某个概念的属性；instance-of表达概念和概念的实例之间的关系。
假定Onto是一个本体，则有：
定义1：称O=｛x|x是Onto中的概念｝是本体的概念集。
假定x，y，z∈O，则有：
定义2：符号P代表Onto中概念之间的part-of关系，P（x，y）表示概念y是概念x的一部分，例如P（car，wheel）。
定义3：符号K代表Onto中概念之间的kind-of关系，K（x，y）表示概念y是概念x的子概念，例如K（wheel，front-wheel）。
定义4：符号A代表Onto中概念之间的attribute-of关系，A（x，y）表示概念y是概念x的一属性，例如P（car，color）。
定义5：符号I代表Onto中概念之间的instance-of关系，I（x，y）表示概念y是概念x的一实例，例如P（car，Lincoln）。
定义6：关系Direct_Contain（x，y）满足：
P（x，y）→Direct_Contain（x，y）；
K（x，y）→Direct_Contain（x，y）；
A（x，y）→Direct_Contain（x，y）；
I（x，y）→Direct_Contain（x，y）。
定义7：关系Contain（x，y）满足：
Direct_Contain（x，y）→Contain（x，y）；
Contain（x，z）∧Contain（z，y）→Contain（x，y）。
定义8：关系intersection（x，y）满足
intersection（x，y）=｛z|Contain（x，z）∧Contain（y，z），z∈O｝。
定义9：关系union（x，y）满足
union（x，y）=｛z|Contain（x，z）∨Contain（y，z），z∈O｝。
定义10：关系difference（x，y）满足
difference（x，y）=｛z|Contain（x，z）∧┐Contain（y，z），z∈O｝。
定义11：本体Onto内的代数N=（O，R，Op）定义为：
O是Onto上的概念集；
R是O中概念之间的关系集合；
Op是对O中概念的操作集合。
定义12：称∑=（O，R，Op）是本体Onto内的基本代数，如果∑满足：
∑是Onto内的代数；
（Direct_Contain，Contain）R（P，K，A，I，Direct_Contain，Contain）；
Op=（intersection，union，difference）。
本体论依据包含的内容分为：经典本体论和混合本体论。经典本体论只包含概念，例如概念分类，每个断言表示概念之间的关系；混合本体论包括本体的关系和事件。
本体论依赖于所采用的语言，按照表示和描述的形式化程度的不同，可以分为：完全非形式化的、半非形式化的、半形式化的和严格形式化的本体论[76]。形式化程度越高，越有利于计算机进行自动处理。尽管可以采用多种不同的表示形式，但一般都包含术语的词汇表和词汇意思的某些解释，即概念的定义和概念之间的关系，以及概念之间的关系所满足的公理，从而共同在领域中设定一个结构，限定对术语的可能解释。
有些文献将本体看作是构造知识库的一种途径；另外一些将本体视为知识库的一部分；此外还有将本体看作与应用有关的交互工具和企业本体。根据已有文献，按照应用领域的不同将本体可大致分成三类[134]：人或组织之间达成概念共识的通讯；系统间使用本体作为交换格式的互操作；系统工程领域（可复用性、知识获取、规范、可靠性）。
上面定义的本体分类包含了与问题求解方法无关的静态知识，是构成领域层的一部分。为实现知识库系统各层次间的灵活配置，目前已提出了任务本体和方法本体的概念，它们分别描述特定任务与问题的求解方法。任务本体和方法本体本质上是从推理与问题求解角度描述领域知识的视图，它们有助于解决系统的互操作问题，即领域知识不能以与其使用方式无关的形式表示。任务本体和方法本体通过“假设”将领域知识与问题求解方法之间的交互明确地表达出来，充当了系统层次间的“粘合剂”，从而解决了知识库系统的复用与组件化开发中的关键问题。
依据目前的文献，可把本体分成：基本的研究主题，如哲学问题、知识表示、常识知识、通用本体库、领域本体库、工作和方法本体库等；本体的设计方法，如top-down、bottom-up、middle-out、大规模、分类和概念层次、内部结构、集成等；本体的应用，如自然语言处理、知识管理、商业过程建模、智能信息检索、Internet搜索、虚拟企业、企业供应链、仿真和建模、医学、教学、照片注释、电子商务、地理等；本体的开发，如方法论、框架、工具、语言、对比、评估、标准化等；以及知识共享和复用，如本体库的参与、多Agent间通讯、知识库等。
按照对本体操作的文献可分成：
l本体编辑：浏览[80,83]－提供浏览本体的可能性；生成[83]－生成新本体；扩展[14]－以不需修改现有定义的方式，基于现有词汇为特定使用来定义新术语的可能性；发布[80,14]－产生本体使能访问和复用；保存[80]－在开发过程中保存本体版本；更新－产生本体的更新拷贝。
l本体代数：交集－产生由共享实体组成的新本体子集；并集[85,86]－集合本体中的所有唯一实体来产生新本体合集。
l本体构造：抽取[81]－列举和组织大型本体的领域概念以便产生接近特定领域的本体；合并[81,85]－合并两个独立开发的KBs（KnowledgeBases）或解决术语间名称和结构表示冲突的本体；修剪[81]－删除给定领域不需要的概念或概念的子层次；切割[82]－选择部分输入的本体用于新应用或新本体。
l本体转换：术语转换[14,80,81,82]－使得一种形式开发的本体可用于其它知识表示形式和不同的语言。
l聚合/分解：模块化[82]或分解[14]－把KB内容分成概念部分以便充当KB开发和推理的基础。
l本体检查：匹配[80]－判断本体的符合度；验证[81,84]－检验新本体的完整性和一致性。
l查询[14]－提供从远程应用（客户）到系统和从系统到外部知识源（供应商）进行请求的可能性。
由于领域本体包含大量指定的概念，因此与通用本体和工作本体相比产生很少的进步。领域本体由对象、属性、关系以及子领域本体构成[41]。因此领域实体对象和实体间的关系都是独立的知识单元，而且领域本体可以嵌套。可以把领域本体形式化表示成一个连接的、有限嵌套的超图[40]，或有向非循环图（DAG，DirectedAcyclicGraph）[58]，图中的结点表示概念或单个对象，有向边表示概念之间的关系或关联。通过特性以及控制概念行为的属性、约束、函数和规则可以增强图的表示。
为了捕获本体论中不同术语的语义，应该定义本体论之间的关系和转换函数[174]。术语之间的语义关系SR主要有[35,167]：同义词关系（synonym）、上位关系（hypernym）、下位关系（hyponym）[165]、属关系（positiveassociation）[166]。其中同义词关系表示相似数据源之间对称的等价关系，即不同本体论中的两个术语有同样的语义；上位关系表示一个本体中术语的语义比另一本体中另一术语的语义更普通、更抽象；下位关系表示一个本体中术语的语义比另一本体中另一术语的语义更专业、更特殊；属关系表示一类事物属于另一类事物，如part-of关系。上下位关系是不对称的偏序关系，具有传递性。对于其它的术语关系，可以通过推理机制演绎得出。各个概念之间复杂的语义关系组成语义网络图，结点表示概念，结点间连线表示关系。
Hammer和McLeod[47]提出用一组关系描述符来捕获不同本体论中术语之间的关系。同义词关系本质上是对称的，表达方式是
考虑到不同角色的值之间的转换函数，定义有
本体间关系的服务主要包括有：
Guarino等人[121]提出用词汇概念图（LCGs，LexicalConceptualGraphs）表示本体的方法。LCGs是一种带标记的有向图，图中结点表示概念，有向边表示关系，结点中的词汇代表概念的名称，有向边上的词汇表示连接两个结点之间的关系。本体和XML都具备半结构化数据的特点，均可用LCGs表示，因此邓志鸿等人[123]采用XML表示本体概念，并利用XML-QL[122]查询语言实现本体概念的检索，从而提供更有效的概念检索，更好地取得本体的共享和复用。
假定本体Onto（O，R），其中O=（o1，o2，…，on）是Onto上的概念集，R=（r1，r2，…，rm）是O中概念之间关系的集合。利用以下步骤实现本体的XML表示：用LCGs表示Onto；LCGs中的非叶结点（概念）oi都转换成XML中的元素
基于本体论的启发式公式[119]可定义为n个函数的组合运算：，其中，表示一条有向边e或其反向e－1；是偏序闭包，表示路径长度，取值应≥0。该公式表明以一有向图的结点集作为输入，对每个结点沿着公式所说明的边从右到左的顺序进行计算，每步产生的中间结果作为下一步的输入，最后输出满足启发式条件的所有信息。
尽管UML缺乏形式语义的准确定义，但UML类图能用来表达领域的概念模型，最近已被提议用作本体表示语言[89,90]。仅依据UML的数学语义定义它的构造，还不能充分地适合于本体表示语言，因此为了建模需要，应该在上层形式本体的基础上建立概念建模语言，即应该有形式的和本体的语义。
Evermann[91]和Wand等人[92]都基于BWW本体框架把概念建模的公共结构映射到上层本体，Opdahl等人[93]把BWW本体用作概念框架的基础，以便依据BWW本体主要特性（自反性、不对称性、传递性）、次要特性（共享性、易变性、可分性）和随后的特性（所有权、操作的传播、封装）来定义整体－局部关系的分类，并依据本体表示分析不同种类的整体－局部关系，还提出一些UML版型以便用于本体区别的语法表示。
Guizzardi等人[94]使用通用本体语言（GOL，GeneralOntologicalLanguage）[95]和在其下的上层本体来评估概念UML类模型中本体的正确性，并为怎样用于定义良好的本体语义的UML构造开发指南，特别是从本体意思的角度研究UML中类和对象的元概念、超类型、关联以及整体－局部关系（聚合/合成），为了更满意地处理整体－局部关系还对UML版本1.4的扩展提出一些建议。
Maedche和Staab[181]提出基于浅文本处理和学习算法半自动产生本体的方法。提取依赖关系并当成学习算法的输入，并建立半自动产生本体论的Text-To-Onto系统。
Faure和Nedellec[182]提出交互式机器学习系统ASIUM，基于语法输入来获取动词的分类关系和子分类框架。ASIUM系统基于动词对共存的名词进行层次化分类。
Byrd和Ravin[183]从特殊的语法模式中提取指定的关系，如同位短语。通过计算术语间相互信息的度量，他们从共存的概念中得出未命名的关系。
最近注意力好像从表示转换到内容或构造本体的方法论，在设计领域本体环境时需要现有的有用信息资源，主要有两种复用已有领域本体知识来构造新的领域本体的方法。一是从用户需求分析开始，在已有领域本体的基础上构造新的领域本体，已有领域本体将会成为新的领域本体的一部分。在此类方法中，需要分析被选本体是否具有足够的描述细节和粒度，对于多本体库操作还要考虑本体描述语言之间的转换。
利用现有自然语言本体来作为本体构造资源的研究很多，如在Ontosaurus[42]中利用SENSUS[43]作为MRDs，采用半自动化的方法构造领域本体，但是仅仅给出用户输入的种子术语和SENSUS之间的拼写匹配结果来支持构造领域本体。DODDL[44]则以WordNet[35]作为MRDs对现有的领域本体进行有限的增减操作。Heijst[45]试着用领域特异性和方法特异性对现有相似的医学领域本体进行扩展以便复用，然而当相似的领域本体消失时，构造新的领域本体就变得很难。
PhysicalSystems本体库是在核心本体开发环境Ontolingua系统[1]上实现的本体复用系统，该系统辨别三类本体集成方法：应用新的概念和关系对本体进行扩充；对本体内容进行定制；分析现有领域本体以便提取领域间依赖关系来构造新本体。此方法对领域依赖关系作了深入分析，但是对怎样利用这些关系构造新本体却有待进一步研究。
二是对具有相同主题的已有领域本体的概念、分类规则和标准进行合并集成，从而构造新的领域本体。Heijst[45]从改造现有的同类医学领域本体库开始，对医学本体库中本体的概念、类、属性以及关系进行归并和扩充。
知识工程领域的研究已经转移到知识级上的领域建模。20世纪90年代，本体论工程作为新的领域出现。有几种构造本体论的工程框架的尝试：Genesereth和Fikes描述知识交互格式（KIF，KnowledgeInterchangeFormat）[36]，KIF是面向计算机并通过元知识和非单调推理规则得以增强的基于一阶逻辑的知识交互语言，用来帮助表达领域实际知识的使能技术；Neches和他的同事描述主动的知识共享[37]；Gruber提出Ontolingua语言来帮助构造便携式本体[1]；欧洲的CommonKADS项目采用相似的方案来建模领域知识[38]。这些语言把不同的谓词逻辑用作基本形式，谓词逻辑便于表示对象、特性和关系，提供共享本体技术的良好起始点。
传统的知识工程工具只提供关于基本的知识表示技术的本体论，并将其隐含于表示语言和推理机制中，缺乏足够的约束来描述知识的结构化组织，从而导致知识获取的困难和知识库难以维护。知识建模的研究促使本体论的研究面向结构化组织，以求按系统化和结构化方式开发对应用领域和问题求解任务的深入理解，然而以下两个问题仍困扰着基于本体论的知识建模：
l本体论的失配。大多数建模工具提供面向特定问题的求解方法（如启发式分类、骨架规则细化等）和任务类（如诊断、规划等）的本体论[131]。它们隐含于知识表示语言和推理机制，用户不能作修改扩充，从而导致与应用领域特征和问题求解任务的要求失配，严重时，建模工具成为开发KB系统的障碍而非辅助。
l本体论的非操作化。按照应用领域特征和问题求解任务的要求建立面向应用领域任务的专用本体论――概念模型，可克服本体论的失配问题。知识工程环境KADS提供分四个层次表示知识的通用本体论辅助概念建模，但却以本体论的非操作化为代价，即用户需要自行设计隐含概念模型的知识表示语言和推理机制[132]。
似乎这两个问题的解决不可兼得，并由此阻碍知识建模研究的深入开展和实用化。KADS要求本体论的非操作化关键在于追求通用本体论的普适性。鉴于世界的复杂性，不可能设计普适的本体论，综合集成异质的本体论才是取得普适性最有效的途径，因此放弃普适性就使得设计操作化的通用本体论成为可能。高济[133]设计两个操作化通用本体论用来辅助概念建模，概念模型将自动转变为符号级实现的形式，并和模型内容一起装配成符号级知识模型。这两个本体论加上一组问题求解方法或任务类的本体论，可以覆盖各种知识模型结构化组织的需求。
领域知识模型的构造是个特别繁重并且费时的事情，而且为了保证领域知识描述的一致性，对领域知识库的维护也相当繁琐。怎样利用知识库系统中现有的领域知识来构造新的领域模型和领域本体，以便更好地实现领域知识的共享和复用就成为亟待解决的问题。陈刚等人[40]设计并实现虚拟领域本体（VDO，VirtualDomainOntology）子系统，该系统的基本原理就是在领域知识库中只保存最基本的领域本体，当用户需要新的领域本体时，由系统依据用户提出的具体需求分析来对已有的领域本体进行重新组合或增减，从而在现有领域本体的基础上动态地构造出新的领域本体。
组织寻求复用并集成现有知识基的方式主要有两种：知识熔合――现有知识归并入新知识基，或现有知识基熔合成综合资源，例如数据仓库[96]；基于分布式知识的系统――分布在网络结点上现有基于知识的系统（或Agent）的互操作，例如欧洲Archon体系[97]。
在知识基之间共享知识需要两种规则[102]：转换规则，把知识表示转换成公共语言；映射规则，把术语映射到公共本体。如果知识基使用一阶谓词逻辑加密的语法版，就很容易实现转换问题。知识基和本体之间的映射规则定义知识基的本体论承诺，该本体论承诺应该确保一致性：本体中没有约束与知识基得出的推理相冲突，反之亦然。
映射将一直是本体复用中重要且远离自动化的隐含价值。从一些源材料集合中运行时构造本体论，并把本体论适应到所用问题解答方法的需求，这样的系统将能更有效地使用和复用本体。此方法更能处理变化的信息环境，并随时朝着“活本体论”[171]移动。能够集成和使用不同源的知识来构造特定领域、特定任务的本体的系统必将能用来生成新的领域本体论，也能更新现有的本体论，或者适应生成不同任务的本体论。
为了允许两个知识基之间的知识共享，建立知识共享的使能技术需要三个构件[37]：通讯知识的公共协议；表达知识的公共语言；定义术语的公共集合――本体。把本体当作共享知识基的方法，基本思想是以标准形式开发可复用的本体库，以便每个系统开发者采用。许多工作致力于为知识的通讯和表达来定义公共协议与语言，最著名的是美国DARPA的KSE（KnowledgeSharingEffort）项目[37]提出的KQML协议[98]和KIF语言[36]。
作为开发共享知识框架技术的一部分，为了确保共享框架的广泛可应用性，对很多领域和任务进行试验是必要的。文献[160]描述分子生物学试验领域的本体设计项目，基本目标是开发生物学试验的表示框架，并支持智能问题解答，集中于扩展以前的本体论模型和基于框架的形式，以便处理试验科学知识的表示问题。框架形式的额外特征包括属性组来辨识公共特性的关系集，并包括局部填充限制把可能的大部分属性值知识与处理不期望值的能力结合起来。试验表明扩展使能运用领域无关的推理规则，支持智能信息检索，并改善查询接口的质量。最后实现了智能信息M&M（Materials和Methods）检索系统原型，来辅助生物学家访问材料和方法领域研究论文的在线文档。
Uschold等[170]指出仍然没有现有本体复用的案例文献，他们通过在工程领域复用本体的经验发现从一种表示转换到另一种表示是个很难的问题，并表明完全的自动转换器在‘未来几年是不可能实现的’。尽管最终成功地实现本体论的复用，但是应该注意到他们起始于高品质的本体。
尽管高品质的专业本体论不可用，但是Internet上的高级本体论是逐渐可用的。SENSUS项目[43]尝试从高级本体论中自动生成领域本体论，这涉及使用广泛通用的本体半自动化的来开发专业的、特定领域的本体。
对本体的认识，可归纳为以下几点[2]：本体是对某一领域概念化的表达；概念是现实对象在某一或某些属性空间上的投影；对同一领域的概念化有某些共同点，但概念化可能有所差异；投影规则可能非常复杂，可能涉及多次投影或其它转换；任意本体均不可能包括现实对象的全部属性，只能限定到所研究的领域范围内；一个本体的断言转换到另一本体的断言不一定可逆。
本体论工程包含本体在概念化、设计、实现和配置期间的一系列指导活动，并提供知识基的设计原理，帮助定义领域世界的本质的概念，允许知识基的受训设计，以及使能知识积累，应用的研究范围包括哲学、形而上学、知识表现主义、方法论开发、知识共享和复用、知识管理、商业过程建模、常识知识、领域知识的系统化、Internet信息检索、标准化、以及评估[28]。
抽象上来讲，构造本体的范围从形成所有领域的知识表示基础的非常通用的术语到限定到特定知识领域的专业术语，数据结构和程序直接或间接地承担领域本体的承诺。信息检索系统、数字图书馆、异构信息源的集成、以及Internet搜索引擎都需要领域本体来组织信息和指导搜索过程。
在WWW领域，本体库已经变得普遍，在Web上的本体库范围从用大的分类法进行归类的Web网站（Yahoo和Lycos）到为销售的产品以及产品特征进行分类（Amazon和eBay），以及配置（Dell和PC-Order）等。
现在很多学科开发标准化的本体库，领域专家能用其对本领域的信息进行共享和注释，医学已经产生了大的、标准化的、结构化的词汇表SNOMED[8]和UMLS（UnifiedMedicalLanguageSystem）系统的语义网[9]。
OKBC（OpenKnowledgeBaseConnectivity）是本体的网络API，主要包括三个构件：知识模型、操作集和行为集。OKBC指定操纵知识基的整个操作集，操作通常分成如下几种类型：
l处理客户端和服务器之间的连接，例如establish-connection；
l发现服务器所知的表示系统和知识基，并确定此表示系统所知的知识基，例如get-kb-types和get-kbs-of-type；
l发布知识表示系统的性能和行为，例如get-kb-behaviors；
l操纵知识基，例如save-kb；
l为知识基的特定元素和整个知识基来询问或修改OO信息，例如get-kb-classes、add-class-subclass和get-frame-slots；
l询问或修改知识基中对象的特性/属性，例如get-slot-values、replace-slot-value；
l生成、操纵、存储和调用过程，例如call-procedure；
l操纵错误条件，例如okbc-condition-p；
l列举属性值并操纵之，例如enumerate-slot-values和next；
l增强移植性，例如decontextualize、coerce-to-kb-value和value-as-string；
l展现知识基的句子视图，例如ask和tell。
l对象管理组（OMG，ObjectManagementGroup）的公共对象请求代理体系架构（CORBA，CommonObjectRequestBrokerArchitecture）作为通讯架构；
lOMG的统一建模语言（UML，UnifiedModelingLanguage）来表示本体论（描述用户级领域和数据源的模型）；
l对象数据管理组（ODMG，ObjectDataManagementGroup）的对象查询语言（OQL，ObjectQueryLanguage）来表达OO数据模型的查询；
lOMG的元对象设备（MOF，MetaObjectFacility）用来存储本体论和本体建模语言的模型。
本体和词汇结构（字典、词典）提供的基本功能包括[1]：
几种专门用于发表本体论领域著作的期刊和杂志[21]已经描述了本体论的当前趋势，其中主要包括生成大规模的本体库[26]，定义表述本体知识的表示语言[27]，以及实现支持基于本体应用的系统[32]。然而令人遗憾的是，大多数文献都没有包含本体论工程和其它学科之间的关系[17]，使得其它学科的专家不得不竭力去理解本体论工程的优势，然后把本体论工程的术语映射到他们自己的研究领域中。因此，本节将简单介绍本体论工程与其它学科之间的相似性，并且还会对与软件工程学科的相似性进行详细描述。
通过把本体论工程放入其它学科的环境中，将会发现很多相似性。这些相似性允许实践者在本体论工程和其他学科之间建立连接，以便弥补理解上的代沟。本体论工程具有很多优良的品质，例如可分解性、可扩展性、可维护性、可转移性、模块化与接口性，以及信息的普遍理解性与软件构件的互操作性。来自其它领域的实践者可以使用该领域的不同术语，但术语的意思通常是相似的，因此自然会出现下面的问题：本体实践者能借用其他学科的知识么？两个通用的学科能够在规范化阶段与概念化阶段帮助本体论工程的开发，这两个学科就是元建模（metamodeling）和建模（modeling）[17]，如图1所示。
图1本体论工程与元建模和建模之间的关系
元建模是建模技术的概念模型，可以改善不同但相似模型的精确性[23]。知识模型的本体也可做到这点，原因是概念化的本体和特定的本体都有强大的元模型。没有本体的支持，表述同一领域知识的知识基既便使用相似的知识模型，通常也会不兼容。使用元模型的优点是永远不会失去任意特定模型的有效性，本体为领域知识的相应模型提供简单的框架。
通常，本体是用来描述怎样建立模型的元模型[17]。当对领域知识进行建模时，总是用（或复用）本体的构件（本体定义的概念及其之间的关系）来建立模块。当开发实际的软件系统时，如果工具包含有内在的模型知识（例如元模型或本体）将会有很大的益处，本体的元建模功能使得工具更加智能化。
把本体论工程放到其他学科的环境中，使得领域专家和本体论工程师都能从不同的视点来观察他们所研究的领域。对领域专家来说，在他们的研究领域和本体论之间获取类似处将会有助于解释某些本体论工程的概念造成的相似感觉；对本体论工程师来讲，意识到这些相似处可能会产生建立和改善本体的新途径。通过使用其它学科的知识、惯例和解决方案，实践者能够在本体基础上更加便利知识的共享和复用。
在本体论工程和软件工程学科之间存在着很多潜在有用的相似性，例如软件体系和软件模式，但在实际开发中却很少明确地讨论或使用这些相似性。很多实践者理解本体论工程和OO范例之间的相似处，并且理解本体开发阶段和软件开发过程之间的相似处，特别是当考虑特定目的的本体开发的软件工具时，例如西班牙Madrid理工大学的ODE[27]和美国Stanford大学的Ontolingua[116]。
假使实践者知晓更多有用的相似处，那么获益将会更多。软件工程学科和本体研究者之间很少讨论的很多内容都会有助于高级本体论工程的开发，例如软件体系、编程语言和编译器、传统软件工程、OOAD（Object-OrientedAnalysisandDesign，面向对象分析和设计）、设计模式，以及基于构件的软件工程。
2.1软件体系
软件的体系风格包含熟练的软件设计师获得的体系知识的浓缩框架，并提供复用这些知识的方法。例如，分层风格适用于涉及用层次进行安排的不同服务类的应用，设计师经常把服务层次化为基本系统级的服务、适用于很多应用级的服务，以及特定应用任务级的服务。同样地，本体结构用分层风格把特定用途的知识从核心（和更可复用的）知识中分离出来[28,32]。有些体系风格有助于定义本体论工程的解决方案，例如流水线和数据抽象[29]。
2.2编程语言和编译器
使用基于框架和/或基于逻辑的形式，可以实现特定目的的本体语言和本体编辑工具[24,26,27]。例如，Ontolingua[83,116]是基于KIF（KnowledgeInterchangeFormat，知识交互格式）的框架语言，KIF是对一阶谓词逻辑扩展版的符号和语义进行发布以及知识通讯。Ontolingua能够独立于特定数据或编程语言来编写知识级规范，并能把专业表示语言的知识基转换成另一种语言的知识基。其它的几种建立本体的语言和工具也都使用类似的在知识级直接建立本体的转换方法，该方法消除所需的主要实现语言，并消除从知识级转换到实现级过程中所用的转换器。但是为了使得经常坏结构或无结构的大量知识级规范顺利地转换成形式良好的谓词逻辑表达式时，一阶谓词逻辑却受到相当多的限制。使用特定的转换器也存在着问题[32]，因此为了充分地使用转换后的本体，还需进行大量的手工修改。
值得注意的是，最近的语言和工具都广泛地使用编译原理的技术与技巧，以便改善转换过程的质量和性能。例如，ODE[27]环境使用普通的转换器以便允许用户以面向用户的内部表示方式来指定本体，并把该本体自动地转换成目标语言Ontolingua。转换器以BNF范式（Backus-NaurForm，巴科斯范式）的形式使用语法来陈述性地表达概念模型；目标语言中每一类型的正确定义，都有表格把转换规则中使用的术语和概念模型中运用的术语相互关联起来。仅通过改变确定将要生成的术语的转换规则的标准，并改变把概念化和实现相互关联起来的相应表格，就能很容易地建立新的转换器。
除了特定目的的本体语言外，从本体论工程的角度来考虑其它的编程语言也很有必要。对于如标识符、保留字和结构等概念，除定义编程语言的通用本体外，还可以从任意编程语言中抽象出本体框架。这实际上暗示实践者在编程语言中隐含存在着很多本体，因此不应该再发明。例如，Java语言中至少具有两个明显与本体论工程的概念相类似但却很少注意到的部分[17]：
2.3传统软件工程
2.4OOAD
本体论工程需要额外努力的就是开发广泛接受的本体表示符号。在过去的十几年里，软件工程已经在OOD中使用几种不同的表示符号，但最后所有的都汇总到提供OOD元模型的UML（UnifiedModelingLanguage，统一建模语言）[23]语言符号中。UML定义的图形符号以四种不同视图（逻辑、用例、构件和配置）来表示类、对象和它们之间的关系，这将覆盖OOD的所有实践方面。如果本体论工程有每个人在实践中都能接受、理解和使用的标准符号，那么将是很美好的。元语言的统一图形表示法能够帮助构建丰富且易用的可视化工具[32]，并将在设计阶段增加知识复用，但不幸的是，当前大多数本体开发者都仅使用他们自己开发的符号。
从实践者的角度来讲，在本体论工程与OOAD之间存在着重要的区别。“本体”意味着采用知识级的方式来描述系统[21]；然而“OO”大部分涉及设计和实现的手段。例如，在基于语义的信息检索系统中，本体指定将被搜索的概念的意思；而在此系统的OOD中，本体却表示领域模型。像UML等OOD语言为所有设计策略提供清晰的设计方法学和符号，而本体和元建模原理在这些语言中却是隐式的[28]。换句话说，本体是在知识级上从相应的任意OO符号（如UML）表示的类图、对象图和用例图中抽象出来。本体的作用就是表达并明确地指定OOAD应依赖与支持的领域概念、术语、定义、关系和约束，以及其它的语义内容。
2.5设计模式
把设计模式描述成OO软件设计中特定问题的简单而精确的解决方案[25]，为设计师提供公共词汇表以便进行通讯。设计模式包含很多基于再设计和再编码尝试的知识与经验以便取得更大的软件复用和灵活性。尽管设计模式和本体不能同等，但实践者应该意识到两种概念的重叠，并且都涉及词汇表、知识和“体系架构”，以及都在知识级上描述概念，因此在实践开发中可以共用软件模式和其它的本体设计资源。
2.6基于构件的软件工程
本体论工程的长期目标就是建立本体知识库，即可复用的知识构件和能够通过网络调用的基于知识的服务[17]。基于构件的软件工程致力于开发可复用的、预先检验的和可互操作的知识库，并使能设计和开发可独立升级的即插即用的软件构件。这些目标使得从用不同语言、工具和开发平台的开发者独立构造的应用基础来设计系统成为必需。
本体是构件，但反之却未必。本体概念上比构件更抽象，但构件好像是本体的一部分，开发与本体完全相符的构件是可能的，不同的领域和本体能够共享知识库中的构件。本体能够准确地定义构件和构件局部的语义，还能定义关系的类型以及软件构件之间的通讯，因此在某种意义上，本体实际上应该是设计和开发可互操作的软件构件的基础。
尽管OO系统和本体强调不同的方向，但可以预言不久的将来两种技术之间的汇聚程度必将会逐步增加。正如信息系统模型扩大知识领域的范围一样，领域本体将会在软件系统中变得日益重要。
过去的几年里已经开发了五种本体语言。有些是直接基于XML语法，例如基于XML的本体交换语言（XOL，XML-basedOntologyexchangeLanguage），简单的HTML本体扩展（SHOE，SimpleHTMLOntologyExtension），和本体标记语言（OML，OntologyMarkupLanguage），另外的两种语言是建立于RDF(S)――RDF和RDFS的并集――之上，以便改善RDF(S)的特征：本体交互语言（OIL，OntologyInterchangeLanguage）和DAML（DARPAAgentMarkupLanguage）+OIL（OntologyInferenceLayer）。
l基于XML的本体交换语言（XOL）[3]
为了在异构的软件系统中进行本体定义的交换，US的生物信息学领域设计了XOL。在研究了生物信息学专家的代表性需求后，研究人员创造了XOL。基于XML，他们选取Ontolingua和OML作为生成XOL的基础，并结合开放知识基连通协议（OKBC，OpenKnowledgeBaseConnectivityprotocol）的子集OKBC-Lite的高级表现和OML的语法。没有工具支持使用XOL开发本体。然而，由于XOL文件使用XML语法，因此可以使用XML编辑器来生成XOL文件。
语义网中的语言堆栈
l简单HTML本体扩展（SHOE）[4]
l本体标记语言（OML）[5]
美国Washington大学开发了部分基于SHOE的OML。事实上，最初是把OML视为SHOE的XML顺序化。因此OML和SHOE共享很多特征。
l本体交互语言（OIL）[6]
当前，本体应用于WWW生成了语义网。最初，Web发展主要是围绕着HTML。为了呈现结构化文档，HTML为浏览器能以规范的方式翻译这些文档提供了标准。一方面，HTML的简单有助于刺激Web的快速发展；另一方面，在很多领域和很多工作中，它的简单严重地阻碍了更高级的Web应用程序，它不能提供方法来表述丰富的语法和数据语义。这导致了XML的出现，它允许开发者随意地定义特殊领域和工作的扩展。
XML基本上是用已定义的方式来为树结构提供一序列语法――这是朝着建立语义网的重要的第一步，应用程序可以直接访问语义网中的数据语义。然而，尽管XML为数据结构和语义的定义提供标准序列化语法，但是没有提供标准数据结构和术语来描述商业过程和产品交换。资源描述架构（RDF，ResourceDescriptionFramework）已经采取了额外的重要步骤，通过定义语法协定和简单数据模型来表示机器可处理的数据语义。RDF是W3C组织开发的Web元数据的标准，并且RDF基于对象、属性和数值定义了数据模型。RDFS（RDFSchema）在更丰富的表示形式上更深入了一步，并且把基本的本体原始建模引入到Web中。在基于Web的条件下，使用RDFS能够讨论类、子类、子属性、属性的领域和范围约束等等。我们以RDFS作为开始点，并把它全部浓缩进基于Web的本体语言OIL中。包括如下方面：
为什么是OIL？
本体的有效工作需要来自高级工具的支持。需要高级本体语言来表达和表述本体。这门语言应该满足三条需求：
OIL满足这些标准并统一了不同领域提出的三个重要方面：框架领域提出的认识论上的丰富的原始建模，描述逻辑提出的形式的语义和有效地推理支持，以及Web领域提出的语法交换符号的标准提议。
OIL的分层体系结构：
核心OIL（CoreOIL）与大部分RDFS相符（除了RDFS的具体化特征）。
标准OIL（StandardOIL）是完整的OIL模型，目的是捕获必要的主流原始建模，这些建模能够提供充足的表现力且能很好地理解，因此准确指定语义并使得完整的推理是可行的。
实例OIL（InstanceOIL）包括完全单个的集成，给前一层增加概念和角色的实例。尽管标准OIL包括在术语定义中指定单个填充物的建模构造，但实例OIL包括完整的数据库能力。
重型OIL（HeavyOIL）将包括额外的表象（进而推理）能力，是OIL的未来扩展层。
OIL的分层体系结构具有三个优点：
OIL在三个领域上有强大的工具支撑：
在OIL案例中，当前两种工具辅助本体描述大量的实例群。第一，能够从OIL的本体中获取XML的DTD和XMLSchema定义。第二，能够从OIL中为实例得到RDF和RDFS定义。
本体的推理引擎能够推理本体的实例和规范定义。如此推理机有助于建立本体并用它们进行高级信息的访问和导航。OIL使用FaCT（FastClassificationofTerminologies）系统为本体设计、集成和验证提供推理支持。
OIL具有优点：在Web语言（例如XML规范和RDFS）中是适当地接地，并且提供不同级别的复杂性。它的内部分层使能基于FaCT进行有效地推理支持，并且具有定义良好的形式化语义，该语义是语义网语言的基线需求。关于它的原始建模，OIL不仅是另一种新语言，而且在领域――例如DL和基于框架的系统――中反映了确定的共识。
OIL最基本的语法格式：
begin-ontology
ontology-container
title"PrinterProduct"
creator"WenJieLi"
subject"printer,Price,ManufacturedBy"
description"AsimpleexampleontologydescribingPrinterProduct"
description.release"1.0"
publisher"WenJie"
type"ontology"
format"pseudo-xml"
format"pdf"
language"OIL"
language"en"
ontology-definitions
class-defProduct
slot-defPrice
domainProduct
slot-defManufacturedBy
class-defPrintingAndDigitalImagingProduct
subclass-ofProduct
class-defHPProduct
slot-constraintManufacturedBy
has-value"HewlettPackard"
class-defPrinter
subclass-ofPrintingAndDigitalImagingProduct
slot-defPrinterTechnology
domainPrinter
slot-defPrintingSpeed
slot-defPrintingResolution
class-defPrinterForPersonalUse
subclass-ofPrinter
class-defHPPrinter
subclass-ofHPProductandPrinter
class-defLaserJetPrinter
slot-constraintPrintingTechnology
has-value"LaserJet"
class-defHPLaserJetPrinter
subclass-ofLaserJetPrinterandHPProduct
class-defHPLaserJet1100Series
subclass-ofHPLaserJetPrinterandPrinterForPersonalUse
slot-constraintPrintingSpeed
has-value"8ppm"
slot-constraintPrintingResolution
has-value"600dpi"
class-defHPLaserJet1100se
subclass-ofHPLaserJet1100Series
slot-constraintPrice
has-value"$479"
class-defHPLaserJet1100xi
has-value"$399"
end-ontology
把本体语言定义为RDFS的扩展意味着：每个RDFS本体在新语言中都是一个正确的本体。定义OIL扩展尽可能的接近RDFS允许基于现有RDFS应用和工具的最大复用。因为本体语言经常包含新的方面，100％兼容是不可能的。
OIL与RDF/RDFS的关系：
lDARPA的Agent标记语言+本体推理层（DAML+OIL）[7]
各语言之间的比较：[16]
表述性的需要依据应用中本体库的使用而不同。术语轻型（lightweight）和重型（heavyweight）指得是两种不同的本体库：这些本体库包含概念（用概念的属性加以描述，并在分类学中仅用subclass-of关系进行组织）、关系和功能、以及实例（可能是被表述的唯一构件），也包含公理。
如果从允许定义轻型本体库的语言到允许定义重型本体库的语言来测量语言的表现力，那么顺序将是：XOL、RDF(S)、SHOE、OML、OIL和DAML+OIL。
在定义重型本体库时，应该仔细选择语言，因为错误的决定会阻止应用的成功。在应用中最初采用框架来确定表现力需要。一旦表格填满了信息，就可以用标准信息对其进行比较，从而去掉没有充足表现能力的语言。接下来应该基于应用所需的推理机制。XOL和OML没有任何可用的推理机制，而RDF(S)、SHOE、OIL和DAML+OIL都有推理机。在此情况下，应该考虑需要何种推理。RDF(S)、SHOE和DAML+OIL能生成查询服务。OIL和DAML+OIL也为本体中的一致性检测和分类学中的组织概念提供自动分类。
通过基于现有的生成本体库和注释资源（生成实例和约束）的工具，能对候选的语言进一步筛选。大范围的本体开发工具（OILEd、OntoEdit（仅DAML+OIL）、Protégé和WebODE）都支持OIL和DAML+OIL。没有任意一种本体工具支持RDF(S)，但更通用的生成元数据的工具支持它。注释RDF(S)的工具也能用于存储为RDF实例的OIL和DAML+OIL。SHOE知识注释器允许用SHOE注释Web页面，但没有可用的建立本体库的本体编辑器。没有任何特定的工具支持剩余的语言。
Web本体语言
语义网的梦想：机器可理解Web中的资源，并且自动Agents和人都能交换和处理Web中的信息，但缺乏互操作性威胁着Internet的将来，通过信息的标准化可以解决各种争议。W3C组织的成员协会和受邀专家组成WOWG（WebOntologyWorkingGroup）的宪章中明确表述：当设计Web本体语言时应把DAML+OIL当作起始点。Web本体语言是很多人用于不同用途的工具，最重要特性是定义良好的形式化语义，共有7维：层次、包容、大小、研究、前景、社会、商业[77]。本体语言能充分有力地捕获所需的大多数信息，同时仍足够的简单以便允许Agents在任意特定时刻执行自身基于事实的推理，这必将会给语义网的开发带来很大的贡献。语义网中本体的目的是：为分布在所有Web中的数据提供一种语义类型以方便用户通过搜索或查询引擎的访问，同时更便于Web服务的输入或输出。
Web本体语言具有三种复杂性：计算复杂性、技术复杂性和概念复杂性[77]。
计算复杂性：计算效率是三种复杂性中最少引人注意的，特别是当解释成渐近最坏情况的复杂性结果。有时所需的可判定性也是有争议的，可判定仅意味着不存在判断任意OWL理论一致性的算法，然而实际情况中可能存在许多很好的算法。不过计算复杂性仍是设计DAML+OIL的指导方针之一。
概念复杂性：DAML+OIL失去平衡最多的地方就是概念复杂性。在概念方面强调DAML+OIL优点的唯一方法就是查看DAML+OIL建立的本体。概念复杂性的另一重要方面就是建模方式，大多数本体建模都是基于框架的建模方式，这与DAML+OIL的描述逻辑有着直接的冲突。OWL通过删除一半DAML+OIL语言，并基于RDF和RDFS把描述逻辑语义隐藏在基于框架的语法后面，从而能降低DAML+OIL的概念复杂性。
Ontology开发指南
1．概述
Ontology的概念最初起源于哲学领域：“对存在的系统地描述，即存在论”。
本质上，经常以某种形式的和更适宜机器易读的方式把本体的意思属性化为概念化的规范，即已定义的术语和术语之间的关系。本体为某领域共享信息的研究者定义公共词汇。
AI领域，开发本体论来便利知识共享和复用。从20世纪90年代，已成流行的研究主题，主要方向有：知识工程、自然语言处理和知识表示。
更近，本体的概念在很多领域都正在变得广泛，如智能信息集成、协作信息系统、信息检索、电子商务和知识管理、多Agent系统等。
最近几年，本体库的开发已经从AI实验室等领域转移到领域专家的桌面。
在软件领域，任何软件本身都固有一套概念体系，这个体系包括对象、对象之间的相互约束关系、对事务处理过程的描述、语义交互，以及简单的推理和逻辑规则，因此可以把此体系通称为软件领域的本体[2]。
Ontology语言
过去的几年里已经开发了五种本体语言（如图1所示）。有些是直接基于XML语法，例如基于XML的本体交换语言（XOL，XML-basedOntologyexchangeLanguage），简单的HTML本体扩展（SHOE，SimpleHTMLOntologyExtension），和本体标记语言（OML，OntologyMarkupLanguage），另外的两种语言是建立于RDF(S)――RDF和RDFS的并集――之上，以便改善RDF(S)的特征：本体交互语言（OIL，OntologyInterchangeLanguage）和DAML（DARPAAgentMarkupLanguage）+OIL。
图1语义网中的语言堆栈
为了在异构的软件系统中进行本体定义的交换，US的生物信息学领域设计了XOL。在研究了生物信息学专家的代表性需求后，研究人员创造了XOL。他们基于XML，选取Ontolingua和OML作为生成XOL的基础，并结合开放知识基的连通协议（OpenKnowledgeBaseConnectivityprotocol）的子集OKBC-Lite的高级表现和OML的语法。没有工具支持使用XOL开发本体论。然而，由于XOL文件使用XML语法，因此可以使用XML编辑器来生成XOL文件。
l简单的HTML本体扩展（SHOE）[4]
在OntoKnowledge项目和IBROW下开发了OIL，欧盟信息社会技术的IST程序资助开发OIL，允许Web资源之间的语义互用性。它的语法和语义是基于现有的提议（OKBC、XOL和RDF(S)），把基于框架的方法中普遍使用的原始建模提供给本体论的工程（概念、概念分类、关系等），以及在描述逻辑方法（结合了决定性和有效推理机制，维护高表现力的第一阶逻辑的子集）中发现的形式的语义和推理支持。
Ontology编辑和开发工具：
应用领域：
在WWW领域，本体库已经变得普遍。在Web上的本体论范围从用大的分类法进行归类的Web网站（Yahoo和Lycos）到为销售的产品以及产品特征进行分类（Amazon和eBay），以及配置（Dell和PC-Order）等。
现在很多学科开发标准化的本体库，领域专家能用其对本领域的信息进行共享和注释。医学已经产生了大的、标准化的、结构化的词汇表SNOMED[8]和UMLS（UnifiedMedicalLanguageSystem）系统的语义网[9]。
2．为什么开发本体？
开发本体的一些原因是：
l在人或软件Agents之中对信息的结构的共同理解进行共享是开发本体库的最普通的目标之一[1,10]。
l使能复用领域知识是本体研究中最近涌现出的驱动力之一。
l制定清晰的领域假定使得如果关于领域的知识变化时容易地改变这些假定是可行的。
l从操作知识中分离出领域知识是本体库的另一个公共用途。
经常，领域本体本身不是一个目标。开发本体类似于定义一套数据和它们的结构以便其它程序使用。解决问题的方法、独立领域的应用和软件Agents使用本体库和从本体库中建立的知识基来作为数据。
3．什么是本体？
本体是对研究领域的概念进行正式的明确地描述（classes或concepts），每个概念的特性描述其不同的特征和属性（slots或roles、properties），以及属性的约束（facets或rolerestrictions）。
本体和类的一组实例（instances）构成了知识基（knowledgebase）。事实上，本体的结束和知识基的开始有清晰的分隔线。
4．本体开发步骤
实际上，本体的简单开发过程包括：
l定义本体的类
l在分类学（子类－超类）层次上安排类
l定义属性并描述这些属性的允许值
l填充属性值形成实例
本体开发采用迭代步骤：最初定义粗略的本体，接着修改并细化进化的本体，随后填充细节。决定将使用本体做什么，以及本体将怎样详细或通用，这将在开发中指导很多建模决策。在几个可用的替代方案中，需要确定对设计的工作来说哪个更有效、更直觉、更可扩展和更可维护。需要记住本体是现实世界的模型，本体中的概念应该反映这一事实。定义本体的最初版本后，通过在应用或问题解决方法中使用，或通过与领域专家讨论，或者两者结合，能够对其进行评估和测试。因此，几乎确定需要修改最初的本体。
Step1.确定本体的领域和范围
回答基本问题：本体覆盖的领域，用本体做什么，本体中的信息应提供何种类型的答案，谁使用和维护本体。设计并填写本体的性能调查表（competencyquestions）[13]
Step2.考虑现有本体的复用
为特定的领域和工作来细化和扩展现有的资源。如果系统需要与其它特定的本体库或受控词汇的应用交互，则复用现有的本体库可能是系统需求。很多电子格式的本体库都可用，并能导入本体开发环境。
Step3.枚举本体的重要术语（名词、动词）
Step4.定义类和类层次
类是大多数本体库的核心，描述领域的概念。有几种开发类层次的可能方案[14]：top-down开发过程开始于定义领域中最普通的概念，随后对概念特性化；bottom-up开发过程开始于定义最特殊的类，即类层次的叶子，随后把这些类分组成更普通的概念；combination首先定义更明显的概念，接着对其进行适当地泛化和特性化，它是最容易的过程，因为“在中间的”概念倾向于是领域中更具描述性的概念[15]。
Step5.定义类的特性－slots
属性描述类和实例的特性。单靠类不能提供足够的信息来回答Step1的性能调查表。因此定义一些类后，应该描述概念的内部结构，即属性。子类可以继承或覆盖父类的属性。
已经从Step3产生的术语表中提取出了类，大部分剩余的术语可能是这些类的特性。对于列表中的每个特性，应该确定其描述哪个类。这些特性变成附属于最通用类的属性。
通常，在本体中能变成属性的几种对象特性是：“固有的”、“外在的”、局部、关系。
属性具有反向性（Inverserelations），并可具有缺省值
Step6.定义属性的约束
属性能有不同的约束来描述值类型（String、Number、Boolean、Enumerated、Instance）、允许值（范围、域）、值数目（单一或多个、最小或最大），以及值的其它特征。
如果定义了属性的范围或域的类表中包括类和它的子类，则删除子类。
Step7.生成实例
定义类的单个实例需要：（1）选择类；（2）生成这些类的单个实例；（3）填充属性值。
5．对于任何领域，没有唯一、正确的本体。最合适的开发过程都是与具体的实际应用相互关联。
附注：
Protégé-2000v1.7的主要特征（2003/04/09已发布v1.8，2003/06/04已发布v1.9Beta）
l兼容JDK1.3（以上），软件可自带VM
l可扩展、平台无关
l开放源码、free
l生成、编辑本体库和知识基
l直觉和易用GUI，配置可扩展Plug-in体系（Classes、Slots、Forms、Instances、Queries、PalQueries、KATool、ClassesAndInstances、PalConstraints、Flora、InstanceTree、Oil、OntologyBeanGenerator、KnowledgeTree、Prompt、UMLS、OKBC、DAMLHousekeeping、WordNet、BeanShell、Fca、TGViz、Ontoviz、Algernon、DataGenie、XML、Relations、TM等共50个）
l支持任何语言输入的知识基
l支持任意有JDBC1.0的DB，以及大部分RDB、Oracle、MySQL、SQL和Access
l支持标准的输入和输出格式：
u标准文本文件（*.pprj、*.pont、*.pins）
uRDFS（*.pprj、*.rdfs、*.rdf、名字空间）
uJDBCdatabase（*.pprj、驱动器类名、URL、表、用户名、密码）
uUML1.4类图（*.pprj、*.uml.xmi）
uProtegeXMIfiles（*.pprj、*.protege.xmi）
uDAML＋OIL（*.pprj、*.daml、*.daml、名字空间）
uXMLDTD（*.pprj、*.xml、*.dtd）
l仅用于Java，使用JNI（JavaNativeInterface）从C和C++可以访问JavaAPI
l设置用户，生成日志文件*.pjrn
l矩阵统计：显示类、属性、实例等的总数、均值、方差信息
l直接生成HTML
l支持多用户
l通过模板的方式定制性能
l完整的一致性检测确保本体包含正确的知识
参考文献：
《AgentsandtheSemanticWeb》
多Agent系统通信的很多挑战都需要本体。Agent技术和本体论的集成能够明显地影响WebServices的使用，并能通过程序扩展更有效地为用户完成工作，且需要更少的人类干涉。
真正的本体是什么？
例如，烹饪和食谱本体包括成分、怎样搅拌和混合配料、煨炖和油炸之间的区别、最终产品是吃还是喝、油是用来烹饪或食用而不是用来润滑，等等。
在最近的XML2000会议上，TimBerners-Lee给出了图1所示的夹心蛋糕（layercake）结构，此图通过使用更低级的语法和语义，显示了具有更高级语言的语义网（theSemanticWeb）的已提议层次。
图1语义网夹心蛋糕
语义网本体论
在接下来的几年里，几乎每个公司、大学、政府代理，或者特别利益集团将要把它们的Web资源链接到本体论的内容，由于很多有力的工具将可用来使用这些内容。应用程序之间将会交换信息，使得程序随意地收集和处理Web内容和交换信息。在这个基础架构之上，基于Agent的计算将变得更加实用。分布式的计算机程序与非本地的基于Web的资源交互最终可能变成主导的方式，在此方式中，计算机与人类相互作用。在不远的将来，如此交互将会变成计算的主要手段。
Agent之间的通信
图5描述了小部分的本体论的Web。小盒子表示Agent或其它Web资源，它们使用用更大的盒子表示的Web本体论中的术语。箭头表示提供从一个本体到另一个本体的映射（全部或部分）的任何机制。该图显示了一个有向非循环图（DAG，directedacyclicgraph）。
图5Agents和它们所用本体论之间的映射
假定Agent之间使用本体论中的内容术语相互进行通信，这种通信是相当简单的。通过链接到这些本体论，Agent使用与在这些本体中规定的用法相一致的术语进行通信。
更有意思的是，没有使用同一本体论的Agent之间仍然可能进行通信。如果所有的映射都是正确的，那么很显然，任何Agent都能与其它Agent进行通信，通过发现它两都能映射到的共同本体。
DAML和其它的语言
现代的IT世界是个动态变化的环境，同时数据的生成和发布能力也以指数级增长，这迅速地超越了人类把这些数据处理成信息的能力。在这个普遍地分布式、异构、不确定的信息环境中，基于Agent的计算能够潜在地帮助我们识别复杂的模式。不幸的是，当Agent理解数据并与之交互时，这些数据或是未被处理或是自然语言的方式，因此Agent所面临的困难阻碍了这种潜能。
一个可能的解决方案是在半路上满足计算机。通过使用工具来给数据源提供附加的标记注释，我们能够使得Agent以新颖且令人兴奋的方式来使用信息。DAML（DARPAAgentMarkupLanguage）项目的目标就是开发以机器易读的方式来表述语义关系的一门语言，这种方式将会与当前和未来的Internet技术相兼容。当前，项目正在开发原型工具来展示如此标记提供革命性能的潜能，这将改变人类和信息交互的方式。
为了实现这些目标，Internet标记语言应该脱离XML和特殊领域受控语言固有的隐式语义协定。DARPA指引着DAML的方向，DAML将变成把网页上的信息与机器易读的语义相结合的语义语言。该语言应该允许领域自身扩展简单的本体论，还允许自底向上的设计方式，同时允许更高级概念的共享。此外，该语言将为服务、过程和商业模型的显式表示提供机制，并且还允许识别非显式信息（例如程序或传感器中的封装）。
相对于当前的标记方法，DAML将提供很多优点。它将跟当前在XML中的语法互用性同一级别上允许语义互用性。Web中的对象标记包括：对象编码的信息描述、对象提供的功能描述和对象能产生的数据描述。这样的话，将允许通过Agent把网页、数据库、程序、模型和传感器都链接到一起，以便使用DAML来识别它们查询的概念。如果成功的话，则来自不同源的信息熔合将变成现实。
DARPA基金致力于DAML的开发以便帮助美国军事上的命令和控制领域，并应用于军事智能领域。例如，DAML的用途之一是改善大型军事信息仓储的组织和检索。就关于智能方面，DAML的目的是从多个源到提供特殊指示和警告来改善信息的集成，以便阻止恐怖分子对军事目标的攻击。
网站
《KnowledgeProcessesandOntologies》
图6本体开发过程或知识元过程
知识元过程（本体开发过程）
我们的本体开发模型范围从建立KM项目的早期阶段到基于本体的KM应用程序的最终展示。图6显示了本体的开发过程。
可行性研究：
即使KM系统是完全地集成，则它也仅能满足功能上的需求。几个因素而非技术能够决定成功或失败。为了分析这些因素，必须进行可行性研究以便来识别问题域或机会域和可能的解决方案，还要进行可行性研究以便把这些问题或机会放入到更宽范围的组织前景中。
开始阶段：
开始阶段的输出产品是本体需求规范文档（图7）。开始阶段描述了本体应该支持什么，并且概述了本体应用程序的规划区域。在此阶段也指导本体工程师对本体中概念的包含、排除和层次结构进行判断。在这个早期阶段，应该寻找已经开发过的和可能重用的本体。
图7本体需求规范文档
总之，开始阶段应该明确几条信息的细节：
开始阶段还应包括能力调查表，本质上是系统可能疑问的总览，该系统能象征域本体的范围和内容。最后，开始阶段应该详述任何可能重用的本体论。
细化阶段：
细化阶段的目的是根据开始阶段给出的规范，产生出一个成熟且面向应用程序的目标本体。可把此阶段分成不同的子阶段：
使用可能重用的本体论（开始阶段识别出来的）能够改善整个细化阶段期间开发的速度和质量。这些本体论可能为建模决策提供有用的线索。
评估阶段：
在此阶段也将测试目标应用程序环境中的本体。对于本体的进一步细化来说，来自beta版用户的反馈可能是有价值的输入。原型系统应该追踪用户对概念和关系进行导航或搜索的方式。还应追踪本体最常应用于哪个区域。
这个阶段与细化阶段是亲密关联的。本体工程师应该需要执行几次循环直到目标本体达到指定的级别。转出目标本体完成了评估阶段。
维护阶段：
本体的规范经常需要改变以便反映现实世界的变化。为了反映出这些变化，必须经常地维护本体论。维护本体论主要是个组织的过程。对于本体论内部的更新－删除－插入过程应该有严格的规则。
推荐收集本体的变化，并在彻底地测试应用程序的可能影响后，开始转换到该本体的新版本。正如在细化阶段，来自用户的反馈可能对辨识变化有帮助。
《OIL:AnOntologyInfrastructurefortheSemanticWeb》
在AI领域的研究者首先开发了本体论来便利知识共享和重用。自从20世纪90年代开始，本体论已经变成了一个流行的研究主题，并且一些AI研究领域――包括知识工程、自然语言处理和知识表示――都已开始研究本体论。
更近，本体的概念在很多领域都正在变得广泛，如智能信息集成、协作信息系统、信息检索、电子商务和知识管理等。本体论变得流行的主要原因是它们许诺：能够跨越人类和应用程序系统的共享和公共的理解。
当前，本体论应用于WWW生成了语义网（theSemanticWeb）[1]。最初，Web发展主要是围绕着HTML。为了呈现结构化文档，HTML为浏览器能以规范的方式翻译这些文档提供了标准。一方面，HTML的简单有助于刺激Web的快速发展；另一方面，在很多领域和很多工作中，它的简单严重地阻碍了更高级的Web应用程序。这导致了XML（图1）的出现，它允许开发者随意地定义特殊领域和工作的扩展（甚至HTML作为XML应用程序而出现――XHTML）。
图1Web的层次语言模型
本体论：信息访问和集成的革命
本体技术的三个主要应用领域是：知识管理、Web商务和电子商业。
知识管理：
使用本体论，语义注释将允许文档的结构的和语义的定义。这些注释能够提供完全新的可能性：智能搜索而不是关键词匹配，疑问应答而不是信息检索，通过本体映射在部门之间交换文档，文档视图的定义。
本体论的有效工作需要来自高级工具的支持。需要高级本体语言来表达和表述本体论。这门语言应该满足三条需求：
很多现有的语言，例如CycL[6]、KIF[7]和Ontolingua[8]都失败了。然而，OIL[9]满足这些标准并统一了不同领域提出的三个重要方面：框架领域提出的认识论上的丰富的原始建模，描述逻辑提出的形式的语义和有效地推理支持，以及Web领域提出的语法交换符号的标准提议。
OIL的分层体系结构
单一的本体语言不可能实现语义网的大范围用户和应用程序的所有要求。我们因此把OIL组织成一系列永远渐增的次语言层。每个附加层向前一层增添功能性和复杂性。仅能处理较低层的Agent（人类或机器）仍能理解任意更高层表达的部分本体论。这种原理的首要应用程序是OIL和RDFS之间的关系。正如图3所示，核心OIL（CoreOIL）与大部分RDFS相符（除了RDFS的具体化特征），原始OIL与原始RDF(S)有直接映射。这意味着甚至简单的RDFSAgent也能够处理OIL本体论，对于它们有限的能力，能够获取尽可能多的意义。
图3OIL的分层语言模型
标准OIL（StandardOIL）是完整的OIL模型，目的是捕获必要的主流原始建模，这些建模能够提供充足的表现力且能很好地理解，因此正好指定语义并使得完整的推理是可行的。
实例OIL（InstanceOIL）包括完全单个的集成，给前一层增加概念和角色的实例。尽管前一层――标准OIL――包括在术语定义中指定单个填充物的建模构造，但实例OIL包括完整的数据库能力。
OIL原始建模的说明
用元数据来注释OIL本体自身，开始用标题、创作者、创作日期等。OIL遵从W3C都柏林中心关于文献元数据的标准。
OIL工具
在OIL案例中，当前两种工具辅助本体论描述大量的实例群。第一，能够从OIL的本体中获取XML的DTD和XMLSchema定义。第二，能够从OIL中为实例得到RDF和RDFS定义。
《OntologyLanguagesfortheSemanticWeb》
本体的定义：“本体是共享概念化的显式的、机器可读的规范。”[1]
本体语言
过去的几年里已经开发了几种本体语言。有些是基于XML语法，例如本体交换语言（XOL，OntologyExchangeLanguage），[2]简单的HTML本体扩展（SHOE，SimpleHTMLOntologyExtension），[3]和本体标记语言（OML，OntologyMarkupLanguage），[4]然而，资源描述架构（RDF，ResourceDescriptionFramework）[5]和RDF规范[6]是W3C组织（WorldWideWebConsortium）的工作团队生成的语言。最后，额外的两种语言是建立于RDF(S)――RDF和RDF规范的并集――之上，以便改善它的特征：本体交互语言（OIL，OntologyInterchangeLanguage）[7]和DAML+OIL[8]（图1所示）。
基于XML的本体交换语言（XOL）
为了在异构的软件系统中进行本体定义的交换，US的生物信息学领域设计了XOL。在研究了生物信息学专家的代表性需求后，研究人员创造了XOL。他们基于XML，选取Ontolingua和OML作为生成XOL的基础，并结合OKBC-Lite（开放知识基连通协议的子集，OpenKnowledgeBaseConnectivityprotocol）的高级表现和OML的语法。没有工具允许使用XOL开发本体论。然而，由于XOL文件使用XML语法，因此可以使用XML编辑器来生成XOL文件。
简单的HTML本体扩展（SHOE）
Maryland大学开发了SHOE，并用它来开发OML。SHOE是HTML的扩展，在HTML文档或其它Web文档中结合了机器可读的语义知识。最近，Maryland大学已经把SHOE语法适应到XML。SHOE能够使得Agent收集Web页面和文档的有意义的信息，改善搜索机制和知识聚集。这个过程由三个阶段构成：定义本体；用本体论的信息注释HTML页面，以便描述自身和其它的页面；Agent通过搜索现有的全部网页来语义地检索信息，并一直保持信息的更新。
本体标记语言（OML）
Washington大学开发了部分基于SHOE的OML。事实上，最初是把OML视为SHOE的XML顺序化。因此OML和SHOE共享很多特征。
资源描述架构和RDF规范（RDF和RDFSchema）
为了描述Web资源，W3C组织开发了RDF，允许以标准化的、可互操作的方式基于XML的数据的语义的说明规范。RDF也为明确地表述服务、过程和商业模型提供了机制，同时允许模糊信息的识别。
本体交互语言（OIL）
OIL建立于RDF(S)之上（图1所示）。OILEd、Protégé2000和WebODE都能够用来编辑OIL本体论。OIL的语法不仅能用XML表达，而且也能用ASCII表达。
DARPA的Agent标记语言+本体推理层（DAML+OIL）
US和欧盟（IST）的联合委员会在DAML的基础上开发了DAML+OIL，DAML是在XML中允许语义互用性的DARPA项目。因此，DAML+OIL与OIL共享同样的目标。
DAML+OIL建立于RDF(S)之上。它的名字间接地暗示出与OIL有着紧密的关系。它取代了最初称为DAML-ONT的规范，此规范也是基于OIL语言。OILEd、OntoEdit、Protégé2000和WebODE都是用来编辑DAML+OIL本体论的工具。
孔特征：阶梯孔、螺纹孔、固定孔、油孔、
Screwhole
以孔特征为例，具体的知识表达如下所示：
Unit:HoleinKBcapp.kbs孔的知识表达单元
Memberslot:TypefromHole孔的类型
Inheritance:OVERRIDE.VALUES
Valueclass:String
Values:Unknown
Memberslot:DiameterfromHole孔的直径
Valueclass:Real
Memberslot:LengthfromHole孔的长度
Memberslot:RoughnessfromHole孔的粗糙度
……
Memberslot:H_F_rlslfromcom_hF孔的规则集
Inheritance:Override.Values
Valueclass:RULES
Values:{
rule1规则1
fact_FRAME.Type=”Hole”如果：特征类型为孔
and_FRAME.Diameter<=20直径小于20
and_FRAME.IT<=10IT<=10
and_FRAME.Roughness<1.25Roughness<1.25
and_FRAME.Roughness>=0.7Roughness>=0.7
then_FRAME.H_RM_M1=”Drilling”;那么：工序1＝钻孔；
_FRAME.H_RM_T1=”DrillBit”;刀具1＝钻头；
_FRAME.H_RM_M2=”RoughReaming”;工序2＝铰孔；
_FRAME.H_RM_T2=”RoughReamer”;刀具2＝铰刀；
}
孔的加工链用规则表达形式如下：
Rule1:
factHole.Type=”hole”（类型x“孔”）
andHole.Diameter=20（直径（x）20）
andHole.Roughness>=1.25（（表面粗糙度（x）rs）（and（>=rs1.25）（ andHole.Roughness<5 andHole.IT>=8（（加工精度（x）ps）（and（>=ps8）（ andHole.IT<9 thenHole.H_RM_M1=”Drilling”;孔的粗加工工步：钻 Hole.H_RM_T1=”Drill”;粗加工孔的刀具 Hole.H_RM_M2=”Redrilling”; Hole.H_RM_T2=”RedrillBit”; Hole.H_RM_M3=”RoughReaming”;铰 Hole.H_RM_T3=”RoughReamer” Rule2: factHole.Type=”hole” andHole.Diameter>20 andHole.Roughness>=1.25 andHole.IT>=8 thenHole.H_RM_M1=”RoughBoring”;镗 Hole.H_RM_T1=”RoughBoreCutter”; Hole.H_RM_M2=”SemiFinishBoring”; Hole.H_RM_T2=”SFBoreCutter”; Hole.H_FM_M1=”FinishBoring”;孔的精加工工步 Hole.H_FM_T1=”FinishBoreCutter”精加工孔的刀具 Drilling：钻、Boring：镗、Milling：铣、Reaming：铰 《AMediatedArchitectureforMulti-AgentSystems》 每个Agent向注册服务中心发布它们的能力。 当顾问Agent接受来自元Agent的查询时，它首先检查自己的知识内容以便发现答案。如果答案可用，将把之发送给元Agent。如果没有响应容易可用，顾问Agent形成自己的查询，并试着开发答案通过利用自己内部的知识资源，以及其它的Agent。 图2多Agent知识Web体系架构 服务Agent管理专业Agent的已发布能力。当获得请求时，元Agent调用服务Agent来辨识适当的目的Agent为请求。目的Agent将通常是知识Agent，表示着唯一的专业领域。元Agent派发问题给目的知识Agent。在生成响应的过程中，知识Agent可能需要传递自己的查询给系统。元Agent再次使用服务Agent来发现匹配的目的Agent，并派发相应的问题。 元Agent的工作是在知识Agent之间进行征召和仲裁，以便取得一个目标。通过提供管理角度给多Agent操作，元Agent执行高级推理，或者对其它的推理能力进行推理。元Agent配合其它Agent的活动，利用它们单个的能力，并确保它们的响应的完整性。 当元Agent初始化一个知识交互时，它协商服务Agent为了有用知识Agent的身份。在交互的过程中，额外的Agent将被调入满足所需。需要时将产生联盟，并且很快解散。没有静态、固定的体系架构。在知识交互的任意时刻，仅存在着使用的机会关联。 图3逻辑符号Agent功能构件架构 《ClassAlgebraforOntologyReasoning》 随着基于Agent的技术开始出现在网络上，本体正在变得日益重要[AdamFarquhar[13]]。过去，每个公司有其自己的格式为它们的数据库，并通过形式来更新数据库，这是不同的为每个公司。现在，随着电子商务和Agent谈判变得更普遍，为Agent开发一个标准术语以便当它们谈判时使用是必要的。看上去好像XML正在变成发送带符号在线形式的标准语言，但是在XML记录内部，领域的定义依然依赖应用的本质。 本体推理服务器是有用的工具为开发普通共享的模型和术语。它充当数据库挖掘者，搜索“有意思的”子类和关联。它能生成决策树，基于树中任意节点上最“有意义的”属性来分类对象。它也能返回一套对象的“描述”。它还能为类似Prolog的规则制定建议，基于在它的ISA层次中类的扩展之间的子集关系。 类代数提供了一个自然架构为比较类的定义并使得几个公司定义一个公共的本体（即，类的“ISA”层次包含有属性、二元关系和方法）。与其它的OO模型相比，它具有几个优点。例如，CORBA提供了对象语义，但没有涉及ISA层次和继承的定义。ODMG2.0[4]包含多重继承的定义，但它的绑定到多个语言是不实用的。比如，Java绑定当前没有定义二元关系。语言模型像C++、Java和Smalltalk是相当复杂的，并且不一致如此基本的细节像：是不是包括多重继承、是否使用继承或者代理、普通函数怎样调用等等。对象导航符号（ONN，ObjectNavigatorNotation）[5]与类代数最相似，但由于包含三元关系，语法变得相当混乱。当前ONN也仅是用于OOD的符号，而没用于数据库查询。类代数是美好的“简单的”折衷，它包含多重继承、二元关系、以及具有覆盖的普通方法调用。 Framethingofthing. Frameuniversityofthing. Framedepartmentofthing. Framepersonofthing. FramefacultyMemberofperson. FramestudentoffacultyMember. FramestaffoffacultyMember. FrameresearchStudentofstudent. PersonhasSlotnameofBoolean. PersonhasSlotageofinteger. PersonhasSlothasDegreeofBoolean. PersonhasSlotenrolledofBoolean. FacultyMemberhasSlotuniofuniversity. FacultyMemberhasSlotdepofdepartment. StaffhasSlottenuredofBoolean. ResearchStudenthasSlotsupervisorofstaff. Instancealunofstaff. InstanceAndrewofresearchStudent. HasValue(alun,hasDegree,yes). Hasvalue(Andrew,supervisor,alun). Constraint XisaresearchStudentandyisastaff Where SlotValue(x,supervisor,y) Tohave SlotValue(y,uni,varu)andslotValue(x,uni,u). Rule120: ResearchStudenthasValueyesifstudenthasValueyesandtakesCourseshasValueno.