このドキュメントは
Content Interoperability Use Case final draft
http://lists.w3.org/Archives/Public/www-webont-wg/2002Jan/0066.html
の和訳です。
この文書には和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版文書を参照して下さい。

会議資料: コンテンツ相互運用性の使用事例
            最終ドラフト

送信者: Leo Obrst (lobrst@mitre.org)
日付: 2002年1月7日月曜日

  • 次のメッセージ: Dan Connolly: "必読書リスト、ftf ページ [は 会議資料である。文書の最終版...]"

    メッセージID: <3C3A1167.64594252@mitre.org>
    日付: 2002年1月7日月曜日 16:21:43 -0500
    送信者: Leo Obrst <lobrst@mitre.org>
    宛先: W3C Web オントロジー‐ WG <www-webont-wg@w3.org>
    主題: 会議資料: コンテンツ相互運用性の使用事例 最終ドラフト
    
    
    各位殿
    
    拝啓、
    サブグループによるコンテンツ相互運用性の使用事例に関する会議の事前資料の最終ドラフトを
    添付しています。会議に備えて本書をお読み下さい。来週の会議で皆様が取り上げたいとお考えの
    コメント、提案、その他追加の問題について、皆様との意見交換を楽しみにしております。
    
    

    敬具

    Leo -- _____________________________________________ Dr. Leo Obrst The MITRE Corporation mailto:lobrst@mitre.org Intelligent Information Management/Exploitation Voice: 703-883-6770 7515 Colshire Drive, M/S W640 Fax: 703-883-1379 McLean, VA 22102-7508, USA W3C Web オントロジー WG: コンテンツ相互運用性の使用事例 2002年1月7日 0. はじめに 本文書はOntology Web Language (OWL)--オントロジーWeb言語--のコンテンツ相互運用性の使用 事例のカテゴリを述べたものである。 コンテンツ相互運用性に関連する使用の特別な事例は数多くの提供者や数多くの提供リストや組織 から集めたものである。 特定の事例が数多く(22)あるため、それらをより一般的な事例カテゴリ(8)に集約した。 一般的な事例カテゴリ(これはより抽象的な定義であるが)を使用することによって、使用事例の テーマをたてわけ、Webオントロジー言語の要件に合致するように分類することができる。 本書は以下の様に構成されている。 1. コンテンツ相互運用性の使用事例への参加者 2. コンテンツ相互運用性の範囲と定義 3. (19の使用事例から集めた)Webオントロジー言語のための一般要件 4. 特定の使用事例の索引 5. 一般使用事例の索引 6. 一般使用事例 7. 特定の使用事例 本文書は量が多いため、1-6章と詳細な付録の役割をしている7章(一番量の多い章)を中心に読み 進められることをお勧めする。 コメントや提案をご自由にお送り下さい。 1. コンテンツ相互運用性の使用事例への参加者 Leo Obrst (議長) lobrst@mitre.org Pat Hayes phayes@ai.uwf.edu Dan Connolly connolly@w3.org Mike Dean mdean@bbn.com Herman ter Horst herman.ter.horst@philips.com Deborah McGuinness dlm@ksl.stanford.edu Raphael Volz volz@fzi.de Ora Lassila daml@lassila.org 2. コンテンツ相互運用性の範囲と定義 一般的な記述: コンテンツ相互運用性には、セマンティック相互運用性とデバイスへコンテンツを配布したり、 マッピングしたりすることに関係する相互運用問題などと言った概念が含まれる。 セマンティック相互運用性とは、大まかに言うと、セマンティックを保持するアプリケーション間 のオントロジーがサポートしているコンテンツを送受信する機能、もしくは、セマンティックの方 法を変えずに異なるオントロジー間でマップする機能のことである。 もう一つの側面としては、セマンティック等価や、二つのオントロジー間での整合性の決定。そし て、オントロジーの連携と合併がある。 本使用事例に含まれるものは以下である。 - データベーススキーマからオントロジーへのセマンティックのマッピング - 分類法や分類システムからオントロジーへのセマンティックのマッピング - オントロジーからオントロジーへのセマンティックのマッピング - オントロジークラスからオントロジーインスタンスへのセマンティックのマッピング - オントロジー連携および、オントロジー合併の反転としてのオントロジーの分離と分解- オント  ロジーのマッピングをサポートするオントロジー言語拡張子 - オントロジーを使用した電子商取引の基準とカタログマッピング - 独立したオントロジーがサポートしているWebサービスの動的な合成 - オントロジーを使用したユーザやアプリケーション、特定のタスクを元にしたオント  ロジー "表示(view)" の構築や保存、および、デバイス - オントロジー間での翻訳 - オントロジーの合併 コンテンツ相互運用性のサブタスクは以下である。 - オントロジーマッピングをサポートする概念の検索 - バージョンに関する問題: マッピングが一旦、作成され、保存され、更新され、  時間が経過してオントロジー自身が変更するとどうなるのか - ユーザやタスク、アプリ-ケーション表示、文脈記述や構築のためオントロジー言語をサポート - メタ-知識でオントロジーに注釈をつける機能(そして恐らく具体化) 3. (19の使用事例から集めた)Webオントロジー言語のための一般要件 本章では、一般使用事例と特定の使用事例から集約したものとして、OWLの一般要件について記述す る。以下の各要件は、この要件を必要とする一般使用事例のリストである。 3.1 さまざまな情報限とサービスを表すオントロジーの相互関係/マッピング/合併/翻訳 1. オントロジーネーム空間とオントロジー間での参照: 他のオントロジーの用語を参照する大きな   オントロジーを表現する必要がある。(A, C, E, F, H) 2. オントロジー翻訳: オントロジー間で翻訳する必要がある。(A, B, C, E, F, H) 3. オントロジーマッピング規則と特徴: セマンティックマッピング規則、オントロジ間の特徴を表 現し、概念、関係、インスタンス/個人間での一貫した関係を確立できる。(A, C, E, F, G, H) 4. オントロジー合成言語: 異なるオントロジから情報の合成が可能である。(A, E, H) 5. オントロジーサービス合成言語: オントロジーベース合成的な処理と既存のサービスを合成 できるサービス記述言語 (D, E) 6. オントロジーマッピングバージョニング: オントロジー間の関係のマッピング複数のバージョン   をサポートする。(Gとすべて) 7. オントロジー照会言語: 複数のオントロジーについての回答をサポートする。:   オントロジーには概念Aがあるのか? オントロジーXでAは何を意味しているのか? (B, C, D, E, H) 8. オントロジー間の同意語/別名: 一つのオントロジーにある概念、もしくは、個人/インスタンス は他のオントロジーにある概念や個人/インスタンスの同意語/別名 (A, C, E, F, G, H)であると   表現する。 9. 不整合性の管理: 大規模で分散したシステムでは、不整合性は避けられない。そのため、不整合 性に左右されない標準の意味が必要である。(A, C, E, F, H) 10. オントロジー信頼: 信頼/信用のオントロジー(B, C, E) 11. オントロジーの近似: オントロジー間でマッピングをするには矛盾処理や、仮定を元に した信頼維持、非単調性、そして、近似関係の表現が必要な場合がある。(A, C, E, F, G, H) 12. オントロジー間の認証: 認証、オントロジー間の整合性チェックサービス、オントロジのマッ プされた部分を整合性があるとタグ付けする、整合性チェックの日付など。(F, G, H) 3.2 デバイス/リソースの相互運用性のサポート 1. オントロジー情報の伝送: 異なるデバイスへオントロジー情報を配布するので、低域幅やメモリ などを低く抑えることができる。オントロジーの表現言語はメモリ領域が小さい場合でもデバイ スプロパティを表すことができるように、分かりやすくて、簡潔でなければならない。デバイス の範囲はさまざまである: 経済的な範囲から考えると、少なければ少ないほど、領域もよりよい ものが必要になる。デバイスのオントロジーがあまりに大きすぎる場合、そのオントロジーに唯 一の参照だけが利用可能でなければならない。(A) 2. 分散されたオントロジー: デバイスオントロジーは、分散されたオントロジーを形づくる他のデ バイスオントロジーと論理的な始まりと終わり/決定論的なトラバース方式でリンクできなけれ ばならない 。(A, C, F, G, H) 3. デバイス間通信言語のためのオントロジー言語サポート(A) 4. 合成: デバイスの合成にはオントロジーの情報の合成が必要である。(A) 5. オントロジーパーティション: 分離したオントロジーのパーティションの一部は、物理的な境界と 論理的な境界(デバイスの合成)に関して、認識可能でなければならない。(A, F, H) 6. 反映: デバイスは自身のオントロジーに関するパーティションを認識しなければならない。(A) 7. 分散されたデバイスプロパティ: 配下のデバイスのプロパティの合計が合成デバイスを超えた場 合、それらのプロパティは複数のノードに物理的に配置できる。(A) 8. 所有: デバイスプロパティは、複数のエンティティで所有、制御、管理されてもよい。その所有 社、制御者、管理者はプロパティ値を変更してもよい。(A) 9. 管理の代行: 管理は代行させることができる。(A) 10. リソースメタデータ: 管理されているリソースには、管理機能、つまり、アクションや時間間 隔、動作記録ログ、所有/管理者/代行、そして、同期的なイベントを記述しているメタ属性が ある。(A) 11. デバイスプロパティの更新と配布/遠隔認識: 種類や値も変更できる。種類変更は他のサービス   /デバイスで発見でき、種類のセマンティックはすぐに解析できる。(A) 3.3 オントロジ作成/管理 1. プロパティ値の更新: オントロジのプロパティは、プロパティ値を提供しているサービス/機能 と関連付けれていなくてはならない(B, C, D, E, F, G) 2. プロパティアクセス条件: プロパティは、アクセス必須条件をサポートしなければならない。 例えば、監視ネットワークは、管理ネットワークによる書き込みができるが、書き込みは防が   なければならない。(A, すべて) 3. メタ知識と具体化: メタデータや具体化などで、オントロジー的な構造の注釈をサポートする。 例えば、プロパティ値にはデータの新しさや、ポーリング/イベント間隔、または、新しさの目標、 値の許容範囲、例外条件などを記述したメタ属性があるべきである。 (B, C, D, E, F, G) 4. プロパティの分類: 恐らく、2番目の構造やメタクラス、具体化などを使用してのプロパティを分   類する能力(例えば、構造的、化学的)(C, E, F, G) 5. 時間: 時間特定の拡張子を作成する能力(すべて) 6. ユーザ/開発者のアクセスおよびバージョニング: 管理更新は、承認された更新のみを許可し、 アクセス制御され、バージョニングされ、ロールバックは更新であるべきであり、 意図したように動作すべきでない。バージョニングにはメジャー、差分、モジュール、ノードが 含まれるべきである。(B, C, D, E, F, G) 7. オントロジーのモジュール化: (再利用によって相互運用性を行う)モジュール化の基本原則 および、分割スキーム、階層的なモジュールの構造をサポートする必要がある。 8. オントロジーの拡張性: 非常に大きく、拡張性のあるオントロジーが可能になるべきである。 (すべて) 9. オントロジーの複雑な層: 表現的な機能に関する複雑で異なる層をサポート。 (B, C, D, E, F, G) 10. イントラオントロジー検証: 検証や、オントロジーの整合性チェックサービス、整合性がある とオントロジーをタグ付けすること、整合性チェックの日付などを可能にする。(C, E, F, G) 11. オントロジーサービス: アプリケーション用のオントロジーサービス(例えば、推論や、 照会サポート、特定のプロパティを持つ概念をすべて検索するなど)をサポートする。 (C, E, F, G) 3.4 オントロジーの表示/文脈、言語サポート 1. プレゼンテーション対プレゼンテーション: (基本のデータベースを変更しないデータベースの 表示の様に)基本のオントロジーのプレゼンテーションとその基本のプレゼンテーションを区別 する。これにはアクセス権への関係が含まれる。 つまり、特定のユーザの役割は基本となる論 理的な関係を変更できるが、別の役割ではプレゼンテーションの関係しか変更できないことなど。 (A, C, D, E, F, G, H) 2. オントロジーの文脈: 変更された文脈の使用に合わせて、オントロジーの構造や規則が使用でき る。例えば、機能的なサブオントロジー対物理的なサブオントロジーなど(E, F, G) 3. 表示/文脈の合成: オントロジーの表示/文脈の合成が可能である。(繰り返し?) (E, F, G) 4. イントラオントロジーの同義語/別名: あるオントロジーの概念や個人/インスタンスが同じオン トロジーの他の個人/インスタンスの同義語/別名であると表現する。(A, C, E, F, G, H) 5. 語彙のプレゼンテーション: (例えば)オントロジー内に語彙層の表示ができる能力。 これは概念と関連した用語である。(F, H, All) 6. 表示名: 文脈やアプリケーション、言語などに従って、異なるオントロジーの表示名を可能にす る。(F, G) 7. 多言語、多文化のサポート: 多言語でのオントロジーのサポートや多言語のオントロジー間のマ ッピングをサポートできる。 (G) 8.オントロジーの細分性:文脈やアプリケーションの必要に合わせて細分性の測定ができる。(G) 9. 個人化: ユーザが自身の関心やアプリケーションに関してオントロジーを個人化できる。 (D, F, G) 4. 特定の使用事例の索引 本章では(番号で索引をつけている)特定の使用事例の目次とその記述について述べる。 使用事例/タスク説明 1 オントロジーのやり取りが必要で、パームパイロットデバイスが使用できる旅行に関連するタス  クを自動化する。 2 知能エージェントのためのオントロジー表現の交換と翻訳 3 異なるデバイスや合成デバイスのために、オントロジーを使用したコントロールネットワークの管 理および企業のLANやその他の種類のネットワークとの連携 4 オントロジーを使用したデバイス構成の動的側面のサポート 5 オントロジー、特に、OM間のオントロジーのマッピングを使用した知識管理の分散されたOM (Organizational Memories)のための拡張可能で、エージェントベースのミドルウェアの設計 6 Web上の文脈依存とドメイン間の検索 7 異種のオントロジーからの情報の統合/合成 8 サービス間でのATO(Air Tasking Order)の普及 9 偶発性の相互運用性: 二つ(またはそれ以上)のデバイスが相互運用できると認識する 10 計算デバイス間での広範囲な計算をサポート 11 異なるオントロジーを使用した組織ユニット間での協調性の確保 12 基準、そのモデル、そして適合検査の相互評価のサポート 13 文脈や"表示(view)"を元にオントロジーの情報をフィルタリングを行うことによ るCAD技術開発者のサポート 14 製品とサービスの基準をマッピングすることによる知能相互運用可能な電子商取引のサポート 15 異種言語で、異種の組織やコミュニティがオントロジーマッピングを使用して通信、相互運用 をできる 16 自動的にユーザへのコンテンツ(媒体)の表示とその文脈を適合させる 17 DAML Combat Support Agent 18 マルチメディア世代 19 オンラインコンテンツの注釈 20 FIPA セマンティックフレームワークマッピング: 上位オントロジー 21 FIPA セマンティックフレームワークマッピング: ドメイン固有のオントロジー 22 FIPA 情報エージェント: 情報の連携と合併 5. 一般使用事例の索引 本章では(アルファベットで索引をつけている)一般使用事例の目次とそのカテゴリ名とそれらが 取巻くそれぞれ特定の使用事例と。簡単な記述について述べる。 複数の一般カテゴリの中に特定の使用事例がいくつか出てくることに注意。 一般使用事例/カテゴリ/特定の使用事例/記述 A デバイス相互運用性 1, 3, 4, 9, 10 デバイス適合および相互運用性 B 知能エージェント 2, 5, 20, 21, 22 知能エージェントのためのオントロジー表現の交換と翻訳 C 知識管理 5,11,15,19 異なるオントロジーを使用して、組織単位間での協調性を確保 D 知識検索、電子商取引 6, 14 Web上の文脈依存とドメイン間の検索、電子商取引 E 知識統合 7, 20, 21, 22 異種のオントロジーからの情報の統合/合成 F モデル、標準、検査の相互評価 12 標準、モデル、そして適合検査の相互評価のサポート G 文脈/表示マッピング 13, 16, 18 オントロジーの文脈や"表示(view)"を使用可能に することによってユーザ、開発者、デバイスをサポート H コマンド& コントロールメッセージコンテンツの相互運用性 8, 17 サービス間、または、 l コマンドとコントロールドメイン間でのセマンティック情報の伝送 6. 一般使用事例 特定の使用事例から集約した一般使用事例を以下に述べる。 各一般使用事例には以下の形式がある(しかし、全部のフィールドが使用されているわけではない)。 一般使用事例の文字 カテゴリ記述 記述 WEB オントロジーの要件 ----- 一般使用事例: A (1, 3, 4, 9, 10) カテゴリ記述: デバイス相互運用性 - デバイスの適合と相互運用性 記述: 計算デバイスはセマンティックレベルで相互運用ができなければならない。こういったデバイスに は、PCやラップトップ、PDA(personal digital assistants)、プリンタやその他ネットワークデ バイスなどがある。これらのデバイスは同じ目的で使用できる。例えば、旅行の計画など。 これらはドメインへの適切なものとしてオントロジーの同じ集合を使用できるが、 限定された低 域幅や制限されたメモリなどを含む特定の要件にマップされたり、カスタマイズされるべきではな い。 また、デバイスは動的に変化する環境にセマンティック的に採用するべきである。 例えば、新しいプリンタを規定のデバイスのネットワークに追加し場合や、PDAが異なる計算や、 アクセス、そしてセキュリティ要件がある新しい場所に導入された場合など。 最後に、デバイスはWebサービスによって制御可能である。このWebサービスはオントロジーを使用 してタスクの分解とコントロールフローを表示できる。 ドメインの例: 旅行計画、デバイスとネットワーク構成、管理、分散されたWebサービス 代表的なユーザ: 旅行計画者、デバイス/ネットワーク管理者、デバイス利用者 Webオントロジーの要件: ----- 一般使用事例: : B (2, 5, 20, 21, 22) カテゴリ記述: 知能エージェント - 知能エージェントのためのオントロジー表現の交換と翻訳 記述: 知能エージェントは、Web上で生まれたソフトウェアパラダイムである。 さまざまなエージェント基準にはオントロジー言語(FIPA、Agentcitiesなど)の使用が必要である。 この言語は(複数のオントロジーからの)オントロジー表現交換と(あるオントロジーか他のオン トロジーへの)オントロジー翻訳をサポートしなければならない。 さらに、交換や翻訳されるオントロジーは異なるエージェントプラットフォーム/インフラストラク チャー/ドメイン(例えば、Agentcities エージェントで交換するFIPAエージェント)で使用できる。 また、交換/翻訳されるオントロジーは異なる言語(Ontolingua/KIF vs. DAML+OIL or CycL)で表現で きるし、異なるレベルであることもできる。 例えば、上位オントロジーや下位のドメインオントロジーなど。 複数の上位オントロジーや上位オントロジーの一部分が交換/翻訳、そして、判断されなければなら ない場合もある。 同じ個人/インスタンス/データが異なるオントロジーにマップされなければならない場合もある。 照会言語間でマッピングされる必要がある場合もある。(SQL、RQLなど) ドメインの例: 分散されたOM(Organizational Memories)、Agentcities エージェントコミュニ ケーションへのFIPA 代表的なユーザ: 知能エージェント、エージェント開発者 Webオントロジーの要件: ----- 一般使用事例: C (5, 11, 15, 19) カテゴリ記述: 知識管理 - 異なるオントロジーを使用して、組織単位間での協調性を確保 記述: 複数の組織の単位ではWeb上でお互いに通信を行わなければならない。 これらの単位には異なるOM(Organizational Memories)や、知識リポジトリが含まれることがあ り、複数のデータベースや文書のセットをサポートしなければならないこともある。 これらのセットはすべてこの異なるオントロジーで表示することができる。 組織に対してさまざまなレベルがあることがあるため、データ/情報固有のドメインから大企業の レベルまで、さまざまな情報のモデルとそれに相当する語彙がある。 さらに、組織と組織がサポートしているオントロジーは動的に変化することがある。 組織の中には仮想的で、他の既存の組織の合成や分離であったりすることがある。 (例えば、財閥のコミュニティなど) しかし、こういった組織や組織の単位は、オントロジーマッピングを使用して、異種の語彙やモ デルとセマンティック的に相互運用ができなければならない。必要であれば、これらのマッピング は発見され、保持され、更新可能となり、破棄可能になることがある。 ドメインの例: ビジネス組織、財閥のWebコミュニティ 代表的なユーザ: 他の組織からの情報を必要としている組織のメンバ Webオントロジーの要件: --- 一般使用事例: D (6, 14) カテゴリ記述: 知能検索、電子商取引、 - Web上の文脈依存とドメイン間の検索、電子商取引 記述: Web上のビジネス対ビジネス(B2B) およびビジネス対顧客 (B2C)の電子商取引では、買い手はアプ リケーションやカタログ、新旧のB2BまたはB2Cエンジンやインフラストラクチャーのさまざな範囲 から将来の製品やサービスを探し、見つけ出すことができる。 こういったリソースはすべて、分類や分類学、あるいはオントロジーによってモデル化されること がある。 結局、それらはオントロジー言語を使用してモデル化されるのである。 その為、問題はWeb上に異質にモデル化されたり、明示的にまたは黙示的に分類された製品やサービ ス(そして、他のドメインのオブジェクト)をユーザが検索できることおよび、これらのモデルや 分類化システム、またはオントロジー間を概念的にマッピングすることの一つである。 将来の買い手は、個々の会社のカタログや文書にさまざまに表示されている語彙(そして意味)を 使用して製品やサービスを探したいと考える。一方で、将来の売り手は、 将来の買い手が探すこと ができるように、製品やサービスを分類し、適切にモデル化するのである。 このような概念的な検索/ナビゲーション(分類) には、セマンティック的にマップされるオントロジ ーが必要である。 検索の最初(または、他の文脈的な側面)で、マップするための適切な概念を(一部)示すことがあ る("ドリル"が歯科または、精神科の作業の文脈で提示された場合、潜在的に多義的な "ドリル" は変わってくるかもしれない。)ので、概念的な検索/ナビゲーション(分類)は文 脈依存でなければならない。 ドメインの例: B2B 電子商取引 代表的なユーザ: 製品を探す将来の買い手、自分の製品やサービスを特徴づける適切なカテゴ リや特徴を探す将来の供給者/売り手 Webオントロジーの要件: ----- 一般使用事例: E (7, 20, 21, 22) カテゴリ記述: 知識の統合 - 異種のオントロジーからの情報の統合と合成 記述: WebやWebにアクセス可能なアプリケーション(または、LANでローカルに)で表示されている情報は、 ドメインごとや、アプリケーションが解決しようと試みている問題ごと、そして、モデルの複雑さ の度合いに応じてさまざまな方法でセマンティック的に表示されることがある。 オントロジーの概念とその概念が特徴付けている個人/インスタンス/データにはセマンティック的 な合成/統合(そして分離) および、対応する構文上の/形式の変換が必要である。 総合と統合のレベルが数多く必要である。 防御関連のコマンドとコントロールと知識収集状況では、統合は異なるセマンティックモデル (さまざまな種類のシグナルやマップや地政学的な場所の異なる表示、異なる解釈レベルで描写な ど)を使用するセンサーを越えたり、または、知識の証拠収集と分析のための非常に異なる方法で セマンティック的に表示された異なる媒体の文書やデータを超えることがある。概念とデータは マップ、修正、統合されなければならないが、それは、マッピング/修正/統合が不定(継続)で、 分離でき、訂正できる状態において、である。 この使用事例は知能エージェントの使用事例と関連している。 ドメインの例: 防御関連のコマンドとセンサーデータのコントロール統合、知識の収集と分析 代表的なユーザ: 指揮者、知識分析者 Webオントロジーの要件: ----- 一般使用事例: F (12) カテゴリ記述: モデル、基準、検査の相互評価 − 基準、そのモデル、そして適合検査の 相互評価のサポート 記述: 多くの場合、国防総省では特定の基準のセマンティックモデル(オントロジー) の基準や適合検査 の実現に関してその特定の基準のセマンティックモデル(オントロジー)で苦労をしている。 これらの重要な三つのコンポーネントもすべて、お互いに相互関係なしに、動的に変化する。 原則では、モデルで強制されべきであり、基準と一致していると称しているアプリケーションは (作成可能かもしれない) 一連の適合検査によって、その適合に関して検査可能であるべきである。 これには、モデルと基準と一連の基準の検査間でのセマンティックマッピングが必要である。 付加的なある複雑さとは、基準には異なるバージョンがあるので、モデルとその一連の適合検査に は異なるバージョンがあるだろうということである。 ドメインの例: 国防総省の武器、ネットワーク、コマンドとコントロールシステム 代表的なユーザ: コマンドとコントロールシステムのユーザ、開発者 Webオントロジーの要件: ----- 一般使用事例: G (13, 16, 18) カテゴリ記述: 文脈/表示マッピング - オントロジーの文脈や"表示 (view)"を可能にすることによってユーザ、開発者、デバイスをサポート; 記述: アプリケーションは、文脈や"表示(view)"を元にオントロジーの情報をフィルタリン グしたり、表示したりすることによって、ユーザへのコンテンツ表示を合わせなければならない。 センサー検知とCAD技術は、ユーザが関心を持つ特定の表示を表すために文脈上の情報に適合する 二つのドメインである。これらの"表示(views)"はアプリケーション表示(例、個人化 やローカル化のため)の要件、または、ただ単に与えられた時間、恐らく照会への回答、 (例えば、概念の"物理的な" 性質ではなく、"機能的"側面のみを表示するた めに)においてオントロジーの特定の面に重点を置くという要求をもとに抑制/フィルタリングする 必要がある。こういった表示や文脈は合成されたり、操作されたりする必要があるため、オントロ ジーのアプリケーション理論として持続し、主要なものとなるのである。 ドメインの例: センサー検知、 CAD技術、マルチメディア作成 代表的なユーザ: CAD設計技術者、デバイスユーザ、オントロジーアプリケーション開発者 Webオントロジーの要件: ----- 一般使用事例: H (8, 17) カテゴリ記述: コマンド & コントロールメッセージコンテンツ相互運用性 - サーバ間、または、コマンドとコントロールドメイン間でのセマンティック情報の伝送 記述: コマンドとコントロールのための防衛関連のアプリケーション、軍事派遣計画、ロジスティックス などは、サービスと組織ユニット間でマルチドメイン情報を使用し、普及することが必要である。 多くの場合、オントロジーは明確で、セマンティック的にほとんど同じ概念に対しても異なる用語 /意味を採用している。さまざまな軍隊サービスや組織間で命令や情報が行き交う場合や、異なる 目標を達成するために同じ情報をしようする場合、セマンティックをできる限り保持するために 異なるオントロジーをマップする必要がある。 ドメインの例: 防衛指令とコントロール、軍事派遣計画 代表的なユーザ: 指令者、防衛計画者 Webオントロジーの要件: 7. 特定の使用事例 本章に述べる特定の使用事例は、多くの提供者や、数多くの配布リスト、そして組織から集めたも のである。特定の使用事例にはそれぞれに以下の形式がある。 使用事例番号 提供者 記述 ドメインの例 代表的なユーザ Webオントロジーの要件 1. 提供者: Mike Dean タスク: オントロジーのやり取りが必要で、パームパイロットデバイスが使用できる旅行に関連す るタスクを自動化する。 記述: 出張などに関するタスクを自動化するプログラムを書き込んだり、 使用したりできるような方法で、WebOnt を使用して、WWW上で 現在利用可能な情報(そして、現在WWW上で利用できない)を 提供したいと考えている。 この使用事例の重点として、そのドメインを使用する。 私はいつも、実際の旅行代理店に電話する前に旅行計画を立てる。 フライトに関しては、ユナイテッドエアラインの電子時刻表の コピーを使用する。 この時刻表は、毎月(9月11日以降は毎週)、圧縮バイナリー形式 で更新される(時々基本データの抽出に失敗するが)。 このオフライン(例えば飛行機など)で作業できるのが私のお気に入りである。 私は自身の趣向を申請したり、航空に関するその他の情報へリンクしたりで きる様に、この情報をWebOntで得たいと思う。 自分にはお気に入りのホテルチェーンがある。 よく行く場所に関しては、その地域のホテルを知ってはいるが、 詳細については忘れているものがある。 (例えば、どこのハンバーガーがおいしいか、とか、どの場所の部屋を 避けるべきかなど) その他に関しては、Webサイトの情報を検索し、その情報をWebOnt形式で 取得し、私個人の興味の項目のプロパティに追加したいと考える。 私は、ハイスピードの有線または、ワイヤレスのインターネットアクセスが装備 されている部屋を予約しようとする。ホテルのWebサイトはこのサービスを伝える点 では非常に一貫性がない。 あまり慣れていないプロパテイに関して、ホテル提供を行っている大手のISP(CAIS、 STSN、Wayport、そしてMobileStar)が保持しているディレクトリを調べる。 これらのISPは代理店が使用しやすい形式では情報を提供していない (これらのISPのほとんどが、マップやページ、階層そしてPDFを使用している)。 私はこの情報をWebOntで取得し、私の旅行日程とその他地理的情報に合併したいと思う。 予約を行うと、私の会社の旅行代理店は、私の旅行日程を"un-Semantic Web" の規範的な例だと思われる形式でメールする。 その形式とは、従来のファックスで送られた PDF イメージである。 これは印刷はするが、実際にプログラムが処理できない。 私は、WebOntを使用してこの情報を取得し、それを自動的に旅行代理店の個人的なプロ グラムに送ることを選ぶ。 私は同僚と私の旅行日程の一部(例えば、旅行日や到着時間)かを共有するが、 一部(例えば、クレジットカードの番号など)は私個人のものとして残したいと思う。 航空券の予約が終わると、航空会社に電話をして席の予約を格上げしたり、 よりよい席を取ったりする。 (ラップトップを私の前の席の下に置くことができるように)仕切りのない窓側の席を 選ぶ。 ユナイテッドはこの趣向を突き止めることができないので、何度か電話をしなければ ならないことがある。 代理店だったらこの業務をもっとうまく(そして確実に)やるだろう。 そして、ユナイテッドのフライトページングサービスに登録する。 このサービスは、フライトの2時間前か、遅延やキャンセルが発生した場合に必ず、 私のページャにメッセージを自動的に送信する。 問題が発生した場合、自動的に代替のフライトと旅程の設定を特定することがで きるように、私は、代理店に本情報をWebOntで送るように選択する。 また、fly.faa.govの無料サービスに登録する。 このサービスでは、指定した空港の地上待機命令と遅延についてメッセージを送る ものである。 残念ながら、これは私の旅行日程にリンクしていないので、旅行中でなくてもそう いったメッセージを受け取る。 この情報がWebOnt形式だった場合、旅行代理店は私の旅行日程に簡単にクロスリフ ァレンスでき、関連する問題を特定できただろう。 旅行中に、私はPalmDAML [1]などを使用してPDAに早くアクセスしたいと考える。 かなりの長時間空港で待つ場合、私はハイスピードのインターネットアクセスを したいと考える。 普通、そういったサービスを探すにはWebページよりコンコースを探したほうがう まくいく。 そして、私のお気に入りのWebOntオントロジー(に翻訳された)でその情報を取 得したいと考える。時々、アメリカンエアラインのアドミラルクラブを訪れてハ イスピードのMobileStarワイヤレスインターネットアクセスポイントを使用する。 アメリカンエアラインは別のターミナルにあるので、私はいつもゲートの場所や 徒歩何分かかるかについてのWebOnt情報を得る。 知らない町を訪れると、私はいつもハーツでNeverLost GPSを借りる。 ホテルやその他の目的地の道の名前や番号で入念にトグルスイッチをひねるので はなく、IR または Bluetoothを使用して、PDAからWebOnt形式でその情報を送り たいと思う。 また、現在Web上にはない詳細情報を取得したいと考える。 例えば、旅行ルートにそったレストラン(そしてルームサービス)の営業時間 など。遅い時間に到着するフライトの場合、例えば、私の旅行代理店は、 空港出発前に軽食が必要かどうかを尋ねる。 旅行から戻ると、エクセルの表計算シートに旅費を入力しなければならない。 WebOnt形式で旅費が提供されていれば、 私の旅行日程やホテルの領収書やクレジットカードの領収書から直接運用する ことができただろう。 私にはクレジットカード計算書や当座預金で支出の報告を承認するための、 DAMLアプリケーション[2] がある。 報告: 1) 本情報(フライトスケジュールや、旅行日程、ホテルの住所、支出報告など )はオントロジー的に高度ではない。 2) 情報の多くはすでに人間が読むことのできる形式で利用可能である。 3) ユナイテッドの新しいフライトページングサービスなど、   特定のストーブパイプでのみ自動操作ができる。 4) 非常にやる気のある人ですら、現行の情報を合併するのを実践的ではないと知っている。 5) WebOntの使用が普及しているため、 私達はこれらのことを非常に簡単に行うことができるべきである。 [1] http://www.daml.org/PalmDAML/ [2] http://www.daml.org/2001/06/expenses/ ドメインの例: 旅行 代表的なユーザ: 複数のデバイスから旅行の計画やスケジュールを組む必要のある旅行者 Webオントロジーの要件: - 相互関係/マッピング/さまざまな情報源やサービスを表しているオントロジーの合併 - オントロジーの情報を異なるデバイスに配布することによって、より低い低域幅などにへの集約 が発行できる ----- 2. 提供者: Jonathan Dale タスク: 知能エージェントのためのオントロジーの表現の交換と翻訳 記述: エージェントとエージェント技術の実践的な応用を目標としているので、実用的な標準化の観点か らFIPAおよびAgentcitiesはオントロジー表現言語(ORL)を選択することを考えるのである。 - オントロジー表現交換に参加するには。 まず、定義を行おうとしているアプリケーションのほとんどが妥当に小さく、限定されているので、 FIPA および Agentcities が人間中心で、協力的な方法でオントロジーを開発するだろうというこ とを期待する(つまり、上から下にではなく、下から上である、など)。 しかし、将来、ORLも大量のオントロジーを表現し、他のオントロジー、恐らく他のORLで、用語を 参照できることが重要になるだろう。 - オントロジー翻訳に参加するには。 FIPA対応のエージェントプラットフォームのネットワークのノードが増加するにつれ、 ネットワーク内での異種性も増加する。 FIPA は相互運用を通して異種性を統合するモデルを元にしており、適切なORLの主な特徴は他の ORLと互換性があるべきである。 機能性が多様化しすぎている場合、ORL間での翻訳はより難しいものとなるだろう。 ドメインの例: 知能エージェントコミュニティ 代表的なユーザ: サービスが必要なエンドユーザ、知能エージェントの開発者 Webオントロジーの要件: - 他のオントロジーの用語を参照する大量のオントロジーを表現する必要がある。 - オントロジー間での翻訳する必要がある。 ----- 3. 提供者: Ned Smith 以下は、相互運用の使用事例の起こり得るある一日の例である。 背景: 既知事項: UPnP ネットワーク、ANSI 709 ネットワーク (プロトコルゲートウェイで互い に連結している) 既知事項: UPnP デバイス - テレビジョン/ディスプレイ、プリンタ; 709 デバイス -  電子灯、洗濯機 シナリオ: 1) 家のある部屋で本を読んでいる親は、別の部屋で子供が親の指導を必要とするチャン ネルや番組(chX)を選択したときに知らせて欲しいと思う。 2) chX を選択すると、ゲートウェイ経由で通報が送られる。 そのメッセージは、UPnP固有のフォームで表現されているchXは中間のフォームに翻訳されること を示す。 UPnPからWOLの翻訳プログラムは(取り囲むデバイス記述 - 例えば、TVの名前や場所、などを含む) chXの表現から、オントロジーの表現へマップする。 3) WOL構文では、chXの規則がおこなわれる行動を記述する。 その行動は親に通知される。 規則エンジンは、親に通知することとその通知をどのように行うかを決める。 このシナリオでは、親が読書をしている部屋でランプが三度点滅する。 (これは親に通知する方法を決める研究課題になるか、構成上の問題になることがある。) 4) デバイス記述論理とサービス記述論理(例えば、イベントE経由で通知する場所Lでの T時でchX状態のTVにはすべての要素を捕らえるためにサービスオントロジーが必要である。)の要 素で構成されるWOLメッセージ。 (推理規則への引数のような)そのメッセージは 評価され、WOL-->709翻訳プログラムに送ら れる別のメッセージを(WOLフォームで)作成する。 5) 709 翻訳プログラムはそのメッセージを709構文に作り直し、もとの709で操作を行う。 つまり、部屋のランプ X フラッシュ3回 シナリオは、ゲートウェイの他に、別のノードで翻訳を行うために変更されることがある。 (オントロジーのサブセットとして表現されている)そのメッセージは、証明/推理オントロジーで あるゲートウェイ上でオントロジーと合併される。 本シナリオは、規則/ポリシーを著わし、それらをゲートウェイに適用する第三機関の管理サービス を含むために拡張できた。 <-- タスク: コントロールネットワークの管理と、異なるデバイスや合成デバイスのためのオントロジー を使用したコントロールネットワークのLANやその他のネットワークへの統合 記述: 使用事例: 1) センサーデバイス製造者は、他の製造者が作成したセンサー/アクチュエーターと相互運用を行 うデバイスを作成する。そのデバイスの性質はオントロジーのフォームで表現される。 そのデバイスの性質を表現したオントロジー、または、"デバイスオントロジー"はその デバイスに組み込まれる。そのデバイスがネットワークをネットワークに接続する場合、そのオン トロジーを解析し、その機能と統合するのにどうすれば最良なのかを決めるエージェントがそのデ バイスを認識し、ネットワークにインストールすることができる。 一旦インストールされると、デバイスは合成デバイスを構成しているその他のデバイスと連結され る。論理的に唯一のその合成デバイスはネットワーク上のその他のデバイスやサービスと相互作用 する。 デバイス製造者は、相互運用を実現するためにデバイス構成を先見的に検査しようとは思わない。 2) レガシーコントロールネットワークは管理者が邪魔をしない処理を行うが、管理者は特定の 機能を監視したいと思う。 管理者はコントロールネットワーク/処理のオントロジーを作成し、管理している機能をそのオン トロジーのプロパティにマップする。 外部のサービスはコントロールネットワークのオントロジーを発見するかも知れない。 プロパティ値を変更すると、外部のサービスに送る通知イベントをトリガできる。監視機能は遅 延を起こしたりしないし、コントロールネットワークがそのタスクを行うのを防いだり はしない。監視サブシステムは定期的に管理者によって、再構成され、監視されている コントロール処理に影響を与えない。 3) コントロールネットワークは、複数の外部資源活用の管理サービスプロバイダによって管理され ている。 管理の責任はコントロールネットワーク所有者からサービスプロバイダに委任されている。 管理の責任は管理の重複を防ぐ方法で、サービスプロバイダ間で分割されている。 管理行為はアプリケーションの以前に受容可能となるように確認される。 サービスプロバイダは、定期的に責任をどのように分割するかを再交渉する。 以前得た特権のどれかをなくした後、新しい特権を得る。 ドメインの例: コントロールネットワーク管理 代表的なユーザ: コントロールネットワーク管理者とサービスプロバイダ Webオントロジーの要件: 1a) オントロジー表現言語(ORL?) はメモリ領域が小さい場合でもデバイスプロパティを表すこと ができるように、分かりやすくて、簡潔でなければならない。デバイスの範囲はさまざまである- 経済的な範囲から考えると、少なければ少ないほど、領域もよりよいものが必要になる。デバイス のオントロジーがあまりに大きすぎる場合、そのオントロジーに唯一の参照だけが利用可能でなけ ればならない。 1b) デバイスオントロジーは、分散されたオントロジーを形づくる他のデバイスオントロジーと論 理的な始まりと終わりの決定論的なトラバース方式でリンクできなければならない。 1c) 分離したオントロジーのパーティションは、物理的なと論理的な境界(デバイスの合成)に関 して、認識可能でなければならない。 1d) デバイスは自身のオントロジーのプロパティを認識する。 1e) 配下のデバイスのプロパティの合計が合成デバイスを超えた場合、それらのプロパティは複数 のノードに物理的に配置できる 1f) デバイスプロパティは、複数のエンティティで所有/管理されてもよい。 所有者/管理者はプロパティ値を変更してもよい。 1g) プロパティタイプとプロパティ値は変更できる。タイプの変更は他のサービス/デバイスで発見 され、タイプのセマンティックは分析できる。- 願わくば早く! 2a) オントロジーのプロパティは、プロパティ値を与えているサービス/機能と連携可能でなければ ならない。 2b) プロパティはアクセス必須条件をサポートしなければならない。- すなわち、監視ネットワーク は、管理ネットワークによる書き込みを許可するが、書き込みは防がなければならない 2c) プロパティ値にはデータの新しさや、ポーリング/イベント感覚、または、新しさの目標、値の 許容範囲、例外条件などを記述したメタ属性がある。 2d) 管理更新は、承認された更新のみを許可し、アクセス制御され、バージョニングされ、ロールバ ックは更新であるべきであり、意図したように動作すべきでない。 3a) コントロールネットワークのリソースはオントロジーによって記述される。 3b) リソースは異なる/複数のエンティティで管理できる。 3c) 管理責任は代行してもよい。 3d) 管理されたリソースには管理機能を記述しているメタ属性がある。- つまり、アクション、 時間間隔、動作記録ログ、所有/管理者/代行、そして、同期的なイベント ----- 4. 提供者: Stefan Decker タスク: オントロジーを使用したデバイス構成の動的側面のサポート 記述: LastMileServices 内で: ---------------------------------- LastMileServices とは電気通信デバイスの静的そして動的な 側面を記述することを目的としたスタートアップである。 その目標は、大規模なネットワークのサービスの構造と構成を 簡単にすることである。 デバイスオントロジーを定義するために、オントロジー言語を使用する。 (例えば、ルータやスイッチなど) デバイス構成の動的側面を捕らえるために、サービス記述オントロジーを開発した。 このオントロジーは、タスク分離、コントロールフロー(UMLステートチャートの語彙 を使用して)、そして、サービスのデータフローを宣言するためにプリミティブを定義する。 その他のプリミティブは、既存のサービスを合成したり、構成したりして新しいサービスを作成す ることができる。 このことによって、新しいサービス作成を目標にして、構成的なオントロジーベースの処理と (分散されたWebサービスやJavaオブジェクトなどによって与えられた既存のサービスを合成できる サービス記述言語が発生する。 サービス記述はJava コードにコンパイルされ、実行できる。 ドメインの例: 分散されたWebサービス、デバイス構成 代表的なユーザ: Webサービスやデバイスのユーザ、Webサービスの開発者、デバイス開発者 Webオントロジーの要件: 合成的なオントロジーベースの処理と既存のサービスを合成できるサービス記述言語 ----- 5. 提供者: Mike Sintek タスク: オントロジー、特にOM間でのオントロジーのマッピング、を使用して、知識管理の分散さ れたOMのための拡張可能で、エージェントベースのミドルウェアを設計する。 記述: 以下は、FRODO [2]プロジェクトの(そして、知識管理のための)オントロジーを記述している[1] からの文章の一部である。 FRODO プロジェクトでは、分散されたOMのための拡張可能で、エージェントベースのミドルウェア を設計する。 知識管理(KM)では、概念化[Gruber91]の明示的な仕様としてのオントロジーはアクセスや知識の再 利用をしやすくする有益な方法を提供することが広く受け入れられている。 典型的な利用のシナリオは、ディスカッショングループ、検索エンジン、情報のフィルタリング、 非逐語的なオブジェクトへのアクセス、そして、専門的なユーザの通信で構成されている。 OMの文脈では、オントロジーは、キーワードベースから、概念ベースの管理、索引、検索方法へ進 歩するために情報ニーズと同様に情報リソースを指定する言語を提供する。また、知識強化された、 または、知識補助された検索の基礎を形作る。 これらのアプリケーションで、オントロジーは正式に表現された"共有言語による開示の仕様 "としての役割を果たす。KMは一般的に複数の行為者のシナリオを処理するので、このような 共有理解は特に重要である。 知識管理の展望では、誰が知識を取得し、それをどこに格納し、どのように明確に述べるか、という 企業の知識の綜合的な使用を想定する。このような展望に対する技術サポートは *一元化されたアプ ローチ* に準拠する。 このアプローチは利用可能な*完全な*情報を考慮することを保証するためにうまく適合しているよう に思われる。 例えば、、KnowMoreフレームワークから取り出したOM 参照アーキテクチャー(添付の図を参照のこと) では、一貫した*知識記述レベル*の導入によっていくつかの異種の情報源の問題に取り掛かる。 さまざまな情報項目は、一致する語彙や情報、企業、そしてドメインオントロジーに準拠した知識記 述によって注釈をつけられる。 その為、分散された情報の特徴に関する一元化された見方が構築される。 FRODO プロジェクトでは、私達は、一元化された(KnowMore)フレームワークを結果的には*ドメイン オントロジーサービス*が必要となる*分散化された OM* シナリオへ拡張することを目的としている。 これには、ドメインオントロジーをOMを付加し、他のOMからオントロジーサービスにアクセスする という便利さが必要である。 従って、私達は二つのオントロジーサービスを提案する。それは、 ドメインオントロジーエージェ ント(DOA) と分散されたドメインオントロジーエージェント(D2OA)である。ドメインオントロジー エージェントは *ひとつのOM内*のオントロジーのためのサービスであり、分散されたドメインオン トロジーエージェントは*複数のOM間*に配置されており、OM間における通信を容易にしている。 その為、D2OAのタスクは非常に "標準情報統合オントロジー" (例えば、マッピングサ ービスなど)に類似しているが、ソースが単なる"情報サービスプロバイダ"ではなく、 すでに正式なオントロジーであるため、それ以上に使いやすい。 DOAへの一般的な質問として、"概念Aのサブ概念は何か?" というのがあるのにたいし、 D2OAは、"AやBと言った概念をどのOMが持っているのか?" または、"OM_yのAとは どういう意味なのか?"というような回答を行っている。 この構造は、受け継いで分散された(オントロジーの)知識の性質をよりよく採用している。 *すべての概念化* がシステムの*すべての行為者* 間で共有されているわけではないが、*オント ロジー社会* は関連するドメインに関して形作られる。インフラストラクチャーを増加すること はオントロジー社会の間の通信を可能にする。 [1] http://citeseer.nj.nec.com/450299.html [2] http://www.dfki.uni-kl.de/frodo/ ドメインの例: 知識管理と、特にOM(Organizational Memories) 代表的なユーザ: 組織内、または組織間での情報を検索するエンドユーザ Webオントロジーの要件: - オントロジー間でのマッピングのサポート - 複数のオントロジーについての回答のサポート: オントロジーには概念A があるのか?、オントロジーXでAは何を意味するのか? ----- 6. 提供者: Jeff Heflin タスク: Web上の文脈依存とドメイン間の検索 記述: - 文脈依存Web検索 - ドメイン間Web検索 - Web上での質問の回答 ドメインの例: 代表的なユーザ: Web検索をしているユーザ Webオントロジーの要件: これらの要件では、完全なWebオントロジー言語で必要な特徴を示している。 私は、SHOE やDAML+OILI での経験から学んだ結果として、このリストを何度も練り上げた。 これらの要件の中には、WebOntワーキンググループの範囲外のものもあるが、後の、 セマンティックWebの"層"のために保存すべきである。 しかし、今それを特定すると、後にそれらを追加することをオントロジー層のデザインは禁止 することはないと確証できる。 <抜粋:> オントロジー発達の管理 [HH00, KF01, Hef01 (3.4章)] バージョン番号、またな、改訂関連 セマンティックの後方互換性 異議 異種のオントロジーの相互運用性 オントロジー間のマッピング機能 同義語 個々の同義語を含む! サブクラス / スーパクラス 倒置関係 接続詞、 離接的接続詞、言外の意味 算術的な機能 グループ化 文字列操作 手続き的接続? Java? 不整合性の管理 大規模で分散されたシステムでは不整合性は避けられない 不整合性でも標準の意味は必要 信頼/信用のオントロジー 矛盾処理を優先させる[GLC99] 仮定をベースとして信頼保守システム (ATMSs) [dK86] 単調ではない 他の方法? 拡張性 表現を制限? 完全な推理アルゴリズムを望む? 参考文献 [dK86] J. de Kleer. An Assumption-based TMS. Artificial Intelligence, 28(2), pp. 127-162, 1986. [GLC99] B. Grosof, Y. Labrou, and H. Chan. A Declarative Approach to Business Rules in Contracts: Courteous Logic Programs in XML. In Proc. 1st ACM Conf. on Electronic Commerce (EC-99), 1999. (PDF) [Hef01] J. Heflin. Towards the Semantic Web: Knowledge Representation in a Dynamic, Distributed Environment. Ph.D. Thesis, University of Maryland, College Park. 2001. (PDF) [HH00] J. Heflin and J. Hendler. Dynamic Ontologies on the Web. In: Proceedings of the Seventeenth National Conference on Artificial Intelligence (AAAI-2000). AAAI/MIT Press, Menlo Park, CA, 2000. pp. 443-449. (PDF) [KF01] M. Klein and D. Fensel. Ontology Versioning on the Semantic Web. In First International Semantic Web Working Symposium (SWWS'01), 2001. (PDF) ----- 7. 提供者: Leo Obrst タスク: 異種のオントロジーからの情報の統合/合成 記述: 分析または、参照モデルへソースをモデル化した異なるオントロジーからの情報の合併/合成 (例えば、防衛関連の指令と意思決定の管理など)。 ドメインの例: 防衛のコマンドとコントロール 代表的なユーザ: コマンドとコントロールのアナリスト Webオントロジーの要件: - 異なるオントロジーでサポートしている情報を合成することができる ----- 8. 提供者: Eric Hughes, MITRE, Leo Obrst (その他の人々によって提供された情報を含む) タスク: サービス間でのATO(Air Tasking Order)の普及 記述: 各軍事サービス(空軍、陸軍、海軍など) はコンテンツメッセージのXMLマークアップを使用 する普及機能をすこしずつ導入している。 これらのDTDとスキームは、防衛情報システムエージェンシー--Defense Information Systems Agency (DISA)--の XML レジストリに登録されている。 しかし、異なるサービスで提供するスキーマ間で統合する機能はまったくないし、セマンティック も表現しない。 ATOはさまざまな目的でさまざまな軍事組織によって使用される必要がある。 ドメインの例: 軍事派遣計画と上空領域管理 代表的なユーザ: 以下のユーザは代表的である。派遣計画者、兵站学の計画者、指令者、軍事気候 学者、航空交通管理者 Webオントロジーの要件: ----- 9. 提供者: Ora Lassila タスク: 偶発性の相互運用性: 二つ(またはそれ以上)のデバイスが相互運用できると認識する 記述: ここでは私が最終的にWebOntで行いたいことを記述する。 私は(携帯電話やプリンター、センサーなど)さまざまなデバイス特徴や機能を記述することに関 心がある。 私は(デバイスとソフトウェアの機能を記述する際)CC/PPと(発見や合成などを目的としたWebサー ビスのセマンティックを記述する際)DAML-S の両方から取り出したいと思う。 最終的な目標は、"偶発性の相互運用性"である。この偶発性の相互運用性では、二つ (普通はそれ以上) のデバイスが相互運用性ができるように設計されていなくてもそうできると認 識する。(例えば、異なる目的のために作成することによって、または、異なる製造業者が異なると きに作成する、など) "輪の中に"人間のいないこれらすべて、つまり、私が、デバイスが他のデバイスと意味 あるダイアログに参加するのを見たいと思うことである。 私は、この夢の重要な部分としてデバイスの機能のセマンティックを表現する強力な言語を知って いる。 言語に加え、私達にはそれを実現するのには適切な語彙とオントロジ-が必要である。 私は当然、研究志向の問題を選択したことに対して謝罪しなければならない。 すべての人が研究機関を代表していないことと、実践的で、短期間の目標を持っているわけではな いないことを認識している。 しかし、このワーキンググループがセマンティックウェブのビジョンを実現しようとする先駆けと なっているため、中にはこのグループに所属している人もいる。 (このことに関心のない人はこのメッセージを読み飛ばしてもよい。 :-) セマンィックWebは*難しい*問題である。どうして? なぜなら、より簡単な例の多くは、他の方法で解決できるからである。 - RDFやDAML+OILの推論などは必要ない。 (これは、私がセマンティックWebとは何か、と言うことを説明しようとし、過去5年間行った時に 受け取った答えである。) 情報を統合したり、交換するために、より賢いXSLT やPerlのプログラマの団体を採用することによ って、妥当な数の情報システムが作成できる。 そして、人はこれを行い、同様にこのアプローチをWebサービスに拡張する。 私達が行おうとしていることは性質的に難しいものである。 問題は、簡単なシナリオを使用して表現したり、説明したりできないことである。 セマンティックWebが役に立つしっかりとした事例を作成したいと考えると私は思う。 そうしなければ、"XSLT マジック"を信じている人達にいつも遭遇するだろう。 システム(仮想、または、物理的)の"内容すべてを表示しない" 相互運用性に関しては、 十分に強力な*標準化された* 表現言語が成功し、私達は問題のシステムのセマンティック (のいくつかを)を著わし、予期しない状況で妥当なレスポンスが作成できるようになる。 [1] http://lists.w3.org/Archives/Public/www-webont-wg/2001Dec/0022.html -- Ora Lassila mailto:daml@lassila.org http://www.lassila.org/ Research Fellow, Nokia Research Center ドメインの例: 複数の計算デバイス 代表的なユーザ: デバイス Webオントロジーの要件: ----- 10. 提供者: Tim Finin タスク: 計算デバイス間での広範囲な計算をサポート 記述: 私達は、モバイル計算や広範囲な計算環境のデバイスのために、サービス記述、発見、照合、 そして交渉をサポートするためにセマンティックWeb言語を遂行することに関心がある。 特に、よりよく自身のタスクを行えるように、デバイスが、"文脈"を認識できるという ことに関心がある。 私達は、提供され、追求されたサービスを記述するためにDAML+OILを使用するJINIのバージョンの 開発を含む予備の作業をいくつか終了した。 また、サービス記述やBluetooth Service Discovery Protocolの照合のためにRDFを使用するシステ ムも開発した。 Chaitanya Pullela, Liang Xu, Dipanjan Chakraborty, Anupam Joshi, "Component based Architecture for Mobile Information Access", 2000年8月に行われた、 2000 International Conference on Parallel Processing (ICPP 2000)の議事録 2002年3月17日〜21日オーランドで行われたIEEE Wireless、Computing and Networking  Conferenceで提出された Sasikanth Avancha, Anupam Joshi, そして Tim Finin, の Enhancing the Bluetooth Service Discovery Protocol, ドメインの例: 複数の計算デバイス 代表的なユーザ: デバイス Webオントロジーの要件: ----- 11. 提供者: Alexander Maedche タスク: 異なるオントロジーを使用した組織ユニット間での協調性の確保 記述: 私達は、異なるアプリケーションの分野でセマンティックWeb技術を探求している。 知識管理(例えば、人的資源の能力のオントロジー、仮想組織、 複数のオントロジーを使用した異なる部門[1]間での協同作業、E-ラーニング[2]、 そして、知識とコミュニティのポータル[3] 脚注: [1] http://www.ontologging.com [2] http://edutella.jxta.org [3] http://www.ontoweb.org ドメインの例: 知識管理 代表的なユーザ: 別々の組織単位やコミュニティのユーザ Webオントロジーの要件: - (例えば)オントロジー内の語彙層の表現 - (再利用によって相互運用性を行わせる)モジュール化の基本原則 - 拡張性 - 異なるオントロジー間でのマッピング規則の表現 - 表現能力に関する異なる複雑な層をサポート ----- 12. 提供者: John Stanton タスク: 基準、そのモデル、そして適合検査の相互評価のサポート 記述: 国防総省にいつも必要だと思われることは、二つの分野に分かれる。 私の判断ではそれは、相互運用可能な製品を作成するセキュリティ & フォーマル方式である。 フォーマル方式とは、表現の正式な方法に重点をおいたものではない。 - 叙述規則で表現される文脈に縛られない、または、 文脈から依存の要件; または、自身のBackus-Naur Formの変形を 行うこと。 つまり、接続され、定義の元で基準と連携している相互基準開発プロセス、 モデル、そして、一緒に進歩しているような適合検査システムで ある。 これら三つの要素が、明確に定義された国際的なプロセスで一緒に展開 する場合、DODは経済的に節約をし、他にもすごいイベントが起こるだろ う。 私達は売上規模上位500社と同じくらい多くのソフトウェアを購入する。 99%が相互運用可能であると、残り1%がプラットフォーム間での転送に 何百万かかるか、技術者に高額を支払うか、 または、その製品の寿命まで高い保守を必要とする製品に遭遇する。 この1%の非相互運用性の製品に遭遇すると 国際的なソフトウェア工業技術を開発し、モデル化された製品、検査さ れた製品、進歩した製品など、品質を作る三つの要素を使用して、基準 における表現の正式な表現が不足していることと、 ほとんどの場合、国際的で、包括的な基準開発プロセスが無いというこ とを突き止めることができる。 その為、その製品は、適合検査をする方法がなく、何を買ったかもわか らないし、何百万を支払うことになる。 ドメインの例: 国防総省の武器、ネットワーク、指令とコントロールシステム 代表的なユーザ: 指令とコントロールシステムのユーザ、開発者 Webオントロジーの要件: ----- 13. 提供者: Ruediger Klein タスク: 文脈や"表示(view)"を元にオントロジーの情報をフィルタリングして CAD技術開発者を支援 記述: 技術開発者への支援をしたいと考えている。 使用事例では、技術開発者はCADシステムの前に座り、技術業務を行っている。 その技術者は同時にセマンティックWeb文書で作成された技術の最高のプラクティスにアクセスする。 基本となるオントロジーを使用して、私達は、その技術者に相当する部分のみをを提供するために、 その情報をフィルタリングする。 持ち上がる質問は、文脈を元にした情報をフィルタリングすることと、特定の業務(例えば 分類はカタログを見るよりも異なる表示を行う。)に適応するオントロジーに関する表示を行うこと、 そして、要素間の制約は特定のプロパティの値を計算するのに使用できるということである。 より詳細に、私達はたくさんのオブジェクトやプロパティや関係で非常に複雑な世界を模倣している。 こういったモデルは数多くの異なる人々によって幾分か同時に作成されるべきである。 すなわち、あるチームの人々が、一人ではなく、我々の世界を発展させているということである。 多くの人たちが別々に同じ世界を模倣しているため、私達は、関わっている人たちへの手引きとな る構造を提供したいと思う。 中心となる業務は、関係者が行った変更/編集における整合性を確保することである。 例えば、グループの会議、私達はその世界で技術部品や生産過程段階、材料などをある方法で模倣 すると言うことに同意した。 これらは同意した方法で、幾分か関係がある。 これは共通にフレームワークに同意し、実際のモデリングを導く役割をしている。 モデリングを実行する人たちは現在、技術部品や生産過程段階、材料などを専門化し、その専門化 のプロパティを定義し、それらを同意した関係の中に置く。 要約すると: (a) 複数の人でオントロジーのモデリングの整合性をとる (b) ユーザの文脈に準拠したオントロジーに関する表示を変更する(スクリューを選択する際の分類 学対分類); (c) 要素間の関係を表現するための制約 この文脈で重要な部分は以下の方法で、統括できる。 1.工業技術情報 工業技術情報は、主に、以下の点で特徴づけられる。 - 知識の大きな集合体: 材料や部品、コンポーネントのカタログ、材料の目録、供給者情報、幾何 学的なシミュレーションとその他のモデル... - 工業技術情報の異なる部分でのさまざまな相互関係: 要件、機能的な記述、挙動、構造、幾何 学的構造 - 算術に元づき、特に、幾何学的なモデルは工業技術情報の統合された部分である。 工業技術ITツールの全分野は、現在、工業技術の問題解決のある側面に専念している。 : 大規模なデータベースシステム、PDM (製品データ管理--product data management--) ツール、CAD、数字のシミュレーションシステム、ワークフローなど。 現在、この複雑な情報の大部分はITシステムで表現されているわけではなく、手順コード内に 無条件に残されている。 工業技術とは、必須の協同的な作業である。: 多くの人達が工業技術問題解決で交流する - 解決されるタスクに関する特別な展望を提供しながら。 結果として、一般的な技術工業環境で現在使用されているその多くの異なるITシステムは、 - (STEPのような基準を使用して)その相互運用の能力に制限がある。 - 相互運用のための特別な"手作りの" インターフェースが必要である。または、 - セマンティックが隠れる場合は、データ交換だけしかできない。 2. 工業技術におけるセマンティックWeb セマンティックWebの観点から、工業技術情報を取り扱うの主に三つの側面がある。 2.1.) 要件、機能的な記述、挙動、構造、幾何学的構造などを取り扱う大きくて、セマンティックが豊 富な工業技術オントロジー 2.2.) l工業技術に関する異なる見方 - 共同作業に関わるさまざまな人たちの見方を反映している (あるいは、同じように、一貫した方法で異なるオントロジーを統合する) 2.3.) (関連する)コンテンツの変更: バージョン、(類似) 異型、モデルの次の段階、ワークフローなど 3. セマンティックWebの要件 私達は、現在話題となっているセマンティックWebが本当にこういった問題を解決するとは思って いない。 これらはあまりに深く、あまりに普及している。しかし、工業技術の改良された問題処置として使 用できるようにするため、セマンティックWebは基本の機能をいくつか持つべきである。 3.1.) 情報の大きなオントロジーと集合を組み立てる - オントロジーの階層的なモジュール式構造をサポートする。 - オントロジーの知識についてのメタ知識 (タグ付けや具体化を含む) 3.2.) 異なる見方 - ユーザ特定の見方はオントロジーの一部、または、トップとして定義できる。 - 異なるオントロジーは(一部)合併できる。 3.3.) 算術と幾何学的構造 一般的な記述論理を以上に、工業技術オントロジーには豊富な算術的/幾何学的なモデリング機能 が必要である。 4. 有用な要件 作業を行うには、以下の三つの必須条件を満たしているべきである。 4.1.) 一般的な目的と、アプリケーションから独立しているが、ドメイン特有の "基準" オントロジー (機能性や構造、挙動、幾何学構造などについての)はアプリケーション特有情報 モデルの"出発点"として提供されるべきある。 4.2.) 複雑な工業技術オントロジーを取り扱うために、高度なツールが必要である。例えば、検索と知能 モデリングの整合性のために。(また、経験豊かなエンドユーザになるべきである。特に、" より低く" より、頻繁にオントロジーの部分を変更するなど) 4.3.) データベースやツール統合のために高度な技術が必要である。: 現在"非セマンティック Webフォーム"で現在利用可能な工業技術を使用できなければばらない。 ドメインの例: CAD/CAMをベースとした自動車設計システム 代表的なユーザ: CAD/CAMシステムを利用する工業技術設計者 Webオントロジーの要件: ----- 14. 提供者: Deborah McGuinness および Leo Obrst タスク: 製品とサービス基準をマップして知能的相互運用可能な電子商取引のサポート 記述: - 知能的で相互運用可能な電子商取引。保全性チェックのような簡単なことや、UNSPSCやeClass などの"基準"の上位オントロジーへの合併やマッピングなどのようなより複雑なもの を含むすべてのレベルのサポートのためにオントロジーを使用する。実際、OntoWeb コンテンツ 基準グループは UNSPSC や eClass などの間でマップするのに難問を投げかけている。 例えば、B2B の電子商取引国際語 (http://www.ladseb.pd.cnr.it/infor/ontology/OntoWeb/SIGContentStandards.html)をサポートするなど。 単なる初期のバージョンには、Directory Westfieldなどのような電子のイエローページが含まれ ている。これのもっと複雑なバージョンには実際の構成や複雑なドメイン間での解決策がある。 オントロジー強化設定の初期の例には PROSE/QUESTAR [5]での作業が含まれる。 [5] http://www.research.att.com/~dlm/papers/ieee-expert.html ドメインの例: ビジネス対ビジネス(B2B)の電子商取引 代表的なユーザ: 異種のカタログで製品を探す将来の買い手、共通の取引言語へのマップが必要な 異種カタログを持つ売り手 Webオントロジーの要件: ----- 15. 提供者: Raphael Voltz タスク: オントロジーマッピングを使用して、通信と相互運用を行うために、異種言語を持つ異なる 組織やコミュニティ 記述: 一番目のシナリオでは、オントロジーは、単一で共通の言語を提供する。 この共通の言語は人間と機械との間の通信基礎としての役割をする、つまり、異種データの統合のた めのセマンティックデータモデルや、使用される共通のビジネス用語として使用されるのである。 FZI 研究プロジェクト"Ontologging" は、一つの部門内ではこの共通の語彙を超える。 困難な問題は、異なる語彙をサポートしている異なる部門を通しての国際的な知識アクセスである。 例えば、財務と人材資源部門との間での人間と機械との通信を確立することなど。 このアプローチの背後にあるアイデアは、人々が自身のオントロジーを使用するが、異なるオントロ ジー間(この場合、他の部門)でのマッピングは自動的に発見され、システムの使用内でユーザに提 案されるというものである。 そして、ユーザは、そのマッピングを明確に表現するか否かを決める。 オントロジー言語はそういったマッピング(つまりDAML+OIL に相当するものがクラス/プロパティの 等価を表現するために使用できる)を表現できなければならない(または、少なくとも、表現を容易 にできなければならない)。 ドメインの例: 財務部門と人材資源部門間の部門間通信 代表的なユーザ: 財務部門の従業員、人材資源部門の従業員 Webオントロジーの要件: ----- 16. 提供者: Herman ter Horst タスク: 自動的にユーザへのコンテンツ(媒体)の表示とその文脈を適合させる 記述: 存在するセンサーがどのオブジェクト(例えば、誰が)がある部屋/スペースにあるのかの判断を 下すことを想定する。('簡単' な方法にはそのオブジェクトをタグ付けすることが含まれる)  そのオブジェクトはオントロジーに記述される。また、コンテンツのメタデータもオントロジー に記述される。人の趣向に関わる情報、例えば、媒体コンテンツに関することなど、を含めるこ とは適切なことである。センサー検知とその記述は文脈(居間や事務所、移動状況)についての 結論を導くための基本を形作り、この文脈へのコンテンツの表現と適合させるために形をなす。 また、これには、例えば、特定の設備を個人化するために使用される行動の仕様を文脈から独立 した形で含むことがある。協同のフィルタリングの主題へ自然な接続をすることができる。 最後に、異なるユーザのプロフィール間での比較ができる一方で、 ユーザプロフィールの表現の個人モードを許可することが望ましい。 ドメインの例: センサー検知 オントロジーの例: 代表的なユーザ: Webオントロジーの要件: ----- 17. 提供者: Mary Pulvermacher, MITRE タスク: DAML Combat Support Agent 記述: DARPA エージェントマークアップ言語--Agent Markup Language-- (DAML) とその関連のツールを Combat Support とAir Tasking ドメインに応用したいと思う。私達は、データとFY01 ngJBI (Joint Battlespace Infosphereの次世代)パイロットで開発した知識を構築することを計画して いる。このパイロットは、Expeditionary Aerospace Force (AEF) コンバットサポートアクティ ビティと戦域Air Tasking Order (ATO)ミッションを連携させた同期のCombat Support Order (CSO) を構築しようとしていた。人間の知識がオントロジーで手順コードに元から組み込まれており、 それらのオントロジーを使用するエージェントである場合、アプリケーションを入れ替えること によるDAMLへこのパイロットを拡張する。 ドメインの例: 関係ある三つのドメインがある。それは、 派遣計画--Mission Planning-- 実戦サポート--Combat Support-- 軍用輸送--Transportation-- 代表的なユーザ: 代表的ユーザーには以下がある: 派遣計画--Mission Planning--: 派遣計画チームの意志決定者 * Air Operations Centerの派遣計画チームの意志決定者のメンバーは実戦のための Air Tasking Orderを開発する。メンバーは、航空機の可用性、特定の標的に対する 適切な軍用品、そして戦闘目標を成し遂げるのに必要なサポート設備(RADAR, Inertial Navigation Systems, Electronic Countermeasures)を考慮にいれ なければならない。 実戦サポート--Combat Support--: AFFORスタッフの意志決定者 * A-4/AFFOR のスタッフは、航空機の状態、軍用品の可用性、サポート設備、 必要な能力と資格をもつ人材、燃料などを追跡する。計画されていた軍事用品の使用と その補充を計算する。また、人的資源や航空宇宙場の設備など、重要な資産を管理し、 その使用を最適化しなければならない。 軍用輸送--Transportation--: Air Mobility Command's Tanker Airlift Control Center (TACC)の計画者/調整者 * TACC は空輸資産を貨物の優先コードを元に割り当て、目的地に着くまで貨物の動きを 監視する。 Webオントロジーの要件: ----- 18. 提供者: 2001年12月の初めにアムステルダムで行われた行われたOntoWeb会議の際の オントロジー言語基準についてのOntoWebへの特別な関心について、CWI Amsterdam の Jacco van Ossenbruggen が提出 タスク: マルチメディア世代 記述: CWI AmsterdamのJacco van Ossenbruggen はマルチメディア表現世代に関しての研究についてグル ープに紹介した。: 意図したシナリオは以下である。データベースへの紹介に対する回答で、 ユーザは媒体項目の集合を返信する。; 問題はその項目をその紹介に答える一貫したマルチメディ ア表現に結合することである。このために、これらマルチメディア項目とその関係に関する情報が 多量に必要になる。表限の要件は以下である。 - 異なるレベルの異なるオントロジーの必要性。     例えば、媒体特有、ドメイン/コンテンツ特有、表現特有 - 結合したこれらのオントロジーすべてについての判断を下す必要性。     オントロジーが必要な推論は、クラスやインスタンスレベルで推論を     結合する。小前提方式の推論は必要ないように思われる。 - 大きな現行のオントロジー、その中の必要な部分だけを使用する必要性。     従って、 情報隠蔽/モジュール化の概念の要件がある。; これらの異なる 現行のオントロジーも異なるコミュニティから来る可能性があるので、     構文翻訳が必要となる。 - 最後に、グループはデータベースから"入力メタデータ"を再利用     し、それを出力表現に組み込みたいと思っている。     また、これにはメカニズムをマップし、インポートする必要がある。 現在、グループの仕事はすべて、自家製の特定の記述ソリューションに符号化される。 しかし、よりはっきりとした宣言言語に移行することに強く関心がある。 ドメインの例: データベースがサポートしているマルチメディア表現 オントロジーの例: 一般的ユーザ: マルチメディアデータベースを紹介するユーザ Webオントロジーの要件: ----- 19. 提供者: 2001年12月の初めにアムステルダムで行われた行われたOntoWeb会議の際の オントロジー言語基準についてのOntoWebへの特別な関心について、KMI/OU-UKの Enrico Mottaが提出 タスク: オンラインコンテンツの注釈 記述: KMI/OU-UKのEnrico Mottaは、オンラインコンテンツの注釈についての研究についてのべた。 アプリケーションに必要なオントロジー言語の特徴として、具体化機能を強く主張した。 参加者からの意見では、その機能はエージェントベースのアプリケーションでも必要であると の提案があった。 Daimler-Chrysler社のRudiger Klein は二番目の作成が必要であると主張した。 (具体化と似ているが同じではない。) Rudiger Klein が必要としている例は以下である。 - 特定のタイプとしてクオリティプロパティを修正する。 (例えば、構造的、化学的) - 同じオントロジーに関する異なる見方を選択する。 - 拡張性のために(例えば、言語が提供しない場合は、時間特有の構成をオントロジー言語に 付加する); - オントロジー内にメタデータを格納する。(例えば、ソース、著者、信頼性) - 概要を注釈するようなアプリケーションでもこういった機能は必要である。 (例えば、議論的な構造を巣くる) サブプロパティ階層でこのうちのどれだけが実現可能か、と言うことと、メタクラス(子--Protege --が提供したメカニズムのような)メタクラスでどれだけ実現可能か、と言うことのあとに、 包括的な議論が行われた。 また、いろんな人が具体化の多くと、2番目の構造はより 単純な種類で、コンピュータ使用の根拠 にはならないことを指摘した。 ドメインの例: オントロジーの例: 代表的なユーザ: Webオントロジーの要件: -具体化 - 2番目の構造、または、プロパティ入力のためのメタクラス (例えば、構想的、化学的) - オントロジー表示 - 時間特有の拡張子 - オントロジーメタデータ ----- 20. 提供者: Jonathan Dale  2001年10月カリフォルニア州パサデナで行われたFIPA オントロジー技術委員会から 提出元: FIPA オントロジー TC: オントロジーの使用事例 ontology@fipa.org2001年12月19日 記述: セマンティックフレームワークマッピング: 上位オントロジー これらの分野での使用される上位オントロジーにはいくつか種類がある。 上位レベルオントロジーは以下のために使用される。 セキュリティのポリシーや会話のポリシーのようなポリシー ??法的な約定、社会的な約定、倫理的な約定などのような約定 ??代理店間で結ぶことのできる契約 これらのオントロジーはポリシーや契約、約定の構造やコンテンツについての知識を提供する。 また、一般レベルの各コンポーネントの意味、これには、以下が含まれる。 ??ポリシーと契約内で使用される用語や基礎 例えば、ポリシーの上位オントロジーは構造的な用語や、法的な用語、社会的な用語、そして、 その他全体的にポリシーと密接な関係がある一般用語を含むことができる。 ??これらの基礎がどのように与えられた約定やポリシーや契約の中で合成できるかを定義する原理 ??これらの用語とそれに関する理由を扱うセマンティック ??異なる上位オントロジー間での相互関係、オントロジー間の関係の性質と傾向、上位オントロ ジー間からドメイン特有のオントロジー間への関係 例えば、約定や法的システムの前後関係にポリシーが存在する場合。 これらの上位オントロジーの一つの性質、いわゆる、ポリシー、は上位オントロジーからは例示さ れていないが、ポリシーは定義され、その使用は進んでいると一般的には例示される。 ドメインの例: オントロジーの例: 代表的なユーザ: Webオントロジーの要件: ----- 21. 提供者: Jonathan Dale 2001年10月カリフォルニア州パサデナで行われたFIPA オントロジー技術委員会から 提出元: FIPA オントロジー TC: オントロジーの使用事例 ontology@fipa.org2001年12月19日 2.2 ドメイン特有のオントロジー 下位レベルのオントロジーはよりドメイン特有なものである。 例えば、特定の分野で、ポリシーを定義する場合。与えられたドメイン特有のオントロジーは いくつかの上位レベルのオントロジーとの関係の中に存在し、その関係は表現されなければな らない。 また、上位オントロジーを使用して表現されたポリシーは異なるドメインや異なる使用 で異なるように例示してもよい。 下位レベルは複数のモデルや表現を持つことができる。オントロジー自身はオントロジーの集合か らの用語について推論できなければならない。このオントロジーの集合とは、与えられたインスタ ンスが偶然に使用されたオントロジーの集合である。 ドメインオントロジーの定義は上位オントロジーの用語や原理を直接表現すると再利用や適合の妨 げになるのですべきではないと言うことに注意。また、ポリシーや約定や契約の例示期間を超えて 行われる。複数のオントロジーの問題のため、そう言ったポリシーなどについての推論はポリシー や規定や契約が完全に例示されないことがあるという事実に順応できなければならない。 使用事例 1. エージェントA、B、C はオントロジーO1とO2について知っている。 2. データ集合D1 はある地方Rの地形図についての情報を提供する。 また、データ集合D1にはその地域の傾斜と概観の場所単位での情報がある。 D1のオントロジーはO1で、システム C1と対等にするために、場所と参照するx点、 y点とを関連付ける。 3. データ集合D2 はある地域Rの土壌の種類の情報を場所単位で提供する。 D2 のオントロジーは O2で、 システムC2と対等にするために、場所と参照するx点、 y点とを関連付ける。 Aはワイン用の葡萄の栽培に適した地域Rの地域について知りたいと思っている。 AはBにR内で、条件にあう種類の葡萄が育つのに適切だと知られている特定の様相と 土壌の種類がある場所すべての情報を求める。 5. Bはデータ集合D1とD2にアクセスすることによって、この質問に満足のいく答えを出すことが できるが、二つの異なるオントロジー01と02に従って記述された場所と照合しなければならない。 6. BはCに適切な土壌の種類と様相の場所と照合するために、オントロジー01の場所をオントロ ジー02の相当する場所に翻訳するように依頼する。 ドメインの例: オントロジーの例: 代表的なユーザ: Webオントロジーの要件: ----- 22. 提供者: Jonathan Dale 2001年10月カリフォルニア州パサデナで行われたFIPA オントロジー技術委員会から 提出元: FIPA オントロジー TC: オントロジーの使用事例 ontology@fipa.org 2001年12月19日 5. 情報エージェント 5.1 情報の連携と統合 情報エージェントシステムにおいて、オントロジーが使用される方法の一つに、さまざまな情報 源から導入しようとしているデータについての知識を表現するというものがある。情報エージェ ントはスキーマの様なオントロジーを使用してデータベースの様な方法で、例えばSQLを通じてな ど、情報を操作することがある。代わりに、何がオントロジーにあるのかについて条件をつける。 例えば、 ??オントロジーは、エージェントシステムが利用する必要のある各情報源の要素カバーしなければ ならないが、すべての情報源からの概念すべてをオントロジーに表現することを意味しない。 ??データに直接関係するオントロジーの一部には、関係的な操作を通じて、操作しやすい仕様があ る必要がある。すなわち、実体や関係、そして、その属性として表現される概念。 ??異なるソースからの関係する情報が、関係結合操作を使用して結合される必要がある場合、 その結合で指定された属性は同じ方法で表現されなければならない。 (これは、他の場合では必要ではないということに注意。他の属性に同じ表現をさせる情報操作 には優先順位はない。) 一般的に鍵に似た方法で照会処理の展望から属性は表示される。 この場合、正規の表現に代替表現がどのように関連するのかに従って、オントロジーにこれらの 属性や知識のための正規の表現の知識を原理の形式に組み込ませることが望ましい。 ドメインの例: オントロジーの例: 代表的なユーザ: Webオントロジーの要件: