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

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

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

　　请继续

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

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

　　]>Issue catalogAn optional collection of resources for which issues have or canbe defined.　Use dc:relation to associate the catalog with itsresources.IssueA problem, suggestion or other matter for action or discussionrelevant to a resource.　Use Dublin Core properties for basedescription.issueAssociate an issue to its resourcesactionAssociate an action with an issueActionAn action to be taken with regard to an issueAssign toSpecify the party to whom the action is assignedstatusFor instance, "not done" or "done"commentAssociate a comment with an issueCommentA comment made with regard to an issue

　　您会注意到发生了一些变化，包括使用的名称空间也发生了变化。遗憾的是，我们不会象解释我们以前的 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 模式

　　]><!-- Note: requires expansion by RCS, CVS or the like$Revision$Ontology for an issue tracking system for arbitrary resourcesRelevant resourceAn implied classification of resources that have related issuesIssueA problem, suggestion or other matter for action or discussionrelevant to a resource.　Use Dublin Core properties for basedescription.issueAssociate an issue to its resourcesactionAssociate an action with an issueActionAn action to be taken with regard to anissueAssign toSpecify the party to whom the action is assignedstatusFor instance, "not done" or "done"commentAssociate a comment with an issueCommentA comment made with regard to an issue

　　存在标题出现在任何定义之前。这是一个 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. 更新的实例数据

　　]>Unnecessary abbreviationIs the abbreviation of rdf:type predicates in queries necessary?2001-03-04The abbreviation in listing 8 doesn't seem necessary to NicoChauvat or me.Organize a vote on this topicInconsistent versioningThe RIL versioning is not clear (there's a mix of 0.1, 0/1, 0.2and 0/2)2001-04-20Correct all to use the "0/1" form in the next draft.Alexandre FayolleUche OgbujiNicolas Chauvat

　　我们定义一个针对其提出样本问题的资源。按照 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 的开放查询语言，它将使我们提供的所有查询代码更简单和更快。