Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.certifiedchinesetranslation.com/openaccess/owlguide-tc.html below:

OWL Web Ontology Language Guide

譯文：

OWL Web本體語言 指南
http://www.certifiedchinesetranslation.com/openaccess/owlguide-tc.html

原文：

OWL Web Ontology Language Guide

(http://www.w3.org/TR/2004/REC-owl-guide-20040210/ ）

注意：

• 本文檔的英文版爲唯一正式版本
• 本文檔爲繁體中文翻譯版，譯者儘量與原著保持一致，錯誤和不妥之處歡迎指正
• 著作權聲明：http://www.w3.org/Consortium/Legal/copyright-documents.html
• 本文檔是根據發佈的W3CHINA.ORG中文繁體翻譯進行格式修改的。原中文繁體翻譯位于 http://zh.transwiki.org/cn/owlguide.htm
• 原譯者(Translators)
  劉升平（Shengping Liu）翻譯活動主席 lsp<at>w3china.org：翻譯目錄、第1節和附錄A、附錄C，並負責工作組的組織與翻譯工作的統籌。
  倪躍（Yue Ni）,nybon<at>163.com ：翻譯3.3-3.4節和第7節。
  徐涵（Collin Hsu），collin<at>w3china.org：翻譯第2.1-2.3節、第3.1-3.2節和附錄B。
  sprag, spragsina.com：翻譯第5節。
  zephyr, gzq03mails.tsinghua.edu.cn：翻譯第4節。
  icecream199612, fenglp1996163.com：翻譯第6節。
  jumbo, jumboemilymsn.com：翻譯第2節引言部分。
   

格式修改：

Chinese Translation Services (Samuel Chong)

格式修改時間：

初次定稿 2009-08-23

當前版本:

http://www.w3.org/TR/2004/REC-owl-guide-20040210/

最新版本:

http://www.w3.org/TR/owl-guide/

上一版本:

http://www.w3.org/TR/2003/PR-owl-guide-20031215/

編者:

Michael K. Smith, Electronic Data Systems, 
Chris Welty, IBM Research, 
Deborah L. McGuinness, Stanford University, 

請參考本文的 勘誤表 那裏會有一些規範性的修正.

也可以查看 相關翻譯.

Copyright © 2004 W3C^® (MIT, ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

目前這種結構的萬維網，很像一本地圖做得很差的地理書，我們對於Web中可以使用的文檔和服務的瞭解，都是基於關鍵字搜索的， 同時還需要靈活地使用文檔的鏈結和使用模式。如果沒有強有力的工具的支援，這麽大規模的資料是很難管理的，爲了能夠給Web繪製出更爲詳實的地圖，計算代理需要對於網路上可用資源的內容和能力做一個機器能夠讀得懂的描述。這些描述是人類能夠讀得懂的資訊的擴展。

OWL，這種本體描述語言，可以用來描述Web文檔和應用中內在的類和關係。

這篇文章解釋了OWL語言的使用：

1. 通過定義類以及類的屬性來形式化某個領域；
2. 定義個體並說明它們之間的屬性；
3. 在OWL語言的形式化語義允許的層次上，對類和個體進行推理。

本文的各章節間是按照類、屬性、個體的集合的定義給出來的，從最簡單的概念開始，逐漸過渡到更爲複雜的概念。

• 摘要
• 本文檔狀態
• 內容
• 1. 引言
  • 1.1. OWL的種類
  • 1.2. 本文檔的結構
• 2. 本體的結構  
  • 2.1. 命名空間 
  • 2.2. 本體頭資訊
  • 2.3. 資料聚合和隱私
• 3. 基本元素  
  • 3.1. 簡單類和個體  
    • 3.1.1. 簡單具名類
    • 3.1.2. 個體
    • 3.1.3. 使用時的設計
  • 3.2. 簡單屬性 
    • 3.2.1. 定義屬性
    • 3.2.2. 屬性和資料類型
    • 3.2.3. 個體的屬性
  • 3.3. 屬性的特徵
    • 3.3.1. 傳遞屬性
    • 3.3.2. 對稱屬性
    • 3.3.3. 函數型屬性
    • 3.3.4. 逆屬性
    • 3.3.5. 反函數型屬性
  • 3.4. 屬性約束
    • 3.4.1. allValuesFrom, someValuesFrom
    • 3.4.2. Cardinality
    • 3.4.3. hasValue
• 4. 本體映射
  • 4.1. 類之間和屬性之間的等價性
  • 4.2. 個體之間的等同性
  • 4.3. 不同的個體
• 5. 複雜類
  • 5.1. 集合操作
  • 5.2. 枚舉類
  • 5.3. 不相交類
• 6. 本體版本
• 7. 使用舉例
  • 7.1. 關於酒的門戶網站
  • 7.2. 關於酒的主體（Agent）
• 致謝
• OWL辭彙表
• 術語索引和交叉引用
• 參考文獻
• 附錄A: XML + RDF基礎
• 附錄B: 歷史
• 附錄C: 上次發佈以來的修改日誌

“告訴我我應該買什麽酒提供給下列功能表的每道菜，隨便說一下，我不喜歡蘇特恩白葡萄酒”。

目前構造一個能夠查找滿足這個查詢的酒的Web代理會是困難的。類似地，考慮派給軟體代理一個做出合理的旅行安排的任務（更多的用例, OWL 需求文檔.)

爲了支援這種計算，不僅僅用關鍵字而是說明Web上描述的資源的含義是必要的。這個額外的解釋層表述了資料的“語義”。

Web本體語言OWL是一種定義和實例化“Web本體”的語言。“本體”這個術語來自於哲學，它是研究世界上的各種實體以及他們是怎麽關聯的科學。一個“Web本體”可能包含了類，屬性和他們的實例的描述。給出這樣的一個本體， OWL 形式語義 說明怎麽獲得它的邏輯結論，也就是說，不是逐字寫在本體中的事實，而是語義蘊涵的事實。這些蘊涵可以是基於單個的文檔也或利用OWL機制 合併在一起的多個分佈的文檔。

本文檔是W3CWeb本體工作組（WebOnt）制定的Web本體語言的描述的一部分。 OWL綜述 ([Overview], 1.1) 的文檔指南 部分描述了不同部分的文檔以及他們怎樣結合的。

當描述另外一個XML/Web標準時，有一個問題會冒出來：這個標準給了我什麽XML和XML Schema不能給的。這個問題有兩個答案。

• 本體和XML Schema的區別是它是一種知識表示，而不是一種消息格式。大多數來自工業界的Web標準包含了一個消息格式和協定規範的組合。這些格式已經被給予一個操作語義，例如，"一旦收到訂單（PurchaseOrder）的消息，從AccountFrom賬號轉移Amount數量的美元到AccountTo賬號，並且發貨(Product)"，但是這些規範並沒有設計爲支援此事務上下文之外的推理。例如，一般來說，沒有機制讓我們推出：因爲這個産品的類型是夏敦埃酒（Chardonnay，一種無甜味白葡萄酒），它必定也是一種白色酒。
• OWL本體的一個優點是會有能夠對其做推理的工具。這些工具提供了不特定於某個主題領域的通用支援，而如果要構建一個能對一個特定的工業界標準XML Schema做推理的系統，它往往是特定於一個領域的。構建一個可靠的和有用的推理系統不是一項簡單的工作。而創建一個本體則更爲容易處理。我們的期望就是很多團體會著手本體創建。他們會得益於基於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]"。

I爲了在這個指南中提供一個一致的例子，我們創建了一個關於 酒 和食物 的本體。它是一個OWL DL本體。我們有些討論會集中於OWL Full的表達能力，因此會標注出來。這個酒和食物本體是對歷史悠久的DAML本體庫中的一個元素 的重大修改而成的。它最初由McGuinness作爲一個描述邏輯CLASSIC的 例子開發的，後來擴充爲一個描述邏輯教程 和一個本體 教程.

在這個文檔中，我們假設大部分讀者熟悉XML，因此用 RDF/XML 語法表示例子 ([RDF], 5). 標準的OWL交換語法是RDF/XML。注意OWL在設計時保持了與RDF和RDF Schema的最大相容性。這些XML和RDF格式是OWL標準的一部分。

本文檔中引進的所有例子都是從本體wine wine.rdf and food.rdf,中摘取的，除了那些在右下角用 ? 標注的。

OWL是 語義網 活動的一個組成部分。這項工作的目的是通過對增加關於那些描述或提供網路內容的資源的資訊，從而使網路資源能夠更容易地被那些自動進程訪問。由於語義網路固有的分佈性，OWL必須允許資訊能夠從分佈的資訊源收集起來。其中，允許本體間相互聯繫，包括明確導入其他本體的資訊，能夠部分實現這樣的功能。
 

另外，OWL提出了一個開放世界的假設。也就是說，對資源的描述並不局限於在一個簡單的文件或範圍內。類C1本來是由本體O1定義出來的，然而，它也可以是由其他的本體擴展出來的。對C1進行這樣的假設的結果是單調的。新的資訊不能否定之前的資訊。新的資訊可以是和舊的資訊矛盾的，但是事實和推導只能被增加而不能被刪減。

當設計一個本體的時候，設計者必須考慮到這種矛盾的可能性。一種期望是，工具的支援將幫助偵測到這樣的情況。
 

爲了能寫出一個能被唯一翻譯的而且能被軟體（代理）使用的本體，我們要求OWL有一個語法和正規的語義。OWL是RDF的一個辭彙擴充 [RDF 語義] (http://www.w3.org/TR/rdf-mt/)]。 在OWL 網路本體語言語義和簡明語法 中，有OWL的語義定義。

在我們使用一組術語之前，我們需要一個精確地指出哪些具體的辭彙表將被用到。一個標準的本體開頭部分裏包括一組 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#"> 

建立了命名空間後，接下來我們通常要在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提供了若干其他的機制來將當前本體與被導入本體相關聯 (see 本題映射部分).

我們也可以用rdfs:label來對本體進行自然語言標注。

本體頭部定義在下列標簽處結束：

 
</owl:Ontology>

在這段開頭之後跟隨的是構成本體的實際定義，最終由

 
</rdf:RDF>

終止。

OWL在表達出現在多個文檔中的實例資訊的能力方面，支援連接來自異源的資料。下層語義爲這些資料提供推理支援，這可以産生意外的結果。特別地，owl:sameAs的表達等價的能力，可被用來表達表面上不同的個體實際上是相同的。Owl:InverseFunctionalProperty也可被用來連接個體。例如，如果一個屬性，比如“SocialSecurityNumber”，是一個owl:InverseFunctionalProperty，那麽兩個分開的個體如果具有相同的SocialSecurityNumber屬性，則可被推理出是相同的個體。當個體被這樣確定爲相同時，來自異源的關於這些個體的資訊可以被合併。這種聚合可被用來得出不可直接從單源獲得的事實。

語義網的連接來自多源的資訊的能力是一個理想的、強大的特性，它可被用在許多 應用中。但是合併來自多源資料的能力，加上OWL的推理能力，確實存在被誤用的可能。OWL用戶應對潛在的隱私問題予以警惕。具體的安全方案超出了工作組的工作範疇。一些組織正在用各種不同的安全和偏好方案來處理這些問題，比如 SAML 和P3P.

一個OWL本體中的大部分元素是與類（class）、屬性（property）[譯注//這裏的property也可譯作“特性”]、類的實例（instance）以及這些實例間的關係有關的。本節給出應用這些元素所必需的語言成分。

許多情況下，使用本體是爲了用它進行關於個體的推理。爲了在一種有效的方式下做到這一點，我們需要一種機制來描述個體所屬的類以及這些個體通過類成員關係而繼承得到的屬性。儘管我們總能爲個體聲明特定的屬性，但是本體的大部分能力在於基於類的推理。
 

有時，我們希望強調區分一個類是作爲物件還是作爲包含元素的集合。我們稱由屬於某個類的個體所構成的集合爲該類的外延（extension）。

Class, rdfs:subClassOf

一個領域中的最基本概念應分別對應於各個分類層次樹的根。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 屬性 ([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（標號）就像一個注釋，不向本體的邏輯解釋添加任何內容。

葡萄酒的定義仍然是不完整的。我們除了知道葡萄酒是一種事物並且適於飲用以外，對它別無所知。但我們有足夠的資訊來創建個體和對個體進行推理。
 

除了描述類，我們還希望能夠描述類的成員。我們通常認爲類的成員是我們所關心的範疇中的一個個體（而不是另一個類或屬性）。要引入一個個體（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是一個個體，因爲它代表的是某個單個葡萄品種。

關於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等）同時作爲類來看待。
.

如果僅允許定義層次分類，那麽這個類和個體的世界也許會變得頗爲無趣。屬性（propertyies）使得我們可以斷言關於類成員的一般事實以及關於個體的具體事實。

一個屬性是一個二元關係。有兩種類型的屬性：

• 資料類型屬性（datatype properties），類實例與RDF文字或XML Schema資料類型間的關係。
• 或XML Schema資料類型間的關係。
  物件屬性（object properties），兩個類的實例間的關係。注意：物件屬性這個名稱並不是要反映與 RDF 術語rdf:object ([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關聯到它們的生産年份。

根據是將個體關聯到個體、還是將個體關聯到資料類型，我們可以區分兩類屬性：前者稱爲物件屬性（object properties）；後者稱爲資料類型屬性（datatype properties）。資料類型屬性的值域範圍是RDF文字或者是 XML Schema 資料類型中定義的那些簡單類型（simple types）。
 

OWL使用XML Schema內嵌資料類型中的大部分。對這些資料類型的引用是通過對http://www.w3.org/2001/XMLSchema 這個URI引用進行的。下列資料類型是推薦在OWL中使用的：

上面的資料類型，連同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 ([Reference], 6.2) 描述了owl:oneOf的使用、以及用rdf:List和rdf:rest來定義一個枚舉資料類型，那裏有個例子展示了如何構建一個值域爲整數值列表{0, 15, 30, 40}的資料類型屬性tennisGameScore。
 

首先，我們描述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> 

接下來的幾節描述了用以進一步說明屬性的機制。我們可以對屬性的特性進行詳細的說明，這就提供了一種強有力的機制以增強對於一個屬性的推理。
 

如果一個屬性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是傳遞屬性。
 

如果一個屬性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, 和z:

 
P(x,y) 與P(x,z) 蘊含 y = z

在我們的葡萄酒本體中，hasVintageYear屬性是函數型屬性。一種葡萄酒有著一個特定的製造年份。也即，一個給定的Vintage個體只能使用hasVintageYear屬性與單獨一個年份相關聯。owl:FunctionalProperty並不要求該屬性的定義域的所有元素都有值。請參見關於 基數的討論.

 
<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>

如果一個屬性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）。而每個釀酒廠生産的酒均以該釀酒廠爲製造商。

如果一個屬性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屬性。

除了能夠指定屬性特性，我們還能夠使用多種方法進一步在一個明確的上下文中限制屬性的值域。這是通過“屬性限制”來完成的。下面描述的多種形式僅在owl:Restriction的上下文中才能使用。owl:onProperty元素指出了受限制的屬性。

我們已經發現了一種限制組成屬性的元素的類型的方法。到現在爲止，我們所講述的機制都是全局的（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>                                             ¬  

這兩種限制形式間的不同就是全稱量詞與存在量詞間的不同。

前者並不要求一種葡萄酒一定要有一個製造商。如果它確實有一個或多個製造商，那麽這些製造商必須全部都是釀酒廠。後者要求至少有一個製造商是釀酒廠，但是可以存在不是釀酒廠的製造商。

在前面我們已經看到過關於基數約束的例子了。到目前爲止的例子中，這些約束都是關於最小基數的所作出的斷言。更爲直接的方法是使用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能夠用來指定一個下界。使用二者的組合就能夠將一個屬性的基數限制爲一個數值區間。
 

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屬性作出限制。

爲了讓本體發揮最大的作用，就需要讓本體得到充分的共用。爲了使得在開發本體時盡可能的節省人力，就需要使得開發出的本體能夠被重用。更理想的情況是他們能夠被組合使用。例如，你可能同時使用來自某一來源的日期本體(date ontology)和來自另一來源的物理位置本體(physical location ontology),並將位置(location)的概念加以擴展以包括這個位置所處在的時間段。
 

在開發一個本體的過程中，很多的精力都被投入到將類與屬性聯繫起來以獲取最大的意義的工作上去了,意識到這一點也是很重要的。我們希望對類成員作出的斷言較爲簡單同時又要求有廣泛的和有用的含意在裏面。這也是在本體開發過程中最爲困難的工作。如果你能夠找到已經經過廣泛使用和精煉的本體，那麽採用它才有意義。
 

多個本體的合併工作是非常具有挑戰性的。爲了維護其一致性,幾乎必然需要工具的支援。
 

當我們要把一些本體組合在一起作爲另一個新的本體的一部分時，能說明在一個本體中的某個類或者屬性與另一個本體中的某個類或者屬性是等價的，這往往很有用。在實際應用中我們這樣做的時候要千萬小心。因爲如果要組合的那些本體是互相矛盾的（所有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類。
 

類似的，我們可以通過使用owl:equivalentProperty屬性聲明表達屬性的等同。

sameAs

描述個體之間相同的機制與描述類之間的相同的機制類似，僅僅只要將兩個個體聲明成一致的就可以了。

例如這樣一個例子：

 
<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可以用來引用兩個東西，如一個類和一個個體、一個類和一個屬性等等，無論什麽情況，都將被解釋爲個體。

這一機制提供了與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構造，可以實現一些其他的方法來完成這一擴展。

OWL另外還提供了一些用於構建類的構造子。這些構造子被用於創建所謂的類運算式。OWL支援基本的集合操作，即並，交和補運算。它們分別被命名爲owl:unionOf,owl:intersectionOf,和owl:complementOf.此外，類還可以是枚舉的。類的外延可以使用oneOf構造子來顯示的聲明。同時，我們也可以聲明類的外延必須是互不相交的。

注意類運算式是可以嵌套的，它並不要求要爲每一個中間類都提供一個名字。這樣就允許我們通過使用集合操作來從匿名類或具有值約束的類來創建複合類。

記住:OWL類外延是由個體組成的集合，而這些個體都是類的成員。OWL使用基本的集合操作運算元來處理類的外延。
 

下面的例子展示了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類的外延的一部分。

下面的例子展示了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的交集的子集,這裏我們將預計得到一個空集。

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類與所有不位於法國的事物的集合的交集。

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.

使用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 有詳細說明。

這一方法的工作原理如下。我們描述一個父類，它的元素有一個基數等於一的屬性。接著，對於這個父類的每一個子類，我們都要求這個子類的實例的這一屬性必須具有一個唯一的值。在這種情況下，各個不同子類就不可能有共同的成員了。

本體和軟體一樣需要維護，因此它們將隨著時間的推移而改變。在一個owl:Ontology元素（如上面討論的http://www.w3.org/TR/2004/REC-owl-guide-20040210/#OntologyHeaders） 內，鏈結到一個以前定義的本體版本是可能的。屬性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使用者來確保這些屬性是按其本意使用的。
 

Once an initial domain ontology is available, a 一旦有某個初始的領域本體可以利用，人們就能夠使用這個本體開發大量的應用。在本節中，我們會描述使用在葡萄酒領域的一些例子。
 

現今有許多站點稱自己是葡萄酒的門戶網站。比如在Google上就可以找到152,000個與“wine portal”（葡萄酒門戶網站）相匹配的結果。最匹配的是一個稱爲 "Wine-Portal.com", 的站點，該站點提供了問其他許多站點的途徑。聲稱自己是葡萄酒門戶網站的站點大多是資訊式站點（informational sites）。例如，wine-portal.com中的第一個特色站點被稱爲“酒塞烹飪”（cork cuisine) (www.corkcuisine.com/), 這一站點就是提供關於葡萄酒和食物的搭配、關於以葡萄酒作爲禮物等方面的資訊的。

細讀任何一個範圍的主題，人們都會發現大量與該主題相關的內容，它們包含了與該主題相關的資訊或者服務。像“附屬品和禮物”（accessories and gifts）這個主題中就包含了關於購買特別的葡萄酒物品（wine item）時的注意事項的資訊，同時也包含了衆多的在線零售商的資訊。另一個頂層的主題範圍“購物”中包含了一個子範圍“葡萄酒購買”（wine shopping），從這兒用戶能夠找到在線（或者“街道購物”（stree shopping））商店（按照國家分類）。這兩個站點僅僅是現在許多例子中的兩個，它們代表了這些門戶網站的一般概念，也即葡萄酒門戶爲某個特定主題範圍提供了大量的資訊和服務。
 

即使在更細節的程度上考察這些站點，我們也無法得知現在它們在多大程度上依賴著本體。例如，我們從html的源代碼中並無法找出它們使用本體的證據。然而，非常明顯的，這些站點是有可能使用本體的並可以從中得到一些葡萄酒本體。

在門戶網站中，本體的一個簡單使用就是利用其進行組織和瀏覽。上面的類別列表就可能從葡萄酒的類別層次的最高幾層生成。查詢能夠使用葡萄酒本體對與葡萄酒相關的資訊進行檢索。如果某人對本體中包含的術語進行搜索，查詢就可能根據子類的資訊進行擴展從而找到更多相關的答案。門戶網站也可能使用（候選的）相關主題範圍內的資訊進行自我更新。使用強大的推理能力，它們甚至能夠識別出可能的葡萄酒銷售站點並通過協商將這些站點包含爲門戶網站的一部分。

爲了說明的目的，我們啓動了一個 葡萄酒主體（wine agent）專案。按照我們最初的設計，葡萄酒主體的目標是爲飲宴上的菜推薦合適品種的葡萄酒。該應用使用的本體就是作爲本指南基礎的這一葡萄酒本體。這一葡萄酒本體可以在DAML本體庫中得到，名爲wines.

一個個性化的葡萄酒主體能爲人們夠提供大量的服務。

主體能夠根據給定的許多約束條件（例如要提供的餐宴）推薦合適的葡萄酒，能夠找到關於某種特定的葡萄酒或者某種特定的葡萄酒的類別的資訊，它還能夠爲一種葡萄酒找出合適的附屬品（例如爲某個品種的葡萄酒找到合適的特定種類的杯子等）。

接下來，我們用一個簡單的原型系統來描述一個例子，該系統是作爲一個學生作業專案來完成的。

考慮下面的情景：

某人正在籌劃一個晚宴，其中至少有一個客人對酒瞭解甚深。主人希望能夠使用與功能表上的菜肴最合適的酒來招待客人。主人也希望自己能夠對晚宴的用酒顯得學識淵博。並且，主人決定在晚宴上使用一種用番茄做成的義大利麵條醬和新鮮的義大利麵條作爲主菜來招待客人。

爲了能夠提供與餐宴合適的葡萄酒，主人需要葡萄酒酒和食物搭配方面的知識。爲了顯得對葡萄酒有相當的瞭解，主人需要獲得關於宴會用酒的有關資訊。爲了配上合適的附屬品，主人還需要有關在該情況下（以及在主人認可價格範圍內）的附屬品的資訊。

通過一個相關背景的葡萄酒本體，根據對餐宴的一定的描述，葡萄酒主體能夠給出適合該餐宴的酒的類型的建議。葡萄酒主體可能會建議使用馨芳葡萄酒（Zinfandel）作爲這次宴會的用酒類型。除此之外，通過相關背景的本體，葡萄酒主體可以給出建議使用某種特定的馨芳葡萄酒，比如瑪麗埃塔馨芳葡萄酒（Marietta Zinfandel)。如果給定了用酒是馨芳葡萄酒的話，葡萄酒主體可能會去某個地點進行搜尋，它可能得到的是一系列的馨芳葡萄酒，也可能得到某種特定的馨芳葡萄酒，例如瑪麗埃塔馨芳葡萄酒。如果本體中包含了購買葡萄酒的合適地點的資訊（可能根據主人所在地以及葡萄酒銷售商所在地資訊進行了過濾），葡萄酒主體就可能訪問一個站點如 wine.com 在站點內搜索‘馨芳葡萄酒’並返回那個站點所銷售的馨芳葡萄酒的列表。葡萄酒主體也可能從釀酒廠或者其他零售商處嘗試尋找 瑪麗埃塔 馨芳 葡萄酒。例如，它可能發現（通過在Google進行搜索或者在某些選定站點上進行結構化的查詢）在winelibrary.com上有1999年製造的瑪麗埃塔馨芳葡萄酒正以13.99美元的折扣價進行銷售。葡萄酒主體就可能使用附加的過濾資訊進行過濾，這些過濾資訊可能是由消費者提供的價格範圍或者是對於不同品種的建議等。

葡萄酒主體現在就可能嘗試要提供關於馨芳葡萄酒的通用資訊或者瑪麗埃塔馨芳葡萄酒的特定資訊。它可能使用一個具有葡萄酒站點背景的本體來尋找關於特定的葡萄酒的資訊。例如，它可能用到釀酒廠對它們最新的馨芳葡萄酒的描述 。像Wine Spectator 這樣的其他相關資訊源的額外的評論也可能被用上。如果在某個最受歡迎的站點上沒有關於瑪麗埃塔馨芳葡萄酒的相關評論，在相同的地方找一些關於馨芳葡萄酒的評論可能也是有用的，比如在這裏就可以找一些關於加利福尼亞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]。它們也根據啓瓶器的不同類型（杠杆型、服務員型、固定型、旋轉型、抽吸型）進行區分，而主人可能想要得到關於這些不同類型的啓瓶器的資訊。
.

根據不同領域的背景本體知識和不同的資訊以及不同的服務站點，葡萄酒主體可能應用到不同複雜程度的情況中去。在本例中，我們僅僅考慮了關於酒、品種類型、食物和酒的組合、某些酒的附屬品和它們相關屬性的一些資訊。當然，我們能夠根據顧客要求將本例擴展以包含更多的資訊和更多的約束。

葡萄酒主體的例子還在不斷完善中，從 這裏 我們可以得到它

This document is the result of extensive discussions within the Web Ontology Working Group as a whole. The participants in this Working Group included: Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, and John Yanosy.

Some critical early text on complex restrictions was written by Raphael Volz, Forschungszentrum Informatik (FZI). Substantial insight was provided by the DAML+OIL Walkthru. Jeremy Carroll, Jerome Euzenat, Jeff Heflin, Kevin Page and Peter F. Patel-Schneider provided extensive reviews. At the WG Face to Face, 8 October 2002, Stephen Buswell, Ruediger Klein, Enrico Motta, and Evan Wallace provided a detailed review of the ontology resulting in substantial changes. At the WG Face to Face, 10 January 2003, Jonathan Dale, Bernard Horan, Guus Schreiber, and Jeff Heflin provided detailed reviews of the Guide resulting in changes. The public reviews provided numerous helpful suggestions and corrections.

Attribute

as in XML

Class Definition

informal term for an owl:Class element

Class Description

describes an OWL class, either by a class name or by specifying a class extension of an unnamed anonymous class

Class name

informal term for an owl:Class rdf:ID attribute value.

Class

as in RDF

Component

for parts of a definition e.g. the arguments to intersection-of in a class definition

Concept

informal term for the abstractions "in the world" that ontologies describe

Constraint

informal term for discussing the effect of a restriction

Data-valued Property

alternative term for DataType Property

Datatype Property

an OWL property that relates individuals to data values

Datatype

an RDFS datatype, almost always one of the built-in non-list XML Schema datatypes

Element

(1) as in XML

(2) an element of a set

Entity

as in XML

Imports Closure

the information in an ontology document, plus the information in the imports closure of ontology documents that are imported by the document

Individual-valued Property

alternative term for Object Property

Individual

an instance of an OWL class, i.e., a resource that belongs to the class extension of an OWL class

Instance Of

the relation between an individual and a class

Instance

a member of the class extension of an OWL class

Name

as in XML Namespaces

Named Class

an OWL class with an associated identifier

Node

as in RDF Graphs

OWL Class

an RDFS class that belongs to the class extension of owl:Class

Object Property

an OWL property that relates individuals to other individuals

Object

(1) the object of an RDF triple

(2) an alternative term for individual (used for historical reasons)

Ontology Document

a Web document that contains an ontology, generally indicated by the presence of an owl:Ontology element in the document

Ontology

(1) collection of information, generally including information about classes and properties

(2) the information contained in an ontology document

Property Definition

informal term for an owl:ObjectProperty element and or owl:DatatypeProperty element

Resource

an element of the RDF domain of discourse

Restriction, global

reserved for discussions of the domain and range of properties

Restriction, local

[see above]

Restriction

usually a piece of a class expression, a statement that expresses a constraint, local by default

Set

a mathematical set

Statement

as in RDF Graphs

Type

as in RDF (rdf:type)

URI reference

as in RDF

Unnamed Class

an OWL class without an associated identifier, normally components of restrictions.

Vocabulary

a set of URI references

[OWL Semantics and Abstract Syntax]

OWL Web Ontology Language Semantics and Abstract Syntax , Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/.
Latest version available at http://www.w3.org/TR/owl-semantics/.

[OWL Overview]

OWL Web Ontology Language Overview , Deborah L. McGuinness and Frank van Harmelen, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-features-20040210/.
Latest version available at http://www.w3.org/TR/owl-features/.

[OWL Reference]

OWL Web Ontology Language Reference , Mike Dean and Guus Schreiber, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
Latest version available at http://www.w3.org/TR/owl-ref/.

[OWL Requirements]

OWL Web Ontology Language Use Cases and Requirements , Jeff Heflin, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-webont-req-20040210/.
Latest version available at http://www.w3.org/TR/webont-req/.

[OWL Test Cases]

OWL Web Ontology Language Test Cases , Jeremy J. Carroll and Jos De Roo, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-owl-test-20040210/.
Latest version available at http://www.w3.org/TR/owl-test/.

[RDF]

Resource Description Framework (RDF) Model and Syntax Specification , Ora Lassila, Ralph R. Swick, Editors. World Wide Web Consortium Recommendation, 1999,
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
Latest version available at http://www.w3.org/TR/REC-rdf-syntax/.

[RDFS]

RDF Vocabulary Description Language 1.0: RDF Schema , Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .
Latest version available at http://www.w3.org/TR/rdf-schema/.

[RDF Concepts]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.
Latest version available at http://www.w3.org/TR/rdf-concepts/.

[RDF Semantics]

RDF Semantics , Patrick Hayes, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.
Latest version available at http://www.w3.org/TR/rdf-mt/.

[RDF Syntax]

RDF/XML Syntax Specification (Revised) , Dave Beckett, Editor. W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/.
Latest version available at http://www.w3.org/TR/rdf-syntax-grammar.

[URI]

Uniform Resource Identifiers (URI): Generic Syntax , T. Berners-Lee, R. Fielding, and L. Masinter, IETF Draft Standard August, 1998 (RFC 2396).

[XML Base]

XML Base, Jonathan Marsh, Editor. W3C Recommendation, 27 June 2001,
http://www.w3.org/TR/2001/REC-xmlbase-20010627/.
Latest version available at http://www.w3.org/TR/xmlbase/.

[XML Namespaces]

Namespaces in XML , Tim Bray, Dave Hollander, Andrew Layman, Editors. W3C Recommendation, Jan 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114/.
Latest version available at http://www.w3.org/TR/REC-xml-names.

[XML]

Extensible Markup Language (XML) 1.0 , Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Editors. W3C Recommendation, 10 February 1998,
http://www.w3.org/TR/1998/REC-xml-19980210.
Latest version available at http://www.w3.org/TR/REC-xml.

[XML Schema 1]

XML Schema Part 1: Structures, Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn, Editors. W3C Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
Latest version available at http://www.w3.org/TR/xmlschema-1/.

[XML Schema 2]

XML Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, Editors. W3C Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/.
Latest version available at http://www.w3.org/TR/xmlschema-2/.

[Integrating Applications]

Integrating Applications on the Semantic Web , James Hendler, Tim Berners-Lee, and Eric Miller. Journal of the Institute of Electrical Engineers of Japan, Vol 122(10), October, 2002, p. 676-680.

[VerticalNet]

Industrial Strength Ontology Management , Aseem Das, Wei Wu, and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-09 2001. In the Proceedings of the International Semantic Web Working Symposium, Stanford, CA, July 2001.

[Wine Ontology From Daml.org]

http://www.daml.org/ontologies/76

[Wine Ontology / CLASSIC Tutorial]

Classic Knowledge Representation System Tutorial , Deborah L. McGuinness, Peter F. Patel-Schneider, Richmond H. Thomason, Merryll K. Abrahams, Lori Alperin Resnick, Violetta Cavalli-Sforza, and Cristina Conati. AT&T Bell Laboratories and University of Pittsburgh, 1994.

[Wine Ontology Tutorial]

Ontology Development 101: A Guide to Creating Your First Ontology, Natalya Fridman Noy and Deborah L. McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, March 2001.

[Wine Ontology in CLASSIC]

Living with CLASSIC: When and How to Use a KL-ONE-Like Language , Ronald J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin Resnick , and Alex Borgida. In Principles of Semantic Networks: Explorations in the representation of knowledge, John Sowa, Editor. Morgan-Kaufmann, San Mateo, California, 1991, pages 401--456.

[DAML+OIL]

DAML+OIL W3C Submission, Includes reference description, both model theoretic and axiomatic semantics, annotated walkthrough and examples.

Annotated DAML+OIL Ontology Markup , Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein. December 2001.

[DAML-ONT]

DAML-ONT initial release at http://www.daml.org/2000/10/daml-ont.html.

[DAML-ONT KIF]

Partial DAML-ONT axiomatization at http://www.daml.org/2000/10/DAML-Ont-kif-axioms-001107.html.
Defined in KIF (http://logic.stanford.edu/kif/kif.html).

[Description Logics]

The Description Logic Handbook: Theory, Implementation and Application , Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, Editors. Cambridge University Press, 2002.

[MCF]

Meta Content Framework Using XML , R.V. Guha and Tim Bray. Netscape Communications, 6 June 1997.

[Part Whole]

A Taxonomy of Part-Whole Relations. M. Winston, R. Chaffin & D. Herrmann. Cognitive Science, 11:417-444, 1987.

[XOL]

XOL: An XML-Based Ontology Exchange Language, Peter D. Karp, Vinay K. Chaudhri, and Jerome F. Thomere. Technical Report 559. AI Center, SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, Jul 1999.

[Dublin Core]

Dublin Core Metadata at home page, http://dublincore.org/.

[Dublin Core XML]

Expressing Dublin Core in RDF/XML, Dave Beckett, Eric Brickley, and Dan Brickley.
Dublin Core Metadata Initiative. July 31, 2002,
http://dublincore.org/documents/2001/11/28/dcmes-xml/.

[KAON]

The Karlsruhe Ontology and Semantic Web Tool Suite at http://kaon.semanticweb.org.

[OIL]

OIL Home Page at http://oil.semanticweb.org/.

[Ontobroker]

The Ontobroker home page at http://ontobroker.aifb.uni-karlsruhe.de/index_ob.html.
Institute AIFB, University of Karlsruhe.

[Ontoknowledge]

Ontoknowledge Home Page at http://www.ontoknowledge.org/.

[RDF Home]

RDF: Resource Description Framework. Background information at http://www.w3.org/RDF/.

[SHOE]

Simple HTML Ontology Extensions (SHOE) home page at http://www.cs.umd.edu/projects/plus/SHOE/. University of Maryland.

[KR]

KR Home Page at http://kr.org/.

這個附錄提供對OWL標準的基礎的介紹的鏈結。

爲了完全理解OWL的語法和語義，你應該對下面列出的相關W3C和IETF標準的基礎知識有所瞭解。下面鏈結的開始兩個提供了對XML和RDF的最簡明指南。

• Appendix 到 DAML+OIL Walkthru
• URI - 統一資源識別字
• XML - 可擴展標記語言
• XML 命名空間
• XML Schema
• RDF - 資源描述框架  
• RDF Schema

資源描述框架(RDF) 是W3C的第一個用於表達關於任意資源的語義資訊的語言。 RDF Schema (RDFS) 是一個W3C候選推薦標準[譯注//目前RDF Schema已成爲W3C推薦標準]，它是一個RDF的擴展，用於描述RDF辭彙。RDFS可被用於創建本體，但它是羽量級的，表達能力要弱於OWL。

和OWL一樣，RDFS中也有類（class）和屬性（property），以及值域（range）和定義域（domain）限定。RDFS也允許爲類和屬性定義繼承的層次結構。RDFS一經發佈，用戶們就開始要求添加新的特性，比如資料類型，枚舉以及對屬性施加更多限制的能力。

實際上，研究圈內已經有一些對上述這些特性進行研究的工作。下面是部分相關的專案和語言列表，供希望作進一步瞭解的讀者參考：

• DAML - DARPA Agent Markup Language
• DAML-ONT
• MCF - Meta Content Framework.
• Ontobroker
• On-To-Knowledge
• OIL - Ontology Inference Layer
• SHOE - Simple HTML Ontology Extensions
• XOL

一些研究人員，包括許多參與制定OIL和DAML-ONT的主要成員，並沒有只致力於開發各自獨立的語義網本體語言，而是聚集在Joint US/EU ad hoc Agent Markup Language Committee （主體標記語言特別美歐聯合委員會），創建了一種新的Web本體語言。該語言DAML+OIL建立在OIL和DAML-ONT的基礎之上，並被提交給W3C，作爲OWL的基礎。該語言是OWL的起始點。

除本體語言之外，已有不少層次分類和本體處於商業應用之中。在電子商務網站上，它們促進了買賣雙方基於機器的通信、使得市場的縱向集成成爲可能、允許描述在不同的交易場所中被重用。將本體投入實際商業應用的站點的例子有：

• VerticalNet Vertical Net currently hosts 59 industry-specific e-marketplaces that span diverse industries such as manufacturing, communications, energy, and healthcare.

各種醫藥相關的本體已被創建用於管理海量的醫學和生物化學研究資料，否則將很難將這些資料聚合爲一個一致的本體。Gene Ontology Consortium （基因本體聯盟）是這樣面的一個主要資源，他們定義的本體涉及：

• Molecular Function,
• Biological Process, and
• Cellular Components.

That site also has pointers to ontologies for

• sequence attributes,
• gene product attributes,
• chemical substances,
• pathways,
• anatomies,
• pathology,
• physical characteristics,
• experiment attributes,
• classification, and
• pathology.

有一些正在使用的大型層次分類體系可被作爲OWL空間的延伸。比如，北美工業分類系統（North American Industry Classification System，NAICS）定義了一個包含超過1900個條目的層次分類體系。NAICS還依賴于聯合國開發並維護的國際工業分類系統（International Standard Industrial Classification System，ISIC Revision 3）。

• 修正了一個文字錯誤（allValuesFrom 改爲 someValuesFrom），在4.1節的TexasThings例子中。
   
• 增加了owl:AnnotationProperty的錨(anchor)。
   
• 在3.1.1節，爲'about' 語法例子增加了明確的本體字首。
   
• 在5.2節末尾的 Reference 處，增加了一個對描述owl:oneOf的用法的交叉引用。
   
• 根據發到public-webont-comments的 消息 的建議，作了一些小的修正。
   
• 爲了保持和其他OWL文檔的一致性，修改了一些引用。
  .
• 爲了保持和其他OWL文檔的一致性，修改了一些引用。
  修改了一些關於名字空間引用的編號的文字錯誤。

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4