Uche Ogbuji 继续研究 RDF 如何与 XML 相结合以能够进行知识管理。在这一部分中，他深入研究了 RDF 世界中的建模，而且开始考虑开发问题跟踪程序的模式以及它与面向对象和关系建模之间的相似与不同。读者将学习各种技巧、技术和最佳实践，以便从 XML 数据开发有效的知识 管理模型。
目前为止，在对问题跟踪程序应用的研究中，我已经通过示例讨论了从 XML 数据抽取 RDF 数据、实现这一抽取的技术以及与 RDF 有关的无谓纷扰引起的一种简洁的语义搜索功能。现在，我将进一步研究各模式在使用 RDF 将知识管理功能部件构建到 XML 应用程序中时所起 的作用。
关系与对象数据库模式，以及甚至 XML 模式，都为数据驱动的应用程序提供文档、指导和控制。RDF 模式更为宽松和一般化；它们陈述放入 RDF 模型中的资源的分类。在这一部分和下一部分中，我们将同时使用 W3C RDF 模式（RDFS）规范和“DARPA 代理标 记语言／存在推论语言（DARPA Agent Markup Language/Ontology Inference Language，DAML+OIL）”来考虑问题跟踪程序 RDF 语句的模式。DAML+OIL 是 W3C 规范的重要扩展和改进。对 RDFS 和 DAML+OIL 有些熟悉是有用的，尽管我会对在我的示例和讨论中所运用的大部分概念进行介 绍。
那只代表了您的类
RDFS 和 DAML+OIL 都以资源分类为中心。在本专栏的前几部分中，您可能已经注意到问题跟踪程序 RDF 没有足够的分类。事实上，目前为止，它根本没有使用过任何类和类型。这对 RDF 系统毫无问题。就问题跟踪程序来说，由于几乎任何资源都可以用问题来标记 — 而且问题几乎可 以是我们能附加作者、注释和操作的任何事物 — 所以严格的分类可能不自然，而且只会起阻碍作用。
不过，RDF 的长处之一是：它不需要那种许多面向对象（OO）语言所要求的严格的分类。它关于类和类型的概念更一般化，并可以由模型设计者来解释。类可以是您可能要用于资源的任何一种组织的核心。它不必是一个有条理的树，如生物的科学分类。例如，在 XML 世界中，“采购订 单”常常作为一个几乎不可能标准化的文档示例（即使想尽办法使用 XML）使用。这是因为有无数方法可以对 PO 进行分类、细分类和常规地设想。所以特别设计了 RDF 来调节这种混乱。
通过提出了将类作为类型的自然指示符这一想法，RDFS 引入了一些 OO 开发的世界观。确实有许多 RDF 实现都遵循这一示例，也许是因为 OO 技术近来已广受瞩目。但是，我认为有一点非常重要值得注意：该模式对 RDF 本身来说并不是根本的。
这些都是相当深奥的概念，因此需要一个具体的示例。想想电话号码。如果我们要以某种分类模式搞清电话号码，那就有许多方法可以考虑：电话号码是一种号码。 电话号码是一种联系数据。 电话号码是一种资产（询问那些为保留可以在数字小键盘上拼出它们商标的免费电话号码而竞争的美国企业）。 免费号码是一种电话号码。 传真号码是一种电话号码。
您会发现有些典型的层次结构具有 OO 思想显而易见的特点。您还会发现有些重叠和尝试性的分类易于在已建立的 OO 实践中导致问题。如果您想引发一次讨厌的问题，只要向任何一个 OO 开发人员询问“死亡钻石”或“不能飞的鸟”。以上，“kind of”常常映射为 OO 概念的“is-a”关系，而且通常将对象类型定义为 OO 实现语言的内置语义的结果。
但是，在现实世界中，存在的类型要比类多。看看下列语句：501-555-1111 是 Mark 的工作号码。 500-555-1234 是 Mark 的家庭号码。 使用 500-555-1234 作为 Mark 的紧急联系号码。 在 555 交换机以外的地方，必须用 10 位拨号方式拨打 555-1234。
这些语句都定义了一个电话号码的特征。它们的分类没有第一组示例清楚，而且事实上在 OO 世界观中，可以用许多方法（如属性和关联）来表示它们，而很少使用类型化。但是，考虑到人们通常思考此类特征的方法，没有理由认为它们不是与第一组语句差不多的类型。很自然地认为“工作号码是一个类型（type of）的电话号码”，而对于 501 区号内的位置，“10 位号码”自然就是一个“类型”的电话号码。在 RDF 中，应该使用 rdf:type 谓词来表示这些特征。事实上，请考虑 vCard/RDF 提议，它是一个 W3C 注释：建议从非常流行的 vCard 联系规范模式转换到 RDF。vCard/RDF 使用 rdf:type 来区分工作号码和家庭号码、传真号码和语音号码、因特网邮箱和 Lotus Notes 邮箱等。它也将 rdf:type 用在公共 RDFS 含义中：表示在其数据模型中的分类。
但是，如果以这样有分歧的方法使用相同的谓词（ rdf:type ），不会产生含糊不清的危险吗？我认为这种情况要求将 rdf:type 的各种使用细化，而且 RDFS 最好是引入 rdf:type 的子特性，称为 rdfs:type ，如果那太混淆的话，干脆使用 rdfs:classificationType 。 同样地，vCard 可以创建 rdf:type 的子特性，称为 vCard:contactType ，来区分它所用类型的各种概念。
问题的计划
问题跟踪程序不需要执行许多与类型化和分类有关的简洁操作，但是以上的讨论激励了这一想法：何不相当松散地构造类型、类及其它模式事物呢？在我曾参与的许多 RDF 项目中，为了推敲出这一模式，常会坐在放着许多面包圈和咖啡因饮料的桌子旁苦思冥想。这是从 OO 开发和关系 DBMS 世界中借鉴过来的一种清教徒般的认真。但是，迄今在使用问题跟踪程序时，我甚至在转而同意这一模式之前就已经使用了一些实例。没有任何理由可以不这样做。我们将问题附加到任何基于 Web 的资源，并且写出关于这些问题极其松散的语句。
该谈谈模式了。清单 1 是一个 XML 片段，说明了一个问题的 RDFS 类：
清单 1. Issue 类
<rdfs:Class ID="Issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>A problem, suggestion or other matter for action
or discussion relevant to a resource</rdfs:comment>
</rdfs:Class>
该代码声明了一个问题的内联（因为使用 ID ）RDFS 类。注意 label 和 comment — 我想它们是非常重要的，而且在我的实践中，我需要每个定义的资源（特别是模式元素）都有这两者。label 尤其重要，因为智能 RDF 工具能够使用它们为资源提供用户友好的名称，而不是难看的 URI。
清单 2. Author 类以及 issue 和 author 特性
<rdfs:Class ID="Author">
<rdfs:label>Author</rdfs:label>
<rdfs:comment>A person raising or posting an issue</rdfs:comment>
</rdfs:Class>
<rdfs:Property ID="issue">
<rdfs:label>issue</rdfs:label>
<rdfs:comment>Associate an issue with its resource
</rdfs:comment>
<rdfs:range rdf:resource="#Issue"/>
</rdfs:Property>
<rdfs:Property ID="author">
<rdfs:label>author</rdfs:label>
<rdfs:comment>Associate an issue with whoever posted it
</rdfs:comment>
<!-- Where the <i>dc</i> entity has been set to the
Dublin Core metadata element base URI -->
<rdfs:subPropertyOf rdf:resource="&dc;creator"/>
<rdfs:domain rdf:resource="#Issue"/>
<rdfs:range rdf:resource="#Author"/>
</rdfs:Property>
这里，我们定义了特性 issue 。range 语句声明任何有 issue 谓词的语句的宾语，其 rdf:type 必须为 Issue 。我们没有对这种语句（应为 domain 语句）的主语做任何这样的限制，因此实际上，任何资源都可以有 issue 谓词，这是我们的意图。用 domain 和 range 定义了 author 特性，该特性成为 Dublin Core 中“creator”元数据元素的子特性。这意味着任何有 author 特性的 issue 都自动声明还有 dc:creator 特性。这是 一个普通而有用的技术，在这种情况下意味着熟悉 Dublin Core 的代理软件将在一定程度上能够处理我们的问题跟踪程序元数据，而不会有任何问题。这一诀窍其实是语义的 Web 基础的一部分。
如果此时您已经回到实例数据以与我们正在构建的模式进行比较，则可能正在迷惑：“但是，这与我们一直在使用的实例并不匹配呀。”例如，我们有实例：
清单 3. 以前实例中的代码片段
<rdf:Description about='&ril-spec;ril-20010502'>
<rit:issue rdf:resource='#i2001030423'/>
</rdf:Description>
<rdf:Description ID='i2001030423'>
<it:author rdf:resource='&ril-users;#uogbuji'/>
</rdf:Description>
这好象违反了我们设置的约束，因为没有将 ID i2001030423 的资源的 rdf:type 声明为 Issue ，也没有将 ID“uogbuji”的资源的 rdf:type 声明为 Author 。
是否真的违反了模式实际上可能取决于我们如何解释模式。最常见的解释是：如果在模型中没有语句满足约束的条件（如 domain 或 range），则该模型是不一致的 — 通常是一个错误情况。这被称为 RDF 模式的一个限制性角色。它也是有时称为“封闭世界”假设的一部分，因为在查询 时，它不考虑任何模型中不明白的事物。
但是，有另一个不太常用但非常有趣的方法。在本文中定义的约束之一宣称：如果某个资源有 author 特性，则它的 rdf:type 必须是 Issue 。那么，就可以根据 i2001030423 资源上存在所说的特性推理出它必定有所需的类型。简而言之，处理器可以有效地生成满足约束的语句。这被称为 RDF 模式的一个生成性或推断性作用。这近似于人们如何处理实际世界的变迁，因而也近似于语义的 Web 后面功能强大的想法。但是，有了这一功能，也带来了知识表示方面的棘手缺陷。
在此学到的最重要的教训是：即使我们从原型 RDF 实例开始，并且逐步建立了一个乍看好象我们之前的努力都是无效的模式，但是所有这一切都是对的。多亏 RDF 的宽宏大量（我不会随便用这个词），所以一切都是对的。作为一个经验丰富的建模者／设计者，我必须说这一能力和灵活性是 RDF 基本优势之一，也是它很难被按传统 OO 和关系思考的人所掌握的原因之一。
结束语
我们已经到达这一部分的结尾，但是我希望您会发现在我们进行的过程中介绍和讨论重要的建模概念是有用的。如果是我刚开始学习可扩展元数据，我会很感谢有这样的过程。在本专栏的下一部分中，我们将使 RDFS 形式的问题跟踪 程序模式更趋完美，还会讨论这一模式的 DAML 形式。
