XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:問題跟蹤程式模式(轉)

XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:問題跟蹤程式模式(轉)[@more@]

　　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 實現語言的內建語義的結果。

　　但是，在現實世界中，存在的型別要比類多。看看下列語句：

• 501-555-1111 是 Mark 的工作號碼。
• 500-555-1234 是 Mark 的家庭號碼。
• 使用 500-555-1234 作為 Mark 的緊急聯絡號碼。
• 在 555 交換機以外的地方，必須用 10 位撥號方式撥打 555-1234。

　　這些語句都定義了一個電話號碼的特徵。它們的分類沒有第一組示例清楚，而且事實上在 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 類

　　　　　Issue　　A problem, suggestion or other matter for action　　or discussion relevant to a resource　

　　該程式碼宣告瞭一個問題的內聯（因為使用 ID ）RDFS 類。注意 label 和 comment — 我想它們是非常重要的，而且在我的實踐中，我需要每個定義的資源（特別是模式元素）都有這兩者。label 尤其重要，因為智慧 RDF 工具能夠使用它們為資源提供使用者友好的名稱，而不是難看的 URI。

　　清單 2. Author 類以及 issue 和 author 特性

　　　　　Author　　A person raising or posting an issue　　　　issue　　Associate an issue with its resource　　　　　　　　author　　Associate an issue with whoever posted it　　　　<!-- Where the dc entity has been set to the　　　　 Dublin Core metadata element base URI --&gt　　　　　　　

　　這裡，我們定義了特性 issue 。range 語句宣告任何有 issue 謂詞的語句的賓語，其 rdf:type 必須為 Issue 。我們沒有對這種語句（應為 domain 語句）的主語做任何這樣的限制，因此實際上，任何資源都可以有 issue 謂詞，這是我們的意圖。用 domain 和 range 定義了 author 特性，該特性成為 Dublin Core 中“creator”後設資料元素的子特性。這意味著任何有 author 特性的 issue 都自動宣告還有 dc:creator 特性。這是 一個普通而有用的技術，在這種情況下意味著熟悉 Dublin Core 的代理軟體將在一定程度上能夠處理我們的問題跟蹤程式後設資料，而不會有任何問題。這一訣竅其實是語義的 Web 基礎的一部分。

　　如果此時您已經回到例項資料以與我們正在構建的模式進行比較，則可能正在迷惑：“但是，這與我們一直在使用的例項並不匹配呀。”例如，我們有例項：

　　清單 3. 以前例項中的程式碼片段

　　　　　　　　　　

　　這好象違反了我們設定的約束，因為沒有將 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 形式。