面向对象开发者语义网入门
本文由W3C
发布（http://www.w3.org/TR/2006/NOTE-sw-oosd-primer-20060309/
）
摘要
在从需求分析到设计的整个软件开发周期中，领域建模都起着中心作用。现在，在整个过程中一致性的使用模型已经取得了很大进步。支持UML和代码生成的软件开发工具以及模型驱动架构使得开发者可以用模型将技术应用与用户需求同步并进行验证。但是，由于定义模型时，领域模型由于只在其个体问题领域类寻找解决方案，进行有限的抽象，其重用性是有限的。但是网络不仅限于此，提供了几乎无限领域的多维答案空间。同时我们的许多软件都越来越多地嵌入到网页中，然而开发过程还没有完全应用来自于网络的模型重用潜力。因此，本文介绍语义网语言RDF和OWL，并且展示它们如何与主流面向对象语言轮流使用，我们将展示语义网可以作为一个领域模型建立、共享和重用的平台。
1．介绍
对软件系统而言，通常表达目标问题空间的领域模型都具有中心地位。领域模型可以从应用领域的角度描述相关概念和数据结构，并且编码对驱动应用程序行为的有用知识。例如，我们开发一个在线商店系统，在对其进行需求分析时，我们了解到：
1．
有一系列产品清单的订单与一个客户关联
2．
客户属于某个国家
3．
德国、法国和澳大利亚都是国家
4．
欧联是一个自由贸易区
5．
德国、法国是欧联的一部分
6．
来自与在线商店所在国签订了自由贸易协定的国家的客户的订单是免税的。
经过思考，我们可能会画出如下的面向对象的UML类图：
![simple domain model in UML]()
图1：基于UML语法的领域模型样例
我们可以将该图拿去与客户讨论，经过数轮后，我们可能会得到适合我们编程语言的数据结构。我们也可以从为最终用户定制的用户界面组件（可能是JavaServer页面）或者为在线商店经理定制的界面组件（可能需要更精致的用Java/Swing、C#或者VB写的前台应用）开始。如果我们的系统被证明是成功的，可以围绕其建立更多的组件，比如通过网络服务进入产品目录的组件。在这些情况下，其他组件可能要共享相同的数据结构和领域知识以便能够相互作用。即便我们的系统不是如此的成功或者被传送到另一个不同的平台，我们可以依然需要重用其中的一部分。此时，有某种办法进入领域模型来抽出需要的部分是有用的。
由于有这些潜在的期望，我们的系统采用“模型-视图-控制（Model-View-Control）”体系结构。这个著名的模式推荐将领域模型和用户界面与控制逻辑分离开来。这种可视组件与非可视组件的分离使在其它应用程序和应用平台上重用和共享领域模型更为方便。然而不幸的是，面向对象模型对重用性的承诺并没有完全实现。很多情况下，领域模型都包含有依赖于应用程序的硬代码。特别是一旦用某种编程语言对模型进行了编码，许多初始设计时的知识就损失了。例如，免税订单的条件可能以if语句的形式在相应的方法中实现（如UML图中的totalPrice（）），而除非你仔细阅读整个用户界面应用的控制逻辑，每张订单至少需要一个产品的事实就变得不太清楚了。这类系统的另一个问题是互操作性。例如，如果其它系统想从我们的系统获得数据或者服务，它可能需要通过与我们的应用程序紧密关联在一起的良好定义的接口（API）实现。也许会采用XML格式来实现这些应用程序间的信息交换。如果多个具有相似任务的应用程序需要相互作用，则需要大量的接口和格式交换。
在我们给出的例子的情节中，UML图提供了最大的重用和交互作用的潜能。这样的图形模型具有更高的抽象层次，可以被用来导出基于多种目的的应用代码。然而，即便两个应用程序或者组件都从UML图开始，它们也可能具有不兼容部分。依然需要很多手工代码来实现它们。应该采用什么样的格式来存储和共享客户数据？UML模型可能会有冲突或者被误解。在一个应用中，国家可能是以字符串存储的，而另外的应用则可能用国家类来表达。这两种情况都不清楚如何在UML表达如德国和法国这样的国家。此外，除非项目遵循了一致的模型驱动手段，在开发生命期中，UML图只是作为一个中间品，作为应用的基础但不能被其它开发者使用。在实际的应用项目中，UML通常不再需要修订，因此被收藏起来。其结果是软件开发需要花大量时间进行不必要的重复工作。领域模型一开始需要绘制草图，然后绘制成中间格式的图以便应用程序共享数据。
理想化的情况下，开发者可以从各种相关的仓库中发现共享的领域模型和知识库，然后将其与面向对象的用户界面组件和控制组件捆绑在一起—慢慢形成了“本体驱动架构（Ontology Driven Architecture）”的概念。共享重载领域模型的所有应用程序因此具有了一定的内在可相互作用性。这样的理想情况基本还是一种期望，一些有希望的手段正在浮现。
在不受主流软件工程阵营注意的情况下，互联网协会（W3C—Wide World Web Consortium）为语义网设计了一些非常有趣的技术。这些技术，包括RDF和OWL，已经初步实现了标记页面，使其能够被智能代理和网页服务理解的目的。然而有趣的是，它产生的语义网语言和工具可以在一般的软件开发中发挥主要作用。
语义网社团已经产生了一些列广受赞誉的语言和工具，用来开发、维护、使用和共享用于软件工程和其它目的的领域模型。在以OWL语言和RDF纲要（RDFS）为核心的架构中，OWL更适合用来从一个高的抽象层次表示结构化知识。以OWL编码的领域模型可以上载到网络上并被多个应用程序共享。OWL由称为描述逻辑（Description Logic）的没有歧义的形式逻辑语言支持。这种形式逻辑基础使其可以应用智能推理服务，比如自动分类和一致性检查。这些服务可以在构建期使用，因此可以方便地用来构造可重用的，被良好测试的领域模型。推理也可以用于各种目的的运行期服务。比如，它使运行期的动态分类，实例再分类和复杂的逻辑查询成为可能。除了它们的逻辑基础外，OWL和RDFS与面向对象语言具有类似的结构，因此可以有效地与传统的软件组件集成在一起。
总之，与面向对象语言相比，RDFS和OWL具有以下主要的益处：
l
重用性和互作用性：RDF和OWL模型可以在应用程序间和网页上共享。
l
柔性：RDF和OWL模型可以在一个开放的环境中运行，在这个环境中，类可以被动态定义。
l
一致性检查和质量检查贯穿模型
l
推理：OWL具有由自动推理工具支持的丰富的表达性。
注意上述的部分益处，如一致性检查和自动推理，也可以通过对象约束语言（OCL—Object Constraint Language）获得。OCL是用于模型驱动架构的OMG系列语言的一部分，提供了与现代语义网语言类似的表达性。例如图1中的约束可以用OCL重新表达来形成免税订单条件。然而，OCL并不是设计来用于网络，而是在一个更加封闭的数据模型中表达约束。语义网技术面向一个开放的世界，其模型可以被多个应用和团体共享。我们会在稍后的语义网语言中说明其开放性。值得注意的是在面向对象语言和OWL之间的区别是不可能桥接的。实际上，一个OMG的工作组定义了一个本体元模型，该模型使开发者可以将语义网语言和其它诸如OCL格式一起协同工作。
本文试图解释如何在语义网技术的协助下设计和应用面向对象的应用程序。第2部分给出了一个在应用程序开发周期中如何利用语义网技术获得益处的概要。第3部分介绍语义网语言RDFS和OWL，并将其与面向对象语言比较。第4部分显示RDF和OWL模型如何嵌入到面向对象程序中（这里，采用了Java）。附录给出了进一步阅读的资料，工具和图书馆。
2．采用语义网技术开发应用程序
什么是语义网？现在绝大部分的“传统网页”都是适合于人阅读的。其表达语言如HTML包含了Web浏览器指令以指示其如何显示多媒体描述来使我们的视觉和听觉能够理解。然而，如果我们想让计算机程序来搜索基于Web的信息，将会发现现有的办法非常难以理解这些Web页面，除非这些计算机程序具有非常高级的人类语言技能。同时，同时代的服务器侧的Web语言，如JSP和ASP，支持单一文件中的视觉和模型的随机混合，这导致了非常不结构化的内容。
语义网的最后动机是产生机器可阅读的网页，这样网页就可以非常容易地被软件代理分析和由网页服务共享。为此目的，互联网协会（W3C）推荐了一系列可以用于网页内容格式化的网页语言。RDFS和OWL可以被用来象面向对象语言一样描述类，属性和关系。比如，RDFS可以定义一个Product（产品）类，它具有一个浮点数类型的hasPrice（价格）属性。你也可以定义一个Purchase（交易）类以及它的与多个产品关联的hasProducts（产品）属性。OWL通过添加定义更为复杂的类的能力扩展了RDFS。例如，OWL可以用来定义一个DutyFreeOrder（免税订购）类作为交易类的子类，该类对每个国家都有一个与之签订了自由贸易协定的地址清单。W3C也与其他语言一起描述if-then规则和复杂的SQL类的查询。不过这里，我们将讨论重点集中在RDFS和OWL。
与你发布HTML网页一样，基于这些语言的领域模型可以上载并与网页相连。例如，一个显示产品的HTML页面可以编码元数据使其连接回一个基于OWL模型建模的相应实体，这样，所有的应用程序都可以通过HTML页面来理解该产品是什么。此外，特定产品的供货商也可以通过一个RDFS类实例，以一种没有歧义的可交换的格式来通知购货代理其部长是谁。这样一个语义网应用的典型场景如图2所示。
![exploiting domain models and services from the Web]()
图2 一个采用语义网技术的应用程序可以从网页上使用领域模型和服务。图中，黄色框以类UML符号的形式表示OWL文件。注意，UML符号仅仅是一个例子，也可采用其它可视方式来完整表达OWL语义
同时，一定程度上的互作用性也可以通过传统的XML方式来获得，而语义网语言具有更丰富的表达能力。与面向对象语言类似，RDFS和OWL使定义子类和建立概念层次成为可能。将领域模型组织进类的方式意味着继承模型组织进软件模块的自然映射。此外，因为每一个语义网资源都有一个唯一的URI，因此有可能在已有的模型之间建立联系。这意味着不论什么时候一旦一个领域模型在网上发布，就有可能在它的基础上建立其它模型，并由此而建立一个领域内的，也可能是跨领域的，知识网络。
语义网语言的可扩展性支持其全球范围内的可重用性。不用建立第1000个产品交易领域模型，应用程序开发者可以简单地重用或者扩展一个网上的合适的模型。通过重用已有的模型，具有类似任务的应用程序可以非常容易地共享结果和数据。更进一步，一个独立于应用程序的组件（如购物篮应用或者信用卡网络服务）可能被集成起来。虽然现在就期望在不远的将来在语义网的基础上实现全球知识共享有些太过奢望，RDFS和OWL至少提供了一个在感兴趣的领域间进行通信的可重用的基础结构。这超出了本文想要详细讨论的范畴。
能具有重用性部分因为语义网语言是基于网络的：在RDFS和OWL中的每个类、属性和对象都具有一个唯一的标示（URI），因此它可以从任何一个其它地方定位。另外一个使语义网模型具有重用性的主要原因是它是基于形式逻辑的。这意味着OWL模型不仅仅只限于定义类及其属性，也可以限制这些类的潜在实例，因此这些类可以无歧义地在人和机器间共享。这样基于良好定义的逻辑的领域模型通常被归类为本体。实际上，OWL就是“Web Ontology Language”的缩写。根据[OWL 2004]，OWL可以直接用来表达词条的意义及这些词条间的相互关系。词条及其间相互关系的表述就是本体的另一种形式。以面向对象的观点看，本体是包含其意义明确表达的逻辑描述的领域类。稍后我们将展示称作推理机的工具可以使用这些逻辑描述来完成能够显示资源间隐含关系的高级查询。
本体和领域模型经常跨越不同的抽象层次，应用程序依赖性和重用性。回顾介绍中的例子，陈述1和2描述客户和交易数据的数据结构。陈述3、4和5表述国家，它可以用于地理或者行政应用程序。陈述6独立于国家的描述，表达了作为国家判定条件的领域关系。这部分可以从标准解决方案中重用。实际上，本体通常由某个团体定义（如电子商务协会或者国家地理勘探）以便与其用于信息集成的领域共享词汇表联系起来。一旦一个国家及其关系的标准本体已经存在，则没有必要为每个单独的应用程序重写本体。此外，重用网上已有本体的另一个好处是应用程序可以直接受益于诸如新国家等的更新。
但是，对特定的国家而言，特定的客户我在线商店的所在地是一个应用程序级描述，需要与客户相适应。这种适应可以通过特定的子类或者实例来获得。如果共享本体/领域模型对特定的应用程序来说不是最优的，则可以在此基础上进行修改或者重建，这可以利用领域模型工具（如附录中列出的）来完成。这类工具适合于具有很少或者没有程序语言知识的领域专家。与UML编辑器相比，这些工具具有可试化的对类和其间关系的编辑界面，允许用户创建这些类的实例。
可以将这种领域模型建模的开发程序与传统的软件开发需求分析进行对比。领域专家、最终用户与软件工程师、开发者和测试员通力合作，一起完成对领域模型的恰当抽象。来自网络的本体被组合、扩展和实例化。本体开发工具提供实例化类的方便手段，以便样例的建立和样本化。最终的领域模型与应用程序的其它组件，如程序编制的用户界面和控制逻辑，相组合。与传统的面向对象的设计方法比较，面向对象的分析和设计只为代码生成产生一个中间的过渡产品，而语义网络方法中同样的模型贯穿了从分析、设计、执行到测试甚至使用的所有步骤。初期的本体定义确定了应用的所有类，同时，在应用程序执行过程中，这种初期的设计模型仍然是可以访问的。隐藏在本体后面的形式逻辑甚至可以用来导出测试用例。如果领域模型有一个明确的运行语义，它可以更进一步地使用推理服务。在我们对RDF和OWL进行简单介绍之后，我们会更进一步来探讨这个问题。
3．RDFS和OWL简介
为了实现语义网的意图，W3C定义了一系列的描述语言。RDF及RDF纲要提供了以符合网络的格式表达类、属性和实例的基础，OWL则扩展了RDF纲要使其具有更丰富的表达性。现在，两种语言都有工具、解析器和编程API的支持。本部分对RDF纲要和OWL做一简介并与面向对象语言进行对比。
3.1.RDF和RDF纲要（RDFS）
RDF（Resource Description Framework）[RDF2004]是一种可以形式化描述资源建联系的网页语言。资源是具有统一资源标示URI的任何东西。因为具有URL，HTML网页、图像和多媒体文件都是资源。在RDF中，资源还可以是类、属性和实例。比如，统一资源标示http://ecommerce.example.org/ecommerce.rdf#Product就可以在RDF文件中表达一个类，你也可以使用这个URI给特定的产品网页做注释。
RDF只为语义网内容定义了最基本的语法，有一系列的XML代码允许用户在网页上共享模型。RDF纲要为RDF定义了一个面向对象模型。RDF纲要定义了如何申明类、子类、关系、属性和数据类型等。如，下面的RDF纲要文件申明了一个Product（产品）类和一个属性hasPrice（价格）：
<rdf:RDF xml:base="http://ecommerce.example.org/ecommerce.rdf"
xmlns="http://ecommerce.example.org/ecommerce.rdf#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdfs:Class rdf:ID="Product"/>
<rdf:Property rdf:ID="hasPrice">
<rdfs:domain rdf:resource="#Product"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
</rdf:Property>
</rdf:RDF
该片断远远不能描述RDF、RDF纲要和XML语法的细节。本文档的目的仅仅是建立几个重要的概念。URI通常被划分为命名空间和本地名字，命名空间可以有前缀符号缩写。例如，如果前缀rdfs已经在文件头申明了的话，rdfs:Class就是统一资源标示
http://www.w3.org/2000/01/rdf-schema#Class的缩写。如果没有给出前缀（如Product），就使用文件的隐含命名空间。为了文档表述的简化，我们将重点集中在本地名字的短符号上。
RDF纲要中的类是具有共享特征的一组个体的集合。和UML一样，RDF纲要支持多继承。然而，与面向对象语言的一个主要区别是RDF中的所有类都可以重载。因为可以可以有多个类型，这意味着一个实例可以被多个类共享。更进一步，实例可以在生命周期中更改其类型。一个订单可以在开始的时候作为PurchaseOrder（订单）类的计划实例，然后在程序收集到更多的客户交货地址后更改为DutyFreeOder（免税订单）类的实例。
语义网和面向对象语言的另一个主要区别是语义网是开放的，文件中可以添加现有资源的新的信息。因为网页是一个任何东西都可以与其它东西连接的巨大的空间，不可能推断出一个叙述是否为真，或者是否会变为真。例如，我们定义了一个类，我们通常不知道它以后具有的所有实例。同样我们也不可能推断出一个特定的产品是否同时也是一个拍卖项目。这个“开放假定”意味着语义网的建模领域可能需要那些习惯于“经典”的面向对象系统和“传统”的关系数据库的开发者转换其思维。另一方面，它也提供了一个在无限世界的重用和互操作性的柔性和共享经验的回报。特别是，一个开放的方法意味着一个基于网页的公共本体可以通过在另外一个类定以中添加子类或者添加概念的附加特征来限制它们使用不同的应用程序的情况。在类似Java程序这样的封闭的系统中这是不容易，或者方便实现的。
现在让我们回到RDF语言本身。RDF中的属性properties可以与面向对象语言中的属性、字段或者相关的结点类比。但是，UML和Java中的属性只能够属于一个类，RDF的属性是一个独立的实体，可以分离于类进行定义并被多个类使用。例如，你可以定义一个hasPrice（价格）属性然后将它赋予所有的具有价格功能的类。这也可以使在多个文件中重用属性成为可能。例如，如果你建立一个在线拍卖的软件模型，你可以使用在线商店模型中的价格属性来描述在线拍卖中的价格。在多个模型中共享同一个类意味着更容易在值上集成，例如将现行的拍卖价格与另一个在线商店的新产品价格进行比较。
为了将属性“附着”或者“联系”到一个类或者，可以使用rdfs:domain语句。rdfs:domain是RDF纲要命名空间中的一个标签，它使用谓词将一个属性和一个类关联起来。在上面的例子中，hasPrice的定义域（domain）是类Product。这样，从面向对象的观点来看，Product类的所有实例都具有与之关联的价格值，这样就构成了产品价格属性。不过，在RDF和OWL中这还包含一个内涵：任何具有hasPrice条目的东西都是Product类的实例。换句话说，RDF中的定义域domain可以用来对实例分类。因此，对于上面的例子可以肯定地说，一个物品如果有价格，不管它使否与其它的申明（第三者）共享，该物品一定会被作为Product的实例。更关键的问题会在后面的OWL推理中详细讨论。
在这种方式下，RDF中的如价格这样的原始值被称为字面值（literals），字面值以XML纲要中的数据类型如xsd:float和xsd:string作为其类型。还可以使用语句rdfs:range来限制属性的值的类型。一个属性可以以XML纲要的数据类型，也可以以类作为其取值范围（值域range）。将类作为其值域的属性可以与面向对象语言中的关系类比。例如，如果属性hasCustormer（有客户）具有值域Customer（客户）类，则所有该属性的值必须是客户。与定义域语句domain相似，range语句也可以以另外一种方式解读：如果我们知道一个资源以某种方式与hasCustormer属性关联，我们则可以推断出该资源实际上是一个客户Customer，而不管它是否也具有其它的类型。
3.2．OWL
如前所述，RDF纲要定义了一个与面向对象语言类似的简单的领域模型语言。你可以定义类及其属性，然后创建这些类的实例。这对很多情况都是有用的。然而，在许多应用领域，RDF纲要的表达能力是不够的。例如，RDF不能表达基数来约束一个产品只有一个价格。
网页本体语言（OWL—Web Ontology Language）[OWL2004]采用与RDF相同的基本语法扩展了RDF纲要。OWL提供了对属性特征的更强的表达能力，以及通过满足这些特征的实例集合来定义类的能力。为了更好地理解，很重要的是要记住OWL的类是公理的集合。如图3所示，这些集合可以重载，也可以相互包含。
![OWL classes as sets of instances]()
图3 OWL类可以被认为是一组具有公有特征的实例的集合
图3中左边的圆圈表示所有来自澳大利亚的东西的类，右边的圆圈表示所有产品类的实例。两个大圆圈的交集表示同时是产品，也来自澳大利亚的东西的实例，也就是澳大利亚的产品。产品中的小圈表示与德国作贸易的产品，它是产品集合的子集。最后，所有与德国进行贸易的澳大利亚的产品则由所有类的交集表示。
记住RDF/OWL的属性是独立于特定的类的，可以在多处使用。例如，属性hasOrigin（源自）可以用于产品、人、客户、音乐或者任何其它东西。假设澳大利亚已经在某个地方被定义为国家类Country的一个实例，现在，任何人都可以利用OWL来定义一个类其中的所有事物的hasOrigin属性都取值为澳大利亚。这样所有由其它人定义的实例现在都可以用这个定义来分类。
表达着类定义的OWL语言元素被称为约束restriction。一个约束表示类的所有实例在该属性上都实行一个特定的条件。OWL有多种类型的约束。我们称上面的例子的约束为取值hasValue约束，它将一个属性连接到特定的个体。另外的约束限制属性的基数，例如，定义一个类的所有事物的hasOrigin属性都至少有两个值。
这里不需要讨论约束的细节。OWL的关键能力在于它可以通过组合多个约束和其它类来定义类。为此目的，OWL提供了逻辑运算符来构建其它类的交（and）、并（or）和补（not）。例如你可以定义“所有的没有订购DVD的来自法国的客户，他们都至少有3个订单或者有1个书本订单的类”。
在面向对象系统中，这样的描述通常都被隐藏在基础代码的某个地方。在语义网本体中，逻辑关系通过类定义和其它的形式描述被显示地表达。这不仅仅意味着使用模型的其他人能够更容易地理解其内在含义，也意味着其它工具可以明确地使用定义。OWL定义简单地声明事物，然后等待应用程序使用这些定义来做某种有益的事情。
一些语义网应用程序可以使用其它工具来掌握和分析OWL模型。推理机就是这样一类工具。推理机是这样一种服务，它将陈述编码（断言）输入某个本体并从中导出（推理出）新的陈述。对于OWL推理机而言，可以用于：
l
显示类的父/子关系
l
确定个体最详细的类型
l
检测类定义的不一致性
这样，我们可以构造如下恰当的例子：假设你定义了一个免税订单类DutyFreeOrder，它由其客户都生活在签订了自由贸易协定国家的PurchaseOrder订单类组成。现在假设一个新用户登录进在线商店并将物品放入他自己的购物篮内。在内部，我们需要创建客户类Custormer和订单类PurchaseOder的空实例。随后，当用户开始检查并输入其地址的时候，我们可以调用推理机来分类该订单。其结果是返回给我们该特定订单所属的最详细的类（这里，返回DutyFreeOrder）。此后，拥有一个免税订单的事实将会导致该对象的一个新的控制生命周期，因为应用程序逻辑又展示了关于免税订单的新的领域知识。
与对象通常不能改变其类型的面向对象系统不同，基于语义网技术的应用程序采用了形式化的，同时也是动态的类型系统。RDF和OWL类本身也是动态的，可以在运行时创建和处理。例如，可以利用OWL的形式化语法定义一个临时类，并调用推理机对该类的实例进行推理。这意味着可以将推理机比喻为一个丰富的查询系统。这些查询不仅可以在本体构建是产生，也可以在运行时产生。
3.3． OWL/RDF与面向对象语言的比较
总结上述对RDF和OWL的介绍，下表列出了语义网语言和面向对象语言间的重要异同。
|
面向对象语言
|
OWL
和RDF
|
|
领域模型由类、属性和实例（个体）组成。类可以具有子类及其继承层次。属性值可以为对象或者值（字面值）。
|
|
类和实例
|
|
类被认为是实例的类型
|
类被认为是个体的集合
|
|
每个实例只有一个类类型，类不能共享实例
|
每个个体可以属于多个类
|
|
实例不能在运行时改变其类型
|
类的成员可以在运行时变化
|
|
编译时具有所有类的清单，并且不能在其后变化
|
类可以在运行时建立和改变
|
|
在构建时使用编译器，编译错误指示问题
|
在构建和运行时由推理机进行分类和一致性检查
|
|
属性，属性和值
|
|
属性在类内定义（派生类通过继承）
|
属性是独立实体，可以不依赖于任何类存在
|
|
实例只能拥有属于其属性的值，值必须是正确的类型，值域约束用于类型检查
|
实例可以拥有任意属性的任意值，值域和定义域约束用于类型检查和类型推理
|
|
类通过强制性函数和方法编码其大部分意义和行为
|
类通过OWL语句显示表达其意义，不可以添加强制性代码
|
|
类可以封装其成员为私有
|
RDF/OWL文件的所有部分都是公有的，并可以任意连接到其它地方
|
|
封闭的：如果没有足够的信息证明陈述是针对，则假设为假的
|
开放的：如果没有足够信息证明陈述是真的，则它可能是真的或者假的
|
|
设计过程的作用
|
|
一些通用的API在应用程序间共享。少量的UML图（如果有的话）共享
|
RDF和OWL从本地到网页设计。领域模型在线共享
|
|
领域模型被当作软件架构的一部分设计
|
领域模型用于表达领域知识，以及用于信息集成
|
|
UML，Java和C#等是由许多商务和开源工具支持的混合技术
|
语义网是一门新技术，由一些开源工具和少量商务工具支持
|
|
其它特征
|
|
实例是匿名的，不易从运行程序外部定位
|
所有命名的RDF和OWL资源都有唯一的URI，可以被引用
|
|
UML模型可以在XML中串行化并在工具间交换，但并不是真正基于网页的。Java对象可以被串行化为各种基于XML的格式或者本地中间格式
|
RDF和OWL对象具有标准的基于XML的串行化方式，并在其中存储了资源的唯一URI
|
4．用RDF纲要和OWL编程
许多现代软件架构都由面向对象组件构成，并应用于主流编程语言如Java和C#中。在胖客户系统中，许多用户界面和控制代码都采用面向对象库如Swing和SWT编写。在客户-服务器结构中，服务器可能是完成与数据库和其它资源通讯的企业JavaBean（EJB）的宿主。在网络服务中，许多控制逻辑都要应用强制式的，面向对象的方法。
为了将语义网技术的优点应用于这样的面向对象系统上下文中，软件架构需要理解设计和决策模式来无缝地集成这些技术。当我们仅仅是初步理解语义网技术在系统和软件工程中的含义的时候，包括编程接口API和代码生成器在内的许多有希望的选择方案已经出现。本部分我们将概要叙述本体驱动软件开发的艺术并讨论它的一些基本概念。
要理解本体驱动架构的关键必须记住本体语言是：
l
属性独立于特定的类
l
实例可以有多种类型并且可以根据分类结果改变其类型
l
类可以在运行时动态定义
这些关键的区别隐含了不能简单地将OWL/RDF纲要类映射为具有其属性固定于类等特征的面向对象类。如果一个应用程序想使用OWL/RDF纲要的弱类型和柔性的话，它必须将OWL/RDF类映射到某个运行对象上，以便使本体中的类成为面向对象类的实例。如图4所示，一个典型的表达语义网本体的对象模型可能包含表示资源、类、属性和个体的类。注意条目RDFSClass和RDFProperty与RDF纲要中定义的类rdfs:Class和rdf:Property相关联，同时，条目RDFIndividual在RDF纲要中没有对应的定义。
可以容易地设想对各种类型的OWL类和属性的更进一步的扩展（参见完整的OWL对象模型的Protégé OWL图）。
![simple model representing RDF Schema]()
图4 一个表达RDF纲要本体的面向对象模型样例
应用程序可以将本体装载进这样的对象模型中，并在运行时处理和查询对象。因为OWL/RDF纲要类是对象，所以可以在运行时添加和修改这些类，比如在运行时改变本体的逻辑特征。因为RDF属性是对象（其值并没有作为面向对象的属性存储），则可以动态地修改和查询任何资源的值。因为个体是对象，则可以动态修改其类型。
这种由动态方法开发进行驱动的方法在主流软件技术中称为动态对象模型（Dynamic Object Model）模式[RTJ 2005]。对特定的面向对象系统而言，通过将对象类型表述为对象，它们可以在配置时和运行时改变，这使改变和修改系统来适应新的需求变得容易。
在语义网通讯中，部分API接口采用了这种模式。附录中列出了Java、C和PHP的公共库清单。除了动态对象模型接口外，这些库还提供了解析器，推理接口和操作本体的其它各种接口。为了体会如何使用这样的库，给出如下的Java程序片断（对给定客户所有交易求和的方法）：
public static float getPurchasesSum(RDFIndividual customer) {
OWLModel owlModel = customer.getOWLModel();
float sum = 0;
RDFProperty purchasesProperty = owlModel.getRDFProperty("purchases");
RDFProperty productProperty = owlModel.getRDFProperty("product");
RDFProperty priceProperty = owlModel.getRDFProperty("price");
Iterator purchases = customer.listPropertyValues(purchasesProperty);
while(purchases.hasNext()) {
RDFIndividual purchase = (RDFIndividual) purchases.next();
RDFIndividual product= (RDFIndividual) purchase.getPropertyValue(productProperty);
Float price = (Float) product.getPropertyValue(priceProperty);
sum += price.floatValue();
}
return sum;
}
该代码是通用和柔性的，但同时该方法也有一些缺点。如果类和属性是运行时对象，则强类型系统的优点则不能在编译时使用。这会变得非常不方便，访问属性值和代码会因为访问属性等操作变得臃肿。此外，通过名字对资源的访问被编码为字符串，这样编译器便不能帮助进行错误检查。从面向对象应用的观点看，上述操作的更好的应用方法应该如下所示：
public class Customer extends RDFIndividual {
public float getPurchasesSum() {
float sum = 0;
Iterator purchases = listPurchases();
while (purchases.hasNext()) {
Purchase purchase = (Purchase) purchases.next();
Product product = purchase.getProduct();
sum += product.getPrice();
}
return sum;
}
}
不是访问通用的诸如RDFIndividual和RDFProperty类，我们应该访问用户定制的诸如Purchase和Product那样的类。幸运的是，有可能构造和使用这样的类而不必牺牲动态对象模型的优点。代码生成器可以以RDF纲要和OWL类作为输入并将生成的面向对象的接口和应用类作为输出。附录中列出了一些可选择的代码生成器。在前面的例子中，代码生成器建立Customer的Java接口，定义属性定义域中有Customer的属性的get和set方法（即getEmail，setEmail）。这些接口是动态对象模型API中的通用类（如RDFIndividual）的子类。这意味着接口的实例同时也是“常规”的RDFIndividual，同时生成的接口作为其上的一个方便的顶层次来使用。
![accessing models using generic API or using classes]()
图5 语义网模型既可以通过通用的API也可以通过特定领域类来访问
运行时对象同时也是通用的，动态的API意味着开发者可以根据任务来使用不同的API。对于推理、解释、查询和输入确认这样一般性的服务可能会采用动态对象模型API。通用的代码具有最大的重用潜力，将来也会有越来越多的处理RDF和OWL的组件出现。这个观点对于本体驱动系统的开发方法是有其内在含义的。如果存在通用的推理和查询组件，软件设计者就应该更多地采用RDF/OWL来编码领域模型，并因此提高常规服务领域的抽象水平。例如，对于签订了自由贸易协定的国家的订单免税可以在方法，如Java类PuchaseOrder的isDutyFree（）方法，内部实现。但是，这将使通用的推理机不可能自动地对贸易订单进行分类。一个更无瑕疵的解决方案是在OWL本体内定义一个DutyFreePurchaseOrder子类，并与描述逻辑语句一起来定义免税订单和其它订单的区别。可重用性和通用服务是采用明确的语义定义领域模型的基本原因。
除了本体驱动软件开发的期望，理解什么时候不能使用语义网技术也是很重要的。最重要的是，本文中提到的许多推理机都具有可测性和性能上的问题。OWL DL本体的分类可能是个冗长的任务并因此限制了运行时分类的用处。推理机的性能问题在构建期中则不是那么关键。
另一个一般性的语义网问题与本体的重用性极限有关。要建立一个真正领域独立的和可重用的本体非常困难。此外，本体建立通常很难也很昂贵，面对如此庞大的投资许多软件公司不会简单地上载并在网络上共享。这超出了本文的论述范围，但值得我们注意。
附录：进阶材料
API连接
l
Java
n
Jena – 语义网络框架(http://jena.sourceforge.net/)
n
WonderWeb OWL API (http://wonderweb.man.ac.uk/owl)
n
Protege OWL API (http://protege.stanford.edu/plugins/owl/api)
l
C
n
Redland – RDF应用程序框架 (http://librdf.org/)
l
PHP
n
pOWL – 语义网开发平台(http://powl.sourceforge.net/)
l
代码生成器
n
RDFReactor (http://rdfreactor.ontoware.org/)
n
Kazuki (http://projects.semwebcentral.org/projects/kazuki/)
n
Jastor (http://jastor.sourceforge.net/)
基础支持和工具连接
l
Protege-OWL本体编辑器 (http://protege.stanford.edu/plugins/owl)
l
OntoEdit/OntoStudio – 本体工程环境 (http://ontoedit.com/)
l
SemanticWorks RDF/OWL 编辑器( http://www.altova.com/products_semanticworks.html)
l
SMORE – HTML页面OWL标记 (http://www.mindswap.org/2005/SMORE/)
l
SWOOP – 轻量本体编辑器 (http://www.mindswap.org/2004/SWOOP/)
l
OntoMat Annotizer ( http://annotation.semanticweb.org/ontomat)
进阶在线文档
l
Semantic Web Activity (Semantic Web Activity)
l
RDF Primer (http://www.w3.org/TR/rdf-primer/)
l
Tutorial on OWL (http://www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/)
本体样例连接
l
SchemaWeb - A comprehensive directory of RDF schemas and OWL ontologies (http://www.schemaweb.info/default.aspx)
l
DAML Ontology Library (http://www.daml.org/ontologies/)
l
Ontoware - Ontology repository ( http://www.ontoware.org)
l
Protege-OWL Ontology library (http://www.owl-ontologies.com/)
SW应用程序样例连接
l
SWCLOS - A Semantic Web Processor on Common Lisp Object System (http://iswc2004.semanticweb.org/demos/32/)
l
Swoogle - A Semantic Web Search Engine (http://swoogle.umbc.edu/)
l
Bibster - A Semantics-Based Bibliographic Peer-to-Peer System (http://bibster.semanticweb.org/)
l
Ontoware - Semantic Web related Software Projects (http://www.ontoware.org/)
标准参考
[BCCG 2004]
Visual modeling of OWL DL ontologies using UML. Saartje Brockmans, Andreas Eberhart, Raphael Volz, Peter Löffler In S.A. McIlraith et al., Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, 2004, pp. 198-213. Springer, November 2004.
[BHS 2003]
Description Logics. Baader, Franz, Horrocks, Ian, and Sattler, Ulrike. Volume Handbook on Ontologies in Information Systems of International Handbooks on Information Systems, chapter I: Ontology Representation and Reasoning, pages 3-31. Steffen Staab and Rudi Studer, Eds., Springer. 2003.
[BMRSS 1996]
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Buschmann, Frank, Meunier, Regine, Rohnert, Hans, Sommerlad, Peter, and Stal, Michael. John Wiley and Son Ltd., 1996.
[BMT 2005]
Case Studies on Ontology Reuse. Elena Paslaru Bontas, Malgorzata Mochol, Robert Tolksdorf. 5th International Conference on Knowledge Management (I-Know=9205). 2005.
[BCCG 2003]
Reasoning on UML Class Diagrams. Berardi, D., A. Caly, D. Calvanese, and G. De Giacomo TR-11-2003, Dipartimento di Informatica e Sistemistica, Universita di Roma, La Sapienza (2003)
[G 2003]
Ontology-oriented programming: Static typing for the inconsistent programmer. Neil M. Goldman. In 2nd International Semantic Web Conference (ISWC 2003), Sanibel Island, FL, 2003.
[KPBP 2004]
Automatic mapping of OWL ontologies into Java. Aditya Kalyanpur, Daniel Jimenez Pastor, Steve Battle, and Julian Padget.In 16th International Conference on Software Engineering and Knowledge Engineering (SEKE), Banff, Canada, 2004.
[ODM 2005]
Ontology Definition Metamodel. OMG Ontology Working Group. 2005.
[OWL 2004]
Web Ontology Language (OWL) Overview. McGuinness, Deborah L. and van Harmelen, Frank. W3C Recommendation. 2004.
[RDF 2004]
RDF Primer. Frank Manola, Erik Miller. W3C Recommendation. 2004.
[RTJ 2005]
Dynamic Object Model. Dirk Riehle, Michel Tilman, and Ralph Johnson. In Dragos Manolescu, Markus Völter, James Noble (eds.) Pattern Languages of Program Design5. Reading, MA: Addison-Wesley, 2005.
[TPOWUK 2005]
Ontology Driven Architectures and Potential Uses of the Semantic Web in Software Engineering. Tetlow, Phil, Pan, Jeff, Oberle, Daniel,Wallace, Evan, Uschold, Mike, and Kendall, Elisa. W3C Working Draft. 2005
扫一扫
134
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
