Web Ontology Language (OWL) Use Cases and Requirements
W3C Working Draft 3 February 2003
- This version:
- http://www.w3.org/TR/2003/WD-webont-req-20030203/
- Latest version:
- http://www.w3.org/TR/webont-req/
- Previous version:
- http://www.w3.org/TR/2002/WD-webont-req-20020708/
- Editor:
- Jeff Heflin (Lehigh University) heflin@cse.lehigh.edu
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Abstract
本ドキュメントはWebオントロジ言語に対する利用シナリオ，目標，要求事項を記述したものである．オントロジは，正式には，対象ドメインを記述し表現するために使用される共通の用語の集合を定義する．オントロジは，自動化されたツールによって，より正確なウェブサーチ，知的ソフトウェアエージェント，知識マネージメントのような先進的なサービスを強化するために利用することができる．
Status of this document
本ドキュメントは，W3C Semantic Web Activity(Activity Statement)の一部分として作成されたもので， W3C Processとして用意された手続きに従っている． 本ドキュメントはWeb Ontology Working Groupによって書かれてきた． Web Ontology Working Groupの目標は，Web Ontology Working Group charterの中で述べられている．
この版は設計作業の途中で取り入れられた改善を要求事項に反映したものである． また，いくつかの要求事項は目標（Objectives）に降格された． Working Groupは本ドキュメントの中のすべての要求事項がOWLの設計ドキュメントで満足されると信じている． これらのドキュメントが固まってくる間に，もう少し残されたレビューコメントが統合されつつある． Web Ontology Working Groupは，要求事項の変化を反映し，またOWLがW3C Recommendationになるまでのパブリックコメントを反映するために，本ドキュメントの改訂を続けるであろう． Working Groupのスケジュールと関連ドキュメントのリリースについては，Working Groupのホームページを参照いただきたい．
本ドキュメントに対するコメントはpublic-webont-comments@w3.orgに送付していただきたい． このメーリングリストはpublic archiveを備えている． 関連技術に関する幅広い議論もメーリングリストw3c-rdf-logic@w3.orgで歓迎しており，このメーリングリストも同じくpublic archiveを備えている．
本ドキュメントはW3Cのメンバーと他の関心のあるグループによるレビューのためのW3C Working Draftである． まだドラフトであり，いつでも変更され，置き換えられ，あるいは他のドキュメントによって無効にされる可能性がある．
W3C Working Draftを参考文献として利用したり，あるいは，“作業中”とせずに参照することは不適当である． 現在のW3C Recommendationのリストと他の技術文書はhttp://www.w3.org/TR/で閲覧できる．
目次
1 はじめに
セマンティックWebは将来のWebに対するビジョンで，そこでは情報に明示的が意味を与えられ，それによって機械が自動的にWeb上にある情報を処理し統合することを容易にする． セマンティックWebは，カスタマイズされたタギングの枠組みを規定できるXMLと，データ表現にフレキシブルなアプローチを提供するRDFの上に構築される．セマンティックWebに必要な次の要素は，Webドキュメントで使用されるクラスとプロパティの意味をフォーマルに記述することができるWebオントロジ言語である． 機械がこうしたドキュメントの上で有用な推論を行うために，Webオントロジ言語はRDF Schemaの基本意味論を越えなければならない． このドキュメントはこうした言語に対する現状の要求事項を並べたものである． この言語は将来更に拡張されることが期待されていて，特に，より高い論理的能力とセマンティックWebの上で信頼性（trust）を確立する能力を加えることが望まれる．
このドキュメントは，６つのユースケース（Use Caess）を記述することによって，Webオントロジ言語の必要性を示すものである．これらのユースケースのいくつかは産業界と学界で現在進行中の活動に基づいており，それ以外は更に長期的な可能性を示すものである．ユースケースはWebオントロジ言語の開発のための高いレベルの目標とガイドラインを記述した設計ゴール（Design Goals）に引き継がれる．これらの設計ゴールは，提案された特性の評価の際に考慮されるであろう．要求事項（Requirements）に関するセクションでは，Webオントロジ言語が持つべき特性の集合を示し，それらの特性に動機付けを与える．目標（Objectives）のセクションでは，多くのユースケースに有効ではあるが，必ずしもワーキンググループによって言及されないかもしれない特性のリストを記述する．
Web Ontology Working
Group charterは，ワーキンググループに対し，いっそう表現力豊かな意味論を作り出し，Webオントロジ言語が“実体間のより複雑な関係，すなわち，クラスのプロパティを数やタイプで限定する手段，多様なプロパティを持った項目が特定のクラスのメンバーであることを推論する手段，プロパティ継承の明瞭なモデル，ベースとなる言語への同様の意味的な拡張などを含む関係”を提供できるメカニズムを規定する仕事を与える．Webオントロジ言語の詳細な使用で検討されるであろう項目は次の通り：
- このドキュメントに含まれる設計ゴールと要求事項
- このドキュメントに対する，一般からのフィードバック，招待された専門家，及びワーキンググループのメンバーからのレビューコメント
- これらの必要条件の多くを満たす言語の仕様あるいはそれ間の提案
- こうした要求事項に合った，言語に対する仕様や提案
1.1 オントロジとは何か？
オントロジは，知識の領域を記述し，表現するために使用される用語を定義する． オントロジは，ドメイン情報（ドメインとは，例えば，医薬品，工具製造，不動産，自動車修理，金融マネージメントなどのように，特定の主題領域あるいは知識領域）を共有する必要がある人間，データベース，アプリケーションによって使用される．
オントロジはコンピュータが利用できる基本コンセプトの定義とそれらの間の関係を含む（ここで，そしてこのドキュメント全体で，定義とは論理学者の言うような技術的な意味で使われていないことに注意して欲しい）．
オントロジはドメインの中の知識とドメイン間にまたがる知識をコード化する． こうして，オントロジは知識を再利用可能にする．
ワードオントロジは人工物を異なった構造レベルで記述するために使われてきた． これらは，（Yahoo階層のような）単純な分類法（taxonomy）から，（ダブリンコアのような）メタデータの枠組みや，論理的な理論にまで広がっている．セマンティックWebは大きな構造レベルを持ったオントロジを必要とする．
これらは次のような種類の概念記述を規定する必要がある：
- 多くのドメインの中のクラス（一般的なもの）
- ものの間に存在する関係
- それらのものが持っているかもしれないプロパティ（あるいは特質）
オントロジは，通常，論理学をベースする言語で表現され，それで，クラス，プロパティ，関係の間で，詳細な，正確な，一貫した，健全な，そして意味のある区別がなされることができる．いくつかのオントロジツールはオントロジを使って自動推論を行い，概念/意味検索，ソフトウェアエージェント，意志決定支援，音声と自然言語の理解，知識マネージメント，知的データベース，電子コマースなどの知的アプリケーションに対し，進歩的なサービスを提供することができる．
オントロジは，現在発展中のセマンティックWebにおいて，ドキュメントの意味を表す手段として，またWebアプリケーションや知的エージェントによって使用される意味論を与える手段として，重要な役割を果たしている．オントロジは，コミュニティにとって，現在集められ，標準化されつつあるメタデータの用語の意味を構造化し定義する手段として，大変有用であることが分かっている．
オントロジを使って，明日のアプリケーションは，人間の概念レベルでより正確に働くという意味で，“知的”になるであろう．
オントロジは，異なるコミュニティを横断して検索したり，異なるコミュニティからの情報をマージしたりすることを望むアプリケーションにとって決め手になる． XML DTDsとXML Schemaは，あらかじめ定義に同意したグループ間でのデータ交換には十分であるが，意味論の欠如は新しいXMLの語彙の下でマシンが信頼をもってこのタスクを行うことを妨げる． 同じ用語が異なった文脈では異なった（時には微妙に違う）意味で使われるかもしれないし，また異なった用語が同じ意味を持った項目のために使われるかもしれない． RDFとRDF Schemaは，識別子と結び付いた簡単な意味論を与えることによって，この問題にアプローチし始めた． RDF Schemaによって，複数のサブクラスとスーパークラスを持つクラスを定義でき，またサブプロパティと変域（domain）と値域（range）を持つプロパティを定義することができる． この意味で，RDF Schemaは簡単なWebオントロジ言語である． しかしながら，多数の，自立的に作られ，そして管理されたスキーマ間の処理を実現するためには，より豊かな意味論が必要である． 例えば，RDF SchemaはPersonとCarのクラスに重なりがない，あるいは文字列quartetがちょうど４人のミュージシャンをメンバーとして持っていることを表現することができない．
このドキュメントのゴールの１つが，Webオントロジ言語で何が必要であるかを明らかにすることである．これらの要求事項は，潜在的なユースケースとオントロジの標準的な概念をWebの特異な環境に適用する上での困難を考慮した一般的な設計目標によって動機付けされるであろう．
2 ユースケース
オントロジは既存のWebベースアプリケーションを改良するのに利用でき，またWebの新しい活用を可能にするであろう．このセクションではWebオントロジの６つの代表的なユースケースについて述べる．これは完全なリストではなく，興味あるユースケースの代表例であることを注意して欲しい．
2.1 Webポータル
Webポータルは共通トピック，例えば特定の都市あるいは興味のドメイン，に関する情報内容を提供するWebサイトである．Webポータルはそのトピックに興味を持っている個人がニュースを受け取り，お互いを見いだし，話をし，コミュニティを築き，そして共通の興味を持つ他のWebリソースへのリンクを見いだすことを許す．
ポータルが成功するためには，興味あるコンテンツの場所を特定することが出発点に違いない．通常，こうしたコンテンツはコミュニティのメンバーより投稿され，彼らはしばしばそのコンテンツをあるサブトピックの下にインデックス付けする．コンテンツを集めるもう一つの手段がコンテンツプロバイダに頼るもので，彼らはコンテンツが情報発信されたときに用いられた情報に基づいてタグ付けする．通常，これはコンテンツのトピックを特定する単純なメタデータの形式をとる．
しかしながら，主題のエリアを単純にインデックス付けするだけでは，コミュニティのメンバーが必要とするコンテンツを探すのに十分な能力を提供しない．より知的な情報発信を実現するために，Webポータルはコミュニティのためのオントロジを定義することができる．このオントロジはコンテンツと公理（axiom）を記述するためのターミノロジを提供する．例えば，オントロジは，「ジャーナル論文」，「出版」，「人」，「著者」といったターミノロジーを含むかもしれない．このオントロジは，「すべてのジャーナル論文が出版物である」あるいは「すべての出版物の著者は人である」といったことを述べるための定義を含みうる．事実と結び付けられるとき，これらの定義は，必ず真と推論される他の事実を許す．これらの推論は，その結果として，ユーザーが従来の検索システムでは得ることのできない検索結果をポータルから得ることを可能にする．もちろん，このような技術は，彼らのページにWebオントロジ言語で注釈を付けているコンテンツプロバイダに依存するが，もしこれらの所有者ができる限り広く彼らのコンテンツを配布しようとすると想定するならば，彼らが喜んでこれをするであろうと期待することができる．
オントロジをベースとするのポータルの一例がOntoWebである．このポータルはオントロジ研究に興味を持っている学術的なコミュニティや産業界のコミュニティを支援する．セマンティックWebの技術を使い，オントロジ言語の恩恵を受けたポータルのもう一つの例が，The Open Directory Projectで，人間によって編集された大規模かつ包括的なWebのディレクトリである．それはボランティアによる巨大で国際的なコミュニティによって構築され維持されている．The
Open DirectoryデータベースのRDFのダンプはダウンロード可能である．
2.2 マルチメディアコレクション
オントロジは，画像や音楽，あるいは，他の文字でないオブジェクトのコレクションに対し，意味的な注釈を付けるのに利用することができる．機械がマルチメディアから意味を抽出することは，自然言語テキストから意味を抽出するより困難である．そこで，こうしたタイプのリソースは，通常，キャプションあるいはメタタグによってインデックス付けされる．しかしながら，いろいろな人々がそれぞれ異なった方法でこうしたテキストでないオブジェクトを記述することができるため，検索機能は単純なキーワードマッチングを越えることが重要である．理想的には，オントロジは画像検索を改良するために利用することのできる追加的なドメイン知識を獲得するであろう．
マルチメディアオントロジには２つのタイプがあり得る．すなわち，メディア特有タイプとコンテンツ特有タイプである．メディア特有のオントロジは，異なったメディアタイプの分類法（taxonomy）を持っていて，異なったメディアのプロパティを記述することができるかもしれない．例えば，ビデオはクリップの長さとシーンの中断を特定するプロパティを含むかもしれない．コンテンツ特有のオントロジは，リソースの主題，例えば場面設定や登場人物などを記述することができる．このようなオントロジは，メディア特有ではないので，それらは同じドメインを取り扱う他のドキュメントによって再利用できる．このような再利用は，リソースのフォーマットにかかわらず，特定の主題に関する情報を単に探していた検索を強化するであろう．メディアのタイプが重要な検索は，メディア特有のオントロジとコンテンツ特有のオントロジを組み合わせることができる．
マルチメディアコレクションの例として，アンティーク家具の画像アーカイブを考えて欲しい．アンティーク家具のオントロジは，このようなアーカイブの検索に大変有効であろう．分類学（taxonomy）が異なったタイプの家具を分類するために使用することができる．オントロジが定義的な知識を表現することができるなら，同じく有効であろう．例えば，もしインデキシングエンジンがアンティーク整理だんすのスタイル／時代に対する値として「後期ジョージ王朝風」という値を選択するなら，データエレメント“date.created”が西暦１７６０年から１８１１年までの間の値を取り，また，“culture”が英国文化であることを推論することが可能なはずである．この種のバックグラウンド知識の利用可能性が，検索と同様インデキシングのために与えられるサポートを著しく増加させる．有用なもう１つの特性がデフォルト知識の表現のサポートである．このような知識の例は，「後期ジョージ王朝風の整理だんす」は通常マホガニーで作られているといったものであろう．この知識は本当の意味的な問合せにとって極めて重要で，例えば，「アンティークなマホガニーの収納家具」というユーザの質問は，画像に対するアノテーションの中で木材の材質について何も言われていなくても，後期ジョージ王朝風の整理だんすの画像にマッチしうる．
2.3 企業Webサイトマネージメント
大企業は，通常，新聞発表，製品発表とケーススタディ，企業のプロシージャ，内部の製品説明と比較，白書，プロセス記述などに関する膨大なWebページを持っている．オントロジはこれらのドキュメントにインデックスを付け，検索のより良い手段を提供するために使用することができる．多くの大きな組織が情報を整理するための分類法（taxonomy）を持っているにもかかわらず，それはしばしば不十分である．一つの分類法がしばしば制限的なのは，多くのものが複数のカテゴリーの下に位置するためである．さらに，異なったパラメータのために値を探索する能力は，しばしば分類法を使ったキーワード検索より有用である．
オントロジを可能にしたWebサイトは，次のような人達に利用されるかもしれない：
- 販売遂行に対応した担保物権を探している販売員．
- 特定の技術的な専門能力や詳細な過去の経験の貯蔵庫を探している技術者．
- 複雑で多相のプロジェクトを，提案フェーズと実行フェーズの両方で，支える過去の経験とテンプレートを探しているプロジェクトリーダー．
これらのタイプのそれぞれのユーザにとっての典型的な問題は，彼らが望んでいるコンテンツの作者との間で用語が共有化されていないことである．販売員は望んでいる特性の専門的な名前を知らないかもしれないし，異なったフィールドの技術者は同じ概念に対して別の用語を使っているかもしれない．このような問題のために，それぞれのユーザのクラスにとって異なった用語のオントロジを持つことは有益かもしれないが，それぞれのオントロジが，翻訳が自動的に行われるように，相互に関係づけられるであろう．
もう１つの問題は問合せを正しい抽象化レベルに合わせることである．オペレーティングシステムの専門能力を持つ誰かを探しているプロジェクトリーダーは，UnixとWindowsの両方の専門家である従業員を突き止めることができるはずである．
大きいサービス組織の１つの様相は，それが非常に広範囲な能力の集合を持っているかもしれないということである．しかし大きな仕事を追い求めるとき，これらの能力は時には新しい方法に組み立てられる必要がある．マッチする過去のプロジェクトがないのがしばしばである．一つの挑戦が，過去のテンプレートとドキュメントが，多様な前提条件の集合を満足させている間に，どのようにして新しい形状に組み立て直すことができるかを推論することである．
2.4 設計ドキュメンテーション
このユースケースは大量のエンジニアリングドキュメンテーションのためのもので，例えば航空機産業によって使われた．このドキュメンテーションはいくつかの異なったタイプから成り，設計ドキュメンテーション，製造ドキュメンテーション，テストドキュメンテーションを含む．これらのドキュメント集合はそれぞれ階層的な構造を持っている，しかし構造は集合間で異なる．また，ドキュメンテーション集合を相互にリンクさせる暗黙軸の集合がある：例えば，航空機の設計ドキュメントでは，翼桁のような項目が各ドキュメントに現われるかもしれない．
オントロジは，情報モデルを構築するのに利用することができ，この情報モデルは，表現された項目，項目間の関係，項目のプロパティ，リンクを記述し定義するドキュメンテーション（すなわち，モデルの中にその項目が存在することの外部からの正当化）へのそれらのリンクなどに基づいて情報空間の探索を可能にする．つまり，オントロジと分類学は，それらが表す物理的な項目から独立ではないが，同時に開発され探究されるであろう．
このユースケースの具体的な例は航空機ドメインでの設計ドキュメンテーションで，このドメインには次のような典型的なユーザが含まれている．
- 特定の部分（例えば，「翼桁」）に関連するすべての情報を探しているメンテナンスエンジニア．
- 特定の部分組み立て部品の再利用に関する制約を調べている設計エンジニア．
この種類の使用方法をサポートするためには，制約を定義できることが重要である．これらの制約は検索を強化したり一貫性をチェックするのに利用することができる．制約の一例は次のようなものである：
biplane(X) => CardinalityOf(wing(X)) = 2この種類のオントロジのもう一つの使い方は，特定の概念（クラスかインスタンス）に焦点を置いた情報空間のスナップショットを示す図表の視覚化や編集のサポートである．これらの典型的なものが，活動/規則ダイアグラムあるいは実体関係ダイアグラムである．
wingspar(X) AND wing(Y) AND isComponentOf(X,Y) => length(X) < length(Y)
2.5 エージェントとサービス
セマンティックWebは多様な情報リソースを理解し，統合する能力を持ったエージェントを提供することができる．特定の例が社会活動プランナーで，それはユーザの嗜好（どのような映画が好きか，どのような食べ物が好きか，等々）を取り扱い，この情報をその人の夕方の活動の計画に利用する．こうした活動を計画するタスクは，提供されるサービス環境の豊富さとユーザのニーズに依存するであろう．サービスの決定／マッチングプロセスにおいて，ランク付けと評価のサービスがユーザの嗜好により近いものを見つけるのに利用されるかもしれない（例えば，“ベスト”を選ぶために，映画やレストランの評価やランク付けを利用する）．
このタイプのエージェントは，レストラン，ホテルなどの用語を表現するドメインオントロジと実サービスで使用される用語を表現するサービスオントロジを必要とする．実サービスを構築するときには，情報が多数の情報源，例えばポータル，特定サービスサイト，予約サイト，あるいは一般のWebなどから集まってくるかもしれない．
これは多くの異なったドメインとサービスのオントロジを必要とするだろう：キーとなる課題としては次のようなものが含まれる：
- 異なるドメインとサービスにわたる複数の独立したオントロジの利用と統合
- インターネット上のオントロジのに分散した場所
- 各ドメインやサービスごとの潜在的に異なるオントロジ（オントロジ変換／相互参照）
- オントロジの定義や利用を簡単にする単純なオントロジの表現
2.6 ユビキタスコンピューティング
ユビキタスコンピューティングは専用のコンピューティング機構から我々の日常の環境の中に埋め込まれたパーベイシブコンピューティングの可能性へのシフトに特徴付けられたパーソナルコンピューティングの新しいパラダイムである．ユビキタスコンピューティングの特徴は，小型で，持ち運び可能で，無線のコンピューティングデバイスである．デバイスのパーベイシブ性と無線の性質は，自動的かつアドホックな構成をサポートするネットワークアーキテクチャを必要とする．自動構成の開発の付加的な理由は，この技術が一般消費者を対象としていることである．
本当のアドホックネットワークのキー技術は，サービスディスカバリ（service discovery）で，これは「サービス」（すなわち，携帯電話，プリンタ，センサなどのような種々のデバイスによって提供される機能）が，他の人たちによって，記述され，宣伝され，発見されることのできる機能である．現在のサービスディスカバリと能力記述のメカニズムのすべて（例えば，サンのJINI，マイクロソフトのUPnP）は，アドホックな表現の枠組みに基づいていて，標準化（すなわち，人がコミュニケートし議論することを望むすべてのものの先見的な特定）に大きく頼っている．
ユビキタスコンピューティングのキーとなる問題（そしてゴール）は，「思いがけなく幸運な互換性」，あるいは「振り付けをしない」条件下での互換性で，すなわち，必ずしも一緒に動くように設計されていないデバイス（異なった目的のために，異なった製造業者によって，異なった時に作られたもの）がお互いの機能を発見し利用することができるようにならなければならない．他のデバイスを「理解して」，それらのサービス／機能を推論することが必要である．何故なら，本格的なユビキタスコンピューティングのシナリオは，何百ではないにしても多数のデバイスを含み，そして前もって利用シナリオを標準化することは手に負えないタスクであるからである．
インターオペレーションのシナリオは，この上なく動的で（すなわち，デバイスは所有者がある部屋や建物から別の部屋や建物に運ぶたびに現れたり消えたりする），（再）構成に関する限りループの中に人間を含まない．
デバイスに機能性を与えることがWebサービスとしてモデル化できるとすると，このユースケースのニーズは，DAML-Ｓに対するニーズにいくぶん類似している（特に，言語の表現力の豊かさを取り巻く問題）．
サービスの利用に関するタスクは，発見，請負，合成を含む．サービスの請負は，報酬に関する詳細（サービスのプロバイダは，提供されたサービスに対する報酬を受けなければならない）と同様，セキュリティ，プライバシー，信頼（trust）についての情報の表現を含むかもしれない．特に，企業や組織のセキュリティポリシーがアプリケーションに依存しない形式で表現され，それによって多様な実施メカニズム（例えば，ファイアウォール，フィルタ／スキャナ，トラフィックモニタ，アプリケーションレベルでのルータやロードバランサ）の上の制約表現を可能にするのがゴールである．
デバイスの特性に関する情報を表現するためのRDFベースの枠組みが採用され始めれば（すなわち），追加的なニーズはRDFとのあるレベルでの互換性を持つ．（すなわち，W3CのComposite Capability/Preference
Profile (CC/PP)やWAPフォーラムのUser
Agent ProfileあるいはUAProf）採用され始めれば，さらに必要が若干のレベルにおいて RDF との互換性である．
3 設計ゴール
デザインゴールは，Webオントロジ言語に対する，必ずしも一つのユースケースに起因しない一般的な動機を記述する．このセクションで，我々はWebオントロジ言語のための８つの設計ゴールを記述する．それぞれのゴールについては，それがサポートするタスクを記述し，ゴールのための根本原理を説明する．同じくゴールに対してRDFとRDF
Schemeがサポートする度合いも示す．
3.1 共有化されたオントロジ（Shared ontlogies）
オントロジは公的に利用可能で，異なったデータソースを，共有化された意味において，同じオントロジに付託することができなければならない．また，オントロジは，追加的な定義を与えるために，他のオントロジを拡張できなければならない．
サポートされるタスク：
分散したデータソースが共通の用語（terminology）を使用する任意のユースケース．
正当性：
互換性は識別子の定義に関する合意を必要とする．オントロジは識別子の標準的な集合とこれらの識別子のフォーマルな記述を与えることができる．同じオントロジに付託されるデータソースは，同じ識別子を同じ意味で使用することに明示的に同意する．
しばしば，共有化されたオントロジは十分ではない．ある組織は既存のオントロジが彼らの必要とすることの９０％を与えることが分かるかもしれないが，残りの１０％が重要である．このようなケースでは，その組織は新しいオントロジを最初から作るべきではないであろう．むしろ，既存のオントロジを拡張し必要な識別子と定義を加えたオントロジを作ることができるべきである．
RDF(S)のサポート：
RDFでは，それぞれのスキーマはURIによって識別される名前空間を持っている．スキーマの中の各リソースはＩＤを持ち，グローバルに唯一の識別子がＩＤと名前空間のURIとの組合せによって作られる．このURIを用いる任意のリソースは，そのスキーマで定義された用語を参照する．しかしながら，RDFは複数のスキーマの中で部分的な定義を持っている用語の定義については明確でない．仕様は，定義が情報源にかかわらず同じ識別子を使用するすべての記述の結合であることを仮定しているように思われる．しかしながら，分散環境下では，あるスキーマは正しくないか虚偽の定義を含んでいるかもしれず，問題を生じさせるかもしれない．RDFではリソースがどの定義の集合を認めているかを示す手段がない．
3.2 オントロジの進化（Ontology evolution）
オントロジはその存続期間の間に変化するかもしれない．データソースはそれが付託されるオントロジの版を指定しなければならない．
重要な問題は，オントロジの１つの版に付託されたドキュメントが他の版に付託されたドキュメントと互換かどうかである．互換な改版と非互換な改版の両方が許されるが，どちらであるかが区別されなければならない．フォーマルな記述は大部分の識別子に対する近似を提供するだけであるため，改版で識別子のフォーマルな記述を変えることなく意図した意味に変更することができることに注意して欲しい．このように，意味的なバックワード互換性（backwards-compatibility）の判定は，用語の記述の単純な比較よりも多くのことを必要とする．よって，オントロジの記述者はこのような変更を明示的に示す必要がある．
サポートされるタスク：
オントロジが潜在的に変化し，特にオントロジの所有者がデータの提供者と異なるようなユースケース．
正当性：
Webは絶えず成長し変化するため，オントロジに対しても同様に変化することを期待しなければならない．オントロジは，古い版にエラーがあったり，ドメインのモデル化の新しい方法が好まれたり，あるいは新しいターミノロジが作られたために（例えば，新しい技術の発明の結果として），変化する必要があるかもしれない．オントロジの進化は，元のオントロジを変更しないオントロジ拡張とは異なることに注意して欲しい．
RDF(S)のサポート：
RDF Schemaの仕様は，スキーマのそれぞれの版がURIによる別々のリソースであることを薦めている．プロパティrdfs:subClassOfとrdfs:subPropertyOfは，クラスとプロパティの新しい版を古い版に関係付けるのに使用することができる．しかしながら，これは正しくない定義を取り消すことができないという欠点を持っている．例えば，スキーマv1でv1:Dolphinがv1:Fishのrdfs:subClassOfであると仮定する．この間違いに気付いたとき，スキーマの新しい版v2では，v2:Dolphinがv2:Mammalのrdfs:subClassOfであると記述する．しかしながら，もしv2:Dolphinをv1:Dolphinのrdfs:subClassOfとするなら，v2:Dolphinがv1:Fishのrdfs:subClassOfであるということになり，誤りを永続させてしまう．
3.3 オントロジの互換性（Ontology interoperability）
異なるオントロジが同じコンセプトを別の方法でモデル化しているかもしれない．Webオントロジ言語は，異なる表現を関係付け，それゆえにデータが別のオントロジに変換されるのを許し，「オントロジのWeb」を可能にするためのプリミティブを提供しなければならない．
サポートされるタスク：
異なるプロバイダからの異なるターミノロジを伴うデータが統合されなければならないユースケース．
正当性：
共有化されたオントロジとオントロジの拡張が異なる組織とドメインの間のある程度の互換性を可能にするにもかかわらず，同じ情報を複数の方法でモデル化するケースがしばしばある．これは，異なる組織，異なる職業，異なる国籍などでの視点の違いによるかもしれない．マシンが異質なオントロジに付託される情報を統合できるようにするためには，オントロジがコンセプトを他のオントロジの同等のものにマップすることを許すプリミティブが必要である．
RDF(S)のサポート：
RDFは互換性についての最小限のサポートをプロパティrdfs:subClassOfとrdfs:subPropertyOfによって提供する．
3.4 矛盾検出（Inconsistency detection）
異なるオントロジやデータソースは矛盾を含む可能性がある．こうした矛盾を検出できる必要がある．
サポートされるタスク：
データの分散と制御する権威者の欠如がデータの矛盾をもたらしうるユースケース．統一性のない記述に終わるオントロジの拡張タスク（たぶん制約の強すぎるコンセプトを生成するようなオントロジの拡張によるであろう）．
正当性：
Webは分散していて，誰もが何を言っても構わない．その結果，異なる視点が相反したり，虚偽の情報でさえも作られることがある．エージェントが矛盾するデータを組み合わせることや一貫性のあるデータを一貫性のない状態に進化させることを防ぐためには，自動的に矛盾を検出することが重要である．
RDF(S)のサポート：
RDFとRDFSは矛盾を表現することを許していない．
3.5 表現能力とスケーラビリティのバランス（Balance of expressivity and scalability）
Webオントロジ言語は幅広い種類の知識を表現できなければならないが，同時に効率的に推論する手段を提供しなければならない．これら２つの要求は通常相反するため，Webオントロジ言語のゴールは最も重要な種類の知識を表現する能力をサポートするバランスを発見することである．
サポートされるタスク：
大規模なオントロジあるいは大規模なデータセットを用い，多様な知識の表現を要求するユースケース．
正当性：
Webの上には１０億以上のページが存在し，セマンティックWebのデバイスやエージェントへの潜在的なアプリケーションは取り扱わなければならない情報量より多くを主張する．Webオントロジ言語は規模をうまく取り扱う推論システムをサポートしなければならない．しかしながら，Webオントロジ言語は，ユーザが彼らのアプリケーションで重要な知識の種類を記述できるように，できる限り高い表現力を持たなければならない．
表現能力は言語で何が記述できるかを決定し，そしてその言語の推論能力とその言語を完全にインプリメントしたシステムでどのような推論可能性が期待されるかを決定する．表現力の高い言語は，幅広い種類の知識の定式化を許す豊かなプリミティブの集合を含んでいる．表現力の低い言語では，役に立つ推論の機会を殆ど提供せず，既存の言語を越える貢献をもたらさないだろう．
RDF(S)のサポート：
RDFはスケーラブルであるが（相当まわりくどいXMLのシンタックスを除いて）表現力は高くない．
3.6 使いやすさ（Ease of use）
Webオントロジ言語は，習得の障壁が低く，そして明確なコンセプトと意味を持たなければならない．このコンセプトはシンタックスとは独立でなければならない．
サポートされるタスク：
ユーザによる，直接あるいは間接の，セマンティックWebドキュメントに対するマークアップと質問．
正当性：
理想的には，大部分のユーザは，フロントエンドツールによって，言語仕様から切り離されてはいるが，Webオントロジ言語の基本思想は自然で習得しやすいものでなければならない．更に，初期の適用者やツール開発者やパワーユーザは，シンタックスを直接取り扱うであろうから，人間にとって読みやすい（書きやすい）シンタックスが望ましい．
RDF(S)のサポート：
RDFかなり使いやすいが，RDF Schemaはより複雑である．シンタックスが多くの人にとっての主な障壁になっているようである．
3.7 他のスタンダードとの互換性（Compatibility with other standards）
Webオントロジ言語は他の共通に利用されているWebや産業界のスタンダードと互換性を持たなければならない．それには，特に，XMLとそれに関係するスタンダード（XML
SchemaやRDF）が含まれ，また多分UMLのような他のモデリングスタンダードも含まれるであろう．
サポートされるタスク：
オントロジとデータの標準フォーマットによる交換．
正当性：
他のスタンダードとの互換性は，ツール開発とWebオントロジ言語の展開を容易にする．
RDF(S)のサポート：
RDFはXMLのserializationシンタックスを持つ．
3.8 国際化（Internationalization）
Webオントロジ言語は，多言語オントロジの開発をサポートしなければならない．また，潜在的に，異なる文化にとって適切な異なる視点のオントロジを提供しなければならない．
サポートされるタスク：
同じオントロジが複数の国や文化で使用されるようなタスク．
正当性：
Webは国際的なツールである．セマンティックWebは，異なった文化の間でアイデアや情報を交換することを助けなければならず，したがって異なった国の人が同じオントロジを利用することを容易にしなければならない．
RDF(S)のサポート：
XMLがサポートする国際化の範囲で，RDFもサポートする．
4 要求事項
ユースケースと設計ゴールはWebオントロジ言語に対するいくつかの要求事項の動機を与える．ワーキンググループでは，現在，以下の要求事項はWebオントロジ言語に不可欠であると考えている．それぞれの要求事項は，短い説明を含み，前のセクションの設計ゴールの一つまたはそれ以上に動機付けられている．
- R1. 識別可能なリソースとしてのオントロジ（Ontologies as distinct resources）
-
オントロジはURIのように自分自身の唯一のＩＤを持つリソースでなければならない．
- R2. URIで参照される曖昧性のないコンセプト（Unambiguous concept referencing with URIs）
-
異なるオントロジの２つのコンセプトは別々の絶対的な識別子を持たなければならない（それらは同一の相対的な識別子を持つかもしれないが）．URI参照を用いてオントロジ中のコンセプトをユニークに識別することができるはずである．
- R3. 明示的なオントロジの拡張（Explicit ontology extension）
-
オントロジは，他のオントロジに新しいクラスとプロパティを加える一方でコンセプトを再利用するために，他のオントロジを明示的に拡張できなければならない．オントロジ拡張は推移的な関係で，もしオントロジAがオントロジBを拡張し，オントロジBがオントロジCを拡張するなら，オントロジAは暗黙的にオントロジCを拡張する．
- R4. オントロジへの付託（Commitment to ontologies）
-
リソースは，どの定義と仮説の集合が使われたかを正確に指し示して，特定のオントロジに明示的に付託できなければならない．
- R5. オントロジのメタデータ（Ontology metadata）
-
それぞれのオントロジにメタデータ，例えば著者や出版日などを提供できなければならない．これらのプロパティはダブリンコアのエレメントセットから借用できるかもしれないし，できないかもしれない．
- R6. バージョン情報（Versioning information）
-
Webオントロジ言語は同じオントロジの異なる版を比較し関係付ける特性を提供しなければならない．これには，新しい版を古い版に関係付ける特性，バックワード互換性（backwards-compatibility）の明示的な記述，識別子をおとしめる（すなわち，バックワード互換のためだけに利用できることを記述し，新しいアプリケーションやドキュメントの中では使用されない）機能が含まれる．
- R7. クラス定義のプリミティブ（Class definition primitives）
-
Webオントロジ言語はクラスの複雑な定義を表現できなければならない．これには，これだけに限られるわけではないが，サブクラス生成，クラス表現の論理的組合せ（すなわち，intersection，union，complement）が含まれる．
-
動機： Balance of expressivity and scalability, Ontology interoperability, Inconsistency detection
- R8. プロパティ定義のプリミティブ（Property definition primitives）
-
Webオントロジ言語はプロパティの定義を表現できなければならない．これには，これだけに限られるわけではないが，サブプロパティ，変域と値域に関する制約，推移性，逆プロパティが含まれる．
-
動機： Balance of expressivity and scalability, Ontology interoperability, Inconsistency detection
- R9. データタイプ（Data types）
-
Webオントロジ言語は標準的なデータタイプを提供しなければならない．これらのデータタイプはXML Schemaデータタイプに基づくであろう．
- R10. クラスとプロパティの同一性（Class and property equivalence）
-
Webオントロジ言語は２つのクラスやプロパティは同一であることを記述する特性を含まなければならない．
- R11. 個体の同一性（Individual equivalence）
-
Webオントロジ言語は２つの識別子が同じ個体を表現していることを記述する特性を含まなければならない（他のOWLのドキュメントで用いられる用語との統一性を考えると，ここで個体というのはOWLのクラスのインスタンスで，必ずしも人を指すわけではないことに注意して欲しい）．Webの分散的な性質のため，異なる識別子が同じ個体に割り当てられることはありそうに思われる．標準的なURLを用いることでは，この問題を解決できない．何故なら，家庭用と仕事用のWebページやメールアドレスを持つ人のように，ある個体は複数のURLを持つかもしれないからである．
- R12. 記述への情報付加（Attaching information to statements）
-
Webオントロジ言語は，記述に対して，情報源，タイムスタンプ，機密レベルなどの付加的情報を“タグ付け”する手段を提供しなければならない．Webオントロジ言語はこのように利用されるプロパティの標準セットを持つ必要はないが，その代わり，こうした情報をユーザが付加するための一般的なメカニズムを提供しなければならない．RDFのreification（具体化）はこの要求事項に対応する方法の一つかもしれない．ただし，reification（具体化）は多少異論のある特性ではある．
- R13. インスタンスとしてのクラス（Classes as instances）
-
Webオントロジ言語はクラスをインスタンスとして取り扱う能力をサポートしなければならない．これは同じコンセプトが，しばしば，ユーザの視点に応じて，クラスと見られたり個体と見られたりするためである．例えば，生物学のオントロジでは，クラスOrangutanは個体の動物をインスタンスに持つかもしれない．しかしながら，クラスOrangutan自身はクラスSpeciesのインスタンスである．OrangutanはSpeciesのサブクラスではないことに注意して欲しい．何故なら，サブクラスであれば，Orangutanの各インスタンスがSpeciesのインスタンスであることになるからである．
- R14. Cardinality制約（Cardinality constraints）
-
Webオントロジ言語はプロパティのcardinality制約の仕様をサポートしなければならない．これらの制約は指定されたプロパティを介して関係付けられる個体の数の最小値と最大値を設定する．
-
動機： Balance of expressivity and scalability goal,, Inconsistency detection
- R15. XMLシンタックス（XML syntax）
-
Webオントロジ言語はXMLのserializationシンタックスを持たなければならない．XMLは産業界で幅広く受け入れられ，XMLを処理するたくさんのツールが開発されてきた．Webオントロジ言語がXMLシンタックスを持てば，これらのツールを拡張し再利用することができる．
- R16. ユーザに表示可能なラベル（User-displayable labels）
-
Webオントロジ言語は，オントロジによって表現されるリソースに対し，ユーザに表示可能な複数のラベルの選択肢からの指定をサポートしなければならない．これは，例えば，オントロジを異なる自然言語で見るのに利用することができる．
- R17. 文字モデルのサポート（Supporting a character model）
-
Webオントロジ言語は多言語文字セットの利用をサポートしなければならない．
動機： Internationalization, Compatibility with other standards
- R18. Unicode文字列の唯一性のサポート（Supporting a uniqueness of Unicode strings）
-
ある文字コード，例えばUnicodeベースのコードでは，ときどき，２つの異なる文字列が同じように見え，同じかどうか比較することを求められる場合がある．一つの例は，前もって合成した形式（一つのcセディア文字）を用いるもので，もう一つの例は分解した形式（セディアアクセント文字が続く'c'の文字）を用いるものである．W3CのI18N WGが初期の統一正規化（Unicode Normal C）をこの問題を解決する普通のアプローチに決めており，その他の解は正当化される必要がある．
-
動機： Internationalization, Compatibility with other standards
5 目標
Webオントロジ言語に含めれるべき特性の集合（前のセクションで定義）に加え，多くのユースケースで有用な他の特性がある．これらの特性は，可能であれば，ワーキンググループで取り組むが，言語仕様から除外するのに，あるいは，将来のワーキンググループでインプリメントするようそのままにするのに，十分な理由があると判断するかもしれない．これらの目標のいくつかは完全に定義されておらず，そういうものとして，Webオントロジ言語がそれらに取り組むなら，更に明確にする必要がある．以下の目標の順番は，相対的な優先順位やコンセンサスの度合を意味するものではないことに注意して欲しい．
- O1. 言語特性の階層化（Layering of language features）
-
Webオントロジ言語はオントロジを定義するための異なったレベルの複雑さをサポートすることができる．アプリケーションは言語全体をサポートしなくても特定の階層に合わせることができる．階層を決めるためのガイドラインは，異なったタイプのデータベースや知識ベースシステムに見い出される機能に基づくかもしれない．
- O2. デフォルトのプロパティ値（Default property values）
-
Webオントロジ言語はプロパティのデフォルト値に関する仕様をサポートしなければならない．デフォルト値はクラスの代表的なメンバーに関する推論を行うのに有用である．しかしながら，本当のデフォルト値は非単調で，これは新しい情報が絶えず発見され追加されるWeb上では問題を含んでいる．更に，デフォルトを扱う一般的に受け入れられている手法はない．その代わりとしては，言語仕様で，独自のデフォルトメカニズムをどのように作るかをユーザに薦めることである．
- O3. 閉じた世界を記述する能力（Ability to state closed worlds）
-
Webの変化の大きさや速さのために，閉世界仮説（closed-world assumption）（推論できないものは偽であるとみなすこと）は不適切である．しかしながら，閉じた世界の情報が有益である場面がたくさんある．したがって，Webオントロジ言語は与えられたオントロジが完全であるとみなすことができることを記述できなければならない．これはそのオントロジから導き出されるべき推論に認可を与えることであろう．このような記述（と対応する推論の集合）の正確な意味論は定義されるべく残っているが，例では，個体に関する完全なプロパティ情報を仮定し，クラスのメンバーシップの完全性を仮定し，さらにサブクラスの十分性を仮定することなどを含むかもしれない．
- O4. 値域のデータタイプに関する制約（Range constraints on data types）
-
Webオントロジ言語はプロパティの値の値域を特定する能力をサポートしなければならない．このメカニズムはXML Schemaのデータタイプから借用するだろう．
- O5. 連鎖したプロパティ（Chained properties）
-
Webオントロジ言語はクラスやプロパティに関する記述においてプロパティの組合せをサポートする必要がある．プロパティの組合せの例は，uncleOfという名前のプロパティがfatherOfとbrotherOfのプロパティの組合せと同じであることを記述する場合である．
- O6. 効果的な決定手続き（Effective decision procedure）
-
Webオントロジ言語は決定可能でなければならない．
- O7. オントロジの一部分への付託（Commitment to portions of ontologies）
-
Webオントロジ言語はオントロジの一部分への付託をオントロジ全体への付託と同様にサポートしなければならない．しかしながら，ここでどのような大きさの粒子を用いるべきかは明確でない．可能な選択肢は，コンセプトのサブセットを全部の定義と一緒に選択するか，個体の定義だけを選択するかである．コンセプトの部分的定義を借りてくることは，異なるアプリケーションが異なるものを意味するのに同じ識別子を用いるために起こる潜在的な互換性の問題に取り組まなければならないことに注意して欲しい．
- O8. 視点のメカニズム（View mechanism）
-
Webオントロジ言語はオントロジの視点を作る能力をサポートしなければならない．その視点の下では，オントロジのサブセットを指定でき，コンセプトに別の名前を割り当てることができる．これは特にオントロジの多文化版を開発するのに有用である．この要求事項が，複数のオントロジを持ち，オントロジマッピングメカニズムを用いることによって満足されることに注意して欲しい．
- O9. デジタル署名の統合（Integration of digital signatures）
-
W3CのXML Digital Signatureの仕様は信頼性の低いプロパティ間のコミュニケーションのための重要な構成要素で，多くのオントロジアプリケーションにとって重要である．Webオントロジ言語はXML Signatureの使用に向けて設計されるべきである．
- O10. 算術演算子（Arithmetic primitives）
-
Webオントロジ言語は算術関数の使用をサポートする必要がある．算術関数は異なる尺度の単位間の変換に使用することができる．
- O11. 文字列処理（String manipulation）
-
Webオントロジ言語は文字列結合と単純なパターンマッチングをサポートする必要がある．これらの特性は，複合的な情報を，フォーマット化された文字列として取り扱うオントロジと，各構成要素に対して独立したプロパティを持つものとして取り扱うオントロジの間の互換性を確保するために利用できる．例えば，あるオントロジは人の名前を"lastname, firstname"という一つの文字列として表現するが，別のオントロジはそれぞれに対するプロパティを持つ．
- O12. 統合とグルーピング（Aggregation and grouping）
-
Webオントロジ言語はSQLのGROUP BY節に似た方法で情報を統合する能力をサポートしなければならない．それは，計数，加算，及び各グループに対して計算されるべき他の操作を許さなければならない．これは粒子の大きさの違うレベルにある情報を表現したオントロジ間の互換性を許し，予算費目の総計と予算項目の合計との関係や，社員数と従業員に関する個人データとの関係のように，物事の関係付けを行うことができる．
- O13. 手続き付加（Procedural attachment）
-
Webオントロジ言語は複雑な基準（criteria）を評価するための実行コードの使用をサポートする必要がある．手続き付加は言語の表現能力を大きく拡張するが，形式意味論には適していない．Webオントロジのための手続き付加のメカニズムはいかに手続きの場所を特定し実行するかを規定する必要がある．こうした可能性のある言語の一つがJavaで，既にWeb上のプラットフォームによく適応している．
- O14. ローカルな名前の唯一性の仮説（Local unique names assumptions）
-
一般に，Webオントロジ言語は名前の唯一性の仮説（unique names assumption）を設けない．すなわち，別個の識別子が異なる個体を指すことを仮定していない（要求事項R11参照）．しかしながら，名前の唯一性の仮説が有効なプリケーションはたくさんある．ユーザは特定の名前空間やドキュメントのすべての名前が別個の個体を参照することを明記するオプションを持つべきである．
- 015. 複合データタイプ（Complex data types）
-
Webオントロジ言語は複合的な／構造化されたデータタイプをサポートする必要がある．これらは日付，対等の組，住所などを記述するのに利用できる．
謝辞
このドキュメントは，多くの人々，特にW3CのWeb Ontology Working Groupのメンバーの仕事を表現したものである． Raphael
VolzとJonathan Daleは，このドキュメントの以前の版の編集を助けてくれた． オリジナルのゴールの多くは，Deborah
McGuinnessによって提供された要求事項のリストに基づいている． 企業のWebサイトマネージメントのセクションのドラフト版は，Michael
Smithによって書かれた．