【注意】 このドキュメントは、W3CのOWL Web Ontology Language Guide W3C Recommendation 10 February 2004の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2004年5月9日 | Last Update: 2021年4月6日
このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。
翻訳版も参照してください。
Copyright © 2004 W3C® (MIT, ERCIM , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
現在構成されているワールド・ワイド・ウェブは、不完全に描かれた地図に似ています。ドキュメントに対する我々の見識と利用可能な能力はキーワード検索（ドキュメントの関連性と使用パターンの巧みな使用にサポートされた）に基づいています。この莫大な量のデータは、強力なツールのサポートがなければ処理できません。この地形をより正確にマッピングするためには、コンピュータを利用したエージェントは、コンテンツの記述に機械可読性があることや、資源がウェブでアクセス可能であることを要求します。これらの記述は、人間が読める形の情報に付加されたものでなければなりません。
OWLウェブ・オントロジー言語は、ウェブ・ドキュメントやアプリケーションに内在するクラスやクラス間の関係を記述するために使用できる言語を提供することを意図されています。
このドキュメントは、以下を目的としたOWL言語の使用を実証します。
この項は、より複雑な言語構成要素に対する基礎と手続きに始まり、クラスの集合、プロパティーおよび個体のインクリメント定義を示すように構成されています。
このドキュメントは、W3Cメンバーおよび他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
これは、6つからなるOWL（ウェブ・オントロジー言語）のW3C勧告の1つです。2004年2月10日の公開に向けてW3Cセマンティック・ウェブ・アクティビティ（アクティビティ声明、グループ憲章）の一部としてウェブ・オントロジー・ワーキンググループによって開発されてきたものです。
これらのドキュメントの初期バージョンで示されたOWLの設計は広くレビューされており、ワーキンググループの技術要件を満たします。ワーキンググループは、必要に応じて変更を加えながら受理したすべてのコメントに取り組みました。勧告案バージョン以後のこのドキュメントに対する変更の詳細は、変更履歴に記述されています。
コメントはpublic-webont-comments@w3.org（アーカイブ）で歓迎され、関連技術の一般的な議論はwww-rdf-logic@w3.org（アーカイブ）で歓迎されます。
実装のリストが利用可能です。
W3Cは、この事業に関するあらゆる特許の開示のリストを維持します。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物および技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスで見つけることができます。
「次のメニューの各コースで出すために、私がどのワインを買うべきか教えてください。ところで、私はソーテルヌが好きではありません。」
今日、この質問を満たしたウェブ上のワインの検索を実行することができるウェブ・エージェントを構築することは困難でしょう。 同様に、整合性のある旅行計画を立てるタスクをソフトウェア・エージェントに現実に課すことを考えてみてください（ユースケースの詳細は、OWL要件ドキュメントを参照してください）。
この種のコンピュータの利用をサポートするためには、キーワードを超えて、ウェブ上で記述された資源の意味を指定する必要性があります。解釈のこの追加された層は、データのセマンティクスを捕らえます。
OWLウェブ・オントロジー言語は、ウェブのオントロジーを定義し実証するための言語です。オントロジーは、世界のエンティティーの種類を記述し、それらがどのように関連付けられるかの科学に関する哲学から借りた用語です。OWLオントロジーには、クラス、プロパティーと、それらのインスタンスの記述を含むことができます。そのようなオントロジーのもと、OWLの形式意味論は、その論理的な結果、つまり、オントロジーに文字通りに存在する事実ではなく、セマンティクスによって含意される事実を引き出す方法を定めます。これらの含意（entailments）は、単一ドキュメント、あるいは、定義済みのOWLメカニズムを使用して組み合わせられた多数の分散したドキュメントに基づくことができます。
このドキュメントは、W3Cウェブ・オントロジー・ワーキンググループ（WebOnt）によって作成されているOWL（ウェブ・オントロジー言語）の記述の1つの構成要素です。概要（[概要]、1.1）のドキュメント・ロードマップの項は、異なる各々の部分について記述し、また、それらがどのように組み合わさるかについて記述します。
さらに別のXML/Web標準を記述する場合に生じる1つの疑問は、「XMLおよびXMLスキーマは与えてくれないもので、これが与えてくれるものは何だ?」ということです。 この疑問には2つの答えがあります。
OWL言語は、特定の開発者コミュニティーやユーザが使用できるように設計された、（訳注：OWL Lite、OWL DL、OWL Fullの順で）順に表現力のある3つのサブ言語を提供します。
OWL Liteは、主として分類階層やシンプルな制約を必要としているユーザをサポートします。例えば、OWL Liteはカーディナリティー制約をサポートしていますが、カーディナリティーの値は0または1のみが許されています。 より表現力のある他の関連言語よりも、OWL Liteへのツールのサポートがより簡単であるべきで、OWL Liteは類語集やその他の分類法に対して迅速な移行パスを提供します。
OWL DLは、計算能力の完全性（すべての結論が計算されることが保証される）や、決定可能性（すべての計算が限られた時間内に終了する）を保持しつつ、最大の表現力を要求するユーザをサポートします。OWL DLは、タイプ分離（クラスは個体あるいはプロパティーではありえなく、プロパティは個体あるいはクラスではありえない）のような制限付きで、すべてのOWLの言語構成子を含んでいます。OWL DLという名前は、記述論理[Description Logics]（一階述語論理の特定の決定可能なフラグメントを研究している研究分野の1つ）と一致していることから、そのように名づけられています。OWL DLは、既存の記述論理の事業セグメントを支援するように設計され、推論システムにとって望ましい計算特性を持っています。
OWL Fullは、最大の表現力、および、コンピュータ上の保証がないRDFの構文に制限がないこと望むユーザに向けたものです。例えば、OWL Fullでは、クラスを個体の集まりとして、また同時に、1つの個体自体として扱うことができます。OWL DLとの他の大きな違いは、owl:DatatypePropertyをowl:InverseFunctionalPropertyとしてマークアップすることができることです。OWL Fullでは、オントロジーは、定義済みである（RDFあるいはOWLの）語彙の意味を補強することができます。どんな推論ソフトウェアでも、OWL Fullのすべての機能に対して推論をサポートすることは望めそうにありません。
これらのサブ言語は、それぞれ、何を正当に表現でき、何を有効的に結論づけられるかの両方において、前身の、よりシンプルな言語を拡張したものです。下記の一連の関係は成り立ちます。その逆は成り立ちません。
OWLを導入するオントロジーの開発者は、どのサブ言語が彼らのニーズに最適であるかを考慮するべきです。OWL LiteかOWL DLかの選択は、ユーザがどの程度OWL DLよりも表現力がある構成子を求めるかによります。OWL Liteの推論システムは、望ましい計算特性を持つでしょう。OWL DLの推論システムは、決定可能なサブ言語を扱いますが、より高い最悪計算量（worst-case complexity）を必要とするでしょう。OWL DLかOWL Fullかの選択は、主としてユーザがRDFスキームのメタモデリング機能を要求する程度に依存します（例えば、クラスのクラスを定義する）。OWL Fullを使用する際には、OWL DLと比較して、推論のサポートが予測できません。この問題に関する詳細は、OWLセマンティクス・ドキュメントをご覧ください。
RDFからOWL DLあるいはOWL Liteへマイグレートするユーザは、OWL DLおよびOWL Liteによって課された制約にオリジナルのRDFドキュメントが適合することを保証するように注意する必要があります。これらの制約の詳細は、OWLリファレンスの付録Eで説明されます。
OWL DLあるいはOWL Fullのみで許されている構成子を導入する場合は、[OWL DL]とマークアップしています。
このガイドの全体にわたって一貫した例を提供するために、ワイン（wine）と食品のオントロジーを作成しました。これはOWL DLのオントロジーです。いくつかの議論はOWL Fullの性能に焦点を当てており、そのようにマークアップされています。ワインおよび食品のオントロジーは、長い歴史のあるDAMLオントロジー・ライブラリの要素を大幅に変更したものです。これは、典型的な記述論理の例としてMcGuinnessがもともと開発し、記述論理のチュートリアルに拡張され、オントロジーのチュートリアルに拡張されました。
このドキュメントでは、XMLが大多数の対象者によく知られていると仮定し、RDF/XML構文（[RDF], 5）を使用して例を示しています。標準のOWL交換構文はRDF/XMLです。OWLがRDFおよびRDFスキーマと最大の互換性を持つように設計されたことに注意してください。これらのXMLおよびRDFのフォーマットはOWL標準の一部です。
このドキュメントで示される例は、右下の隅に ¬ とマークアップされたものを除いて、すべてwine.rdfおよびfood.rdfに含まれているオントロジーから採っています。
OWLはセマンティック・ウェブの取り組みの1つです。この活動は、ウェブ・コンテンツを記述あるいは提供する資源に関する情報を加えることによって、より簡単にウェブ資源が自動プロセスにアクセスできるようにすることを目標としてます。セマンティック・ウェブは生来的に分散しているため、OWLは分散した情報源から情報を集めることを可能にしなければなりません。これは、他のオントロジーから明示的にインポートする情報を含め、オントロジーが関連付けられることを可能にすることによりある程度行われます。
さらに、OWLは開世界仮定を作ります。つまり、資源の記述は、単一のファイルあるいは範囲に制限されません。クラス「C1」がオントロジー「O1」にもともと定義されていたとしても、他のオントロジーにおいて拡張することができます。「C1」に関するこれらの追加命題の結果は単調です。新しい情報は、前の情報を取り消すことができません。新しい情報は矛盾しているかもしれませんが、事実と含意は追加することができるのみで、削除することはできません。
オントロジーの設計者は、そのような矛盾の可能性を考慮に入れておく必要があます。ツールのサポートがそのようなケースを検知する助けとなることが期待されます。
一意に解釈することができ、ソフトウェア・エージェントが使用することができるオントロジーを書くためには、OWL用の構文と形式意味論が必要です。OWLはRDFの語彙の拡張[RDFセマンティクス]です。OWLセマンティクスは、OWLウェブ・オントロジー言語セマンティクスおよび抽象構文で定義されます。
一組の用語が使用できるようになるに先だって、どのような特定の語彙が使用されているかを正確に表示する必要があります。オントロジーの標準的な初期構成要素は、開始を示すrdf:RDFタグで囲まれた一組のXML名前空間宣言を含んでいます。これらは、識別子を一意に解釈する手段を提供し、残りのオントロジー表示をはるかにより解読しやすくします。典型的なOWLオントロジーは、以下と同様の名前空間宣言で始まります。もちろん、定義済みオントロジーのURIは、通常は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つの宣言は、このオントロジーに関連する名前空間を識別します。最初のものは、接頭辞のない修飾名はカレント・オントロジーを参照すると述べて、それをデフォルトの名前空間にします。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#と呼ばれる名前空間から引き出された事物を参照します。次の2つの名前空間宣言は、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では、ontologyという用語はインスタンス・データを含めるために拡張されました（上記参照）。
rdf:about属性は、オントロジーの名前あるいは参照を提供します。属性の値が「""」（標準の場合）である場合、オントロジーの名前はowl:Ontology要素の基底URIです。通常は、これはオントロジーを含んでいるドキュメントのURIです。これの例外は、要素に対する基底URIを現在のドキュメントのURI以外のものに対して設定することができるxml:baseを利用する文脈です。
rdfs:commentは、オントロジーにアノテーションを付与するという明かに必要とされる性能を提供します。
owl:priorVersionは、オントロジーに働くバージョン管理システムにフックを提供することを意図した標準的なタグです。オントロジーのバージョン付けは、以下でさらに議論されます。
owl:importsは、包含形式（include-style）のメカニズムを提供します。owl:importsは、rdf:resource属性によって識別される1つの引数をとります。
別のオントロジーをインポートすると、そのオントロジーによって提供されるすべての言明の集合がカレント・オントロジーにもたらされます。このインポートしたオントロジーを最大限に利用するために、通常は名前空間宣言との調整がおこなわれるでしょう。これらの2つのメカニズムの違いに注意してください。名前空間宣言は、他のOWLオントロジーで定義された参照の名前に便利な手段を提供します。概念的には、owl:importsは、ターゲット・オントロジーの言明を包含するという意図を表すために提供されます。別のオントロジー（O2）のインポートも、O2がインポートするすべてのオントロジーをインポートするでしょう。
owl:importsは、常に成功するとは限らないということに注意してください。セマンティック・ウェブを扱う際に予期されるように、ウェブ中に分散している資源へのアクセスが常に可能だとは限りません。ツールは実装に定義された方法でこの状況に対処するでしょう。
OWLの語彙を使用するために、owl.rdfオントロジーをインポートする必要がないことに注意してください。実際、そのようなインポートは推奨できません。
ここで適切に包含することができる付加的なタグの共通セットの1つは、標準のダブリン・コアメタデータ・タグのうちのいくつかです。サブセットには、シンプルなタイプあるいはストリングを値としてとるものが含まれます。例えば、タイトル（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である場合、そのプロパティの同じ値を持っているということに基づいて、2つの別個の個体は同一であると推論することができます。そのような手段によって個体が同じであると定められている場合、それらに関する異なる情報源からの情報を結合することができます。この集約（aggregation）は、1つの任意の情報源では直接表されない事実を決定するために使用することができます。
多数の情報源からの情報をリンクするというセマンティック・ウェブの性能は、多くのアプリケーションで使用することができる望ましく強力な特徴です。しかし、OWLの推理力と合わせて、多数の情報源からのデータを結合する性能は、乱用される可能性を持っています。OWLのユーザは、潜在的なプライバシーへの影響に注意するべきです。セキュリティの解決策の詳細は、ワーキンググループの範囲外であると考えられました。多くの組織が、様々なセキュリティとプリファレンスの解決策の問題に取り組んでいます。SAMLとP3Pの例を参照してください。
OWLオントロジーのほとんどの要素は、クラス、プロパティー、クラスのインスタンス、およびこれらのインスタンス間の関係に関連しています。この項では、これらの要素の導入に不可欠な言語構成要素を紹介します。
オントロジーのユーザの多くが、個体に関する推論能力に依存するでしょう。有用な方法でこれを行うためには、個体が属するクラスと、クラスのメンバーシップによって継承するプロパティーを記述するためのメカニズムを持つ必要があります。個体に関する特定のプロパティーをいつでも言明することできますが、オントロジーの能力の多くはクラスに基づいた推論から得られます。
オブジェクトとしてのクラスと、要素を包含する一つの集合としてのクラスとの違いを強調したいことがあります。クラスのメンバーである個体の集合を、クラスの外延と呼びます。
定義域で最も基本的な概念は、様々な分類木のルートであるクラスに対応付けられるべきです。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と呼んたほうがよいでしょう。
定義が漸増的かつ分散的であるかもしれないことを覚えておくことは重要です。特に、ワイナリーに関しては後ほどもっと述べなければならないでしょう。
構文rdf:ID="Region"は、その定義の一部として、名前を導入するために使用されます。これは、XMLによって定義付けられる、よく知られているID属性に似たrdf:ID 属性（[RDF]、7.2.22）です。このドキュメント内では、地域クラスは#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を使用してワイナリークラスを参照することができます。より厳密には、完全な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（飲用に適した液体）を、消耗品のサブクラスになるように定義しました。
ウェブ・ベースのオントロジーの世界では、これらのクラスは両方とも、様々な食品と飲料のオントロジーに基礎構成要素を提供する別個のオントロジーで定義することができ（実際に我々は行った）、これらは（ワイン・オントロジーにインポートされた）食品（food）オントロジーで定義されている。foodオントロジーには、例えばFood、食料品（EdibleThing）、食事のコース（MealCourse）、および甲殻類（Shellfish）のような、ワインの事実の集合に属さないが有用な推論を実行するならばワインの語彙に結合しなければならない、多くのクラスが含まれます。食品とワインは、ワインと食品の相性を識別する必要性を満たすために、互いに依存します。
クラス定義は、名前の導入あるいは参照と制約のリストの2つの部分から成ります。クラス定義に直接含まれる式は、それぞれ、定義済みクラスのインスタンスをさらに制約します。クラスのインスタンスは、制約の積集合に属します。（しかし、owl:equivalentClassの詳細を参照してください）。これまでのところでは、新しいクラスが他のある名前付きクラスのサブクラスであることを強制する、たった一つの制約を含んでいる例を見ただけです。
この時点で、クラスワインのシンプルな（かつ不完全な）定義を作成することができます。ワインは、飲用液体（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」属性は、多言語に対するサポートを提供します。ラベルは、コメントに似ており、オントロジーの論理的な解釈には何も寄付しません。
我々のワインの定義は、まだ非常に不完全です。我々は、事物（thing）であることと飲用液体であるという点を除いてワインに関しては何も知りませんが、個体を作って推論するのに十分な情報を持っています。
クラスに加えて、それらのメンバーについての記述が可能であることが望まれます。これらは通常、事物の宇宙（universe）の個体であると考えられます。個体は、それをクラスのメンバーであると宣言することにより、最小限に導入されます。
<Region rdf:ID="CentralCoastRegion" />
下記が、上記の例と同じことを意味することに注意してください。
<owl:Thing rdf:ID="CentralCoastRegion" /> <owl:Thing rdf:about="#CentralCoastRegion"> <rdf:type rdf:resource="#Region"/> </owl:Thing>
rdf:typeは、そのメンバーであるクラスに個体を結び付けるRDFプロパティーです。
ここであげるべきポイントが2つあります。最初に、セントラル・コースト地域（CentralCoastRegion）（特定の区域）が、すべての地理上の地域を含んでいるクラスである地域のメンバーであると決めました。次に、2部からなる例において、2つの要素が互いに隣接している必要性はなく、あるいは同じファイル内にある必要（そのような場合には、名前がURIで拡張される必要があるが）さえもありません。ウェブ・オントロジーは、分散するように設計されています。ウェブ・オントロジーは、インポートされ、拡張されて、派生オントロジーを生成します。
次の項で導入されているプロパティーに対していくつかのクラスを利用できるようにするために、カベルネ・ソーヴィニヨンのブドウの品種を表している個体で、ブドウ（grape）分類の分枝を定義します。ブドウは食品オントロジーで定義されています。
<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はブドウの1つの品種を表すゆえに、個体です。
OWLには、クラスと個体の区別に関して重要な問題があります。クラスは、名前、および一組の個体を記述するプロパティーの集合にすぎません。個体は、そのような集合のメンバーです。したがって、クラスは自然発生する議論領域中の事物の集合に対応すべきで、個体はクラスにグループ分けできる実際のエンティティーに対応すべきです。
オントロジーを構築する際には、この区別は以下の2つの点でしばしば不明瞭です。
ワインクラスの扱いでも、同じ区別が起ることに注意してください。ワインクラスは、誰かが購入するかもしれない実際のボトルの集合ではなく、ワインのすべての種類の集合を現実に表します。これと違って別のオントロジーでは、カレント・オントロジーのワインのそれぞれのインスタンスが、そのタイプのワインのすべてのボトルからなるクラスを指定することができます。ワイン業者用の在庫管理システムのような、ワインの個々のボトルを考慮する必要がある情報システムを想像することは簡単です。現存するワイン・オントロジーは、そのような解釈をサポートするためのインスタンスとしてクラスを扱う性能を要求するでしょう。OWL Fullではそのような表現力が可能で、ワインの種類のインスタンスを、同時にそのインスタンスがワインのボトルであるクラスとしても扱うことを可能であることに注意してください。
同様に、ワイナリーが特定の年に生産したワインはヴィンテージと見なされます。ヴィンテージの概念を表すためには、それがカレント・オントロジーのどこに適合するかを決めなければなりません。上で議論したように、ワインクラスのインスタンスは、例えばFormanChardonnayのように、一つのワイナリーが生産したワインの一つの種類を表します。
2000年に生産されたワインがヴィンテージ（Vintage）と考えられることを付け加えることは、与えられたワインの個体のサブセットを表す能力がないので、難問をもたらします。このヴィンテージは新しい種類のワインではなく、ワインの特定のサブセット（2000年に生産された）です。オプションは、OWL Fullを使用し、ヴィンテージを表すサブクラス（サブセット）付きのクラスとしてワインのインスタンスを扱うことです。もうひとつのオプションは、次善策を利用し、ヴィンテージをそのインスタンスがヴィンテージであるワインとの関係を持っている別個のクラスと見なすことです。例えば、FormanChardonnay2000は、ワイン、フォーマン・シャルドネ（FormanChardonnay）を値とするvintageOfプロパティーを持つ個体のヴィンテージです。ヴィンテージクラスを下記のように定義します。
この議論のポイントは、オントロジーの開発が意図した利用法によって確実に推進されるべきであるということを示すことです。さらに、これらの問題はOWL FullとOWL DLとの一つの大きな違いを明示します。OWL Fullでは、インスタンスとしてクラスを使用することができますが、OWL DLでは可能はありません。ワイン・オントロジーはOWL DLで機能するように設計されており、その結果、FormanChardonnayのような個体を同時にクラスとして扱うことはできません。
分類を定義することしかできなければ、クラスと個体のこの世界はかなり面白くないでしょう。プロパティーによって、クラスのメンバーに関する一般的な事実および個体に関する特定の事実を言明できます。
プロパティーは2項関係です。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では、明示的な演算子を持たない要素のシーケンスは、暗黙の論理積を表します。プロパティーmadeFromGrapeは、ワインの定義域とワイン用のブドウ（WineGrape）の値域を持っています。すなわちそれは、クラスワインのインスタンスを、クラスワイン用のブドウのインスタンスに関連付けます。複数の定義域は、プロパティーの定義域が識別されたクラスの（そして同様に値域に対する）積集合であることを意味します。
同様に、プロパティーコース（course）は、食事（Meal）を食事のコース（MealCourse）に結合させます。
OWLの中の値域および定義域情報の使用がプログラミング言語のタイプ情報とは異なることに注意してください。とりわけ、タイプはプログラミング言語の整合性をチェックするために使用されます。OWLでは、タイプを推論するために値域を使用することができます。例えば、下記のようであれば、
<owl:Thing rdf:ID="LindemansBin65Chardonnay">
<madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing> ¬
madeFromGrapeの定義域がワインであるため、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）は、その値域をさらにワインの色（WineColor）に制限したワイン記述子を持つ（hasWineDescriptor）プロパティーのサブプロパティーです。この場合、rdfs:subPropertyOf関係は、値Xを持つ色を持つプロパティーを持つあらゆるものは値Xを持つワイン記述子を持つプロパティーも持っているということを意味します。
次に、事物をそれらが位置する地域へ関連付ける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の定義域および値域がどのように定義されるかに注意してください。定義域では、地域自身を含むあらゆるものが地域に位置できます。また、原則としてこの関係の推移的な構成は、地理的に含まれるサブ地域と事物のネットワークを作成します。他のものを含んでいる事物は地域でなければなりませんが、自身の中に何も位置するものがない事物は任意のクラスでありえます。
これで、ワインが少なくとも1つのワイン用のブドウで作られているという概念を含めるように、ワインの定義を拡張することができるようになりました。プロパティー定義のように、クラス定義も暗黙的に結合される多数の下位区分を持っています。
<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>
少なくとも1つのmadeFromGrapeプロパティーを持つ事物の集合を表す、名前のないクラスを定義します。これらを匿名クラスと呼びます。ワインクラス定義の本体にこの制限を含むことにより、ワインである事物もこの匿名のクラスのメンバーであるということを明言します。すなわち、すべての個体ワインは、少なくとも1つのmadeFromGrape関係に関与していなければなりません。
これで、以前に議論したヴィンテージのクラスについて記述することができるようになりました。
<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は、ヴィンテージをワインに結び付けます。
<owl:ObjectProperty rdf:ID="vintageOf">
<rdfs:domain rdf:resource="#Vintage" /> <rdfs:range rdf:resource="#Wine" />
</owl:ObjectProperty> ¬
次の項では、ヴィンテージを年に関連付けます。
個体を個体（オブジェクト・プロパティー）に関連付けるか、個体をデータ型（データ型プロパティー）に関連付けるかによってプロパティーを区別します。データ型プロパティーの値域は、XMLスキーマ・データ型に従って定義されたRDFリテラルあるいはシンプルなタイプに及ぶかもしれません。
OWLは、組込型XMLスキーマ・データ型の大部分を使用します。http://www.w3.org/2001/XMLSchema. これらのデータ型への参照は、データ型の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セマンティクスおよび抽象構文ドキュメンテーションで示されている注意事項のもとで）。
<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）を自然数の値に関連付けます。以下で、ヴィンテージをヴィンテージ・イヤーに関連付けるヴィンテージ・イヤーを持つ（hasVintageYear）プロパティーを導入します。
OWLリファレンス（[リファレンス]、6.2）は、列挙型データ型を定義するためにowl:oneOf、rdf:Listとrdf:restの使用について記述しています。この例では、整数の値{0、15、30、40}のリストの要素と同等の値域でowl:DatatypeProperty、tennisGameScoreを構築する方法を示します。
最初に地域とワイナリーの個体について記述し、次に最初のワインであるカベルネ・ソーヴィニヨンを定義します。
<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）で作られたことが分っています。カベルネ・ソーヴィニヨン（wine.rdfを参照）なので、それが辛口の赤ワインであることが分ります。
データ型プロパティーも、同様の方法で個体に加えることができます。以下では、ヴィンテージ・イヤーのインスタンスを記述し、それをタイプの特定値&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）にも位置しているに違いありません。
プロパティー「P」が対称的であるとタグ付けされれば、任意のxおよびyは以下を満たします。
P(x,y) iff 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）に隣接しており、その逆もまた同様です。メンドシノ地域はカリフォルニア地域に位置していますが、その逆は成り立ちません。
プロパティー「P」が関数型であるとタグ付けされれば、任意のx、yおよびzは以下を満たします。
P(x,y) and P(x,z) implies y = z
ワイン・オントロジーでは、ヴィンテージ・イヤーを持つが関数型です。一つのワインは、たった一つののヴィンテージ・イヤーを持っています。すなわち、与えられた個体ヴィンテージは、ヴィンテージ・イヤーを持つプロパティーを使用して1つの年にのみ関連付けることができます。定義域のすべての要素が値を持つことは、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) iff P2(y,x)
owl:inverseOfの構文は、プロパティー名を引数としてとることに注意してください。A iff 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>
ワインは生産者を持っており、ワインの定義においては、それはワイナリーに限定されています。その結果、それぞれのワイナリーは、そのワイナリーが生産者であるワインの集合を生産します。
プロパティー「P」が、逆関数型（InverseFunctional）であるとタグ付けされれば、すべてのx、yおよびzは以下を満たします。
P(y,x) and P(z,x) implies y = z
前項のワインを製造する（producesWine）が逆関数型であることに注意してください。その理由は、関数型プロパティーの逆は逆関数型でなければならないからです。生産者を持つ（hasMaker）とワインを製造するは以下のように定義することができ、前例と同一の効果を得ることができます。
<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では、inverseFunctionalとしてDatatypePropertyをタグ付けすることができます。これによって一つの文字列がユニーク・キーであると識別することが可能になります。OWL DLではリテラルはowl:Thingと素の関係にあり、これが、なぜOWL DLではInverseFunctionalがDatatypePropertyに適用することが不可能であるかの理由です。
プロパティー特性の指定に加えて、特定の文脈においてプロパティーの値域を様々な方法でさらに制約することができます。プロパティー制約でこれを行います。下記の様々な形式は、owl:Restrictionの文脈中でのみ使用することができます。owl:onProperty要素は、制約されたプロパティーを示します。
プロパティーを作る要素のタイプを制約する方法を既に1つ見ました。今までのメカニズムは、プロパティーのすべてのインスタンスに当てはまるため、グローバルでした。次の2つ、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>
ワインの生産者は、ワイナリーに違いありません。allValuesFrom制約は、このワインクラスの生産者を持つプロパティーのみに働きます。チーズの生産者は、このローカルな制約によって制限されません。
owl:someValuesFromも似ています。上例においてowl:allValuesFromをowl:someValuesFromに入れ替えた場合、ワインの生産者を持つプロパティーの少なくとも1つがワイナリーである個体を指すに違いないことを意味します。
<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> ¬
2つの式の違いは、全称量化（universal）か特称量化（existential）かの違いです。
| 関係 | 含意 |
|---|---|
| allValuesFrom | すべてのワインに対し、それらが生産者を持っている場合、その生産者はすべてワイナリーです。 |
| someValuesFrom | すべてのワインに対し、ワイナリーである少なくとも1つの生産者を持っています。 |
最初のものは、ワインが生産者を持つことを要求しません。1つ以上の生産者を持っている場合、それらはすべてワイナリーでなければなりません。2番目のものは、少なくとも1つの生産者がワイナリーであることを要求しますが、ワイナリーでない生産者があることもありえます。
既にカーディナリティー制約の例を見ました。現在までは、それらは最小のカーディナリティーに関する言明でした。さらに直裁的なのはowl:cardinalityで、関連する要素の数を厳密に指定できます。例えば、きっかり1つのヴィンテージ・イヤーを持つクラスであるヴィンテージを指定します。
<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>
ヴィンテージ・イヤーを持つを関数型プロパティーであると指定しましたが、これは、すべてのヴィンテージが高々1つのヴィンテージ・イヤーを持っていると述べるのと同じことです。カーディナリティー制約を使用してヴィンテージにそのプロパティーを適用することは、すべてのヴィンテージがきっかり1つのヴィンテージ・イヤーを持っているという、より強い言明になります。
OWL Liteには、0または1に制約された値を持つカーディナリティー式があります。これにより、ユーザが「すくなくとも1つ」「高々1つ」および「きっかり1つ」を示すことが可能になりす。OWL DLでは、0または1以外の自然数の値が許されています。owl:maxCardinalityは上限を指定するために使用できます。owl:minCardinalityは下限を指定するために使用できます。この2つを組み合わせて、プロパティーのカーディナリティーを、ある数の範囲に制限するために使用できます。
hasValueによって、特定のプロパティー値の存在に基づいたクラスを指定することが可能になります。したがって、そのプロパティー値の少なくとも1つが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>
ここでは、ブルゴーニュのワインがすべて辛口（dry）であると宣言しています。つまり、それらの糖分がある（hasSugar）プロパティーは、少なくとも1つの辛口と同等の値を持っていなければなりません。
allValuesFromとsomeValuesFromは、ローカルな制約です。ブルゴーニュに適用されるときに、糖分があるに適用できます。
オントロジーが最大の効果を発揮するためには、広く共有される必要があります。オントロジーの開発に対する知的努力を最小限にするために、オントロジーを再利用する必要があります。すべての可能世界（possible worlds）の最良な状態で、それらを構成する必要があります。例えば、ある情報源から日付のオントロジーを採用し、別の情報源から物理的な位置のオントロジーを採用して、それがもつ時間枠を含むように位置の概念を拡張するかもしれません。
オントロジーを開発する努力の多くが含意が最大になるようにクラスとプロパティーを繋げるためにささげられているということを理解することは重要です。クラスのメンバーシップに関する簡潔な言明が、広く有用な含意を持つことが望まれます。これが、オントロジー開発の最も難しい部分です。広く利用され精練された、既存のオントロジーを見つけることができれば、それを採用する価値があります。
オントロジーの集合を合併することは、やりがいがあるでしょう。整合性を維持するためには、ほぼ間違いなくツールのサポートが必要となるでしょう。
構成要素のオントロジーの集合を第3のオントロジーの一部として結合するためには、1つのオントロジーの中の特定のクラスあるいはプロパティーが別のクラスあるいはプロパティーと同等であると示せることは、しばしば有用です。この機能は注意して使用しなければなりません。結合されたオントロジーが矛盾している（すべてのAはBであるのに対し、すべてのAはBでない）場合、結果として生じた結合を満たす外延（個体と関係）は存在しません。
食品オントロジーでは、ダイニング・コースの記述におけるワインの特徴をワイン・オントロジーにリンクしたいです。これを行う一つの方法は、食品オントロジー（&food;Wine）でクラスを定義し、それがワイン・オントロジーの既存のワイン・クラスと同等であると宣言することです。
<owl:Class rdf:ID="Wine"> <owl:equivalentClass rdf:resource="&vin;Wine"/> </owl:Class>
プロパティーowl:equivalentClassは、2つのクラスが全く同じインスタンスを持っていることを示すために使用されます。OWL DLでは、クラスは単に個体の集合を示しており、個体自身ではないことに注意してください。しかしながら、OWL Fullでは、2つのクラス間があらゆる点で同一であることを示すために、owl:sameAsを使用することができます。
もちろん、#Wineを使用するところではどこでも常に&vin;Wineを使用することができ、再定義なしに同じ結果を得ることができるため、上記の例は多少不自然です。よりありうる使用方法としては、2つの独立して開発されたオントロジーに依存するケースで、それらが同じクラスを参照するためにURIのO1:fooとO2:barを使用することに注意してください。owl:equivalentClassは、2つのオントロジーからの帰結を結合することができるように、これらを重なり合わせるために使用することができます。
クラス式が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を使用します。
このメカニズムは、クラスのものに似ていますが、2つの個体が同一であると宣言します。例は、
<Wine rdf:ID="MikesFavoriteWine">
<owl:sameAs rdf:resource="#StGenevieveTexasWhite" />
</Wine> ¬
この例は、あまり有用ではありません。これから学ぶことができるほぼすべてのことは、マイク（Mike）が安いローカルのワインが好きだということです。sameAsのより典型的な使用方法は、2つのオントロジーの統合の部分として、異なるドキュメントで定義されている個体を互いに同等にすることでしょう。
これは、重要なポイントを提起します。OWLは、単一名仮定を持っていません。2つの名前が異なるというだけでは、それらが異なる個体を指すことを意味するとはいえません。
上記の例では、2つの別個の名前の同一性を言明しました。しかし、この種の同一性は推論することも可能です。関数型のプロパティーから導き出すことができる含意を思い出してください。生産者を持つが関数型だとすれば、以下は必ずしも矛盾してはいません。
<owl:Thing rdf:about="#BancroftChardonnay">
<hasMaker rdf:resource="#Bancroft" />
<hasMaker rdf:resource="#Beringer" />
</owl:Thing> ¬
これが我々のオントロジーの他の情報と矛盾しなければ、それは単にBancroft = Beringerを意味します。
2つのクラスを同一にするためにsameAsを使用することは、それらをequivalentClassと同一にするのと同じことではないことに注意してください。その代わりに、それはクラスが個体として解釈される原因となり、それゆえにオントロジーを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>
これは、これらの3つの値が互いに異なると言明する方法の1つです。そのような違いの識別性を保証することが重要な場合があるでしょう。これらの言明がなければ、辛口かつ甘口なワインについて記述することができます。ワインに適用された糖分があるプロパティーが高々1つの値しか持っていないことを述べました。誤ってワインが辛口でもあり甘口でもあると言明すれば、上記の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との組み合わせによってのみ使用することができることに注意してください。
ワインのオントロジーでは、すべてのワイン記述子に対してowl:AllDifferentの言明を提供しました。さらに、複数のワイナリーがすべて異なると述べます。他のあるオントロジーに新しいワイナリーを加え、それが既に定義されているすべてと素の関係にあると言明したければ、オリジナルの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）が厳密にクラスワインと白色の事物との集合の積集合であると述べています。これは、あるものが白色かつワインであるならば、それは白ワインのインスタンスであることを意味します。そのような定義がなければ、白ワインがワインかつ白色であることを知ることは出来ますが、その逆を知ることはできません。これは、個体を分類するための重要なツールです。（「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）を、ブルゴーニュ（Bourgogne）地域と少なくとも1つの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のクラス外延の一部です。
以下の例は、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> ¬
これは、果物のインスタンスが甘い果物と甘くない果物との積集合のサブセットであり、それが空の集合になるだろう、ということを述べます。
complementOf構成子は、あるクラスに属さない個体すべてを議論領域から選び出します。通常、これは、個体の非常に大きな集合を表します。
<owl:Class rdf:ID="ConsumableThing" />
<owl:Class rdf:ID="NonConsumableThing">
<owl:complementOf rdf:resource="#ConsumableThing" />
</owl:Class>
非消耗品（NonConsumableThing）のクラスは、消耗品の外延に属さないすべての個体をメンバーとして含みます。この集合はワイン、地域などをすべて含んでいます。これは文字通り、owl:Thingと消耗品間の差集合です。したがって、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）を定義します。
OWLは、そのメンバーの直接列挙によってクラスを指定する手段を提供します。これは、oneOf構成子を使用して行われます。特に、この定義はクラスの外延を完全に指定し、その結果、他の個体がクラスに属すると宣言することが不可能になります。
以下は、個体白、ロゼおよび赤をメンバーとする、クラスワインの色を定義します。
<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>
ここで最初に分かることは、クラスが列挙によって定義されたため、他の個体が正当なワインの色ではありえないということです。
oneOf構成子の各要素は、正当に宣言された個体でなければなりません。個体は、いずれかのクラスに属さなければなりません。上例では、それぞれの個体は名前によって参照されています。参照を導入するための簡単な表現としてowl:Thingを使用しました。またあるいは、以下のようにして、それらの特定のタイプ、ワインの色、に従って集合の要素を参照することができます。
<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の使用のさらなる例については、参照をご覧ください。
1組のクラスが素であることは、owl:disjointWithコンストラクタを使用して表現することができます。これは、1つのクラスのメンバーである個体が、指定された他のクラスのインスタンスに、同時にはなりえないことを保証します。
<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）の例は、多重な素のクラスを示すものです。これは、パスタがこれらの他のクラスのすべてと素の関係であると言明するだけだということに注意してください。これは、例えば、肉（Meat）と果物が素であるとは言明しません。1組のクラスが互い素であると言明するためには、すべての対に対して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の和集合であると定義します。また、これらのサブクラスは素であるため、果物を2つの異なるサブクラスに厳密に分類することが分かります。互いに素であるクラスの数が増加するにつれ、素であるとの言明の数はn2に比例して増加します。しかし、今までに見た使用例では、nは概して小さいです。
nが大きい場合、言明の数が2乗に比例してに増えるのを避けるために別のアプローチをとることができます。そのような方法の一つは、OWLテスト・スィートで例示されています。
例示の方法は以下のようになります。その要素がカーディナリティーが1と等しいプロパティーを持つ親クラスを記述します。すなわち、各インスタンスは、プロパティーに対して唯一の値を持たなければなりません。次に、親のすべてのサブクラスに対して、そのインスタンスがプロパティーに対する特定のユニークな値を持っていなければならないことを要求します。その場合には、どの異なるサブクラスもメンバーを共有することができません。
オントロジーはソフトウェアのように、維持され、時間とともに変化するでしょう。owl:Ontology要素（上で議論された）の中では、定義済みのオントロジーの前のバージョンにリンクすることができます。owl:priorVersionプロパティーは、このリンクを提供することを目的としており、オントロジーのバージョン履歴を追跡するために使用することができます。
<owl:Ontology rdf:about=""> ... <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine"/> ... </owl:Ontology>
提示されているオントロジーは定義済みのものの前のバージョンです。
オントロジーのバージョンは、互いに互換性を持たないことも可能です。例えば、オントロジーの前のバージョンは、現バージョンと矛盾するステートメントを含むことができます。owl:Ontology要素の中では、前オントロジー・バージョンとの互換性あるいはその不足を示すためにowl:backwardCompatibleWithとowl:incompatibleWithのタグを使用します。owl:backwardCompatibleWithが宣言されていなければ、互換性は見込めません。さらに、owl:versionInfoは、バージョン付けシステムが使用するのに適したフックを提供します。前の3つのタグとは対照的に、owl:versionInfoのオブジェクトは、リテラル、およびオントロジーに加えてクラスとプロパティーにアノテーションを加えるために使用することができるタグです。
多くの意味で、オントロジー全体の粒度でバージョン追跡を行うことは十分ではありません。保守管理者はクラス、プロパティー、個体に対するバージョン情報の維持を望むかもしれませんし、それでも足りないかもしれません。OWLのクラス式の漸進的な性質は、別のオントロジーで定義された（名前付き）クラスに1つのオントロジーが制限を加えるかもしれないことを意味し、これらの追加制限自身はバージョン情報を要するかもしれません。
OWL Fullは、クラスに関するあらゆる種類の言明を作り出す表現力を提供します。つまり、それは別のクラスのインスタンスである、あるいは、それ（そのインスタンスではなく）はプロパティーとそのプロパティーに対する値を持っています。このフレームワークは、バージョン情報を追跡するためのクラスとプロパティーのオントロジーを構築するために使用することができます。OWL名前空間は、この目的のために使用することができる、owl:DeprecatedClassとowl:DeprecatedPropertyという2つの定義済みクラスを含んでいます。これらは、クラスあるいはプロパティーが次回のリリースにおいて互換性のない形に変化うることを示すように意図されています。
...
<owl:DeprecatedClass rdf:ID="&vin;JugWine" />
<owl:DeprecatedProperty rdf:ID="&vin;hasSeeds" />
... ¬
owl:DeprecatedClassとowl:DeprecatedPropertyが付加的セマンティックスを持っていないことが重要で、それらが意図されたとおりに確実に使用できるようになるかどうかはツール開発者およびOWLユーザ次第です。
いったん最初の定義域オントロジーが利用できるようになれば、オントロジーを活用する多くのアプリケーションを開発することができます。この項では、ワインの定義域でいくつかの使用例を説明します。
今日、ワイン・ポータルと自称する多くのサイトが存在しています。例えば、グーグルは「ワイン・ポータル」というクエリーに対し152,000件の検索結果を提供します。上位の検索結果のうちの1つ、「Wine-Portal.com」と呼ばれるサイトは、多くのサイトへのアクセスを提供します。ワイン・ポータルを自称する多くのサイトのほとんどが情報サイトです。例えば、wine-portal.comで最初に紹介されている「コルク・クイジーン」（www.corkcuisine.com/）と呼ばれるサイトは、ワインと食品の相性、ギフト用ワインなどに関する情報を提供します。
トピック・エリアのどれかを熟読することで、情報や、時にはトピックに関するサービスを含んでいるページの集まりを見つけることができます。例えば、「アクセサリーとギフト」は、特別なワインを買うときに何を探すべきかに関する情報を含んでおり、さらに、かなりの数のオンライン小売店を含んでいます。「ショッピング」という別のトップ・レベルのエリアには、ユーザがオンライン（または「ストリート・ショッピング」）ストア（国別に分類された）を見つけることができる「ワイン・ショッピング」という下位エリアがあります。これらの2つのサイトは今日の多くある例の2つに過ぎず、特定のトピック・エリアに関連する情報とサービスの集まりを提供するワイン・ポータルの一般的な概念を代表するものです。
これらのサイトを多少詳細に見ても、それらが今日どれほどオントロジーに依存しているかは明らかではありません。例えば、HTMLのソースを見ても、オントロジーを使用しているという証拠は明らかになりません。しかし、いくつかのワイン・オントロジーが利用できていれば、サイトがオントロジーを開発することができていたことは明らかです。
ポータル・サイトでのオントロジーの簡単な使用法の1つは編成とブラウジングに対するものです。ワインに関連するクラスのトップに位置する少数のレベルから、上記のカテゴリーのリストを生成することができます。クエリを使うと、ワイン・オントロジーを活用してワインに関連する情報を検索することができます。オントロジーに含まれている用語を検索する場合には、より適切な答えを見つけるためにサブクラスの情報を使ってクエリを拡張することができます。トピック・エリアの（候補となる）情報を使って、自ら自動更新するようにポータルを作ることができるかもしれません。非常に強力な推論力で、適当なワイン販売サイトを識別し、ポータルの一部としてそれらを含めるように交渉することすら可能でしょう。
我々は、説明する目的でワイン・エージェントを始めました。初期の設計では、ワイン・エージェントの目標は食事のコースに付け合わせるワインを推奨することでした。このアプリケーションは、このガイドの基礎として使用されているオントロジーを活用します。このワイン・オントロジーは、DAMLオントロジー・ライブラリーで利用でき、ワインというタイトルをつけられています。
パーソナライズされたワイン・エージェントは、人間に多くのサービスを提供することができます。
エージェントは一連の制約（出される食事のような）を与えられたワインを推奨するために使用することができたり、特定のワインや特定クラスのワインに関する情報を見つけることができたり、ワイン用の適切なアクセサリー（そのワインの品種に適した特殊なグラスのような）を探すことができます。
以下に、学生プロジェクトとして書かれている簡単なプロトタイプ・システムでの例について記述します。
以下のシナリオを考えてみてください。
誰かがディナー・パーティーを計画しており、ゲストの少なくとも一人はワインにつて見識があります。ホストは、メニューのコースによく合うワインを出したいと考えています。ホストは、そのイベントで出されるワインに見識があるように見られたいと思っています。さらにホストは、ディナーに適切なアクセサリーを用意しておきたいと考えています。ホストは、メイン・コースとして特製のトマトベースのパスタ・ソースと生パスタを出すことを決めているかもしれません。
食事に適したワインを出すために、ホストはワインと食品の組み合わせに関する情報を必要とします。ワインに見識があるように見られるためには、ホストはイベントに関連するワイン情報にアクセスすれば有益でしょう。適切なワインのアクセサリーを用意しておくためには、ホストはどのアクセサリが状況に合っているか（また、ホストが支払える範囲であるか）に関する情報を得る必要があるでしょう。
ワインのバックグラウンド・オントロジーがあれば、食事の記述を与えられれば、ワイン・エージェントは食事と一緒に出すワインの種類を提案することができます。ワイン・エージェントは、食事に合ったワインの品種のチョイスとしてジンファンデルを提案するかもしれません。さらに、バックグラウンド・オントロジーが与えられていれば、ワイン・エージェントは特定のジンファンデル（おそらくマリエッタ・ジンファンデル）を提案するかもしれません。ワインがジンファンデルであるべきであるという情報が与えられれば、ワイン・エージェントは、ジンファンデルのセレクションか、マリエッタのような特定のジンファンデルを探すことができる場所を探すかもしれません。ワインを購入するための適切な情報源（おそらく、ホストの場所とワイン販売業者の場所でフィルタリングした）を含んでいるバックグラウンド・オントロジーを与えられれば、ワイン・エージェントはwine.comのようなサイトへ行って「ジンファンデル」の検索を行い、そのサイトで売り出されているジンファンデルのリストを返すことができるでしょう。ワイン・エージェントは、ワイナリー自体または他の再販業者からマリエッタ・ジンファンデルを見つけようと試みることができます。例えば、winelibrary.comがマリエッタ・ジンファンデルの1999年ヴィンテージを13.99ドルの割引価格で販売していることを見つける（Googleの検索や選ばれたウェブ・サイトの構造化検索によって）ことができます。ワイン・エージェントは、消費者から提供されたりワインの品種に基づいた提案として提供される、価格帯のような付加的なフィルタリング情報を利用することができました。
今度は、ワイン・エージェントは、ジンファンデル一般に関する情報、または、特別にマリエッタ・ジンファンデルに関する情報を提供しようと試みるかもしれません。特定のワインに関する情報を見つけるためにワイン・サイトのバックグラウンド・オントロジーを使用することができます。例えば、最新のジンファンデルに関するワイナリーの記述が役に立つかもしれません。さらに、ワイン・スペクテイターのような評判の高い情報源のレビューも役に立つかもしれません。好みのワインのレビュー・サイトでマリエッタ・ジンファンデルのレビューが得られない場合、同じ地域（この場合、カリフォルニアのソノマ・カウンティー）のジンファンデルに関するレビューのような関連する情報を探すことが有用かもしれません。
一般的な背景情報も役に立つかもしれません。さらにホストは、ワイン一般あるいは特にジンファンデルに関する本に興味を持っていて、本を読みたいかもしれません。例えば、ホストは、Amazon.comが販売しているジンファンデルのに関する本に興味を持っているかもしれません。また、ホストは、同じ産地のワインに関する情報に興味を持っているかもしれず、 それゆえにソノマ・ジンファンデルに興味を持っているかもしれません。ワイン・エージェントは、その主要な知識領域と関係のある典型的な背景情報を利用できるようにするかもしれません。例えば、このワイン・エージェントは食品とワインの相性に関係があるため、ワイン・スペクテイターの食品とワインの相性に関する記事のような、このトピックに関する無料・有料の両方の情報を持っているかもしれません。
ディナーのホストは、イベントに先立って適切なワイン・アクセサリーを入手したいとも思うかもしれません。ワインはワイン・グラスで出されますが、異なる品種のワインは異なる種類のグラスで出されるのが一番です。例えば、ホストがジンファンデルが合う食事コースを選んだならば、ホストはリーデルがワイン・ガラス器の有名なメーカーであることを知りたいと思うかもしれません。また、ホストは、ワイン・エンスージアスト（ワイン商品の評価の高いサプライヤー）からリンクしれもらい、ワイン・エンスージアストがリーデルのヴィヌム・ジンファンデル・グラスを4脚セットで$63.95で（4脚セットを2組買えば$59.95に値引きして）販売してもらうことを望むかもしれません。 さらに、ホストは、Amazon.comではリーデルのソムリエ・ジンファンデル単脚グラスを$49.99（表示価格は$65.00）で入手できるという情報を得ることに興味を持っているかもしれません。Amazonは、同じヴィヌム・グラスを6脚（ワイン・エンスージアストの4脚の代わりに）のセットで$79.99（表示価格は$119.40）でも販売しています。ワイン・エージェントは、食事に合った（つまり、ジンファンデルを出すのに適した）グラス器の比較表を提供して、オントロジーのプロパティーのリストから選んだ価格や他の基準によって比較できるようにすることが可能です。
ディナーのホストは、他のワイン・アクセサリーを検討したいと思うかもしれません。オントロジーから、栓抜きがワイン・アクセサリーであることが分かっています。バックグラウンド・オントロジーは、栓抜きのサブクラスをコード化するかもしれないし、適切なワイン・サイトからもそのような情報を見つけることができるかもしれません。ワイン・エンスージアストには、お勧めの（型式と価格帯が書かれた）栓抜きのセットがあります。さらに、それらは型式（レベル、ウェイター、固定式、ツイスト、ポンプ）で区別されており、ディナーのホストはそれらの形式に関する情報を得たいと思うかもしれません。
ワイン・エージェントは、ドメインや情報とサービス・サイトのバックグラウンド・オントロジーの知識に依存する多様なレベルの高度な知識に関わるようになるかもしれません。この例では、ワイン、品種、食品とワインの組み合わせ、いくつかのワイン・アクセサリーと関連するプロパティーの情報を活用しただけです。もちろん、顧客によるより多くの情報とより多くの制約を含めるために、これを拡張することができます。
このワイン・エージェントの発展例が利用可能です。
このドキュメントは、総じてウェブ・オントロジー・ワーキンググループ内で積み重ねられた議論の結果です。このワーキンググループのメンバーは、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、John Yanosyです。
複合制約に関するいくつかの重大な初期のテキストがForschungszentrum Informatik（FZI）のRaphael Volzによって書かれました。DAML+OIL Walkthruから重要な洞察が得られました。Jeremy Carroll、Jerome Euzenat、Jeff Heflin、Kevin PageとPeter F. Patel-Schneiderが広範囲なレビューを提供してくれました。2002年の10月8日のWG Face to Faceでは、Stephen Buswell、Ruediger Klein、Enrico MottaとEvan Wallaceが、重要な変更をもたらしたオントロジーの詳細なレビューを提供してくれました。2003年1月10日のWG Face to Faceでは、Jonathan Dale、Bernard Horan、Guus SchreiberとJeff Heflinが、変更をもたらした「ガイド」の詳細なレビューを提供してくれました。パブリック・レビューにより多くの有用な提案と修正が加えられました。
| 用語 | 項 |
|---|---|
| anonymous class（匿名クラス） | 3.2.1. |
| class（クラス） | 3.1.3. |
| cardinality（カーディナリティー） | 3.4.2. |
| complement（補[集合]） | 5.1.3. |
| datatype（データ型） | 3.2.1. |
| datatype property（データ型プロパティー） | 3.2.1. |
| domain（定義域） | 3.2.1. |
| entailed（含意される） | 1. |
| enumerated（列挙型） | 5. |
| extension（外延） | 3.1. |
| instance of（インスタンス） | 3.1.3. |
| intersectionOf（積[集合]） | 5.1.1. |
| imports（インポート） | 2.2. |
| individual（個体） | 3.1.3. |
| instance（インスタンス） | 3.1.3. |
| monotonic（単調） | 2. |
| object properties（オブジェクト・プロパティー） | 3.2.1. |
| ontology（オントロジー） | 1. |
| open world（開世界） | 2. |
| OWL DL | 1.1. |
| OWL Full | 1.1. |
| OWL Lite | 1.1. |
| property（プロパティー） | 3.2.1. |
| range（値域） | 3.2.1. |
| restriction class（制約クラス） | 3.4.1. |
| union（和[集合]） | 5.1.2. |
| unique names（単一名） | 4.2. |
OWLの構文とセマンティックスを完全に理解するためには、以下にリストアップされた関連するW3CとIETFの標準の基礎に精通しているべきです。下記の最初の2つのリンクによって、XMLとRDFの最小限のガイドが提供されます。
Resource Description Framework（RDF）は、任意の資源に関するセマンティックな情報を表すためにW3Cによって規定された最初の言語です。RDFスキーマ（RDFS）は、RDF語彙を記述するためのRDF拡張のW3C勧告候補です。RDFSはオントロジーを作成するために使用できますが、意図的に軽量であり、OWLより表現力がありません。
OWLのように、RDFSはプロパティーの値域と定義域の制約と同様にクラスとプロパティーを含んでいます。それは、クラスとプロパティーの両方に継承階層を提供します。それがリリースされた時には、ユーザはデータ型、列挙、プロパティーをより厳格に定義する能力を含む追加機能を要求し始めました。
研究コミュニティーにおけるその他の取り組みで、まさにこのような機能が既に検討されていました。この背景をより深く徹底的に調べたい人々のために、プロジェクトと言語の部分的なリストには以下が含まれます。
OILとDAML-ONTの両方の取り組みの主要メンバーの多くを含む研究者グループが、セマンティック・ウェブのための別個のオントロジー言語を持続する代わりに新しいウェブ・オントロジー言語を作成しようと、Joint US/EU ad hoc Agent Markup Language Committeeに集まりました。OILとDAML-ONTの両方の上に構築されたDAML+OILというこの言語は、OWLの提案根拠としてW3Cに提出され、その後にOWLの出発点として選ばれました。
オントロジー言語に加え、様々な分類や既存のオントロジーが既に商業利用されています。電子商取引サイトでは、それらは買い手と売り手の間のマシンベースのコミュニケーションを促進し、市場の垂直統合を可能にし、異なる市場で再利用される記述を可能にします。実際に商業利用でオントロジーを作っているサイトの例には、以下が含まれます。
完全に凝集するように結びつけることが困難でありうる、現代医療および生化学の圧倒的な量の研究データの管理をサポートしようと、様々な医学や薬品関連のオントロジーが開発されています。主要な資源の1つは、以下のオントロジーを定義している遺伝子オントロジー・コンソーシアムです。
そのサイトは、以下のオントロジーに対する指示子も持っています。
今日使用されている大きな分類で、OWLスペースへ拡張できるところまできているものがあります。例えば、North American Industry Classification System（NAICS）は、業種を識別する1900項目以上の階層を定義します。NAICSも、国連が開発・維持する、International Standard Industrial Classification System（ISIC、改定3）と連携しています。