面向對象開發者語義網入門
本文由W3C發佈（http://www.w3.org/TR/2006/NOTE-sw-oosd-primer-20060309/）
摘要
在從需求分析到設計的整個軟件開發週期中，領域建模都起着中心作用。現在，在整個過程中一致性的使用模型已經取得了很大進步。支持UML和代碼生成的軟件開發工具以及模型驅動架構使得開發者可以用模型將技術應用與用戶需求同步並進行驗證。但是，由於定義模型時，領域模型由於只在其個體問題領域類尋找解決方案，進行有限的抽象，其重用性是有限的。但是網絡不僅限於此，提供了幾乎無限領域的多維答案空間。同時我們的許多軟件都越來越多地嵌入到網頁中，然而開發過程還沒有完全應用來自於網絡的模型重用潛力。因此，本文介紹語義網語言RDF和OWL，並且展示它們如何與主流面嚮對象語言輪流使用，我們將展示語義網可以作爲一個領域模型建立、共享和重用的平臺。
1．介紹
對軟件系統而言，通常表達目標問題空間的領域模型都具有中心地位。領域模型可以從應用領域的角度描述相關概念和數據結構，並且編碼對驅動應用程序行爲的有用知識。例如，我們開發一個在線商店系統，在對其進行需求分析時，我們瞭解到：
1． 有一系列產品清單的訂單與一個客戶關聯
2． 客戶屬於某個國家
3． 德國、法國和澳大利亞都是國家
4． 歐聯是一個自由貿易區
5． 德國、法國是歐聯的一部分
6． 來自與在線商店所在國簽訂了自由貿易協定的國家的客戶的訂單是免稅的。
經過思考，我們可能會畫出如下的面向對象的UML類圖：
圖1：基於UML語法的領域模型樣例
我們可以將該圖拿去與客戶討論，經過數輪後，我們可能會得到適合我們編程語言的數據結構。我們也可以從爲最終用戶定製的用戶界面組件（可能是JavaServer頁面）或者爲在線商店經理定製的界面組件（可能需要更精緻的用Java/Swing、C#或者VB寫的前臺應用）開始。如果我們的系統被證明是成功的，可以圍繞其建立更多的組件，比如通過網絡服務進入產品目錄的組件。在這些情況下，其他組件可能要共享相同的數據結構和領域知識以便能夠相互作用。即便我們的系統不是如此的成功或者被傳送到另一個不同的平臺，我們可以依然需要重用其中的一部分。此時，有某種辦法進入領域模型來抽出需要的部分是有用的。
由於有這些潛在的期望，我們的系統採用“模型-視圖-控制（Model-View-Control）”體系結構。這個著名的模式推薦將領域模型和用戶界面與控制邏輯分離開來。這種可視組件與非可視組件的分離使在其它應用程序和應用平臺上重用和共享領域模型更爲方便。然而不幸的是，面向對象模型對重用性的承諾並沒有完全實現。很多情況下，領域模型都包含有依賴於應用程序的硬代碼。特別是一旦用某種編程語言對模型進行了編碼，許多初始設計時的知識就損失了。例如，免稅訂單的條件可能以if語句的形式在相應的方法中實現（如UML圖中的totalPrice（）），而除非你仔細閱讀整個用戶界面應用的控制邏輯，每張訂單至少需要一個產品的事實就變得不太清楚了。這類系統的另一個問題是互操作性。例如，如果其它系統想從我們的系統獲得數據或者服務，它可能需要通過與我們的應用程序緊密關聯在一起的良好定義的接口（API）實現。也許會採用XML格式來實現這些應用程序間的信息交換。如果多個具有相似任務的應用程序需要相互作用，則需要大量的接口和格式交換。
在我們給出的例子的情節中，UML圖提供了最大的重用和交互作用的潛能。這樣的圖形模型具有更高的抽象層次，可以被用來導出基於多種目的的應用代碼。然而，即便兩個應用程序或者組件都從UML圖開始，它們也可能具有不兼容部分。依然需要很多手工代碼來實現它們。應該採用什麼樣的格式來存儲和共享客戶數據？UML模型可能會有衝突或者被誤解。在一個應用中，國家可能是以字符串存儲的，而另外的應用則可能用國家類來表達。這兩種情況都不清楚如何在UML表達如德國和法國這樣的國家。此外，除非項目遵循了一致的模型驅動手段，在開發生命期中，UML圖只是作爲一箇中間品，作爲應用的基礎但不能被其它開發者使用。在實際的應用項目中，UML通常不再需要修訂，因此被收藏起來。其結果是軟件開發需要花大量時間進行不必要的重複工作。領域模型一開始需要繪製草圖，然後繪製成中間格式的圖以便應用程序共享數據。
理想化的情況下，開發者可以從各種相關的倉庫中發現共享的領域模型和知識庫，然後將其與面向對象的用戶界面組件和控制組件捆綁在一起—慢慢形成了“本體驅動架構（Ontology Driven Architecture）”的概念。共享重載領域模型的所有應用程序因此具有了一定的內在可相互作用性。這樣的理想情況基本還是一種期望，一些有希望的手段正在浮現。
在不受主流軟件工程陣營注意的情況下，互聯網協會（W3C—Wide World Web Consortium）爲語義網設計了一些非常有趣的技術。這些技術，包括RDF和OWL，已經初步實現了標記頁面，使其能夠被智能代理和網頁服務理解的目的。然而有趣的是，它產生的語義網語言和工具可以在一般的軟件開發中發揮主要作用。
語義網社團已經產生了一些列廣受讚譽的語言和工具，用來開發、維護、使用和共享用於軟件工程和其它目的的領域模型。在以OWL語言和RDF綱要（RDFS）爲核心的架構中，OWL更適合用來從一個高的抽象層次表示結構化知識。以OWL編碼的領域模型可以上載到網絡上並被多個應用程序共享。OWL由稱爲描述邏輯（Description Logic）的沒有歧義的形式邏輯語言支持。這種形式邏輯基礎使其可以應用智能推理服務，比如自動分類和一致性檢查。這些服務可以在構建期使用，因此可以方便地用來構造可重用的，被良好測試的領域模型。推理也可以用於各種目的的運行期服務。比如，它使運行期的動態分類，實例再分類和複雜的邏輯查詢成爲可能。除了它們的邏輯基礎外，OWL和RDFS與面嚮對象語言具有類似的結構，因此可以有效地與傳統的軟件組件集成在一起。
總之，與面嚮對象語言相比，RDFS和OWL具有以下主要的益處：
l 重用性和互作用性：RDF和OWL模型可以在應用程序間和網頁上共享。
l 柔性：RDF和OWL模型可以在一個開放的環境中運行，在這個環境中，類可以被動態定義。
l 一致性檢查和質量檢查貫穿模型
l 推理：OWL具有由自動推理工具支持的豐富的表達性。
注意上述的部分益處，如一致性檢查和自動推理，也可以通過對象約束語言（OCL—Object Constraint Language）獲得。OCL是用於模型驅動架構的OMG系列語言的一部分，提供了與現代語義網語言類似的表達性。例如圖1中的約束可以用OCL重新表達來形成免稅訂單條件。然而，OCL並不是設計來用於網絡，而是在一個更加封閉的數據模型中表達約束。語義網技術面向一個開放的世界，其模型可以被多個應用和團體共享。我們會在稍後的語義網語言中說明其開放性。值得注意的是在面嚮對象語言和OWL之間的區別是不可能橋接的。實際上，一個OMG的工作組定義了一個本體元模型，該模型使開發者可以將語義網語言和其它諸如OCL格式一起協同工作。
本文試圖解釋如何在語義網技術的協助下設計和應用面向對象的應用程序。第2部分給出了一個在應用程序開發週期中如何利用語義網技術獲得益處的概要。第3部分介紹語義網語言RDFS和OWL，並將其與面嚮對象語言比較。第4部分顯示RDF和OWL模型如何嵌入到面向對象程序中（這裏，採用了Java）。附錄給出了進一步閱讀的資料，工具和圖書館。
2．採用語義網技術開發應用程序
什麼是語義網？現在絕大部分的“傳統網頁”都是適合於人閱讀的。其表達語言如HTML包含了Web瀏覽器指令以指示其如何顯示多媒體描述來使我們的視覺和聽覺能夠理解。然而，如果我們想讓計算機程序來搜索基於Web的信息，將會發現現有的辦法非常難以理解這些Web頁面，除非這些計算機程序具有非常高級的人類語言技能。同時，同時代的服務器側的Web語言，如JSP和ASP，支持單一文件中的視覺和模型的隨機混合，這導致了非常不結構化的內容。
語義網的最後動機是產生機器可閱讀的網頁，這樣網頁就可以非常容易地被軟件代理分析和由網頁服務共享。爲此目的，互聯網協會（W3C）推薦了一系列可以用於網頁內容格式化的網頁語言。RDFS和OWL可以被用來象面嚮對象語言一樣描述類，屬性和關係。比如，RDFS可以定義一個Product（產品）類，它具有一個浮點數類型的hasPrice（價格）屬性。你也可以定義一個Purchase（交易）類以及它的與多個產品關聯的hasProducts（產品）屬性。OWL通過添加定義更爲複雜的類的能力擴展了RDFS。例如，OWL可以用來定義一個DutyFreeOrder（免稅訂購）類作爲交易類的子類，該類對每個國家都有一個與之簽訂了自由貿易協定的地址清單。W3C也與其他語言一起描述if-then規則和複雜的SQL類的查詢。不過這裏，我們將討論重點集中在RDFS和OWL。
與你發佈HTML網頁一樣，基於這些語言的領域模型可以上載並與網頁相連。例如，一個顯示產品的HTML頁面可以編碼元數據使其連接回一個基於OWL模型建模的相應實體，這樣，所有的應用程序都可以通過HTML頁面來理解該產品是什麼。此外，特定產品的供貨商也可以通過一個RDFS類實例，以一種沒有歧義的可交換的格式來通知購貨代理其部長是誰。這樣一個語義網應用的典型場景如圖2所示。
圖2 一個採用語義網技術的應用程序可以從網頁上使用領域模型和服務。圖中，黃色框以類UML符號的形式表示OWL文件。注意，UML符號僅僅是一個例子，也可採用其它可視方式來完整表達OWL語義
同時，一定程度上的互作用性也可以通過傳統的XML方式來獲得，而語義網語言具有更豐富的表達能力。與面嚮對象語言類似，RDFS和OWL使定義子類和建立概念層次成爲可能。將領域模型組織進類的方式意味着繼承模型組織進軟件模塊的自然映射。此外，因爲每一個語義網資源都有一個唯一的URI，因此有可能在已有的模型之間建立聯繫。這意味着不論什麼時候一旦一個領域模型在網上發佈，就有可能在它的基礎上建立其它模型，並由此而建立一個領域內的，也可能是跨領域的，知識網絡。
語義網語言的可擴展性支持其全球範圍內的可重用性。不用建立第1000個產品交易領域模型，應用程序開發者可以簡單地重用或者擴展一個網上的合適的模型。通過重用已有的模型，具有類似任務的應用程序可以非常容易地共享結果和數據。更進一步，一個獨立於應用程序的組件（如購物籃應用或者信用卡網絡服務）可能被集成起來。雖然現在就期望在不遠的將來在語義網的基礎上實現全球知識共享有些太過奢望，RDFS和OWL至少提供了一個在感興趣的領域間進行通信的可重用的基礎結構。這超出了本文想要詳細討論的範疇。
能具有重用性部分因爲語義網語言是基於網絡的：在RDFS和OWL中的每個類、屬性和對象都具有一個唯一的標示（URI），因此它可以從任何一個其它地方定位。另外一個使語義網模型具有重用性的主要原因是它是基於形式邏輯的。這意味着OWL模型不僅僅只限於定義類及其屬性，也可以限制這些類的潛在實例，因此這些類可以無歧義地在人和機器間共享。這樣基於良好定義的邏輯的領域模型通常被歸類爲本體。實際上，OWL就是“Web Ontology Language”的縮寫。根據[OWL 2004]，OWL可以直接用來表達詞條的意義及這些詞條間的相互關係。詞條及其間相互關係的表述就是本體的另一種形式。以面向對象的觀點看，本體是包含其意義明確表達的邏輯描述的領域類。稍後我們將展示稱作推理機的工具可以使用這些邏輯描述來完成能夠顯示資源間隱含關係的高級查詢。
本體和領域模型經常跨越不同的抽象層次，應用程序依賴性和重用性。回顧介紹中的例子，陳述1和2描述客戶和交易數據的數據結構。陳述3、4和5表述國家，它可以用於地理或者行政應用程序。陳述6獨立於國家的描述，表達了作爲國家判定條件的領域關係。這部分可以從標準解決方案中重用。實際上，本體通常由某個團體定義（如電子商務協會或者國家地理勘探）以便與其用於信息集成的領域共享詞彙表聯繫起來。一旦一個國家及其關係的標準本體已經存在，則沒有必要爲每個單獨的應用程序重寫本體。此外，重用網上已有本體的另一個好處是應用程序可以直接受益於諸如新國家等的更新。
但是，對特定的國家而言，特定的客戶我在線商店的所在地是一個應用程序級描述，需要與客戶相適應。這種適應可以通過特定的子類或者實例來獲得。如果共享本體/領域模型對特定的應用程序來說不是最優的，則可以在此基礎上進行修改或者重建，這可以利用領域模型工具（如附錄中列出的）來完成。這類工具適合於具有很少或者沒有程序語言知識的領域專家。與UML編輯器相比，這些工具具有可試化的對類和其間關係的編輯界面，允許用戶創建這些類的實例。
可以將這種領域模型建模的開發程序與傳統的軟件開發需求分析進行對比。領域專家、最終用戶與軟件工程師、開發者和測試員通力合作，一起完成對領域模型的恰當抽象。來自網絡的本體被組合、擴展和實例化。本體開發工具提供實例化類的方便手段，以便樣例的建立和樣本化。最終的領域模型與應用程序的其它組件，如程序編制的用戶界面和控制邏輯，相組合。與傳統的面向對象的設計方法比較，面向對象的分析和設計只爲代碼生成產生一箇中間的過渡產品，而語義網絡方法中同樣的模型貫穿了從分析、設計、執行到測試甚至使用的所有步驟。初期的本體定義確定了應用的所有類，同時，在應用程序執行過程中，這種初期的設計模型仍然是可以訪問的。隱藏在本體後面的形式邏輯甚至可以用來導出測試用例。如果領域模型有一個明確的運行語義，它可以更進一步地使用推理服務。在我們對RDF和OWL進行簡單介紹之後，我們會更進一步來探討這個問題。
3．RDFS和OWL簡介
爲了實現語義網的意圖，W3C定義了一系列的描述語言。RDF及RDF綱要提供了以符合網絡的格式表達類、屬性和實例的基礎，OWL則擴展了RDF綱要使其具有更豐富的表達性。現在，兩種語言都有工具、解析器和編程API的支持。本部分對RDF綱要和OWL做一簡介並與面嚮對象語言進行對比。
3.1.RDF和RDF綱要（RDFS）
RDF（Resource Description Framework）[RDF2004]是一種可以形式化描述資源建聯繫的網頁語言。資源是具有統一資源標示URI的任何東西。因爲具有URL，HTML網頁、圖像和多媒體文件都是資源。在RDF中，資源還可以是類、屬性和實例。比如，統一資源標示http://ecommerce.example.org/ecommerce.rdf#Product就可以在RDF文件中表達一個類，你也可以使用這個URI給特定的產品網頁做註釋。
RDF只爲語義網內容定義了最基本的語法，有一系列的XML代碼允許用戶在網頁上共享模型。RDF綱要爲RDF定義了一個面向對象模型。RDF綱要定義瞭如何申明類、子類、關係、屬性和數據類型等。如，下面的RDF綱要文件申明瞭一個Product（產品）類和一個屬性hasPrice（價格）：
<rdf:RDF xml:base="http://ecommerce.example.org/ecommerce.rdf"
xmlns="http://ecommerce.example.org/ecommerce.rdf#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdfs:Class rdf:ID="Product"/>
<rdf:Property rdf:ID="hasPrice">
<rdfs:domain rdf:resource="#Product"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/>
</rdf:Property>
</rdf:RDF
該片斷遠遠不能描述RDF、RDF綱要和XML語法的細節。本文檔的目的僅僅是建立幾個重要的概念。URI通常被劃分爲命名空間和本地名字，命名空間可以有前綴符號縮寫。例如，如果前綴rdfs已經在文件頭申明瞭的話，rdfs:Class就是統一資源標示
http://www.w3.org/2000/01/rdf-schema#Class的縮寫。如果沒有給出前綴（如Product），就使用文件的隱含命名空間。爲了文檔表述的簡化，我們將重點集中在本地名字的短符號上。
RDF綱要中的類是具有共享特徵的一組個體的集合。和UML一樣，RDF綱要支持多繼承。然而，與面嚮對象語言的一個主要區別是RDF中的所有類都可以重載。因爲可以可以有多個類型，這意味着一個實例可以被多個類共享。更進一步，實例可以在生命週期中更改其類型。一個訂單可以在開始的時候作爲PurchaseOrder（訂單）類的計劃實例，然後在程序收集到更多的客戶交貨地址後更改爲DutyFreeOder（免稅訂單）類的實例。
語義網和面嚮對象語言的另一個主要區別是語義網是開放的，文件中可以添加現有資源的新的信息。因爲網頁是一個任何東西都可以與其它東西連接的巨大的空間，不可能推斷出一個敘述是否爲真，或者是否會變爲真。例如，我們定義了一個類，我們通常不知道它以後具有的所有實例。同樣我們也不可能推斷出一個特定的產品是否同時也是一個拍賣項目。這個“開放假定”意味着語義網的建模領域可能需要那些習慣於“經典”的面向對象系統和“傳統”的關係數據庫的開發者轉換其思維。另一方面，它也提供了一個在無限世界的重用和互操作性的柔性和共享經驗的回報。特別是，一個開放的方法意味着一個基於網頁的公共本體可以通過在另外一個類定以中添加子類或者添加概念的附加特徵來限制它們使用不同的應用程序的情況。在類似Java程序這樣的封閉的系統中這是不容易，或者方便實現的。
現在讓我們回到RDF語言本身。RDF中的屬性properties可以與面嚮對象語言中的屬性、字段或者相關的結點類比。但是，UML和Java中的屬性只能夠屬於一個類，RDF的屬性是一個獨立的實體，可以分離於類進行定義並被多個類使用。例如，你可以定義一個hasPrice（價格）屬性然後將它賦予所有的具有價格功能的類。這也可以使在多個文件中重用屬性成爲可能。例如，如果你建立一個在線拍賣的軟件模型，你可以使用在線商店模型中的價格屬性來描述在線拍賣中的價格。在多個模型中共享同一個類意味着更容易在值上集成，例如將現行的拍賣價格與另一個在線商店的新產品價格進行比較。
爲了將屬性“附着”或者“聯繫”到一個類或者，可以使用rdfs:domain語句。rdfs:domain是RDF綱要命名空間中的一個標籤，它使用謂詞將一個屬性和一個類關聯起來。在上面的例子中，hasPrice的定義域（domain）是類Product。這樣，從面向對象的觀點來看，Product類的所有實例都具有與之關聯的價格值，這樣就構成了產品價格屬性。不過，在RDF和OWL中這還包含一個內涵：任何具有hasPrice條目的東西都是Product類的實例。換句話說，RDF中的定義域domain可以用來對實例分類。因此，對於上面的例子可以肯定地說，一個物品如果有價格，不管它使否與其它的申明（第三者）共享，該物品一定會被作爲Product的實例。更關鍵的問題會在後面的OWL推理中詳細討論。
在這種方式下，RDF中的如價格這樣的原始值被稱爲字面值（literals），字面值以XML綱要中的數據類型如xsd:float和xsd:string作爲其類型。還可以使用語句rdfs:range來限制屬性的值的類型。一個屬性可以以XML綱要的數據類型，也可以以類作爲其取值範圍（值域range）。將類作爲其值域的屬性可以與面嚮對象語言中的關係類比。例如，如果屬性hasCustormer（有客戶）具有值域Customer（客戶）類，則所有該屬性的值必須是客戶。與定義域語句domain相似，range語句也可以以另外一種方式解讀：如果我們知道一個資源以某種方式與hasCustormer屬性關聯，我們則可以推斷出該資源實際上是一個客戶Customer，而不管它是否也具有其它的類型。
3.2．OWL
如前所述，RDF綱要定義了一個與面嚮對象語言類似的簡單的領域模型語言。你可以定義類及其屬性，然後創建這些類的實例。這對很多情況都是有用的。然而，在許多應用領域，RDF綱要的表達能力是不夠的。例如，RDF不能表達基數來約束一個產品只有一個價格。
網頁本體語言（OWL—Web Ontology Language）[OWL2004]採用與RDF相同的基本語法擴展了RDF綱要。OWL提供了對屬性特徵的更強的表達能力，以及通過滿足這些特徵的實例集合來定義類的能力。爲了更好地理解，很重要的是要記住OWL的類是公理的集合。如圖3所示，這些集合可以重載，也可以相互包含。
圖3 OWL類可以被認爲是一組具有公有特徵的實例的集合
圖3中左邊的圓圈表示所有來自澳大利亞的東西的類，右邊的圓圈表示所有產品類的實例。兩個大圓圈的交集表示同時是產品，也來自澳大利亞的東西的實例，也就是澳大利亞的產品。產品中的小圈表示與德國作貿易的產品，它是產品集合的子集。最後，所有與德國進行貿易的澳大利亞的產品則由所有類的交集表示。
記住RDF/OWL的屬性是獨立於特定的類的，可以在多處使用。例如，屬性hasOrigin（源自）可以用於產品、人、客戶、音樂或者任何其它東西。假設澳大利亞已經在某個地方被定義爲國家類Country的一個實例，現在，任何人都可以利用OWL來定義一個類其中的所有事物的hasOrigin屬性都取值爲澳大利亞。這樣所有由其它人定義的實例現在都可以用這個定義來分類。
表達着類定義的OWL語言元素被稱爲約束restriction。一個約束表示類的所有實例在該屬性上都實行一個特定的條件。OWL有多種類型的約束。我們稱上面的例子的約束爲取值hasValue約束，它將一個屬性連接到特定的個體。另外的約束限制屬性的基數，例如，定義一個類的所有事物的hasOrigin屬性都至少有兩個值。
這裏不需要討論約束的細節。OWL的關鍵能力在於它可以通過組合多個約束和其它類來定義類。爲此目的，OWL提供了邏輯運算符來構建其它類的交（and）、並（or）和補（not）。例如你可以定義“所有的沒有訂購DVD的來自法國的客戶，他們都至少有3個訂單或者有1個書本訂單的類”。
在面向對象系統中，這樣的描述通常都被隱藏在基礎代碼的某個地方。在語義網本體中，邏輯關係通過類定義和其它的形式描述被顯示地表達。這不僅僅意味着使用模型的其他人能夠更容易地理解其內在含義，也意味着其它工具可以明確地使用定義。OWL定義簡單地聲明事物，然後等待應用程序使用這些定義來做某種有益的事情。
一些語義網應用程序可以使用其它工具來掌握和分析OWL模型。推理機就是這樣一類工具。推理機是這樣一種服務，它將陳述編碼（斷言）輸入某個本體並從中導出（推理出）新的陳述。對於OWL推理機而言，可以用於：
l 顯示類的父/子關係
l 確定個體最詳細的類型
l 檢測類定義的不一致性
這樣，我們可以構造如下恰當的例子：假設你定義了一個免稅訂單類DutyFreeOrder，它由其客戶都生活在簽訂了自由貿易協定國家的PurchaseOrder訂單類組成。現在假設一個新用戶登錄進在線商店並將物品放入他自己的購物籃內。在內部，我們需要創建客戶類Custormer和訂單類PurchaseOder的空實例。隨後，當用戶開始檢查並輸入其地址的時候，我們可以調用推理機來分類該訂單。其結果是返回給我們該特定訂單所屬的最詳細的類（這裏，返回DutyFreeOrder）。此後，擁有一個免稅訂單的事實將會導致該對象的一個新的控制生命週期，因爲應用程序邏輯又展示了關於免稅訂單的新的領域知識。
與對象通常不能改變其類型的面向對象系統不同，基於語義網技術的應用程序採用了形式化的，同時也是動態的類型系統。RDF和OWL類本身也是動態的，可以在運行時創建和處理。例如，可以利用OWL的形式化語法定義一個臨時類，並調用推理機對該類的實例進行推理。這意味着可以將推理機比喻爲一個豐富的查詢系統。這些查詢不僅可以在本體構建是產生，也可以在運行時產生。
3.3． OWL/RDF與面嚮對象語言的比較
總結上述對RDF和OWL的介紹，下表列出了語義網語言和面嚮對象語言間的重要異同。
|
面嚮對象語言
|
OWL和RDF
|
|
領域模型由類、屬性和實例（個體）組成。類可以具有子類及其繼承層次。屬性值可以爲對象或者值（字面值）。
|
|
類和實例
|
|
類被認爲是實例的類型
|
類被認爲是個體的集合
|
|
每個實例只有一個類類型，類不能共享實例
|
每個個體可以屬於多個類
|
|
實例不能在運行時改變其類型
|
類的成員可以在運行時變化
|
|
編譯時具有所有類的清單，並且不能在其後變化
|
類可以在運行時建立和改變
|
|
在構建時使用編譯器，編譯錯誤指示問題
|
在構建和運行時由推理機進行分類和一致性檢查
|
|
屬性，屬性和值
|
|
屬性在類內定義（派生類通過繼承）
|
屬性是獨立實體，可以不依賴於任何類存在
|
|
實例只能擁有屬於其屬性的值，值必須是正確的類型，值域約束用於類型檢查
|
實例可以擁有任意屬性的任意值，值域和定義域約束用於類型檢查和類型推理
|
|
類通過強制性函數和方法編碼其大部分意義和行爲
|
類通過OWL語句顯示錶達其意義，不可以添加強制性代碼
|
|
類可以封裝其成員爲私有
|
RDF/OWL文件的所有部分都是公有的，並可以任意連接到其它地方
|
|
封閉的：如果沒有足夠的信息證明陳述是針對，則假設爲假的
|
開放的：如果沒有足夠信息證明陳述是真的，則它可能是真的或者假的
|
|
設計過程的作用
|
|
一些通用的API在應用程序間共享。少量的UML圖（如果有的話）共享
|
RDF和OWL從本地到網頁設計。領域模型在線共享
|
|
領域模型被當作軟件架構的一部分設計
|
領域模型用於表達領域知識，以及用於信息集成
|
|
UML，Java和C#等是由許多商務和開源工具支持的混合技術
|
語義網是一門新技術，由一些開源工具和少量商務工具支持
|
|
其它特徵
|
|
實例是匿名的，不易從運行程序外部定位
|
所有命名的RDF和OWL資源都有唯一的URI，可以被引用
|
|
UML模型可以在XML中串行化並在工具間交換，但並不是真正基於網頁的。Java對象可以被串行化爲各種基於XML的格式或者本地中間格式
|
RDF和OWL對象具有標準的基於XML的串行化方式，並在其中存儲了資源的唯一URI
|
4．用RDF綱要和OWL編程
許多現代軟件架構都由面向對象組件構成，並應用於主流編程語言如Java和C#中。在胖客戶系統中，許多用戶界面和控制代碼都採用面向對象庫如Swing和SWT編寫。在客戶-服務器結構中，服務器可能是完成與數據庫和其它資源通訊的企業JavaBean（EJB）的宿主。在網絡服務中，許多控制邏輯都要應用強制式的，面向對象的方法。
爲了將語義網技術的優點應用於這樣的面向對象系統上下文中，軟件架構需要理解設計和決策模式來無縫地集成這些技術。當我們僅僅是初步理解語義網技術在系統和軟件工程中的含義的時候，包括編程接口API和代碼生成器在內的許多有希望的選擇方案已經出現。本部分我們將概要敘述本體驅動軟件開發的藝術並討論它的一些基本概念。
要理解本體驅動架構的關鍵必須記住本體語言是：
l 屬性獨立於特定的類
l 實例可以有多種類型並且可以根據分類結果改變其類型
l 類可以在運行時動態定義
這些關鍵的區別隱含了不能簡單地將OWL/RDF綱要類映射爲具有其屬性固定於類等特徵的面向對象類。如果一個應用程序想使用OWL/RDF綱要的弱類型和柔性的話，它必須將OWL/RDF類映射到某個運行對象上，以便使本體中的類成爲面向對象類的實例。如圖4所示，一個典型的表達語義網本體的對象模型可能包含表示資源、類、屬性和個體的類。注意條目RDFSClass和RDFProperty與RDF綱要中定義的類rdfs:Class和rdf:Property相關聯，同時，條目RDFIndividual在RDF綱要中沒有對應的定義。
可以容易地設想對各種類型的OWL類和屬性的更進一步的擴展（參見完整的OWL對象模型的Protégé OWL圖）。
圖4 一個表達RDF綱要本體的面向對象模型樣例
應用程序可以將本體裝載進這樣的對象模型中，並在運行時處理和查詢對象。因爲OWL/RDF綱要類是對象，所以可以在運行時添加和修改這些類，比如在運行時改變本體的邏輯特徵。因爲RDF屬性是對象（其值並沒有作爲面向對象的屬性存儲），則可以動態地修改和查詢任何資源的值。因爲個體是對象，則可以動態修改其類型。
這種由動態方法開發進行驅動的方法在主流軟件技術中稱爲動態對象模型（Dynamic Object Model）模式[RTJ 2005]。對特定的面向對象系統而言，通過將對象類型表述爲對象，它們可以在配置時和運行時改變，這使改變和修改系統來適應新的需求變得容易。
在語義網通訊中，部分API接口採用了這種模式。附錄中列出了Java、C和PHP的公共庫清單。除了動態對象模型接口外，這些庫還提供瞭解析器，推理接口和操作本體的其它各種接口。爲了體會如何使用這樣的庫，給出如下的Java程序片斷（對給定客戶所有交易求和的方法）：
public static float getPurchasesSum(RDFIndividual customer) {
OWLModel owlModel = customer.getOWLModel();
float sum = 0;
RDFProperty purchasesProperty = owlModel.getRDFProperty("purchases");
RDFProperty productProperty = owlModel.getRDFProperty("product");
RDFProperty priceProperty = owlModel.getRDFProperty("price");
Iterator purchases = customer.listPropertyValues(purchasesProperty);
while(purchases.hasNext()) {
RDFIndividual purchase = (RDFIndividual) purchases.next();
RDFIndividual product= (RDFIndividual) purchase.getPropertyValue(productProperty);
Float price = (Float) product.getPropertyValue(priceProperty);
sum += price.floatValue();
}
return sum;
}
該代碼是通用和柔性的，但同時該方法也有一些缺點。如果類和屬性是運行時對象，則強類型系統的優點則不能在編譯時使用。這會變得非常不方便，訪問屬性值和代碼會因爲訪問屬性等操作變得臃腫。此外，通過名字對資源的訪問被編碼爲字符串，這樣編譯器便不能幫助進行錯誤檢查。從面向對象應用的觀點看，上述操作的更好的應用方法應該如下所示：
public class Customer extends RDFIndividual {
public float getPurchasesSum() {
float sum = 0;
Iterator purchases = listPurchases();
while (purchases.hasNext()) {
Purchase purchase = (Purchase) purchases.next();
Product product = purchase.getProduct();
sum += product.getPrice();
}
return sum;
}
}
不是訪問通用的諸如RDFIndividual和RDFProperty類，我們應該訪問用戶定製的諸如Purchase和Product那樣的類。幸運的是，有可能構造和使用這樣的類而不必犧牲動態對象模型的優點。代碼生成器可以以RDF綱要和OWL類作爲輸入並將生成的面向對象的接口和應用類作爲輸出。附錄中列出了一些可選擇的代碼生成器。在前面的例子中，代碼生成器建立Customer的Java接口，定義屬性定義域中有Customer的屬性的get和set方法（即getEmail，setEmail）。這些接口是動態對象模型API中的通用類（如RDFIndividual）的子類。這意味着接口的實例同時也是“常規”的RDFIndividual，同時生成的接口作爲其上的一個方便的頂層次來使用。
圖5 語義網模型既可以通過通用的API也可以通過特定領域類來訪問
運行時對象同時也是通用的，動態的API意味着開發者可以根據任務來使用不同的API。對於推理、解釋、查詢和輸入確認這樣一般性的服務可能會採用動態對象模型API。通用的代碼具有最大的重用潛力，將來也會有越來越多的處理RDF和OWL的組件出現。這個觀點對於本體驅動系統的開發方法是有其內在含義的。如果存在通用的推理和查詢組件，軟件設計者就應該更多地採用RDF/OWL來編碼領域模型，並因此提高常規服務領域的抽象水平。例如，對於簽訂了自由貿易協定的國家的訂單免稅可以在方法，如Java類PuchaseOrder的isDutyFree（）方法，內部實現。但是，這將使通用的推理機不可能自動地對貿易訂單進行分類。一個更無瑕疵的解決方案是在OWL本體內定義一個DutyFreePurchaseOrder子類，並與描述邏輯語句一起來定義免稅訂單和其它訂單的區別。可重用性和通用服務是採用明確的語義定義領域模型的基本原因。
除了本體驅動軟件開發的期望，理解什麼時候不能使用語義網技術也是很重要的。最重要的是，本文中提到的許多推理機都具有可測性和性能上的問題。OWL DL本體的分類可能是個冗長的任務並因此限制了運行時分類的用處。推理機的性能問題在構建期中則不是那麼關鍵。
另一個一般性的語義網問題與本體的重用性極限有關。要建立一個真正領域獨立的和可重用的本體非常困難。此外，本體建立通常很難也很昂貴，面對如此龐大的投資許多軟件公司不會簡單地上載並在網絡上共享。這超出了本文的論述範圍，但值得我們注意。
附錄：進階材料
API連接
l Java
n Jena – 語義網絡框架(http://jena.sourceforge.net/)
n WonderWeb OWL API (http://wonderweb.man.ac.uk/owl)
n Protege OWL API (http://protege.stanford.edu/plugins/owl/api)
l C
n Redland – RDF應用程序框架 (http://librdf.org/)
l PHP
n pOWL – 語義網開發平臺(http://powl.sourceforge.net/)
l 代碼生成器
n RDFReactor (http://rdfreactor.ontoware.org/)
n Kazuki (http://projects.semwebcentral.org/projects/kazuki/)
n Jastor (http://jastor.sourceforge.net/)
基礎支持和工具連接
l Protege-OWL本體編輯器 (http://protege.stanford.edu/plugins/owl)
l OntoEdit/OntoStudio – 本體工程環境 (http://ontoedit.com/)
l SemanticWorks RDF/OWL 編輯器( http://www.altova.com/products_semanticworks.html)
l SMORE – HTML頁面OWL標記 (http://www.mindswap.org/2005/SMORE/)
l SWOOP – 輕量本體編輯器 (http://www.mindswap.org/2004/SWOOP/)
l OntoMat Annotizer ( http://annotation.semanticweb.org/ontomat)
進階在線文檔
l Semantic Web Activity (Semantic Web Activity)
l RDF Primer (http://www.w3.org/TR/rdf-primer/)
l Tutorial on OWL (http://www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/)
本體樣例連接
l SchemaWeb - A comprehensive directory of RDF schemas and OWL ontologies (http://www.schemaweb.info/default.aspx)
l DAML Ontology Library (http://www.daml.org/ontologies/)
l Ontoware - Ontology repository ( http://www.ontoware.org)
l Protege-OWL Ontology library (http://www.owl-ontologies.com/)
SW應用程序樣例連接
l SWCLOS - A Semantic Web Processor on Common Lisp Object System (http://iswc2004.semanticweb.org/demos/32/)
l Swoogle - A Semantic Web Search Engine (http://swoogle.umbc.edu/)
l Bibster - A Semantics-Based Bibliographic Peer-to-Peer System (http://bibster.semanticweb.org/)
l Ontoware - Semantic Web related Software Projects (http://www.ontoware.org/)
標準參考
[BCCG 2004]
Visual modeling of OWL DL ontologies using UML. Saartje Brockmans, Andreas Eberhart, Raphael Volz, Peter Löffler In S.A. McIlraith et al., Proceedings of the Third International Semantic Web Conference, Hiroshima, Japan, 2004, pp. 198-213. Springer, November 2004.
[BHS 2003]
Description Logics. Baader, Franz, Horrocks, Ian, and Sattler, Ulrike. Volume Handbook on Ontologies in Information Systems of International Handbooks on Information Systems, chapter I: Ontology Representation and Reasoning, pages 3-31. Steffen Staab and Rudi Studer, Eds., Springer. 2003.
[BMRSS 1996]
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Buschmann, Frank, Meunier, Regine, Rohnert, Hans, Sommerlad, Peter, and Stal, Michael. John Wiley and Son Ltd., 1996.
[BMT 2005]
Case Studies on Ontology Reuse. Elena Paslaru Bontas, Malgorzata Mochol, Robert Tolksdorf. 5th International Conference on Knowledge Management (I-Know=9205). 2005.
[BCCG 2003]
Reasoning on UML Class Diagrams. Berardi, D., A. Caly, D. Calvanese, and G. De Giacomo TR-11-2003, Dipartimento di Informatica e Sistemistica, Universita di Roma, La Sapienza (2003)
[G 2003]
Ontology-oriented programming: Static typing for the inconsistent programmer. Neil M. Goldman. In 2nd International Semantic Web Conference (ISWC 2003), Sanibel Island, FL, 2003.
[KPBP 2004]
Automatic mapping of OWL ontologies into Java. Aditya Kalyanpur, Daniel Jimenez Pastor, Steve Battle, and Julian Padget.In 16th International Conference on Software Engineering and Knowledge Engineering (SEKE), Banff, Canada, 2004.
[ODM 2005]
Ontology Definition Metamodel. OMG Ontology Working Group. 2005.
[OWL 2004]
Web Ontology Language (OWL) Overview. McGuinness, Deborah L. and van Harmelen, Frank. W3C Recommendation. 2004.
[RDF 2004]
RDF Primer. Frank Manola, Erik Miller. W3C Recommendation. 2004.
[RTJ 2005]
Dynamic Object Model. Dirk Riehle, Michel Tilman, and Ralph Johnson. In Dragos Manolescu, Markus Völter, James Noble (eds.) Pattern Languages of Program Design5. Reading, MA: Addison-Wesley, 2005.
[TPOWUK 2005]
Ontology Driven Architectures and Potential Uses of the Semantic Web in Software Engineering. Tetlow, Phil, Pan, Jeff, Oberle, Daniel,Wallace, Evan, Uschold, Mike, and Kendall, Elisa. W3C Working Draft. 2005
