【注意】 このドキュメントは、W3CのOWL Web Ontology Language Use Cases and Requirements W3C Recommendation 10 February 2004の和訳です。
このドキュメントの正式版はW3Cのサイト上にある英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。
First Update: 2003年5月23日
このドキュメントに対する正誤表を参照してください。いくつかの規範的な修正が含まれているかもしれません。
翻訳版も参照してください。
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
このドキュメントは、ウェブ・オントロジー言語に対する使用シナリオ、目標および要件を定めています。オントロジーは、領域を記述し表現するために使用される共通の用語の集合を正式に定義するものです。オントロジーは、自動ツールによって、より正確なウェブ検索、知的ソフトウェア・エージェント、ナレッジ・マネジメントといった高度なサービスを強化するために使用することができます。
このドキュメントは、W3Cメンバーおよび他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。
これは、6つからなるOWL、ウェブ・オントロジー言語のW3C勧告の1つです。2004年2月10日の公開に向けてW3Cセマンティック・ウェブ・アクティビティ（アクティビティ声明、グループ憲章）の一部としてウェブ・オントロジー・ワーキンググループによって開発されてきたものです。
これらのドキュメントの初期バージョンで示されたOWLの設計は広くレビューされており、ワーキンググループの技術要件を満たします。ワーキンググループは、必要に応じて変更を加えながら受理した全てのコメントに取り組みました。勧告案バージョン以後のこのドキュメントに対する変更の詳細は、変更履歴に記述されています。
コメントは[email protected]（アーカイブ）で歓迎され、関連技術の一般的な議論は[email protected]（アーカイブ）で歓迎されます。
実装のリストが利用可能です。
W3Cは、この事業に関するあらゆる特許の開示のリストを維持します。
この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物および技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスで見つけることができます。
セマンティック・ウェブは、情報に明示的な意味を与え、ウェブ上で公開されている情報を機械がより簡単に自動的に処理し統合するという将来のウェブに対する一つのビジョンです。セマンティック・ウェブは、カスタマイズされたタグ・スキームを定義するXMLの性能[XML]およびRDFのデータ表現に対する柔軟なアプローチ[RDF Concepts]の上に築き上げられるでしょう。次にセマンティック・ウェブに要求される要素は、ウェブ・ドキュメントの中で使用されるクラスおよびプロパティのセマンティクスを形式的に記述できるウェブ・オントロジー言語です。機械がこれらのドキュメントにおいて有効な推論タスクを実行するためには、オントロジー言語はRDFスキーマの基本的なセマンティクスの枠組みを超えるものでなければなりません。[RDF Vocabulary]
このドキュメントは、OWL（ウェブ・オントロジー言語）の仕様の1部分です。OWL概要ドキュメントのドキュメント・ロードマップの項は、それぞれの別のドキュメントについて記述します。このドキュメントでは、ワーキンググループが認識しているウェブ・オントロジー言語の要件を列挙します。しかし、将来の言語は、数ある中でも、より大きな論理機能とセマンティック・ウェブの信頼性を確立する性能を追加して、OWLを拡張することが期待されます。
我々は、6つのユースケースを記述することによりウェブ・オントロジー言語の必要性を動機づけます。これらのユースケースは産業と学術研究の場において現在進行している試みに基づいているものもあれば、より長期的な可能性を示すものもあります。ユースケースの次には、オントロジー言語開発のためのハイ・レベルな目標とガイドラインを記述した設計目標が続きます。この設計目標は、提案された機能を評価する際に検討されるでしょう。要件の項では、オントロジー言語に盛り込まれているべきである一連の機能を示し、それらの機能に対して動機づけを与えます。目的の項では、多くのユースケースに役立つ機能のリストについて記述しますが、このワーキンググループによって扱われるとは限りません。
ウェブ・オントロジー・ワーキンググループ憲章は、より表現力のあるセマンティクスを作り出し、数やタイプに関するクラスのプロパティを制限する手段、様々なプロパティを持つアイテムが特定のクラスのメンバーであると推論する手段、明確に定義された（well-defined）プロパティ継承（property inheritance）の一モデル、そして、基礎言語に対する同様のセマンティック拡張群を含む「エンティティ間の、より複雑な関係」を、オントロジー言語が提供できるメカニズムを特定するというタスクをそのグループに課します。ウェブ・オントロジー言語の詳細な仕様は、以下を考慮に入れるでしょう。
オントロジーは、知識の一分野について記述し表現するために使用される用語を定義するものです。オントロジーは、領域情報（領域とは、医学、工具生産、不動産、自動車修理、財務管理などのような、ある特定の主題分野あるいは知識の一分野にすぎない）を共有する必要のある、人々、データ・ベースおよびアプリケーションによって利用されます。オントロジーは、領域の基本概念と、概念間の関係に対するコンピューターが扱える形の定義を含んでいます（この部分またはこのドキュメントの全体にわたって、定義は論理学者が解釈している技術的な意味で使われるわけではないことに注意して下さい）。オントロジーは、ある領域の知識、および、複数の領域にまたがる知識をコード化します。このようにして、オントロジーはその知識を再利用できるようにします。
オントロジーという言葉は、程度の異なる構造を持つアーティファクトを記述するために使用されてきました。これらは、単純な分類（Yahooの階層のような）からメタデータ・スキーム（ダブリン・コアのような）、論理的な理論にまで及びます。セマンティック・ウェブは、かなり大きな構造を持ったオントロジーを必要とします。これらのオントロジーは、以下のような概念に対する記述を定める必要があります。
オントロジーは通常、クラス、プロパティーおよび関係の間で、詳細かつ正確で、整合性があり、そして信頼できて意味深い区別を行うことができるように、論理に基づいた言語で表現されます。いくつかのオントロジー・ツールはオントロジーを利用して自動推論を実行し、それゆえに、概念/セマンティック探索および検索、ソフトウェア・エージェント、意志決定支援、スピーチおよび自然言語理解、ナレッジ・マネジメント、知的データ・ベース、および電子商取引といった知的アプリケーションに高度なサービスを提供することができます。
ドキュメントのセマンティクスを表現し、ウェブ・アプリケーションと知的エージェントがセマンティクスを利用できるようにする一つの方法として、オントロジーは、新しく出現してくるセマンティック・ウェブの中で重要な位置を占めます。オントロジーは、現在収集・標準化されているメタデータ用語の意味を構造化し定義する一つの方法として、あるコミュニティーにとって非常に有益であると判明することがあります。オントロジーを使うと、人間の概念レベルでより正確に機能することができるという意味で、将来のアプリケーションは「知的」になりえます 。
オントロジーは、横断検索や、多種多様なコミュニティーからの情報の統合を目指しているアプリケーションにとって極めて重要です。XML DTDとXMLスキーマは、前もって定義に同意した団体間のデータ交換には事足りますが、セマンティクスがなければ、新しいXML語彙を付与された時に、機械がこのタスクを確実には実行できなくなります。同じ用語が、異なる文脈において（時には、わずかに）異なる意味で使われるかもしれませんし、異なる用語が同じ意味を持っているアイテムに対して使われるかもしれません。RDFおよびRDFスキーマは、シンプルなセマンティクスを識別子に関連付けることにより、この問題へのアプローチを開始します。RDFスキーマを用いると、多数のサブクラスとスーパークラスを持つクラスを定義でき、プロパティ（サブプロパティ、定義域および値域を持っている）を定義することができます。この意味では、RDFスキーマはシンプルなオントロジー言語です。しかし、多数の、自律的に開発され、管理されたスキーマの間の相互運用を達成するためには、より豊かなセマンティクスが必要とされます。例えばRDFスキーマは、人と自動車のクラスは共通部分を持たない（disjoint）ことや、弦楽四重奏団は、きっかり4人のミュージシャンをメンバーとして持っているということを示すことができません。
この文書の目標の1つは、ウェブ・オントロジー言語に何が必要かを示すことです。ウェブのユニークな環境に対してオントロジーの標準概念を適用することの困難さを考慮に入れた、可能性のあるユースケースと一般的な設計目標が、これらの要件を動機付けるでしょう。
オントロジーは既存のウェブ・ベースのアプリケーションを改善するために使用することができ、ウェブの新しい使い方を可能にしえます。この項で、我々はウェブ・オントロジーの6つの代表的なユースケースについて記述します。これは網羅的なリストではなく、興味深いユースケースの一断面であることにご留意下さい。これらのユースケースは、OWL言語の要件を選択する際のガイドラインとしての役割をはたしました（セクション4を参照してください）。要件は、OWL憲章や他の設計上の制約の範囲を考慮しながら、ワーキンググループが最も重要だと考えたユースケースの見地に基いて選ばれました。そのため、OWLがユースケースのすべての側面を直接サポートするだろうと仮定してはなりません。
ウェブ・ポータルは、例えば特定の都市や関心領域などのような、ある共通のトピックに関する情報コンテンツを提供するウェブサイトです。ウェブ・ポータルは、あるトピックに興味のある個人が、ニュースを受け取り、互いに見つけて話し合い、コミュニティーを構築し、共通の関心事に関する他のウェブ資源へのリンクを見つけることを可能にします。
ポータルが成功するためには、興味深いコンテンツを見つけるための起点でなければなりません。通常、このコンテンツは、コミュニティーのメンバーによって投稿され、しばしば、彼らはそれを、あるサブトピックの下にインデキシングします。コンテンツ収集のもう一つの手段は、配信する際に使用できる情報をコンテンツ提供者がコンテンツにタグ付けするという行為に依存します。通常、これは、コンテンツのトピックなどを識別するシンプルなメタタグの形をとります。
しかし、主題分野の簡単なインデックスは、メンバーが要求するコンテンツを検索するのに十分な性能をコミュニティーに提供しないかもしれません。より知的な配信を可能にするために、ウェブ・ポータルはコミュニティーに対するオントロジーを定義することができます。このオントロジーは、そのオントロジーの他の用語を使って用語を定義する、コンテンツと公理（aximos）を記述するための用語を提供することができます。例えば、オントロジーは、「ジャーナル紙」、「出版物」、「人」および「著者」のような用語を含んでいるかもしれません。このオントロジーは、「すべてのジャーナル紙は出版物である」、あるいは「すべての出版物の著者は人である」というような事柄を述べる定義を含んでいる可能性があります。事実（facts）と結びつく時には、これらの定義によって必然的に真実である他の事実を推論することが可能になります。次に、これらの推論によって、ユーザは、従来の検索システムからは得られない検索結果をそのポータルから得られるようになります。そのような技術は、コンテンツの提供者が質の高いオントロジーの関係を捕らえるためにウェブ・オントロジー言語を使用するという行為に依存し、OWLの目的は、十分に豊かで有用なメタデータ・コンテンツによって、必要とされる取り組みが動機づけられるようにすることです。この取り組みを最小限にすることは別の課題で、それによって、少しも情報生成プロセスの干渉がない部分としてメタデータを捕らえることが容易になるならば、オントロジー言語は恐らくより大きな効果を持つでしょう。
オントロジーに基づいたポータルの一例は、OntoWebです。このポータルは、オントロジー研究に興味を持っている学者および産業コミュニティーのためのサービスです。セマンティック・ウェブ技術を利用し、オントロジー言語の恩恵を受けうるポータルの別の例は、The Open Directory Project（膨大かつ包括的な人手によって編集されたウェブ・ディレクトリ）です。これは、ボランティア編集者の巨大な世界的コミュニティーによって構築・維持されています。The Open Directory ProjectのRDFダンプはダウンロード可能です。
オントロジーは、画像、音声、あるいは、他の非テキスト・オブジェクトのコレクションに対してセマンティックなアノテーションを付与するために使用することができます。機械が自然言語テキストからセマンティクスを抽出することよりも、マルチメディアから意味のあるセマンティクスを抽出することのほうが困難です。したがって、この種の資源は通常、キャプションやメタタグによってインデキシングされます。しかし、異なる人々が異なる方法でこれらの非テキスト・オブジェクトを記述できるため、検索機能は単純なキーワード・マッチングを超えるものであることが重要です。理想的には、オントロジーは、画像検索を改良するために使用できる領域に関する付加的な知識を獲得するでしょう。
マルチメディア・オントロジーは、メディア特化（media-specific）とコンテンツ特化（contents-specific）の2つのタイプである可能性があります。メディア特化のオントロジーは、異なるメディア・タイプの分類法（taxonomy）を持つことができ、異なるメディアのプロパティーを記述することができます。例えば、ビデオは、クリップの長さと場面の変わり目を識別するためのプロパティーを含んでいるかもしれません。コンテンツ特化のオントロジーは、セッティングや関係者のような、資源の主題を記述することができます。このようなオントロジーはメディアに特化したものではないので、同じ領域を扱う他のドキュメントがそれらを再利用できる可能性があります。このような再利用は、資源のフォーマットにかかわらず、特定の主題に関する情報を単純に探す検索を強化するでしょう。メディア・タイプが重要な検索では、メディア特化とコンテンツ特化のオントロジーを組み合わせることができます。
マルチメディア・コレクションの例として、アンティーク家具の画像アーカイブについて考えてみましょう。アンティーク家具のオントロジーは、そのようなアーカイブの検索に大いに役立つでしょう。異なる種類の家具を分類するために分類法を使うことができます。オントロジーが定義的な知識を表現することができればさらに役立つでしょう。例えば、インデックス作成者が、（例えば）アンティークの整理だんすの様式/時代に対して、「後期ジョージ王朝様式」という値を選択する場合、データ要素「date.created」は、A.D.1760年から1811年の間の値を持っているべきで、「文化」は英国であると推論することが可能であるべきです。この種の背景知識が入手できれば、検索に対するものと同様にインデキシングに対しても提供することができるサポートが極めて大きくなります。役に立ちうるもうひとつの機能は、デフォルト知識の表現に対するサポートです。このような知識の例は、「後期ジョージ王朝様式の整理だんす」は、他の情報がなければ、マホガニー製であると推測されるということでしょう。この知識は実際のセマンティック・クエリーには極めて重要で、例えば、画像のアノテーションに木材の種類に関して何も書かれていなくても、「アンティーク・マホガニー収納家具」というユーザのクエリーを後期ジョージ王朝様式の整理だんすの画像にマッチさせることができます。
大企業は通常、プレス・リリース、製品紹介とケース・スタディー、社内手順、内部製品報告と比較、白書、そして、プロセス記述のような事柄に関する多数のウェブ・ページを持っています。これらのドキュメントをインデキシングし、よりよい検索の手段を提供するためにオントロジーを使用することができます。多くの大組織は、自分達の情報を整理するための分類法（taxonomy）を持っていますが、これは大抵の場合、不十分です。構成要素のカテゴリーが、領域の1つの見識や1つの粒度を表すものに制約されてしまいそうなため、オントロジーにはしばしば限界があります―同時に多数のオントロジーが連動する性能があれば、記述の豊かさが増すでしょう。さらに、たいていの場合、異なるパラメータ値で検索する性能のほうが、分類法を用いたキーワード検索より有用です。
オントロジーが使用可能なウェブサイトは、以下によって利用される可能性があります。
これらのタイプのそれぞれのユーザに特有の問題は、彼らが、求めるコンテンツの作者達と用語を共有していないということです。セールスマンは望まれる機能の専門的な名称を知らないかもしれないし、異なる分野の技術者達は同じ概念に対して異なる用語を使用しているかもしれません。そのような問題については、それぞれのクラスのユーザが異なるオントロジー用語を持っていても、自動的に翻訳が実行されるようにそれぞれのオントロジーを相互に関係づけると有効的です。
もうひとつの問題は、正しいレベルの抽象（abstraction）でクエリーを組み立てることです。オペレーティング・システムの専門家を探しているプロジェクト・リーダーは、Unixとウインドウズの両方の専門家である従業員を見つけることができるべきです。
大規模なサービス機関の一面は、それが非常に大きな能力を持っているかもしれないということです。しかし、大きな契約を推し進める際には、これらの能力を時々、新しい方法で組み直す必要があります。たいていは、予めこれしかないというようなプロジェクトはありません。一連の様々な必須条件を満たしている間に、新しい設定で過去のテンプレートおよびドキュメントをどのように再構築できるかについて推論することが課題となります。
このユースケースは、航空宇宙業界によって使用されるような、膨大な工学ドキュメンテーションのためのものです。このドキュメンテーションは、設計ドキュメンテーション、製造工程ドキュメンテーションおよびテスト工程ドキュメンテーションを含むいくつかの異なる種類で構成されています。これらのドキュメントの集合はそれぞれ、階層構造を持っていますが、集合によって構造が異なっています。さらに、ドキュメンテーションの集合をクロスリンクさせる暗黙の軸（implied axes）もあります。例えば、航空宇宙の設計ドキュメントでは、翼桁のような項目は、どのドキュメントにも出現する可能性があります。
オントロジーは、表される項目、項目間の関連性、項目の特性、および、それらを記述し定義するドキュメンテーションへのリンク（つまり、モデル中の項目の存在に対する外的根拠）に基づいて情報空間の探究を可能にする情報モデルを構築するために使用することができます。つまり、オントロジーと分類法は、それらが表す物理的な項目から独立しているわけではなく、提携して開発/探究されているかもしれないということです。
このユースケースの具体例は、航空宇宙領域の設計ドキュメンテーションで、典型的なユーザには以下が含まれます。
この種の利用をサポートするためには、制約を定義できることが重要です。これらの制約は、検索を強化したり整合性をチェックしたりするために使用されるかもしれません。制約の一例は、以下のようである可能性があります。
biplane(X) => CardinalityOf(wing(X)) = 2 wingspar(X) AND wing(Y) AND isComponentOf(X,Y) => length(X) < length(Y)
この種のオントロジーのもうひとつの一般的な使い方は、特定オブジェクト（例えば、クラスまたはインスタンス）を中心とする情報空間のスナップショットを表す図表のビジュアル化と編集をサポートすることです。これらは通常、アクティビティー/ルール図あるいはエンティティ関係図です。
セマンティック・ウェブは、エージェントに多様な情報資源を理解し統合する性能を提供することができます。具体例は、社会活動プランナーのもので、ユーザの嗜好（どのような種類の映画が好きかとか、どんな種類の食物が好きかなど）を調べ、その情報をユーザの夜の行動を計画するために利用することができるというものです。これらの行動を計画するタスクは、提供されているサービス環境の豊かさとユーザのニーズに依存するでしょう。サービスの決定/マッチングの過程で、ユーザの好みによりマッチするものを見つけるために格付けや評価サービスを利用するかもしれません（例えば「最上のもの」を見つけるために映画やレストランの評価や格付けを調べます）。
この種のエージェントは、レストラン、ホテルなどに対する用語を表す領域オントロジー（domain ontology）と実際のサービスで使われる用語を表すサービス・オントロジー（service ontology）を必要とします。これらのオントロジーによって、ユーザの好みを識別しバランスをとるために必要な情報をアプリケーションが獲得することが可能になるでしょう。そのような情報は、ポータル、サービスに特化したサイト、予約サイトやウェブ全般のような多数の情報源から提供されるかもしれません。
Agentcitiesは、インターネット全域に分散しているサービス環境におけるエージェントの使用を模索しているイニシアティブの一例です。これは、サンフランシスコやベイエリアのような、現実または仮想の都市を表すエージェント・プラットフォームのネットワークを構築し、それらの都市のサービスで人々を居住させることを含んでいます。最初は、これらのサービスは、ホテル、レストラン、エンターテインメントなどのような対消費者（Business to Consumer）サービスに向けられるでしょうが、最終的には、給料支払のような対ビジネス（Business to Business）サービスや、対企業サービス（Business to Enterprise）を含むように拡張されるでしょう。これには多くの異なる領域オントロジーとサービス・オントロジーが必要となるでしょう。主要な課題は以下を含んでいます。
ユビキタス・コンピューティングは、パーソナル・コンピューティングの新しいパラダイムで、専用コンピュータ機器から、我々の日常の環境に組み込まれたパーベイシブ・コンピューティング性能への転換によって特徴づけらます。ユビキタス・コンピューティングの特徴は、小さくて、携帯型の、ワイアレス・コンピューティング機器であることです。広汎性と無線であるという機器の性質は、自動設定とアドホックな設定をサポートすることをネットワーク・アーキテクチャーに要求します。自動設定の開発のもう一つの理由は、この技術が普通の消費者に向けられるからです。
本当のアドホック・ネットワークの主要技術は、サービス発見（service discovery）、つまり「サービス」（つまり、携帯電話、プリンタ、センサーなどのような様々な機器によって提供される機能）を他人が、記述し、広告し、発見できるという機能です。現在のサービス発見と機能記述のメカニズム（例えばサンのJINI、マイクロソフトのUPnP）はすべて、アドホック表現スキームに基づいており、 標準化（つまり、人が通信または議論を求める全てのものを事前に識別すること）に極度に依存します。
ユビキタス・コンピューティングの主要問題（および目標）は「予期せぬ相互運用性（serendipitous interoperability）」であり、「演出なし」の条件下での相互運用性です。つまり、連動するようには必ずしも設計されていない機器（異なる目的で、異なる製造業者により、異なる時期などに構築されたもののように）が、お互いの機能を発見し、それを利用することができるべきです。本格的なユビキタス・コンピューティングのシナリオは何百でないとしても多数の機器を巻き込み、事前に使用シナリオを標準化することは手に余る作業であるため、他の機器を「理解」できること、そして、それらのサービス/機能について推察できることが必要です。
相互運用シナリオは、本質的に動的で（つまり、機器の所有者が、ある部屋や建物から別の場所へ機器を運ぶと同時に、現われたり消えたりする）、（再）設定に関する限り人間を介在しません。サービスの利用に関連するタスクは、発見、契約、合成を含んでいます。サービスの契約は、補償に関する詳細（サービスの提供者は提供されたサービスに対する代償を支払われなければならないかもしれない）に関する情報と同様に、セキュリティ、プライバシーおよび信頼に関する情報の表現を含んでいるかもしれません。特に、企業あるいは組織のセキュリティ・ポリシーを、アプリケーションに依存しない形で表現し、それゆえに多様な実施メカニズム（例えば、ファイアウォール、フィルタ/スキャナ、交通モニター、アプリケーション・レベル・ルーターおよび負荷分散装置）にまたがった制約表現を可能にすることが目標です。
したがって、オントロジー言語は、装置の特性、そのような機器へのアクセスの手段、機器使用のために所有者が定めた政策、および、ユビキタス・コンピューティング・ネットワークへの機器の組み入れに影響を与える他の技術的な制約および要件について記述するために使用されるでしょう。機器特性に関する情報を表現するためのDAML-S（特にオントロジー言語の表現力を取り巻く問題）とRDFに基いたスキーム（すなわち、W3CのComposite Capability/Preference Profile（CC/PP）とWAPフォーラムのユーザ・エージェント・プロフィール、あるいはUAProf）に対して確立されたニーズは、このユースケースや、動的にアドホック・ネットワークを交渉して形成するアプリケーションをサポートする資源インフラストラクチュアに直接関連しています。
設計目標は、どのような単一のユースケースにも必ずしも起因しない、オントロジー言語の一般的な動機づけを表すものです。ユースケースと並んで、これらは、第4、5項の要件と目的を動機づけます。この項では、ウェブ・オントロジー言語の8つの設計目標、特に以下を扱うものについて言及します。
それぞれの目標については、それがサポートするタスクについて言及し、目標の論理的根拠について説明しますさらに、RDFおよびRDFスキーマが目標をサポートする度合いについても説明します。
オントロジーは公的に利用可能であるべきで、異なるデータ・ソースが共有化された意味で同じオントロジーに関係づけることができるべきです。さらに、オントロジーは定義を追加するために他のオントロジーを拡張できるべきです。
サポートされるタスク:
分散データ・ソースが共有の用語を使用するユースケース。
正当性:
相互運用には、用語の定義における合意が必要です。オントロジーは、識別子の標準セットとそれらの識別子の形式記述を提供することができます。同じオントロジーに関係づけられているデータ・ソースは、同じ意味で同じ識別子を使用することに明示的に合意します。
多くの場合、オントロジーの共有では十分ではありません。ある団体は、既存のオントロジーは、彼らが必要とするものの90%は提供するけれども、残りの10%が非常に重要だということに気づくかもしれません。りに、既存のオントロジーを拡張して、望ましい識別子や定義を加えたオントロジーを作成することが可能であるべきです。
RDF(S)サポート:
RDFでは、それぞれのスキーマは、URIによって識別される独自の名前空間を持っています。スキーマのそれぞれの資源はIDを持ち、グローバルに一意な識別子はIDと名前空間のURIとの組み合わせにより作られます。このURIを使用するあらゆる資源は、そのスキーマに定義されているとおりに用語を参照します。しかし、RDFは、多数のスキーマに部分的な定義を持っている用語の定義においては明確ではありません。その仕様は、ソースにかかわらず、その定義が同じ識別子を使用するすべての記述を結合したものだとみなしているように見えます。しかし、これは、分散環境下で問題を引き起こすかもしれませんし、いくつかのスキームは不正確あるいは誤った定義を含んでいるかもしれません。RDFでは、ある資源が定義のどのセットに一致しているかを指摘することはできません。
オントロジーは、長い期間の間に変化するかもしれません。データ・ソースは、それが関係づけられているオントロジーのバージョンを指定するべきです。
重要な問題は、オントロジーの1つのバージョンに関係づけられたドキュメントが、別のもう1つのバージョンに関係づけられたものと互換性を持つかどうかということです。互換、非互換の両方の改版が許されるべきですが、この2つを区別することが可能であるべきです。形式記述は、ほとんどの識別子の意味に対して推定を加えることしかできないため、改版によって、その形式記述を変更せずに識別子の意図する意味を変更することが可能だということに注意して下さい。したがって、セマンティックの下位互換性（backwards-compatibility）の決定には、用語記述の単純な比較以上のものが必要とされます。そのため、オントロジーの作者は、そのような変更を明示的に表すことができる必要があります。
サポートされるタスク:
オントロジーが潜在的に変化しうるユースケース、特にオントロジーの所有者がデータの供給者と異なっているもの。
正当性:
ウェブは絶えず成長し変化しているため、はオントロジーも同様に変化することを予期しなければなりません。オントロジーが変化する必要がある可能性があるのは、以前のバージョンにエラーがあった場合や、領域をモデル化する新しい方法が好まれた場合や、あるいは、新しい用語が作成された（例えば、新技術の発明の結果として）場合です。ウェブ・オントロジー言語はオントロジーの改版を受け入れることができなければなりません。オントロジーの進化は、それはオリジナルのオントロジーを変えないオントロジーの拡張とは異なることに注意が必要です。
RDF(S)サポート:
RDFスキーマの仕様は、スキーマの各バージョンが自身のURIを持った個別の資源であることを推奨しています。rdfs:subClassOfとrdfs:subPropertyOfプロパティーは、古いバージョンに新しいバージョンのクラスとプロパティを関連付けるために使用することができます。しかし、これには誤った定義を取り消すことができないという欠点があります。例えば、スキーマv1において、v1:Dolphinはrdfs:subClassOf v1:Fishとなっていると仮定します。この誤りに気づいた場合、新バージョンのスキーマであるv2は、v2:Dolphinはrdfs:subClassOf v2:Mammalだと述べます。しかし、もし、v2:Dolphinをrdfs:subClassOf v1:Dolphinにすれば、v2:Dolphinはrdfs:subClassOf v1:Fishということになり、エラーを永続化させてしまいます。
異なるオントロジーは、異なる方法で同じ概念をモデル化するかもしれません。オントロジー言語は、異なる表現を関連付け、それによって、データが異なるオントロジーに変換されることを可能にし、「オントロジーのウェブ」を可能にするためにプリミティブを提供するべきです。
サポートされるタスク:
異なる用語を持った異なる供給者からのデータを統合しなければならないユースケース。
正当性:
オントロジーの共有化とオントロジーの拡張は、異なる組織と領域の間のある程度の相互運用性を許しますが、同じ情報をモデル化する多数の方法があるという事例がしばしばあります。これは、異なる組織、異なる職業、異なる国籍などにおける見方の違いによるものかもしれません。機械が異種のオントロジーに関係づけられている情報を統合できるようになるためには、オントロジーが概念を他のオントロジーの同等の概念にマッピングできるようにするプリミティブが必要です。
RDF(S)サポート:
RDFは、rdfs:subClassOfとrdfs:subPropertyOfプロパティーによって、相互運用性に対して最小限のサポートしか提供しません。
異なるオントロジーあるいはデータ・ソースは矛盾しているかもしれません。これらの矛盾を検出することが可能であるべきです。
サポートされるタスク:
データの分散と管理権者の欠如がデータの矛盾をもたらしうるようなユースケース。一貫性のない記述をもたらすかもしれないオントロジーの拡張タスク（恐らく、制約が大きすぎる概念を生成するという方法でオントロジーを拡張することによって）。
正当性:
ウェブは分散していて、誰でも何でも発言できます。その結果、異なる視点は矛盾しているかもしれませんし、誤った情報が提供されることさえあるかもしれません。エージェントが相容れないデータを結合したり、整合性のあるデータを矛盾した状態へ転じさせるの防ぐために、矛盾を自動的に検知できることが重要です。
RDF(S)サポート:
RDFとRDFSでは、矛盾が表現されることは許されません。
オントロジー言語は多種多様な知識を表現することができるべきですが、さらに、それを推論する効率的な手段を提供するべきです。これらの2つの要件は通常は反目し合っているため、ウェブ・オントロジー言語の目標は最も重要な種類の知識を表現するための性能をサポートするバランスを見つけることです。
サポートされるタスク:
大きなオントロジーや大きなデータ集合を使用し、多様な知識の表現を要求するユースケース。
正当性:
ウェブ上には10億以上のページが存在し、組み込み装置やエージェントに対するセマンティック・ウェブの潜在的なアプリケーションは、より大量な情報を処理することを課します。ウェブ・オントロジー言語は、大きさにうまく適応できる推論システムをサポートするべきです。しかし、ユーザが自分たちのアプリケーションにとって重要な種類の知識を記述できるように、オントロジー言語は可能な限りの表現力を持っているべきでもあります。
表現力は、オントロジー言語で何を述べることができるかを決定し、それゆえに、その推理力と、その言語を完全に実装したシステムにどのような推論性能が期待できるかということを決定します。表現力のある言語は、多様な知識を形式化させうる豊かなプリミティブの集合を含んでいます。あまりに乏しい表現力しか持たない言語は、役に立つ推論の機会をあまりに少ししか提供せず、既存の言語に対しても貢献しないでしょう。
RDF(S)サポート:
RDFは非常にスケーラビリティがありますが（極めて冗長なXML構文は例外ですが）、あまり表現力がありません。
オントロジー言語は、学習障壁が低く、明瞭な概念と意味を持っているべきです。概念は、構文から独立しているべきです。
サポートされるタスク:
ユーザによる、直接的あるいは間接的な、セマンティック・ウェブ・ドキュメントのマークアップおよび照会。
正当性:
理想的には、ほとんどのユーザはフロント・エンド・ツールによってオントロジー言語から切り離されているでしょうが、オントロジー言語の基本哲学は、自然で、容易に学習できるものでなければなりません。さらに、早期採用者、ツール開発者、および、パワー・ユーザは、直接構文を用いて仕事をするかもしれません。つまり、人間が読める（そして、書ける）構文が望ましいことを意味します。
RDF(S)サポート:
RDFは、かなり簡単に利用できますが、RDFスキーマは、ずっと複雑です。構文は、多くの人にとって重大な障壁であるように思われます。
オントロジー言語は、他の一般に用いられているウェブや業界標準と互換性をもっているべきです。特に、これはXMLと関連規格（XMLスキーマやRDFのような）、そして、できればUMLのような他のモデリング規格を含んでいます。
サポートされるタスク:
標準フォーマットでのオントロジーとデータとの交換。
正当性:
他の規格との互換性は、ツールの開発とオントロジー言語の開発を容易にします。
RDF(S)サポート:
RDFはXMLシリアル化構文（serialization syntax）を持っています[RDF Syntax]。
オントロジー言語は、多言語オントロジーの開発をサポートし、異なる文化に適したオントロジーの異なる見解を潜在的に提供するべきです。
サポートされるタスク:
同じオントロジーが、多数の国々や文化によって使用されるタスク。
正当性:
ウェブは国際的なツールです。セマンティック・ウェブは、異なる文化間の考えや情報の交換を助けるべきであり、それゆえに、異なる国家の人々が、同じオントロジーを簡単に利用できるようにするべきです。
RDF(S)サポート:
XMLが国際化をサポートする範囲で、RDFも同様に国際化をサポートします。
ユースケースおよび設計目標は、ウェブ・オントロジー言語用の多くの要件を動機づけます。ワーキング・グループは、下記の要件がオントロジー言語に不可欠であると現在感じています。それぞれの要件は短い記述を含んでいて、前項のひとつ以上の設計目標によって動機づけられています。
オントロジーは、URI参照のような、自身のユニークな識別子を持っている資源でなければなりません。
動機づけ:オントロジーの共有化
異なるオントロジーの2つの概念は、別個の絶対識別子を持っていなくてはなりません（それらは同一の相対識別子を持っているかもしれませんが）。URI参照を用いて、オントロジーの概念をユニークに識別することが可能でなければなりません。
動機づけ:オントロジーの共有化,オントロジーの相互運用性
オントロジーは、新しいクラスとプロパティを追加している間に、概念を再利用するために他のオントロジーを明示的に拡張することができなければなりません。オントロジーの拡張は推移的関係でなければなりません。つまり、オントロジーAがオントロジーBを拡張し、オントロジーBがオントロジーCを拡張する場合、オントロジーAは暗黙のうちにオントロジーCも同様に拡張します。
動機づけ:オントロジーの共有化
資源は、定義と仮定のどの集合が作られるかを正確に示し、特定のオントロジーに明示的に関係づけることができなければなりません。
動機づけ:オントロジーの共有化
作者、公表日のようなメタデータをそれぞれのオントロジーに与えることが可能でなければなりません。これらのプロパティーはダブリン・コア要素セットから借用できるかもしれないし、できないかもしれません。
動機づけ:オントロジーの共有化
オントロジー言語は、同じオントロジーの異なるバージョンを比較し関連付ける機能を提供しなければなりません。これは、改版を旧版に関連付ける機能、下位互換性の明示的な記述、および、識別子を非推奨だとする性能（つまり、それらが下位互換性のみに対して利用可能であり、新しいアプリケーション/ドキュメントで使用されるべきではないと明示すること）を含んでいるべきです。
動機づけ:オントロジーの進化
オントロジー言語は、クラスの複雑な定義を表現することができなければなりません。これには、クラス式のサブクラスとブール組合せ（つまり、積集合（intersection）、和集合（union）および補集合（complement））が含まれます（しかし、これに限られるわけではありません）。
オントロジー言語は、プロパティの定義を表現できなければなりません。これには、サブプロパティ、定義域と値域制約、推移性、および逆プロパティが含まれます（しかし、これに限られるわけではありません）。
オントロジー言語は一連の標準のデータ・タイプを提供しなければなりません。このデータ・タイプはXMLスキーマのデータ・タイプに基づいているかもしれません[XML-SCHEMA2]。
オントロジー言語は、2つのクラスあるいはプロパティーが同等であると明示する機能を含んでいなければなりません。
動機づけ:オントロジーの相互運用性
オントロジー言語は、2つの識別子が同じ個体を表すと明示する機能を含んでいなければなりません（他のOWLのドキュメントで使用されている用語との整合性を考えると、ここの個体はOWLのクラスのインスタンスであり、必ずしも人を意味するわけではないとに注意してください）。ウェブの分散した性質のために、異なった識別子が同じ個体に割り当てられる傾向があります。家と職場でウェブ・ページやemailアドレスを持っている人のように、個体が多数のURLを持っているかもしれないので、標準的なURLの使用ではこの問題は解決しません。
動機づけ:オントロジーの相互運用性
オントロジー言語は、ステートメントが、ソース、タイムスタンプ、信頼性のレベルなどのような付加的な情報に「タグ付け」されることを可能にする方法を提供しなければなりません。オントロジー言語は、この方法で使用できるプロパティーの標準セットを提供する必要はありませんが、その代り、ユーザがそのような情報を付与するための一般的なメカニズムを提供するべきです。具象化（reification）は多少論議をよびそうな機能ですが、RDF具象化は要件に適合する1つの可能性のある方法かもしれません。
動機づけ:オントロジーの共有化,オントロジーの相互運用性
オントロジー言語は、インスタンスとしてクラスを扱う性能をサポートしなければなりません。これは、ユーザの見方次第で、しばしば同じ概念をクラスとも個体とも見なすことができるからです。例えば、生物学のオントロジーでは、オランウータンというクラスは、動物という個体をインスタンスとして持っているかもしれません。しかし、オランウータンというクラスそれ自体は、種というクラスのインスタンスです。オランウータンが種のサブクラスではないことに注意して下さい。なぜなら、そうすれば、オランウータン（動物）のそれぞれのインスタンスは種のインスタンスであることになるからです。
動機づけ:オントロジーの相互運用性
オントロジー言語は、プロパティーに対するカーディナリティー制約（Cardinality constraints）の仕様をサポートしなければなりません。これらの制約は、ひとつの個体が特定のプロパティーによって関連付けられうる個体の最小数および最大数を定めます。
動機づけ:表現力とスケーラビリティとのバランス,矛盾の検出
オントロジー言語はXMLシリアル化構文を持っているべきです。XMLは、産業界に広く受けいれられるようになり、XMLを処理するためのツールが多数開発されています。ウェブ・オントロジー言語がXML構文を持っている場合、これらのツールは拡張したり再利用することができます。
動機づけ:他規格との互換性
オントロジー言語は、オントロジーによって指定される資源に対し、多数選択形式のユーザが表示できるラベルの仕様をサポートするべきです。これは、例えば、異なる自然言語でオントロジーを見るために使用することができます。
オントロジー言語は、多言語文字セットの使用をサポートするべきです。
いくつかの文字コード化（例えば、Unicodeに基づくコード化）では、2つの異なる文字列が同じにように見え、同等性を比較することを（ほとんどのユーザに）期待される場合があります。例としては、事前合成（pre-composed）形式（たった1つのcセディーユ文字）を使用したものと、分解（decomposed）形式（セディーユ・アクセント文字が後続する「c」の文字）を使用するものがあります。W3C I18N WGが、この問題の解決への通常のアプローチとして、Early Uniform Normalization（Unicodeの正規形Cへの）を決定したとすれば、他の解決策を正当化する必要があります。
オントロジー言語に含まれるべき一連の機能に加えて（前項で定義されているように）、多くのユースケースに役立つ他の機能があります。これらの機能は、可能であれば、ワーキング・グループが取り組むでしょうが、ワーキング・グループは、これらをオントロジー言語から除外する、あるいは、後のワーキング・グループによって進められるべきものとして残しておく、もっともな理由があると判断するかもしれません。これらの目的のうちのいくつかは完全には定義されておらず、したがって、それらがオントロジー言語によって取り組まれることになっている場合には、さらなる解明が必要となります。下記の目的の並び順は、相対的な優先順位やコンセンサスの程度を意味しないことに注意してください。
オントロジー言語は、オントロジーの定義のために異なるレベルの複雑さをサポートするかもしれません。アプリケーションは、言語全体をサポートすることなしに、特定の階層に従うことができます。階層を識別するためのガイドラインは、異なるタイプのデータベースや知識ベースのシステムで発見された機能性に基づくかもしれません。
動機づけ:表現力とスケーラビリティとのバランス
オントロジー言語は、プロパティのデフォルト値の仕様をサポートするべきです。そのような値は、典型的なクラスのメンバーに関する推論を行うのに役立ちます。しかし、実際のデフォルト値（論駁継承推論（defeasible inheritance reasoning）で使用されるもののような）は単調ではなく、新しい情報が絶えず発見されたり増えたりしているウェブでは問題をはらんでいます。さらに、デフォルトに対する一般に認められている対処法はありません。代案としては、どのように独自のデフォルト・メカニズムを作成できるかを、オントロジー言語仕様がユーザに勧告することです。
動機づけ:表現力とスケーラビリティとのバランス
ウェブは変化のサイズと範囲が大きいため、閉世界仮説（closed-world assumption）（推論できないものはすべて誤りであると仮定されると述べる）は適していません。しかし、閉世界の情報が役立つ状況もたくさんあります。したがって、オントロジー言語は、あるオントロジーが完全であると見なせると明示できなければなりません。そうすれば、付加的な推論がそのオントロジーから引き出されるのを認めることになるでしょう。そのようなステートメント（および対応する推論の集り）の厳密なセマンティクスについては今後定義されますが、個体に関する完全なプロパティー情報の仮定、クラスのメンバー（class-membership）の完全性の仮定、および、サブクラスの徹底性（exhaustiveness）の仮定の例が含まれるかもしれません。
動機づけ:オントロジーの共有化,矛盾の検出
オントロジー言語は、プロパティーの値の値域を指定する性能をサポートするべきです。このメカニズムは、XMLスキーマのデータ型から借用するかもしれません[XML-SCHEMA2]。
動機づけ:矛盾の検出
オントロジー言語は、クラスとプロパティーに関するステイトメントにおいてプロパティーの合成をサポートする可能性があります。プロパティー合成の使用の一例は、uncleOfというプロパティーはfatherOfやbrotherOfプロパティーの合成と同じであると主張することでしょう。
動機づけ:表現力とスケーラビリティとのバランス
オントロジー言語は決定可能であるべきです。
動機づけ:表現力とスケーラビリティとのバランス
オントロジー言語は、オントロジー全体に関係づける性能をサポートするべきなのと同様に、オントロジーの部分に対して関連付ける性能をサポートするべきです。しかし、その際にどのような粒度を使用すべきかは不明です。概念のサブセットをすべての定義と一緒に選ぶか、個々の定義を選ぶかという選択肢があります。異なるアプリケーションが異なる事柄を表すために同じ識別子を使うため、概念の部分定義を借りることは相互運用の問題をもたらすだろうということに注意が必要です。
動機づけ:オントロジーの共有化
オントロジー言語は、オントロジーのサブセットを指定したり、概念に別名を割り当てたりすることができるオントロジー・ビュー（ontology view）を作成する性能をサポートするべきです。これは、多文化バージョンのオントロジーの開発において特に有効です。多数のオントロジーを持ち、オントロジー・マッピング・メカニズムを使用することによって、この要件が満たされるかもしれないということに注意して下さい。
動機づけ:国際化,オントロジーの相互運用性
W3C XMLデジタル署名の仕様は、信頼できないプロパティー間のコミュニケーションのための重要な構成要素で、多くのオントロジー・アプリケーションにとって重要です。ウェブ・オントロジー言語は、XML署名を確実に使用するように設計されるべきです。
動機づけ:他規格との互換性
オントロジー言語は、演算機能の使用をサポートするべきです。これは、異なる計量単位間の変換を行うのに使用することができます。
動機づけ:オントロジーの相互運用性
オントロジー言語は文字列連結と単純パターンマッチをサポートするべきです。これらの機能は、複雑な情報を1つの定形文字列として扱うオントロジーと、各構成要素に対して別個のプロパティーを持っているオントロジーの間に相互運用性を確立するために使用することができます。例えば、あるオントロジーは、emailアドレスを、ひとつの文字列として表すかもしれませんし、別のオントロジーはユーザ名とサーバ名の文字列に分割するかもしれません。2つのオントロジーを統合するためには、ユーザ名、「@」という文字、およびサーバ名の連結が最初のオントロジーで使用されるひとつ値と同等であると明示する必要があるでしょう。
動機づけ:オントロジーの相互運用性
オントロジー言語は、SQLのGROUP BY句に似た方法で情報をまとめる性能をサポートするべきです。これは、計算、合計および他の演算が各グループのために計算されることを可能にするべきです。これは、異なるレベルの粒度で情報を表し、予算カテゴリー合計のような事物を予算線価格（budget line item amounts）に関連付けたり、社員数を従業員の個々のデータに関連付けることができるオントロジー間の相互運用を可能にするでしょう。
動機づけ:オントロジーの相互運用性
オントロジー言語は、複雑な規準を評価するために実行コードの使用をサポートするべきです。手続き付加は、オントロジー言語の表現力を大きく拡張しますが、形式意味論（formal semantics）には適していません。ウェブ・オントロジーの手続き付加メカニズムは、手続きを捜し出して実行する方法を指定するべきです。1つの候補となりうる言語はJavaで、Javaは既にウェブ上のイントラ・プラットフォームの共有（intra-platform sharing）にうまく適応しています。
動機づけ:オントロジーの相互運用性
一般に、オントロジー言語単一名仮定（unique names assumption）を作らないでしょう。すなわち、別個の識別子が異なる個体を参照するとは仮定されません（要件R11を参照）。しかし、単一名仮定が有用なアプリケーションはたくさんあります。ユーザは、特定の名前空間やドキュメントのすべての名前が別個の個体を参照することを明示するオプションを持っているべきです。
動機づけ:矛盾の検出
オントロジー言語は、複雑な/構造化されたデータ型の定義と使用をサポートするべきです。日付、座標対（coordinate pair）、アドレスなどを指定するためにこれを使用してもかまいせん。
勧告候補以後の変更は、年代の逆順で掲載されています。
Raphael VolzとJonathan Daleは、このドキュメントに大きな著作上の貢献を行い、また、現在の編集者ともに初期の草案の共同編者でもありました。設計目標および要件を特定する初期の取り組みは、Deborah McGuinnessと編集者が共同で指揮にあたりました。要件のいくつかは、オントロジー・ベースのシステム構築における10年以上の研究に基づき、McGuinness博士[DWM]が直接貢献しました。他の要件は、プロトタイプのセマンティック・ウェブ・システムの構築における、編集者の博士論文[Hef]の一部であることが分っています。企業ウェブサイト管理の項の草案バージョンは、Michael Smithによって書かれました。
このドキュメントの内容は、総じてウェブ・オントロジー・ワーキンググループ内で積み重られた議論の結果です。このワーキンググループのメンバーは、Yasser alSafadi、Jean-Francois Baget、James Barnette、Sean Bechhofer、Jonathan Borden、Stephen Buswell、Jeremy Carroll、Dan Connolly、Peter Crowther、Jonathan Dale、Jos De Roo、David De Roure、Mike Dean、Larry Eshelman、Jerome Euzenat、Tim Finin、Nicholas Gibbins、Sandro Hawke、Patrick Hayes、Jeff Heflin、Ziv Hellman、James Hendler、Bernard Horan、Masahiro Hori、Ian Horrocks、Jane Hunter、Ruediger Klein、Natasha Kravtsova、Ora Lassila、Deborah McGuinness、Enrico Motta、Leo Obrst、Mehrdad Omidvari、Martin Pike、Marwan Sabbouh、Guus Schreiber、Noboru Shimizu、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、Frederik Brysse、Francesco Iannuzzelli、Massimo Marchiori、Michael Sintek、John Yanosyです。