石家莊OA信息化的基本XML和RDF技術（四）：問題跟蹤程序模式

申請免費試用、咨詢電話：400-8352-114

知識管理的基本XML和RDF技術（四）：問題跟蹤程序模式

Uche Ogbuji（uche.ogbuji@fourthought.com）

首席顧問，F(xiàn)ourthought，Inc.

2002 年 2 月

Uche Ogbuji 繼續(xù)研究 RDF 如何與 XML 相結合以能夠進行知識管理。在這一部分中，他深入研究了 RDF 世界中的建模，而且開始考慮開發(fā)問題跟蹤程序的模式以及它與面向對象和關系建模之間的相似與不同。讀者將學習各種技巧、技術和最佳實踐，以便從 XML 數(shù)據(jù)開發(fā)有效的知識 管理模型。

目前為止，在對問題跟蹤程序應用的研究中，我已經通過示例討論了從 XML 數(shù)據(jù)抽取 RDF 數(shù)據(jù)、實現(xiàn)這一抽取的技術以及與 RDF 有關的無謂紛擾引起的一種簡潔的語義搜索功能?，F(xiàn)在，我將進一步研究各模式在使用 RDF 將知識管理功能部件構建到 XML 應用程序中時所起 的作用。

關系與對象數(shù)據(jù)庫模式，以及甚至 XML 模式，都為數(shù)據(jù)驅動的應用程序提供文檔、指導和控制。RDF 模式更為寬松和一般化；它們陳述放入 RDF 模型中的資源的分類。在這一部分和下一部分中，我們將同時使用 W3C RDF 模式（RDFS）規(guī)范和“DARPA 代理標 記語言／存在推論語言（DARPA Agent Markup Language/Ontology Inference Language，DAML+OIL）”來考慮問題跟蹤程序 RDF 語句的模式。DAML+OIL 是 W3C 規(guī)范的重要擴展和改進。對 RDFS 和 DAML+OIL 有些熟悉是有用的，盡管我會對在我的示例和討論中所運用的大部分概念進行介 紹。

那只代表了您的類

RDFS 和 DAML+OIL 都以資源分類為中心。在本專欄的前幾部分中，您可能已經注意到問題跟蹤程序 RDF 沒有足夠的分類。事實上，目前為止，它根本沒有使用過任何類和類型。這對 RDF 系統(tǒng)毫無問題。就問題跟蹤程序來說，由于幾乎任何資源都可以用問題來標記 — 而且問題幾乎可 以是我們能附加作者、注釋和操作的任何事物 — 所以嚴格的分類可能不自然，而且只會起阻礙作用。

不過，RDF 的長處之一是：它不需要那種許多面向對象（OO）語言所要求的嚴格的分類。它關于類和類型的概念更一般化，并可以由模型設計者來解釋。類可以是您可能要用于資源的任何一種組織的核心。它不必是一個有條理的樹，如生物的科學分類。例如，在 XML 世界中，“采購訂 單”常常作為一個幾乎不可能標準化的文檔示例（即使想盡辦法使用 XML）使用。這是因為有無數(shù)方法可以對 PO 進行分類、細分類和常規(guī)地設想。所以特別設計了 RDF 來調節(jié)這種混亂。

通過提出了將類作為類型的自然指示符這一想法，RDFS 引入了一些 OO 開發(fā)的世界觀。確實有許多 RDF 實現(xiàn)都遵循這一示例，也許是因為 OO 技術近來已廣受矚目。但是，我認為有一點非常重要值得注意：該模式對 RDF 本身來說并不是根本的。

這些都是相當深奧的概念，因此需要一個具體的示例。想想電話號碼。如果我們要以某種分類模式搞清電話號碼，那就有許多方法可以考慮：

電話號碼是一種號碼。

電話號碼是一種聯(lián)系數(shù)據(jù)。

電話號碼是一種資產（詢問那些為保留可以在數(shù)字小鍵盤上拼出它們商標的免費電話號碼而競爭的美國企業(yè)）。

免費號碼是一種電話號碼。

傳真號碼是一種電話號碼。

您會發(fā)現(xiàn)有些典型的層次結構具有 OO 思想顯而易見的特點。您還會發(fā)現(xiàn)有些重疊和嘗試性的分類易于在已建立的 OO 實踐中導致問題。如果您想引發(fā)一次討厭的問題，只要向任何一個 OO 開發(fā)人員詢問“死亡鉆石”或“不能飛的鳥”。以上，“kind of”常常映射為 OO 概念的“is-a”關系，而且通常將對象類型定義為 OO 實現(xiàn)語言的內置語義的結果。

但是，在現(xiàn)實世界中，存在的類型要比類多?？纯聪铝姓Z句：

501-555-1111 是 Mark 的工作號碼。

500-555-1234 是 Mark 的家庭號碼。

使用 500-555-1234 作為 Mark 的緊急聯(lián)系號碼。

在 555 交換機以外的地方，必須用 10 位撥號方式撥打 555-1234。

這些語句都定義了一個電話號碼的特征。它們的分類沒有第一組示例清楚，而且事實上在 OO 世界觀中，可以用許多方法（如屬性和關聯(lián)）來表示它們，而很少使用類型化。但是，考慮到人們通常思考此類特征的方法，沒有理由認為它們不是與第一組語句差不多的類型。很自然地認為“工作號碼是一個類型（type of）的電話號碼”，而對于 501 區(qū)號內的位置，“10 位號碼”自然就是一個“類型”的電話號碼。在 RDF 中，應該使用 rdf:type 謂詞來表示這些特征。事實上，請考慮 vCard/RDF 提議，它是一個 W3C 注釋：建議從非常流行的 vCard 聯(lián)系規(guī)范模式轉換到 RDF。vCard/RDF 使用 rdf:type 來區(qū)分工作號碼和家庭號碼、傳真號碼和語音號碼、因特網郵箱和 Lotus Notes 郵箱等。它也將 rdf:type 用在公共 RDFS 含義中：表示在其數(shù)據(jù)模型中的分類。

但是，如果以這樣有分歧的方法使用相同的謂詞（rdf:type），不會產生含糊不清的危險嗎？我認為這種情況要求將 rdf:type 的各種使用細化，而且 RDFS 最好是引入 rdf:type 的子特性，稱為 rdfs:type，如果那太混淆的話，干脆使用 rdfs:classificationType。 同樣地，vCard 可以創(chuàng)建 rdf:type 的子特性，稱為 vCard:contactType，來區(qū)分它所用類型的各種概念。

問題的計劃

問題跟蹤程序不需要執(zhí)行許多與類型化和分類有關的簡潔操作，但是以上的討論激勵了這一想法：何不相當松散地構造類型、類及其它模式事物呢？在我曾參與的許多 RDF 項目中，為了推敲出這一模式，常會坐在放著許多面包圈和咖啡因飲料的桌子旁苦思冥想。這是從 OO 開發(fā)和關系 DBMS 世界中借鑒過來的一種清教徒般的認真。但是，迄今在使用問題跟蹤程序時，我甚至在轉而同意這一模式之前就已經使用了一些實例。沒有任何理由可以不這樣做。我們將問題附加到任何基于 Web 的資源，并且寫出關于這些問題極其松散的語句。

該談談模式了。清單 1 是一個 XML 片段，說明了一個問題的 RDFS 類：

清單 1. Issue 類


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

該代碼聲明了一個問題的內聯(lián)（因為使用 ID）RDFS 類。注意 label 和 comment — 我想它們是非常重要的，而且在我的實踐中，我需要每個定義的資源（特別是模式元素）都有這兩者。label 尤其重要，因為智能 RDF 工具能夠使用它們?yōu)橘Y源提供用戶友好的名稱，而不是難看的 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

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

如果此時您已經回到實例數(shù)據(jù)以與我們正在構建的模式進行比較，則可能正在迷惑：“但是，這與我們一直在使用的實例并不匹配呀?！崩纾覀冇袑嵗?

清單 3. 以前實例中的代碼片段

這好象違反了我們設置的約束，因為沒有將 ID i2001030423 的資源的 rdf:type 聲明為 Issue，也沒有將 ID“uogbuji”的資源的 rdf:type 聲明為 Author。

是否真的違反了模式實際上可能取決于我們如何解釋模式。最常見的解釋是：如果在模型中沒有語句滿足約束的條件（如 domain 或 range），則該模型是不一致的 — 通常是一個錯誤情況。這被稱為 RDF 模式的一個限制性角色。它也是有時稱為“封閉世界”假設的一部分，因為在查詢 時，它不考慮任何模型中不明白的事物。

但是，有另一個不太常用但非常有趣的方法。在本文中定義的約束之一宣稱：如果某個資源有 author 特性，則它的 rdf:type 必須是 Issue。那么，就可以根據(jù) i2001030423 資源上存在所說的特性推理出它必定有所需的類型。簡而言之，處理器可以有效地生成滿足約束的語句。這被稱為 RDF 模式的一個生成性或推斷性作用。這近似于人們如何處理實際世界的變遷，因而也近似于語義的 Web 后面功能強大的想法。但是，有了這一功能，也帶來了知識表示方面的棘手缺陷。

在此學到的最重要的教訓是：即使我們從原型 RDF 實例開始，并且逐步建立了一個乍看好象我們之前的努力都是無效的模式，但是所有這一切都是對的。多虧 RDF 的寬宏大量（我不會隨便用這個詞），所以一切都是對的。作為一個經驗豐富的建模者／設計者，我必須說這一能力和靈活性是 RDF 基本優(yōu)勢之一，也是它很難被按傳統(tǒng) OO 和關系思考的人所掌握的原因之一。

結束語

我們已經到達這一部分的結尾，但是我希望您會發(fā)現(xiàn)在我們進行的過程中介紹和討論重要的建模概念是有用的。如果是我剛開始學習可擴展元數(shù)據(jù)，我會很感謝有這樣的過程。在本專欄的下一部分中，我們將使 RDFS 形式的問題跟蹤 程序模式更趨完美，還會討論這一模式的 DAML 形式。

參考資料

Pierre-Antoine Champin 編寫了一份極好的 RDF Tutorial，其中也介紹了 RDFS。

RDFS 規(guī)范實際上仍只是 W3C 的備選建議。最近的 RDFCore 活動很可能促成它的最終完成。

Dave Beckett 制作了一份方便有用的 RDF 和 RDFS 概念的參考。

有許多好的資料可供進一步的學習，包括 An Extensible Approach for Modeling Ontologies in RDF(S)，這篇文章討論了使用 RDFS 進行存在論的建模，包括公理建模（例如，象“所有人都會死”這樣的一般陳述）。

還有 Walter W. Chang 寫的 W3C 注釋：A Discussion of the Relationship Between RDF-Schema and UML。

www-rdf-interest 上的這一公告也值得一看，它總結了 Graham Klyne 和 Stephen Cranefield 之間的私人交流信息，包括對 UML 和 RDF 建模相交部分的一些見解。

關于作者

Uche Ogbuji 是 Fourthought Inc. 的顧問兼共同創(chuàng)始人，該公司是專為企業(yè)知識管理提供 XML 解決方案的軟件供應商和顧問。Fourthought 開發(fā)了 4Suite，它是 XML、RDF 和知識管理應用程序的開放源碼平臺。 Ogbuji 先生是一位出生于尼日利亞的計算機工程師和作家，他現(xiàn)在在美國科羅拉多州博耳德（Boulder）生活和工作。可以通過 uche.ogbuji@fourthought.com 與 Ogbuji 先生聯(lián)系。

瀏覽：知識管理的基本XML和RDF技術（一）

知識管理的基本XML和RDF技術（二）

知識管理的基本XML和RDF技術（三）

知識管理的基本XML和RDF 技術（五）

知識管理的基本XML和RDF技術（六）