この標準仕様書(TS)は，2004年2月にWorld Wide Web Consortium (W3C)から公表されたWeb Ontology Language, Guideを翻訳し，技術的内容を変更することなく作成した標準 仕様書(TS)である。
現在のワールドワイドウェブは，貧弱な地図しかない地形に似ている。文書を識別しそれを利用する能力は，キーワード検索に基づくものであって，文書のつながり及び利用パターンを巧妙に用いることによって遂行されている。効果的なツールの支援がない場合，大部分のデータの扱いは困難になる。この地形をより精緻な地図にするために，コンピュータのエージェントは，計算機が読み取れるように記述された内容及びウェブアクセス可能な資源を必要とする。これらの記述は，その情報の人間可読な版に追加されなければならない。
OWLウェブオントロジ言語は，ウェブ文書及びアプリケーションに潜在的に備わっているクラス及びクラス間の関係を記述するために使用できる言語の提供を意図している。
この標準仕様書(TS)は，OWL言語の次に示す内容を規定し，その使用法を示す。
各節は，クラス，特性及び個体の集合の定義を追加しながら表現するように構成され，基本から始まり，より複雑な言語構成要素へと進む。
“次の食事メニューの各コースに供するためにどのワインを買ったらよいか教えて欲しい。ただし，ソーテルヌは好まない。”
現在，ウェブ上でワインに関する検索を実行して，この問いに満足できる答えを出すウェブエージェントを構成するのは難しい。同様に，実際に，ソフトウェアエージェントに一貫した一連の旅行手配作業を作成する仕事を割り当てる場合を検討してみるのもよい。より多くの利用事例については，OWL 要件規定を参照されたい。
この種の計算を支援するためには，キーワードを越えて，ウェブ上に記述された資源の意味を指定することが必要になる。この解釈のために追加される層は，データの意味を把握する。
OWLウェブオントロジ言語は， ウェブオントロジを定義し，そのインスタンスを生成するための言語とする。オントロジとは，哲学から借りた用語であって，世界に存在する実体の種類，及びそれらがどのように 関連付けられるかを記述する科学に由来する。OWL オントロジは，クラス, 特性及びそれらのインスタンスの記述を含む。 こうしたオントロジを仮定することによって，OWLの形式意味論は，その論理的帰結，すなわち，オントロジの中にそのままでは存在せず，意味論によって論理的に導かれる事実，をどのように導き出すかを規定する。 これらの論理的帰結は，単一の文書に基づいてもよく， 定義済みのOWL機構によって結合された複数の分散文書に基づいてもよい。
この標準仕様書(TS)は，OWLというウェブオントロジ言語の記述における構成要素の一つであって，W3C ウェブオントロジ作業グループ(WebOnt)によって作成された。OWL 概要([Overview]の1.1)の規定一覧では，記述の異なる部分のそれぞれ及びそれらがどのように組み合わされているかを示している。
別のXML/Web規格を規定するとき，“このXML/Web規格によって得られて，XML及びXMLスキーマでは 得られないものは何か。”という疑問が生じる。 この疑問に対する答えは，次の二つになる。
OWLは，特定の実装者及び利用者が使用するために設計された，段階的に表現力が増す三つの下位言語を提供する。
OWL Liteは，主に分類階層及び簡単な制約を必要とする利用者を支援する。例えば，OWL Liteは，メンバ数の制約をサポートする一方で，メンバ数の値は0又は1しか認めない。OWL Liteに対するツール支援は，より表現力のある他の言語サブセットよりも簡単になる。OWL Liteは，シソーラス及び他のタクソノミに対して迅速な移行手順を提供する。
OWL DLは，計算完全性(すべての結論が計算可能であることが保証されている)，及び決定可能性(すべての計算が有限時間内に終了する)を保持しつつ，最大の表現力を要求する利用者をサポートする。OWL DLにはOWL言語のすべての構成要素が含まれるが，その使用には一定の制限がある。例えば，あるクラスは複数のクラスの下位クラスであってもよいが，他のクラスのインスタンスにはなり得ない。OWL DLは，記述論理[Description Logics]という一階述語論理の特定の決定可能な部分を研究する分野との対応から，DLと名前付けされている。 OWL DLは，記述論理が使われてきた既存の分野を支援するために設計されたが，推論システムのために望ましい計算特性をもつ。
OWL Fullは，最大の表現力及び計算上の保証を伴わないRDFの構文の自由を要求する利用者を対象とする。例えば，OWL Fullでは，一つのクラスを個体の集まりとして扱うと同時に ，それ自体を一つの個体として扱うことができる。 OWL DLと他との一つの重要な相違点は，owl:DatatypePropertyをowl:InverseFunctionalPropertyとしてマーク付けできることにある。 OWL Fullによって，オントロジは，定義済みのRDF又はOWLの語い(彙)の意味を増強することが可能となる。どのような推論ソフトウェアであっても，OWL Fullのすべての機能に対する完全な推論をサポートできるというわけではない。
これらの各下位言語は，何を正当に表現できるかという点においても，何を妥当に結論付けできるかという点においても，その一つ前のより単純な下位言語を拡張したものになっている。次の一連の関係は成立するが，その逆は成立しない。
OWLを採用するオントロジ開発者は，どの下位言語が自分の要求事項に最も合うかを考慮することが望ましい。OWL Liteを選択するかOWL DLを選択するかは，利用者が，OWL DLが提供するOWL Liteより表現力のある構成要素をどの程度必要としているかによる。 OWL Liteの推論機構は，望みどおりの計算特性をもつ。OWL DLの推論機構は，決定可能な下位言語を扱いつつも，最悪の場合，より困難な複雑性に支配されかねない。OWL DLを選択するかOWL Fullを選択するかは，主に，利用者が，クラスのクラスを定義するなど，RDFスキーマのメタモデル化 機能をどの程度必要としているかによる。OWL Fullを使用する場合は，OWL DLと比較して，推論支援の予測可能性が低くなる。 この問題に関する詳細は，OWL 意味論規定を参照すること。
RDFからOWL DL又はOWL Liteへ移行する利用者は，元のRDF文書がOWL DL及びOWL Liteが課す制約に 確実に従っていることに注意を払う必要がある。これらの制約に関する詳細については，OWL 機能一覧(TS X 7253)の附属書Eを参照されたい。
この規定の中で，OWL DL又はOWL Fullだけで許される構成要素を導入する場合, それらを“[OWL DL]”とマーク付けする。
手引全体を通じて一貫性のある例を提供するために，ワイン及び食品のオントロジを作成した。これは，OWL DLオントロジである。ここでの記述の幾つかは，OWL Fullの能力に焦点を当てることになるが， その場合は，そのようにマーク付けをする。 ワイン及び食品のオントロジは，長い歴史をもつDAMLオントロジライブラリの一つの要素を大幅に変更したものである。 これは，元々，McGuinnessによってCLASSIC記述論理の例として開発されたものであって，記述論理の解説用に拡張され，さらに，オントロジの解説用に拡張された。
この規定では，RDF/XML構文([RDF], 5)を使用して例を表示し，XMLが大半の対象者にとってよく知られた言語になっていると想定する。規定としてのOWL交換構文は，RDF/XMLとする。OWLがRDF及びRDFスキーマに最も互換性をもつものとして設計された点に注意されたい。これらのXML及びRDFの書式は，OWLの規定の一部とする。
この規定で表示される例は，すべてwine.rdf及びfood.rdfに含まれるオントロジから採用されている。ただし，右下の隅に， ¬ でマーク付けされたものは除く。
OWLは，セマンティクウェブ活動の構成要素といえる。 この活動は，ウェブコンテンツを記述又は提供する資源に関する情報を追加することによって，ウェブ資源を，自動化された処理に対してより容易にアクセス可能とすることを目的とする。 セマンティクウェブは，本来分散されるものなので，OWLによって，分散された情報源から情報を集めることができなければならない。 これは，他のオントロジから情報を明示的に取り込むことを含むオントロジの関連付けを可能にすることによって，部分的に実行される。
さらに，OWLは，開かれた世界を前提とする。すなわち，資源の記述は，単一のファイル又は有効範囲に限定されない。 クラスC1は，元々オントロジO1で定義されていてもよいが，他のオントロジでそれを拡張することができる。 C1に関するこれらの追加的な命題の結論は，単調とする。 すなわち，新しい情報が，以前の情報を撤回することはできない。 新しい情報は，矛盾を含む可能性があるが，事実及び論理的帰結は，追加だけが可能であって，削除はできない。
こうした矛盾の可能性は，オントロジ設計者が考慮する必要のあるものとする。 ツールによる支援が，こうした事例の検出に役立つことが期待される。
あいまい性なく解釈可能であってソフトウェアエージェントによって使用可能なオントロジを書くために，OWLに対して構文及び形式意味論を要求する。OWLは，RDFの語い(彙)の拡張 [RDF Semantics]とする。 OWLの意味論は，OWLウェブオントロジ言語 意味論及び抽象構文(TS X 7254)の中で定義される。
一連の用語を使用可能とする前に，どんな固有の語い(彙)が使用されているかを正確に示す必要がある。 オントロジの標準的な初期構成要素は，rdf:RDFで開始されるタグで囲まれた 一連のXML 名前空間宣言を含む。 これらは，識別子をあいまいさ無しに解釈し， 残りのオントロジ表示をさらに読み易くする手段を提供する。 典型的なOWLオントロジは，次のような名前空間宣言で始まる。 もちろん，定義済みのオントロジのURI (Uniform Resource Identifier, 統一資源識別子)は，通常は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#">
最初の二つの宣言は，このオントロジと関連する名前空間を識別する。最初の宣言は，それをデフォルトの名前空間とし，接頭辞のない修飾名が現在のオントロジを参照することを示す。2番目の宣言は，接頭辞にvin:をもつ現在のオントロジの名前空間を識別する。3番目の宣言は，この文書の基底URIを識別する(以降を参照)。4番目の宣言は，接頭辞にfood:をもつサポートする食品のオントロジの名前空間を識別する。
5番目の名前空間宣言は，この標準仕様書では，接頭辞にowl:をもつ要素が，http://www.w3.org/2002/07/owl#と呼ばれる名前空間からもってきたものを参照すると理解されるのが望ましいことを表す。
これは，慣習的なOWL宣言であって，OWL語い(彙)の導入に使用される。
OWLは，RDF，RDFS及びXMLスキーマデータ型によって定義される構成要素に依存する。
この標準仕様書では，接頭辞rdf:は，http://www.w3.org/1999/02/22-rdf-syntax-ns#と呼ばれる名前空間からもってきたものを参照する。
次の二つの名前空間宣言は，RDFスキーマ(rdfs:)及び
XMLスキーマデータ型(xsd:)の名前空間に関して，類似の宣言をしている。
長いURLを書く場合の手助けとして， オントロジ定義に先行する文書型宣言(DOCTYPE)の中で実体定義の集合を提供することが，有用なことが多い。 名前空間宣言によって定義される名前は，XMLタグの一部として意味があるにすぎない。 属性値は，名前空間の影響を受けない。しかし，OWLでは，属性値を使用して， オントロジ識別子を参照する場合が多い。それらは，完全に展開された形式で書き下すことができる。"http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot"は，その例である。 その代わりに，ENTITY定義を使用して，短縮形を定義することもできる。 次にその例を示す。
<!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#" > ]>
この一対のENTITY宣言の後では，値"&vin;merlot"を書くことができ，それは，"http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot"に展開される。
さらに重要なのは，rdf:RDF名前空間宣言は単純化でき，その結果，実体宣言の変更がオントロジを通じて一貫して伝搬することであろう。
<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においては，オントロジという用語は， インスタンスデータを含むように拡張された(1.を参照)。
rdf:about属性は，オントロジに関する名前又は参照を提供する。属性値が""であるところでは，つまり標準的な場合には，オントロジの名前は，owl:Ontology要素の基底URIとなる。典型的には，これは，オントロジを含む文書のURIになる。 この例外は，xml:baseを使用する文脈であって，それは，要素の基底URIを現文書のURI以外の何かに設定する。
rdfs:commentは，オントロジに注記をつけるために明らかに必要な機能を提供する。
owl:priorVersionは，オントロジと連携して動作する版管理システムのためのフックを提供することを意図した標準タグとする。 オントロジ版管理については，以降に詳細を示す。
owl:importsは，取込み方式の機構を提供する。owl:importsは，単一の引数を取り， その引数は，rdf:resource属性によって識別される。
他のオントロジの取込みは，そのオントロジが提供する表明の集合全体を現在のオントロジにもち込む。 この取り込まれるオントロジを最も効果的に使用するために， 通常，それを名前空間宣言と組み合わせる。 これら二つの機構の相違点に注意されたい。 名前空間宣言は， 他のOWLオントロジで定義された名前を参照するための便利な手段を提供する。 概念上は，owl:importsは， 対象オントロジの表明を取り込むという意図を示すために提供される。 他のオントロジ，02を取り込むことは，02が取り込むすべてのオントロジをも取り込む。
owl:importsが常に成功するわけではないことに注意されたい。 セマンティクウェブを扱う際には予期されることだが， ウェブをまたがって分散された資源にアクセスすることは，常に可能なわけではない。 ツールは，実装定義の方法でこの状況に対応する。
OWL語い(彙)を使用するためには，owl.rdfオントロジを取り込む必要はないということに注意されたい。実際，このような取込みは勧められない。
取り込むことが妥当と思われる追加タグの一つの共通的な集合は， 標準的なDublin Coreメタデータタグの幾つかとする。 その部分集合は，値として単純型又は文字列を取るものを含む。その例に， 題(Title)，作成者(Creator)，記述(Description)，発行者(Publisher)及び 日付(Date)がある。RDF宣言を参照されたい。
注記として使用される特性は，owl:AnnotationPropertyを使用して宣言されることが望ましい。 次に例を示す。
<owl:AnnotationProperty rdf:about="&dc;creator" />
OWLは，現在のオントロジ及び取り込まれたオントロジを一緒にして結合する機構をほかにも幾つか提供する。 オントロジマッピングを参照されたい。
オントロジに関する自然言語のラベルをサポートするのに，rdfs:labelもある。
オントロジヘッダ定義は，次のタグで終了する。
</owl:Ontology>
この前書きとしての記述の次に，オントロジを構成する実際の定義が続き，最後は次で終了する。
</rdf:RDF>
複数の文書中に現れるインスタンス群のオントロジ情報を表現するOWLの機能は， 様々な情報源からのデータの結合を一貫した手法で支援する。 予期しない結果を生じ得るこれらデータにおける推論を， 基礎となる意味論は，提供し支援する。 特に，owl:sameAsを使用して等価性を表現する能力は， 表面上異なる個体が実際には同一であると示すために使用できる。Owl:InverseFunctionalPropertyも個体を互いに結合するために使用できる。 例えば，"SocialSecurityNumber"といった特性が owl:InverseFunctionalPropertyである場合， その特性の値が同じであることに基づき， 二つの(一見は)別々の個体が同一であると推論することができる。 個体がこれらの方法によって同一と決定された場合， 異なる情報源から得られたそれらに関する情報を併合することができる。 この集約関係の使用を通じて， 一つの情報源からは直接的に表現されない事実を決定できる。
複数の情報源からの情報を結合するセマンティクウェブの機能は，多くのアプリケーションで使用できる望ましい強力な特徴である。 しかし，複数の情報源から得たデータをOWLの強力な推論機能を用いて併合する能力は， 誤用される可能性をもつ。OWLの利用者は，プライバシを犯す可能性を含んでいることに注意することが望ましい。 セキュリティの解決の詳細は，OWLの作業グループの活動の適用範囲外となっている。 多くの組織が，セキュリティ及び個人の好みに配慮した様々な解決を用いて， これらの問題に取り組んでいる。 例えば，SAML及びP3Pを参照されたい。
OWLオントロジの要素の大部分は， クラス，特性，クラスのインスタンス，及びこれらのインスタンス間の関係に関与している。3.は，これらの要素の導入に不可欠な言語構成要素を示す。
オントロジの使用は，多くの場合， 個体について推論する能力に依存する。 これを実用的に行うために，個体が属するクラスを記述し， クラスへの帰属関係によって個体が継承する特性を記述する機構が必要となる。 個体についての特定の特性について表明することは常にできるが，オントロジの威力の多くはクラスに基づく推論に由来する。
オブジェクトとしてのクラスと 要素集合としてのクラスとの差異が問題になる場合もある。 クラスのメンバである個体の集合をそのクラスの拡張と呼ぶ。
ある領域の中で最も基本的な概念が， 様々なタクソノミのルートとなるクラス群に対応することが望ましい。OWL世界のすべての個体は， クラスowl:Thingのメンバとする。 さらに，利用者定義の各クラスは， 暗黙的にowl:Thingの下位クラスとなる。 領域に特定のルートクラスは， 単に名前付きクラスを宣言することによって定義される。 さらに，OWLは，owl:Nothingを空クラスとして定義する。
ワイン領域の例においては，Winery，Region及びConsumableThingの3個のルートクラスを生成する。
<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属性に似ている。 この例の文書内では，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又は属性値&vin;Wineryのいずれかを用いて，wineryクラスを参照することが可能になる。より厳密には，その完全なURI，http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Wineryを用いて，資源の参照が常に可能となる。
クラスを分類構築するための基本要素は，rdfs:subClassOfとする。 これは，より具体的なクラスをより一般的なクラスに関連付ける。XがYの下位クラスである場合，Xの個々のインスタンスは，Yのインスタンスにもなる。rdfs:subClassOf関係は，推移的とする。XがYの下位クラスであって，YがZの下位クラスになっている場合，XはZの下位クラスになる。
<owl:Class rdf:ID="PotableLiquid"> <rdfs:subClassOf rdf:resource="#ConsumableThing" /> ... </owl:Class>
PotableLiquid(飲用に適した液体)をConsumableThingの下位クラスとして定義する。
ウェブに基づくオントロジの世界では， これらの両クラスは，いずれも広範囲にわたる食品及び飲料のオントロジの基本構成単位を提供する分離されたオントロジにおいて定義できるが，実際にはそれらは，foodオントロジの中で定義され，wineオントロジの中に取り込まれる。foodオントロジは，Food，EdibleThing，MealCourse，Shellfishなどの数多くのクラスを含む。それらのクラスは，ワインという事実の集合に属さないが，有用な推論を実行しようとする場合は， それらをワインの語い(彙)と結び付けなければならない。食品及びワインは，ワインと食品とのマッチを識別する必要性を満たすために，相互に依存している。
クラス定義には二つの部分がある。それらは，名前の導入又は参照，及び制限のリストとする。クラス定義に直接に含まれる各表現は，定義済みクラスのインスタンスを更に制限する。クラスのインスタンスは，制限の積集合に属する。 (詳細については，owl:equivalentClassを参照されたい。) これまでは，新しいクラスを他の名前付きクラスの下位クラスとするという一つの制限を取り込んだ例を見てきたに過ぎない。
この点で，Wineクラスの(不完全ではあるが)簡単な定義を生成することができる。 Wineは，PotableLiquidである。同様に，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"属性は，複数言語の支援を提供する。ラベル(rdfs:label)は，注釈と同様に，オントロジの論理的な解釈に何も寄与しない。
このワイン定義は，まだ極めて不完全である。ワインが物であり，飲用液体であることを除き，何の知識ももたないが，個体を生成し，それについて推論するために充分な情報がある。
クラスだけではなく，それらのメンバを記述できることが望まれる。物の世界では，通常，これらのメンバは個体として考えられる。個体は，最小限，それをクラスのメンバとすると宣言することによって導入される。
<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を用いて名前が展開される必要がある。) ウェブオントロジは，分散するものとして設計される。 それらは，取り込まれ，強化されて，派生オントロジを生成できる。
3.2で導入される特性のためのクラスを若干追加するために，カベルネソービニョン(Cabernet Sauvignon)種のブドウの品種を示す個体を用いて，Grape分類(タクソノミ)の分岐を定義する。ブドウは，foodオントロジで定義される。
<owl:Class rdf:ID="Grape"> ... </owl:Class>
ワインオントロジの中には，次がある。
<owl:Class rdf:ID="WineGrape"> <rdfs:subClassOf rdf:resource="&food;Grape" /> </owl:Class> <WineGrape rdf:ID="CabernetSauvignonGrape" />
3.1.3で示すとおり，CabernetSauvignonGrapeは，単一のブドウ品種を示すので，個体である。
OWLにおいて，クラスと個体との相違に関する重要な課題がある。 クラスは，単に，個体の集合を記述する特性の集合及び名前とする。 個体は，それらの集合のメンバとする。 したがって，クラスは，議論の領域における事物の集合と自然に対応するのが望ましく， 個体は，これらクラスにグループ化可能な実際の実体に対応するのが望ましい。
オントロジを構築する際， この相違が次の2点においてあいまいにされる場合が多い。
Wineクラスを扱う際に，同じ違いが生じることに注意されたい。 Wineクラスは，実際のところ，ワインのすべての品種の集合を示しており， 誰かが購入するかもしれない実際のワインボトルの集合を示しているわけではない。 代替オントロジとして，現在のオントロジにおけるWineの各インスタンスの代りに， その種類のワインボトルすべてから成るクラスを想定することができる。 ワインの個々のボトルを考慮する必要がある情報システムとしては，ワイン業者の在庫システムなどが容易に想像される。 現実に存在するワインオントロジは，このような解釈を支援するために，インスタンスとしてのクラスを扱う機能が要求されるであろう。 ワイン品種のインスタンスでありながら，それが同時にワインボトルのクラスとなるような表現は，OWL Fullでは許される点に注意されたい。
同様に，特定の年に醸造所で作られたワインは，ビンテージ(極上)と考えられる。 ビンテージであることを明示するためには，現在のオントロジにおいてそれを示す適切な場所を決めておかなければならない。 ここで示されているWineクラスのインスタンスは，一つの醸造所が作った，ただ一つの種類のワイン，例えば，FormanChardonnayを表す。
2000年に作られたワインがビンテージであると考えられる場合， そのことを追加するためには，特定のワイン個体の部分集合を表現する必要があるが， その機能は存在しないので，困難な問題を生じる。 このビンテージは，新種のワインではなく，2000年という年に作られた既存ワインの特別な部分集合である。 OWL Fullを使用して，ワインインスタンスをビンテージを表す下位クラス(部分集合)をもつクラスとして扱うという選択がある。 作業環境を使用して，インスタンスがビンテージワインと関係付けされる別のクラスとして Vintageを考えるという別の選択もある。 例えば，FormanChardonnay2000は，vintageOf特性をもつ個体のVintageであって，その値は，Wine，FormanChardonnayとする。 Vintageクラスの定義は，後で示す。
この記述のポイントは，オントロジの開発は，実使用を意図することによって確実に促進されることが望ましいということである。 これらの問題の背景には，OWL FullとOWL DLとの間の重要な違いが存在する。OWL Fullでは，クラスをインスタンスとして使用できるが，OWL DLではそれはできない。ワインオントロジは，OWL DL上での稼動を目的として設計されており，結果として，FormanChardonnayなどの個体を，同時にクラスとしては扱わない。
タクソノミしか定義できない場合には，このクラス及び個体の世界は，極めてつまらないものであろう。特性が, クラスのメンバに関する一般的な事実及び個体に関する特定の事実を表明させる。
特性は，二項関係とする。 特性における型は，次の2種類に分類される。
特性を定義する場合， 関係を制限するための多くの方法が存在する。 領域及び値域を指定できる。 既存の特性を特殊化(下位特性化)することによって特性を定義することもできる。 更に複雑な制限も可能であり，後で示す。
<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特性は，領域はWineをもち，かつ，値域WineGrapeをもつ。 すなわち，この特性は，クラスWineのインスタンスを クラスWineGrapeのインスタンスに関係付ける。 複数の領域は，その特性の領域を識別されるクラスの積集合とすることを意味する。 値域の場合も同様とする。
同様に， 特性courseはMealをMealCourseに関係付ける。
OWLにおける値域及び領域の情報の使用は， プログラム言語における型情報の使用とは異なる点に注意されたい。 特に，型は，プログラム言語では整合性を検査するために使用される。 OWLでは，値域は，型を推論するために使用してもよい。次に例を示す。
<owl:Thing rdf:ID="LindemansBin65Chardonnay">
<madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing> ¬
madeFromGrapeの領域がWineなので，LindemansBin65Chardonnayはワインであると推論できる。
特性も，クラスと同様に，階層的に配置することができる。
<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特性は，ワインを，甘さ，こく及び風味を含む味わいの構成要素と色とに関係付ける。 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>
locatedInの領域及び値域をどのように定義するかに注意されたい。 領域は，地域それ自体を含む地域に存在するあらゆる事物を許す。 この関係における推移的結合は， 地理的構造に本質的に含まれる地域階層及び関連事物のネットワークを生成する。 存在位置に関するものが皆無の事物は，任意のクラスに属することができるが， そうでない何らかのものを含む事物は，地方とならなければならない。
これで， ワインが少なくとも一つのWineGrapeから製造されるという概念を取り込むために，Wineの定義を拡張することが可能となった。 特性の定義と同様に，クラス定義においても， 暗黙的に結合される複数の下位部分が存在する。
<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>
この記述は， 少なくとも一つのmadeFromGrape特性をもつ事物の集合を表す無名のクラスを定義している。 これらを 匿名クラスと呼ぶ。 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> ¬
3.2.2では，Vintageを年に関係付ける。
特性が個体を個体に関係付ける(オブジェクト特性)か，特性が個体をデータ型に関連付ける(データ型特性)かに従って，特性は区別される。 データ型特性は，RDFリテラルの値域をもってよく，又はXMLスキーマデータ型に従って定義される単純型であってよい。
OWLは，組込みのXMLスキーマデータ型のほとんどを使用する。 これらのデータ型へ参照は，データ型のURI，http://www.w3.org/2001/XMLSchemaを用いて行われる。 OWLにおいては，次のデータ型の使用を推奨する。
| xsd:string | xsd:normalizedString | xsd:boolean | |
| xsd:decimal | xsd:float | xsd:double | |
| xsd:integer | xsd:nonNegativeInteger | xsd:positiveInteger | |
| xsd:nonPositiveInteger | xsd:negativeInteger | ||
| xsd:long | xsd:int | xsd:short | xsd:byte |
| xsd:unsignedLong | xsd:unsignedInt | xsd:unsignedShort | xsd:unsignedByte |
| xsd:hexBinary | xsd:base64Binary | ||
| xsd:dateTime | xsd:time | xsd:date | xsd:gYearMonth |
| xsd:gYear | xsd:gMonthDay | xsd:gDay | xsd:gMonth |
| xsd:anyURI | xsd:token | xsd:language | |
| xsd:NMTOKEN | xsd:Name | xsd:NCName |
これらのデータ型及びrdfs:Literalが，OWLにおける組込みデータ型を形成する。 すべてのOWL推論機構は，xsd:integer及びxsd:stringのデータ型のサポートを要求される。
他の組込みのXMLスキーマデータ型は，OWL Fullで使用されてもよいが，OWL 意味論及び抽象構文(TS X 7254)の規定で示される注意に従う必要がある。
<owl:Class rdf:ID="VintageYear" /> <owl:DatatypeProperty rdf:ID="yearValue"> <rdfs:domain rdf:resource="#VintageYear" /> <rdfs:range rdf:resource="&xsd;positiveInteger"/> </owl:DatatypeProperty>
yearValue特性は，VintageYearを正の整数(positiveInteger)の値に関係付ける。3.3.3において，VintageをVintageYearに関係付けるhasVintageYear特性を導入する。
OWL 機能一覧([Reference], 6.2)では， 列挙データ型を定義するために，owl:oneOf，rdf:List及びrdf:restの使用を示す。 そこの例は，整数値{0, 15, 30, 40}のリストの要素と同じ値域をもつ，owl:DatatypePropertyであるtennisGameScoreの構成方法を示している。
最初に，個体であるRegion及びWineryを記述し，最初のワイン，カベルネソービニョンを定義する。
<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>
これではまだ不完全である。 完全なオントロジでは定義されるワインの風味の他の側面が存在するが， それらは抜け落ちている。 このワインが， 食品オントロジのどのメニュー項目に合うかについて推論を開始することはできる。 この定義から，サンタクルス山ブドウ園でこのワインが製造されたことは分かる。 このワインは， カベルネソービニョン(wine.rdfを参照)なので， 辛口の赤ワインであることも分かる。
同様の方法で，データ型特性を個体に追加することができる。 次は，VintageYearのインスタンスを記述し，&xsd:positiveInteger型の特定の値に結合している。
<VintageYear rdf:ID="Year1998"> <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue> </VintageYear>
次の幾つかの節では，更に詳細に特性を指定するために使用する機構を示す。 特性の特徴を指定することができ， これによって，特性についてより強化された推論のための強力な機構が提供される。
特性Pが推移的な場合は， 任意のx, y及びzについて，次が成り立つ。
P(x,y) and P(y,z) implies 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>
locatedIn特性が推移的であることから，SantaCruzMountainsRegionがCaliforniaRegionに位置する(locatedIn)ので， それは，USRegionにも位置する(locatedIn)ことになる。
特性Pが対称的とタグ付けされる場合，任意のx及びyについて次が成り立つ。
P(x,y) iff P(y,x)
特性adjacentRegionは対称的であるが，locatedInは対称的でない。 より正確には，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に位置するが， 逆は成り立たない。
特性Pがすべてのx, y及びzについて関数的であるとタグ付けされる場合は，次が成立する。
P(x,y) and P(x,z) implies y = z
このワインオントロジでは，hasVintageYearが関数的である。 ワインの醸造年は，一意である。 すなわち，hasVintageYear特性を使用して，個々のVintageは，ただ一つの年だけに関連付けられる。 owl:FunctionalPropertyでは，領域のすべての要素が値をもつことを要件にはしない。Vintageのメンバ数の記述を参照されたい。
<owl:Class rdf:ID="VintageYear" /> <owl:ObjectProperty rdf:ID="hasVintageYear"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Vintage" /> <rdfs:range rdf:resource="#VintageYear" /> </owl:ObjectProperty>
特性P1がowl:inverseOfP2としてタグ付けされる場合は，すべてのx及びyについて，次が成り立つ。
P1(x,y) iff P2(y,x)
owl:inverseOfの構文は，引数として特性の名前をとる点に注意されたい。 A iff Bは，(A implies B) and (B implies 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には製造元があり，Wineの定義では，それはWineryに制限される。 したがって，各Wineryは， そのWineryを製造元として識別するワインの集合を生成する。
特性Pが逆関数的としてタグ付けされる場合，すべてのx, y及びzについて，次が成り立つ。
P(y,x) and P(z,x) implies y = z
3.3.4の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では，InverseFunctionalをDatatypePropertyに適用できないが， それは，OWL DLにおいては，リテラルがowl:Thingとは互いに素であることによる。
特性の特徴を指定することに加え， 様々な方法で，特定の文脈において特性の値域を制約することができる。 これは，特性の制限を用いて実行される。 次に示す様々な様式は，owl:Restrictionの文脈内でだけ使用できる。owl:onProperty要素は，制限された特性を示す。
特性を構成する要素の型を制限する一つの方法は，既に見てきた。 これまでの機構は，それが特性のすべてのインスタンスに適用される大域的なものであった。 次の二つ，allValuesFrom及びsomeValuesFromは， それらを含むクラス定義に対して局所的になっている。
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: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 | すべてのワインについて，少なくとも一つの製造元は，ワイン醸造所とする。 |
最初の記述では，ワインが製造元をもつことは要求しない。 一つ以上もつ場合には，それらはすべてワイン醸造所でなければならない。 2番目の記述では，ワイン醸造所である製造元が少なくとも一つ存在することを要求するが， ワイン醸造所ではない製造元が存在してもよい。
メンバ数制約の例については，既に見てきた。 これまでのところ，それは，最小メンバ数に関しての表明であった。owl:cardinalityは，より直接的であって，一つの関係における要素の数を正確に指定可能とする。 例えば，Vintageを正確に一つのVintageYearをもつクラスと指定する。
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasVintageYear"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
hasVintageYearは，関数的特性として指定されるが，これによって，すべてのVintage(ビンテージ)が一つ以下のVintageYear(醸造年)をもつという意味と同じになる。 メンバ数制限を使用してその特性をVintageに適用することによって，すべてのVintageが正確に一つのVintageYearをもつことを一層強調する。
OWL Liteでは，メンバ数表現における値は，0又は1に限定される。 これによって，利用者は“少なくとも一つ”，“一つ以下”及び“正確に一つ”を指示することができる。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に対しても成り立つ。
オントロジの影響を最大とするためには， それらが広く共有される必要がある。 オントロジを開発する際に生じる知的な作業を最小にするために， オントロジは，再利用される必要がある。 考えることが可能な最良の世界で，オントロジは構成される必要がある。 例えば，一つの情報源から日付のオントロジを， 別の情報源から物理的な位置のオントロジを採用し， 占有時間の範囲を含むように位置の概念をとして拡張するかもしれない。
オントロジを開発する努力の多くが， その意味することを最大とするために， クラス及び特性を結び付けることに費やされていることを認識するのは重要である。 幅広い有用な意味することを保持するために， クラスへの帰属関係の表明は単純にしたい。 これは，オントロジ開発の最も困難な部分といえる。 既に広く使用され，洗練された既存のオントロジが存在する場合， それを採用するのは理にかなっている。
オントロジの集まりを統合するのは，大きな課題になる。 一貫性を維持するために，ツールの支援は必要不可欠となる。
構成要素オントロジの集合を結合して第三のオントロジの一部とするために， 一つのオントロジの特定のクラス又は特性が， 二つ目のオントロジのクラス又は特性と等価であることを示すことができれば， 有用であることが多い。 この能力は，注意して使用しなければならない。 結合されるオントロジが矛盾する(“すべての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は，まさにテキサス地域に存在する事物である。 ここでのowl:equivalentClassの使用とrdfs:subClassOfの使用との違いは， 必要条件と必要十分条件との違いになる。 subClassOfを使用した場合，テキサスに位置する事物は，必ずしもTexasThingsではない。 しかし，owl:equivalentClassを使用した場合，あるものがテキサスに位置する場合， それは，TexasThingsのクラスに属さなければならない。
| 関係 | 含意 |
|---|---|
| subClassOf | TexasThings(x)はlocatedIn(x,y)及びTexasRegion(y)を表す。 |
| equivalentClass | TexasThings(x)はlocatedIn(x,y)及びTexasRegion(y)を表す。 locatedIn(x,y)及びTexasRegion(y)はTexasThings(x)を表す。 |
同様の方法で特性を結合するために，owl:equivalentPropertyを使用する。
この機構は，クラスにおける機構と類似するが， 二つの個体が同一であると宣言する。 次に例を示す。
<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を使用すると， クラス及び個体，特性及びクラスといった， すべてのものを同じと扱うことが可能で，両方の引数は個体として解釈される。
<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>
この例は，三つの値が互に異なることを表明する一つの方法である。 このような相違を確実に識別することが重要になる場合がある。 これらを表明しないと，DryでしかもSweetなワインを記述することができことになる。 ワインに適用されるhasSugar特性の値は，一つしかないことを先に述べた。 誤って，前述のdifferentFrom要素なしに，ワインがDryであってSweetであると表明した場合，これは，Dry及びSweetが同一であるという意味になる。これらの要素の場合，結果的に矛盾を抱えることになる。
互いに異なる個体の集合を定義するために，より便利な機構が存在する。 Red，White及びRoseが，それぞれ互いに異なることを表明する例を次に示す。
<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は，追加のクラスを形成するための構築子(constructor)を提供する。 これらの構築子を使用して，いわゆるクラス表現を生成することができる。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>
ここで，ブルゴーニュ地域と少なくとも一つのlocatedIn関係をもつワインを正確に含むように，Burgundyを定義する。 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のクラス拡張の一部となる。
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のインスタンスは甘い果物と甘くない果物との積集合の部分集合であって，それは，空集合となると考えられる。
complementOf構成要素は， 議論の領域から，あるクラスに属さないすべての個体を選択する。 通常，これは，非常に大きい個体の集合を参照する。
<owl:Class rdf:ID="ConsumableThing" />
<owl:Class rdf:ID="NonConsumableThing">
<owl:complementOf rdf:resource="#ConsumableThing" />
</owl:Class>
NonConsumableThingのクラスは， そのメンバとして，ConsumableThingの拡張に属さないすべての個体を含む。 この集合は，すべてのWinery，すべてのRegionなどを含む。 それは，文字どおりには，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構成要素を使用して，これを行う。 特に，この定義は，クラス拡張を完全に指定することによって， 他の個体がこのクラスに属すことを宣言できないようにする。
個体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">
<rdfs:label>White</rdfs:label>
</WineColor> ¬
oneOfの使用に関する他の例については，参考文献を参照されたい。
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>
ここで，Fruitを 厳密にSweetFruit及びNonSweetFruitの和集合であると定義する。 これらの下位クラスは互いに素なので，Fruitを二つの別々の下位クラスに厳密に分割できることが分かる。 互いに素であるクラスの数が増えるにつれて， 互いに素であることの表明は，n2に比例して増える。 しかし，今までに検討してきた利用事例では，通常，nは小さい。
nが大きい場合，代替のアプローチを使用することで， 表明の数の2乗的な増加を回避することができる。この方法の一つは，OWL試験スイートで示されている。
説明されている方法の動作を次に示す。 メンバ数が1に等しい特性をもつ要素をもつ親のクラスを記述する。 すなわち，各インスタンスは，この特性について値を一つだけもたなければならない。 次に，親クラスのすべての下位クラスについて，そのインスタンスはその特性に関して特定の一意の値をもたなければならないと要求する。その場合，異なる下位クラスは共通のメンバをもつことができない。
オントロジは，ソフトウェアに似て，管理され，時間とともに変化する。owl:Ontology要素(2.2参照)内では，定義されているオントロジの過去の版への結合ができる。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は， 版管理システムの使用に適したフックを提供する。先の三つのタグとは異なり，owl:versionInfoのオブジェクトは，リテラルであって，そのタグは，オントロジに加えて，クラス及び特性の注記に用いることができる。
多くの目的を考慮すると， 一つのオントロジ全体の粒度から見た版管理では十分とはいえない。 維持管理者は，クラス，特性及び個体の版情報を保存したいと考えるかもしれない。 しかし，それでも不十分かもしれない。OWLは，クラス表現を逐次追加する性質をもつが， あるオントロジが別のオントロジで定義された(名前付き)クラスに制限を加えてもよく， これらの追加された制限それ自体が版情報を必要としてもよい。
OWL Fullは，クラスについてあらゆる種類の表明を作成するための表現力を提供する。 この場合のクラスは，他のクラスのインスタンスであったり，(インスタンスでない)クラスが，特性及びその特性の値をもっていたりする。 この枠組みは，版情報を追跡するためのクラス及び特性のオントロジを構築するために使用できる。OWL名前空間は，この目的で使用できる二つの定義済みクラス，owl:DeprecatedClass及びowl:DeprecatedPropertyを含む。 これらは，クラス又は特性が，次の版では，現在の版との互換性が失われた状態で変更される可能性があることを示すことを意図している。
...
<owl:DeprecatedClass rdf:ID="&vin;JugWine" />
<owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
... ¬
注意したほうがよい重要なこととして，owl:DeprecatedClass及びowl:DeprecatedPropertyは追加的な意味をもたないこと， 及びそれらが確実に意図どおりに使用されるのは， ツール開発者及びOWL利用者の義務であることが挙げられる。
一度，ある領域のオントロジを入手できれば， そのオントロジを活用するために， 数多くのアプリケーションを開発することができる。 7.では，ワインの分野における使用例を幾つか示す。
今日，ワインポータルと呼ばれるサイトが数多く存在する。 例えばGoogleで“wine portal”を検索すると，152,000件のサイトが得られる。 上位で合致するサイトの一つは，“Wine-Portal.com”であって， 多数のサイトへのアクセスを提供している。 ワインポータルであることを主張する多くのサイトは， ほとんどが情報サイトになっている。 例えば，Wine-Portal.comで最初に掲載されているサイトは，“cork cuisine”(www.corkcuisine.com/)と呼ばれるサイトで，ワイン及び食べ物の相性，贈り物としてのワインなどに関する情報を提供している。
それらトピックの領域を熟読すると， 様々な情報を含むページの収集，時にはそのトピックに関係するサービスが掲載されている。 例えば，“アクセサリ及びギフト”欄には， 特別なワインを買う場合に探すとよい情報に加え， 膨大なオンライン小売業者の情報が網羅されている。“購買(shopping)”と呼ばれる別の上位項目には， “ワイン購買(wine shopping)”と呼ばれる下位領域がある。 利用者は，そこから，国別のオンライン(又は街頭購買)の店を探すことができる。 これら二つのサイトは，今日ある数多くの例のうちの二つに過ぎず， 特定のトピック領域に関連した情報及びサービスの収集を提供するワイン情報のポータルサイトという一般概念を表現している。
これらのサイトをある程度詳しく見ても，今日それらがどの程度オントロジに依存しているかは明らかではない。 例えば，htmlのソースを見ても，オントロジを使用している証拠は明らかにはならない。しかし，オントロジを活用できるサイトが，幾つかのワインオントロジを利用し得たことは明らかである。
ポータルサイトにおけるオントロジの簡単な使用の一つは， コンテンツ編成及び閲覧への適用である。 前述の分類のリストは， ワインに関連するクラスの上位の幾つかのレベルから生成することができる。 問合せは，ワインオントロジを活用し，ワインの関連情報を検索することができる。 オントロジに含まれる用語について検索した場合，関連する答えをより多く見つけるために，下位クラスの情報を使用して問合せを拡張することができる。 トピックの領域の(候補となる)情報を用いて，ポータルサイト自体を自動的に更新することができる。 非常に強力な推論能力を使用すれば，それらは，ワイン販売サイトを識別し，それらをポータルサイトの一部として取り込むことを交渉することさえ可能であろう。
ワインエージェントの解説から始める。 ワインエージェントの目的は，当初の設計では， 食事のコースとともに供されるワインを薦めることであった。 このアプリケーションは， この手引の例として使用されるオントロジを利用する。 このワインオントロジは，DAMLオントロジライブラリから入手が可能であって，Winesと表題がつけられている。
特定個人向けのワインエージェントは， その個人に数多くのサービスを提供することができる。
エージェントを使用することによって，(供される食事などの)一連の制約が課されたワインを推薦したり，エージェントが特定のワイン又はワインの特定クラスに関する情報を見つけたり，ワインにふさわしいアクセサリ(そのワイン品種に合う特殊なグラスなどの付属品のこと。)を探したりすることもある。
次に，ある学生の研究課題として書かれた簡単なプロトタイプシステムの例を示す。
次のシナリオを考察してみる。
ある人がディナーパーティを計画しており，
ゲストのうち少なくとも一人はワインに精通している。
ホストは，メニューのコースにぴったりのワインを出したいと思っている。
ホストは，ディナーで供されるワインについての知識を披瀝し，
ディナーに，ふさわしいアクセサリも使用したいとも考えている。
ホストは，生パスタを使ったトマトベースの特製ソースのパスタをメインコースに出すことを決めている。
食事に合ったワインを供するために，ホストは，ワインと食べ物との組合せに関する情報を必要としている。 ワインに関する知識を披瀝するために，ホストは，イベントにかかわるワイン情報へアクセスすることによって恩恵を得ることになる。 的確なワインのアクセサリを選ぶために，ホストは，どのアクセサリがその場にふさわしいか(及びそれらの価格がホストが購入可能な範囲であるか)の情報を必要としている。
背景となるワインオントロジとともに食事の記述が与えられると， ワインエージェントは，食事とともに供されるワインの種類を提案することができる。 ワインエージェントは，その食事に合ったワイン品種の選択として， ジンファンデル種のワインを提案するかもしれない。 さらに，背景オントロジを与えられれば，ワインエージェントは， 特定のジンファンデル種のワイン，もしかするとマリエッタジンファンデルを提案するかもしれない。 ワインはジンファンデルであることが望ましいという情報が与えられれば， ワインエージェントは，ジンファンデルを選べる場所を探すか， 又はマリエッタなどの特定のジンファンデルワインを探すかのいずれかを行うかもしれない。 (恐らく，ホストの居住地及びワイン販売業者がある場所による選別によって，)ワインを購入するための適切な情報源を含むオントロジが与えられれば， ワインエージェントは，wine.comなどのサイトに行って，“zinfandel”について検索し， そのサイトで販売されているジンファンデルのリストを返すことができるであろう。 ワインエージェントは，ワイン醸造所又は他の再販業者のいずれかから，マリエッタ ジンファンデルを見つけようとすることができるであろう。 それによって，例えば，(Google又は選定されたウェブサイトの構造的な検索によって，)マリエッタジンファンデル1999年物がwinelibrary.comで割引価格13.99ドルで販売されていることを発見できるかもしれない。 ワインエージェントは，消費者又は品種から示唆される価格帯のような付加的なフィルタ情報を使用することができる。
ここで，ワインエージェントは， ジンファンデル一般又は特にマリエッタジンファンデルに関する情報を提供しようとしている。 ワインエージェントは，ワインサイトの背景オントロジを使用して， 特別なワインに関する情報を発見することができる。 例えば，ジンファンデルの醸造所の最新の記述が有用かもしれない。 さらに，Wine Spectator誌のような評判の情報誌の論評が有用であるかもしれない。 好みのワインを論評するサイトで， マリエッタジンファンデルに関する論評を入手できない場合は， 同じ地域のジンファンデル， この場合は，カリフォルニア州，ソノマ郡のジンファンデルに関する論評など， 関連情報を探すのも有用である。
一般的な背景情報も有用である。 ホストは，ワイン一般又は特にジンファンデルに関する本に関心をもち， 読みたいと考えるかもしれない。 例えば，ホストは，Amazon.comが販売するジンファンデルに関する本に興味をもつかもしれない。 ホストは，同じ地域のワインに関連した情報にも関心をもち，その結果， ソノマジンファンデルに興味を引かれるかもしれない。 ワインエージェントは，主たる知識領域に関連した代表的な背景情報を入手するかもしれない。 例えば，このワインエージェントは，食べ物とワインとの相性に関わっているので， 雑誌Wine Spectator誌の食べ物とワインの相性に関する記事といったこの話題についての有償無償の情報をもっているかもしれない。
ディナーのホストは，イベントに先立って， 適切なワインのアクセサリを購入したいとも考えるかもしれない。 ワインは，ワイングラスで供され， 品種の異なるワインは，別々の種類のグラスで供されるのが最もよい。 例えば，ホストがジンファンデルに合った料理コースを選んだ場合，ホストは， リーデル社がワイングラス類の有名な製造業者であることを知っていることを望むであろう。 ホストは，Wine Enthusiast (ワイン販売における定評のある供給者)に接触し，Wine Enthusiastからリーデルのヴィノムジンファンデルワイングラスが4個セットで63.95ドル(4個セットを二つ買う場合は値引きして59.95ドル)で売られていると語られることを期待するかもしれない。 ホストは，Amazon.comから， (表示価格が65ドルの)リーデルのソムリエジンファンデル脚付きグラスを49.99ドルで購入できることにも興味をもつかもしれない。 さらに， アマゾンは，(Wine Enthusiastでは，1セット4個入りだった)同じヴィノムのワイングラスの6個セットを(表示価格は119.40ドルであるが)79.99ドルで販売している。 ワインエージェントは，(例えば，ジンファンデルを出す際にふさわしい)食事に適しており， 値段又はオントロジの特性のリストから選択された他の基準によって比較された， グラス類の比較リストを提供することができるかもしれない。
ディナーのホストは，他のワインアクセサリを検討したいと考えるかもしれない。 オントロジから，コルク栓抜きがワインアクセサリであることが分かる。 背景オントロジは，コルク栓抜きの下位クラスを符号化してもよいし， 関連するワインサイトからもこのような情報が見つかるかもしれない。Wine Enthusiastは，(種類及び価格帯の記述のある)推奨するコルク栓抜きのリストをもっている。コルク栓抜きは，(品格，ウェイター，固定式又は可動式，ねじれ具合，ポンプ作用などの)型で区別され，ディナーホストは，それらの型についての情報を得たいと考えるかもしれない。
ワインエージェントは，対象領域における背景オントロジの知識，情報及びサービスサイトに依存する数多くの洗練された知識レベルに馴染むようになるかもしれない。 この例では，ワイン，品種，食べ物とワインとの組合せ，幾つかのワインアクセサリ及びそれらに関連する特性についての情報が活用されているに過ぎない。もちろん，これを拡張して，利用者がより多くの情報及びより多くの制約を含めることができるだろう。
このワインエージェントの更なる発展例が，利用可能になっている。