开放源代码项目最伟大的一点是其本质上的民主性：任何人都很容易启动自己的项目，事实上经常如此！不幸的是，用户要找到适合自己用途的软件可能比较难。这一要求在过去一直通过不同的软件注册来满足。可能最出名的也是历史最悠久的软件注册是 Freshmeat，但还有更多，通常是针对更专门化的要求。比如，Free Software Foundation 的 FSF/UNESCO Free Software Directory、GNOME Software Map 以及 BioInformatics Software Map（相关链接请参阅 参考资料）。

现在有这么多的注册，能否及时更新已经成为一个实实在在的问题。勤勉的软件维护人员在每个发布周期常常需要访问多个站点更新信息，更不用说还有自己的 Web 站点。但是这样的维护人员很少见，在一个注册中找到最新的信息是很难得的事情。如果考虑到许多现代软件项目所牵扯的方方面面：邮件列表、IRC 频道、Web 站点、wikis、CVS 资源库，等等，发现找到的信息已经过时并不令人惊讶。

本文开始开发一种解决方案满足保持软件项目信息及时更新的需要：可用于 XML 文档在 Web 上交换项目细节的一种词汇表。在第 1 部分中，我将列出项目的范围、选择实现技术并考察现有的相关工作。

目标、范围与策略

每个项目都需要一个名称。我从 FOAF（朋友的朋友）得到了灵感，决定把该项目命名为 DOAP，“项目的描述（description of a project）”的缩写。现在最困难的选择 90% 已经完成，剩下的也有了眉目！

像这样的项目很容易失控造成相反的结果。如果创建的东西其实现比当前实际要求的工作量还大或者与之相当，您就不大可能会成功，无论您的 XML 词汇表能够带来多大的好处。Web 上到处都有因为要做的太多而失败的项目。把自己限制到比较实际的较少的一组目标上是值得的。

这个词汇表第一次迭代中的有限需求包括：

• 软件项目及其相关资源的国际化描述，包括参与者和 Web 资源
• 易于创建和消费这种描述的基本工具
• 与其他流行 Web 元数据项目（RSS、FOAF、Dublin Core）的互操作性
• 能够针对专门用途对词汇表进行扩展

第一次迭代明确地没有包含软件版本的描述。这方面的工作可以在以后的迭代过程中研究。此外，项目内部的规划数据如任务分配或者里程碑也不在考虑范围之内。不必走得太远去重新发明 Microsoft 的项目！

项目描述的用例包括：

• 项目导入软件目录的简易性
• 软件目录间的数据交换
• 共享 CVS 资源库或者 bug 跟踪程序之类资源的自动配置
• 帮助捆绑待发行软件的软件包维护人员

回页首

技术选择

尽管经过了多年的词汇表开发，技术的选择仍然是一个公开的问题。大量部署的各种流行词汇表采用了不同的方式规定其术语。研究其中的一些，看看能否从中得到好的经验或者有益的教训。所有这些规范的链接请参阅 参考资料。

• Dublin Core Metadata Element Set：这个流行的库元数据应用使用技术独立的表达方式，通过伴随的规范说明元素如何在RDF/XML、HTML 元标签和 W3C XML Schema 中表示。Dublin Core 非常成功，但是在术语的解释上有一些模糊，造成了一些互操作性的问题。比如， Creator 规定为“主要负责制作资源内容的实体。Creator 的例子包括人、组织或者服务。通常 Creator 的名称应该用于标识该实体”。从计算的角度看，“名称”一词可能有非常宽泛的解释，上述定义实际上只对元数据的人类消费者有效。比方说，创建实体的是一个人还是一群人，这并不清楚。
• RSS (RDF Site Summary/Really Simple Syndication)：该规范的多种版本选择了不同的路线：0.91 版使用 XML DTD 加上平叙；1.0 版使用平叙加例子，还有描述性的 RDF 模式；2.0 则使用带有例子的平叙。亚规范性一直是 RSS 互操作性的问题。
• ebXML:来自这一电子商务项目的词汇表通常在它们的正式规范中采用大量的平叙，也提供了例子、DTD 和模式。
• HTML:按照任何标准衡量都非常成功，HTML 很大程度上是在特定例子的支持下扩展的。现在它有了更正式的规范，但是太晚了。清理工作花费了许多年。可怜的互操作性造成了极大的代价，时间都浪费在用多种浏览器测试网站上，实际上是支持浏览器本身的遗留特性。

既然 DOAP 主要的消费对象是计算机，词汇表显然需要某种机器可读的模式。另一方面，因为数据要靠人来创建，提供足够的人类可读的信息以便避免亚规范性带来的互操作性，这一问题同样重要。DOAP 的一个明确目标是交换词汇表，因此应尽量减少由于术语使用不一致造成的数据损失。如果曾经尝试在设备间同步 vCard 数据，您就会了解虽然数据表面上都遵循该规范，但每种实现都有自己的怪癖需要解决。

回页首

XML 还是 RDF？

Dublin Core（DC）真正吸引人的一个地方是映射到各种不同的表示，包括 RDF、XML 以及 HTML。这种一般性温暖了任何软件开发人员的心。尽管如此，说 DC 部署在 Web 上的主流还是使用 RDF 可能是公平的。

ebXML 的例子表明如果互操作性和交换非常重要，定义良好的序列化就是必须的。这就带来了一个痛苦的选择――选择 RDF 还是 XML 表示。对于元数据应用，一般认为 RDF 是首选的语言。不幸而且也不应该的是，RDF 由于对 XML 增加了约束而有了怪物的声誉：您不能随便写 一堆标签而指望它工作，并且只有使用 RDF 感知的处理工具才能充分利用 RDF 带来的好处。在 RSS 1.0 的开发过程中竟为此引发了许多争执，结果是尽可能地隐藏起 RDF 特性。

直接的 XML 序列化也有其困难。您可以选择一种模式语言来定义文档结构，每一种在表达能力和工具支持上各不相同。DTD 虽然被认为应用最广泛（有争议），没有提供定义文档非常有力的表达方式，通常被看作是昨日的技术。W3C XML Schema（WXS）更加灵活，但是一种沉重的解决方案，其接受程度在商业软件世界中是最高的――当然不是供人类阅读的。RELAX NG 是一个有希望的后来者，可能比 WXS 更容易理解，而且自诩很容易转换成 WXS。它还有一种人类可读的紧凑语法，更容易手工编写。如果采用 XML 路线，RELAX NG 似乎最好，而且能够转化成其他两种，并且很容易理解。

纯 XML 序列化在序列化方面存在一些困难。尽管 XML 很好的定义了文档的语法，却完全没有触及元素的语义。RDF Schema（以及它的更大的弟兄 OWL，W3C Ontology Language）允许把一个软件项目的维护者称作 Dublin Core 术语“creator”的一个子类。任何知道如何处理 Dublin Core 的 RDF 应用程序至少能够使用基本的 DOAP 数据。相反，对于直接的 XML 文档，如果应用程序没有专门的编码，就不能处理 DOAP 名称空间，即使有相应的模式。

最后，还没有解决的一个大问题仍然在 XML 中――名称空间混合的问题。给定来自不同名称空间的两个任意词汇表，如何能够混合使用创建一种复合词汇表呢？这个问题并没有一般的解决方案，就是说除非另有一个结合两者的模式明确规定了一种方法，每个 XML 词汇表仍然是独立的。另一方面，RDF 则有规定好的解决方案。因此，如果优先考虑 DOAP 与其他名称空间的混合，RDF 可能是一种首选的办法。

总之，应该选择直接的 XML 还是 RDF呢？前者更便于人们理解，后者则拥有灵活性以及随之而来的约束？

我的专栏的热心读者可能已经猜到我倾向使用 RDF。这确实是本项目采用的方式，因为 RDF 非常适合元数据应用。但是，上面提及的问题也不能忘记，在开发的过程中我将寻求减轻使用 RDF 的复杂性的方法。如果 DOAP 能用一般的 XML 工具处理，毫无疑问将非常有利。

出于自动化消费的目的，将使用 RDF Schema 来规定 DOAP 词汇表，并尽可能地增加一些平叙作为补充。FOAF 规范（请参阅 参考资料）选择了这种方法，并取得了一些成功。

回页首

现有的工作

技术选择已经完成，现在重要的是看一看关于该项目的目标已经有哪些工作已经做了。完成这项任务后，我将在本系列的下一篇文章中开始定义词汇表。关于这些工作的链接可以在 参考资料中找到，建议您阅读一下。

• Freshmeat XML 导出：Freshmeat.net 软件注册为它的所有数据提供了一种 XML 导出格式，每天都会更新。它们还为所用的 XML 格式提供了 DTD。Leigh Dodds 曾经做了一些工作，把这种导出格式转换成使用 FOAF 术语的数据。
• Open Source Metadata Framework（开放源代码元数据框架）：该项目主要关注开放源代码项目文档的元数据，因此一些重要的目标与 DOAP 是相通的。它作为 ScrollKeeper Open Documentation Cataloging Project 的一部分得到了广泛采用。
• PRJ Project Vocabulary:Danny Ayers 创建这个词汇表的真正目标是要成为通用项目管理词汇表，无论什么领域。
• CPAN2FOAF: 综合 Perl 文档网络（CPAN，Comprehensive Perl Archive Network）是一个 Perl 软件大型资源库。Dan Brickley 曾经把作者元数据转化到 FOAF/RDF。
• Description of a Software Project:这是一个刚刚启动的类似 DOAP 的词汇表，由 Max V?lkel 创建。
• RPMFind:这个软件定位服务使用软件的 RDF 描述，软件采用 RPM 格式打包。关于每个软件版本的元数据非常详尽。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 看一看这些常见的开放源代码软件目录：
  • Freshmeat
  • Free Software Directory
  • GNOME Software Map
  • Open Source Directory
  • SourceForge

  还有一些更专门的目录，如 BioInformatics Software Map。

  
  
  
• 看一看 Dublin Core Metadata Element Set 规范， Dublin 和新元数据集化的文档资源库。
  
  
  
• 阅读两篇关于 RSS 的阐释文章：
  • Mark Pilgrim 的 XML.com 文章“ What is RSS?”，介绍了 RSS 文档元数据连锁规范的各种流派。
  • James Lewin 在“ RSS 2.0 内容提要”（ developerWorks，2003 年 12 月）一文中介绍了 RSS 2.0。
  
  
  
• 进一步了解 ebXML 项目，这是 UN/CEFACT 和 OASIS 领导下的一个启动全球电子市场的计划。参阅 David Mertz 的“ 理解 ebXML”（ developerWorks，2001 年 6 月））和 Nicholas Chase 的教程“ ebXML 简介”（ developerWorks，2002 年 6 月）。
  
  
  
• 访问 HTML 的 W3C 主页，很好地了解 HTML 规范的开发和它的 历史。
  
  
  
• 探索 W3C XML Schema，一种约束 XML 文档的 XML 语言。
  
  
  
• 另外一种 XML 模式语言 RELAX NG是由 James Clark 创立的，并通过一个 OASIS 技术委员会和 ISO 标准化。请参阅 David Mertz 的“ 使用 RELAX NG 反击”系列文章（ developerWorks，2003 年 2 月），以及 Nicholas Chase 的“ 理解 RELAX NG”教程（ developerWorks，2003 年 12 月）。
  
  
  
• 看一看 W3C 的 RDF Schema和 OWL Web Ontology Language规范，如何对 RDF 词汇表赋予机器可读的语义和约束。
  
  
  
• 阅读 FOAF（朋友的朋友）规范，它结合使用 RDF 模式和文本性描述，后者从 RDF Schema/OWL 本体论和一组逐项文本文件自动生成。关于 FOAF 的更多信息，请参阅作者的 developerWorks 文章“ 使用 XML 和 RDF 找到朋友”（2002 年 6 月）和“ 使用 FOAF 支持在线社区”（2002 年 8 月）。
  
  
  
• 访问 Freshmeat 软件注册和它的 XML 导出（标志为 fm-projects.rdf，但实际上是一个 XML 文件）。
  
  
  
• 看一看 Open Source Metadata Framework，常用于 ScrollKeeper Open Documentation Cataloging Project。可以找到一份 术语规范和一个 XML DTD。
  
  
  
• 试一试 Dan Brickley 的 CPAN2FOAF 脚本，把元数据从 CPAN Perl 软件文档转化为 FOAF RDF。
  
  
  
• 看一看 Daniel Veillard 维护的 RPMFind，它利用了所记录的每个软件包的 RDF 描述。
  
  
  
• 在 developerWorks XML 专区可以找到更多 XML 资源。阅读 XML 观察 专栏的以往各期文章。
  
  
  
• 了解 XML 和相关技术的 IBM 认证资源。
  
  

关于作者

为本文评分

评论

回页首

内容

• 目标、范围与策略
• 技术选择
• XML 还是 RDF？
• 现有的工作
• 参考资料
• 关于作者
• 建议