XML 程式設計思想:知識管理的基本 XML 和 RDF 技術(7)(轉)
Uche Ogbuji 花了些時間回顧了他所展示的 XML/RDF 技術在更廣闊的環境下的相關性。他討論了 XML/RDF 交換的重要性、專門的 RDF 查詢的重要性以及將 RDF 建模中獲得的經驗教訓應用到整個應用程式開發的重要性。他還顯示了 Thinking XML 專欄的這條線索與有關語義透明性方面的開發的類似線索之間是如何關聯的。
在這一系列文章中,我演示了應用程式中 XML 和 RDF 設施之間用於互操作性的常規技術,側重於 RDF 交換如何將特性新增到 XML 應用程式以符合語義或者只是為了取得資訊建模中更大的靈活性。當總結本系列文章時,我將回顧已經介紹的各種技術,並給出如何將它們應用於其它應用程式開發任務的示例和指南。
跟著我重複:“沒有語法”
最初的 RDF 1.0 規範把 RDF 的抽象模型和用於可互操作的表示和交換的 XML 語法結合在一起。我和其他人一樣認為這種組合是錯誤的。除規範設計問題以外,這一繫結讓許多人相信 RDF 確實是規範中的語法,例如,要利用 RDF,您必須按那個語法使用 rdf:RDF 作為所有文件中的根元素來編制 XML 檔案。這完全錯了,我要重申的一個重點就是:
為了使用 RDF 並從中獲益,您不必使用任何特殊語法 ? 甚至不必使用在 RDF 1.0 規範中指定的語法。訣竅是從 XML 文件中抽取關鍵後設資料 ? 甚至非標記格式(例如,RDBMS)? 然後將它同步成為 RDF 模型。然後您可以將這些模型視為本地化的語義 Web。例如,您可以將下列內容結合在一起:
- 一個資料來源中的個人聯絡資訊
- 來自另一個來源的待辦事項和日程安排
- 要建立信任的公鑰基礎結構後設資料
- 字典列表和其它語義資料
這種資訊的高度整合會造成其它不實用的特性並建立附加值填補 XML 和 RDF 模型之間流量的工作。
我所演示的將 XML 轉換成 RDF 語法的 XSLT 轉換(唯一目的是可互操作匯入到 RDF 模型)是完成 XML/RDF 交換的一種方法。某些 RDF 工具可以為您管理這種交換。例如,您可以使用 4Suite 工具定義對映規則,而不必處理 RDF 語法。
在我的樣本問題跟蹤器應用程式中,雖然可以毫不費力地使用 RDF 將象語意搜尋這樣的高階特性結合進來,我仍使用 XML/RDF 對映以最自然的形式產生和交換應用資料。在本專欄的另一條線索(請參閱 參考資料)中,我介紹了幾個電子商務字典資源;在利用這些資源的應用程式中,您可以使用 XML/RDF 對映匯入如下資源:
- RosettaNet 字典
- ISO 基本語義登錄檔(RDF 形式的登錄檔已經可用)
- DISA 格式的美國政府模式庫
在統一的 RDF 模型中,這些資源可以與各種本地或其它全球資料集進行豐富的連結以用於統一的查詢和自主代理處理。
Software AG 的 William Ruh 在最近的一次 XML Web Services One 會議上所作的會議主題演講中指出,目前在建立 XML 格式的實體方法(ontologies)上人們花費了巨大的努力。實體方法是以結構化格式定義術語和概念的文件,並因此提供了語義資料庫。Ruh 先生指出這種原始 XML 資料與 RDF 技術的結合將導致可實用的語義 Web。
查詢的藝術
我還演示了查詢 RDF 模型的一種很低階的方法。作為常規圖的 RDF 模式需要專門的查詢工具,這些工具可以逐個或以整體方式遍歷圖和弧。這與舊的層次型資料庫的雜湊法和搜尋樹技術、關聯式資料庫的表掃描以及物件資料庫的屬性彙總和關係遍歷都是不同的。事實上,RDF 查詢與後者最類似:物件關係被構造成抽象圖,但區別是物件理論已經提供了支撐其弧和接點的許多語義。RDF 不提供任何這樣的語義(RDF Schema 和 DAML+OIL 是位於 RDF 上的系統示例,這些系統確實提供某些結構和語義,但即使這樣也比物件理論更加通用)。
我還介紹了 RDF 的一種比較高階的查詢語言:Versa。這種語言透過可以整合到其它語言(例如,XML 處理語言)的特性處理圖遍歷以及屬性聚集。諸如 Squish 和 CWM(請參閱 參考資料)之類的其它比較高階的 RDF 查詢語言側重於類似 SQL 的習慣用法和邏輯推斷。某些 XQuery 擁護者建議:可以根據 XML/RDF 序列化或者從原始 XML(如果使用 XML/RDF 對映)將 XQuery 用於後設資料查詢。這一思想的主要問題是最通用的 XQuery 實現也不太可能為 RDF 中需要的查詢模式種類而進行最佳化。如果您想使用一種專門的查詢引擎,則還可能要使用適合於這種專門性的語法和語義(例如,RDF)。
選擇 RDF 查詢機制時要考慮的另一個問題是資料是如何分佈的。到目前為止,本系列文章中的許多討論都是適合封閉模型和單一型別資料庫的,但 RDF 的某些能力在分散式系統中最為明顯。例如,RDF 可以成為彙總多個內部網頁面後設資料的一種非常有用的工具,或者用於開銷不大的應用程式整合。在這些情況下,您需要一種查詢系統,該系統可以儲存和轉發部分結果、有效地形成子查詢並處理衝突和矛盾。這些工具對於許多代理技術(例如搜尋引擎 Web 搜尋器 (crawler))已經很常見,而且可以被覆蓋到基本 RDF 查詢系統上。
下一代分析和設計
資訊建模的教訓甚至可能比我已經提到的 XML 對映或查詢實現的詳細資訊更加重要。包括與實體有關的建模和統一建模過程(Unified Modeling Process)在內的用於應用程式開發的所有公共方法所期望的是實現,而不是退回到構成近似於實現的問題空間的基本概念。在許多情況下,這構成了軟體的維護和整合巨大代價的很大部分。兩個不同的軟體包 ? 例如,人力資源資料庫和內容管理包 ? 可能有相同的 僱員含義,但事實上在兩個包中,如何對僱員資料的結構處理進行建模和實現幾乎總是不同。約束和規則不同。表示和包含的資料也不同。如果您需要連線這兩個應用程式,則這些差別可能阻撓您的努力,並且在許多情況下使它在經濟上不可行。
物件管理組織(Object Management Group (OMG))是負責許多物件(Object)設計規範(包括 CORBA 和 UML)的組織,它已經表示對這個問題有所理解。OMG 正在進行一場根本的轉變,即,從根據平臺無關性在系統中開展開發實踐(CORBA 和 UML)到基於完全抽象的模型(這些模型代表組織內、行業內甚或全球的概念)開展開發。這種模型可能很象那種實體方法,但由於某些原因(可能期望強化其工作產品的吸引力),OMG 選擇了推動 UML 作為抽象模型的語言和表示。這裡的問題是 UML 偏重於實現。如 OMG 自己在其對 UML 介紹中所說的:
您可以使用 UML 對幾乎任何型別的應用程式建模,這些應用程式可以在任何型別的硬體、作業系統、程式語言和網路及其組合上執行。它的靈活性讓您能對幾乎使用市場上的任何中介軟體的分散式應用程式建模。因為 UML 建立在將類和操作定義成基本概念的 MOF [Meta-Object Facility] 元模型基礎上,所以它很自然地適合物件導向的語言和環境(例如 C++、Java [語言]和最新的 C#),但您也可以使用它對非物件導向的應用程式(例如,Fortran、VB 或 COBOL)建模。
最後,這個 OMG 描述否認其專門用於物件導向的設計,其本身也是有爭議的免責宣告。但即使有人同意這一點,也正是這個能配合應用程式開發的 UML 的宣傳強調了餘留問題。XML 的一個勝利是其擴充套件能力使開發人員的世界觀超越應用程式開發的狹窄界限。最初,這種擴充套件能力表現為整合從 SGML 繼承的傳統面向文件處理的思路和模式的形式。最近 ? 尤其隨著 XML 以 Web 服務方式闖入分散式程式設計領域 ? 更多開發人員對無狀態資訊處理模型的工作原理有了基本瞭解。
為了確定如何從 OMG 和 RDF 這兩個領域最大程度地獲益來為應用程式開發提供更利於可維護性的基礎,從事 OMG 的人們和從事 RDF/實體方法研究的人們之間的相互聯絡正在增長。以 RDF 建模將您的視野擴充套件到諸如類和型別這種規範化概念的更廣的聯絡上來。這是通向下一代建模之途上的一個重要里程碑。現在,實體方法與傳統分析與設計的整合已經給了早期採用者明顯的回報,即,更短的開發週期、改進的維護和整合以及推動所得到的應用程式的知識庫中的新價值。遺憾的是,這類先驅者同樣經歷了許多不足:程式設計工具還不支援實體方法,實體方法工具(就象現在這樣)還不支援傳統的程式設計。要成功使用這種混合方法需要經驗豐富的開發人員和良好的企業氛圍。遺憾的是在大多數 IT 組織中,這兩種資產都非常缺乏。
重點是:如果專案將資訊建模放在首位,則它們有更好的機會使應用程式與現實世界保持同步。將資訊建模放在首位意味著使用要建模的關鍵概念的正式描述和期望行為,並在開發週期開始初期使用一般資料表示工具(例如 XML 和 RDF 模式)來開展專案。並且只有當您很好地定義了抽象模型時,它才能被用來生成構成應用程式設計程式設計方面的結果構件。
下一步,技術更新
在軟體建模和實體方法社群中有許多幕後工作。這種交換似乎必然導致我們開發應用程式方式的根本改變。現在要做的是以現有良好建立的工具的擴充套件形式連線這兩個領域。我已經以稱為 清潔建模方法(Clean Modeling Methodology)的形式使用這類工具開始實驗了。清潔建模方法一開始就使用清除了所有實現考慮的模型,然後幫助開發人員生成介面和其它設計構件。還有許多人研究連線 UML 和 RDF 技術的工具,並建立了 XMI,雖然它是連線 UML 和 XML 的不太好用的工具。
下一篇文章將總結“知識管理的基本 XML 和 RDF 技術”系列文章,其中,我將展示問題跟蹤器應用程式的統一實現,包括查詢方法和模式的更新。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752019/viewspace-950182/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:語義知識(轉)XML程式設計
- XML 程式設計思想:知識管理的基本 XML 和 RDF 技術:問題跟蹤程式模式(轉)XML程式設計模式
- XML 程式設計思想:將檔案合併到 RDF 模型和基本的 RDF 查詢(轉)XML程式設計模型
- XML 程式設計思想:使用 XSLT 生成 RDF(轉)XML程式設計
- XML 程式設計思想:定義 RDF 和 DAML+OIL 圖示(轉)XML程式設計
- XML 程式設計思想:XML和語義(轉)XML程式設計
- XML 程式設計思想:XML 建模藝術描述(轉)XML程式設計
- XML 程式設計思想:XML語義(轉)XML程式設計
- XML 程式設計思想: 研讀XML Hacks(轉)XML程式設計
- XML 程式設計思想: XML 語義錨(轉)XML程式設計
- XML 程式設計思想: Harold 的高效 XML 設計原則(轉)XML程式設計
- XML 程式設計思想:XML和語義:XML 會兌現其承諾嗎?(轉)XML程式設計
- XML 程式設計思想:查詢 XML 格式的 WordNet(轉)XML程式設計
- XML 程式設計思想: 專利編檔遭遇 XML(轉)XML程式設計
- XML 程式設計思想: XMLOpen 會議,再評 XML Hacks(轉)XML程式設計
- XML 程式設計思想:用 MusicBrainz 管理後設資料(轉)XML程式設計AI
- XML 程式設計思想:從書本學習 XML Topic Maps(轉)XML程式設計
- XML 程式設計思想:Thinking XML: 通用商業語言(UBL)(轉)XML程式設計Thinking
- XML 程式設計思想:重新審視 XML 中的語義透明性(轉)XML程式設計
- XML 程式設計思想:踏著語義的節拍(轉)XML程式設計
- XML 程式設計思想: 學習物件後設資料(轉)XML程式設計物件
- 解析.Net框架下的XML程式設計技術框架XML程式設計
- XML 程式設計思想: UBL 1.0(以及 ebXML Core Components 等)(轉)XML程式設計
- XML專題文章收集整理 解析.Net框架下的XML程式設計技術XML框架程式設計
- XML入門指南(19)XML相關技術(轉)XML
- XML程式設計例項(二) (轉)XML程式設計
- XML與ASP程式設計(一) (轉)XML程式設計
- XML 程式設計思想:利用模式標準化實現自上而下的語義透明(轉)XML程式設計模式
- 非常硬核的技術知識-CopyOnWrite思想
- XML解析技術XML
- XML 程式設計思想: 使用 Atom 格式連鎖新聞及其他內容(轉)XML程式設計
- 程式設計的基本知識點(浙大)程式設計
- shell vbscript xml程式設計XML程式設計
- XML入門指南(7)XML瀏覽器(轉)XML瀏覽器
- XML與其相關技術(1) (轉)XML
- 程式設計師的知識管理程式設計師
- [轉]XML檔案結構和基本語法XML
- 作為程式設計師應具備的基本知識 (轉)程式設計師