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 映射導入如下資源：
在統一的 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 技術”系列文章，其中，我將展示問題跟蹤器應用程序的統一實現，包括查詢方法和模式的更新。