本体
在计算机科学与信息科学领域，理论上，本体是指一种“形式化的，对于共享概念体系的明确而又详细的说明”[1]。本体提供的是一种共享词表，也就是特定领域之中那些存在着的对象类型或概念及其属性和相互关系[2]；或者说，本体就是一种特殊类型的术语集，具有结构化的特点，且更加适合于在计算机系统之中使用；或者说，本体实际上就是对特定领域之中某套概念及其相互之间关系的形式化表达（formal representation）。本体是人们以自己兴趣领域的知识为素材，运用信息科学的本体论原理而编写出来的作品。本体一般可以用来针对该领域的属性进行推理，亦可用于定义该领域（也就是对该领域进行建模）。此外，有时人们也会将“本体”称为“本体论”。
作为一种关于现实世界或其中某个组成部分的知识表达形式，本体目前的应用领域包括（但不仅限于）：人工智能、语义网、软件工程、 生物医学信息学、图书馆学以及信息架构。
概述
英文术语“ontology”一词源于哲学领域，且一直以来存在着许多不同的用法。在计算机科学领域，其核心意思是指一种模型，用于描述由一套对象类型（概念或者说类）、属性以及关系类型所构成的世界。尽管不同的本体对于这些构成成分的确切称谓有所不同，但它们却都是一部本体不可或缺的基本要素。一般来说，人们所普遍期望的一点就是，本体之中模型的那些特征应当非常类似于相应的现实世界[3]。
就计算机科学与哲学来说，二者所说的本体之间的共同之处就在于，它们都是依据某种类别体系，来表达实体、概念、事件及其属性和相互关系。就计算机科学与哲学来说，二者所说的本体之间的共同之处就在于，它们都是依据某种类别体系，来表达实体、概念、事件及其属性和相互关系。
本体往往等同于那些由各种类、类之定义以及归类关系（subsumption relation）所构成的分类法层次结构，但本体并不一定仅限于此类形式。同时，本体也并不局限于保守型的定义（也就是传统逻辑学意义上的那些定义，它们所引入和采用的仅仅是术语，而没有添加任何有关现实世界的知识）[9]。要明确而又详细地说明所要表达的某个概念之时，我们需要声明若干的公理，从而对所定义术语的那些可能解释加以约束和限制[10]。
本体构成要素
就现有的各种本体而言，无论其在表达上采用的究竟是何种语言，在结构上都具有许多的相似性。如前所述，大多数本体描述的都是个体（实例）、类（概念）、属性以及关系。在这一节当中，我们将分别依次论述本体的这些构成要素。
常见的本体构成要素包括：
- 个体（实例）：基础的或者说“底层的”对象。
- 类：集合（sets）、概念、对象类型或者说事物的种类[注释 1]。
- 属性：对象（和类）所可能具有的属性、特征、特性、特点和参数。
- 关系：类与个体之间的彼此关联所可能具有的方式。
- 函数术语：在声明语句当中，可用来代替具体术语的特定关系所构成的复杂结构。
- 约束（限制）：采取形式化方式所声明的，关于接受某项断言作为输入而必须成立的情况的描述。。
- 规则：用于描述可以依据特定形式的某项断言所能够得出的逻辑推论的，if-then（前因－后果）式语句形式的声明。
- 公理：采取特定逻辑形式的断言（包括规则在内）所共同构成的就是其本体在相应应用领域当中所描述的整个理论。这种定义有别于产生式语法和形式逻辑当中所说的“公理”。在这些学科当中，公理之中仅仅包括那些被断言为先验知识的声明。就这里的用法而言，“公理”之中还包括依据公理型声明所推导得出的理论。
- 事件 (哲学)：属性或关系的变化。
领域本体与上层本体
领域本体（domain ontology或者说domain-specific ontology，即领域特异性本体）所建模的是某个特定领域，或者现实世界的一部分。领域本体所表达的是那些适合于该领域的那些术语的特殊含义。例如，就拿具有许多种含义的英文单词“card”来说。关于扑克领域的本体可能会赋予该词以“打扑克”的意思，而关于计算机硬件领域的本体则可能会赋予其“穿孔卡片”和“视频卡”的意思。
上层本体（upper ontology或者说foundation ontology，即基础本体）是指一种由那些在各种各样的领域本体之中都普遍适用的共同对象所构成的模型。其中所收录的核心词表，可以用来描述一套领域当中的对象。目前，存在着几部现成可用的标准化上层本体，包括都柏林核心、通用形式化本体（General Formal Ontology，GFO）、OpenCyc/ResearchCyc、推荐上层合并本体（Suggested Upper Merged Ontology，SUMO）以及DOLCE。另外，有些人认为WordNet属于上层本体，但实际上它并不是一部本体：WordNet只是由一部分类法（taxonomy）与一部受控词表所形成的独特组合（参见上述关于“属性”方面的内容）。
领域本体在表达概念时采用的是非常特殊而又往往具有选择性的方式，因而它们常常缺乏兼容性。随着那些依赖于领域本体的系统的扩展，它们往往需要将不同的领域本体合并成一部更为通用的表达形式。对于本体设计者来说，这就提出了一项富有挑战性的难题。在同一领域内，由于文化背景、受教育程度以及意识形态的不同所造成的，对于该领域感知（perceptions）情况的不同，或者因为所采用的表达语言的不同，还可能出现不同的本体。
当前，对于那些并非依据同一部基础本体所编制的本体的合并工作，在很大程度上还是一种手工过程，因而既耗费时间又成本高昂。那些利用同一部基础本体所提供的一套基本元素来规定领域本体元素之含义的领域本体，则可以实现自动化的合并。目前，存在着多项针对本体合并方面的通用技术方法的研究工作，但这个方面的研究在很大程度上依然还处于理论层面。
本体语言
本体一般都是采用本体语言来编制的。本体语言，又称为“本体论语言”，是一种用于编制本体的形式化语言。目前，存在着许许多多此类的本体语言，既包括专有的，也包括基于标准的：
普通逻辑（Common logic）就是ISO标准24707；这是关于一种本体语言家族的技术规范，其中的本体语言彼此之间可以准确地相互转换[14]。
- Cyc项目有其自己的，基于一阶谓词演算，且具有某些高阶扩展的本体语言（即CycL）[15]。
- Gellish语言之中包括了关于自身扩展的规则，因而集成了一部本体和一种本体语言[16]。
- IDEF5是一种用于编制和维护准确的，具有可复用性的领域本体的软件工程方法[6]。
- 知识交换格式（Knowledge Interchange Format，KIF）是基于S-表达式的一种一阶逻辑语法[17]。
- 规则交换格式（Rule Interchange Format，RIF）与F-逻辑（F-Logic）可将各种本体和规则结合起来[18]。
- OWL（Web Ontology Language）是一种用于编写本体声明（ontological statements）的语言。OWL的发展继承了RDF和RDFS以及一些早期的本体语言项目，包括本体推理层（Ontology Inference Layer，OIL）、DARPA智能体标记语言（DARPA Agent Markup Language，DAML）以及DAMLplusOIL。OWL旨在应用于万维网之上；而且，其构成要素（类、属性和个体）均被定义为RDF资源，并采用URI加以标识[19]。
本体库
为互联网开发各种本体的工作，已经孕育出那些具有搜索功能的，提供本体目录（directories）或列表的服务。此类目录就称为“本体库”。
如下是一些采用人工方式选择出来的本体所构成静态库：
- CO-ODE项目本体库[43]：提供的是一些与CO-ODE项目相关的本体示例和本体资源链接。
- DAML本体库（DAML Ontology Library）[44]之中保存的是那些采用DAML格式的历史遗留本体。
- Protege本体库（Protege Ontology Library）[45]之中收录的是一套采用OWL格式、基于框架的格式以及其他格式的本体。
- SchemaWeb[46]则是一个由采用RDFS、OWL以及DAML+OIL格式所表达的RDF模式（RDF schemata）而构成的目录。
常用本体工具
本体服务器
CO-ODE本体浏览器：又称为“OWLDoc Server”，即OWL本体文档服务器，用于动态生成HTML OWLDoc文档，功能类似于Protégé本体编辑器之中的OWLDoc插件。
本体编辑器
用于编纂本体的软件编辑器称为“本体编辑器（ontology editor）”，有时又称为“本体论编辑器”。
- Protégé https://protege.stanford.edu/
- Neon工具箱
- OilEd
- MediaWiki的扩展：允许在维基网页之中标注语义数据的语义MediaWiki（Semantic MediaWiki，SMW）。
- OntoWiki：一个自由的开源型语义维基应用，旨在作为本体编辑器和知识获取系统
一点总结
本体论是在试图建立一个工业领域的通用建模工具时接触到的，我们首选的是OPC-UA，并基于OPC-UA进行裁剪，在使用过程中，我们发现，OPC-UA对于工业领域是基本适用的，语义完整，且经过业界验证；但也存在某些缺点，就我们的需求来说，作为一个统一建模工具，其NodeClass对于Attribute的约束过于严格，出于不同服务器间互联互通的考虑，这是必须的，但对于构建一个灵活的建模工具来说，这些约束显得多余。
OWL是本体论语言，相较于OPC-UA，应当处理建模领域的底层，其中的本体论内涵在OPC-UA中也有继承，从整个物联网领域来看，无论是Predix还是Thingwrox都能找出本体论的痕迹。
具体到我们现在面临的问题，无论是OPC-UA还是OWL都无法很好的满足需求，这可能就需要我们博采众家之长，紧密结合用户和应用场景不断进化。
<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">