当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

Thinking XML #9: 知识管理的基本 XML 和 RDF 技术

第五部分：定义 RDF 和 DAML+OIL 图示

Uche Ogbuji (uche.ogbuji@fourthought.com), CEO 和首席顾问, Fourthought, Inc.

Uche Ogbuji 是 Fourthought Inc.的顾问兼合伙创始人，该公司是专为企业知识管理应用提供 XML 解决方案的供应商和咨询公司。Fourthought 开发了 4Suite 和 4Suite 服务器，它们是 XML 中间件的开放源码平台。Ogbuji 先生是一名出生于尼日利亚的计算机工程师兼作家，他生活和工作在美国科罗拉多州的博耳德。可以通过 uche.ogbuji@fourthought.com与 Ogbuji 先生联系。

简介： Uche Ogbuji 继续定义问题跟踪应用程序的 RDF 与 DAML+OIL 图示，继续同以前一样讨论建模。

标记本文！

发布日期： 2002 年 3 月 01 日
级别： 初级
访问情况： 1713 次浏览
评论：

在本专栏的上一篇文章中，我讨论了诸如 RDF 这样的 XML 知识管理系统是如何另辟蹊径解决数据设计与建模这些老问题的。我的目的是要准确说明问题跟踪程序包的模式，我曾使用问题跟踪程序包来演示将 RDF 同 XML 应用程序一起使用。现在，我将以 RDFS 和 DAML+OIL 形式完成问题跟踪程序模式的定义。

这里，同样需要熟悉 RDF、RDFS 和 DAML+OIL。写完上一篇文章之后，我已与同事 Roxane Ouellet 一起发表了 DAML+OIL 简介（请参阅参考资料），因此，您再也不用埋头翻阅厚厚的规范来掌握它了。

请继续

言归正传，下面给出的清单 1 是问题跟踪程序的完整 RDFS。

清单 1. 问题跟踪程序的 RDFS 模式

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY it "http://rdfinference.org/schemata/issue-tracker/">
<!ENTITY dc "http://purl.org/dc/elements/1.1/">
]>
<rdf:RDF
xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:it="&it;"
>
<rdfs:Class rdf:about="&it;Catalog">
<rdfs:label>Issue catalog</rdfs:label>
<rdfs:comment>
An optional collection of resources for which issues have or can
be defined.  Use dc:relation to associate the catalog with its
resources.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about="&it;Issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>
A problem, suggestion or other matter for action or discussion
relevant to a resource.  Use Dublin Core properties for base
description.
</rdfs:comment>
</rdfs:Class>
<rdfs:Property rdf:about="&it;issue">
<rdfs:label>issue</rdfs:label>
<rdfs:comment>Associate an issue to its resources</rdfs:comment>
<rdfs:range rdf:resource="&it;Issue"/>
</rdfs:Property>
<rdfs:Property rdf:about="&it;action">
<rdfs:label>action</rdfs:label>
<rdfs:comment>Associate an action with an issue</rdfs:comment>
<rdfs:domain rdf:resource="&it;Issue"/>
<rdfs:range rdf:resource="&it;Action"/>
</rdfs:Property>
<rdfs:Class rdf:about="&it;Action">
<rdfs:label>Action</rdfs:label>
<rdfs:comment>
An action to be taken with regard to an issue
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about="&it;it:assignee">
<rdfs:label>Assign to</rdfs:label>
<rdfs:comment>
Specify the party to whom the action is assigned
</rdfs:comment>
<rdfs:domain rdf:resource="&it;Action"/>
</rdfs:Class>
<rdfs:Class rdf:about="&it;status">
<rdfs:label>status</rdfs:label>
<rdfs:comment>For instance, "not done" or "done"</rdfs:comment>
<rdfs:domain rdf:resource="&it;Action"/>
</rdfs:Class>
<rdfs:Class rdf:about="&it;comment">
<rdfs:label>comment</rdfs:label>
<rdfs:comment>Associate a comment with an issue</rdfs:comment>
<rdfs:domain rdf:resource="&it;Issue"/>
<rdfs:range rdf:resource="&it;Comment"/>
</rdfs:Class>
<rdfs:Class rdf:about="&it;Comment">
<rdfs:label>Comment</rdfs:label>
<rdfs:comment>A comment made with regard to an issue</rdfs:comment>
</rdfs:Class>
</rdf:RDF>

您会注意到发生了一些变化，包括使用的名称空间也发生了变化。遗憾的是，我们不会象解释我们以前的 RDF 示例没有使用任何定义的类那样详尽地解释这些变化。这一模式表示了 RDFInference.org 的问题跟踪程序当前正在使用什么，包括由于各种原因所做的变化。我将稍后提供实例 RDF 的相应更新。

我也采用了一些词法约定：首先，我将所有的名称空间 URI 定义为 DTD 内部子集中的实体（这一约定是我从 Ouellet 女士那里学来的），这一约定减少了错误并改善了可读性。于是，我只使用 rdf:about ，而不再使用 rdf:ID ，在艰辛地经历了与对包含文档的假设 URI 解析 ID 有关的所有缺陷之后，最近，我采用了这一约定。请注意，只有在能确保有一个显式的 xml:base 声明，以及需要互操作性的所有 RDF 处理程序都支持 XML 基础时，我才使用 rdf:ID 。

Catalog 类提供了一种方法，来聚合所有拥有问题或允许用户为其创建问题的资源。这主要为应用程序提供便利。请想象一下跟踪程序的一个基于 Web 的表单。它可能有一个感兴趣资源的下拉选择框。一种填充该列表的方法是从给定的目录检查所有 dc:relation 语句的对象。而我将要提供的 DAML+OIL 模式则演示了另外一种方法。

还有其它几个小小的变化，例如为了词类更一致的使用，将“assigned-to”重命名为“assignee”。除此之外，在这一模式中没有什么值得奇怪的，好了，让我们继续了解 DAML+OIL 版本。

回页首

DAML 的特点

DAML+OIL 是一个模式系统，它提供了对 RDFS 的关键改进，其中包括一个内置的数据类型确定系统、枚举支持、特性专门化以及通过推论进行分类与确定类型。它也超出了纯粹的示意图，它允许我们定义存在（ontology），我们对概念的理解大概就是这样的，但是目前我们主要还是使用基本的示意功能。清单 2 是类似于清单 1 的问题跟踪程序的 DAML+OIL 模式。

清单 2. 问题跟踪程序的 DAML+OIL 模式

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY xsd "http://www.w3.org/2000/10/XMLSchema#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY daml "http://www.daml.org/2001/03/daml+oil#">
<!ENTITY dc "http://purl.org/dc/elements/1.1/">
<!ENTITY it "http://rdfinference.org/schemata/issue-tracker/">
]>
<rdf:RDF
xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:daml="&daml;"
xmlns:xsd="&xsd;"
xmlns:it="&it;"
>
<daml:Ontology rdf:about="">
<daml:versionInfo>
<!-- Note: requires expansion by RCS, CVS or the like
$Revision$
</daml:versionInfo>
<rdfs:comment>
Ontology for an issue tracking system for arbitrary resources
</rdfs:comment>
<daml:imports rdf:resource="http://www.w3.org/2001/10/daml+oil"/>
</daml:Ontology>
<daml:Class rdf:about="&it;RelevantResource">
<rdfs:label>Relevant resource</rdfs:label>
<rdfs:comment>
An implied classification of resources that have related issues
</rdfs:comment>
<rdfs:subClassOf>
<daml:onProperty rdf:resource="&it;issue"/>
<daml:toClass rdf:resource="&it;Issue"/>
</rdfs:subClassOf>
</daml:Class>
<daml:Class rdf:about="&it;Issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>
A problem, suggestion or other matter for action or discussion
relevant to a resource.  Use Dublin Core properties for base
description.
</rdfs:comment>
</daml:Class>
<daml:ObjectProperty rdf:about="&it;issue">
<rdfs:label>issue</rdfs:label>
<rdfs:comment>Associate an issue to its resources</rdfs:comment>
<rdfs:range rdf:resource="&it;Issue"/>
</daml:ObjectProperty>
<daml:ObjectProperty rdf:about="&it;action">
<rdfs:label>action</rdfs:label>
<rdfs:comment>Associate an action with an issue</rdfs:comment>
<rdfs:domain rdf:resource="&it;Issue"/>
<rdfs:range rdf:resource="&it;Action"/>
</daml:ObjectProperty>
<daml:Class rdf:about="&it;Action">
<rdfs:label>Action</rdfs:label>
<rdfs:comment>An action to be taken with regard to an
issue</rdfs:comment>
</daml:Class>
<daml:ObjectProperty rdf:about="&it;it:assignee">
<rdfs:label>Assign to</rdfs:label>
<rdfs:comment>
Specify the party to whom the action is assigned
</rdfs:comment>
<rdfs:domain rdf:resource="&it;Action"/>
</daml:ObjectProperty>
<daml:ObjectProperty rdf:about="&it;status">
<rdfs:label>status</rdfs:label>
<rdfs:comment>For instance, "not done" or "done"</rdfs:comment>
<rdfs:domain rdf:resource="&it;Action"/>
</daml:ObjectProperty>
<daml:ObjectProperty rdf:about="&it;comment">
<rdfs:label>comment</rdfs:label>
<rdfs:comment>Associate a comment with an issue</rdfs:comment>
<rdfs:domain rdf:resource="&it;Issue"/>
<rdfs:range rdf:resource="&it;Comment"/>
</daml:ObjectProperty>
<daml:Class rdf:about="&it;Comment">
<rdfs:label>Comment</rdfs:label>
<rdfs:comment>A comment made with regard to an issue</rdfs:comment>
</daml:Class>
</rdf:RDF>

存在标题出现在任何定义之前。这是一个 DAML 约定，它描述文档、确定模式（因此使用空的 rdf:about ，它将文档本身设置为主题）。它的一个特征是有一条修订语句，我是使用由修订控制系统扩展的关键字来定义该语句的。其另外一个特征是一个导入，它是由 DAML+OIL 添加的一个显式机制，目的在于将来自其它文件的定义合并到当前文件（在 DAML 出现之前，您要么必须将多个源定义合并成一个模型，要么使用诸如 XInclude 的较低级别的机制）。作为标准实践，我导入核心 DAML+OIL 模式，为特定于 DAML+OIL 的资源添加定义。

接下来是一个特殊的类 RelevantResource ，它没有显式地声明其实例，而是由对实例特性的推论定义实例。更进一步地研究 RelevantResource 类可以搞清楚这一点。它被定义为匿名内联资源的子类，而匿名内联资源类型又是 daml:Restriction 的类型。这是一个特殊的 DAML+OIL 机制，它允许您根据实例具有的特性以及这些特性的值来定义规则。在这个例子里，约束条件选择所有具有 issue 特性并且该特性的值属于类 Issue 的资源。通过从这一约束条件划分子类， RelevantResource 类成为一种包含一个所有满足该约束条件资源集合的虚拟类。如果在任何时候资源获得具有适当类值的适当特性，那么无需显式声明，它会自动成为这一虚拟类的成员。

在您可能还没有控制正在操作的所有信息空间时，这是一项非常重要的功能，这也是为什么要推出 DAML+OIL 的缘故，DAML+OIL 的推出在巩固 Semantic Web 的这类技术方面向前跨了一大步。在更恰当的例子中，这一功能允许我们无须为问题跟踪显式地注册所有资源，如同我们以模式的 RDFS 形式（使用 Catalog 类）所做的那样。

我使用 daml:Class 定义所有的类，它是 rdfs:Class 的子类，而 rdfs:Class 提供 DAML 所引入的所有附加功能。类似地，我使用 daml:ObjectProperty 定义特性。问题跟踪程序模式不使用具体的数据类型（字符串、整数等等）来定义任何特性的值，但是需要说明的是，这些特性在 DAML+OIL 中是作为 daml:DatatypeProperty 的子类定义的。

DAML+OIL 模式实际上就是在 RDFInference.org 应用程序中所使用的那种模式，而且我们也将它用作本专栏继续下去的基础。

回页首

更新实例

由于那些我所提到过的变化，我回顾并更新了到目前为止在本专栏中我们一直在研究的问题的样本实例，请参阅清单 3。

清单 3. 更新的实例数据

<?xml version='1.0'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY daml "http://www.daml.org/2001/03/daml+oil#">
<!ENTITY dc "http://purl.org/dc/elements/1.1/">
<!ENTITY foaf "http://xmlns.com/foaf/0.1/">
<!ENTITY it "http://rdfinference.org/schemata/issue-tracker/">
<!ENTITY rit "http://rdfinference.org/ril/issue-tracker/">
]>
<rdf:RDF
xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
xmlns:daml="&daml;"
xmlns:rit="&rit;"
xmlns:it="&it;"
xmlns:dc="&dc;"
xmlns:foaf="&foaf;"
xmlns="&it;"
>
<rdf:Description rdf:about='http://rdfinference.org/ril/ril-20010502'>
<issue rdf:resource='&rit;i2001030423'/>
<issue rdf:resource='&rit;i2001042003'/>
</rdf:Description>
<Issue rdf:about='&rit;i2001030423'>
<dc:title>Unnecessary abbreviation</dc:title>
<dc:creator rdf:resource='mailto:Alexandre.Fayolle@logilab.fr'/>
<dc:description>
Is the abbreviation of rdf:type predicates in queries necessary?
</dc:description>
<dc:date>2001-03-04</dc:date>
<comment rdf:parseType="Resource">
<dc:creator rdf:resource='mailto:Alexandre.Fayolle@logilab.fr'/>
<dc:description>
The abbreviation in listing 8 doesn't seem necessary to Nico
Chauvat or me.
</dc:description>
</comment>
<action rdf:parseType="Resource">
<dc:description>Organize a vote on this topic</dc:description>
<it:assignee rdf:resource='mailto:uche.ogbuji@fourthought.com'/>
</action>
</Issue>
<Issue rdf:about='&rit;i2001042003'>
<dc:title>Inconsistent versioning</dc:title>
<dc:creator rdf:resource='mailto:Nicolas.Chauvat@logilab.fr'/>
<dc:description>
The RIL versioning is not clear (there's a mix of 0.1, 0/1, 0.2
and 0/2)
</dc:description>
<dc:date>2001-04-20</dc:date>
<action rdf:parseType="Resource">
<dc:description>
Correct all to use the "0/1" form in the next draft.
</dc:description>
<it:assignee rdf:resource='mailto:uche.ogbuji@fourthought.com'/>
</action>
</Issue>
<rdf:Description rdf:about='mailto:Alexandre.Fayolle@logilab.fr'>
<foaf:name>Alexandre Fayolle</foaf:name>
</rdf:Description>
<rdf:Description rdf:about='mailto:uche.ogbuji@fourthought.com'>
<foaf:name>Uche Ogbuji</foaf:name>
</rdf:Description>
<rdf:Description rdf:about='mailto:Nicolas.Chauvat@logilab.fr'>
<foaf:name>Nicolas Chauvat</foaf:name>
</rdf:Description>
</rdf:RDF>

我们定义一个针对其提出样本问题的资源。按照 DAML+OIL 模式， http://rdfinference.org/ril/ril-20010502 自动成为 RelevantResource 类的成员。另外一个重要的变化是我们通过 mailto URL 来和某个人联系，该 URL 然后使用“朋友的朋友”（FOAF）链接到他们正常的姓名，“朋友的朋友”是一种有名的确定个人联系信息的 DAML+OIL 模式，它适合于描述谁属于某个电子邮箱。请注意，在 RDF 中有另一个有名的选择可用于建模联系信息，它基于普通的 vCard 格式，将联系信息作为电子邮件的附件嵌入。vCard RDF 模式比 FOAF 模式覆盖面更广，但是我们不需要其额外的特性。如果我们需要的话，还有一个基于 FOAF 的选项：FOAFCorp，它将同公司结构有关的元素添加到 FOAF 中的核心个人概要信息。

生成这个表单而不是原来的表单的 XSLT 的变化很小 ― 主要是文字结果元素名称和名称空间 URI 的变化。

回页首

结束语

通常，即使您希望以松散的方式应用在本专栏上一篇文章中讨论过的约束，您也应该有某种模式供文档使用（如果不用于其它东西的话）。RDFS 仍然是最简单、最普遍的选择，但是 DAML+OIL 有许多好的方面，还是值得推荐：不仅是额外的功能，而且还包括更清晰的核心语义。既然问题跟踪程序有了一个模式，我们将继续下去，改进我们构造查询的方式：我们将研究 Versa，它是一种用于 RDF 的开放查询语言，它将使我们提供的所有查询代码更简单和更快。

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文.
请通过单击本文顶部或底部的讨论来参与本文的论坛。
除了我在上一篇专栏文章中所列出的简介资源之外，现在有一篇 Roxane Ouellet 和 Uche Ogbuji 撰写的 Introduction to DAML: Part I。
有一个管理个人概要信息的“朋友的朋友” （FOAF）模式。还有 FOAFCorp，它为表达企业实体的结构添加了更多详细信息。
Representing vCard Objects in RDF/XML是由 Renato Iannella 撰写的 W3C 注解。