このドキュメントは
Web Ontology Language (OWL) Guide Version 1.0
http://www.w3.org/TR/2002/WD-owl-guide-20021104/
の和訳です。
この文書には和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版文書を参照して下さい。
W3C

Web Ontology Language (OWL)
ガイド Version 1.0

W3C Working Draft 4 November 2002

この版：
http://www.w3.org/TR/2002/WD-owl-guide-20021104/
最新版：
http://www.w3.org/TR/owl-guide/
以前の版：
なし
著者：
Michael K. Smith, Electronic Data Systems, mailto:michael.smith@eds.com
Deborah McGuinness, Stanford University, mailto:dlm@ksl.stanford.edu
Raphael Volz, Forschungszentrum Informatik (FZI), mailto:volz@fzi.de
Chris Welty, IBM Research, mailto:welty@us.ibm.com

Copyright 2002 W3C ( MIT ， INRIA ， Keio )， All Rights Reserved． W3C 責任 ， 商標 ， ドキュメント利用 ， ソフトウェア許諾 規則が適用される．

アブストラクト

現在のWorld Wide Webは，不完全に作られた地理学に例えることができる．ドキュメントに対する我々の識見や能力は，ドキュメント間の関連や利用パターンを賢く使ったキーワード検索に基づくものにすぎず， Web上のデータの大部分は強力なツールの支援なしには手におえない．地形をより正確にコンピュータ・エージェントに描かせるには， webからアクセス可能なリソースの内容や特性に関するマシンリーダブルな記述を与える必要がある．これらの記述は，人間が理解可能な情報に付加されるものでなければならない．

The Web Ontology Language (OWL)は， Webドキュメントやアプリケーションに固有の，クラスやクラス間の関連を記述するのに使うことができる言語の提供を目指している．

このドキュメントでは，以下の用途におけるOWL言語の利用を説明する．

  1. クラスとクラスのプロパティを定義することによってドメインを形式化する．
  2. 個体を定義し，それについてのプロパティを言明する．
  3. OWL言語の形式意味論が許す範囲で，クラスと個体について推論する．

基本から始めて，より複雑な言語要素へと進むことで，一まとまりのクラス，プロパティ，個体を漸進的に定義するよう，各セクションは構成されている．

このドキュメントの位置付け

このセクションは， 2002年11月4日公開時点でのこのドキュメントの位置付けを示す．このドキュメントは他のドキュメントによって置き換えられ得る．このドキュメントは， W3Cメンバやそれ以外でも関心のある関係者によるレビューのためのW3Cワーキングドラフトである．このドキュメントは草案であり，いつでも他のドキュメントによって更新，置換，破棄され得る． W3Cワーキングドラフトをリファレンスマテリアルとして使うことや，「作業途上」として以外で引用することは適切ではない． W3Cリコメンデーションや他の技術ドキュメントは， http://www.w3.org/TR/ に置かれている．

このドラフトは，大まかに DAML+OIL walkthrough の方向へ向けて始まった，ただしより現実的で詳細な例を使った，ワーキンググループの現在までの成果である．ワーキンググループではかなりのレビューを行ったが，特に残っているオープン・ イシュー に関しては，まだ作業が必要であると予測される．

このドキュメントに関するコメントは， mailto:public-webont-comments@w3.orgへ送っていただきたい．これは， 公開アーカイブ のあるメイリングリストである．関連技術に関する一般的な議論は， www-rdf-logic で歓迎する．

また， この作業に関する特許ディスクロージャ も見ていただきたい．

このドキュメントは， W3C　セマンティックWeb・アクティビティ （ Activity Statement ）の一部として， W3C Process に規定された手続きにしたがって作成された．このドキュメントは， Webオントロジ・ワーキンググループ によって書かれたものである． Webオントロジ・ワーキンググループの目標は， Webオントロジ・ワーキンググループ　チャーター で議論されている．

目次

はじめに

「以下のメニューの各々のコースで供するためには，どのワインを買えば良いか教えて欲しい．ただし，私はソーテルヌは好まない」

今日，この要求に適合するワインをweb上で検索することのできるWebエージェントを構築することは困難であろう．同様に，旅行の一貫した手配作業をソフトウェア・エージェントに実際に与える場合を考えてみても良い（他のユースケースについては， OWL requirements document を参照）．

このような種類の計算をサポートするには，キーワードを超えてweb上に記述されたリソースの意味を規定することが必要である．このように追加された解釈のレイヤは，データの セマンティクス を扱う．

OWLは， Webオントロジ とそれに関連する知識ベースを定義するための言語である． オントロジ は哲学から借りた用語であり，世界にある事物の種類とそれらの関連の仕方を記述する科学を意味する． OWLでは， 一つのオントロジ は クラス と プロパティ の定義と，それらを使うための制約の集まりである． OWLオントロジは以下の要素を含み得る．

さらに，より下位の

データ型プロパティとオブジェクト・プロパティはあわせて，一つのクラスのプロパティである．

推論システムにロードされたOWL言明の集合は， 知識ベース （KB）と呼ばれる．これらの言明は，クラスのメンバである個体に関する事実と同様に，もとのオントロジのテキスト表記で文字には表現されないが OWLの意味論によって 帰結 （論理的に含意）される，さまざまな導出された事実を含むかもしれない．これらの言明は単一のオントロジに基づくものであるかもしれないし， OWLメカニズム の定義を使って結合された，複数の分散したオントロジに基づくものかもしれない．

オントロジは（知識ベースとは異なって）大部分はクラスのインスタンスを含まないが，インスタンスを含む場合の多くは，あるクラスを定義する際にオントロジ中にインスタンスが必要になる場合である．例えば， ワイン と 色 をクラス， 赤 を 色 クラスのインスタンスと考えると， 赤ワイン クラスでは定義の一部としてインスタンス 赤 が必要になり，結果としてオントロジの要素としてインスタンスが必要になる．

新たなXML/Web標準について述べるときに起こる疑問は，「これが与えてくれる，XMLやXML Schemaにはないものは何か？」である． XMLタグセットの意味とその内容に関する操作的な合意は，いつでも開発することができる．まさにこれを行っている，猛烈に進行中の標準化活動が存在する．

この疑問に対する答えは２つある．

OWLの種類

OWLは，実際には段階的に複雑な３つの言語の集まりである．

OWL DLやOWL Fullでのみ許される言語要素を導入する際には，「[OWL DL]」と印を付けて示す．

ドキュメントの構成

このガイドを通じて一貫した例を提供するため，記述論理の 例 と チュートリアル として開発された先のDAML版に基づいて，我々は ワイン　オントロジ を作成した．

このドキュメントでは， XMLが多くの読者になじみがあるものと考えて， OWL XML構文 を使って例を示す． OWL言明をツール間で交換するための標準は RDF ３項組に依存する．これらのXMLとRDFフォーマットは，標準の一部である．他の記法，特に UML バージョンもまとめられている．関連する標準への紹介リンクを， 付録A に掲げる．

まだ明確にされていないが予期される変更を示す注釈には，「@@」を付けた．例えば， [@@ 注釈]． このドキュメントに示した全ての例は，右下に  ¬  の印のあるものを除いて， wine.owl と food.owl に含まれるオントロジから採った．

オントロジの構造

OWLは セマンティックWeb アクティビティの一部である．これは， Webのコンテンツを記述あるいは提供するリソースに関する情報を付加することによって， Webリソースを自動化されたプロセスによって容易にアクセスできるようにすることを目的としている．セマンティックWebはwebコンテンツを扱うので，分散していることが避けられない． OWLオントロジもまた，分散していることを予期しなければならない．この結果の一つとして， OWLは一般にopen worldを仮定する．つまり，リソースの記述は一つのファイルやスコープの中には制限されない．クラスC1はオントロジO1で初めに定義されたとしても，他のオントロジの中で拡張されることは可能である．このC1に関して加えられた命題の結果は， 単調的である．新しい情報は，それまでの情報を否定することはできない．事実と帰結は付加されるのみで， 削除されてはならない．

OWLでは否定を陽に記述することを許す．その結果，矛盾を陽に言明することは全く簡単である．さらに，矛盾は暗黙のものであるかもしれない．知識ベースのこれらの特性は，オントロジ設計者が注意する必要がある点である．ツール支援が，このような場合に助けになることが期待される．

あいまい性のない解釈とソフトウェア・エージェントによる利用が可能なオントロジを書き下すためには，形式的な構文と意味論が必要である． OWLは，オントロジ構築のために必須のこれらの土台を提供する． 形式意味論 と XML構文 を参照していただきたい．

名前空間

ひとまとまりの語彙を使う前には，どの特定の語彙が使われているかの正確な表示が必要である．オントロジの標準的な初期コンポーネントは，最初のrdf:RDFタグで包まれた名前空間宣言の集まりを含む．これらは識別子をあいまい性なく解釈する手段を提供し，残りのオントロジの表示をたいへん読みやすくする．典型的なOWLオントロジは，以下と同等の 名前空間の宣言 で始まる． 

<rdf:RDF 
    xmlns     ="http://www.example.org/wine#" 
    xmlns:vin ="http://www.example.org/wine#"       
    xmlns:food="http://www.example.org/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/2000/10/XMLSchema#"
    xmlns:dte ="http://www.example.org/wine-dt#"    >

最初の２つの宣言は，このオントロジに関連する名前空間を識別する．初めのものは，プレフィックスのないエレメントと空のURI参照がカレント・オントロジを参照することを述べて，それをデフォルトの名前空間にする．２番目のものは，プレフィックスvin:を持つカレント・オントロジの名前空間を指示する．３番目のものは，プレフィックスfood:を持つ，補助の食品オントロジの名前空間を指示する．

４番目の名前空間宣言は，このドキュメントではowl:を前置されたエレメントは http://www.w3.org/2002/07/owl# と呼ばれる名前空間の事物を参照すると理解されるべきであることを言っている．これは通常のOWL宣言であり， OWL語彙を導入するために必要である．

OWLはRDFとRDFSによって定義された構成要素に依存する．このドキュメントでは，プレフィックスrdf:は http://www.w3.org/1999/02/22-rdf-syntax-ns# と呼ばれる名前空間の事物を参照すると理解される．次の２つの名前空間は， RDF Schema（rdfs:）とXML Schema データ型（xsd:）名前空間に関する同様な宣言である．

このOWLドキュメントはXML Schema データ型定義を含む別のドキュメントと関連している．最後の宣言は， dte:を前置した要素は，このガイドのデータ型定義を含む， http://www.example.org/wine-dt# と呼ばれる名前空間の事物を参照すると理解されるべきであることを言っている．

オントロジ定義に先立つドキュメント型宣言（DOCTYPE）の中でエンティティ宣言の集まりを与えることは，長いURL参照の書き下しを避けるうえでしばしば有効である．名前空間宣言で定義された名前はXMLタグの一部としての重要性のみを持ち，属性値は名前空間の影響を受けない．しかし， OWLではしばしばオントロジ識別子を属性値を使って参照する．それらは， "http://www.example.org/owl/wine#merlot"のように，完全に展開した形で書き下すことができる．あるいは， ENTITY定義を使って省略形を定義することができる，例えば： 

<!DOCTYPE owl [
    <!ENTITY vin  "http://www.example.org/wine#" >
    <!ENTITY food "http://www.example.org/food#" > ]>

この２つのENTITY宣言の後では，値"&vin;merlot"を書くことができ，それは"http://www.example.org/wine#merlot"に展開される．

オントロジ・ヘッダ

一旦名前空間が確立すれば，それに続くものがOWLオントロジであることを示す言明から始める． 

<owl:Ontology rdf:about="http://www.example.org/wine">

この言明は決り文句である． about属性は通常現在のファイルのURLであり，この表明の主題がこのドキュメントであることを示す．もし必要ならば，オントロジには名前を付けることができる．名前はURNであり，特定の物理的位置には独立である．

我々がオントロジを定義しようとしている事実が確立し，必要な名前空間マッピングが与えられれば，コメントやバージョン管理や他のオントロジの包含などの重要な整理作業を取り扱うための付加的なタグの集合を与える． 

<owl:Ontology rdf:about="http://www.example.org/wine"> 
  <rdfs:comment>An example OWL ontology</rdfs:comment>
  <owl:versionInfo>
      $Id: Overview.html,v 1.2 2002/11/08 16:42:25 connolly Exp $
  </owl:versionInfo>
  <owl:imports rdf:resource="food.owl"/>

<rdfs:comment> はオントロジに注釈を付けるという，明らかに必要な機能を提供する．

<owl:versionInfo> は，オントロジに働くバージョン管理システムに一貫したフックを与えることを意図した標準タグである． OWLは内容の構造は規定しない．

<owl:imports> はincludeスタイルのメカニズムを提供する． <owl:imports> はrdf:resource属性で指定される１つの引数をとる．

他のオントロジの輸入は，そのオントロジで与えられる定義の全てを知識ベースに持ち込むことを意味する．輸入したオントロジを最大限に利用するために，通常は名前空間宣言と整合させる．これらの２つのメカニズムの間の違いに注意して欲しい． OWL名前空間宣言は，他のオントロジで定義された名前の参照を意味する便利な方法を与える．概念的には， owl:importsは目的オントロジの言明を包含するという記述者の意図を表現する．これらの言明は，そのオントロジで定義された語句の意味，その語句についての推論を支援する意味．を定義する．

owl:importsが常に成功するとは限らないことに注意して欲しい．セマンティックWebを扱う際に予期されるように， Web上に分散したリソースへのアクセスは常に可能であるとは限らない．それに対するツールの反応の仕方は，実現によって定められる．

[@@ 輸入についての最終的な詳細は，まだワーキンググループで検討中である]

ここで包含されるのが適切な付加的なタグの共通セットの１つは，標準の ダブリン　コア メタデータ　タグである．例えば， Title，Creator，Description，Publisher，Dateを含む．ダブリン　コア名前空間を定義するURIは， 'http://purl.org/dc/elements/1.1/'である．

OWLはカレント・オントロジと輸入したオントロジを結合するメカニズムを，他にもいくつか提供する（ オントロジ　マッピング 参照）．

オントロジ・ヘッダ定義は，次のタグで閉じられる． 

  </owl:Ontology>

このプレリュードに続いてオントロジを構成する実際の定義が置かれ，最終的には 

</rdf:RDF>
で閉じられる．

基本定義

単純クラスと個体

オントロジ利用者の多くは，個体に関する推論能力に頼る．これを有用なやり方で行うために，個体が属するクラスとクラスメンバーシップによって，継承する特性を記述するメカニズムを持つことが必要である．我々は個体に関する特定の性質をいつでも言明することができるが，オントロジの能力の多くはクラス ベースの推論から得られる．

我々は時々，オブジェクトとしてのクラスと，要素を包含する集合としてのクラスの違いを強調しておきたい．クラスのメンバである個体の集合を，クラスの外延と呼ぶ．

簡単な階層的な名前付きクラスの定義
class，subClassOf

ドメイン中の最も基本的な概念は，様々な分類木のルートになるクラスと対応付けられるべきである． OWL世界の全ての個体は， owl:Thingのメンバである．したがって，各々のユーザ定義クラスは暗黙的にowl:Thingのサブクラスである．ドメイン依存のルートクラスは，単純に名前付きクラスを宣言することによって定義される．

サンプルのワイン　ドメインのために，我々は３つのルートクラスを作成した： 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"は，その定義の一部として，最初に名前を導入するのに使われる．これは， XMLで定義されるよくあるID属性に似た， rdf:ID 属性である．このドキュメントの中では， Regionクラスはrdf:resource="#Region"を使って参照することができるようになった．他のオントロジが，その完全な形"documentURI#Region"で，この名前を参照するかもしれない（下記を参照）．

参照のもう一つの形は，リソースの定義を 拡張 するのに，構文rdf:about="#Region"を使う． rdf:about="#x"構文のこの利用は，分散したオントロジの作成において重要な要素である．これによって， xの輸入された定義の拡張を，オリジナルドキュメントの変更なしに行うことが可能になり，大きなオントロジの漸増的な構築がサポートされる．

これで，他のOWL構文要素で定義したクラスを，識別子を使って参照することが可能になった．このドキュメントの中では，最初のクラスに対しては相対識別子#Wineryを使うことができる．他のドキュメントでこのクラスを参照する最も適切な方法は，定義しているドキュメントをソースとして取り込むエンティティ定義と，名前空間を与えることである： 

...
<!ENTITY vin  "http://www.example.org/wine#" >
...
<rdf:RDF xmlns:vin="http://www.example.org/wine#" ... >
...

これらの定義を与えることで， wineryクラスをXMLタグvin:Wineryあるいは属性値&vin;Wineryを使って参照することができる．より厳格には，完全なURI http://www.example.org/wine#Wineryを使ってリソースを参照することは，常に可能である．

クラスの基本的な分類構成子はsubclassOfである．これは推移的であり，もしXがsubclassOf YでありYがsubclassOf Zならば， XはsubclassOf Zの一つである． 

<owl:Class rdf:ID="PotableLiquid"> 
  <rdfs:subClassOf rdf:resource="#ConsumableThing" />
  ...
</owl:Class>

PotableLiquid（飲用適合液体）をConsumableThingのサブクラスとなるように定義した．

webに基づくオントロジの世界では，これらのクラスはどちらも，様々な食品と飲料のオントロジの基本構成要素を提供する別のオントロジで定義されるべきである．実際，我々はそのようにした．これらの要素は，ワインオントロジに 輸入 された， food オントロジで定義されている． foodオントロジは，例えばFood，EdibleThing，MealCourse，Shellfishのような，ワインの事物の集合には属さないが有用な推論を行う時にはワインの語彙と結合しなければならない，多くのクラスを含んでいる．ワインと料理の相性を知りたいという我々の要求を満たすためには，食品とワインは相互に依存する．

クラス定義は２つの部分を持つ：名前の導入あるいは参照と，一連の制約である．クラス定義に直接含まれる式は，定義されるクラスのメンバをさらに制約する．クラス要素は制約の共通部分のメンバである．ここまでは，新しいクラスを他の名前付きクラスのサブクラスにする制約を１つ含む例だけを見てきた．

この時点で，クラスWineの簡単な（そして不完全な）定義を作ることができる． WineはPotableLiquidである． 

<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="#PotableLiquid"/> 
  <rdfs:label xml:lang="en">wine</rdfs:label> 
  <rdfs:label xml:lang="fr">vin</rdfs:label> 
  ...  
</owl:Class>

rdfs:labelエントリは，このクラスに対する最適で可読な名前を与える．これは，表示ツールが使うことができる． "lang"属性は多言語サポートを与える．ラベルはコメントに似ており，オントロジの論理的解釈には関与しない．

我々のワイン定義はまだ不完全である．我々はワインがthingでありportable liquidsであること以外は何も知らないが，個体を作ってそれに関する推論を行うのには十分な情報を持っている．

個体の定義

クラスだけでなく，そのメンバを記述できると良い．それらは通常，我々の事物の世界の中の個体であると考えられる．個体は，クラスのメンバであると宣言することによって最小限に導入される． 

<Region rdf:ID="CentralCoastRegion" />

以下が上の定義と同じ意味であることに，注意して欲しい． 

<owl:Thing rdf:ID="CentralCoastRegion" /> 

<owl:Thing rdf:about="#CentralCoastRegion"> 
   <rdf:type rdf:resource="#Region"/> 
</owl:Thing>

rdf:typeは，個体をクラスに結びつけるRDFプロパティである．

ここで，ポイントが２つある．１つは， CentralCoastRegion（特定の地域）が全ての地理学上の地域を含むクラスRegionのメンバであると，我々が決めたことである．

もう一つのポイントは，上の２番目の例では並列する２つの部分が隣り合っている必要はない，それどころか同じファイルにある必要もない（その場合には名前はURIで拡張されていなければならないが）ことである．我々はWebオントロジを分散するように設計した．派生オントロジを作るために，オントロジを輸入し拡張することが可能である．

次のセクションで導入するプロパティで利用する，いくつかのより基本的な定義として，ぶどうのカベルネソーヴィニョン種を表す個体を持つGrape分類の分枝を定義する． 

<owl:Class rdf:ID="Grape">

<owl:Class rdf:ID="WineGrape">
  <rdfs:subClassOf rdf:resource="#Grape"/>
</owl:Class>

<WineGrape rdf:ID="CabernetSauvignonGrape" />

下で議論するように， CabernetSauvignonGrapeはぶとうの一つの種を表すので個体である．

利用に適した設計

OWLのクラスと個体の区別に関連して，重要な問題がある．クラスは単純に名前と個体の集合を記述する特性の集まりであり，個体はそのような集合のメンバである．このように，クラスは領域の中の事物に自然に存在する集合に対応すべきであり，個体はクラスにまとめることのできる現実の実体に対応すべきである．

オントロジを構築する際には，この区別が次の２点でしばしば混乱する：

同じ区別がWineクラスの扱いでも起こることに注意して欲しい． Wineクラスは，だれかが購入するかもしれない実際のボトルの集合ではなく，ワインの全ての種類を表す． Wineの全てのインスタンスは，そのタイプのワインのボトルすべてからなるクラスであると考ることもできる．ワイン業者の在庫管理システムのように，ワインの個々のボトルを考える必要がある情報システムを想像することは容易である．そのような解釈をサポートするためには，現在あるワインオントロジではクラスをインスタンスとして扱う機能が必要である．

同様に，特定の年にワイナリで作られたワインはビンテージとみなされる．ビンテージの概念を表現するためには，それが現在のオントロジに適合する場所を決めなくてはならない．上に議論したように， Wineクラスのインスタンスは，例えばFormanChardonnayのように，一つのワイナリで作られた一つの種類を表現する，

2000年に作られたワインが ビンテージと考えられることを加えるのは，与えられたワインの個体の部分集合を表現する機能を持たない以上，チャレンジングな問題である．ビンテージはワインの新しい種類ではなく，ワインの特別な部分集合−2000年に作られた−である．クラスをインスタンスとする表現を許さない限り，インスタンスがビンテージWineと関係付けられる別のクラスVintageを考えざるを得ない．例えばFormanChardonnay2000は， WineのFormanChardonnayを値とするプロパティvintageOfを持つ， Vintageの個体である． Vintage クラスを以下に定義する．

間違いなくこれらの問題は，より上級のオントロジ構築者の問題であり，このドキュメントではこれ以上扱わない．この議論の要点は，オントロジの開発は意図した利用法によって確実に方向付けられているべきであることを指摘する点にある．これらの問題はまた， OWL FullとOWL DLの大きな違いの一つを明確にする． OWL Fullはクラスをインスタンスとして使うことを許すが， OWL DLはそうではない．ワインオントロジはOWL DLで機能するよう設計されており，結果としてFormanChardonnayのような個体を同時にクラスとして扱うことはできない．

単純プロパティ

プロパティの定義
ObjectProperty，DatatypeProperty，subPropertyOf，
domain，range

もし分類しか定義できないとしたら，このクラスと個体の世界は全くつまらないものだろう． プロパティによって，我々はクラスのメンバに関する一般的な事実と個体に関する特定の事実の言明を行うことができる．

プロパティは２項関係である．２つの種類のプロパティは区別される：

プロパティを定義する際には，関係の要素を制約するいくつかの方法がある．定義域と値域を指定することも可能である．プロパティを，既にあるプロパティの特殊化（サブプロパティ）として定義することもできる．より巧妙な制約も可能であり， 後で 述べる． 

<owl:ObjectProperty rdf:ID="madeFromGrape"> 
  <rdfs:domain rdf:resource="#Wine"/>
  <rdfs:range rdf:resource="#WineGrape"/> 
</owl:ObjectProperty>

OWLでは，文の演算子を陽に持たない並びは暗黙の論理積を示しており，それを包含する要素に作用する．プロパティmadeFromGrapeは，定義域Wineと値域WineGrapeを持つ．すなわち， madeFromGrapeはクラスWineの要素をクラスWineGrapeの要素に関連付ける．

プロパティは，クラスと同様に，階層的に配置することができる． 

<owl:ObjectProperty 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はワインを色と味の要素，甘味／ボディ／風味など，に関連付ける． hasColorは， hasWineDescriptorプロパティの定義域をWineColorに制限したサブプロパティである．

次に，事物をそれが位置する地域に関連付けるプロパティ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>

locatedInの定義域と値域がどのように定義されるかに注意して欲しい．地域内に位置するあらゆるものが定義域に含まれる．原理的には，この関係を推移的に結合すると，リーフがあらゆるものである地理的な包含関係の木が構成される．

これで，地域の概念と，ワインが少なくとも一つのWineGrapeから作られることを含むように， Wineの定義を拡張することが可能になった．プロパティ定義のように，クラス定義も暗黙に結合される多重の部分構造を持つ． 

<owl:Class rdf:ID="Wine"> 
  <rdfs:subClassOf rdf:resource="#PotableLiquid"/> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#madeFromGrape"/>
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction> 
  </rdfs:subClassOf>
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn"/> 
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
  ...  
</Class>

強調されたサブクラス制約は，少なくとも一つのmadeFromGrapeプロパティを持つ事物の集合を表す，名前付けされていないクラスを定義する．これらをanonymousクラスと呼ぶ．[OWL DL] Wineクラス定義の本体にこのサブクラス制約を挿入することで，ワインである事物は同時にanonymousクラスのメンバでもあることを言明する．すなわち，すべてのワイン個体は，少なくとも１つのmadeFromGrape関係に関与していなければならない．さらに，全てのワインは少なくとも１つの地域から来なければならない．この表現は， 制約 のセクションで詳細に示す．

これで， 上で 議論した Vintagesクラスを定義することができる． 

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> 
  <rdfs:subClassOf>
    <owl:Restriction> 
      <owl:onProperty rdf:resource="#vintageOf"/>
      <owl:minCardinality>1</owl:minCardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</Class>

プロパティvintageOfはVintageをWineに結びつける． 

<owl:ObjectProperty rdf:ID="vintageOf">
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#Wine" />
</owl:ObjectProperty>

次のセクションでは， Vintagesを年に関連付ける．

プロパティとデータ型

リソースをリソースに関連付ける（オブジェクト・プロパティ）か，リソースをデータ型に関連付ける（データ型プロパティ）かによって，プロパティを区別する．データ型プロパティの値域は文字列でも良いし， XML Schemaデータ型にしたがって定義された単純型でも良い．

ビンテージ・イヤーを1700年以降に制限する場合を考える． http://www.example.org/wine-dt.xsd のような別のファイルに， XML Schemaデータ型定義を作る．これには，以下が含まれる： 

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
       xmlns="http://www.example.org/wine-dt.xsd">

  <xsd:simpleType name="year"> 
    <!-- year is an XMLS datatype based on integer --> 
    <xsd:restriction base="xsd:decimal"/> 
  </xsd:simpleType>
  
  <xsd:simpleType name="wineYear"> 
    <!-- wineYear is an XMLS datatype based on year --> 
    <!-- with the added restriction that values must be GEQ 1700 --> 
    <xsd:restriction base="year"> 
    <xsd:minInclusive value="1700"/>
  </xsd:restriction> 
  </xsd:simpleType>
</xsd:schema>

「year」型はXML Schema単純型「decimal」の部分型として定義される．「wineYear」型は， 1700以上の１０進数に制限された「year」型の部分型である．このファイルの要素を， OWLプロパティ定義やクラス制約で参照することができる． 

<owl:Class rdf:ID="WineYear" />

<owl:DataTypeProperty rdf:ID="yearValue">
  <rdfs:domain rdf:resource="#WineYear" />    
  <rdfs:range  rdf:resource="&dt;wineYear"/>
</owl:DataTypeProperty>

yearValueプロパティはWineYearを1700以上の十進数に関連付ける． Vintageを直接XML Schemaデータ型dte:wineYearに結合することも可能ではあるが，この間接化のレイヤによってオントロジをワインの「豊年」に結びつけることができる． Vintageを 以下の WineYear に関連付けるプロパティhasVintageYearを定義する．

[@@ データ型参照の最終的な構文については， RDF Coreからの入力を待っているところである]

個体のプロパティ

初めにRegionとWineryの個体を作り，最初のワインとなるカベルネソーヴィニョンを定義する． 

<CaliforniaRegion rdf:ID="SantaCruzMountainsRegion" /> 

<Winery rdf:ID="SantaCruzMountainVineyard" />

<CabernetSauvignon rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
  <locatedIn   rdf:resource="#SantaCruzMountainsRegion"/>  
  <hasMaker    rdf:resource="#SantaCruzMountainVineyard" />   
</CabernetSauvignon>

これは，まだ不完全である．他にもワインの風味の側面があり，完全なオントロジで定義されるが，それらは抜け落ちている．我々は，このワインがどのようなメニューの項目に合うかの推論を始めることができる．上記の定義より，このワインはSanta Cruz Mountain Vineyardで作られたことが分かる．カベルネソーヴィニョンなので（ wine.owl 参照），辛口の赤ワインであることも分かる．

データ型プロパティも，同じようにして個体に与えることができる．以下ではWineYearのインスタンスを作成し， > 1700の整数であるdte:wineYear型の特定の値と結合する． 

<WineYear rdf:ID="Year1998">
  <yearValue rdf:datatype="&dte;wineYear">1998</yearValue>
</WineYear>

プロパティの性質

次のいくつかのセクションでは，さらにプロパティを定義するのに使うメカニズムについて述べる．プロパティについて拡張された推論を行うための強力なメカニズムを与える，プロパティ特徴を規定することができる．

TransitiveProperty

推移的なプロパティPは，次の公理を満たす： 

P(x,y) and P(y,z) -> P(x,z)

プロパティlocatedInは推移的である． 

<owl:ObjectProperty rdf:ID="locatedIn">
  <rdf:type rdf:resource="&owlTransitiveProperty" />
  <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>

locatedInは推移的であり， SantaCruzMountainsRegionはCaliforniaRegionにlocatedInなので， SantaCruzMountainsRegionはUSRegionにlocatedInでなければならない．

SymmetricProperty

対称的なプロパティPは，以下の公理満たす： 

P(x,y) iff P(y,x)

プロパティadjacentRegionは対称的であるのに対し， 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に位置するが，その逆ではない．

Functional Property

関数的なプロパティPは，次の公理を満たす： 

P(x,y) and P(x,z) -> y = z

ワイン・オントロジでは， hasVintageYearが関数的である．ひとつのワインは，唯一のビンテージ・イヤーを持つ．すなわち， Vintageの与えられた個体は， hasVintageYearプロパティを使って１つの年とのみ関連付けることができる．定義域のすべての要素が値を持つことは， FunctionalPropertyの要求ではない． Vintageカーディナリティ の議論を参照． 

<owl:Class rdf:ID="WineYear" />

<owl:ObjectProperty rdf:ID="hasVintageYear">
  <rdf:type rdf:resource="&owl;FunctionalProperty" />
  <rdfs:domain rdf:resource="#Vintage" />
  <rdfs:range  rdf:resource="#WineYear" />
</owl:ObjectProperty>
inverseOf

inverseOf P2であるプロパティP1は，次の公理を満たす： 

P1(x,y) iff P2(y,x)

inverseOfの構文は，プロパティ名を引数として取ることに注意してほしい． 

<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はメーカを持つが， Wineの定義ではメーカはWineryに限定されている．したがって， Wineryはメーカがそのワイナリであるワインの集合を生産する．

InverseFunctionalProperty

逆関数的であるプロパティPは，以下の公理を満たす： 

P(y,x) and 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>                                      

逆関数的なプロパティの値域の要素は，データベース的な意味でユニーク・キーを与えると考えることができる． Inversefunctionalは，値域の要素が定義域の各々の要素に対して唯一の識別子を提供することを意味する．

プロパティの制約

プロパティの性質の区分に加え，特定の文脈で様々な方法でプロパティの範囲をさらに制限することができる．

allValuesFrom, someValuesFrom

我々はすでに，プロパティを作る要素の型を制限するひとつの方法を見た．これまでのメカニズムは，プロパティの全てのインスタンスに作用するので， グローバルである．次の２つ， allValuesFromとsomeValuesFromは，それを含むクラス定義に局所的である． 

<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:allValuesFromをowl:someValuesFromで置き換えると， 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   全てのワインについて，少なくとも１つのメーカはワイナリである．

最初のものは，ワインがメーカを持つことを要求してはいない．もし１つあるいはそれ以上のメーカを持つならば，それらは全てワイナリでなければならない．２番目のものは，ワイナリであるメーカが少なくとも１つ存在することを要求するが，ワイナリでないメーカが存在してもかまわない．

カーディナリティ

既にカーディナリティ制約の例を見たが，それらは最小のカーディナリティに関する言明であった．関連する要素の数を正確に指定するowl:cardinalityは，より直裁的である．例えば， Vintageをちょうど１つのWineYearを持つクラスと定義する． 

<owl:Class rdf:ID="Vintage"> 
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#hasVintageYear"/>  
      <owl:cardinality>1</owl:cardinality>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

hasVintageYearを関数的なプロパティと定義する．そのプロパティをVintageに適用することは， 全てのVintageはちょうど１つのWineYearを持つという，より強い言明となる．

OWL Liteでは，カーディナリティ式は「0」と「1」に限定した値を持つ．これにより，利用者は「少なくとも１つ」，「１を超えない」，「ちょうど１つ」を示すことができる． OWL Fullでは， 0と1以外の正整数も使うことができる． owl:maxCardinalityは， 上限を指定するために使うことができる． owl:minCardinalityと組み合わせることで， 範囲を指定することが可能になる．

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を辛口ワインと定義した．すなわち， hasSugarプロパティは少なくとも１つDryと等しい値を持たなければならない．

hasValueは，プロパティ制約の中でのみ使うことができる． owl:onProperty文は，制約されるプロパティを示す． allValuesFromとsomeValuesFromと同じように，これは局所制約であり， Burgundyに適用されたときにhasSugarに対して成立する．

オントロジ・マッピング

オントロジが最大の効果を発揮するためには，広く共有されている必要がある．オントロジ開発に費やされる知的努力を最小にするためには，オントロジを再利用する必要がある．全ての可能な世界の最良のもののなかでオントロジは構成される必要がある．例えば，ひとつのソースから時間のオントロジを採用し，他のソースから物理的位置のオントロジを採用して，占有する時間範囲を含むように位置の概念が拡張されるかもしれない．

オントロジを開発する努力の多くは含意が最大になるようにクラスとプロパティを結びつけることに費やされることを理解するのは，重要である．クラスのメンバーシップに関する単純な言明が，広範囲で有用な含意を持つことが望ましい．これがオントロジ開発の最も難しい部分である．もし広く使われて洗練された既存のオントロジが存在するのならば，それを採用するのは良い選択である．

KBが首尾一貫していることを保障するためには，ツール支援はほぼ必要不可欠である．

sameClassAs, samePropertyAs

構成要素となるオントロジの集まりを結合して第３のオントロジの一部にする際に，ひとつのオントロジの中の特定のクラスあるいはプロパティが他のオントロジのクラスやプロパティと等価であることを示せれば，しばしば有益である．この機能は，注意して使う必要がある．分散した定義の集合を結合する時に，必然的に空になる集合を作成することはきわめて容易である．もし結合されたオントロジが矛盾（すべてのAはBであるに対して，すべてのAはBではない）するものであれば，結合結果を満たす外延（個体と関係の集合）は存在しない．

食品オントロジでは，ダイニングコースの記述の中のワインの特徴をワイン オントロジへとリンクしたい．これを行うひとつの方法は，食品オントロジにクラスを定義して，それがワイン オントロジの既存のクラスと同一であることを宣言することである． 

<owl:Class rdf:ID="Wine">
  <owl:sameClassAs rdf:resource="&vin;Wine"/>
</owl:Class>

もちろん， #Wineのところでは&vin;Wineを使うことが可能であり，再定義なしに同じ効果が得られるので，上記の例は不自然である．もっとありそうな利用法は，２つの独立に開発されたオントロジにかかわり，同じクラスを参照するのに項O1:fooとO2:barが使われる場合である．２つのオントロジからの帰結が互いに補足しあうようにこれらをまとめるために， sameClassAsを使うことができる．

クラス式がsubClassOf構成子のターゲットになり得ることは，既に見た．クラス式はまた， sameClassAs [OWL DL] のターゲットになり得る．これは，一つ一つのクラス式に名前をつける必要を排除し，プロパティの充足性に基づく基づく強力な定義機能を提供する． 

<owl:Class rdf:ID="TexasThings"> 
  <owl:sameClassAs>
    <owl:Restriction>
      <owl:onProperty rdf:resource="#locatedIn" />
      <owl:allValuesFrom rdf:resource="#TexasRegion" />
    </owl:Restriction>
  </owl:sameClassAs>
</owl:Class>                                                 

TexasThingsは， まさにテキサス地域にある事物である．ここでsameClassAsを使う場合とsubClassOfを使う場合の違いは，必要十分条件と必要条件の違いである． subClassOfでは，テキサスに位置する事物は必ずしもTexasThingsではない．しかしsameClassAsを使うと，何かがテキサスに位置するならば，それはTexasThingsのクラスになければならない．

関係 含意
subClassOf TexasThing(x) → locatedIn(x,y) & TexasRegion(y)
sameClassAs   TexasThing(x) → locatedIn(x,y) & TexasRegion(y)
locatedIn(x,y) & TexasRegion(y) → TexasThing(x)

sameIndividualAs

このメカニズムはクラスのものに似ているが，２つの個体が同一であることを宣言する．例： 

<Wine rdf:ID="MikesFavoriteWine"> 
  <owl:sameIndividualAs rdf:resource="#StGenevieveTexasWhite" /> 
</Wine>                                                   

この例は，あまり有用ではない．ここから学べるほぼ全てのことは， Mikeはワインのしろうとであるということである．より典型的なsameIndividualAsの利用法は，２つのオントロジの統合の一部として，異なるドキュメントの中で定義された個体を相互に等しくすることである．

このことは，重要なポイントを明らかにする． OWLはユニークな名前付けを仮定していない．２つの名前が異なるというだけでは，それらが異なる個体を指すことを意味するわけではない．

上記の例では，２つの別個の名前の同一性を言明した．しかし，この種類の同一性は推論することができる．関数的なプロパティから導出できる含意を思い出してほしい． hasMakerが関数的であるならば，以下は必ずしも矛盾しない． 

<owl:Thing rdf:about="#BancroftChardonnay">
  <hasMaker rdf:resource="#Bancroft" />
  <hasMaker rdf:resource="#Beringer" />
</owl:Thing>                                              

単にBancroft = Beringerを意味しているだけかもしれない．

differentIndividualFrom

このメカニズムはsameIndivdualAsとは逆の効果を提供する． 

<WineSugar rdf:ID="Dry" />

<WineSugar rdf:ID="Sweet">  
  <owl:differentIndividualFrom rdf:about="#Dry"/>  
</WineSugar> 

<WineSugar rdf:ID="OffDry">
  <owl:differentIndividualFrom rdf:about="#Dry"/> 
  <owl:differentIndividualFrom rdf:about="#Sweet"/> 
</WineSugar>

これは，この３つの値が互いに異なることを言明するひとつの方法である．そのような相違の識別を保障することが重要な場合がある．これらの言明がなければ， DryかつSweetなワインを記述することができる．ワインに適用されたhasSugarプロパティが２つ以上の値を値を持たないことは，既に述べた．上記のdifferentIndividualFrom文がなくて，もし間違ってワインがDryでSweetであると言明すると，これはDryとSweetが同一であることを含意してしまう．上記の文があれば，これは矛盾を起こす．

複合クラス [OWL DL]

OWLはクラスを形成するための付加的な構成子を提供する．これらの構成子は，いわゆるクラス式を作るのに使うことができる． OWLは集合和，集合積，補集合という基本的な集合演算をサポートする．これらは順に， unionOf，intersectionOf，complementOfと表記される．さらに，クラスは列挙され得る．クラス外延は， oneOf構成子を使うことによって陽に記述可能である．また，クラス外延が素であることを言明することも可能である．

クラス式は，一つ一つの中間クラスに名前を与えることなく入れ子にできることに注意してほしい．このことにより， anonymousクラスや値制限を持つクラスから複合クラスを構成するのに集合演算を使うことができる．

集合演算子
intersectionOf, unionOf, complementOf [OWL DL]

OWLのクラス外延は集合なので， OWLは基本的な集合演算子を使ってクラスを操作する方法を提供する．

集合積 [OWL DL]

次の例は， 集合積の利用を示す． 

<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関係を持つワインをちょうど含むものと定義した．新しいクラス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はまさに白ワインとバーガンディの集合積である．バーガンディもまた，フランスのブルゴーニュ地域に成育し，かつ辛口ワインである．したがって，このような基準を満たす個体のワインは全て， WhiteBurgundyのクラス外延の一部となる．

Union [OWL DL]

次の例は， unionOfの利用を示す． 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の要素の集まりはあまい果物とあまくない果物の集合積の部分集合であることを言っており，空集合になるであろう．

Complement [OWL DL]

complementOfは，あるクラスに属さない個体全てを領域から選び出す．通常は，これは個体のたいへん大きな集合を表す： 

  <owl:Class rdf:ID="ConsumableThing" />

  <owl:Class rdf:ID="NonConsumableThing">
    <owl:complementOf rdf:resource="#ConsumableThing" />
  </owl:Class>

クラスNonConsumableThingは， ConsumableThingの外延に属さない全ての個体をメンバとして含む．この集合は，全てのWineやRegionなどを含む（訳注：WineはConsumableThingのサブクラスのサブクラスなので，Winery誤りではないか？）．内部的には， 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>                                              

これは， Franceに位置していない全ての事物とWineの集合積として，クラスNonFrenchWineを定義する．

列挙クラス
oneOf [OWL DL]

OWLは，メンバを直接列挙することによってクラスを定義する方法を提供する．これはoneOf構成子を使って行うことができる．特に，この定義はクラス外延を閉じて，他の個体がこのクラスに属すると宣言できなくする．

次の文は，個体White，Rose，RedをメンバとするクラスWineColorを定義する． 

<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を利用する．その代わりに，次のように集合の要素を特定の型，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">
  <rdf:label>White</rdf:label>
</WineColor>

素なクラス
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を言明する必要がある．

互いに素なサブクラスの集まりの合併としてクラスを定義したいというのは，普通にある要求である． 

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

ここでは，まさにSweetFruitとNonSweetFruitの合併としてFruitを定義した．さらに，これらのサブクラスは素であるから， Fruitをちょうど２つに分割するものであることが分かる．互いに素なサブクラスの数が増えると，素の表明はn2に比例して増加する．しかし，今まで我々が見た利用例ではnは一般に小さい．

使用例

最初のドメイン・オントロジが利用できるようになれば，それを活用する多くのアプリケーションを開発することができる．このセクションでは，ワインのドメインでのいくつかの使用例を述べる．

ワイン ポータル

今日，ワイン ポータルを自称するサイトはいくつもある．例えば，Googleで"wine portal"を検索すると152,000のマッチがある．上位にマッチするものの一つである "Wine-Portal.com" と呼ばれるサイトは，いくつかのサイトへのアクセスを提供する．ワイン ポータルを主張するサイトの多くは，主に情報サイトである．例えば， wine-portal.comに最初に掲載されている'cork cuisine'（ http://www.corkcuisine.com/）と呼ばれるサイトは，ワインと料理の相性や贈り物としてのワインなどの情報を提供している． "the Internet Wine Portal"（ http://www.cyberbacchus.com/）と広告しているもう一つのサイトは，多くの話題についてたくさんのワイン情報を魅力的に編成して提供している．

トピック エリアのどれかをよく読むことで，情報や，時には話題に関連したサービスを含むページの集まりを見つけ出すことができる．例えば，「アクセサリとギフト」には，特別なワインを買うときに何を探せばよいかの情報と，多くのオンライン小売商が含まれている．「ショッピング」というもう一つのトップレベルのエリアには「ワインショッピング」というエリアがあり，そこから（国でカテゴライズされた）オンライン（あるいは「ストリート ショッピング」）ストアを探すことができる．これら２つのサイトは，今日ある数多い例の２つに過ぎず，特定のトピック エリアに関連した情報やサービスの集まりを提供するワイン ポータルの一般的な概念を代表するものである．

これらのサイトをある詳細度で見ても，今のところオントロジがどのくらい使われているかが明確ではない．例えば， htmlソースを眺めてもオントロジ的な利用の証拠は明らかにならない．しかしながら，何らかのワイン・オントロジが利用できるならば，そのようなサイトがオントロジを活用することは明らかである．

ポータルサイトでのオントロジの簡単な利用法の一つは，編成とブラウジングへの適用である．上記のカテゴリのリストは，ワインに関連するクラスの上位のわずかなレベルから生成することができる．問い合わせの際に，ワインに関連した情報を引き出すためにワイン・オントロジを活用することができる．オントロジに含まれる用語の検索に対しては，より適切な答えを見つけるためにサブクラス情報を使って問い合わせを拡張することができる． トピック エリアの情報（候補）を使ってポータルが自動的に更新されるように，ポータルを作ることも可能であろう．とても強力な推論機能があれば，適当なワイン販売サイトを見分けてポータルの一部として参加するよう交渉することさえできるであろう．

ワイン エージェント

我々は，説明的な目的でワイン エージェントをはじめた．最初の設計では，ワイン エージェントは食事のコースに合わせたワインの推薦を目的としていた．このアプリケーションは，このドキュメントが基礎として使っているオントロジを活用する．ワイン オントロジは， DAMLライブラリから wines という名前で利用可能である．

パーソナライズしたワイン エージェントは，いくつかのサービスを人に提供することができる．
一連の条件（供される食事など）を与えてワインを推薦したり，特定のワインや特定の種類のワインに関する情報を見つけたり，ワインに合うアクセサリ（そのワインの種類に合った特定の種類のグラスなど）を探したりするのに，エージェントが使われるかもしれない．

以下では，学生プロジェクトとして書かれている簡単なプロトタイプシステムからの例を述べる．

次のシナリオを考える：

ある人がワインパーティを計画している．ゲストの少なくとも一人は，ワインについて見識がある．ホストは，メニューのコースに適したワインを供したいと考えている．また，ホストはイベントで供されるワインについて見識があるように思われたいとも考えている．さらに，ホストはディナーに適切なアクセサリも用意しておきたい．メインコースには，トマトベースのスペシャル パスタソースと生パスタが供されることが決まっている．

食事に合ったワインを供するためには，ワインと食材の組み合わせに関する情報が必要である．ワインについて見識があるように見えるためには，イベントにかかわるワイン情報にアクセスして利用すると有益であろう．適切なワイン アクセサリを用意するためには，どのアクセサリが状況（とホストの財布）にあっているかに関する情報が必要である．

背景となるワイン オントロジがあれば，食事の説明が与えられることで，ワイン エージェントは食事とともに供されるワインの種類を提案することができる．ワイン エージェントは，食事に合ったワインの種類のチョイスとしてジンファンデルを提案するかもしれない．さらに，バックグラウンド・オントロジが与えられていれば，ワイン エージェントは特定のジンファンデル，ことによるとマリエッタ ジンファンデル，を提案するかもしれない．ワインがジンファンデルであるべきだという情報が与えられれば，ワイン エージェントは，ジンファンデルのセレクションか，選び出したマリエッタのような特定のジンファンデルを入手できる場所を探す．ワイン購入のための適当な情報源（できればホストの場所とワイン販売者の場所で選別した）を含むバックグラウンド・オントロジが与えられれば，ワイン エージェントは wine.com のようなサイトへ行ってジンファンデルを探し，そのサイトで売られているジンファンデルの リスト を返すことができるであろう．ワインエージェントは マリエッタ ジンファンデル をワイナリや小売業者から探そうとすることができるであろう．（Googleの検索や選択されたwebサイトの構造的な検索によって）例えば， winelibrary.comがマリエッタ ジンファンデル1999ビンテージを格安価格$13.99で売っていることを見つけられるかもしれない．ワイン エージェントは，ワイン種別に基づく適正価格や消費者から与えられた価格範囲のような付加的なフィルタリング情報を利用することができるかもしれない．

ここで，ワイン エージェントはジンファンデル一般あるいは特にマリエッタ ジンファンデルに関する情報を提供しようとするかもしれない．特定のワインに関する情報を見つけるために，ワイン サイトのバックグラウンド・オントロジを利用できるかもしれない．例えば，ワイナリの 1999ジンファンデル に関する記述が使えるかもしれない．さらに， Wine Spectator のような関連する情報源からのレビューが使えるかもしれない．好みのワインレビューサイトにマリエッタ ジンファンデルのレビューがない場合，同じ地域のジンファンデル，この場合にはカリフォルニアのソノマ カントリーのジンファンデル，のレビューのように関連する情報を探すと役に立つかもしれない．

一般の背景情報もまた役に立つであろう．ホストは，ワイン一般あるいは特にジンファンデルに関する本に関心を持ち，読みたいと思うかもしれない．例えば， Amazon.comが 販売 しているジンファンデルの本に関心を持つかもしれない．また，ホストは同じ地域のワインに関する情報に関心を持ち，その結果ソノマ ジンファンデルに興味を引かれるかもしれない．ワイン エージェントは，専門とする知識領域に関連した代表的な背景情報も，利用可能なものとして持っているかもしれない．例えば，このワイン エージェントは食材とワインの相性に関連しているので， Wine Spectatorの 食材とワインの相性 の記事のような，この話題に関する無料有料どちらの情報も持っているかもしれない．

ディナーのホストはまた，イベントに先立ってワイン アクセサリを入手したいと考えるかもしれない．ワインはワイングラスで供され，異なった種類のワインは別々の種類のグラスで供されるのが最も良い．例えば，ジンファンデルが合う料理コースをホストが選んだ場合， リーデル が良く知られたワイングラス製作所であることを知っていると良いかもしれない．また， Wine Enthusiast（ワイン商品の良く知られた供給者）にリンクすると， Wine Enthusiastが リーデルのヴィノム ジンファンデル グラス を４脚セットで$63.95（４個セットを２つ買う場合には$59.95に値引き）で売っていることが分かるかもしれない．また， Amazon.comでは リーデルのソムリエ ジンファンデル単脚グラス が$49.99（リストプライスは$65.00）で買えることを知っていると良いかもしれない． Amazonはまた，同じヴィノム グラスを６脚（wine enthusiastの４脚の代わりに）セットで$79.99（リスト プライスは$119.40）で売っている．ワインエージェントは料理に合わせた（すなわち，ジンファンデルを供するのに適当な）ガラス製品の比較表を提供し，価格その他のオントロジ中のプロパティのリストから選んだ基準で比較できるようにすることが可能かもしれない．

ディナーのホストは，他にもワイン アクセサリを用意したいと考えるかもしれない．オントロジから，コルク栓抜きがワイン アクセサリであることが分かる．バックグラウンド・オントロジはコルク栓抜きのサブクラスあるいはそのような情報を，関連するワイン サイトからも同様に見つけられるようにコード化しているかもしれない． Wine Enthusiastには 推奨 する コルク栓抜き のリスト（型と価格帯の説明も一緒に）がある．また， Wine Enthusiastはコルク栓抜きを型（レベル，ウェイター，ステーショナリ，ツイスト，ポンプ）で分けているので，ディナーホストはこれらのスタイルに関する情報を欲しがるかもしれない．

ワイン エージェントは，ドメインや情報のバックグラウンド・オントロジ知識やサービス・サイトに依存した数多くのレベルの素養にかかわるかもしれない．この例では，我々はワイン，種別，食材とワインの組み合わせ，ワイン アクセサリと関連する特性に関する情報についてのみ開発した．もちろん，より多くの情報と顧客による制約を含むように，これを拡張することが可能であろう．

より発展したワイン エージェントの例は，すぐに 利用できる ようになるであろう．

謝辞

このドキュメントは，多くの人々，特にW3C Webオントロジ・ワーキンググループ メンバ ，の作業を集約したものである．付録Bはアムステルダム大学のGuus Schreiber， mailto:schreiber@swi.psy.uva.nl，による． DAML+OIL Walkthrugh からは重要な洞察を得た． Jeremy Carroll，Jeff Heflin，Leo Obrst，Peter F. Patel-Schneiderは，有益なレビューをしてくれた． 2002年10月8日に開かれたワーキンググループのフェイス・ツウ・フェイスミーティングで， Stephen Buswell，Ruediger Klein，Enrico Motta，Evan Wallaceは，大きく変更したオントロジのレビューをしてくれた．

参考文献

OWL関連

Requirements
Requirements for a Web Ontology Language. W3C Working Draft, 08 July 2002.

Feature List
Feature Synopsis for OWL Lite and OWL. Deborah L. McGuinness and Frank van Harmelen. W3C Working Draft, 29 Jul 2002.

Reference
OWL Web Ontology Language 1.0 Reference. Mike Dean, Dan Connolly, Frank van Harmelen, James Hendler, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Working Draft, 29 July 2002.

XML Syntax
[@@ ref]

UML Syntax
[@@ ref]

Abstract Syntax
OWL Web Ontology Language 1.0 Abstract Syntax. Peter F. Patel-Schneider, Ian Horrocks, and Frank van Harmelen. W3C Working Draft 29 July 2002.

Formal Model
Model-Theoretic Semantics for OWL to appear

Sample Ontologies and Applications

Daml.org Wine Ontology
http://www.daml.org/ontologies/76

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 John Sowa, ed., Principles of Semantic Networks: Explorations in the representation of knowledge, Morgan-Kaufmann: San Mateo, California, 1991, pages 401--456.
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


オントロジ研究関連

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
Daml Home Page

DAML-ONT
DAML-ONT initial release
DAML-ONT Partial DAML-ONT axiomatization in KIF

OIL
OIL Home Page

Ontoknowledge
Ontoknowledge Home Page

SHOE
Simple HTML Ontology Extensions (SHOE) home page. University of Maryland.

Ontobroker
The Ontobroker home page. Institute AIFB, University of Karlsruhe.

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

OML/CKML
The Conceptual Knowledge Framework: OML/CKML. Kent, Robert. KAW'99, Twelfth Workshop on Knowledge Acquisition, Modeling and Management, Voyager Inn, Banff, Alberta, Canada, October 16-21, 1999.

OKBC
OKBC: A programmatic foundation for knowledge base interoperability, V. K. Chaudhri, A. Farquhar, R. Fikes, P. D. Karp, and J. P. Rice. In Proceedings of the 15th National Conference on Artificial Intelligence (AAAI-98), pages 600?607. AAAI Press,1998.

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

W3C標準関連

RDF
Resource Description Framework (RDF) Model and Syntax Specification. World Wide Web Consortium Recommendation, 1999 Lassila, Swick [eds].

RDF: Resource Description Framework. Background at W3C.

RDFS
RDF Vocabulary Description Language 1.0: RDF Schema. W3C Working Draft 30 April 2002.

XML
Extensible Markup Language (XML) 1.0

XML Tutorial 1: Well-Formed XML Documents. Bonnie SooHoo Aug 4, 2000 in webreview.com.

Extensible Markup Language (XML). More background at W3C.

XML Schema
W3C XML Schema

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

Web Naming and Addressing Overview (URIs, URLs, ...). More background at W3C.

XML Namespaces
Namespaces in XML. W3C Recommendation Jan 1999.

XML Namespaces by Example. Tim Bray Jan. 19, 1999 in XML.com.

Namespace Myths Exploded. Ronald Bourret. March 8, 2000 in XML.com.

XML Base
XML Base. W3C Recommendation

一般

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.

Description Logic Web Page

Knowledge Representation and Ontology
Dublin Core Metadata

Expressing Dublin Core in RDF/XML

KR Home Page

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

Controlled Vocabularies
Mind your phraseology! Using controlled vocabularies to improve findability. DigitalWeb Magazine, Christina Wodtke

付録A ：XML + RDFの基礎

この付録は， OWLが依存する標準の入門へのリンクを提供する．

OWLの構文と意味論を完全に理解するためには，以下にあげるW3CとIETF標準の基礎を良く知る必要がある．最初の２つのリンクは， XMLとRDFの最小限のガイドである．

付録B ：歴史

Resource Description Framework (RDF) は，任意のリソースに関する意味情報を表現するためにW3Cが規定した最初の言語である． RDF Schema (RDFS) は， RDFの語彙を記述するためのRDF拡張のW3C candidate recommendationである． RDFSはオントロジを作るのにも使えるが，意図的に軽量にしてあり， OWLより表現力が弱い．

RDFSには， OWLのようなクラスとプロパティ，プロパティの定義域や値域の制約が含まれる．また，クラスやプロパティの継承階層を提供する． RDFSがリリースされると，利用者はデータ型，列挙，プロパティをより厳密に定義する機能など，さらなる機能を要求し始めた．

研究コミュニティの一部では，既にこの種の機能を調査しているところだった．この背景を深く探求したい人は，プロジェクトと言語に関する以下の部分リストを参照：

OILとDAML-ONTの両方の主要メンバの多くを含む研究者のグループは，セマンティックWebのための別々のオントロジ言語を存続させる代わりに，新しいwebオントロジ言語を作ろうと Joint US/EU ad hoc Agent Markup Language Committee に集まった．この言語 DAML+OIL はOILとDAML-ONTの両方の上に構築され， W3CにOWLのベースとして サブミット されて，その後OWLの出発点になった．

オントロジ言語に加えて，さまざまな分類や既存のオントロジがもう広く使われている． e-コマース サイトでは，それらは売り手と買い手のマシンベースのコミュニケーションを促進し，市場の仮想的な統合を可能にし，違う市場で再利用されるための記述を可能にする．オントロジを実際の商業利用で使っているサイトは：

一つに結合し凝縮することが困難な，現代の医療や生化学研究の圧倒的な量のデータを管理するために，医療や薬品関連のさまざまなオントロジが開発されてきた．主要なリソースの一つは， Gene Ontology Consortium であり，次のオントロジを定義している．

そのサイトは，次のオントロジのためのポインタも持っている．

今日使われている大きな分類で， OWLの空間に拡張できそうなものもある．例えば， the North American Industry Classification System (NAICS)は業種を定める1900を超える要素の階層を定義する． NAICSはまた，国連で開発され保守されているthe International Standard Industrial Classification System (ISIC, Revision 3)とも結び付いている．

付録C：もう一つの地域オントロジ

この例はGuus Schrieber [ W3C WG Archive ]によって開発され，より精巧なワイン地域オントロジを与える．

ワインにとって，「生産地」は重要な特性である．国全体からワイン園まで，生産地の粒度によってワインのタイプには大きな違いがある．生産地の４つの型を区別することができる：

  1. 国：例えば，フランス，イタリア
  2. 地域：例えば，ボルドー，メドック，トスカーニ
  3. 町：例えば，マルゴー, Montalcino, Montepulciano
  4. ワイン園，例えば，シャトー マルゴー, アヴィニョネージ

さらに，生産地のさまざまな種類の間のpart-of関係をモデル化する必要がある：

我々は，ワインKBから，シャトー マルゴーはフランス ワインであり，アヴィニョネージはトスカーナ ワインであることを導出できるようにしたい．

モデリングの方針：ここで，「町」サブクラスを落とし，町を地域として扱うことに決めた．これによってモデルは単純になるとともに，ワイン生産地としての「町」は一般には町の周辺の一帯を表し，実際の町域よりも大きくも小さくもなり得るという事実とも整合する．例えば，生産地「Montalcino」は実際にはMontalcino村を取り囲むトスカーニ地域の一部である．

このことから，以下のモデルが導かれる：

Classes:

<owl:Class rdf:ID="&vin;ProductionArea"/ >
<owl:Class rdf:ID="&vin;Country:">
    <rdfs:subClassOf rdf:resource="&vin;ProductionArea"/>
</owl:Class> 
<owl:Class rdf:ID="&vin;Region:"> 
    <rdfs:subClassOf rdf:resource="&vin;ProductionArea"/> 
</owl:Class> 
<owl:Class rdf:ID="&vin;Vineyard:"> 
    <rdfs:subClassOf rdf:resource="&vin;ProductionArea"/> 
</owl:Class>
Triples
vin:ProductionArea rdf:type rdfs:Class.
vin:Country rdfs:subClassOf vin:ProductionArea.
vin:Region rdfs:subClassOf vin:ProductionArea.
vin:Vineyard rdfs:subClassOf vin:ProductionArea.

Properties:

<owl:ObjectProperty rdf:ID="&vin;hasSubArea">   
  <rdf:type rdf:resource="&owl;TransitiveProperty" />
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;subAreaOf">   
    <owl:inverseOf rdf:resource="&vin;hasSubArea"/> 
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;hasRegion">   
    <rdfs:subPropertyOf rdf:resource="&vin;hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="&vin;Region"/>
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;regionOf">   
    <owl:inverseOf rdf:resource="&vin;hasRegion"/> 
    <owl:allValuesFrom rdf:resource="&vin;Country"/>
    <owl:cardinality>1</owl:cardinality>
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;hasSubRegion">   
    <rdfs:subPropertyOf rdf:resource="&vin;hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="&vin;Region"/>
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;subRegionOf">   
    <owl:inverseOf rdf:resource="&vin;hasSubRegion"/> 
    <owl:allValuesFrom rdf:resource="&vin;Region"/>
    <owl:cardinality>1</owl:cardinality>
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;hasVineyard">   
    <rdfs:subPropertyOf rdf:resource="&vin;hasSubArea"/> 
    <owl:allValuesFrom rdf:resource="&vin;Vinyard"/>
</owl:ObjectProperty>  

<owl:ObjectProperty rdf:ID="&vin;vineyardRegion">   
    <owl:inverseOf rdf:resource="&vin;hasVineyard"/> 
    <owl:allValuesFrom rdf:resource="&vin;Region"/>
    <owl:cardinality>1</owl:cardinality>
</owl:ObjectProperty>
Triples
  
vin:hasSubArea rdf:type rdfs:Property.  
vin:hasSubArea rdf:type owl:TransitiveProperty. 
vin:subAreaOf owl:inverseOf vin:hasSubArea. 

vin:hasRegion rdfs:subPropertyOf vin:hasSubArea.
vin:hasRegion owl:allValuesFrom vin:Region.
vin:regionOf owl:inverseOf vin:hasRegion.
vin:regionOf owl:allValuesFrom vin:Country.
vin:regionOf owl:cardinality 1.

vin:hasSubRegion rdfs:subPropertyOf vin:hasSubArea.
vin:hasSubRegion owl:allValuesFrom vin:Region.
vin:subRegionOf owl:inverseOf vin:hasSubRegion.
vin:subRegionOf owl:allValuesFrom vin:Region.
vin:subRegionOf owl:cardinality 1.

vin:hasVineyard rdfs:subPropertyOf vin:hasSubArea.
vin:hasVineyard owl:allValuesFrom vin:Vineyard.
vin:vineyardRegion owl:inverseOf vin:hasVineyard..
vin:vineyardRegion owl:allValuesFrom vin:Region.
vin:vineyardRegion owl:cardinality 1.

オントロジに関する注釈：ここで述べた部分-全体関係は，フォーマル-オントロジ研究では良く知られている． Winston他 による部分-全体関係の分類では，これは「場所-地域」関係と特徴付けられる．もしフォーマル-オントロジ コミュニティが何らかの点でOWLで部分-全体分類を利用可能にできたら，このワイン オントロジのプロパティはそれにリンクすることができる．

UMLに関する注釈：この例のUMLクラス図を次にあげる．この図のモデル化の方針は， UML表現構文に関する将来のドキュメントで議論されるであろう．ここでは， UMLの「composition」構成要素（黒塗りのひし形）が，場所-地域関係の意味のいくらかを表していることに注意してほしい．

Owl Production Area UML Diagram