在本系列文章的 第 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 用戶進入這一領域的障礙。
本系列的下一篇文章將繼續這個詞匯表的設計，並指出從哪裡可以開始用工具和測試數據進行試驗。