级别： 中级 Edd Dumbill (edd@xml.com), 编辑兼出版者, xmlhack.com
2004 年 4 月 01 日 Edd Dumbill 继续描述开放源代码软件项目的词汇表的开发，考察现有的软件注册并分析强制性属性值的问题。
在本系列文章的
第
1 部分中，我提出了旨在建立 DOAP（项目的描述）的项目，一种描述开放源代码项目的 RDF/XML 词汇表。对于那些需要在无数个
Web 站点上注册软件的项目维护者，以及寻求交换这类信息的任何人而言，DOAP 将满足他们的需求。那篇文章列举了该领域已经进行的工作，并定义了这个项目的边界。
这一次，我将抽取包含在该词汇表中的一组术语，并讨论规定这类术语所固有的困难。我将说明能够在全球分享 DOAP 描述的美好目标对词汇表的设计所带来的影响。
凝炼术语
表 1 列出了对不同软件目录 Web 站点和开放源代码元数据框架所用元数据术语的调查。其中的一些术语进行了近似的分类——比如“主要开发者”和“维护者”是等价的。我也排除了和软件版本有关的术语，这类术语还不在 DOAP 开发的现阶段考虑范围之内。作为现行术语的粗略考察,这个表很有用。
表 1. 开放源代码软件目录中常用的元数据术语
|
术语
|
Freshmeat
|
OMF
|
Advogato
|
GNOME
|
Sourceforge
|
KDE-apps.org
| |
bug tracker
|
?
|
?
|
?
|
y
|
y
|
?
| |
category
|
y
|
y
|
?
|
y
|
y
|
?
| |
creation date
|
y
|
y
|
?
|
y
|
y
|
?
| |
cvs repository
|
?
|
?
|
?
|
y
|
y
|
?
| |
demo site
|
y
|
?
|
?
|
?
|
?
|
?
| |
description
|
y
|
y
|
y
|
y
|
?
|
y
| |
development stage
|
y
|
?
|
?
|
?
|
y
|
?
| |
download page
|
y
|
?
|
?
|
y
|
y
|
y
| |
freshmeat url
|
y
|
?
|
y
|
?
|
?
|
?
| |
homepage
|
y
|
?
|
y
|
y
|
y
|
y
| |
intended audience
|
y
|
?
|
?
|
?
|
y
|
?
| |
license
|
y
|
y
|
y
|
?
|
y
|
y
| |
mailing list
|
?
|
?
|
?
|
y
|
y
|
?
| |
mirror site
|
y
|
?
|
?
|
?
|
?
|
?
| |
natural language
|
?
|
y
|
?
|
?
|
y
|
?
| |
operating system
|
y
|
?
|
?
|
?
|
y
|
?
| |
programming language
|
y
|
?
|
?
|
?
|
y
|
?
| |
purchase link
|
y
|
?
|
?
|
?
|
?
|
?
| |
relationships
|
?
|
?
|
y
|
?
|
y
|
?
| |
rel contributor
|
?
|
?
|
y
|
?
|
?
|
?
| |
rel developer
|
?
|
?
|
y
|
?
|
y
|
?
| |
rel documenter
|
?
|
y
|
y
|
?
|
?
|
?
| |
rel helper
|
?
|
?
|
y
|
?
|
?
|
?
| |
rel lead developer
|
?
|
y
|
y
|
y
|
y
|
?
| |
screenshots
|
y
|
?
|
?
|
y
|
?
|
y
| |
short description
|
y
|
?
|
?
|
y
|
y
|
?
| |
title
|
y
|
y
|
y
|
y
|
y
|
y
| |
version
|
y
|
y
|
?
|
y
|
y
|
y
|
除了
表 1中所列术语之外，还有其他几个在开放源代码项目中常用的术语（多数具有更强的社会性）需要考虑：
-
Wikis:通常用于存放开发文档。
-
其他类型的源代码库：除了 CVS 外经常使用的还有 Subversion、Arch 和 BitKeeper。
-
其他项目角色：至少包括“翻译者”和“测试者”。
-
PGP 公钥：许多软件版本都使用 PGP 数据签名以便提供某种真实性的保证。
表 1中调查的多数站点采用了一种非常简单的模型，以项目作为基本的实体。元数据术语就是该实体的简单属性。后面您将看到有些情况下这些属性值本身也可能成复杂的实体。比如其值域（允许的属性值的集合）是人的属性。显然标识一个人不仅仅需要记录人的姓名。但是，词汇表在完整性和过度复杂性之间求得平衡很重要。
图 1 显示了该词汇表的部分实体关系图。这些图被证明在有多个实体交互的情况下是有用的。如果不使用实体关系模型，也可以采用 UML，即统一建模语言。其他一些文章已经深入分析了
UML 在创建 XML 词汇表中的应用，包括那些使用 W3C XML Schema（请参阅
参考资料）的词汇表。
在这种情况下，您只有少量的实体和许多属性。即使不建立完整的图例可能也管理得很好。由于这项任务的简单性，主要的挑战不在于建模本身，而在于使 DOAP 易于创建和处理。
图 1. 新词汇表的部分实体关系图
现在已经收集了一些将包含在词汇表中的候选术语。选择哪一些是设计、反复试验和个人偏好的问题。您需要在适当的时候构造一些示例应用，以便感受词汇表是如何工作的。您还需要测试您的设计思想。在此之前必须考虑到数据建模时可能遇到的一些问题。
唯一标识项目
为了有效地处理词汇表所表示的数据，需要指定至少一个属性标识项目。这类似于数据库中选择一列作为主键。但和数据库不同的是，本地的唯一键还不行。如果要在 Web 上共享 DOAP 描述，项目键必须是全球唯一的。那么如何才能实现呢？DOAP 的一个基本原则就是它是分散的。不需要在特定的 Web 站点上注册也可创建和发布描述。
在 Web 上，全局标识某个对象的常用方法是赋给它一个 URI。既然每个软件项目在 Web 上都有一个主页，指定主页的 URI 作为项目的标识属性似乎是合情合理的。标识属性的其他唯一一种竞争者是项目名。使用名称的弱点是在同名的情况下没有可以求助的权威。项目选择相同的名称并不稀有。这种情况下常常会引起纷争而冲突可能没有满意的结果。而使用主页 URI（即 URL），DNS 系统的全球权威机构能够保证不会发生名称冲突。
使用主页 URL 有一个明显的不足。在理想情况下，很棒的 URI 不会发生变化（请参阅
参考资料）。而在现实世界中却总是在不停地变动。项目的维护者可能改变
ISP 或者存放的机构。项目可能获得新的拥有不同资源的维护者，或者 Web 站点也可能重新组织。显然如果发生这种情况，您不想所有的 DOAP 描述都变得无效。
为了解决这一问题，您需要一个
旧主页（old home page）属性。一个项目可以有多个这种属性，当站点移动时可以添加。这样也可以把旧主页看作是一种标识属性。限制在于其他的项目不能使用旧主页地址。
这样为何可行呢？假设两个独立的 DOAP 文件中包含同一项目的描述：
- 一个给出了主页属性引用项目，http://example.org/xmlparser
- 第二个给出的主页属性是 http://example.org/projects/xml/parser，并且包含 URL http://example.org/xmlparser
作为旧主页属性。
任何处理代理程序都可以指出这是相同的两个项目。
这种方法在 FOAF（Friend-of-a-friend，朋友的朋友）项目中已经证明可以很好地表示个人信息和社会网络。在我的文章“
Finding
friends with XML and RDF”中标题“
Merging
FOAF descriptions”下可以找到详细的阐述。
强制性属性值
除了项目的唯一标识之外，DOAP 的分散式和全球性目标也在其他方面造成了问题。属性可以具有的值的范围必须以某种方式能够预测，以便对全球收集的 DOAP 信息进行有用的处理。为了说明这一点，我们探讨一下许可证属性。
数据设计 101。人们可以指出 GPL2、GNU General Public License,Version 2 甚至 http://www.gnu.org/licenses/gpl.html 的目标含义并没有什么不同，但计算机显然做不到。解决这类问题最方便的办法——从数据库获得的灵感——就是为各种许可证建立一致认可的代码或者缩写。此外，如果使用定制的许可证还需要一种扩展机制。
到目前还没有什么值得注意的地方。这正是 RDF/XML 开始起作用的一个有趣的方面。在 RDF/XML 中，属性可以具有两种类型的值：一个是资源，用 URI 表示；另一个是字符串文字。这些文字可以指定类型，因此可以定义一个 W3C XML Schema 枚举控制允许的值（请参阅
参考资料）。这样，许可证属性就可以是，比方说 GPL、BSD、Apache 等等之一。如果属性值是“其他”，那么可以增加另外的文本字段描述相应的许可证。
这种方法的不足是向 DOAP 文件的处理者增加了额外的负担。他们现在必须要考虑到可能出现额外的模式，并且要引入 W3C XML Schema 验证所需要的复杂系统。即使如此，所得到的也只是一个含糊不清的字符串，如果提供给人类阅读还必须增加其他的信息。使用枚举也增加了 DOAP 词汇表维护者的负担，因为还要维护和发布另外一个词汇表。
如果使用资源而不是文字可以获得额外的灵活性。这样就可以在您控制的空间内分配代表许可证的 URI。比如，http://example.org/doap/licenses/GPL
可用于表示 GNU General Public License。（域“example.org”在这里仅用于说明）。您也可以在这个位置放上
Web 页面提供关于 GPL 的更多信息，包括完整的文本。作为一种附加的惯例，还可以在 http://example.org/doap/licenses/
上列出所支持的许可证的完整列表。这样做没有增加 DOAP 处理程序的负担。检索字符串 http://example.org/doap/licenses/GPL
和检索字符串 GPL 一样容易。如果在 .../doap/licenses/ URL 上创建一个 RDF 文件——其中包含可供计算机处理的许可证列表，并为每种许可证增加唾手可得的数据，如标签和描述——甚至可以进一步简化处理程序的处理。
这种技术也巧妙地解决了扩展性问题。假设您，Acme Corp.，创建了自己的
Acme Open Source License。您所要做的就是保证控制一个类似 http://acme.com/license/AOSL 的 URI，并使用它作为 DOAP 描述中的许可证属性的值。如果您是一位好市民，您还会在那个 URI 上放上一个说明性的网页。
以这种方式使用资源 URI 有两个不利之处。首先是简易性问题，输入“GPL”要比输入上面所述的完整 URI 容易。这不是一个大问题，可以通过以后提供快捷语法或者工具支持从某种程度上改进：在 RDF 中，标签可用于提供资源 URI 供人类阅读的说明。与完全自由的字符串或者模式验证所造成的负担相比，这当然算不了一个大问题。
第二个也是更严重的一个缺陷是遗留问题：作为 DOAP 的维护者，您可能失去对 URI 空间 http://example.org/doap 的控制。尽管就眼前来说 URI 可以继续使用而不会成为含糊不清的标识符，但是如果那个 URI 上的内容被修改或者删除就会造成很大的混乱。解决这一问题目前有两种常用的方法：
- 使用 purl.org（请参阅
参考资料）这样的服务保证用于注册的 URI 长期有效，或者让 DOAP 加入 OASIS 这样的标准组织也可以提供类似的保证。
- 使用统一资源名（URN——参见
参考资料）而不是 URL。
URN 通过 Internet Assigned Numbers Authority (IANA) 提供了托管的名称空间。分配给 DOAP 的那部分名称空间就可以通过向 Internet Engineering Task Force（Internet 工程任务组，IETF）提交的文档管理。不幸的是，这种方法极其笨拙，可能不适用于这样的项目。
最后，要知道使用资源表示这类常量可能并不总是最好的办法。资源最适用于可扩展性的场合，进一步的研究会有帮助。有时候，和使用短字符串的便捷性相比您可能不愿意使用这种方式。
考察一下 Creative
Commons 项目（参阅
参考资料）所采用的方法是有益的。Creative Commons 能够灵活地将许可证应用于电子媒介，以便推广创造性的工作使其他人能够在此基础上进一步开发或者共享。他们采用上面建议的使用 URI 表示许可证的方法。
结束语
本文试图解决一些常见的问题，部分灵感来自使用 FOAF 词汇表的经验。从整个 Web 的角度来看，RDF 既有长处也有不足。这种情形一般可以描述为冗长与灵活性之间的权衡。正如任何程序员所知道的那样，过早地优化可能是一个错误。我将沿着
Web 的发展潮流得出最终的结论，然后说明可以从哪些方面入手减少新的 DOAP 用户进入这一领域的障碍。
本系列的下一篇文章将继续这个词汇表的设计，并指出从哪里可以开始用工具和测试数据进行试验。
参考资料
关于作者
对本文的评价
| 
