XML 观察: 使用 XML 描述开放源代码项目，第 3 部分

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

Edd Dumbill (edd@xml.com), 编辑兼发行人, xmlhack.com

2004 年 7 月 01 日

这一期的 XML 观察中，Edd Dumbill 继续开发描述开放源代码项目的词汇表的开发，他给出了新词汇表的模式和示例项目描述。

本系列的前两篇文章中，我分析了描述开放源代码项目的 XML/RDF 词汇表的原理和设计问题。DOAP（Description of a Project，项目描述）词汇表应该能够满足项目维护者（他们发现需要在无数的网站上注册自己的软件）以及寻找并交换这类信息的人员的需要。 第 1 部分列举了目前这方面的研究，定义了项目的边界。 第 2 部分提出了词汇表的候选术语，并强调了一些设计问题。

本文将给出 DOAP 词汇表的初步草案，和一些项目的示例描述。本文中包含大量的例子，建议在阅读的过程中练习创建自己的 DOAP 描述。

概述

我将使用 RDF 模式语言讨论 DOAP。虽然 DOAP 很容易作为 XML 使用，但是您将看到它从根本上是一个 RDF 词汇表。要注意本文中使用的两个 RDF 模式概念： 类和 属性。在 RDF 中，类是一种资源类型，就像在 Java 编程语言中类是对象的类型一样。属性是资源和其他资源或者文字值的联系。其他介绍 RDF 的 developerWorks文章请参阅 参考资料.

在开始介绍 DOAP 词汇表的术语之前，先看一看这个简单的示例 DOAP 文件，清单 1 是 DOAP 项目本身的最小化描述：

<Project xmlns="http://usefulinc.com/ns/doap#"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:foaf="http://xmlns.com/foaf/0.1/">
        <name>DOAP</name>
        <homepage rdf:resource="http://usefulinc.com/doap" />
        <created>2004-05-04</created>
        <shortdesc xml:lang="en">
            Tools and vocabulary for describing community-based
            software projects.
        </shortdesc>
        <description xml:lang="en">
            DOAP (Description of a Project) is an RDF vocabulary and
            associated set of tools for describing community-based software
            projects.  It is intended to be an interchange vocabulary for
            software directory sites, and to allow the decentralized
            expression of involvement in a project.
        </description>
        <maintainer>
            <foaf:Person>
                <foaf:name>Edd Dumbill</foaf:name>
                <foaf:homepage rdf:resource="http://usefulinc.com/edd" />
            </foaf:Person>
        </maintainer>
</Project>

从 清单 1可以看到编写 DOAP 文件的一些一般规则：

• 类用首字母大写的词汇标记，如“Project”和“Person”。这是编写 RDF 词汇表的一般约定，它似乎工作得很好。属性用小写书写。
• DOAP 文档的最外层元素是 <Project> 。2004 年 2 月的 RDF 语法规范（请参阅 参考资料）允许省略 <rdf:RDF> 容器，描述可以用外层节点编写。
• 朋友的朋友（Friend-of-a-Friend ，FOAF）词汇表用于描述人。我曾对此写过几篇文章（请参阅 参考资料）。
• DOAP 名称空间是 http://usefulinc.com/ns/doap# 。
• 标准属性 xml:lang 表示文本属性的语言。

DOAP 词汇表目前包括三个类：

• Project：主项目资源
• Version：发布软件的实例
• Repository：源代码资料库

事实上，Repository 有几个子类，后面将说明。现在我们来依次分析各个类。

Project 类

如您所料，Project 是 DOAP 中的主类。每个 Project 都由其主页 URI（我在 上一篇文章中说明了这样做的原因）唯一标识。此外，项目描述还应该列出过去所有主页的 URI，因为它们仍然是有效的唯一标识符，其他人可能仍然使用它引用项目。

表 1 列出了 Project 可以使用的属性。描述可以包含每个属性的实例，数量没有限制。一般而言 Project 只有一个名称是合理的，但也不一定如此。此外，只要作者愿意，Project 描述可以有很少的属性，唯一的要求是至少要有主页属性。

清单 2 显示了一些可用于扩展 清单 1 的属性，可以插入到 </Project> 标签之前：

 <mailing-list 
  rdf:resource="http://lists.usefulinc.com/mailman/listinfo/doap-interest" />
 <!-- Freshmeat category:
     Information Management :: Metadata/Semantic Models -->
 <category rdf:resource="http://software.freshmeat.net/browse/1020/" />
 <!-- OSDIR category:
     All Platforms :: Information Management (XML) -->
 <category 
  rdf:resource="http://osdir.com/Downloads+index-req-viewsdownload-sid-201.phtml" />
 <license rdf:resource="http://usefulinc.com/doap/licenses/GPL" />

清单 2说明了 DOAP 词汇表其他一些原则，比如：

• 以 URI 为值的属性使用 RDF 结构 rdf:resource 包含 URI。
• DOAP 没有提出自己的分类方案。有很多种不同的分类方案，各有不同的优势。专业性的社区可能还有自己的方案。DOAP 采用的方法是仅仅要求类别必须是一个 URI。 清单 2中使用了两种分类方案——用于 Freshmeat 和 OSDIR.com。每种情况下类别都从网站上相应类别的页面 URI 得到。但是要注意规范化，因为网站常常允许不同形式的 URL 指向同一个页面。对于常见的站点 DOAP 需要在这方面标准化。
• 如本系列文章的 第 2 部分所述，常见的软件许可证都将有一个 DOAP 指定的知名 URI。但是作为 DOAP 项目的维护者，我不希望拥有许可证的标识符，将提供一种适当的机制允许任意的 URI。对于处理软件还不知道的许可证 URI，应该能够检索关于许可证较短的 RDF 描述，以便为软件提供人类可读的许可证描述。

如前所述， xml:lang 属性可用于实现 DOAP 描述的国际化。 xml:lang 的允许值就是 RFC 3066 中定义的标准语言代码（请参阅 参考资料）。图 1 是关于 DOAP 自身的完整 DOAP 描述片段的截屏图（请参阅 参考资料）。之所以用截屏图，是因为并非所有读者手头上都有适当的字体来查看这些文本。

Repository 类

DOAP 模式定义了一个 Repository 类，这是用于描述源代码资料库的一个通用类。它本身没有多少用处，因此 DOAP 定义了 Repository 四个更具体的子类，分别用于 Subversion、BitKeeper、CVS 和 GNU Arch 源代码修改控制系统。表 2 列出了每个子类和适用的属性：

DOAP 仅限于描述资料库只读的公共访问版本。这样就不需要为可写入的资料库编码访问控制信息，从而简化了 DOAP；这样做没有多少损失，因为参与开发的人员可以通过其他方式找到这些信息。

为了明确起见，这里给出了针对每个系统的示例描述。Subversion 资料库是简单的 URL。比如，我为该项目建立的 DOAP 公共资料库的 URL 是 http://svn.usefulinc.com/svn/repos/trunk/doap/ 。它还可以被公众浏览（请参阅 参考资料）。使用 DOAP 编写这些细节如下：

<SVNRepository>
 <location rdf:resource="http://svn.usefulinc.com/svn/repos/trunk/doap/" />
 <browse rdf:resource="http://svn.usefulinc.com/cgi-bin/viewcvs.cgi/trunk/doap/" />
</SVNRepository>

用于 BitKeeper 的 DOAP 项和 Subversion 类似，只要一个 URL 就足以确定资料库。下面是对 Linux 2.6 核心的描述：

<BKRepository>
  <location rdf:resource="http://linux.bkbits.net/linux-2.6" />
  <browse rdf:resource="http://linux.bkbits.net:8080/linux-2.6" />
</BKRepository>

CVS 可能是在开放源代码世界应用最广泛的源代码修改控制系统。每个资料库都用根名称和模块名标识。比如，可以使用命令 cvs co -d:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome epiphany 检出 GNOME 的 Epiphany Web 浏览器。Epiphany 资料库的 DOAP 描述类似于这样：

<CVSRepository>
  <anon-root>:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome</anon-root>
  <module>epiphany</module>
  <browse rdf:resource="http://cvs.gnome.org/viewcvs/epiphany/" />
</CVSRepository>

GNU Arch 修改控制系统目前很受欢迎。它避开了中央资料库的概念，而采用了每个开发人员都有一个资料库的原则。但是，项目仍然需要制定一个资料库，从那里建立软件的正式发布版本。Arch 具有档案位置和模块名的概念。比方说，您可以使用 http://www.gnome.org/~jdub/arch/ 上的档案和模块名 jdub@perkypants.org--projects/planet--devel--0.0 访问“PlanetPlanet” RSS 聚合系统的一个版本。下面说明如何用 DOAP 编写这种代码：

<ArchRepository>
  <location rdf:resource="http://www.gnome.org/~jdub/arch" />
  <module>jdub@perkypants.org--projects/planet--devel--0.0</module>
</ArchRepository>

为了在 DOAP 描述中嵌入资料库的位置，它必须作为 repository属性的值。看一看 DOAP 自身的 DOAP 文件（请参阅 参考资料）了解其中的原理。

Version 类

虽然在本系列文章的 第一篇中说过，跟踪每个项目的版本不是 DOAP 在第一阶段的一部分，但是仍然需要描述软件项目的 当前版本。Version 类代表软件版本的一个实例，表 3 说明了它的属性。

比如，关于 Mac OS X 10.3 的版本描述可以写成：

<Version>
  <branch>stable</branch>
  <name>Panther</name>
  <revision>10.3</revision>
  <created>2003-10-24</created>
</Version>

每个项目可能有多个当前版本，因此需要 branch 属性。比如，一个项目可能在维护一个稳定分支的同时，又发布一个不稳定的分支以便测试新属性，这种情况并不少见。

回页首

DOAP 模式

DOAP 词汇表中的类和属性的形式化定义可以在 DOAP 模式中找到（请参阅 参考资料）。它是作为一个 RDF 模式编写，从 OWL 本体论语言借用了一个术语表示标识属性（按 OWL 来说，叫 反转功能属性（inverse functional properties））。支持 RDF 模式或者 OWL 的工具可使用该模式帮助编辑或解释 DOAP 描述。

RDF 模式很好的一个特性是，如果正确使用它就能够把它们转化成很多种文档。Morten Fredriksen 已经为此建立了一个在线服务。在 参考资料部分，您可以看到对所有这些 DOAP 术语引用链接。图 2 给出了其中的一部分：

就像本文中的例子那样，您也可以直接作为 XML 处理 DOAP。我不鼓励用这种方法处理 DOAP。RDF 最好作为 RDF 处理，而且您会发现并不缺乏这方面的工具。但是，DOAP 适当采用正规 XML 语法最大的长处是，能够创建 XSLT 样式表把 DOAP 描述转化成易于阅读的 HTML 块。

回页首

结束语

DOAP 项目至关重要的下一步是建立一套用于创建和使用这种词汇表的工具。如果要实现作为软件模交换词汇表的承诺，就需要在现实世界中进行部署。

其次，很明显 DOAP 需要扩展以便处理软件版本。版本通告是软件项目的一个沉重负担，某种自动化这一过程的方法可以帮助维护者。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 回顾本系列中以前的文章， 第 1 部分介绍了 DOAP 项目， 第 2 部分提出了词汇表的候选术语，并确定了几个设计问题。
  
  
• 阅读“ 知识管理的基本 XML 和 RDF 技术，第 4 部分”（ developerWorks，2002 年 2 月），Uche Ogbuji 在该文中介绍了 RDF 模式。
  
  
• 获得最新的 RDF/XML Syntax Specification (Revised)，2004 年 2 月发布。
  
  
• 看一看作者对 FOAF 词汇表的描述，“ 使用 XML 和 RDF 找到朋友”（ developerWorks，2002 年 6 月）和“ 使用 FOAF 支持在线社区”（ developerWorks，2002 年 8 月）。
  
  
• 请参阅 RFC 3066，它定义了 xml:lang 属性所用的语言代码。
  
  
• 在 developerWorksXML 技术专区 可以找到更多关于 XML 的资源。
  
  
• 了解 XML 和相关技术的 IBM 认证资源。
  

关于作者

		Edd Dumbill 是 XML.com的执行编辑和 XML Europe大会的议程主席。 他是即将由 O'Reilly 出版的 Mono: A Developer's Notebook一书的合著者。可以通过 edd@xml.com和他联系。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首