Uche Ogbuji 繼續研究 RDF 如何與 XML 相結合以能夠進行知識管理。在這一部分中，他深入研究了 RDF 世界中的建模，而且開始考慮開發問題跟蹤程序的模式以及它與面向對象和關系建模之間的相似與不同。讀者將學習各種技巧、技術和最佳實踐，以便從 XML 數據開發有效的知識 管理模型。
目前為止，在對問題跟蹤程序應用的研究中，我已經通過示例討論了從 XML 數據抽取 RDF 數據、實現這一抽取的技術以及與 RDF 有關的無謂紛擾引起的一種簡潔的語義搜索功能。現在，我將進一步研究各模式在使用 RDF 將知識管理功能部件構建到 XML 應用程序中時所起 的作用。
關系與對象數據庫模式，以及甚至 XML 模式，都為數據驅動的應用程序提供文檔、指導和控制。RDF 模式更為寬松和一般化；它們陳述放入 RDF 模型中的資源的分類。在這一部分和下一部分中，我們將同時使用 W3C RDF 模式（RDFS）規范和“DARPA 代理標 記語言／存在推論語言（DARPA Agent Markup Language/Ontology Inference Language，DAML+OIL）”來考慮問題跟蹤程序 RDF 語句的模式。DAML+OIL 是 W3C 規范的重要擴展和改進。對 RDFS 和 DAML+OIL 有些熟悉是有用的，盡管我會對在我的示例和討論中所運用的大部分概念進行介 紹。
那只代表了您的類
RDFS 和 DAML+OIL 都以資源分類為中心。在本專欄的前幾部分中，您可能已經注意到問題跟蹤程序 RDF 沒有足夠的分類。事實上，目前為止，它根本沒有使用過任何類和類型。這對 RDF 系統毫無問題。就問題跟蹤程序來說，由於幾乎任何資源都可以用問題來標記 — 而且問題幾乎可 以是我們能附加作者、注釋和操作的任何事物 — 所以嚴格的分類可能不自然，而且只會起阻礙作用。
不過，RDF 的長處之一是：它不需要那種許多面向對象（OO）語言所要求的嚴格的分類。它關於類和類型的概念更一般化，並可以由模型設計者來解釋。類可以是您可能要用於資源的任何一種組織的核心。它不必是一個有條理的樹，如生物的科學分類。例如，在 XML 世界中，“采購訂 單”常常作為一個幾乎不可能標准化的文檔示例（即使想盡辦法使用 XML）使用。這是因為有無數方法可以對 PO 進行分類、細分類和常規地設想。所以特別設計了 RDF 來調節這種混亂。
通過提出了將類作為類型的自然指示符這一想法，RDFS 引入了一些 OO 開發的世界觀。確實有許多 RDF 實現都遵循這一示例，也許是因為 OO 技術近來已廣受矚目。但是，我認為有一點非常重要值得注意：該模式對 RDF 本身來說並不是根本的。
這些都是相當深奧的概念，因此需要一個具體的示例。想想電話號碼。如果我們要以某種分類模式搞清電話號碼，那就有許多方法可以考慮：
您會發現有些典型的層次結構具有 OO 思想顯而易見的特點。您還會發現有些重疊和嘗試性的分類易於在已建立的 OO 實踐中導致問題。如果您想引發一次討厭的問題，只要向任何一個 OO 開發人員詢問“死亡鑽石”或“不能飛的鳥”。以上，“kind of”常常映射為 OO 概念的“is-a”關系，而且通常將對象類型定義為 OO 實現語言的內置語義的結果。
但是，在現實世界中，存在的類型要比類多。看看下列語句：
這些語句都定義了一個電話號碼的特征。它們的分類沒有第一組示例清楚，而且事實上在 OO 世界觀中，可以用許多方法（如屬性和關聯）來表示它們，而很少使用類型化。但是，考慮到人們通常思考此類特征的方法，沒有理由認為它們不是與第一組語句差不多的類型。很自然地認為“工作號碼是一個類型（type of）的電話號碼”，而對於 501 區號內的位置，“10 位號碼”自然就是一個“類型”的電話號碼。在 RDF 中，應該使用 rdf:type 謂詞來表示這些特征。事實上，請考慮 vCard/RDF 提議，它是一個 W3C 注釋：建議從非常流行的 vCard 聯系規范模式轉換到 RDF。vCard/RDF 使用 rdf:type 來區分工作號碼和家庭號碼、傳真號碼和語音號碼、因特網郵箱和 Lotus Notes 郵箱等。它也將 rdf:type 用在公共 RDFS 含義中：表示在其數據模型中的分類。
但是，如果以這樣有分歧的方法使用相同的謂詞（ rdf:type ），不會產生含糊不清的危險嗎？我認為這種情況要求將 rdf:type 的各種使用細化，而且 RDFS 最好是引入 rdf:type 的子特性，稱為 rdfs:type ，如果那太混淆的話，干脆使用 rdfs:classificationType 。 同樣地，vCard 可以創建 rdf:type 的子特性，稱為 vCard:contactType ，來區分它所用類型的各種概念。
問題的計劃
問題跟蹤程序不需要執行許多與類型化和分類有關的簡潔操作，但是以上的討論激勵了這一想法：何不相當松散地構造類型、類及其它模式事物呢？在我曾參與的許多 RDF 項目中，為了推敲出這一模式，常會坐在放著許多面包圈和咖啡因飲料的桌子旁苦思冥想。這是從 OO 開發和關系 DBMS 世界中借鑒過來的一種清教徒般的認真。但是，迄今在使用問題跟蹤程序時，我甚至在轉而同意這一模式之前就已經使用了一些實例。沒有任何理由可以不這樣做。我們將問題附加到任何基於 Web 的資源，並且寫出關於這些問題極其松散的語句。
該談談模式了。清單 1 是一個 XML 片段，說明了一個問題的 RDFS 類：
清單 1. Issue 類
<rdfs:Class ID="Issue">
<rdfs:label>Issue</rdfs:label>
<rdfs:comment>A problem, suggestion or other matter for action
or discussion relevant to a resource</rdfs:comment>
</rdfs:Class>
該代碼聲明了一個問題的內聯（因為使用 ID ）RDFS 類。注意 label 和 comment — 我想它們是非常重要的，而且在我的實踐中，我需要每個定義的資源（特別是模式元素）都有這兩者。label 尤其重要，因為智能 RDF 工具能夠使用它們為資源提供用戶友好的名稱，而不是難看的 URI。
清單 2. Author 類以及 issue 和 author 特性
<rdfs:Class ID="Author">
<rdfs:label>Author</rdfs:label>
<rdfs:comment>A person raising or posting an issue</rdfs:comment>
</rdfs:Class>
<rdfs:Property ID="issue">
<rdfs:label>issue</rdfs:label>
<rdfs:comment>Associate an issue with its resource
</rdfs:comment>
<rdfs:range rdf:resource="#Issue"/>
</rdfs:Property>
<rdfs:Property ID="author">
<rdfs:label>author</rdfs:label>
<rdfs:comment>Associate an issue with whoever posted it
</rdfs:comment>
<!-- Where the <i>dc</i> entity has been set to the
Dublin Core metadata element base URI -->
<rdfs:subPropertyOf rdf:resource="&dc;creator"/>
<rdfs:domain rdf:resource="#Issue"/>
<rdfs:range rdf:resource="#Author"/>
</rdfs:Property>
這裡，我們定義了特性 issue 。range 語句聲明任何有 issue 謂詞的語句的賓語，其 rdf:type 必須為 Issue 。我們沒有對這種語句（應為 domain 語句）的主語做任何這樣的限制，因此實際上，任何資源都可以有 issue 謂詞，這是我們的意圖。用 domain 和 range 定義了 author 特性，該特性成為 Dublin Core 中“creator”元數據元素的子特性。這意味著任何有 author 特性的 issue 都自動聲明還有 dc:creator 特性。這是 一個普通而有用的技術，在這種情況下意味著熟悉 Dublin Core 的代理軟件將在一定程度上能夠處理我們的問題跟蹤程序元數據，而不會有任何問題。這一訣竅其實是語義的 Web 基礎的一部分。
如果此時您已經回到實例數據以與我們正在構建的模式進行比較，則可能正在迷惑：“但是，這與我們一直在使用的實例並不匹配呀。”例如，我們有實例：
清單 3. 以前實例中的代碼片段
<rdf:Description about='&ril-spec;ril-20010502'>
<rit:issue rdf:resource='#i2001030423'/>
</rdf:Description>
<rdf:Description ID='i2001030423'>
<it:author rdf:resource='&ril-users;#uogbuji'/>
</rdf:Description>
這好象違反了我們設置的約束，因為沒有將 ID i2001030423 的資源的 rdf:type 聲明為 Issue ，也沒有將 ID“uogbuji”的資源的 rdf:type 聲明為 Author 。
是否真的違反了模式實際上可能取決於我們如何解釋模式。最常見的解釋是：如果在模型中沒有語句滿足約束的條件（如 domain 或 range），則該模型是不一致的 — 通常是一個錯誤情況。這被稱為 RDF 模式的一個限制性角色。它也是有時稱為“封閉世界”假設的一部分，因為在查詢 時，它不考慮任何模型中不明白的事物。
但是，有另一個不太常用但非常有趣的方法。在本文中定義的約束之一宣稱：如果某個資源有 author 特性，則它的 rdf:type 必須是 Issue 。那麼，就可以根據 i2001030423 資源上存在所說的特性推理出它必定有所需的類型。簡而言之，處理器可以有效地生成滿足約束的語句。這被稱為 RDF 模式的一個生成性或推斷性作用。這近似於人們如何處理實際世界的變遷，因而也近似於語義的 Web 後面功能強大的想法。但是，有了這一功能，也帶來了知識表示方面的棘手缺陷。
在此學到的最重要的教訓是：即使我們從原型 RDF 實例開始，並且逐步建立了一個乍看好象我們之前的努力都是無效的模式，但是所有這一切都是對的。多虧 RDF 的寬宏大量（我不會隨便用這個詞），所以一切都是對的。作為一個經驗豐富的建模者／設計者，我必須說這一能力和靈活性是 RDF 基本優勢之一，也是它很難被按傳統 OO 和關系思考的人所掌握的原因之一。
結束語
我們已經到達這一部分的結尾，但是我希望您會發現在我們進行的過程中介紹和討論重要的建模概念是有用的。如果是我剛開始學習可擴展元數據，我會很感謝有這樣的過程。在本專欄的下一部分中，我們將使 RDFS 形式的問題跟蹤 程序模式更趨完美，還會討論這一模式的 DAML 形式。