OWL Web本體語言 指南
W3C推薦標準 2004年02月10日
摘要
目前這種結構的萬維網，很像一本地圖做得很差的地理書，我們對於Web中可以使用的文檔和服務的瞭解，都是基於關鍵字搜索的， 同時還需要靈活地使用文檔的鏈接和使用模式。如果沒有強有力的工具的支持，這麼大規模的數據是很難管理的，爲了能夠給Web繪製出更爲詳實的地圖，計算代理需要對於網絡上可用資源的內容和能力做一個機器能夠讀得懂的描述。這些描述是人類能夠讀得懂的信息的擴展。
OWL，這種本體描述語言，可以用來描述Web文檔和應用中內在的類和關係。
這篇文章解釋了OWL語言的使用：
- 通過定義類以及類的屬性來形式化某個領域；
- 定義個體並說明它們之間的屬性；
- 在OWL語言的形式化語義允許的層次上，對類和個體進行推理。
本文的各章節間是按照類、屬性、個體的集合的定義給出來的，從最簡單的概念開始，逐漸過渡到更爲複雜的概念。
本文檔的狀態
本文檔已被W3C成員及其他相關方面審閱，並已被W3C總監（W3C Director）批准爲W3C推薦標準（W3C Recommendation）。W3C制定推薦標準的任務是使之受到關注，並促使其被廣泛應用。這將增強Web的功能性與互操作性。
本文檔是W3C關於Web本體語言OWL的推薦標準的六個部分之一。 它已經被Web 本體工作小組(小組章程) 作爲W3C語義Web行動 (行動聲明) 的一部分於2004年2月10日發佈。
本文檔的早期版本中所描述的關於OWL的設計已被廣泛評閱，並已滿足工作小組的技術需求。工作小組充分考慮所有收到的意見，並做了必要的修改。本文檔自從候選推薦標準版本以來的所有修改都在文後的變更日誌中。
歡迎通過[email protected] (歷史存檔)提出您的意見，也可以通過[email protected] (mailto:[email protected])(歷史存檔) 參與相關技術的討論。
可以訪問到有關實現的一個列表。
W3C維護着一個與這些工作相關的專利聲明的目錄。
這節描述了本文檔在發佈時的狀態。其他文檔可能替代這文檔。一份當前W3C的最新出版物的目錄和這個技術報告的最新版本可以在 W3C技術報告索引http://www.w3.org/TR/ 上找到。
3.2.1. 定義屬性（Defining Properties）
3.3.5. InverseFunctionalProperty
3.4.1. allValuesFrom, someValuesFrom
5.1 集合運算符 intersectionOf,unionOf,complementOf
5.1.1.交運算 [some uses of OWL DL]
5.3. 不相交類 disjointWith [OWL DL]
附錄C：2003年12月15日發佈的提議推薦標準以來的修改日誌
1. 引言
“告訴我我應該買什麼酒提供給下列菜單的每道菜，隨便說一下，我不喜歡蘇特恩白葡萄酒”。
目前構造一個能夠查找滿足這個查詢的酒的Web代理會是困難的。類似地，考慮派給軟件代理一個做出合理的旅行安排的任務（更多的用例，參考OWL需求文檔）。
爲了支持這種計算，不僅僅用關鍵詞而是說明Web上描述的資源的含義是必要的。這個額外的解釋層表述了數據的“語義”。
Web本體語言OWL是一種定義和實例化“Web本體”的語言。“本體”這個術語來自於哲學，它是研究世界上的各種實體以及他們是怎麼關聯的科學。一個“Web本體”可能包含了類，屬性和他們的實例的描述。給出這樣的一個本體，OWL形式語義說明怎麼獲得它的邏輯結論，也就是說，不是逐字寫在本體中的事實，而是語義蘊涵的事實。這些蘊涵可以是基於單個的文檔也或利用OWL機制合併在一起的多個分佈的文檔。
本文檔是W3CWeb本體工作組（WebOnt）制定的Web本體語言的描述的一部分。 OWL綜述([Overview)的文檔指南部分描述了不同部分的文檔以及他們怎樣結合的。
當描述另外一個XML/Web標準時，有一個問題會冒出來：這個標準給了我什麼XML和XML Schema不能給的。這個問題有兩個答案。
· 本體和XML Schema的區別是它是一種知識表示，而不是一種消息格式。大多數來自工業界的Web標準包含了一個消息格式和協議規範的組合。這些式已經被給予一個操作語義，例如，"一旦收到訂單（PurchaseOrder）的消息，從AccountFrom賬號轉移Amount數量的美元到AccountTo賬號，並且發貨(Product)"，但是這些規範並沒有設計爲支持此事務上下文之外的推理。例如，一般來說，沒有機制讓我們推出：因爲這個產品的類型是夏敦埃酒（Chardonnay，一種無甜味白葡萄酒），它必定也是一種白色酒。
· OWL本體的一個優點是會有能夠對其做推理的工具。這些工具提供了不特定於某個主題領域的通用支持，而如果要構建一個能對一個特定的工業界標準XML Schema做推理的系統，它往往是特定於一個領域的。構建一個可靠的和有用的推理系統不是一項簡單的工作。而創建一個本體則更爲容易處理。我們的期望就是很多團體會着手本體創建。他們會得益於基於OWL語言的形式屬性的第三方工具，這些工具提供了多種多樣的能力，而這些能力是大部分組織難以複製的。
1.1. OWL的種類
OWL提供了三種表達能力遞增的子語言，以分別用於特定的實現者和用戶團體。
· OWL Lite用於提供給那些只需要一個分類層次和簡單約束的用戶。例如，雖然OWL Lite支持支持基數限制，但只允許基數爲0或1。提供支持OWL Lite的工具應該比支持表達能力更強的其他OWL語言更簡單，並且從辭典（thesauri）和分類系統（taxonomy）轉換到OWL Lite更爲迅速。
· OWL DL 支持那些需要最強表達能力的推理系統的用戶，且這個推理系統能夠保證計算的完全性（computational completeness，即所有的結論都能夠保證被計算出來）和可判定性（decidability，即所有的計算都在有限的時間內完成）。它包括了OWL語言的所有成分，但有一定的限制，如類型的分離（一個類不能同時是一個個體或屬性，一個屬性不能同時是一個個體或類）。OWL DL 這麼命名是因爲它對應於[描述邏輯]，這是一個研究一階邏輯的一個特定可判定片斷的領域。OWL DL旨在支持已有的描述邏輯商業處理（business segment）和具有良好計算性質的推理系統。
· OWL Full 支持那些需要儘管沒有可計算性保證，但有最強的表達能力和完全自由的RDF語法的用戶。例如，在OWL Full中，一個類可以被同時看爲許多個體的一個集合以及本身作爲一個個體。另外一個和OWL DL的重要區別是owl:DatatypeProperty（數據類型屬性）能作爲一個owl:InverseFunctionalProperty（逆函數型屬性）。OWL full允許一個本體增加預定義的（RDF、OWL）詞彙的含義。這樣，不太可能有推理軟件能支持對OWL FULL的所有成分的完全推理。
在表達能力和推理能力上，每個子語言都是前面的語言的擴展。這三種子語言之間有如下關係成立，但這些關係反過來並不成立。
· 每個合法的OWL Lite本體都是一個合法的OWL DL本體；
· 每個合法的OWL DL本體都是一個合法的OWL Full本體；
· 每個有效的OWL Lite結論都是一個有效的OWL DL結論；
· 每個有效的OWL DL結論都是一個有效的OWL Full結論。
使用OWL的本體開發者要考慮哪種語言最符合他們的需求。選擇OWL Lite還是OWL DL主要取決於用戶在多大程度上需要OWL DL提供的表達能力更強的成分。OWL Lite的推理機會有良好的計算性質。而OWL DL的推理機處理的儘管是一個可判定的子語言，會有更高的最壞情況複雜度。選擇OWL DL還是OWL Full主要取決於用戶在多大程度上需要RDF的元模型機制（如定義關於類的類）；使用OWL Full相比於OWL DL，對推理的支持是更難預測的。關於此問題的更多信息參考OWL語義文檔。
用戶在把RDF文檔轉換到OWL DL或OWL Lite文檔時必須謹慎，以保證原來的RDF文檔是否滿足OWL DL 或OWL Lite對RDF的一些附加的限制。這些限制在文檔OWL參考的附錄E中有詳細的解釋。
當我們介紹只在 OWL DL或 OWL Full中允許的構詞（construct）時，他們被標記爲"[OWL DL]"。
1.2. 本文檔的結構
爲了在這個指南中提供一個一致的例子，我們創建了一個關於酒和食物的本體。它是一個OWL DL本體。我們有些討論會集中於OWL Full的表達能力，因此會標註出來。這個酒和食物本體是對歷史悠久的DAML本體庫中的一個元素的重大修改而成的。它最初由McGuinness作爲一個描述邏輯CLASSIC的例子開發的，後來擴充爲一個描述邏輯教程和一個本體教程。
在這個文檔中，我們假設大部分讀者熟悉XML，因此用RDF/XML語法表示例子([RDF], 5)。標準的OWL交換語法是RDF/XML。注意OWL在設計時保持了與RDF和RDF Schema的最大兼容性。這些XML和RDF格式是OWL標準的一部分。
本文檔中引進的所有例子都是從本體wine.rdf和 food.rdf中摘取的，除了那些在右下角用 ? 標註的。
2. 本體的結構
OWL是語義網活動的一個組成部分。這項工作的目的是通過對增加關於那些描述或提供網絡內容的資源的信息，從而使網絡資源能夠更容易地被那些自動進程訪問。由於語義網絡固有的分佈性，OWL必須允許信息能夠從分佈的信息源收集起來。其中，允許本體間相互聯繫，包括明確導入其他本體的信息，能夠部分實現這樣的功能。
另外，OWL提出了一個開放世界的假設。也就是說，對資源的描述並不侷限於在一個簡單的文件或範圍內。類C1本來是由本體O1定義出來的，然而，它也可以是由其他的本體擴展出來的。對C1進行這樣的假設的結果是單調的。新的信息不能否定之前的信息。新的信息可以是和舊的信息矛盾的，但是事實和推導只能被增加而不能被刪減。
當設計一個本體的時候，設計者必須考慮到這種矛盾的可能性。一種期望是，工具的支持將幫助偵測到這樣的情況。
爲了能寫出一個能被唯一翻譯的而且能被軟件（代理）使用的本體，我們要求OWL有一個語法和正規的語義。OWL是RDF的一個詞彙擴充[RDF語義]。在OWL網絡本體語言語義和簡明語法中，有OWL的語義定義。
2.1. 命名空間
在我們使用一組術語之前，我們需要一個精確地指出哪些具體的詞彙表將被用到。一個標準的本體開頭部分裏包括一組XML命名空間（namespace）聲明（被包含在rdf:RDF標籤裏）。這些命名空間聲明提供了一種無歧義地解釋標識符的方式，並使得剩餘的本體表示具有更強的可讀性。一個典型的OWL本體以一個命名空間聲明（namespace declaration）開始（就像下面的例子那樣）。當然，被定義本體的URIs未必都是w3.org的。
<rdf:RDF
xmlns ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xml:base ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#"
xmlns:owl ="http://www.w3.org/2002/07/owl#"
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd ="http://www.w3.org/2001/XMLSchema#">
前兩個聲明標識了與該本體相關的命名空間。第一個聲明指定了缺省命名空間，即表明所有無前綴的限定名（qualified names）都出自當前本體。第二個聲明爲當前本體指定了前綴 vin:。第三個聲明爲當前文檔（參見下文）指定了基準URI（base URI）。第四個聲明指出食物（food）本體將用前綴food:來標識。
第五個命名空間聲明指出，在當前文檔中，前綴爲owl:的元素應被理解是對出自http://www.w3.org/2002/07/owl#中的事物的引用。這是引入OWL詞彙表的慣例用法。
OWL要依賴RDF、RDFS以及XML Schema數據類型中的構詞（constructs）。在本文檔中，rdf:前綴表明事物出自命名空間 http://www.w3.org/1999/02/22-rdf-syntax-ns#。接下來的兩個命名空間聲明分別爲RDF Schema和XML Schema數據類型指定前綴rdfs:和xsd:。
爲幫助書寫冗長的URLs，在本體的定義之前，在文檔類型聲明（DOCTYPE）中提供一些實體定義（entity definitions）常常是很有用的。這些被命名空間聲明定義的名稱僅當作爲XML標籤的一部分時才具有意義。屬性值（attribute values）是不具有命名空間的。但是在OWL裏，我們經常要用屬性值來引用本體標識符。我們可以寫出它們的完整URI形式，比如“http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot”。或者，利用實體定義來簡略URI的書寫，例如：
<!DOCTYPE rdf:RDF [
<!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ]>
在聲明這些實體後，我們可以將“&vin;merlot”作爲“http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot”的簡寫。
更爲重要的是，這樣rdf:RDf命名空間聲明可以被簡化，並且只需對實體聲明作修改即可在整個本體範圍內應用URI的變化。
<rdf:RDF
xmlns ="&vin;"
xmlns:vin ="&vin;"
xml:base ="&vin;"
xmlns:food="&food;"
xmlns:owl ="http://www.w3.org/2002/07/owl#"
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd ="http://www.w3.org/2001/XMLSchema#">
2.2. 本體頭部
建立了命名空間後，接下來我們通常要在owl:Ontology標籤裏給出一組關於本體的聲明。這些標籤支持一些重要的常務工作比如註釋、版本控制以及其他本體的嵌入等。
<owl:Ontology rdf:about=""> <rdfs:comment>An example OWL ontology</rdfs:comment> <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/> <owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food"/> <rdfs:label>Wine Ontology</rdfs:label> ... 注意：我們使用“...”表明這裏有一些文本被略去了。
owl:Ontology元素是用來收集關於當前文檔的OWL元數據的。它不確保文檔描述一個傳統意義的本體。在某些圈子裏，本體不是關於個體的，而是僅僅關於某個領域的類和屬性的。在使用OWL來描述一個實例數據集合時，owl:Ontology標籤也許會被需要用來記錄版本信息，和導入文檔所依賴的一些定義。因此，在OWL裏，本體一詞被放寬了，已包含實例數據（如上文）。
rdf:about屬性爲本體提供一個名稱或引用。根據標準，當rdf:about屬性的值爲""時，本體的名稱是owl:Ontology元素的基準URI。典型地，這是一個包含本體的文檔的URI。在使用了xml:base的上下文中則是一個特殊情況，這時owl:Ontology元素的基準URI也許會被設爲其他URI。
rdfs:comment提供了顯然必須的爲本體添加註解的能力。
owl:priorVersion是一個爲用於本體的版本控制系統提供相關信息（hook）的標準標籤。本體的版本控制將在後面作進一步討論。
owl:imports提供了一種嵌入機制。owl:imports接受一個用rdf:resource屬性標識的參數。
導入另一個本體將把那個本體中的全部聲明引入到當前本體中。爲了充分利用好這一機制，通常要與命名空間聲明結合使用。請注意這兩種機制的區別。命名空間聲明提供的是一種方便對其他本體定義的名稱進行引用的方法。概念上，owl:imports用於表明包含目標本體中的聲明。在導入另一個本體02時，在02中導入的其他本體也將被導入。
注意：owl:imports並不是總能成功的。正如你所料的，在涉及語義網時，對分佈在Web上的資源的訪問也許是不可及的。在這種情況下，工具的響應是與具體實現相關的。
注意：不必爲了使用OWL本體詞彙，而導入owl.rdf本體。實際上，這樣導入是不推薦的。
一個理想的可被嵌入的標籤集合是部分標準的Dublin Core元數據標籤。該子集包含一些值爲簡單類型或字符串的標籤。比如：Title, Creator, Description, Publisher和Date等（參見RDF聲明）。
被用作註解的屬性（properties）應用owl:AnnotationProperty來聲明。例如
<owl:AnnotationProperty rdf:about="&dc;creator" />
OWL提供了若干其他的機制來將當前本體與被導入本體相關聯（參見本題映射部分）。
我們也可以用rdfs:label來對本體進行自然語言標註。
本體頭部定義在下列標籤處結束：
</owl:Ontology>
在這段開頭之後跟隨的是構成本體的實際定義，最終由
</rdf:RDF> 終止。
2.3. 數據集成與隱私
OWL在表達出現在多個文檔中的實例信息的能力方面，支持連接來自異源的數據。下層語義爲這些數據提供推理支持，這可以產生意外的結果。特別地，owl:sameAs的表達等價的能力，可被用來表達表面上不同的個體實際上是相同的。Owl:InverseFunctionalProperty也可被用來連接個體。例如，如果一個屬性，比如“SocialSecurityNumber”，是一個owl:InverseFunctionalProperty，那麼兩個分開的個體如果具有相同的SocialSecurityNumber屬性，則可被推理出是相同的個體。當個體被這樣確定爲相同時，來自異源的關於這些個體的信息可以被合併。這種聚合可被用來得出不可直接從單源獲得的事實。
語義網的連接來自多源的信息的能力是一個理想的、強大的特性，它可被用在許多應用中。但是合併來自多源數據的能力，加上OWL的推理能力，確實存在被誤用的可能。OWL用戶應對潛在的隱私問題予以警惕。具體的安全方案超出了工作組的工作範疇。一些組織正在用各種不同的安全和偏好方案來處理這些問題，比如SAML和P3P。
3. 基本元素（Basic Elements）
一個OWL本體中的大部分元素是與類（class）、屬性（property）[譯註//這裏的property也可譯作“特性”]、類的實例（instance）以及這些實例間的關係有關的。本節給出應用這些元素所必需的語言成分。
3.1. 簡單的類和個體
許多情況下，使用本體是爲了用它進行關於個體的推理。爲了在一種有效的方式下做到這一點，我們需要一種機制來描述個體所屬的類以及這些個體通過類成員關係而繼承得到的屬性。儘管我們總能爲個體聲明特定的屬性，但是本體的大部分能力在於基於類的推理。
有時，我們希望強調區分一個類是作爲對象還是作爲包含元素的集合。我們稱由屬於某個類的個體所構成的集合爲該類的外延（extension）。
3.1.1. 簡單的具名類
一個領域中的最基本概念應分別對應於各個分類層次樹的根。OWL中的所有個體都是類owl:Thing的成員。因此，各個用戶自定義的類都隱含地是owl:Thing的一個子類。要定義特定領域的根類，只需將它們聲明爲一個具名類（named class）即可。OWL也可以定義空類，owl:Nothing。
在我們所舉的葡萄酒領域的例子中，我們創建三個根類：Winery，Region和ConsumableThing。
<owl:Class rdf:ID="Winery"/>
<owl:Class rdf:ID="Region"/>
<owl:Class rdf:ID="ConsumableThing"/>
注意：我們只是說這裏有三個具有指定名稱（通過語法“rdf:ID=”）的類。形式上，即使我們使用了熟悉的英語單詞作爲標籤,但我們除了知道這些類的存在以外，仍不瞭解任何其他關於它們的信息。而這些類儘管存在，但它們可能沒有成員。就所有目前我們所知道的信息而言，將這些類分別命名爲Thing1、Thing2和Thing3與命名爲上述名稱沒有什麼區別。
記住這一點很重要，即定義可以是增量的和分佈式的。特別地，我們將在後面對Winery作更多的討論。
語法 rdf:ID="Region" 被用於引入一個名稱（作爲定義的一部分）。該rdf:ID屬性（attribute）（[RDF]，7.2.22）類似於XML中的ID屬性（attribute）。在這一文檔中，我們現在可以用#Region來引用Region類，例如 rdf:resource="#Region"。而其他的本體可以通過"http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Region"這一完整形式來引用該名稱。
另一種引用類的形式是用語法 rdf:about="#Region" 來擴展對一個資源的定義。語法rdf:about="&ont;#x" 的使用在分佈式本體的創建中是一個關鍵要素。它允許導入x類的定義並對它進行擴展，而不需修改源定義文檔，從而支持增量構建更大的本體。
現在，我們可以在其他OWL的構建中通過這些類的標識符來引用這些類。比如對於第一個類，同樣也在該文檔內的話,我們就可以使用相對標識符#Winery。由於其他文檔可能也需要引用這個類，因此最合理的方式是提供命名空間和實體定義，在其中包含着這個類的定義文檔作爲定義源：
...
<!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" >
...
<rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... >
...
給定上述定義後，我們便可以通過XML標籤vin:Winery或屬性（attribute）值&vin;Winery來引用winery類。更確切地說，我們總可以使用資源的完整URL來引用它們，比如這裏我們可以用http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery 來引用Winery類。
rdfs:subClassOf是用於類的基本分類構造符。它將一個較具體的類與一個較一般的類關聯。如果X是Y的一個子類（subclass），那麼X的每個實例同時也都是Y的實例。rdfs:subClassOf關係是可傳遞的，即如果X是Y的一個子類，而Y又是Z的一個子類，那麼X就是Z的一個子類。
<owl:Class rdf:ID="PotableLiquid">
<rdfs:subClassOf rdf:resource="#ConsumableThing" />
...
</owl:Class>
上面，我們把PotableLiquid（可飲用的液體）定義爲ConsumableThing的子類。
在基於Web的本體世界中，這兩個類可定義在一個分散的本體中，而這個本體又可以作爲各種不同的食物和飲料本體的基礎。我們已在食物(food)本體中定義了各種不同的食物和飲料本體，並將該食物本體導入葡萄酒（wine）本體中。食物本體中包含了許多類，如Food、EdibleThing、MealCourse和Shellfish等不屬於葡萄酒的事物，但是如果要做有用的推理，則必須將它們與葡萄酒本體中的詞彙相關聯。爲了滿足我們識別葡萄酒/食物對的需求，食物和葡萄酒本體是彼此獨立的。
一個類的定義由兩部分組成：引入或引用一個名稱，以及一個限制列表。被直接包含在類定義中的各個表達式進一步限制了該類的實例，該類的實例屬於所有這些限制的交集。（這裏描述的是成爲某個類的必要條件，關於描述成爲某個類的充分必要條件，請參見owl:equivalentClass部分。）到目前爲止，我們所看到的例子均爲只包含單個限制：強制被描述的新類爲某個其它具名類（named class）的子類。
至此，我們可以爲Wine類創建一個簡單的（和不完整的）定義。Wine是一個PortableLiquid。同時，我們將Pasta定義爲一個EdibleThing。
<owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> <rdfs:label xml:lang="en">wine</rdfs:label> <rdfs:label xml:lang="fr">vin</rdfs:label> ... </owl:Class> <owl:Class rdf:ID="Pasta"> <rdfs:subClassOf rdf:resource="#EdibleThing" /> ... </owl:Class> rdfs:label是可選的，它爲該類提供一個人類可讀的名稱。負責呈現的工具可以利用這個元素。“lang”屬性爲多語言提供了支持。一個label（標號）就像一個註釋，不向本體的邏輯解釋添加任何內容。
葡萄酒的定義仍然是不完整的。我們除了知道葡萄酒是一種事物並且適於飲用以外，對它別無所知。但我們有足夠的信息來創建個體和對個體進行推理。
3.1.2. 個體
除了描述類，我們還希望能夠描述類的成員。我們通常認爲類的成員是我們所關心的範疇中的一個個體（而不是另一個類或屬性）。要引入一個個體（individual），只需將它們聲明爲某個類的成員。
<Region rdf:ID="CentralCoastRegion" /> 注意：下面代碼的含義與上面的例子相同。
<owl:Thing rdf:ID="CentralCoastRegion" />
<owl:Thing rdf:about="#CentralCoastRegion">
<rdf:type rdf:resource="#Region"/>
</owl:Thing>
rdf:type是一個RDF屬性（RDF property），用於關聯一個個體和它所屬的類。
這裏有一些注意點。首先，我們已經決定CentralCoastRegion（一個特定的區域）是Region的成員。這裏的Region類包含所有地理上的區域。其次，對於上述這一由兩個元素構成的示例，並沒有要求這兩個陳述必須是相鄰的、或必須位於同一文件中（儘管這些名字在這種情況下需要擴充一個URI）。Web本體被設計成爲分佈式的，我們可以通過導入和補充已有的本體來創建衍生的本體。
爲了得到更多的類用於將在下一節引入的屬性，我們定義了一個Grape（葡萄）的層次分類以及一個代表Cabernet Sauvignon品種的葡萄的個體。Grapes在食物本體中是這樣定義的：
<owl:Class rdf:ID="Grape">
...
</owl:Class>
接着，我們在葡萄酒本體中有：
<owl:Class rdf:ID="WineGrape"> <rdfs:subClassOf rdf:resource="&food;Grape" /> </owl:Class> <WineGrape rdf:ID="CabernetSauvignonGrape" /> 正如下一節將要討論的，CabernetSauvignonGrape是一個個體，因爲它代表的是某個單個葡萄品種。
3.1.3. 使用方面的考慮
關於OWL中類與個體的區別，有一些重要的問題。一個類僅是一個名稱和一些描述某集合內個體的屬性；而個體是該集合的成員。因此，類應自然地對應於與某論域中的事物的出現集合，而個體應對應於可被歸入這些類的實際的實體。
在構建本體時，這個區別常常變得模糊不清，主要有兩種情況：
· 表示的層次： 在某些上下文中，某些事物明顯是一個類，但同時其本身又可被視爲另一個事物的實例。例如：在葡萄酒本體中，我們有Grape的概念，它是代表所有葡萄品種的集合。CabernetSauvingonGrape是這個類中的一個實例，它代表Cabernet Sauvignon這一葡萄品種。但是，CabernetSauvignonGrape其自身也可被視爲一個類，即代表所有實際的 Cabernet Sauvignon葡萄這一集合的類。
· 子類 vs. 實例： 實例（instance-of）關係和子類（subclass）關係很容易被混淆。例如，也許看上去可以隨意地將CabernetSauvignonGrape作爲Grape的一個實例，而不是作爲Grape的一個子類，但實際上這個決定並不是隨意的。Grape類代表的是所有葡萄品種的集合，因此任何Grape的子類應代表這些品種的一個子集。因而，CabernetSauvignonGrape應被認爲是Grape的一個實例，而不是一個子類。因爲CabernetSauvignonGrape是一個葡萄品種，而不是一個葡萄品種的子類。
注意：對於Wine類也同樣有着上述問題。Wine類實際上代表的是所有葡萄酒種類的集合，而不是某人可以購買的瓶裝葡萄酒的集合。設想在另一個本體中，各個Wine類的實例代表一個類，該類是某類葡萄酒的瓶裝葡萄酒的集合。容易設想這樣一個信息系統，例如一個葡萄酒商的庫存系統，它需要處理各個瓶裝葡萄酒。葡萄酒本體需要有把類作爲實例處理的能力，以支持該解釋。注意：OWL Full是允許這樣表達的，這使得我們可以同時將一個葡萄酒品種的實例視爲一個類，而該類的實例是瓶裝葡萄酒。
同樣的，葡萄酒廠在特定年份所生產的葡萄酒將被視爲佳酒。爲了表達佳酒這一概念，我們必須考慮將它置於當前本體中的何處。如前所述，一個Wine類的實例代表的是某葡萄酒廠所生產的某個單個葡萄酒種類，比如FormanChardonnay。
要表達“2000年生產的葡萄酒被視爲佳酒”是有點複雜的，因爲我們沒有表達某種給定葡萄酒的個體的子集的能力。佳酒並不是一個新的葡萄酒種類，而是一個特殊的葡萄酒子集，即那些產於2000年的葡萄酒。一個方案是使用OWL Full，將Wine類的實例視爲類，而後者的子類（子集）代表瓶裝葡萄酒。另一個方案是使用變通手法，即將Vintage視爲一個單獨的類，Vintage的實例與代表它所屬種類的Wine類相關聯。例如，FormanChardonnay2000是一個Vintage類的個體，它通過vintageOf屬性與Wine類的個體FormanChardonnay相關聯。我們將在後面看到Vintage類的定義。
這裏需要注意的一點是，一個本體的開發應堅定地由它的預定用途所驅動。這些問題也存在於OWL Full和OWL DL之間的一個重要區別。OWL Full允許將類（class）用作實例（instance），而OWL DL不允許。由於葡萄酒本體被預定爲使用OWL DL，因此不會將個體（例如FormanChardonnay等）同時作爲類來看待。
3.2. 簡單屬性
如果僅允許定義層次分類，那麼這個類和個體的世界也許會變得頗爲無趣。屬性（propertyies）使得我們可以斷言關於類成員的一般事實以及關於個體的具體事實。
3.2.1. 定義屬性（Defining Properties）
ObjectProperty, DatatypeProperty, rdfs:subPropertyOf, rdfs:domain, rdfs:range
一個屬性是一個二元關係。有兩種類型的屬性：
· 數據類型屬性（datatype properties），類實例與RDF文字或XML Schema數據類型間的關係。
· 對象屬性（object properties），兩個類的實例間的關係。注意：對象屬性這個名稱並不是要反映與RDF（[RDF]，5.3.4）的聯繫。
在我們定義一個屬性的時候，有一些對該二元關係施加限定的方法。我們可以指定定義域（domain）和值域（range）。可以將一個屬性定義爲某個已有屬性的特殊化（子屬性）。要進行更詳細的限定也是可能的，我們將在後面對此作出介紹。
<owl:ObjectProperty rdf:ID="madeFromGrape">
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="course">
<rdfs:domain rdf:resource="#Meal" />
<rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>
在OWL中，不含顯式操作符的元素序列代表一個隱式的合取（conjunction）。屬性madeFromGrape的定義域（domain）爲Wine，且值域（range）爲WineGrape。也就是說，它把Wine類的實例關聯到WineGrape類的實例。爲同一屬性聲明多個定義域表明該屬性的定義域是所有這些類的交集（多個值域聲明也類似這樣）。
同樣地，屬性course將一個Meal與MealCourse相關聯。
注意：OWL中值域和定義域信息的使用與程序設計語言中的類型信息有所不同。在程序設計中，類型被用來檢查程序設計語言的一致性。而在OWL中，一個值域可被用來推斷一個類型。比如，根據下面這段代碼：
<owl:Thing rdf:ID="LindemansBin65Chardonnay"> <madeFromGrape rdf:resource="#ChardonnayGrape" /> </owl:Thing> ┐ 我們可以推斷出，LindemansBin65Chardonnay是一種葡萄酒，因爲madeFromGrape的定義域爲Wine。
屬性也可以像類一樣按照層次結構來組織。
<owl:Class rdf:ID="WineDescriptor" />
<owl:Class rdf:ID="WineColor">
<rdfs:subClassOf rdf:resource="#WineDescriptor" />
...
</owl:Class>
<owl:ObjectProperty rdf:ID="hasWineDescriptor">
<rdfs:domain rdf:resource="#Wine" />
<rdfs:range rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasColor">
<rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
<rdfs:range rdf:resource="#WineColor" />
...
</owl:ObjectProperty>
WineDescriptor屬性將葡萄酒（wine）與它們的顏色（color）和味覺成分（包括甜、濃、口味）相關聯。hasColor是hasWineDescriptor的子屬性，hasColor與hasWineDescriptor的不同在於它的值域被進一步限定爲WineColor。rdfs:subPropertyOf關係表示：任何事物如果具有一個值爲X的hasColor屬性，那麼它同時具有一個值爲X的hasWineDescriptor屬性。
下面，我們介紹locatedIn屬性，它將事物和事物所在的地區相關聯。
<owl:ObjectProperty rdf:ID="locatedIn">
...
<rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
請注意是如何定義locateIn的定義域和值域的。該定義域定義允許任何事物被值域某個區域中，包括該區域自身。這一關係的傳遞的組合本質上構建了一個包含子區域和事物的地理網絡。沒有包含其他事物於其中的那些事物可以屬於任意類,而包含其他事物或者區域的那些事物則必須是區域。
現在可以擴展Wine的定義來表達“一個葡萄酒是由至少一種WineGrape製成的”了。和屬性定義一樣，類定義也由多個隱含相聯的部分組成。
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#madeFromGrape"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class>
上述被高亮的子類限定
<owl:Restriction> <owl:onProperty rdf:resource="#madeFromGrape"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> 定義了一個無名類（unnamed class），該無名類代表至少具有一個madeFromGrape屬性的事物集合。我們稱這些類爲匿名類。在Wine類的定義中包含該限定表明屬於Wine類的事物，也是該匿名類的成員。也就是說，任何葡萄酒都必須參與至少一個madeFromGrape關係。
現在，我們可以描述前面所提到的Vintage類了。
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#vintageOf"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class> ┐
vintageOf屬性將一個Vintage關聯到Wine。
<owl:ObjectProperty rdf:ID="vintageOf"> <rdfs:domain rdf:resource="#Vintage" /> <rdfs:range rdf:resource="#Wine" /> </owl:ObjectProperty> ┐ 我們將在下一節把Vintages關聯到它們的生產年份。
3.2.2. 屬性和數據類型
根據是將個體關聯到個體、還是將個體關聯到數據類型，我們可以區分兩類屬性：前者稱爲對象屬性（object properties）；後者稱爲數據類型屬性（datatype properties）。數據類型屬性的值域範圍是RDF文字或者是XML Schema數據類型中定義的那些簡單類型（simple types）。
OWL使用XML Schema內嵌數據類型中的大部分。對這些數據類型的引用是通過對http://www.w3.org/2001/XMLSchema 這個URI引用進行的。下列數據類型是推薦在OWL中使用的：
xsd:string xsd:normalizedString xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonNegativeInteger xsd:positiveInteger xsd:nonPositiveInteger xsd:negativeInteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedLong xsd:unsignedInt xsd:unsignedShort xsd:unsignedByte xsd:hexBinary xsd:base64Binary xsd:dateTime xsd:time xsd:date xsd:gYearMonth xsd:gYear xsd:gMonthDay xsd:gDay xsd:gMonth xsd:anyURI xsd:token xsd:language xsd:NMTOKEN xsd:Name xsd:NCName
上面的數據類型，連同rdfs:Literal構成了OWL的內嵌數據類型。所有的OWL推理機都應支持xsd:integer和xsd:string數據類型。
其他XML Schema內嵌數據類型可被在OWL Full中，但在OWL Semantics and Abstract Syntax中給出了一些警告。
<owl:Class rdf:ID="VintageYear" />
<owl:DatatypeProperty rdf:ID="yearValue">
<rdfs:domain rdf:resource="#VintageYear" />
<rdfs:range rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty>
yearValue屬性將VintageYears與一個整數值相關聯。我們將引入hasVintageYear屬性，它將一個Vintage關聯到一個VintageYear（如下）。
OWL Reference描述了owl:oneOf的使用、以及用rdf:List和rdf:rest來定義一個枚舉數據類型，那裏有個例子展示瞭如何構建一個值域爲整數值列表{0, 15, 30, 40}的數據類型屬性tennisGameScore。
3.2.3. 個體的屬性
首先，我們描述Region和Winery個體，然後我們定義第一個葡萄酒Cabernet Sauvignon。
<Region rdf:ID="SantaCruzMountainsRegion"> <locatedIn rdf:resource="#CaliforniaRegion" /> </Region> <Winery rdf:ID="SantaCruzMountainVineyard" /> <CabernetSauvignon rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" > <locatedIn rdf:resource="#SantaCruzMountainsRegion"/> <hasMaker rdf:resource="#SantaCruzMountainVineyard" /> </CabernetSauvignon> 這仍然是不完整的。完整的本體中存在關於葡萄酒口味的其他方面的定義。但這些片斷將會慢慢地揍齊爲一個整體。我們不妨先開始推理葡萄酒將會與食物本體中的什麼菜單項相伴。我們從上述定義得知，它將是Santa Cruz Mountain Vineyard。因爲它是一種Cabernet Sauvignon（定義參見wine.rdf），我們知道它是一種乾的（dry）、紅色（red）葡萄酒（參見wine.rdf）。
可以用同樣的方式給個體增加數據類型屬性。下面，我們描述一個VintageYear的實例，並將它關聯到一個特定的&xsd;positiveInteger類型的值。
<VintageYear rdf:ID="Year1998"> <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue> </VintageYear>
3.3. 屬性特性
接下來的幾節描述了用以進一步說明屬性的機制。我們可以對屬性的特性進行詳細的說明，這就提供了一種強有力的機制以增強對於一個屬性的推理。
3.3.1. TransitiveProperty
如果一個屬性P被聲明爲傳遞屬性，那麼對於任意的x,y和z：
P(x,y) 與 P(y,z) 蘊含 P(x,z)
屬性locatedIn是傳遞屬性。
<owl:ObjectProperty rdf:ID="locatedIn">
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdfs:domain rdf:resource="&owl;Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Region rdf:ID="CaliforniaRegion">
<locatedIn rdf:resource="#USRegion" />
</Region>
因爲聖克魯斯山地區（SantaCruzMountainsRegion）位於（locatedIn）加利福尼亞地區（CaliforniaRegion），那麼它也應該位於（locatedIn）美國地區（USRegion），因爲屬性locatedIn是傳遞屬性。
3.3.2. SymmetricProperty
如果一個屬性P被聲明爲對稱屬性，那麼對於任意的x和y：
P(x,y)當且僅當P(y,x)
adjacentRegion屬性是對稱屬性，而locatedIn屬性則不是。更準確地說，locatedIn屬性是沒有被規定爲對稱屬性。在當前的葡萄酒本體中沒有任何限制，讓它不能成爲對稱屬性。
<owl:ObjectProperty rdf:ID="adjacentRegion"> <rdf:type rdf:resource="&owl;SymmetricProperty" /> <rdfs:domain rdf:resource="#Region" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> <Region rdf:ID="MendocinoRegion"> <locatedIn rdf:resource="#CaliforniaRegion" /> <adjacentRegion rdf:resource="#SonomaRegion" /> </Region> MendocinoRegion地區與SonomaRegion地區相鄰，反過來也是這樣。MendocinoRegion地區位於CaliforniaRegion地區，但是反過來並不成立。
3.3.3. FunctionalProperty
如果一個屬性P被標記爲函數型屬性，那麼對於所有的x, y, 和z:
P(x,y) 與P(x,z) 蘊含 y = z
在我們的葡萄酒本體中，hasVintageYear屬性是函數型屬性。一種葡萄酒有着一個特定的製造年份。也即，一個給定的Vintage個體只能使用hasVintageYear屬性與單獨一個年份相關聯。owl:FunctionalProperty並不要求該屬性的定義域的所有元素都有值。請參見關於Vintage的基數的討論。
<owl:Class rdf:ID="VintageYear" /> <owl:ObjectProperty rdf:ID="hasVintageYear"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Vintage" /> <rdfs:range rdf:resource="#VintageYear" /> </owl:ObjectProperty>
3.3.4. inverseOf
如果一個屬性P1被標記爲屬性P2的逆（owl:inverseOf）, 那麼對於所有的x 和 y:
P1(x,y) 當且僅當P2(y,x)
請注意owl:inverseOf的語法，它僅僅使用一個屬性名作爲參數。A 當且僅當B 意思是 (A 蘊含 B)並且(B蘊含A).
<owl:ObjectProperty rdf:ID="hasMaker">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="producesWine">
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>
各種葡萄酒都有製造商，這些製造商在Wine類的定義中被限制爲釀酒廠（Winery）。而每個釀酒廠生產的酒均以該釀酒廠爲製造商。
3.3.5. InverseFunctionalProperty
如果一個屬性P被標記爲反函數型的（InverseFunctional），那麼對於所有的x, y 和 z:
P(y,x) 與 P(z,x) 蘊含 y = z
我們可以注意到，在前面的章節中提到的producesWine屬性是反函數型屬性。因爲一個函數型屬性的逆必定是反函數型的。我們也能夠如下定義hasMaker屬性和 producesWine 屬性以達到和前例中相同的效果。
<owl:ObjectProperty rdf:ID="hasMaker" />
<owl:ObjectProperty rdf:ID="producesWine">
<rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>
反函數型屬性的值域中的元素可以看成是在數據庫意義上定義一個唯一的鍵值。owl:InverseFunctional意味着屬性的值域中的元素爲定義域中的每個元素提供了一個唯一的標識。
在OWL Full中，DatatypeProperty屬性可以被聲明爲一個反函數型屬性。這就使得我們能夠使用一個字符串作爲一個唯一的鍵值。在OWL DL中，文字（literal）與owl:Thing是不相交的，因此OWL DL不允許將InverseFunctional屬性聲明應用到DatatypeProperty屬性。
3.4. 屬性限制
除了能夠指定屬性特性，我們還能夠使用多種方法進一步在一個明確的上下文中限制屬性的值域。這是通過“屬性限制”來完成的。下面描述的多種形式僅在owl:Restriction的上下文中才能使用。owl:onProperty元素指出了受限制的屬性。
3.4.1. allValuesFrom, someValuesFrom
我們已經發現了一種限制組成屬性的元素的類型的方法。到現在爲止，我們所講述的機制都是全局的（global），因爲這些機制都會應用到屬性的所有實例。而接下來要講述的兩個屬性限制機制，allValuesFrom與 someValuesFrom，則是 局部的（local），它們僅僅在包含它們的類的定義中起作用。
owl:allValuesFrom屬性限制要求：對於每一個有指定屬性實例的類實例，該屬性的值必須是由owl:allValuesFrom從句指定的類的成員。
<owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid" /> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasMaker" /> <owl:allValuesFrom rdf:resource="#Winery" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class> Wine的製造商必須是Winery。allValuesFrom限制僅僅應用在Wine的hasMaker 屬性上。Cheese的製造商並不受這一局部限制的約束。
owl:someValuesFrom限制與之相似。在上個例子中，如果我們用owl:someValuesFrom替換owl:allValuesFrom，那就意味着至少有一個Wine類實例的hasMaker屬性是指向一個Winery類的個體的。
<owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasMaker" /> <owl:someValuesFrom rdf:resource="#Winery" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class> 這兩種限制形式間的不同就是全稱量詞與存在量詞間的不同。
|
|
關係 |
含意 |
|
allValuesFrom |
對於所有的葡萄酒，如果它們有製造商，那麼所有的製造商都是釀酒廠。 |
|
|
someValuesFrom |
對於所有的葡萄酒，它們中至少有一個的製造商是釀酒廠。 |
|
前者並不要求一種葡萄酒一定要有一個製造商。如果它確實有一個或多個製造商，那麼這些製造商必須全部都是釀酒廠。後者要求至少有一個製造商是釀酒廠，但是可以存在不是釀酒廠的製造商。
3.4.2. 基數限制
在前面我們已經看到過關於基數約束的例子了。到目前爲止的例子中，這些約束都是關於最小基數的所作出的斷言。更爲直接的方法是使用owl:cardinality，這一約束允許對一個關係中的元素數目作出精確的限制。例如，我們可以將Vintage標識爲恰好含有一個VintageYear的類。
<owl:Class rdf:ID="Vintage"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasVintageYear"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> 我們標識hasVintageYear屬性爲一個函數型屬性，也即意味着每個Vintage有至多一個VintageYear。而如果對Vintage類的hasVintageYear屬性使用基數限制則是對其作出了更強的斷言，它表明了每個Vintage有恰好一個VintageYear。
值域限制在0和1的基數表達式(Cardinality expressions)是OWL Lite的一部分。這使得用戶能夠表示“至少一個”，“不超過一個”，和“恰好一個”這幾種意思。OWL DL中還允許使用除0與1以外的正整數值。owl:maxCardinality能夠用來指定一個上界。owl:minCardinality能夠用來指定一個下界。使用二者的組合就能夠將一個屬性的基數限制爲一個數值區間。
3.4.3. hasValue [OWL DL]
hasValue 使得我們能夠根據“特定的”屬性值的存在來標識類。因此，一個個體只要至少有“一個”屬性值等於hasValue的資源，這一個體就是該類的成員。
<owl:Class rdf:ID="Burgundy"> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasSugar" /> <owl:hasValue rdf:resource="#Dry" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> 這裏我們聲明瞭所有的Burgundy酒都是幹(dry)的酒。也即，它們的hasSugar屬性必須至少有一個是值等於Dry（乾的）。
與allValuesFrom 和someValuesFrom類似，這是一個局部的限制。它僅僅對Burgundy類的hasSugar屬性作出限制。
4. 本體映射
爲了讓本體發揮最大的作用，就需要讓本體得到充分的共享。爲了使得在開發本體時儘可能的節省人力，就需要使得開發出的本體能夠被重用。更理想的情況是他們能夠被組合使用。例如，你可能同時使用來自某一來源的日期本體(date ontology)和來自另一來源的物理位置本體(physical location ontology),並將位置(location)的概念加以擴展以包括這個位置所處在的時間段。
在開發一個本體的過程中，很多的精力都被投入到將類與屬性聯繫起來以獲取最大的意義的工作上去了,意識到這一點也是很重要的。我們希望對類成員作出的斷言較爲簡單同時又要求有廣泛的和有用的含意在裏面。這也是在本體開發過程中最爲困難的工作。如果你能夠找到已經經過廣泛使用和精煉的本體，那麼採用它纔有意義。
多個本體的合併工作是非常具有挑戰性的。爲了維護其一致性,幾乎必然需要工具的支持。
4.1. 類和屬性之間的等價關係
equivalentClass, equivalentProperty
當我們要把一些本體組合在一起作爲另一個新的本體的一部分時，能說明在一個本體中的某個類或者屬性與另一個本體中的某個類或者屬性是等價的，這往往很有用。在實際應用中我們這樣做的時候要千萬小心。因爲如果要組合的那些本體是互相矛盾的（所有A的都是B的 與 A的並不全是B的），那麼在組合得到的結果中就不會有滿足條件的擴展（沒有滿足條件的個體或關係）了。
在食物本體中，我們現在想把在餐宴菜餚中對葡萄酒特點的描述與葡萄酒本體相聯繫起來。達到這一目的一種方法就是在食物本體中定義一個類(&food;Wine)，然後在葡萄酒本體中將一個已有的類聲明爲與這個類是等價的。
<owl:Class rdf:ID="Wine"> <owl:equivalentClass rdf:resource="&vin;Wine"/> </owl:Class> 屬性owl:equivalentClass被用來表示兩個類有着完全相同的實例。但我們要注意，在OWL DL中，類僅僅代表着個體的集合而不是個體本身。然而在OWL FULL中，我們能夠使用owl:sameAs來表示兩個類在各方面均完全一致。
當然了，上面我們舉的例子多少有點刻意人爲的意思，因爲我們總是能在本來用＃Wine的地方使用&vin;Wine以取得同樣的效果而不需要重新定義類。一種更可能出現的情況是：我們依賴兩個獨立開發的本體，並注意到他們使用了O1:foo和O2:bar這兩個URI引用相同的一個類。 這時我們就能夠使用owl:equivalentClass將這兩個類關聯起來， 使得從這兩個本體中繼承的限制也得到合併。
大家都知道，類名（類的表達式）既能用於<rdfs:subClassOf >設計中，又能用於<owl:equivalentClass>設計中。一個類名可多處使用，既省卻了命名的麻煩，又給我們提供了基於屬性要求的強大的定義能力。
<owl:Class rdf:ID="TexasThings"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn" /> <owl:someValuesFrom rdf:resource="#TexasRegion" /> </owl:Restriction> </owl:equivalentClass> </owl:Class> TexasThings指的是那些恰好位於Texas地區的事物。使用owl:equivalentClass 和使用rdfs:subClassOf 的不同就像必要條件和充要條件的不同一樣。如果是使用subClassOf的話，位於Texas地區的事物不一定是TexasThings。但是，如果使用owl:equivalentClass，位於Texas地區的事物一定屬於TexasThings類。
|
|
關係 |
蘊涵 |
|
subClassOf |
TexasThings(x) implies?locatedIn(x,y) and TexasRegion(y) |
|
|
equivalentClass |
TexasThings(x) implies locatedIn(x,y) and TexasRegion(y) |
|
類似的，我們可以通過使用owl:equivalentProperty屬性聲明表達屬性的等同。
4.2 個體間的同一性
描述個體之間相同的機制與描述類之間的相同的機制類似，僅僅只要將兩個個體聲明成一致的就可以了。
例如這樣一個例子：
<Wine rdf:ID="MikesFavoriteWine> <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> </Wine> <Wine rdf:ID="MikesFavoriteWine"> <owl:sameAs rdf:resource="#StGenevieveTexasWhite" /> </Wine> 在這個例子並沒有什麼實際意義。所有我們從中能瞭解到的就是Mike喜歡一種便宜的本地酒。sameAs的一種更加典型的用法是將不同文檔中定義的兩個個體等同起來，作爲統一兩個本體的部分。
但這樣做帶來了一個問題。OWL中並沒有名稱唯一這一假定。僅僅名稱不同並不意味着這兩個名稱引用的是不同的個體。
在上面的例子中，我們對兩個截然不同的名稱作出一致性斷言。但是也只有在這種標示的情況下，纔可能進行推理。請記住那些可能從函數型屬性中得出的含意。假如hasMaker是一個函數型屬性，那麼下面的例子就不一定會產生衝突。
<owl:Thing rdf:about="#BancroftChardonnay">
<hasMaker rdf:resource="#Bancroft" />
<hasMaker rdf:resource="#Beringer" />
</owl:Thing>
除非和我們本體中的其他信息發生衝突，不然的話這樣的描述是沒有衝突的，他說明Bancroft和Beringer是相同的個體。
要清楚，修飾（或引用）兩個類用sameAs還是用equivalentClass效果是不同的。用sameAs的時候，把一個類解釋爲一個個體，就像在OWL Full中一樣，這有利於對本體進行分類。在OWL Full中，sameAs可以用來引用兩個東西，如一個類和一個個體、一個類和一個屬性等等，無論什麼情況，都將被解釋爲個體。
4.3. 不同的個體
這一機制提供了與sameAs相反的效果。
<WineSugar rdf:ID="Dry" /> <WineSugar rdf:ID="Sweet"> <owl:differentFrom rdf:resource="#Dry"/> </WineSugar> <WineSugar rdf:ID="OffDry"> <owl:differentFrom rdf:resource="#Dry"/> <owl:differentFrom rdf:resource="#Sweet"/> </WineSugar> 這是一種聲明這三個值相互不同的方法。但在有些時候，更重要的是利用這些定義元素能把這種不同區別開來。沒有上述的定義元素，我們可能會定義一種既幹又甜的葡萄酒，並且添加hasSugar屬性使其取值小於等於某個值來限定該種葡萄酒的甜度。如果我們沒有用 differentFrom元素來申明既幹又甜的葡萄酒，這意味着“幹葡萄酒”和“甜葡萄酒”是相同的。但是我們從上面申明的元素來推斷，這又是矛盾的。
還有一種更便利的定義相互不同個體的機制。如下面申明紅葡萄酒、白葡萄酒和玫瑰葡萄酒的例子。
<owl:AllDifferent> <owl:distinctMembers rdf:parseType="Collection"> <vin:WineColor rdf:about="#Red" /> <vin:WineColor rdf:about="#White" /> <vin:WineColor rdf:about="#Rose" /> </owl:distinctMembers> </owl:AllDifferent> 要注意，owl:distinctMembers屬性聲明只能和owl:AllDifferent屬性聲明一起結合使用。
在葡萄酒本體中，我們爲所有的WineDescriptor提供了一個owl:AllDifferent聲明。我們同時還聲明瞭所有的Winery是不同的。這時，如果我們想要在其他的某個本體中添加一個新的釀酒廠，並表明它是與其他已定義的任何釀酒廠都是不同的，我們可能需要拷貝原來的owl:AllDifferent屬性聲明，然後將新的製造廠添加到列表中。在OWL DL中，沒有更加簡單的方法以擴展一個聲明爲owl:AllDifferent的集合。而在OWL Full中，通過使用RDF三元組和rdf:List構造，可以實現一些其他的方法來完成這一擴展。
5. 複雜類 [OWL DL]
OWL另外還提供了一些用於構建類的構造子。這些構造子被用於創建所謂的類表達式。OWL支持基本的集合操作，即並，交和補運算。它們分別被命名爲owl:unionOf,owl:intersectionOf,和owl:complementOf.此外，類還可以是枚舉的。類的外延可以使用oneOf構造子來顯示的聲明。同時，我們也可以聲明類的外延必須是互不相交的。
注意類表達式是可以嵌套的，它並不要求要爲每一箇中間類都提供一個名字。這樣就允許我們通過使用集合操作來從匿名類或具有值約束的類來創建複合類。
5.1 集合運算符 intersectionOf,unionOf,complementOf
記住:OWL類外延是由個體組成的集合，而這些個體都是類的成員。OWL使用基本的集合操作算子來處理類的外延。
5.1.1.交運算 [some uses of OWL DL]
下面的例子展示了intersectionOf構造子的使用
<owl:Class rdf:ID="WhiteWine"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Wine" /> <owl:Restriction> <owl:onProperty rdf:resource="#hasColor" /> <owl:hasValue rdf:resource="#White" /> </owl:Restriction> </owl:intersectionOf> </owl:Class> 使用集合操作構造的類與我們目前所看到的所有語法中的定義類似。類的成員完全是通過集合操作來說明的。上面的語句說明WhiteWine恰好是類Wine與所有顏色是白色的事物的集合的交集。這就意味着如果某一事物是白色的並且是葡萄酒，那麼它就是WhiteWine的實例。如果沒有這樣的定義我們只能知道白葡萄酒是葡萄酒酒並且是白色的，但是反過來就不是這樣了。這是對個體進行分類的強有力工具。(請注意：'rdf:parseType="Collection"'是必需的語法元素。)
<owl:Class rdf:about="#Burgundy"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Wine" /> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn" /> <owl:hasValue rdf:resource="#BourgogneRegion" /> </owl:Restriction> </owl:intersectionOf> </owl:Class> 在這裏我們定義了Burgundy類。這個類恰好包含了那些至少有一個locatedIn關係，而同時這一關係又要聯繫到Bourgogne地區的葡萄酒。當然我們也可以聲明一個新的類ThingsFromBourgogneRegion，並且將該類作爲owl:intersectionOf結構中的類使用。但既然ThingsFromBourgogneRegion不再有其他用處，上面的聲明就顯得更加簡短、清晰，並且這一聲明不需要我們努力想一個新的名字出來。
<owl:Class rdf:ID="WhiteBurgundy"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Burgundy" /> <owl:Class rdf:about="#WhiteWine" /> </owl:intersectionOf> </owl:Class> 最後，WhiteBurgundy類恰好是白葡萄酒和Burgundies的交集。依次，Burgundies生產在法國一個叫做Bourgogne的地方並且它是幹葡萄酒（dry wine）。因此，所有滿足這些標準的葡萄酒個體都是WhiteBurgundy類的外延的一部分。
5.1.2. 並運算 [OWL DL]
下面的例子展示了unionOf結構的使用。它的使用方法和intersectionOf極其類似:
<owl:Class rdf:ID="Fruit"> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#SweetFruit" /> <owl:Class rdf:about="#NonSweetFruit" /> </owl:unionOf> </owl:Class> Fruit類既包含了SweetFruit類的外延也包含了NonSweetFruit的外延。
請仔細觀察這種並集類型的結構與下面的一個結構是多麼的不同。
<owl:Class rdf:ID="Fruit"> <rdfs:subClassOf rdf:resource="#SweetFruit" /> <rdfs:subClassOf rdf:resource="#NonSweetFruit" /> </owl:Class> 上面的例子說明Fruit的實例是SweetFruit和NonSweetFruit的交集的子集,這裏我們將預計得到一個空集。
5.1.3. 補運算 [OWL DL]
complementOf結構從某個論域(domain of discourse)選出不屬於某個類的所有個體。通常它將指向一個非常大的個體集合：
<owl:Class rdf:ID="ConsumableThing" /> <owl:Class rdf:ID="NonConsumableThing"> <owl:complementOf rdf:resource="#ConsumableThing" /> </owl:Class> 類NonConsumableThing包含了所有不屬於ConsumableThing的外延的個體。NonConsumableThing集合包含了所有的Wines,Regions等。它實際上就是owl:Thing與ConsumableThing的這兩個集合的集合差。因此，complementOf典型的用法是與其它集合運算符聯合使用：
<owl:Class rdf:ID="NonFrenchWine"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Wine"/> <owl:Class> <owl:complementOf> <owl:Restriction> <owl:onProperty rdf:resource="#locatedIn" /> <owl:hasValue rdf:resource="#FrenchRegion" /> </owl:Restriction> </owl:complementOf> </owl:Class> </owl:intersectionOf> </owl:Class> 上面的例子定義了一個NonFrenchWine類，它是Wine類與所有不位於法國的事物的集合的交集。
5.2. 枚舉類 oneOf [OWL DL]
OWL提供了一種通過直接枚舉類的成員的方法來描述類。這是通過使用oneOf結構來完成。特別地，這個定義完整地描述了類的外延，因此任何其他個體都不能被聲明爲屬於這個類。
下面的例子定義了WineColor類，它的成員是White,Rose和Red這三個個體.
<owl:Class rdf:ID="WineColor"> <rdfs:subClassOf rdf:resource="#WineDescriptor"/> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#White"/> <owl:Thing rdf:about="#Rose"/> <owl:Thing rdf:about="#Red"/> </owl:oneOf> </owl:Class> 看到上面的定義，第一件想到的事情就是由於這個類是通過枚舉定義的，因此其他任何個體都不可能是一個有效的WineColor。
oneOf結構的每一個元素都必須是一個有效聲明的個體。一個個體必須屬於某個類。在上面的例子中，每一個個體都是通過名字來引用的。我們使用owl:Thing簡單地進行引用，儘管這有點多餘（因爲每個個體都屬於owl:Thing）。另外，我們也可以根據具體類型WineColor來引用集合中的元素：
<owl:Class rdf:ID="WineColor"> <rdfs:subClassOf rdf:resource="#WineDescriptor"/> <owl:oneOf rdf:parseType="Collection"> <WineColor rdf:about="#White" /> <WineColor rdf:about="#Rose" /> <WineColor rdf:about="#Red" /> </owl:oneOf> </owl:Class> 另外，較複雜的個體描述同樣也可以是oneOf結構的有效元素，例如:
<WineColor rdf:about="#White">
<rdfs:label>White</rdfs:label>
</WineColor>
其它關於oneOf使用的例子，請參見 Reference.
5.3. 不相交類 disjointWith [OWL DL]
使用owl:disjointWith構造子可以表達一組類是不相交的。它保證了屬於某一個類的個體不能同時又是另一個指定類的實例。
<owl:Class rdf:ID="Pasta">
<rdfs:subClassOf rdf:resource="#EdibleThing"/>
<owl:disjointWith rdf:resource="#Meat"/>
<owl:disjointWith rdf:resource="#Fowl"/>
<owl:disjointWith rdf:resource="#Seafood"/>
<owl:disjointWith rdf:resource="#Dessert"/>
<owl:disjointWith rdf:resource="#Fruit"/>
</owl:Class>
Pasta例子聲明瞭多個不相交類。注意它只聲明瞭Pasta與其它所有類是不相交的。例如，它並沒有保證Meat和Fruit是不相交的。爲了聲明一組類是互不相交的，我們必須對每兩個類都使用owl:disjointWith來聲明。
一個常見的需求是定義一個類爲一組互不相交的子類的聯合（union）。
<owl:Class rdf:ID="SweetFruit">
<rdfs:subClassOf rdf:resource="#EdibleThing" />
</owl:Class>
<owl:Class rdf:ID="NonSweetFruit">
<rdfs:subClassOf rdf:resource="#EdibleThing" />
<owl:disjointWith rdf:resource="#SweetFruit" />
</owl:Class>
<owl:Class rdf:ID="Fruit">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#SweetFruit" />
<owl:Class rdf:about="#NonSweetFruit" />
</owl:unionOf>
</owl:Class>
在上面個例子中，我們定義了Fruit是SweetFruit和NonSweetFruit的並集。而且我們知道這些子類恰好將Fruit劃分成了連個截然不同的子類，因爲它們是互不相交的。隨着互不相交的類的增加，不相交的聲明的數目也會相應的增加到n2.然而，在我們已知的用例中，n通常比較小。
當n很大時，我們可以使用另一些方法以避免聲明的數目按二次方增長。其中一個方法在OWL test suite 有詳細說明。
這一方法的工作原理如下。我們描述一個父類，它的元素有一個基數等於一的屬性。接着，對於這個父類的每一個子類，我們都要求這個子類的實例的這一屬性必須具有一個唯一的值。在這種情況下，各個不同子類就不可能有共同的成員了。
6. 本體的版本控制
本體和軟件一樣需要維護，因此它們將隨着時間的推移而改變。在一個owl:Ontology元素（如上面討論的）內，鏈接到一個以前定義的本體版本是可能的。屬性owl:priorVersion被用來提供這種鏈接，並能用它跟蹤一個本體的版本歷史。
<owl:Ontology rdf:about=""> ... <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine"/> ... </owl:Ontology> 在上面例子中被指出的那個本體是被定義本體的一個以前版本。
本體版本可能彼此互不兼容，例如，一個本體以前的版本可能包含與現在版本中的陳述相矛盾的陳述。在一個owl:Ontology元素中，我們使用owl:backwardCompatibleWith和owl:incompatibleWith這些屬性來指出本體版本是兼容還是不兼容以前的版本。如果沒有進行owl:backwardCompatibleWith聲明，那麼我們假定就不存在兼容性。除了上面講到的兩個屬性，還有一個屬性owl:versionInfo適用與版本控制系統，它提供了一些相關信息（hook）。和前面三個屬性相反的是，owl:versionInfo的客體是一個文字值（literal），這一屬性除了可以用來註釋本體之外還可以用來註釋類和屬性。
在許多時候，僅僅在整個本體的粒度上提供版本跟蹤是不夠的。維護人員可能希望能夠記錄類、屬性、個體的版本信息——即使這些信息可能還是是不夠充分。在OWL中，類表示的漸增性本質意味着了一個本體可以爲一個在另一個本體中定義的（具名）類添加約束，而這些額外的約束本身可能需要版本信息。
OWL Full提供的表示能力能夠對一個類進行任何類型的聲明，也即可以聲明一個類可以是另一個類的實例，或者一個類（不是它的實例）有一個屬性和一個對應的屬性值。這一框架就能被用來爲版本跟蹤信息建立一個由類和屬性構成的本體。OWL的名稱間中包括了兩個預定義的類owl:DeprecatedClass和owl:DeprecatedProperty來完成這個目的。他們被用來指明某個類或屬性在未來發布的版本中可能以一種不兼容的方式發生變化。
...
<owl:DeprecatedClass rdf:ID="&vin;JugWine" />
<owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
...
我們要注意到owl:DeprecatedClass及owl:DeprecatedProperty並沒有附加的語義，這很重要。它們應由工具開發者和OWL使用者來確保這些屬性是按其本意使用的。
7. 使用範例
一旦有某個初始的領域本體可以利用，人們就能夠使用這個本體開發大量的應用。在本節中，我們會描述使用在葡萄酒領域的一些例子。
7.1.葡萄酒門戶網站
現今有許多站點稱自己是葡萄酒的門戶網站。比如在Google上就可以找到152,000個與“wine portal”（葡萄酒門戶網站）相匹配的結果。最匹配的是一個稱爲"Wine-Portal.com"的站點，該站點提供了問其他許多站點的途徑。聲稱自己是葡萄酒門戶網站的站點大多是信息式站點（informational sites）。例如，wine-portal.com中的第一個特色站點被稱爲“酒塞烹飪”（cork cuisine），這一站點就是提供關於葡萄酒和食物的搭配、關於以葡萄酒作爲禮物等方面的信息的。
細讀任何一個範圍的主題，人們都會發現大量與該主題相關的內容，它們包含了與該主題相關的信息或者服務。像“附屬品和禮物”（accessories and gifts）這個主題中就包含了關於購買特別的葡萄酒物品（wine item）時的注意事項的信息，同時也包含了衆多的在線零售商的信息。另一個頂層的主題範圍“購物”中包含了一個子範圍“葡萄酒購買”（wine shopping），從這兒用戶能夠找到在線（或者“街道購物”（stree shopping））商店（按照國家分類）。這兩個站點僅僅是現在許多例子中的兩個，它們代表了這些門戶網站的一般概念，也即葡萄酒門戶爲某個特定主題範圍提供了大量的信息和服務。
即使在更細節的程度上考察這些站點，我們也無法得知現在它們在多大程度上依賴着本體。例如，我們從html的源代碼中並無法找出它們使用本體的證據。然而，非常明顯的，這些站點是有可能使用本體的並可以從中得到一些葡萄酒本體。
在門戶網站中，本體的一個簡單使用就是利用其進行組織和瀏覽。上面的類別列表就可能從葡萄酒的類別層次的最高几層生成。查詢能夠使用葡萄酒本體對與葡萄酒相關的信息進行檢索。如果某人對本體中包含的術語進行搜索，查詢就可能根據子類的信息進行擴展從而找到更多相關的答案。門戶網站也可能使用（候選的）相關主題範圍內的信息進行自我更新。使用強大的推理能力，它們甚至能夠識別出可能的葡萄酒銷售站點並通過協商將這些站點包含爲門戶網站的一部分。
7.2. 葡萄酒主體（agent）
爲了說明的目的，我們啓動了一個葡萄酒主體（wine agent）項目。按照我們最初的設計，葡萄酒主體的目標是爲飲宴上的菜推薦合適品種的葡萄酒。該應用使用的本體就是作爲本指南基礎的這一葡萄酒本體。這一葡萄酒本體可以在DAML本體庫中得到，名爲wines.
一個個性化的葡萄酒主體能爲人們夠提供大量的服務。
主體能夠根據給定的許多約束條件（例如要提供的餐宴）推薦合適的葡萄酒，能夠找到關於某種特定的葡萄酒或者某種特定的葡萄酒的類別的信息，它還能夠爲一種葡萄酒找出合適的附屬品（例如爲某個品種的葡萄酒找到合適的特定種類的杯子等）。
接下來，我們用一個簡單的原型系統來描述一個例子，該系統是作爲一個學生作業項目來完成的。
考慮下面的情景：
某人正在籌劃一個晚宴，其中至少有一個客人對酒瞭解甚深。主人希望能夠使用與菜單上的菜餚最合適的酒來招待客人。主人也希望自己能夠對晚宴的用酒顯得學識淵博。並且，主人決定在晚宴上使用一種用番茄做成的意大利麪條醬和新鮮的意大利麪條作爲主菜來招待客人。
爲了能夠提供與餐宴合適的葡萄酒，主人需要葡萄酒酒和食物搭配方面的知識。爲了顯得對葡萄酒有相當的瞭解，主人需要獲得關於宴會用酒的有關信息。爲了配上合適的附屬品，主人還需要有關在該情況下（以及在主人認可價格範圍內）的附屬品的信息。
通過一個相關背景的葡萄酒本體，根據對餐宴的一定的描述，葡萄酒主體能夠給出適合該餐宴的酒的類型的建議。葡萄酒主體可能會建議使用馨芳葡萄酒（Zinfandel）作爲這次宴會的用酒類型。除此之外，通過相關背景的本體，葡萄酒主體可以給出建議使用某種特定的馨芳葡萄酒，比如瑪麗埃塔馨芳葡萄酒（Marietta Zinfandel)。如果給定了用酒是馨芳葡萄酒的話，葡萄酒主體可能會去某個地點進行搜尋，它可能得到的是一系列的馨芳葡萄酒，也可能得到某種特定的馨芳葡萄酒，例如瑪麗埃塔馨芳葡萄酒。如果本體中包含了購買葡萄酒的合適地點的信息（可能根據主人所在地以及葡萄酒銷售商所在地信息進行了過濾），葡萄酒主體就可能訪問一個站點如wine.com，在站點內搜索‘馨芳葡萄酒’並返回那個站點所銷售的馨芳葡萄酒的列表。葡萄酒主體也可能從釀酒廠或者其他零售商處嘗試尋找瑪麗埃塔馨芳葡萄酒。例如，它可能發現（通過在Google進行搜索或者在某些選定站點上進行結構化的查詢）在winelibrary.com上有1999年製造的瑪麗埃塔馨芳葡萄酒正以13.99美元的折扣價進行銷售。葡萄酒主體就可能使用附加的過濾信息進行過濾，這些過濾信息可能是由消費者提供的價格範圍或者是對於不同品種的建議等。
葡萄酒主體現在就可能嘗試要提供關於馨芳葡萄酒的通用信息或者瑪麗埃塔馨芳葡萄酒的特定信息。它可能使用一個具有葡萄酒站點背景的本體來尋找關於特定的葡萄酒的信息。例如，它可能用到釀酒廠對它們最新的馨芳葡萄酒的描述這樣的其他相關信息源的額外的評論也可能被用上。如果在某個最受歡迎的站點上沒有關於瑪麗埃塔馨芳葡萄酒的相關評論，在相同的地方找一些關於馨芳葡萄酒的評論可能也是有用的，比如在這裏就可以找一些關於加利福尼亞Sonoma郡的馨芳葡萄酒的評論。
通用的背景信息可能也會使用到。主人可能需要做一些相關的閱讀，他也可能對普通酒或者是馨芳葡萄酒的書籍感興趣。例如，主人可能對Amazon.com上銷售的馨芳葡萄酒的書籍感興趣。主人也可能對相同地區的葡萄酒相關的信息感興趣，這裏可能就是Sonoma郡的馨芳葡萄酒。葡萄酒主體一般僅能得到它的主要知識領域相關的背景信息。比如，這個葡萄酒主體是關於食物和酒的匹配方面的，所以它可能通過免費的或者付費購買的方式得到的這一主題的信息，例如像評酒者上的關於搭配食物和酒的文章。
宴會的主人可能還要購買一些對於宴會活動來說很重要的酒的附屬品。酒是使用酒杯作爲容器的，而不同品種的酒最好使用不同種類的酒杯來裝。例如，如果主人選擇了一道菜是適合用馨芳葡萄酒來配的，主人可能就需要知道Riedel是一個知名的酒器生產商。主人可能還希望能夠鏈接到Wine Enthusiast（一個相當受敬重的葡萄酒商品供應商）並告訴他Wine Enthusiast有一種Riedel生產的馨芳葡萄酒酒杯正在以63.95美元的價格四個一組地進行銷售（如果你買兩組四個的杯子的話就可以得到59.95美元一組的折扣價）。主人可能還有興趣瞭解在Amazon.com上通過49.99美元(and claims a list price of $65.00)就可以購買得到的Reidel生產的Sommelier 馨芳葡萄酒單把杯（Reidel's Sommelier Zinfandel single stem glass）。Amazon上面也有相同的6個一組的馨芳葡萄酒酒杯銷售（而不像Wine Enthusiast上的4個一組），銷售價是79.99美元（and claims a list price of $119.40)。葡萄酒主體能提供一個與餐宴搭配的（也即，與招待用的馨芳葡萄酒搭配的）酒器的列表給主人，然後進行價格的比較或者根據由本體中的一個屬性列表中選出的其他標準來進行比較。
主人可能還要考慮其他的酒的附屬品。從本體中我們可以瞭解到啓瓶器是屬於酒的附屬品。背景本體可能已經對啓瓶器的子類進行了編碼或者這些信息可以通過相關的葡萄酒站點獲得。Wine Enthusiast就有一系列它們推薦的（其中有關於啓瓶器的類型和價格範圍的描述）[1]。它們也根據啓瓶器的不同類型（槓桿型、服務員型、固定型、旋轉型、抽吸型）進行區分，而主人可能想要得到關於這些不同類型的啓瓶器的信息。
根據不同領域的背景本體知識和不同的信息以及不同的服務站點，葡萄酒主體可能應用到不同複雜程度的情況中去。在本例中，我們僅僅考慮了關於酒、品種類型、食物和酒的組合、某些酒的附屬品和它們相關屬性的一些信息。當然，我們能夠根據顧客要求將本例擴展以包含更多的信息和更多的約束。
葡萄酒主體的例子還在不斷完善中，從這裏我們可以得到它。
