本系列的前兩篇文章中，我分析了描述開放源代碼項目的 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 項目本身的最小化描述：
清單 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 描述可以有很少的屬性，唯一的要求是至少要有主頁屬性。
表 1. Project 類的屬性（星號表示標識屬性）
屬性 說明 name 公開的項目主名稱 shortname 項目的縮寫名，通常用於文件名 homepage* 項目主頁的 URI，僅和該項目關聯。 old-homepage* 項目過去主頁的 URI，僅和該項目關聯 created 項目創建的日期，格式為 YYYY-MM-DD description 項目的普通文本描述，幾個句子 shortdesc 項目的簡要普通文本描述，八九個詞 category 表示指定該項目類比的 URI wiki 附加到該項目上的 Wiki 的 URI bug-database 報告項目缺陷的缺陷跟蹤程序或者電子郵件地址 screenshots 帶有項目截屏的網頁 URI mailing-list 該項目相關郵件列表的 URI programming-language 實現該項目使用或者計劃使用的編程語言 os 該項目局限的操作系統（如果項目不針對特定操作系統可以省略） license 允許使用項目軟件的許可證 URI download-page 可以下載項目軟件的位置 URI download-mirror 下載鏡像站點的 URI repository 描述項目源代碼資料庫的 doap:Repository release doap:Version 描述了項目軟件的當前版本 maintainer A foaf:Person 描述項目的維護者或者主導者 developer A foaf:Person 描述項目中的開發人員 documenter A foaf:Person 描述編纂項目文檔的人員 translator A foaf:Person 描述進行項目翻譯的人員 helper A foaf:Person 描述對項目發揮作用但沒有在其他屬性中描述的人員清單 2 顯示了一些可用於擴展 清單 1 的屬性，可以插入到 </Project> 標簽之前：
清單 2. 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 描述片段的截屏圖（請參閱 參考資料）。之所以用截屏圖，是因為並非所有讀者手頭上都有適當的字體來查看這些文本。
圖 1. 國際化的描述屬性
Repository 類
DOAP 模式定義了一個 Repository 類，這是用於描述源代碼資料庫的一個通用類。它本身沒有多少用處，因此 DOAP 定義了 Repository 四個更具體的子類，分別用於 Subversion、BitKeeper、CVS 和 GNU Arch 源代碼修改控制系統。表 2 列出了每個子類和適用的屬性：
表 2. 適用於 Repository 子類的屬性
屬性 說明 SVNRepository BKRepository CVSRepository ArchRepository anon-root 匿名訪問資料庫的根路徑 ? ? * ? module 資料庫中源代碼的模塊名 ? ? * * browse 資料庫的 Web 浏覽器接口 URL * * * ? location 檔案的基 URL * * ? *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 說明了它的屬性。
表 3. Version 類的屬性
屬性 說明 branch 表式版本分值的字符串，如穩定版本、不穩定版本、gnome24 或者 gnome26 name 版本名，如 Panther created 發布日期，采用 YYYY-MM-DD的形式 revision 版本的修訂號，如 1.0比如，關於 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 給出了其中的一部分：
圖 2. 使用 Fredriksen 的模式查看其轉換的 DOAP 模式
就像本文中的例子那樣，您也可以直接作為 XML 處理 DOAP。我不鼓勵用這種方法處理 DOAP。RDF 最好作為 RDF 處理，而且您會發現並不缺乏這方面的工具。但是，DOAP 適當采用正規 XML 語法最大的長處是，能夠創建 XSLT 樣式表把 DOAP 描述轉化成易於閱讀的 Html 塊。
結束語
DOAP 項目至關重要的下一步是建立一套用於創建和使用這種詞匯表的工具。如果要實現作為軟件模交換詞匯表的承諾，就需要在現實世界中進行部署。
其次，很明顯 DOAP 需要擴展以便處理軟件版本。版本通告是軟件項目的一個沉重負擔，某種自動化這一過程的方法可以幫助維護者。