将来型文書統合システムに関する標準化調査研究

平成 16 年度
将来型文書統合システムに関する標準化調査研究
成果報告書
平成 17 年 3 月
財団法人
日本規格協会
情報技術標準化研究センター
□この報告書に添付している JIS/TR 原案は、制定の審議の過程において
変更があり得ます。
また、ISO 等での今後の国際的審議の結果、変更されることがあります。
まえがき
将来型文書統合システム標準化調査研究委員会(AIDOS)は, 2001年度からその活動を開始した。その目的は,
既存の電子文書関連規格の体系整理して, ウェブ上に蓄積された大量の多次元多言語対話形文書を統合的に
扱うためのモデルを構築し, 関連する標準化課題を調査研究することであった。
当初の3年間の計画を完了した昨年度末には, XML化情報検索プロトコルがなお検討途上にあり, W3Cからは
OWL(ゥェブオントロジ言語)の勧告が公表された。そこで, さらにAIDOSの活動を継続することがより大きな
成果につながると判断し, 2004年度の活動を行うことにした。
その結果, Library of Congressで進行中であったZING(Z39.50-International: Next Generation)の活動と
ハーモナイズしたXML化情報検索プロトコルを作成するとともに, OWLのTS原案を完成し, さらにオントロジ
技術の応用に関する標準化提案の寄書をIECに提出することができた。
AIDOSでの検討対象は, 文書への知的参照構造であった。今後はそれをさらに進めて文書の知的利用構造とそ
の属性を明らかにし, 必要な標準化を行って, AIDOSが可能にした広域文書アクセス環境の上に広域文書利用
機能を追加することが望まれる。
平成17年(2005年)2月
将来型文書統合システム標準化調査研究委員会
委員長小町祐史
目次
1. 委員会活動の目的と課題………………………………………………………………………1
2. 委員会構成………………………………………………………………………………………2
2.1 組織構成 ……………………………………………………………………………………2
2.2 委員一覧 ……………………………………………………………………………………2
3. 2003 年度計画 ………………………………………………………………………………… 4
3.1 WG1 計画 ……………………………………………………………………………………4
3.2 WG2 計画 -- 将来型文書が具備すべき条件 -- ………………………………………5
4. 活動内容 ………………………………………………………………………………………10
4.1 WG1 活動内容………………………………………………………………………………10
4.2 WG2 活動内容………………………………………………………………………………17
4.3 将来型文書統合システム調査研究委員会審議…………………………………………18
5. 成果 ……………………………………………………………………………………………19
5.1 WG1 成果……………………………………………………………………………………20
5.2 WG2 成果……………………………………………………………………………………22
6. 今後の課題 ……………………………………………………………………………………22
6.1 WG1 今後の課題……………………………………………………………………………22
6.2 WG2 今後の課題……………………………………………………………………………23
附属資料
A. 作業グループ WG1
A.1 TS X 0xxx 原案 OWL ウェブオントロジ言語概要
A.2 TS X 0xxx 原案 OWL ウェブオントロジ言語手引き
A.3 TS X 0xxx 原案 OWL ウェブオントロジ言語機能一覧
A.4 TS X 0xxx 原案 OWL ウェブオントロジ言語意味論及び抽象構文
A.5 TS X 0091 原案 XML 化情報検索プロトコル
A.6 TR X 0xxx 原案日本語検索機能記述のための指針
B. 作業グループ WG2
B.1 OWL の現状
B.2 IEC/TC100 への提案
B.3 TV 視聴者の嗜好に基づく番組推薦へのオンロトジー応用の可能性について
B.4 ネットワーク管理へのオントロジ適用
B.5 ベイズ理論の迷惑メール対策への応用
B.6 企業組織における将来型文書
B.7 RSS 現状と将来
1. 委員会活動の目的と課題
1.1 目的
現在, Web上での文書情報交換が急速に普及しているが, 将来は動画, 静止画, 音楽, 音声等多次元多言語対
話形文書のやりとりの実現が期待される。今後は, 誰もが効率的に情報生成, 流通, 管理, 再利用する環境
を整備するため, 今から標準化の検討に着手する必要がある。
そのため, 委員会を設置して次の項目について調査研究を行い, 産業, 公共分野等における情報化や個人の
情報リテラシーの向上を図る。
z
z
z
1) 既存の電子文書関連規格の体系整理
2) 多次元多言語対話形文書統合システムのモデル化, それらの標準化課題の抽出及び規格の作成
3) 関連ビジネスモデル及びメタモデル
これらの調査研究項目への対応は, 1)を本委員会, 2)を作業グループ1(WG1), 3)を作業グループ2(WG2)が行
う。
1.2 主要課題
(1) WG1(分散文書管理)
z
z
z
z
z
Web文書のAPI
Web上に分散するトピック間の関連付け
文書統合検索プロトコル
ウェブオントロジ言語
その他の関連課題
(2) WG2(メタモデル)
z
z
z
z
セマンティクウェブ
メタデータ, メタモデル関連技術
オントロジ
その他の関連課題
-1-
2. 委員会構成
2.1 組織構成
将来型文書統合システム標準化調査研究委員会(AIDOS)は, 図2.1に示すとおり, 二つの作業グループ(AIDOSWG1, AIODS-WG2)をもつ。AIDOS-WG1が, 主として分散文書管理に関する標準仕様書(TS)等の原案を作成す
る。AIDOS-WG2は, 主としてメタモデル, セマンティックウェブ等に関する調査研究を行う。それらを調査研
究委員会(AIDOS)がレビューして承認すると共に, 成果を経済産業省産業技術環境局に提出する。
将来型文書統合システム標準化調査研究委員会(AIDOS)
｜
｜
├── 作業グループ1(AIDOS-WG1)
｜
└── 作業グループ2(AIDOS-WG2)
図2.1 委員会の組織構成
2.2 委員一覧
将来型文書統合システム標準化調査研究委員会(AIDOS), 作業グループ(AIDOS-WG1, AIODS-WG2)の構成メンバ
(2005年2月現在)を, それぞれ表2.1, 2.2, 2.3に示す。
表2.1 将来型文書統合システム標準化調査研究委員会構成メンバ
氏名
委員長小町祐史
勤務先
パナソニックコミュニケーションズ(株)
委員
委員
委員
大野邦夫
宮澤彰
安達文夫
(株)ジャストシステム
国立情報学研究所
国立歴史民俗博物館
委員
委員
委員
飯島正
慶應義塾大学
黒田信二郎紀伊国屋書店
内山光一東芝ソリューション(株)
委員
河込和宏
(株)東芝
委員
委員
菊田昌弘
出葉義治
(株)シナジー・インキュベート
ソニー(株)
委員
委員
長村玄
山田篤
ネクストソリューション(株)
(財)京都高度技術研究所
経済省堀坂和秀
事務局内藤昌幸
事務局宮古牧子
経済産業省産業技術環境局
(財)日本規格協会情報技術標準化研究センター
(財)日本規格協会情報技術標準化研究センター
-2-
表2.2 作業グループ(WG1)構成メンバ
主査
氏名
勤務先
小町祐史パナソニックコミュニケーションズ(株)
委員
委員
飯島正慶應義塾大学
内山光一東芝ソリューション(株)
委員
委員
委員
大野邦夫 (株)ジャストシステム
須栗裕樹 (株)コミュニケーションテクノロジーズ
内藤求 (株)シナジー・インキュベート
委員
委員
平山亮
宮澤彰
金沢工業大学
国立情報学研究所
委員山田篤 (財)京都高度技術研究所
経済省堀坂和秀経済産業省産業技術環境局
事務局内藤昌幸 (財)日本規格協会情報技術標準化研究センター
事務局宮古牧子 (財)日本規格協会情報技術標準化研究センター
表2.3 作業グループ(WG2)構成メンバ
氏名
勤務先
主査
委員
委員
大野邦夫
新麗
飯島正
(株)ジャストシステム
(株)インターネットイニシアティブ
慶應義塾大学
委員
委員
内山光一東芝ソリューション(株)
大場みち子 (株)日立製作所
委員
委員
委員
河込和宏 (株)東芝
菊田昌弘 (株)シナジー・インキュベート
黒田信二郎紀伊国屋書店
委員
委員
委員
小町祐史
須栗裕樹
出葉義治
パナソニックコミュニケーションズ(株)
(株)コミュニケーションテクノロジーズ
ソニー(株)
委員
内藤求
(株)シナジー・インキュベート
委員
委員
山田篤
鈴木潤一
(財)京都高度技術研究所
日本オラクル(株)
経済省堀坂和秀経済産業省産業技術環境局
事務局内藤昌幸 (財)日本規格協会情報技術標準化研究センター
事務局宮古牧子
(財)日本規格協会情報技術標準化研究センター
-3-
3.1 WG1 計画
2004年度の実施計画を示す。
3.1.1 ウェブオントロジ記述言語
W3CのOWL(ウェブオントロジ言語)の内容を検討し, 必要なパートについてその翻訳の公表を図る。規定内容
の検討の結果, 必要に応じて, 自然言語の差異に伴う二次的な属性の差異を明らかにし, その扱いの指針(日
本語プロファイルなど)を示す。
3.1.2 XML化情報検索プロトコル
日本語図書館情報の統合検索を容易にするため, XML化情報検索プロトコルZING(Z39.50 International Next
Generation)に対して, 日本語(及び多言語)環境に必要な規定を追加する。
既に2003年度にLibrary of Congressに提出したZING拡張案に, さらに追加の拡張提案を行い, それらをまと
めて, TS X 0091:2004原案とする。
SRWのver.1.1の拡張機能を使った拡張については, 実装によって確認することが望まれる。
3.1.3 日本語検索機能記述のための指針
昨年度に作成した"図書検索利用者への指針"をさらに見直して, 日本語検索機能記述の内容を充実させ, TR
原案を作成する。
-4-
3.2 WG2 計画 -- 将来型文書が具備すべき条件 -WG2の計画として, 将来型文書が具備すべき条件を明らかにする。
3.2.1 コンテナとコンテンツ
文書の役割は人類の歴史を通じて重要であったし、今後もその重要性は変わらない。文書はメッセージ（コ
ミュニケーション手段）であると同時に記録である。紙媒体から電子媒体への移行は、文書の性格を大幅に
変えるものであった。最大の変化は、文書を容器と中身に分離し得たことにある。
紙の場合は媒体と内容は一体である。それに対し、電子媒体では文書は構造を持つことが可能である。それ
は、言わば容器と中身、すなわち、コンテナとコンテンツに分離して考えることが可能なことを意味する。
印刷文書については、コンテナとコンテンツは一体と記したが、紙をコンテナとしてコンテンツを印刷して
あると見ることも可能である。
コンテナは、単票の場合は一枚の紙であり、綴じられたものの場合は、冊子や書籍といった体裁を取る。コ
ンテンツは、文字、図形、画像といった静的な情報の場合と、映像やアニメーションといった動的な情報の
場合もある。このような文書の見方は、複合文書と言われる。最近W3Cは複合文書の検討グループを立ち上げ
て、この分野の標準化に着手した[1]。
3.2.2 コンテナとコンテンツの歴史
将来型文書も、基本的に上記のようにコンテナとコンテンツに分離して考察することが可能であろう。それ
を具体的に把握するために、コンテナとコンテンツの歴史的変遷を踏まえて考えてみたい。紙媒体による印
刷文書の歴史は、グーテンベルグが印刷技術を確立したルネッサンス・宗教改革の時期にまで遡ることがで
きるが、ここではコンピュータが商用に使われだした1950年代から考察することにする。
第1期（1950s~）
この当時、コンピュータはセンターの大型計算機であり、入出力のコンソールとして、キーボードプリンタ
端末が用いられていた。キーボードとプリンタを用いたコンテンツ配信サービスとしては、コンピュータを
介さないで通信網を中継して端末間で直接通信するテレックスが普及していた。このサービスの場合のコン
テナは言わばプリンタ用紙（ロール紙、LP用紙）であり、コンテンツはテキスト文字であった。類似の方式
のサービスとしてファクシミリによる画像通信があげられる。この場合はコンテナがやはり紙であり、コン
テンツは画像である。音声サービスの電話も類似のサービスであるが、コンテナの概念を持ち出すのは無理
がある。音声に関しては放送もあるが、このサービスは不特定多数への一方向一括サービスである。映像に
関するテレビ放送も同様である。
したがって、この当時のサービスは、ネットワークサービスと放送サービスが分離され前者に関しては、文
字、画像、音声という情報メディアが用いられ、後者に対しては、音声、映像が用いられていたことにな
る。いずれにしろ、センターの大型計算機の段階ではコンピュータの参与はほとんど無かったと言える。
第2期（1960s~）
このころになるとコンピュータがTSSで使用されはじめ情報検索サービスが始まった。この場合のコンテナ
は、プリンタ用紙（ロール紙、LP用紙）であり、コンテンツはテキスト文字であった。このモデルは、第1期
におけるテレックスの片側が人間の代わりにコンピュータに変わったようなものである。1960年代は、アポ
ロ計画に象徴されるように米国の科学技術の成果が発展した時期であった。コンピュータユーティリティ
（ガスや水道、電気のようにコンピュータ資源を提供する）という概念が提唱され、Project MAC（Multi
Access Computing）が推進され、MulticsというTSSによるネットワークOSが開発された。この時期の計算機
科学の進展はすばらしいものであったが、センターにおける計算機の強化を指向していたので実用的な進展
はあまり見られなかった。したがってコンテンツ的にはテキスト文字が主流であったが、COBOLの普及によ
り、事務分野へのコンピュータの導入が進展した。CAD分野でプロッタが使われるようになり、図形がコンテ
-5-
ンツとしての地位を獲得した。コンテナはやはり紙である。
第3期（1970s~）
1971年にマイクロプロセッサが発明され、利用者の手元でコンピュータを使うことが可能になった。その結
果、インテリジェント端末と呼ばれる、多様な通信手順や簡単な編集機能を持つ通信端末が用いられるよう
になった。端末の編集機能をローカルな計算機として特化したワードプロセッサが登場し、従来のタイプラ
イタに代わってオフィスで普及していった。
大型コンピュータ向きのネットワークOSであったMulticsを小型のマシン向けにリファインしたUnixがベル研
究所で作成された。このOSは製品としてではなく研究者用のツールとして、当時一般的に普及し始めたDECの
ミニコン上で提供され、大学などで使用されはじめた。多くの研究用のソフトウエアがUnix上で開発され、
それらが研究者間で相互に利用される文化が醸成されていった。その中には、文書作成や編集用のソフトも
含まれ、研究者の文書処理環境として普及していった。その典型がnroffやtroffといったマークアップ言語
で、ワープロや写植編集のために用いられるようになった。このようにして、コンテナとして冊子や書籍が
登場した。[2]
それと呼応するかのように、ゼロックスのパロアルト研究所で、ALTOと呼ばれるパーソナルコンピュータが
作成された。ビットマップディスプレイを用いるウインドウシステムやインタフェースのためのマウス、そ
れらをコントロールするプログラム言語として、Smalltalk、Interlisp-D、Mesaが開発された。センターの
大型計算機とは異なる発想とアーキテクチャのパーソナルコンピュータの誕生である。ビットマップディス
プレイ上に従来紙に書かれていた文字、図形、画像を表示することが可能になった。ALTOマシンは研究用で
あったが、パロアルト研究所以外の大学や公的な研究機関でも使用され、以後のワークステーション、パー
ソナルコンピュータのアーキテクチャの基礎を形成した。[3]
第4期（1980s~）
ALTOマシンの商用版とも言える、ゼロックスのStarワークステーションが市販され、文書処理環境の世界を
大きく変えるインパクトをもたらした。70年代に研究的に試用されはじめた冊子や書籍としてのコンテナが
一挙に実用になったと言える。その基本思想は、WYSIWYG（ウイズィウイグ）、すなわちディスプレイで見た
ものが印刷して得られる（What You See Is What You Get）というものである。これで、文字、図形、画
像、数式といった、一般の冊子や書籍に登場するすべての情報がコンテンツとなったのである。さらに、
個々のコンテンツを、美しくレイアウトして、貼りこむことが可能なコンパウンドドキュメント技術も確立
された。[4]
しかしStarはビジネス的には成功しなかった。ハードウエアが高すぎることと、ソフトウエアがハードウエ
アにバンドルされた製品だったからである。Starの市場に対して、2つの技術陣営が攻撃をしかけた。一つは
SunやApolloといったモトローラの68000系マイクロプロセッサを用いる汎用のUnix系のワークステーション
であり、他の一つは、やはり68000系CPUを用いるアップルのMacintoshによるPCによるものであった。[5]
Starが確立した高機能な文書処理環境は、ほぼそのまま、Unix環境やMacintosh環境で実現され、価格は一挙
に低下した。Unix上ではInterleaf、Framemakerといった高機能、高性能なDTPシステムが登場し、マニュア
ルや仕様書といった系統的な管理を必要とする大規模技術文書の作成・管理に適用された。Macintosh上の
DTPはPagemakerやQuarkXPressといった製品が登場し、一般の書籍やニューズレターなどに使用され始めた。
Unixのnroff、troffのようなマークアップ言語の世界は、WYSIWYG製品に押されて世の中の注目を浴びること
はなかったが、系統的に大量文書を作成・管理する印刷出版業界などには、根強いニーズがあり、マークア
ップ言語の相互運用と標準化を指向するSGML（Standard Generalized Markup Language）となってISOにより
標準化された。
第5期（1990s~）
InterleafやFramemakerなどが企業の文書管理に適用され、NFSなどのUnix系のネットワーク管理ツールと融
合したワークフロー管理ツールと一体化されて、航空機、自動車、保険、製薬、医療などといったさまざま
な業界で使用されはじめた。これらの業界は、文書管理が法律で義務付けられていることに特徴があり、文
書の作成、編集、承認といった作成フェーズのワークフロー管理だけでなく、文書の検索、管理、保存、廃
-6-
棄などの保管フェーズのワークフロー管理、さらに文書の暗号化、アクセス権やアクセス履歴といった機密
管理機能も要求されるものであった。
これらの系統的な文書管理を行うための枠組み（アーキテクチャ）が個別のメーカーで検討されたが、それ
には無理があった。Interleaf社は、Interleaf LispというLisp言語を用いて、作成・編集時の個別文書のコ
ンポーネント（コンテンツ）を管理し、文書全体の承認、保管、検索、保存、廃棄といったワークフロー管
理をRDBを用いて行うシステムを完成させ、一部の業界に導入され使用されたが高額のシステムであり、かつ
SGML関連ツールの完成度が不十分であったために普及はしなかった。
オブジェクト指向後術の標準化コンソーシアムであるOMG（Object Management Group）は、ワークフロー管
理をビジネスプロセスの標準化の一環として位置づけ、ビジネス領域の分散オブジェクト（CORBAビジネスオ
ブジェクト）の標準化を指向していた[6]。ユーザインタフェースと管理情報を複合文書として位置づけ、ア
ップルと協力してOpenDocを複合文書の標準規格として、関連業界に提案していった。しかしそのコンテンツ
の文書要素となるべきCORBAオブジェクトが整備されず、結局絵に描いた餅でしかなかった。すでに業界で使
われ始めていたSGMLとは、まったく別のアーキテクチャを構築しようとした点に関して本質的な無理があっ
た。
SGMLをベースとするネットワーク文書の枠組みとして、HTMLによるWebが急速に普及した。当初は簡単な文字
ベースのシステムに、画像をコンテンツとして挿入できるだけであったが、Javaによる動的なコンテンツの
可能性、VRMLによる3次元モデルの可能性などにより、映像や音声を包含するマルチメディアコンテンツのコ
ンテナとして注目を浴びるに至った。しかし、このような多様なコンテンツを統合して扱うためには、HTML
は機能不足であり、それを幅広いニーズに応える形式で拡張することは出来ない相談であった。そこで登場
したのがXMLであった。
XMLは当初はコンテンツというよりは、B2Bなどにおける企業内における情報流通のデータ形式として扱われ
た。そのために、Webのコンテンツは、HTMLをバージョンアップする形式で拡張されていった。他方、HTMLと
Eメールの世界を携帯電話に持ち込んだi-ModeサービスがNTTドコモから開始され、日本国内ではインターネ
ットの利用者を上回る勢いで普及した。i-Modeでは、HTMLの簡易版であるcHTMLが用いられたが、欧州を中心
とする携帯電話機業界は、WAP（Wireless Application Protocol）と呼ばれるコンソーシアムを立ち上げ、
WML（Wireless Markup Language）と呼ばれるXML準拠のコンテナの規格を作成した。
第6期（2000s~）
HTMLをXML化したXHTMLが標準化され、コンテナ自体がXMLになった。XHTMLは、家電業界におけるXHTML
Basic、携帯電話におけるWML2.0、デジタルTV放送におけるBMLなどに拡張され、今後の電子化コンテンツの
標準的なコンテナとなりつつある。今後コンテンツの世界は、Web（XHTML）をコンテナとするXML化されたコ
ンテンツに移行すると考えられる。SVG（図形）、MathML（数式）、SMIL（映像、アニメの枠組み）、XForms（帳票）などが、XMLコンテンツとして取り上げられつつある。
W3Cは2004年の10月に、コンパウンドドキュメントフォーマットWG（CDF-WG）を立ち上げて、複合文書の標準
化に着手した。当初の目標を携帯電話画面の標準化に絞り、XHTMLとSVGとの統合を第一ステップとしている
ようである。次の段階として、インタラクティブTVを対象とすし、コンピュータデスクトップに関しては、
もっとも高機能なスペックになるので最後に検討するとのことである。
3.2.3 複合文書
結局、将来型文書は、映像、音声、アニメといった動的なコンテンツを含め、クライアント環境上で複合文
書となり、Webという一元的なアーキテクチャの下で統合される動向にある。ADSLや光ケーブルの普及でイン
ターネットの広帯域化が進展し、かつて電話網として独立のネットワークを持っていた電話が、VOIP技術を
ベースにしたPI電話になり、ラジオ放送もインターネット経由で聴けるようになった。映像コンテンツも広
帯域ネットワークで配信されるようになると、デジタルTVと似たようなサービスが可能となる。このように
して、通信と放送が融合しつつある。
さらに3G携帯電話や無線LANの進展でモバイルサービスが進展しつつある。「いつでも、どこでも、誰とで
も」通信が可能になるユビキタスネット社会が進展している。個人を特定して提供されるユビキタスなサー
-7-
ビスに属性として個人情報がリンクされるのが、今後の将来型文書の特徴であろう。
以上の歴史において、第一期から第4期までのコンテナは紙媒体の紙面、冊子、書籍などであった。というこ
とは、紙という媒体をコンテナとするコンテンツビジネスの枠組みでマーケットが存在しており、コンピュ
ータやネットワークはその作成や版下に相当する原稿の管理に用いられていたことを意味する。
そのため、主要な文書の企画、制作、販売といったビジネスプロセス、サービスプロセスは、従来の印刷出
版業界がコントロールしていたと言っても過言ではない。この状況は、第5期においても基本的には持続され
た。
3.2.4 常に供給過剰となるデジタルコンテンツ
第6期になって、デジタルの電子化コンテンツがエンドユーザに流通し始めた段階で、種々の問題が提起され
た。基本的な問題は、
(1) 完璧な複製が誰にでも容易に可能
(2) 著作権、複製権のような知的財産権の扱いにシステムが必要
の２つであり、両者は相互に関係している。複製を自由に認めると、デジタルコンテンツは常に供給過剰に
なり、需要と供給のバランスにより価格が定まるという古典的な経済理論から外れるビジネス市場となる。
印刷出版業界がまかりなりにも需要と供給のバランスによって価格が決まる機構を維持しているのに比べる
と、大きな相違である。
結局、従来の印刷出版業的なパラダイムで「完璧な複製が誰にでも容易に可能」なコンテンツビジネスを行
うことは本質的な無理がある。そこで、「著作権、複製権のような知的財産権の扱いにシステムが必要」と
いうことで、デジタルコンテンツの複製を制約することにより、需要と供給のバランスをとるようにするこ
とが常識的に考えられるであろう。しかしその場合は、そのメカニズムの導入に膨大なコストがかかる。
そのメカニズムは、コンテンツ情報のフォーマットを特別な形式にし、閲覧ツールに特殊な工夫をして、読
み手を識別し、読み手が正当なライセンスを保有している場合にのみ閲覧を許可するというものである。こ
のような機構を導入すると、単なるコンテンツの複製、閲覧のみの場合に比べ、膨大なシステム的なバック
グラウンドを必要とせざるを得ない。特に利用者の閲覧権を認証するような仕組みは、データベースの導入
を要求され、そのシステム構築、維持管理に莫大なコストを要求される。それが利用者の閲覧費用に加算さ
れることになる。このような仕組みを個々のコンテンツ配信ビジネスの提供者が用意することなど、現状で
は困難な課題である。たとえそれが実現できても、本来であればはるかに安い価格で受けることが可能な閲
覧サービスに対し、膨大な知的財産権の管理コストを利用者に払わせるのは、本末転倒的な趣がある。そう
かと言って、コンテンツを基本的にフリーにしてしまうという思想にも無理がある。
3.2.5 コンテンツビジネスの可能性
最近、コンテンツビジネスで、うまく回っているのは、着メロなどに代表される携帯電話向けのビジネスで
ある。この場合は、コンテンツの使用料を定額制にし、通信料金に上乗せして代行回収してもらうという手
段が取られている。すなわち、携帯電話の利用者番号を効果的な認証手段に使い、代金の徴収を携帯電話サ
ービス会社が代行する。要するに携帯電話サービス会社は、利用者認証のビジネスを行うことが可能になる
のである。要するにコンテンツビジネスの基本的な管理は、携帯電話サービス会社が個人認証DBサービスと
して行うのである。
以上から、今後の将来型文書によるコンテンツビジネス・サービスは、個人認証がキーとなる。逆の発想を
すると、個人情報をうまく活用することによりコンテンツ提供者は、利用者や利用者のグループに対して、
きめ細かい効果的なサービスが可能になる。また、コンテナがXHTML化し、コンテンツがXML化する複合文書
化の傾向が利用者デバイスの統一的な枠組みとなりつつある。従来のWebブラウザがHTML文書を閲覧するだけ
だったのに対し、今日のクライアント端末は、XML処理系を内蔵する、リッチクライアントになりつつあると
言える。
-8-
3.2.6 将来型文書が具備すべき条件
以上から、将来型文書が具備すべき条件としては、下記が想定される。
(1) 将来型文書は、将来型複合ドキュメントである。
(2) 将来型複合ドキュメントは、基本的にはXHTMLをコンテナとし、XMLをコンテンツとする枠組みであ
る。
(3) XMLコンテンツは、XML関連規格のすべてが含まれ得るもので、当面はSVGやSMIL、X Formなどが対象に
なっているが将来的にはセマンティックWebのOWLやWebサービスのSOAなども対象になると考えられる。
(4) 将来型文書は、将来のコンテンツビジネスのための枠組みも具備すべきと考えられ、そのためのメタ
データも必須である。
(5) メタデータとしては、ダブリン・コアがデファクトと考えられるが、コンテンツビジネスのために
は、知的所有権やアクセス権に関連するメタデータが必須である。
(6) 上記メタデータとしては、オントロジを活用する枠組みが期待される。
参照情報
[1] http://www.w3.org/2004/CDF/admin/charter
[2] H. Rheingold; "Tools for Thought", Prentice Hall Press (1986)
[3] A. Goldberg; "A History of Personal Workstation", Addison Wesley (1988)
[4] 大野邦夫；"情報の入出力方法と操作性", 信学誌 Vol.87, No.4, pp.362-367, (1984)
[5] http://web.kyoto-inet.or.jp/people/s-oga/mac/
[6] 大野邦夫，佐藤広行；"オブジェクト・マネージメント・グループとその活動", 情報処理 Vol.35,
No.9, pp.845-852, (1994)
-9-
4.1 WG1 活動内容
4.1.1 活動日程
AIDOS/WG1委員会の開催一覧を下表に示す。
AIDOS/WG1委員会開催一覧
番号開催日
開催時間
開催場所
主な議題
1(29) 2004-06-10 14:00～17:00 日本規格協会第802会議室平成16年度活動計画の確認
2(30) 2004-07-22 14:00～17:00 日本規格協会第801会議室 OWL翻訳・訳語検討
3(31) 2004-08-26 14:00～17:00 日本規格協会第201会議室 OWL翻訳・訳語検討
4(32) 2004-09-21 13:30～16:00 日本規格協会第203会議室 OWL素訳レビュー
5(33) 2004-10-21 14:00～17:00 日本規格協会第201会議室 OWL素訳レビュー
6(34) 2004-11-10 14:00～17:00 日本規格協会第201会議室 XML化情報検索プロトコル検討
7(35) 2004-12-08 14:00～17:00 日本規格協会第203会議室 OWL素訳クロスレビュー
8(36) 2004-12-27 14:00～17:00 日本規格協会第801会議室 XML化情報検索プロトコル検討
9(37) 2005-01-11 13:00～16:00 日本規格協会第202会議室 OWL原案レビュー
10(38) 2005-02-17 14:00～16:00 星陵会館第Ｃ会議室
報告書まとめ
4.1.2 ウェブオントロジ記述言語
(1) 訳語の取決め
W3Cが勧告として2004年2月に公表してOWL(Web Ontology Language)の次のパートを分担して作業することに
した。
z
z
z
z
Overview (概要)
Guide (手引き)
Reference (機能一覧)
Semantics and Abstract Syntax (意味論及び抽象構文)
パート毎の訳語の統一を図るため, 次の訳語一覧を作成して翻訳作業を推進した。
OWLの訳語一覧 ver.050111
(2) XMLでの原案記述による翻訳原案作成作業の効率化
翻訳原案レビュー作業の効率化のため, 素訳原稿を原文とalignmentをとってXMLで記述し, それを1カラムで
対訳形式で表示するためのXSLTスタイルシートと2カラムで対訳形式で表示するためのXSLTスタイルシートと
を作成した。
XMLファイル
z
Overview, Guide, Reference, Semantics and Abstract Syntax
XSLTスタイルシート
z
1カラム表示用
-10-
z
2カラム表示用
Semantics and Abstract SyntaxのW3Cオリジナルテキストについては, 1ファイルにまとまった版
http://www.w3.org/TR/owl-semantics/semantics-all.html
と, 複数ファイルに分割されて版
http://www.w3.org/TR/owl-semantics/
とがある。後者は, 1. Introの次にApendix Cが来るという構成をとるため, TSへの整合性が悪いと判断し
て, ここでは前者を採用した。
(3) TS化
TS化に際しては国内規格の様式に近づけるとともに, なるべく原勧告の体裁を保存(特に章・節等の番号の保
存)することに配慮し, これまでのW3C勧告のTR化と同様に, 次の構成上の変更を行った。
z
z
z
z
z
まえがきと解説を追加し, まえがき, 目次, 解説を別ファイルとする。
序文を追加する。
Abstractを0. 適用範囲とする。
本文中の規定でない章を, 附属書n(参考)とする。
原勧告の節番号n.m.またはn.m.k.をそれぞれ項番号n.mまたはn.m.kとする。ここでn, m, kは整数。
またW3Cからの要求に基づき, TSの様式は, なるべく原勧告の論理構造を保存したHTMLとし, TS原案としての
提出に際しては, それをPDFに変換したファイルを用いた。
(4) TS化に関するW3Cとの合意
W3Cの勧告のTS化に際しては, 次のようなEmail交換によってW3Cの合意を得ている。
***************************************************************************************
送信者: Herman
宛先: komachi
件名 : Re: Translation plan for JIS/TRs
日時 : 2004年12月13日 18:37
Mr Komachi,
I understand. Indeed, Mr Duerst made me realize that ISO and therefore JIS have very
special requirements for the terms used.
Please, notify us when the translation is ready, so that we could add it to our database.
Sincerely
Herman
***************************************************************************************
送信者: komachi
宛先: Herman
件名 : Re4: Translation plan for JIS/TRs
日時 : 2004年12月13日 23:59
Dear Mr. Herman
>Please, notify us when the translation is ready, so that we could add it to
>our database.
The committee in INSTAC/JSA will accomplish the JIS/TS drafts of
OWL Web Ontology Language
- Guide
- Overview
- Reference
- Semantics and Abstract Syntax
-11-
and submitted them to METI (Ministry of Economical Trade and Industry,
Japan) by the end of Feb. 2005.
Just before the submission, I will post them for public review on the Web
of drafting committee:
http://www.y-adagio.com/public/standards/std_lst.htm
The formal approval of the drafts and JIS/TS publication will be delayed
(similarly to other activities of government) and take place approximately
by July 2005.
Best Regards,
-----------------------------------------------------------------Yushi Komachi
***************************************************************************************
4.1.3 XML化情報検索プロトコル
(1) 昨年度原案に対するupdate
昨年度のLibrary of Congressとの議論により, SRWのver.1.1の拡張機能を利用することにして, そのための
原案改訂を行った。改訂の方針を次に示す。一部, ver. 1.0 との差の形式で示す。
a) 基本方針
1)
クライアント側から画像又はそれを指定するURIを指定し, サーバ側はそれを使って,
その画像を含む文献のリストをクライアント側に返す。
2)
サーバ側の画像検索の方式などは, この仕様の適用範囲外とし, サーバ側依存
又はクライアント側とサーバ側との間で事前の合意があるものとする。
3)
CQLに画像検索のきっかけになる項目を追加する。
画像それ自体はCQLには含めず, URI指定又は次の4)へのリンクだけを指定する。
=====>
CQLへの拡張は行わない。
その代わりに, ver.1.1で導入されたextraRequestDataに, 画像又はそれを指定するURIを与える。
あくまでも, CQLの検索の追加情報として画像を与えることにし, CQLで絞り込んだ検索結果を,
更に画像で絞り込む, というイメージ。
4)
searchRetrieveRequest ParametersにimageQueryを追加する。
実際の画像を運べるようにする。
ただし, CQLでの指定がない場合には, この項目は無視する。
=====>
ver.1.1で導入されたextraRequestDataに, 画像又はそれを指定するURIを与える。
b) CQL拡張
=====>
行わない。
c) searchRetrieveRequestのextraRequestDataの使用
searchRetrieveRequestのextraRequestDataに検索用の画像データ情報を与える方式を取り入れる。
あくまでも, CQLの検索の追加情報として画像を与えることにし, CQLで絞り込んだ検索結果を。
更に画像で絞り込む, というイメージ。
SRWの仕様上, CQLは必須なので, CQLに画像検索のきっかけを直接に入れない限り,
このような仕様になるのが自然, と考える。
(入れる場合は, SRW ver.1.0 の場合と同様の拡張になるか。)
extraRequestDataの使用法を規定したttp://www.loc.gov/z3950/agency/zing/srw/extra-data.htmlに従う。
適当な名前空間内で, 画像用の問合せを定義する。
-12-
名前空間を何にするかは, 要検討。
例えば,
http://ww.jsa.org/instac/aidos/srw/extension/image-query-v1.0
又はSRWの準標準？に従うならば,
info:srw/extension/n/image-query-v1.0
ここで, n は, この画像検索の仕様を管理する権威機関を示す番号。空き番号は, 現在, 5以上。
(後述のe)の例では, 便宜上, 後者を10として使用。しかし, これは, ZINGに登録が必要そう。)
実際の画像を与えるXMLスキーマは, 次のとおり。
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="imageList">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element ref="imageData"/>
<xsd:element ref="imageURI"/>
<xsd:element ref="imageList"/>
</xsd:choice>
<xsd:sequence minOccurs="0">
<xsd:choice>
<xsd:element name="and"/>
<xsd:element name="or"/>
</xsd:choice>
<xsd:choice>
<xsd:element ref="imageData"/>
<xsd:element ref="imageURI"/>
<xsd:element ref="imageList"/>
</xsd:choice>
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="imageData" type="xsd:base64Binary">
<xsd:attribute name="mimeType" type="xsd:string"/>
</xsd:element>
<xsd:element name="imageURI" type="xsd:anyURI">
<xsd:attribute name="mimeType" type="xsd:string"/>
</xsd:element>
</xsd:schema>
imageListには, 1個以上の画像をbase64Binaryで指定するか, 又は画像を与えるURIを指定する。
imageListは, 画像又はURIを<and/>又は<or/>でつなぐことができ,
<and/>の場合は, <and/>の前後の画像を共通にもつものを探し,
<or/> の場合は, <or/> の前後の画像のどちらかをもつものを探す。
(上記の定義では, 冗長な記述, かなり難しい場合の記述も可能になる。もっと簡単にして,
一般的な記述はやめた方がよさそう。)
imageData及びimageURIには, mimeTypeという属性があり, 画像のMIME型を指定する。
d) 処理方法
具体的な検索方法などは, 原則, サーバ側に任せる。
ただし, 今後, 何らかの検索方式, 精度などを指定できるようにするかどうかは, 要検討。
e) 例
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
-13-
<srw:searchRetrieveRequest xmlns:SRW="http://www.loc.gov/zing/srw/">
<SRW:version>1.1</SRW:version>
<SRW:query>(dc.title any "cat speak")</SRW:query>
<SRW:startRecord>1</SRW:startRecord>
<SRW:maximumRecords>10</SRW:maximumRecords>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordsSchema>
<SRW:extraRequestData>
<imageQuery:imageList xmlns:imageQuery="info:srw/extension/10/image-query-v1.0"/>
<imageQuery:imageData mimeType="image/jpeg">
..... (JPEG data of Tama's picture 1 in base64Binary) .....
</imageQuery:imageData>
<and/>
<imageQuery:imageData mimeType="image/jpeg">
..... (JPEG data of Tama's picture 2 in base64Binary) .....
</imageQuery:imageData>
</imageQuery:imageList>
</SRW:extraRequestData>
</SRW:searchRetreiveRequest>
</SOAP:Body>
</SOAP:Envelope>
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<SRW:searchRetrieveResponse xmlns:SRW="http://www.loc.gov/zing/srw/">
<SRW:numberOfRecords>2</SRW:numberOfRecords>
<SRW:resultSetId>8c527d60-c3b4-4cec-a1de-1ff80a5932df</SRW:resultSetId>
<SRW:resultSetIdleTime>600</SRW:resultSetIdleTime>
<SRW:records>
<SRW:record>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordSchema>
<SRW:recordData>
<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns:xlink="http://www.w3.org/TR/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.loc.gov/mods/"
xsi:schemaLocation="http://www.loc.gov/standards/mods/mods.xsd">
<titleInfo>
<title>How to Speak with Your Cats: Their Misterious Worlds !</title>
</titleInfo>
<name type="personal">
<namePart>Kitty, Furry.</namePart>
<role>creator</role>
</name>
...
</SRW:recordData>
<SRW:recordPosition>1</srw:recordPosition>
</SRW:record>
<SRW:record>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordSchema>
<SRW:recordPacking>string</SRW:recordPacking>
<SRW:recordData>
<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns:xlink="http://www.w3.org/TR/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.loc.gov/mods/"
xsi:schemaLocation="http://www.loc.gov/standards/mods/mods.xsd">
<titleInfo>
<title>Japanese Bobtail Speaks! : A Story of A Japanese Cat</title>
</titleInfo>
<name type="personal">
<namePart>Tamako, Nekomata.</namePart>
<role>creator</role>
</name>
...
</SRW:recordData>
<SRW:recordPosition>2</SRW:recordPosition>
</SRW:record>
-14-
</SRW:records>
</SRW:searchRetrieveResponse>
</SOAP:Body>
</SOAP:Envelope>
f) SRUの指定方法
SRWの標準のパラメタの後に, c)で規定した順番に, 各要素ごとに"x-" という接頭辞を与えて,
&で区切り, key=value形式の標準のSRU記述方式で記述する。
ただし, リストは値が構造をもつので, 二重引用符(")で囲み,
その中は, 上記の記法を入れ子にして記述する。
(SRUとして, これは可能か）
なお, 実際の画像データを与えることはできない。URI方式だけを記述できる。
また, MIME型も与えない。
例えばe)の例のURI版を記述すると, 次のとおりになる。
(見やすいように改行を入れたが, 実際には改行はなし。)
http://myserver.com/myurl/?operation=searchRetrieve&version=1.1&query=dc.title%20any%20%22cat%20speak%22
&startRecord=1&maximumRecords=10&recordSchema=info-1-mods-v3.0
&x-info-10-imageList=
%22x-info-10-imageData=http://myserver.com/imageData/TamaPicture-1.jpg
&x-info-10-and
&x-info-10-imageData=http://myserver.com/imageData/TamaPicture-2.jpg%22
(2) Library of Congressとの相談
前述(1)の検討内容をLibrary of Congressに相談した結果, 次のような回答を得ている。
***************************************************************************************
送信者: Denenberg, Library of Congress
宛先: komachi
件名 : Re: Contribution on ZING Extension
日時 : 2004年12月15日 6:02
Dear Mr. Yushi Komachi:
Thank you, on behalf of the SRW implementor community, we are pleased that
the SRW 1.1 spec. will support your application.
I have added you to the list of organizations assigned an authority string
for construction of srw info URIs. See
http://www.loc.gov/z3950/agency/zing/srw/infoURI.html (let me know if I
listed the organization and contact correctly).
Please also send information for the implementors list at http://www.loc.gov/z3950/agency/zing/srw/implementors.html
Regarding http://srw.cheshire3.org/SRW-1.1.pdf, the consolidated spec, if
you simply want to reference that file you don't need permission. If you want
to copy it, please contact Rob Sanderson (he maintains it), azaroth at LIVERPOOL.AC.UK,
and I'm sure he will give you permission.
I have also subscribed you to the zng listserv. I think it would be worthwhile
to discuss your application on the list. In particular there may be a way to
simplify your schema so that it doesn't need to include boolean 'and's and 'or's
since cql provides this functionality. And that would be a cleaner approach particularly
if your queries become more complex than in your example, the semantics of the
booleans within an extension rather than in the query will not be as clear.
Thus perhaps instead (using your example) you could include the cat pictures within
a schema that defines an arbitrary number of pictures each with a label (referenced
from the query) but without connectors, and define a picture index.
So rather than
(dc.title any "cat speak")
along with a complex schema,
-15-
you might have something like:
(dc.title any "cat speak") and (picture.lable = "lable1" or picture.label = "label2")
where label1 and label2 are included as attributes on the images in the xml extension
file.
However this suggestion isn't completely thought out and I think you will benefit
from discussion and advice from the implementors, to help decide the best way to
formulate this.
So it would be good to post your idea to the list.
I look forward to working further with you.
Denenberg
***************************************************************************************
送信者: L-Soft list server at Library of Congress (1.8e)
宛先: Komachi
Cc: Denenberg
件名 : You have been added to the ZNG list
日時 : 2004年12月16日 23:37
Thu, 16 Dec 2004 09:37:04
You have been added to the
Initiative) by Denenberg.
ZNG mailing list (Z39.50
Next-Generation
***************************************************************************************
(3) TS化
前述(1)の検討内容をこのLibrary of Congressの回答に従って修正し, TS原案を作成した。
4.1.4 日本語検索機能記述のための指針
昨年度の"図書検索利用者への指針"を見直し, 日本語検索機能記述にスコープを限定して, TR原案としてま
とめた。
-16-
4.2 WG2 活動内容
4.2.1 活動日程
AIDOS/WG2委員会の開催一覧を下表に示す。
AIDOS/WG2委員会開催一覧
番号開催日
開催時間
開催場所
主な議題
1(28) 2004-06-10 14:00～17:00 日本規格協会第802会議室平成16年度計画の確認
2(29) 2004-07-27 14:00～17:00 日本規格協会第801会議室オントロジ技術の状況
3(30) 2004-08-24 14:00～17:00 日本規格協会第802会議室 OWLガイドの検討
4(31) 2004-09-28 14:00～17:00 日本規格協会第801会議室オントロジ応用の検討
5(32) 2004-10-18 14:00～17:00 日本規格協会第801会議室モバイルCRMの紹介
6(33) 2004-12-02 14:00～17:00 日本規格協会第201会議室 Xfyの紹介
7(34) 2004-12-28 14:00～17:00 日本規格協会第801会議室報告書原稿レビュー
8(35) 2005-02-09 14:00～17:00 日本規格協会第203会議室報告書まとめ
4.2.2 将来型文書の条件
将来型文書が具備すべき条件として下記の項目を挙げた。
(1) 将来型文書は、将来型複合ドキュメントである。
(2) 将来型複合ドキュメントは、基本的にはXHTMLをコンテナとし、XMLをコンテンツとする枠組みであ
る。
(3) XMLコンテンツは、XML関連規格のすべてが含まれ得るもので、当面はSVGやSMIL、X Formなどが対象に
なっているが将来的にはセマンティックWebのOWLやWebサービスのSOAなども対象になると考えられる。
(4) 将来型文書は、将来のコンテンツビジネスのための枠組みも具備すべきと考えられ、そのためのメタ
データも必須である。
(5) メタデータとしては、ダブリン・コアがデファクトと考えられるが、コンテンツビジネスのために
は、知的所有権やアクセス権に関連するメタデータが必須である。
(6) 上記メタデータとしては、オントロジを活用する枠組みが期待される。
WG2では、上記(3)～(6)に関する項目を検討する。特に(3)、(6)のセマンティックWebおよびオントロジに関
連する項目を中心に調査研究を行っている。今年度は前年度に引き続き、W3CにおけるセマンティックWeb向
けのオントロジ記述言語OWL関連、IEC-TC100におけるAV機器へのオントロジ適用について検討した。さらに
TC100への提案として、TV視聴プリファレンス、ネットワーク管理、迷惑メール管理などへのオントロジ適用
の可能性を検討する。
-17-
4.3 将来型文書統合システム調査研究委員会(AIDOS)審議
委員会開催
将来型文書統合システム調査研究委員会(AIDOS)の開催一覧を次の表に示す。
将来型文書統合システム調査研究委員会(AIDOS) 開催一覧
番号開催日
開催時間
開催場所
主な議題
1
2004-06-01 13:30～15:30 日本規格協会第802会議室平成16年度の活動計画の承認
2
3
2004-09-30 14:00～16:00 日本規格協会第201会議室平成16年度上期作業の承認
2005-02-10 14:00～16:00 日本規格協会第203会議室平成16年度の活動実績の承認
-18-
5.1 WG1 成果
5.1.1 ウェブオントロジ記述言語
W3Cの勧告OWL(Web Ontology Language)の次のパート
z
z
z
z
Overview (概要)
Guide (手引き)
Reference (機能一覧)
Semantics and Abstract Syntax (意味論及び抽象構文)
に対応する4件のTS原案を作成した。それぞれを附属資料のA.1, A.2, A.3, A.4に示す。
TS作成に際して, 明らかに誤りと判断される原勧告の記述については, 訂正してTSに反映すると共に, 次の
Error reportをW3Cに通知した(2004年12月)。
1. The items 2.2, 4.1 and 6.2 of TOC just before "1. Introduction" should be
identical to the corresponding headings in the main body:
clause TOC
Main body
----------------------------------------------------------------------2.2
OWL URI vocabulary and namespace
OWL built-in vocabulary
4.1
RDF Schema property constructs
RDF Schema constructs
6.2
Enumerated datatype using owl:oneOf Enumerated datatype
2. The "c.q." in 3.1.2, para6 and 4.1.3, para2 should be replaced with usual
English "or".
3.1.2, para6
The restriction class should also have exactly one triple that represents
the value constraint c.q. cardinality constraint on the property under
consideration, e.g., that the cardinality of the property is exactly 1.
4.1.3, para2
Multiple range restrictions are interpreted as stating that the range of the
property is the intersection of all ranges (i.e., the intersection of the
class extension of the class descriptions c.q. the intersection of the data
ranges).
5.1.2 XML化情報検索プロトコル
Library of Congressとの議論を反映したXML化情報検索プロトコルの英語版に基づき, TS原案を作成した。
そのTS原案を附属資料のA.5に示す。
5.1.3 日本語検索機能記述のための指針
図書検索利用者を対象とする, 日本語検索機能記述の指針をTRの様式でまとめた。そのTR原案を附属資料の
A.6に示す。
-19-
5.2 WG2 成果
5.2.1 OWLの現状
ウェブオントロジ言語OWLの勧告が2004年2月にW3Cから出されてから1年が経過した。ここでは、具体的にど
のようなオントロジが検討されているかを紹介する。OWLを用いたものもあれば、そうでないものもある。非
常に小規模なものから、比較的大規模なものまで、既に様々なオントロジが作成されていることがわかる。
作成の動機や利用目的も様々であることが見て取れる。 OWLオントロジについては、すでに他の枠組みで作
成されていたものをOWLで記述したというものが散見される。 OWLという言語は、人工知能の文脈でとらえる
と、単にDescription Logicを採用した言語の一つに過ぎず、特に目新しい点は見いだせない、という見方も
ある。確かに、現在作成されているOWLオントロジの中には実験的なものもあれば、特定目的での実用性を指
向したものもあり、このうち、どれだけのものが今後発展していくかは不明であり、中には作りっ放しのも
のもあるだろう。しかしながら、OWLは汎用のオントロジ記述言語ではなく、あくまでもウェブオントロジを
指向したものであるため、ウェブの特性を生かした、真に有用なオントロジがメンテナンスされ、利用され
ていくというストーリもあり得ないわけではない。詳細は付属資料を参照して欲しい。
5.2.2 IEC/TC100への提案
IEC(国際電気標準会議)には, 情報家電を含むマルチメディア関連技術の標準化を担当する技術委員会として
TC100が設けられ, 1995年からその分野の国際規格の開発を行っている。IECには, その将来活動の指針を検
討する委員会としてPresident's Advisory Committee on Future Technology (PACT)があり, 2000年10月
に"Final report of the project on Human interfaces in Multimedia network Era"という報告書(PACT
report)を提出した。PACT reportは, IEC中央事務局経由でTC100に届けられ, TC100がこの報告書への対応を
求められた。このPACT reportは, IECが扱うマルチメディア機器のヒューマンインタフェースの基本概念を
示すものであり, その中にオントロジ技術の必要性が示されている。PACT reportへの対処として, TC100
は"Response to the PACT Report"をまとめ, それに従ってマルチメディア技術の標準化活動を推進してい
る。ここでは, オントロジ技術の情報家電への応用としてこのPACT reportの関連部分を紹介し, IEC/TC100
における"Response to the PACT Report"に従った活動の概要を示す。詳細は付属資料を参照して欲しい。
5.2.3 TV視聴者の嗜好に基づく番組推薦へのオンロトジー応用の可能性
テレビジョン番組は、ハードディスクレコーダーの登場によって従来の放送局が編成した番組を時系列に鑑
賞するのではなく、ユーザ（TV視聴者）の好みだけを選別して自由な時間に見るものに変わりつつある。こ
のことは、ビデオデッキによってすでに技術的には可能ではあったが、全ての番組を予約録画することは現
実的でなく、ビデオテープの録画時間が最長でも9時間（VHS/EPモード）であったことから機械が適当に選択
した番組を録画するだけの容量を無人で持ち得なかったという理由による。しかしながらハードディスクレ
コーダーは200時間を超え、ランダムアクセスができることから大雑把なユーザの嗜好から機械が自動的に番
組を録画していき、後でユーザが選別して番組を視聴するという形態が実現可能となった。そこで、ユーザ
の嗜好にあわせた番組推薦（リコメンデーション）が想定されるが、その際にどのような手法によってこれ
を行うかが課題となっている。ここでは、オントロジーを用いたアプローチの可能性について考察する。
5.2.4 ネットワーク管理へのオントロジ適用
ネットワークハードウェアの小型化により、ネットワークに接続可能な電子機器が次々と登場してきてい
る。新しい機器の接続だけでなく、2004年はIP電話にも注目が集まり、一部の既存の通信網のIPへの置き換
えも行われている。ネットワークに接続可能なDVDなどの家電製品も実用化され、外出先からネットワーク経
由で録画予約が可能になるなど、電子機器の新しい使用法も模索されている。ネットワークと電子機器の進
歩によって便利になる一方で、様々な性質と機能を持つ機器の管理は複雑さを増している。セキュリティや
個人情報保護など企業情報の扱いも考慮しなければならない。対策は多角的に行われなければならず、様々
な知識や技術、ソフトウェア、ハードウェアが必要となり、管理コストが増大している。家庭内の機器にお
いても、ネットワークと機器の設定は複雑になる一方で、必要な機能を使うにはかなり高度な知識が要求さ
れる。これらの状況に対応するには、機器設定および管理の抽象化と自動化が必要である。現在は機器の統
-20-
合的な管理モデルは存在しない。要求されるモデルは、各種機器の細かい差異を吸収した形での管理と、最
適な設定を行うための判断が必要であることから、オントロジの適用が有効と考えられる。ここでは、ネッ
トワーク管理のオントロジ適用の可能性を探るため、現状行われているネットワーク管理の標準化について
まとめ、オントロジの応用を模索する。
5.2.5 ベイズ理論の迷惑メール対策への応用
迷惑メールはいまや社会問題になりつつあり、各事業者は協力して対策にあたっている。迷惑メール対策に
は現在、大きく分けて2つの方法があり、1つは、事業者間でのメールの転送時に認証などにより対策する方
法、もう1つはユーザへの配信時あるいはユーザが自分でフィルタを設定して対策する方法である。後者のフ
ィルタによる対策にはベイズ理論が応用されたものがあり、ある程度の成果を上げている。ここでは、ベイ
ジアンフィルタと呼ばれるベイズ理論の応用による迷惑メールフィルタについて簡単にまとめる。ベイズ理
論は、過去に起きた事象の確率を利用して未来を予測する手法である。迷惑メールにはいろいろな種類があ
るとはいえ、大まかに、広告宣伝を目的とするものと、ウィルスに感染したメールが大多数を占めるだろ
う。つまり迷惑メールには同じような用語が含まれていることが多く、その確率を解析することにより送ら
れてきたメールが、迷惑メールであるかどうかを類推できるのである。ここでは、迷惑メール対策への統計
的手法の応用の概略を述べる。
5.2.6 環境整備
将来型文書をXHTMLをコンテナとする将来型複合文書と考えるとその環境はWebである。Webをビジネス的に使
用する場合は、データベースに支援されたWebサービスが基本的な枠組みとなり、業務分析とそれに基づくワ
ークフローによるイントラネット環境が必要である。企業組織における将来型文書は、そのようなシステム
構成における、XHTMLをコンテナとし、イントラネットで処理・配信されるXMLをコンテンツとするWeb文書で
ある。一方、将来型文書の今後のプライベートな環境としては、ブログやソーシャル・ネットワーク・サイ
トが挙げられる。RSSはそれらのサイトのための有効な枠組みであり、その最新動向について解説する。
(1) 企業組織における将来型文書
ある目的の達成に向けて活動する集合体が組織であり，組織は目的を達成するために活動する成員から構成
される．個々の成員の持つ知識や知恵はドキュメントという目に見える形にして初めて，他者に伝達できる
情報になる．つまり，ドキュメントは組織における意思決定過程のコミュニケーションツールとして位置づ
けることができる．たとえば，企画会議においては用意された企画提案書に基づいて議論が繰り広げられ，
会議の内容を議事録にするとともに決定事項を企画書にし，関連部署の合意を経て企画が実行される．ドキ
ュメントは組織の意思決定過程プロセスにおいて，情報を記録し，伝達するための手段と位置づけられる．
このような性質をもつドキュメントをここではビジネスドキュメントと定義する．ビジネスドキュメントに
は一般的に作成，レビュー，審査，承認，配布，保管，廃棄というようなライフサイクルがある．さらに，
このライフサイクルに関連した業務プロセスが存在する．業務を円滑に推進するには，業務プロセスを自動
化し，速やかに，正確に情報（ビジネスドキュメント）を流通させ，必要に応じて情報を参照できる仕組み
が必要である．これを実現する1つの手段がワークフロー管理である．近代的な組織は，ビジネスドキュメン
トによる記録と伝達，すなわちワークフローで組織内に周知させることにより効果的に運営される. ここで
は，ビジネスドキュメントに対するワークフローの現状の役割と今後期待される適用可能性について考察す
る．ビジネスドキュメントを本業との適性とビジネスプロセスの多様性という２つの要因で分析し，ワーク
フローの適用性と課題を明らかにする．
(2) RSSの現状と将来
RSSは、RDFから派生した記述言語として、近年非常な勢いで広まっている。ニュースサイトやブログと呼ば
れる個人の日記サイトでも利用されている。RSSは、Web上のコンテンツを要約した内容をXML形式で表現した
ものであり、主にXML/RPC形式で送受信され、RSSを読むことができるソフトなどで表示することができる。
これによって、さまざまなWeb上の情報を集約することができ、効率的な情報収集手段として期待されてい
る。RSSの利用の仕方に決まりはなく、Web上でのサービスでのさまざまな試みが実践されており、今後もWeb
上でのさまざまなサービスの中で利用されることが予想される。ここでは、RSSの生い立ち、RSSのバージョ
ンによる仕様の違いや問題点、RSSを利用したサービスについて考察する。
-21-
6.1 WG1 今後の課題
6.1.1 ウェブオントロジ記述言語
TS原案作成作業の結果明らかになった原勧告の問題点をまとめて, W3Cに報告すると共に, 機能拡張などを
W3Cに提案することが望まれる。
6.1.2 XML化情報検索プロトコル
今年度に作成したTS原案に基づき, SRW, CQLの拡張に関する実装を行って, その拡張機能の有効性を確認す
ることが望まれる。
6.1.3 日本語検索機能記述のための指針
"日本語検索機能記述のための指針"を実際の図書検索システムの手引きなどに適用して, 利用者からのフィ
ードバックに基づく指針の充実を図るべきであろう。
-22-
6.2 WG2 今後の課題
以上、将来型文書について具備すべき条件、調査研究内容、環境整備について述べた。将来型文書は、将来
型複合文書であり、それはXHTMLをコンテナとし、XMLをコンテンツとすると想定した。これはW3CのCompound
Document Format Working Group （略称、CDF-WG）が進めている規格そのものである。
現状（2005年2月）の時点でW3CのCDF-WGが検討している規格は、XHTMLにSGVとSMILを融合させたもので、対
象は携帯電話画面である。技術的に単純な携帯電話からはじめて、次にインタラクティブTV、その次にデス
クトップというステップを考えているようである。昨年の10月に発足したばかりのCDF-WGが、最初に携帯画
面から手を付けたということは意外であった。かつて検討されたAppleのOpenDOCのように、複合文書という
ものはコンピュータのデスクトップを基本とするもので、そのヒューマンインタフェースに拡張されるもの
であると考えていたからである。デスクトップで確立された技術が標準となって、家電製品や携帯電話に拡
張されると考えたからである。技術指向の観点に立つとそれは常識的なアプローチである。
そのような観点で、今後のコア技術を、セマンティックWeb、オントロジに置き、その観点から適用可能分野
を、個人情報管理、TV視聴プリファレンス、ネットワーク機器設定などに対象を絞り、下記の可能性を検討
した。
(1) OWLに関しては昨年度正式勧告化され、実用に供される可能性が見えてきた
(2) 個人情報管理に関しては、昨年度にXMLベースの基本モデル（アドレス帳、スケジュール帳、地図情報
を連携させるXML表現事例）を提示し、ロケーションベースのビジネスに使用する可能性を検討した。他
方、富士通研究所とリコーによるOKARがメタデータとしてvCardとiCalendarを適用し、OWLの枠組みで適用
を検討している。
(3) TV視聴プリファレンスに関しては、個人情報管理と連携して、TVの番組案内、ショップチャンネルと
の連携によるビジネスの可能性を検討した。
(4) ネットワーク設定に関しては、最新動向の検討に基づき、XMLメタデータを用いてオントロジ活用を行
う可能性を調査した。その一環として、迷惑メールの分離に用いられているベイズ理論を、設定などにも
適用する可能性を検討している。
主な検討結果は以上のとおりであるが、十分に系統立った検討とは言いがたい。その理由として
(1) 基礎技術となるべきオントロジの理論が明確でないため、検討の方向を縛りきれなかった。
(2) 基礎的な記述言語であるOWLが、昨年度までの段階では必ずしも実用的でなく、システム構築に使えな
かった。
(3) 検討対象として選んだ分野も、昨年度は具体的に手を汚すようなプロトタイプ検討の余裕がなく、机
上検討しかできなかった。
といった点が挙げられるであろう。当WG2としては、具体的な規格を作るよりは先行的な技術を把握すること
に主眼があったので、以上のような結果でもやむを得なかったと考える。世界的なレベルでオントロジ適用
の検討は進んでいるが、実用に供せられている事例はほとんど皆無である。（5.2.1 OWLの現状）
今後の課題としては、上記検討モデル（個人情報管理、TV視聴プリファレンス、ネットワーク設定）のアー
キテクチャの検討、それに基づく実装、オントロジの有効性の確認などが考えられるが、そのような技術指
向のアプローチ自体の問題を考えねばならないと思われる。それに示唆を与えてくれたのは、W3CのCDF-WGの
活動である。CDF-WGは、当面は技術的に困難な課題を避け、むしろ技術的に容易なものから手をつけ、適用
できる分野に迅速に導入する手法を取っている。これは一つの見識であり、今後の標準化のあり方を示唆す
るものであろう。
他方、当WGが進めてきたような技術指向のアプローチは、一般に先進技術を調査研究するためには効果的で
あるが、オントロジ技術のような必ずしも明確な指標が欠ける場合には、具体的な取り組みを行わなければ
有効な成果を上げることができない。最近の日本企業は、IT分野における先端技術に取り組む余裕がなく、
また取り組んでいる場合は、標準化の委員会にその成果を提供するのが非常に困難になっている。以上のよ
うな状況なので、委員の個人的なスキルと、そのような個人をメンバーとして出してくれる企業の余裕に依
存せざるを得ないと言える。このような状況のもとで、なおかつ有効な成果を挙げるためのポリシーとプロ
セスを明確化することが最大の課題と言えるであろう。
-23-
[附属資料－A.1]
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 概要
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公
開後の実用新案登録願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録願にかかわる確認について，責任はもたない。
この標準仕様書(TS)には，次に示す附属書及び解説がある。
附属書A 文献
附属書B(参考) 貢献者
附属書C(参考) 変更記録
この版:
http://www.w3.org/TR/2004/REC-owl-features-20040210/
最新の版:
http://www.w3.org/TR/owl-features/
以前の版:
http://www.w3.org/TR/2003/PR-owl-features-20031215/
編集者:
Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University)
Frank van Harmelen (Vrije Universiteit, Amsterdam)
原規定については正誤表を参照されたい。規定の修正が含まれていることがある。
翻訳版も参照のこと。
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document
use and software licensing rules apply.
原規定の状態
原規定は，W3Cのメンバ及び他の利害関係者によってレビューされ， W3C 勧告として技術統括責任者によっ
て承認された。勧告作成において，W3Cは，原規定を広く知らせ，普及させる役割をもつ。これによって，
ウェブの機能性及び相互運用性が高まる。
これは，六部分から構成されるOWL，ウェブオントロジ言語のW3C勧告のうちの一つである。これは，2004年
2月10日発表のW3C セマンティクウェブ活動 (活動声明，グループ憲章)の一環として，ウェブオントロジ作
業グループによって作成された。
これらの文書の初期の版で表示されたOWLの設計は，広くレビューされ，作業グループの技術要件を満たして
いる。作業グループは，受理したすべてのコメントを検討し，必要に応じて変更している。原規定の勧告
-1-
案版からの変更の詳細については変更記録を参照されたい。
コメントはpublic-webont-comments@w3.org (アーカイブ) で受け付けている。関連技術についてはwww-rdflogic@w3.org (アーカイブ)で議論されている。
実装の一覧を入手することができる。
W3Cは，この作業に関わるすべての特許明細のリストを管理する。
ここでは，公開時における原規定の状態を記述する。他の規定が原規定に取って代わることもある。現在の
W3C刊行物のリスト及びこの技術報告書の最新改訂版については，http://www.w3c.org/TR/のW3C 技術報告書
索引を参照されたい。
-2-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 概要
目
次
まえがき
序文
0. 適用範囲
1. 導入
1.1 規定一覧
1.2 OWLの必要性
1.3 OWLの三種類の下位言語
1.4 この規定の構成
2. 言語概要
2.1 OWL Liteの概要
2.2 OWL DL及びOWL Fullの概要
3. OWL Liteの言語記述
3.1 OWL LiteにおけるRDFスキーマ機能
3.2 OWL Liteにおける同等性及び非同等性
3.3 OWL Liteにおける特性の特徴
3.4 OWL Liteにおける特性の制限
3.5 OWL Liteにおける制限されたメンバ数
3.6 OWL Liteにおけるクラスの積集合
3.7 OWLデータ型
3.8 OWL Liteにおけるヘッダ情報
3.9 OWL Liteにおける注記特性
3.10 OWL Liteにおける版管理
4. OWL DL及びOWL Fullに関する追加的な言語記述
5. まとめ
附属書A 文献
附属書B(参考) 貢献者
附属書C(参考) 変更記録
解説
-3-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 概要
OWL Web Ontology Language — Overview
序文
この標準仕様書(TS)は，2004年2月にWorld Wide Web Consortium (W3C)から公表されたWeb Ontology Language,
Overviewを翻訳し，技術的内容を変更することなく作成した標準仕様書(TS)である。
0. 適用範囲
OWLウェブオントロジ言語は，単に人に情報を提示するのではなく，情報の内容を処理する必要のあるアプリケーショ
ンが利用するために設計されている。 OWLは，形式的な意味論をもつ付加的な語彙を提供することによって，
XML，RDF，及びRDFスキーマ（RDF-S）がサポートするよりも，ウェブコンテンツの計算機による解釈能力を容易に
実現する。 OWLには，三つの段階的に表現力が増す下位言語[注釈]，すなわち，OWL Lite，OWL DL及びOWL
Fullが存在する。
原規定は， OWLの性能について第一印象を得たいと考える読者向けに書かれている。これは，OWLの各下位言語
の特徴を平易に記述することによって， OWLへの導入を行う。 RDF スキーマに関する知識があれば，この規定の理
解に役立つが、必須ではない。興味をもった読者は，この規定の後に， OWL 手引きを読めば， OWLの機能に関し
てより詳細な記述及び多くの例を得ることができる。 OWLの規定の形式定義については， OWL セマンティクス及び
抽象構文を参照されたい。
1. 導入
この規定では，OWLウェブオントロジ言語について記述する。 OWLは，その内容を単に人に提示すればよいという状
況とは対照的に，アプリケーションが文書に含まれる情報を処理する必要がある場合に使用されることを意図したもの
である。 OWLの使用により，語彙中の用語の意味及びそれらの用語間の関係を明示的に表現することが可能とな
る。この用語及びそれらの相互関係の表現をオントロジと呼ぶ。 XML，RDF，及びRDF-Sと比較すると，OWLには意
味及び意味論を表現するための機能がより多く存在し，そのため，OWLは，ウェブ上で計算機が解釈可能な内容を表
現する能力において，これらの言語より優れている。 OWLは DAML+OIL ウェブオントロジ言語を改訂したものであ
り， DAML+OILの設計及びアプリケーションから学んだ教訓を取り入れている。
1.1 規定一覧
OWL言語は，一組の規定によって記述される。この一組の規定は，それぞれが異なる目的を果たし，異なる対象者の
要求を満たす。この規定を閲覧するための簡単な規定一覧を次に示す。
z
z
z
z
z
このOWL 概要は，非常に簡潔な機能記述を伴った言語機能のリストを提供することによって，OWLを簡単に紹
介している。
OWL 手引きは，広範な一つの事例を提供することによって，OWL言語の使用法を例示すると同時に，これらの
規定で使用される専門用語の用語集も提供する。
OWL 機能一覧は， OWLのすべてのモデル化基本要素について，体系的及び集約的だが，非形式的な記述を
提供している。
OWL セマンティクス及び抽象構文規定は，OWL言語に関する最終的な形式的に表明された規定としての定義
である。
OWL ウェブオントロジ試験事例規定には，OWLの試験事例が数多く含まれる。
-4-
z
OWL 利用事例及び要件規定は，ウェブオントロジ言語の使用例を含み， OWLの要件を整理する。
最初の四規定は，列挙された順に技術内容が高度になっていくため，この順序で読むことを勧める。最後の二規定に
より一組の規定が揃うことになる。
1.2 OWLの必要性
セマンティクウェブは，ウェブの一つの将来像である。これは，情報に明示的な意味を与え，ウェブ上に公開されている
情報を計算機が自動的に処理し，統合することをより容易にする。セマンティクウェブは，カスタマイズされたタグ付け
のスキームを定義するXMLの能力，及びデータ表現におけるRDFの柔軟なアプローチを基に構築することになる。セ
マンティクウェブに必要とされるRDFを越える最初のレベルは，ウェブ文書で使用される用語の意味を形式的に記述
することができるオントロジ言語である。計算機がこれらの文書上で有用な推論の実行を期待される場合，この言語
はRDFスキーマの基本的な意味論をしのぐものでなければならない。 OWL 利用事例及び要件規定は，より多くのオ
ントロジの詳細情報を提供し，六つの利用事例の観点から，ウェブオントロジ言語の必要性を動機付けし，OWLの
設計目標，要件及び目的を明確に記述する。
OWLは，ウェブオントロジ言語のこの必要性を満たすために設計されてきた。 OWLは，増加しつつあるセマンティク
ウェブ関連のW3C勧告の一部である。
z
z
z
z
z
XMLは，構造化文書に表面的な構文を提供するが，これらの文書の意味に意味論的な制約を課すものではな
い。
XML スキーマは， XML文書の構造を制限するための言語であり，データ型を用いてXMLの拡張も行う。
RDFは，オブジェクト("資源")及びオブジェクト間の関係のデータモデルであり，このデータモデルに単純な意味
論を提供する。これらのデータモデルはXML構文で表現することができる。
RDF スキーマは， RDF資源の特性及びクラスを，こういった特性及びクラスの一般化階層の意味論を用いて
記述するための語彙である。
OWLでは特性及びクラスを記述するためにより多くの語彙を追加している。特に，互いに素であることなどのク
ラス間の関係， "正確に1"などのメンバ数，同等性，特性のより豊富な型付け，対称性などの特性の特徴及び
列挙クラスである。
1.3 OWLの三種類の下位言語
OWLは，実装者及び利用者の特定の集団が使用するために設計された三つの段階的に記述能力が増す下位言語
を提供する。
z
z
z
OWL Liteは，主にタクソノミ及び簡単な制約を必要とする利用者をサポートする。例えば，OWL Liteはメンバ数
の制約をサポートする一方で，メンバ数の値は0又は1しか認めない。 OWL Liteに対するツール支援は，より表
現力のある他の言語サブセットよりも簡単である。 OWL Liteはシソーラス及び他の分類に対して迅速な移行パ
スを提供する。同様に，OWL LiteはOWL DLほど形式的な複雑性を持たない。さらに詳細を必要とする場合
は， OWL機能一覧のOWL Liteに関する項を参照されたい。
OWL DLは，計算完全性(すべての結論が計算可能であることが保証されている)，及び決定可能性(すべての
計算が有限時間内に終了する)を保持しつつ，最大の表現能力を要求する利用者をサポートする。 OWL DLに
はOWL言語のすべての構成要素が含まれるが，その使用には一定の制限がある。例えば，あるクラスは複数
のクラスの下位クラスであってもよいが，他のクラスのインスタンスにはなり得ない。 OWL DLは記述論理という
OWLの形式的な基礎を形成する論理を研究する研究分野との対応から，このように名前付けされている。
OWL Fullは，最大の表現能力及び計算上の保証を伴わないRDFの構文の自由を要求する利用者に向けたも
のである。例えば，OWL Fullでは，一つのクラスを個物の集合として扱うと同時にそれ自体を一つの個物として
-5-
扱うことができる。 OWL Fullによって，オントロジは定義済みのRDF又はOWLの語彙の意味を増強することが
可能となる。どのような推論ソフトウェアであっても， OWL Fullのすべての機能に対する完全な推論をサポート
できるというわけではない。
これらの各下位言語は，何を正当に表現できるかという点においても，何を妥当に結論付けできるかという点において
も，その一つ前のより単純な下位言語を拡張したものになっている。次の一連の関係は成立するが，その逆は成立し
ない。
z
z
z
z
すべての正当なOWL Liteオントロジは，正当なOWL DLオントロジである。
すべての正当なOWL DLオントロジは正当なOWL Fullオントロジである。
すべての妥当なOWL Liteの結論は妥当なOWL DLの結論である。
すべての妥当なOWL DLの結論は妥当なOWL Fullの結論である。
OWLを採用するオントロジ開発者は，どの下位言語が自分のニーズに最も合うかを考慮すべきである。 OWL Liteを
選択するかOWL DLを選択するかは，利用者が， OWL DLが提供するより表現力のある構成要素をどの程度必要と
しているかによる。 OWL DLを選択するかOWL Fullを選択するかは，主に，利用者が，クラスの中のクラスを定義し
たり，クラスに特性を追加するなどのRDFスキーマのメタモデル化機能をどの程度必要としているかによる。 OWL
Fullを使用する場合， OWL Fullの完全実装が現在は存在しないため， OWL DLと比較して，推論サポートの予測は
難しい。
OWL FullはRDFの拡張と考えることができる。一方、OWL Lite及びOWL DLはRDFの制限された部分の拡張と考え
ることができる。 Lite，DL，FullのすべてのOWL文書はRDF文書であり，すべてのRDF文書はOWL Full文書である
が，正当なOWL Lite又はOWL DL文書となるのは一部のRDF文書のみである。このため，利用者がRDF文書を
OWLに移行したい場合には，多少注意する必要がある。 OWL DL又はOWL Liteの表現能力が適切であるとみなさ
れる場合は，元のRDF文書がOWL DL及びOWL Liteが強制する追加制約に確実に従っていることに事前に注意を
払う必要がある。特に，クラス名として使用されるすべてのURIは，型owl:Classをもつことを明示的に言明されなけれ
ばならず，すべての個物は，たとえowl:Thingのみであっても，少なくとも一つのクラスに属することを言明されなけれ
ばならない。これは特性に対しても同様である。クラス，特性及び個物に使用されたURIは，互いに素でなければなら
ない。これらとOWL及びOWL Liteに関する他の制約の詳細については， OWL 機能一覧の附属書 Eの説明を参照
されたい。
1.4 この規定の構成
この規定は，最初に，OWL Liteの機能を記述し，その後，OWL DL及びOWL Fullで追加された機能を記述している。
OWL DL及びOWL Fullは同じ機能を含むが， OWL Fullは，これらの機能の組合せ方についてOWL DLより自由で
ある。
2. 言語概要
この項では，OWL Lite，OWL DL，及びOWL Fullのすべての言語機能に簡単な索引を提供する。
この規定では，イタリック体の用語は，OWL言語の用語である。用語がすでにRDF又はRDFスキーマに存在する場
合には，rdf:又はrdfs:の接頭辞が使用される。それ以外の場合，用語はOWLによって導入されたものである。したが
って，用語rdfs:subPropertyOfは， subPropertyOfがすでにrdfsの語彙，技術的にはrdfs名前空間にすでに存在している
ことを示す。同様に，用語Classは，より正確にはowl:Classと記述され， OWLによって導入された用語である。
2.1 OWL Liteの概要
OWL Lite言語の構成要素の一覧を以下の表に示す。
-6-
RDFスキーマ機能:
z
z
z
z
z
z
z
Class (Thing, Nothing)
rdfs:subClassOf
rdf:Property
rdfs:subPropertyOf
rdfs:domain
rdfs:range
Individual
特性の制限:
z
z
z
z
Restriction
onProperty
allValuesFrom
someValuesFrom
クラスの積集合:
z
intersectionOf
同等性及び非同等性:
z
z
z
z
z
z
z
xsd datatypes
equivalentClass
equivalentProperty
sameAs
differentFrom
AllDifferent
distinctMembers
z
z
z
z
z
z
z
制限されたメンバ数:
z
z
z
z
z
z
z
z
ObjectProperty
DatatypeProperty
inverseOf
TransitiveProperty
SymmetricProperty
FunctionalProperty
InverseFunctionalProperty
ヘッダ情報:
minCardinality (0又は1のみ)
maxCardinality (0又は1のみ)
cardinality (0又は1のみ)
z
z
Ontology
imports
注記特性:
版管理:
z
データ型
特性の特徴:
versionInfo
priorVersion
backwardCompatibleWith
incompatibleWith
DeprecatedClass
DeprecatedProperty
z
z
z
z
z
z
rdfs:label
rdfs:comment
rdfs:seeAlso
rdfs:isDefinedBy
AnnotationProperty
OntologyProperty
2.2 OWL DL 及びOWL Fullの概要
OWL Liteの構成要素に追加又は拡張するOWL DL言語及びOWL Full言語の構成要素の一覧を以下の表に示す。
クラス式のブール組合せ:
クラス公理:
z
oneOf, dataRange
disjointWith
equivalentClass
z
(クラス式に適用)
rdfs:subClassOf
z
z
z
z
z
unionOf
complementOf
intersectionOf
(クラス式に適用)
(スロットの)値情報:
任意のメンバ数:
z
minCardinality
z
-7-
hasValue
z
z
maxCardinality
cardinality
3. OWL Liteの言語記述
この項では，OWL Lite言語機能の非公式な記述を提供する。これらの機能の固有構文の議論は行わない。定義に
ついては OWL 機能一覧を参照されたい。各言語機能は，より多くの例と使用に際しての手引きを提供するために，
OWL 手引きの適所にハイパリンクされている。
OWL Liteが使用するのは，OWL言語機能の一部にすぎず， OWL DL又はOWL Fullに比べて，機能の使用に際して
の制限が多い。例えば，OWL Liteでは，クラスの定義は名前付き上位クラスに関する場合に限られており，上位クラ
スが任意式であることはない。さらに，使用できるのはある種のクラス制限のみである。クラス間の等価性及びクラス
間の下位クラスの関係も名前付きクラス間でのみ使用でき，任意のクラス式間では使用できない。同様に，OWL Lite
における制限は名前付きクラスのみを使用する。 OWL Liteではメンバ数の概念にも制限がある。すなわち，明示的
に記述できるメンバ数は，0又は1のみである。
3.1 OWL LiteにおけるRDF スキーマ機能
RDFスキーマに関連するOWL Lite機能を次に示す。
z
z
z
z
z
z
Class: クラスは，個物がいくつかの特性を共有するがゆえに，互いに属するような個物のグループを定義する。
例えば，Deborah (デボラ)もFrank (フランク)もクラスPerson (人)のメンバである。 subClassOfを使用して，クラス
を特殊化階層の中に構成することができる。 Thingと名前付けされた組込みの最も一般的なクラスが存在する。
これは，すべての個物のクラスであり，すべてのOWLクラスの上位クラスである。 Nothingと名前付けされた組
込みの最も特殊なクラスも存在する。これは，インスタンスをもたないクラスであり，すべてのOWLクラスの下位
クラスである。
rdfs:subClassOf: クラスが別のクラスの下位クラスであるという表明を一つ以上行うことによって，クラス階層を
生成することができる。例えば，クラスPerson (人)は，クラスMammal (哺乳類)の下位クラスであると表明するこ
とができる。このことから，推論システムは，個物がPerson (人)である場合，それは同時にMammal (哺乳類)で
あると推論することができる。
rdf:Property: 特性を使用して，個物間，又は，個物からデータ値への関係を表明することができる。特性の例
には， hasChild, hasRelative, hasSibling, 及びhasAgeが含まれる。最初の三つを使用すれば，クラスPerson (人)
のインスタンスをクラスPerson (人)の別のインスタンスに関連付けることができる。したがって，これは，
ObjectPropertyの実現値となる。最後のhasAgeを使用すれば，クラスPerson (人)のインスタンスをデータ型
Integer (整数)のインスタンスに関連付けすることができる。したがって，これは， DatatypePropertyの実現値とな
る。 owl:ObjectPropertyもowl:DatatypePropertyも， RDFのクラスrdf:Propertyの下位クラスである。
rdfs:subPropertyOf: 特性階層は，特性が一つ以上の他の特性の下位特性であることを一つ以上表明すること
によって生成することができる。例えば，hasSiblingは，hasRelativeの下位特性であると表明することができる。
このことから，推論システムは，ある個物がhasSibling特性によって別の個物に関連付けされている場合に，そ
の個物がhasRelative特性によってももう一方の個物に関連付けされていると推論することができる。
rdfs:domain: 特性の定義域は，特性を適用できる個物を制限する。特性が個物を別の個物に関連付け，その
特性がその定義域の一つとしてクラスをもつ場合，個物はそのクラスに属さなければならない。例えば，特性
hasChildはMammal (哺乳類)の定義域をもつと表明することができる。このことから，推論システムは， Frank
(フランク)がAnna (アンナ)とhasChild (子をもつ)という特性で関連をもつ場合， Frank (フランク)はMammal (哺乳
類)でなければならないと推論することができる。制限は特性において表明され，特性が特定クラスと関係する
場合においてのみ表明されるわけではないため， rdfs:domainは大域的な制限と呼ばれる点に注意されたい。
特性制限に関する詳細な情報は， 3.4項の議論を参照されたい。
rdfs:range: 特性の値域は，特性がその値としてもつ個物を制限する。特性が個物を別の個物に関連付け，そ
の特性がその値域としてクラスをもつ場合，関連づけられた他方の個物はその値域クラスに属さなければなら
ない。例えば，特性hasChildが， Mammal (哺乳類)の値域をもつことを表明することができる。このことから，推
-8-
z
論システムは， Louise (ルイズ)がhasChild特性によってDeborah (デボラ)と関連付けされる場合，すなわち，
Deborah (デボラ)がLouise (ルイズ)の子である場合， Deborah (デボラ)はMammal (哺乳類)であると推論する
ことができる。値域も上の定義域と同様に大域的な制限である。 AllValuesFromなどの局所制限に関する詳細
な情報については 3.4項の議論を参照されたい。
Individual : 個物はクラスのインスタンスであり，特性を使用して，一つの個物を別の個物に関連付けることがで
きる。例えば，Deborah (デボラ)と名前付けされた個物はクラスPerson (人)のインスタンスとして記述することも
できるし，特性hasEmployerを使用して，個物Deborah (デボラ)を個物StanfordUniversity (スタンフォード大学)に
関連付けることもできる。
3.2 OWL Liteにおける同等性及び非同等性
同等性又は非同等性に関連するOWL Liteの機能を次に示す。
z
z
z
z
z
equivalentClass : 二つのクラスが同等であると表明することができる。同等なクラスは同じインスタンスをもつ。
同等性を使用して，同義のクラスを生成することができる。例えば，Car (車)は， Automobile (自動車)と
equivalentClass (同等クラス)であると表明することができる。このことから，推論システムは， Car (車)のインス
タンスである個物はいずれもAutomobile (自動車)のインスタンスであり，逆もまた可能であると推論することが
できる。
equivalentProperty: 二つの特性が同等であると表明することができる。同等の特性は一つの個物を他の個物
の同じ集合に関連付ける。同等性を使用して，同義の特性を生成することができる。例えば， hasLeaderは，
hasHeadとequivalentProperty (同等特性)であることを表明することができる。このことから，推論システムは， X
が特性hasLeaderによってYと関連付けられる場合， Xは特性hasHeadによってもYと関連付けられ，その逆も可
能であると推論することができる。推論システムは， hasLeaderがhasHeadの下位特性であり， hasHeadが
hasLeaderの下位特性であることも推論することができる。
sameAs: 二つの個物が，同じであると表明することができる。これらの構成要素を使用して，同じ個物を表す異
なる名前を複数生成することができる。例えば，個物Deborah (デボラ)はDeborahMcGuinness (デボラ・マクギネ
ス)と同じ個物であると表明することができる。
differentFrom: 個物は他の個物と異なると表明することができる。例えば，個物Frank (フランク)は，個物
Deborah (デボラ)及び個物Jim (ジム)とは異なると表明することができる。このとき，個物Frank (フランク)と個物
Deborah (デボラ)がともに関数型であると表明された特性の値である場合，関数型の特性値の数は高々一つで
あるため，矛盾が生じる。個物が異なると明示的に表明することは，個物がただ一つの名前をもつことを前提と
しない OWLやRDFといった言語を使用する場合には重要である。例えば，追加情報がなければ，推論システ
ムは， Frank (フランク)とDeborah (デボラ)が別の個物を表すとは推論しないことになる。
AllDifferent: 一つのAllDifferent文によって，複数の個物が互いに異なると表明することができる。例えば，
AllDifferent構成要素を使用して， Frank (フランク)，Deborah (デボラ)及びJim (ジム)は，互いに異なると表明す
ることができる。上述のdifferntFrom文とは異なり，これは，単にFrank (フランク)がDeborah (デボラ)とは別物で
あり， Frank (フランク)はJim (ジム)とは別物であるというだけではなく， Jim (ジム)とDeborah (デボラ)が別物で
あることまで表明する。 AllDifferent構成要素は，異なるオブジェクトの集合が存在する場合，及び，モデル製作
者が，それらのオブジェクトの集合内での一意名の仮定の強化に関心がある場合には，特に有用である。
distinctMembersとともにこれを使用することによって，リストのすべてのメンバが異なり，どの対をとっても互いに
素であることを表明する。
3.3 OWL Liteにおける特性の特徴
OWL Liteには特別な識別子が存在し，特性及び特性値に関連する情報を提供するために使用される。
ObjectProperty とDatatypePropertyとの相違については， 3.1項の特性記述を参照されたい。
z
z
inverseOf: ある特性が別の特性の逆であると表明することができる。特性P1が特性P2の逆であると表明される
場合， Xが特性P2によってYと関連付けされるならば， Yは特性P1によってXに関連付けされる。例えば，
hasChildがhasParentの逆であり， Deborah (デボラ)がLouise (ルイズ)とhasParent (親をもつ)によって関連づけ
られている場合，推論システムは，Louise (ルイズ)がDeborah (デボラ)とhasChild (子をもつ)によって関連づけ
られると推論することができる。
TransitiveProperty: 特性が推移的であると表明することができる。特性が推移的である場合，対(x,y)が推移特
-9-
性Pのインスタンスであり，対(y,z)がPのインスタンスであれば，対(x,z)もPのインスタンスである。例えば，先祖
が推移的であると表明され， Sara (サラ)がLouise (ルイズ)の先祖(すなわち，(Sara,Louise)が特性先祖のイン
スタンス）であり， Louise (ルイズ)がDeborah (デボラ)の先祖(すなわち，(Louise,Deborah)が特性先祖のインス
タンス)であれば，推論システムは，Sara (サラ)はDeborah (デボラ)の先祖(すなわち，(Sara,Deborah)が特性先祖
のインスタンス)であると推論することができる。
z
z
z
OWL Lite及びOWL DLには，推移特性及びその上位特性は， maxCardinalityを1に制約することができないと
いう副条件が課されている。この副条件がなければ， OWL Lite及びOWL DLは，決定不能な言語となる。詳
細については， OWL セマンティクス及び抽象構文規定の特性公理の項を参照されたい。
SymmetricProperty: 特性は対称的であると表明することができる。特性が対称的であり，対(x,y)が対称特性P
のインスタンスである場合，対(y,x)もPのインスタンスである。例えば，友人は対称特性であると表明することが
できる。推論システムは， Frank (フランク)がDeborah (デボラ)の友人であるという条件を与えられた場合，
Deborah (デボラ)がFrank (フランク)の友人であると推論することができる。
FunctionalProperty : 特性は単一の値をもつと表明することができる。特性がFunctionalPropertyであれば，各
個物に対して値は高々一つしかなく，ある個物に対して値がない場合もある。この特徴は，一意の特性として，
表現されてきた。 FunctionalPropertyは，特性の最小のメンバ数が0であり，最大のメンバ数が1であることを表明
するための省略表現である。例えば， hasPrimaryEmployerがFunctionalPropertyであると表明することができ
る。このことから，推論システムは，いかなる個物にも一つ以上の主雇用者は存在しないと推論することができ
る。しかし，これは，すべてのPerson (人)に少なくとも一つの主雇用者が存在しなければならないということを意
味しない。
InverseFunctionalProperty: 特性は逆関数であると表明することができる。特性が逆関数である場合，その特
性の逆は関数である。したがって，その特性の逆がもつ値は，高々一つである。この特徴も曖昧でない特性と
して表現されてきた。例えば， hasUSSocialSecurityNumber (米国社会保障番号をもつ)は，逆関数又は曖昧性
をもたないと表明することができる。この特性の逆は isTheSocialSecurityNumberFor (の社会保障番号である)
として表現することができるが，これがもつ値は，社会保障番号というクラスの中では，どの個物についても一つ
しかない。したがって，ある人の社会保障番号はどれも，そのisTheSocialSecurityNumberFor特性の値のみであ
る。このことから，推論システムは， Person (人)の異なる二つの個物のインスタンスは，同一の米国社会保障
番号をもたないと推論することができる。同様に，推論システムは， Person (人)の二つのインスタンスが同じ社
会保障番号をもつ場合，それらの二つのインスタンスは同一の個物を示すと推論することができる。
3.4 OWL Liteにおける特性の制限
OWL Liteにより，クラスのインスタンスがどのように特性を使用できるかについて，制限を加えることができる。これら
の型及び次の小項目で記述するメンバ数の制限は， owl:Restrictionの文脈内で使用される。 owl:onProperty要素は，
制限される特性を示す。次の二つの制限は，どの値を使用できるかを制限する。その一方で，次の項の制限はどのく
らい多くの値を使用できるかを制限する。
z
z
allValuesFrom: 制限allValuesFromは，クラスに関する特性について表明される。すなわち，この特定のクラス
に関するこの特性には，それに関連する局所的な値域の制限が存在する。したがって，クラスのインスタンスが
特性によって二番目の個物に関連付けされている場合，その二番目の個物は，局所的な値域の制限クラスのイ
ンスタンスであると推論することができる。例えば，クラスPerson (人)は，クラスWoman (女性)とallValuesFromを
もつように制限された hasDaugther (娘をもつ)と呼ばれる特性をもつことができる。すなわち，個物の人である
Louise (ルイズ)が特性hasDaughterによって，個物Deborah (デボラ)に関連付けされる場合，このことから，推論
システムは， Deborah (デボラ)がクラスWoman (女性)のインスタンスであると推論することができる。この制限
により，特性hasDaughterを，クラスCat (猫)などの他のクラスとともに使用することができ，そのクラスの特性の
使用に関連付けられた適正な値に制限することができる。この場合，hasDaughterは，クラスCatと関連する際に
は，局所的な値域のCat (猫)に制限され，クラスPerson (人)と関連する際には，局所的な値域のPerson (人)に制
限されることになる。推論システムは， allValuesFrom制約だけからは，実際にその特性について少なくとも一
つ値があると推論することはできない点に注意されたい。
someValuesFrom: 制限someValuesFromはクラスに関する特性について表明される。ある特定のクラスに対し
て，その特性の少なくとも一つの値が特定の型に属しているという特性についての制限を与えることができる。
例えば，クラスSemanticWebPaper (セマンティクウェブ報告書)には， hasKeyword特性に関してsomeValuesFrom
制限をもたせることができる。この場合，hasKeyword特性は， hasKeyword特性のある値がクラス
-10-
SemanticWebTopic (セマンティクウェブトピック)のインスタンスであるべきであることを表明する。この場合，複
数のキーワードをもつという選択が可能であり，一つ以上がクラスSemanticWebTopic (セマンティクウェブトピッ
ク)のインスタンスである限り，報告書はsomeValuesFrom制限に矛盾しないことになる。 allValuesFromとは異な
り， someValuesFromは特性のすべての値を同じクラスのインスタンスであると制限することはない。 myPaper
(自分の報告書)が SemanticWebPaper (セマンティクウェブ報告書)クラスのインスタンスである場合， myPaper
(自分の報告書)はhasKeyword特性によって，少なくとも一つのSemanticWebTopic (セマンティクウェブトピック)ク
ラスのインスタンスに関連付けされている。 allValuesFrom制限の場合のように，推論システムは，hasKeyword
のすべての値が SemanticWebTopic (セマンティクウェブトピック)クラスのインスタンスであると推論することはで
きない点に注意されたい。
3.5 OWL Liteにおける制限されたメンバ数
OWL Liteには，メンバ数の制限について，限定された形式が存在する。 OWL及びOWL Liteのメンバ数の制限は，局
所制限と呼ばれる。これは，これらの制限が特定クラスに関連した特性に関して表明されるためである。すなわち，こ
の制限は，そのクラスのインスタンスについて，その特性のメンバ数を制約するものである。 OWL Liteのメンバ数制
限は， OWL DL及びOWL Fullのようにメンバ数に関して任意の値をとることはできず，メンバ数については0又は1の
値しか表明できないため，限定されている。
z
z
z
minCardinality: メンバ数は，特定クラスに関する特性について表明される。あるクラスに関する特性について
minCardinalityが1であると表明された場合，そのクラスのすべてのインスタンスは，その特性によって，少なくと
も一つの個物に関連付けされることになる。この制限は，その特性が，そのクラスのすべてのインスタンスに対
して値をもつことを要求されるということを別の表現で言ったものである。例えば，クラスPerson (人)は，すべて
の人が子孫をもつわけではないため， hasOffspring特性に関して表明される最小のメンバ数については何の制
限もない。しかし，クラスParent (親)は， hasOffspring特性について最小のメンバ数1をもつことになる。 Louise
(ルイズ)がPerson (人)である場合，彼女のhasOffspring特性の最小メンバ数について，推論システムは何の結
論も導き出すことはできない。いったん， Louise (ルイズ)がParent (親)のインスタンスであることが発見されれ
ば，推論システムは， Louise (ルイズ)がhasOffspring特性によって少なくとも1つの個物に関連付けされている
と推論することができる。この情報だけからは，推論システムは，クラスParent (親)の個物インスタンスに対する
子孫の最大数については何も推論することはできない。 OWL Liteで使用できる最小メンバ数は， 0又は1に限
られている。特性に0の最小メンバ数が割り当てられた場合，より固有の情報がなければ，その特性がクラスに
関して任意であることを表明するにすぎない。例えば，特性hasOffspringは，クラスPerson (人)の最小メンバ数を
0とすることができる。その一方で，クラスParent (親)については，最小メンバ数が1であるという，より固有な情報
の存在を表明している。
maxCardinality: メンバ数は，特定のクラスに関する特性について表明される。あるクラスに関して
maxCardinalityが1であることを表明した場合，そのクラスのどのインスタンスも，その特性によって，高々1つの
個物に関連付けされることになる。 maxCardinalityが1であるという制限を関数の特性又は一意の特性と呼ぶこ
ともある。例えば，クラスUnitedStateCitizens (アメリカ国民)に関する特性hasRegisteredVotingStateは，国民の投
票権が一つの州に限られているため，最大メンバ数を1とすることができる。このことから，推論システムは，ク
ラスUSCitizens (アメリカ国民)の個物インスタンスは， hasRegisteredVotingState特性を通じて，二つ以上の異な
る個物に関連付けされていないと推論することができる。最大メンバ数を1とするという制限だけでは，推論シス
テムは，最小メンバ数が1であると推論することはできない。特定の特性に対する値が存在しない特定のクラス
があることを表明することは有用である。例えば，クラスUnmarriedPerson (未婚者)のインスタンスは，特性
hasSpouseによって，どの個物にも関連付けられるべきではない。この状況は，クラスUnmarriedPerson (未婚者)
のhasSpouse特性に最大メンバ数0を割り当てることによって，表現される。
cardinality: あるクラスの特性のminCardinalityが0であり，かつ，maxCardinalityも0であるか，又は，
minCardinalityが1であり，かつ，maxCardinalityも1であると表明するのが有用である場合は， cardinalityは簡便
形として提供される。例えば，クラスPerson (人)は，特性hasBirthMotherに対して厳密に値を一つだけもってい
る。このことから，推論システムは，クラスMother (母親)の二つの異なる個物インスタンスが，同一人物に関す
るhasBirthMother特性の値ではないと推論することができる。
これらのメンバ数の制限形式の代替となる名前付けが議論された。現在の勧告は，フロントエンドシステムにそのよう
な名前をすべて含むことになっている。この項目についての詳細は，入手可能なウェブオントロジの公開メールアーカ
イブで入手できる。最も関連するメッセージはhttp://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0063.htmlで
-11-
ある。
3.6 OWL Liteにおけるクラスの積集合
OWL Liteには，積集合の構成要素が含まれるが，その使用は制限されている。
z
intersectionOf: OWL Liteでは，名前付きクラス及び制限の積集合を使用することができる。例えば，クラス
EmployedPerson (被雇用者)は Person (人)及びEmployedThings (被雇用物)のintersectionOf (積集合)として記
述することができる。 EmployedThings (被雇用物)は， hasEmployer特性の最小メンバ数が1である物として定義
できる。このことから，推論システムは，特定のEmployedPerson (被雇用者)はいずれも，少なくとも一人の雇用
主をもつということを推論することができる。
3.7 OWL データ型
OWLはデータ値に対してRDFの機構を使用する。 OWL手引きのデータ型の項を参照されたい。 XMLスキーマのデ
ータ型から大部分を採り入れた組込みのOWLデータ型について，より詳細な記述を入手することができる。
3.8 OWL Liteにおけるヘッダ情報
OWL Liteは，オントロジの包含及び関係並びにオントロジへの付加情報という概念をサポートする。詳細について
は， OWL 機能一覧を，例については OWL 手引きを参照されたい。
3.9 OWL Liteにおける注記特性
OWL Liteでは，クラス，特性，個物及びオントロジヘッダについて注記を使用することができる。これらの注記の使用
には，一定の制限がある。詳細については， OWL 機能一覧の注記の項を参照されたい。
3.10 OWL Liteにおける版管理
RDFには，版管理情報の記述について，小規模な語彙がすでに存在する。 OWLは，この語彙を大きく拡張する。詳
細については， OWL 機能一覧を参照されたい。
4. OWL DL及びOWL Fullの追加的な言語記述
OWL DLはいくつかの制限を受けるが， OWL DL及びOWL Fullは同じ語彙を使用する。おおまかにいえば， OWL
DLは，型分離を要求する。クラスが個物又は特性でもあることはなく，特性が，個物又はクラスでもあることはない。
これは，制限をOWL自体の言語要素，すなわちOWL FULLで利用可能なものに適用できないことを意味する。さら
に，OWL DLは，特性がObjectProperties又はDatatypePropertiesのいずれかであることを要求する。
DatatypePropertiesはクラスのインスタンスとRDFリテラル及びXMLスキーマのデータ型との間の関係であり，
ObjectPropertiesは二つのクラスのインスタンス間の関係である。 OWL セマンティクス及び抽象構文規定は，相違と制
限を説明している。以下では， OWL Liteの構成を拡張するOWL DL及びOWL Fullの語彙を記述する。
z
z
z
oneOf: (列挙クラス): そのクラスを形成する個物を列挙することによって，クラスを記述することができる。クラス
のメンバは，正確に，列挙された個物の集合に他ならない。例えば， daysOfTheWeek (曜日)のクラスは，個物
である日曜日，月曜日，火曜日，水曜日，木曜日，金曜日，土曜日をただ列挙することによって，記述される。こ
のことから，推論システムは， daysOfTheWeek (曜日)をそのallValuesFrom制限としてもつすべての特性の最大
メンバ数(この場合は7)を推論することができる。
hasValue: (特性値): 特性に，ある個物を値としてもつことを要求することができる。これは特性値とも呼ばれる。
例えば， dutchCitizens (オランダ国民)のクラスのインスタンスは，その国籍の値として， theNetherlands (オラン
ダ)をもつ人々として特徴づけられる。この場合，国籍の値であるtheNetherlands (オランダ)は， Nationalities (国
籍)クラスのインスタンスである。
disjointWith: クラスは，互いに素であると表明することができる。例えば， Man (男性)とWoman (女性)が互い
に素なクラスであると表明することができる。このdisjointWith文から，推論システムは，個物が両方のインスタ
-12-
z
z
z
ンスであると表明された場合には矛盾であると推論することができ，同様に，推論システムは， AがMan (男性)
のインスタンスである場合は， AはWoman (女性)のインスタンスではないと推論することができる。
unionOf, complementOf, intersectionOf (ブール結合): OWL DL及びOWL Fullでは，クラス及び制限の任意の
ブール結合を使用することができる。すなわち，unionOf, complementOf, 及び intersectionOfがこれに該当する。
例えば，unionOfを使用すると，あるクラスがUSCitizens (アメリカ国民)か DutchCitizens (オランダ国民)のいず
れかである物を含むことを表明することができる。 complementOfを使用すると, 子供がSeniorCitizens (高齢者)
ではないことを表明することができる。すなわち，クラスChildren (子供)は， SeniorCitizens (高齢者)の補集合の
下位クラスである。欧州連合の市民は，メンバであるすべての加盟国の市民を統合したものであると記述する
ことができる。
minCardinality, maxCardinality, cardinality (完全なメンバ数): OWL Liteでは，メンバ数が少なくても，多くても，
ちょうどでも1又は0に制限されているが，完全なOWLでは，任意の非負整数に対してメンバ数の表明が可能で
ある。例えば，DINKs ("二重収入かつ子供なし")のクラスは，特性hasIncomeのメンバ数を最小メンバ数2に制
限するが，その一方で，特性hasChildはメンバ数を0に制限しなければならないことになる。
complex classes : 多くの構成要素において， OWL Liteは，構文を単一のクラス名に制限する。例えば，これは，
subClassOf文又はequivalentClass文で見受けられる。 OWL Fullは，この制限を拡張し，任意の複雑なクラスの
記述，列挙クラスの構成，特性制限及びブール結合を可能にする。同様に，OWL Fullでは，クラスをインスタン
スとして使用することができるが， OWL DL及びOWL Liteではできない。この項目の詳細については，手引き
規定の"使い分"の項を参照されたい。
5. まとめ
この規定は，ウェブオントロジ言語の必要性及びW3C言語との関係におけるOWLの適合性について，簡単な導入を
提供することによって，ウェブオントロジ言語の概要を記述したものである。さらに，三つのOWL下位言語，すなわち，
OWL Lite，OWL DL及びOWL Fullについても，各言語に関する機能概要とともに簡単に記述している。この規定は，
機能概要規定の更新版であり，簡単な例とともに構成要素についても簡単に説明している。詳細については， OWL
機能一覧規定， OWL 手引き，及びOWL セマンティクス及び抽象構文規定を参照されたい。この規定の以前の版
( 2003年12月15日， 2003年9月5日， 2003年8月18日， 2003年7月30日， 2003年5月1日， 2003年3月20日， 2003年1
月2日， 2002年7月29日， 2002年7月8日， 2002年6月23日， 2002年5月26日，及び 2002年5月15日)は，OWL Liteの
進化の継時的過程及びその過程において議論された課題を提供している。
附属書A 文献
[OWL Guide]
OWL Web Ontology Language Guide, Michael K. Smith, Chris Welty, and Deborah L. McGuinness, Editors, W3C
Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-guide-20040210/ . 最新版は
http://www.w3.org/TR/owl-guide/で入手可能。
[OWL Reference]
OWL Web Ontology Language Reference, Mike Dean and Guus Schreiber, Editors, W3C Recommendation, 10
February 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/ . 最新版はhttp://www.w3.org/TR/owl-ref/
で入手可能。
[OWL Abstract Syntax and Semantics]
OWL Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider, Pat Hayes, and Ian
Horrocks, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-semantics20040210/ . 最新版はhttp://www.w3.org/TR/owl-semantics/で入手可能。
[OWL Test]
OWL Web Ontology Language Test Cases, Jeremy J. Carroll and Jos De Roo, Editors, W3C Recommendation, 10
February 2004, http://www.w3.org/TR/2004/REC-owl-test-20040210/ . 最新版はhttp://www.w3.org/TR/owl-test/
で入手可能。
[OWL Requirements]
OWL Web Ontology Language Use Cases and Requirements, Jeff Heflin, Editor, W3C Recommendation, 10
February 2004, http://www.w3.org/TR/2004/REC-webont-req-20040210/ . 最新版は
http://www.w3.org/TR/webont-req/ で入手可能。
-13-
[OWL Issues]
Web Ontology Issue Status. Michael K. Smith, ed. 1 November 2003.
[DAML+OIL Reference]
DAML+OIL Reference Description . Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah L. McGuinness,
Peter F. Patel-Schneider, and Lynn Andrea Stein. W3C Note 18 December 2001.
[XML]
Extensible Markup Language (XML).
[XML Schema]
XML Schema .
[XML-SCHEMA2]
XML Schema Part 2: Datatypes - W3C Recommendation, World Wide Web Consortium, 2 May 2001.
[RDF/XML Syntax]
RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . 最新版はhttp://www.w3.org/TR/rdf-syntaxgrammar/ で入手可能。
[RDF Concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll,
Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . 最
新版はhttp://www.w3.org/TR/rdf-concepts/ で入手可能。
[RDF Schema]
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R. V. Guha, Editors, W3C
Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . 最新版は
http://www.w3.org/TR/rdf-schema/ で入手可能。
[RDF Semantics]
RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . 最新版はhttp://www.w3.org/TR/rdf-mt/ で入手可能。
[Description Logics]
The Description Logic Handbook. Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi, Peter
Patel-Schneider, editors. Cambridge University Press, 2003; and Description Logics Home Page.
附属書B(参考) 貢献者
この規定は，全体として，ウェブオントロジ作業グループ内で積み重ねられれた議論の結果である。この作業グルー
プのメンバを次に示す。 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, and John Yanosy.
附属書C(参考) 変更記録
C.1 最終審議案からの変更記録
z
z
z
z
z
owl:NothingをOWL Liteに追加。
ポインタをタイトル下の最終審議案に追加。
owl-absynへのすべてのリンクをowl-semanticsに変更。
2003年4月21日付けのpublic-webont-commentsから Lee Lacyの文法に関するコメントを組み込んだ。
Lee Lacyの他のコメント，すなわち，注記特性，版管理特性及び2.2の他の欠落タグを組み込んだ。欠落タグは
結果として再編成された。
-14-
z
z
z
z
z
z
z
z
z
Morten Frederiksenの要請により，hasOffSpringの例をhasDaughterに変更。
"計算機可読性"から"機械解釈可能性"への置換，及び様々な誤植を含むLasillaのコメントをすべて組み込ん
だ。
Jim Hendlerの提案どおり， OWL Liteのより複雑ではないクラスに関する文章を追加。
Sandro Hawkeのコメント後に最初の文を第1項に追加。
スタイルファイルへのリンクを復元。
テスト文書及び5月1日版へのリンクを追加。
文献の項を追加。
項への相対参照に戻した。
TR/2003/CR-xx-20030818/の後に，更新した以前の版からhttp://www.w3.org/TR/xxにリンクを変更。
C.2 勧告候補からの変更記録
z
z
z
z
勧告候補からの変更記録を追加。
すべての行末で，Ctrl Mを削除。
Jeff Rafterの公開ウェブオントロジコメントを組み込んだ。
状態，文書リンク，発行日などを，議長からのPR電子メールに従って更新。
C.3 勧告案からの変更記録
z
z
z
z
z
z
二つのリンク切れを修正。 W3Cアイコンは，著者を示すgifである局所W3c拡張 src="OWL Web Ontology
Language Overview_files/を参照することによって参照されていた。 W3Cアイコン
(http://www.w3.org/Icons/w3c_home) 及びemailのgif (http://www.w3.org/2001/sw/WebOnt/guidesrc/Email.Deborah.McGuinness.gif)を全面的に拡張をした。
新しい版への移行で導入されたすべての行末でCtrl Mを削除。
2003年12月に以前の版へのリンクを追加。
2004年1月12日付けのLee Lacyのコメントを採用した文書を更新。コメントによる変更はほとんどわずかな編集
上のものにとどまり， 30から27への表のセル間隔の変更程度であった。
Benjamin Nowackの編集上のコメントを収録。
文献のフォーマットを更新。
-15-
[附属資料－A.2]
OWL Guide 第 2 章まで抜粋
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 手引き
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公
開後の実用新案登録願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録願にかかわる確認について，責任はもたない。
この標準仕様書(TS)には，次に示す附属書及び解説がある。
附属書1(参考) 貢献者
附属書2 OWL用語集
附属書3(参考) 索引及び相互参照
附属書4 文献
附属書A(参考) XML及びRDFの概要
附属書B(参考) 経緯
附属書C(参考) 最終審議案からの変更記録
この版:
http://www.w3.org/TR/2004/REC-owl-guide-20040210/
最新版:
http://www.w3.org/TR/owl-guide/
以前の版:
http://www.w3.org/TR/2003/PR-owl-guide-20031215/
編者:
Michael K. Smith, Electronic Data Systems
Chris Welty, IBM Research
Deborah L. McGuinness, Stanford University
この文書の正誤表を参照のこと。標準修正が含まれている。
翻訳版も参照のこと。
Copyright© 2004 W3C® (MIT, ERCIM , Keio), All Rights Reserved. W3C 免責, 商標, 文書使用及びソフ
トウェア使用許諾の規則を適用する。
原規定の状態
原規定は，W3Cのメンバ及び他の関係者によってレビューされ，W3C 勧告として技術統括責任者によって承認
された。勧告の作成において，W3Cはこの規定を広く知らせ，普及させる役割をもつ。これによって，ウェブ
の機能性及び相互運用性が高まる。
-1-
これは，六部分から構成されるOWL，ウェブオントロジ言語のW3C勧告のうちの一つである。これは，2004年2
月10日の公開に向けて，ウェブオントロジ作業グループによって，W3C セマンティクウェブ活動 (活動声明,
グループ憲章)の一環として作成された。
これらの文書の初期版で示されたOWLの設計は広くレビューされており，作業グループの技術要件を満たして
いる。作業グループは，必要に応じて変更を加えながら，受理されたすべてのコメントを検討し，必要に応
じて変更している。原規定の勧告案版からの変更の詳細については、変更記録を参照されたい。
コメントは public-webont-comments@w3.org (アーカイブ)で受け付けている。関連技術についてはwww-rdflogic@w3.org (アーカイブ)で議論されている。
実装のリストを入手することができる。
W3Cは，この作業に関するすべての特許明細のリストを管理している。
ここでは，公開時における原規定の状態を記述する。他の規定が原規定に取って代わることもある。現在の
W3C刊行物のリスト及びこの技術報告書の最新改訂版については， http://www.w3.org/TR/のW3C 技術報告書
索引を参照されたい。
-2-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 手引き
目
次
まえがき
序文
0. 適用範囲
1. 導入
1.1 OWLの種類
1.2 この規定の構成
2. オントロジの構造
2.1 名前空間
2.2 オントロジヘッダ
2.3 データ集約及びプライバシ
3. 基本要素
3.1 単純なクラス及び個物
3.2 単純な特性
3.3 特性の性質
3.4 特性の制限
4. オントロジの対応付け
4.1 クラス間および特性間の等価性
4.2 個物間の同一性
4.3 異なる個物
5. 複合クラス
5.1 集合演算子
5.2 列挙クラス
5.3 互いに素なクラス
6. オントロジの版管理
7. 使用例
7.1 ワインポータル
7.2 ワインエージェント
附属書1(参考) 貢献者
附属書2 OWL用語集
附属書3(参考) 索引及び相互参照
附属書4 文献
附属書A(参考) XML及びRDFの概要
附属書B(参考) 経緯
附属書C(参考) 最終審議案からの変更記録
解説
-3-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 手引き
OWL Web Ontology Language — Guide
序文
この標準仕様書(TS)は，2004年2月にWorld Wide Web Consortium (W3C)から公表されたWeb Ontology Language,
Overviewを翻訳し，技術的内容を変更することなく作成した標準仕様書(TS)である。
0. 適用範囲
現在のWorld Wide Webは，貧弱な地図しかない地形に似ている。文書を識別しそれを利用する能力は，キーワード
検索に基づくものであって，文書のつながり及び利用パターンをたくみに用いることによって遂行されている。効果的
なツールの支援がない場合，大部分のデータの扱いは困難になる。この地形をより精緻な地図にするために，コンピ
ュータのエージェントは，機械可読に記述された内容及びウェブアクセス可能な資源を必要とする。これらの記述は，
その情報の人間可読な版に追加されなければならない。
OWLウェブオントロジ言語は，ウェブ文書及びアプリケーションに潜在的に備わっているクラス及びクラス間の関係を
記述するために使用できる言語の提供を意図している。
この規定は，次に掲げるOWL言語の使用法を提示する。
1. クラス及びクラスの特性を定義することによって，定義域を形式化する。
2. 個物を定義し，それらに関する特性を言明する。
3. これらのクラス及び個物について，OWL言語の形式的な意味論が許容する程度まで推論する。
各箇条は，クラス，特性及び個物の集合の定義を追加しながら表現するように構成されており，基本から始まり，より
複雑な言語構成要素へと進む。
1. 導入
"次の食事メニューの各コースに供するためにどのワインを買ったらよいか教えて欲しい。ただし，ソーテルヌは好まな
い。"
現在，ウェブ上でワインに関する検索を実行して，この問いに満足のいく答えを出すウェブエージェントを構成するの
は難しい。同様に，実際に，ソフトウェアエージェントに一貫した一連の旅行手配作業を作成する仕事を割り当てる場
合を検討してみるのもよい。より多くの使用例については，OWL 要件規定を参照すること。
この種の計算を支援するためには，キーワードを超えて，ウェブ上に記述された資源の意味を指定することが必要に
なる。この解釈のために追加される層は，データの意味を取得する。
OWLウェブオントロジ言語は，ウェブオントロジを定義し，そのインスタンスを生成するための言語とする。オントロジ
とは，哲学から借りた用語であって，世界に存在する実体の種類，及びそれらがどのように関連付けられるかを記述
する科学に由来する。 OWL オントロジは，クラス, 特性及びそれらのインスタンスの記述を含む。こうしたオントロジを
仮定することによって，OWLの形式意味論は，その論理的帰結，すなわち，オントロジの中にそのままでは存在せ
ず，意味論によって論理的に導かれる事実，をどのように導き出すかを規定する。これらの論理的帰結は，単一の文
書に基づいてもよいし，定義済みのOWL機構によって結合された複数の分散文書に基づいてもよい。
-4-
この規定は，OWLというウェブオントロジ言語の記述における構成要素の一つであって， W3C ウェブオントロジ作業
グループ(WebOnt)によって作成された。概要([Overview]の1.1)の規定一覧では，記述の異なる部分のそれぞれ及び
それらがどのように組み合わされているかを示している。
新たなXML/Web標準を規定するときには，"このXML/Web標準によって得られて，XML及びXMLスキーマでは得ら
れないものは何か。"という疑問が生じる。この疑問に対する答えは，次の二つになる。
z
z
オントロジがXMLスキーマと異なるのは，オントロジが，知識表現であって，メッセージ書式ではないという点で
ある。大部分の業界指導のウェブ標準は，メッセージ書式及びプロトコル規定の組合せから構成されている。こ
れらの書式には，操作的に意味が示されている。例えば，"このPurchaseOrderメッセージを受け取ったら，
Amountの量のドルをAccountFromからAccountToに振り替え，Productを出荷する。"などである。しかし，その
規定は，トランザクション文脈外の推論を提供するためには設計されていない。例えば，一般に，Productはシ
ャルドネの一種なので，それは白ワインでもなければならない，と結論づける機構はない。
OWLオントロジの利点の一つは，推論を可能とするツールの利用可能性にある。ツールは，特定の問題領域に
縛られない汎用的な支援機能を提供するもので，ある人が特定の業界標準化されたXMLスキーマに関して推
論を行うシステムを構築する場合に寄与する。しっかりした効果的な推論システムを構築することは容易な仕事
ではない。オントロジの構築は，それに比べるとはるかに扱いやすい。多くのグループがオントロジ構築に着手
することが期待される。それらのグループは，OWL言語の形式性に基づく第三者のツール，すなわち，殆どの
組織が同じものを作成するのが難しい一連の機能を配布するツールから恩恵を受けることになる。
1.1 OWLの種類
OWL言語は，特定の実装者及び利用者が使用するために，段階的に表現機能を増加させるように設計された次の三
つの下位言語を提供する。
z
z
z
OWL Liteは，分類階層及び単純な制約機能を必要とする利用者を支援する。例えば，OWL Liteでは，メンバ数
制約を提供するが，そのメンバ数の値としては，0又は1だけを許す。OWL Liteのためのツールの支援は，より
表現力の高い他の二つの言語よりも単純であって，類語集及び他のタクソノミに対して，迅速な移行手順を提供
する。
OWL DLは，推論システムに関して，計算の完全性（すべての論理的帰結の計算が保証されること）及び決定可
能性（すべての計算が有限時間内に終了すること）を保持しつつ，最大の表現力を要求する利用者を支援す
る。 OWL DLは，すべてのOWL言語の構成要素を含むが，型分離などの制約もある。この型分離とは，クラス
が個物又は特性になることはなく，特性が個物又はクラスになることもないことをいう。OWL DLは，記述論理
[Description Logics]，一階述語論理の特定の決定可能な部分を研究してきた分野，に対応しているので，DLと
名前付けされている。OWL DLは，記述論理が使われてきた既存の分野を支援するために設計されたが，推論
システムのために望ましい計算特性をもつ。
OWL Fullは，最大限の表現力，及び計算上の保証が得られていないRDFの構文的自由性を要求する利用者
のために作られた。例えば，OWL Fullでは，クラスを個物の集合とすると同時に，それ自体を個物として扱うこと
ができる。OWL DLとの他の一つの重要な相違点は，owl:DatatypePropertyを
owl:InverseFunctionalPropertyとしてマーク付けできることにある。 OWL Fullによって，オントロジは，事前
に定義された（RDF又はOWLの）語彙の意味を強化できる。いかなる推論ソフトウェアもOWL Fullのすべての機
能を提供できるとは望めない。
これらの下位言語の各々は，何を正しく表現できるかという点でも，何を妥当と結論付けできるかという点でも，より単
純なものとして順序付けられた一段階前の言語を拡張したものとする。次の一連の関係が成立するが，その逆は成立
しない。
z
z
z
すべての正しいOWL Liteオントロジは，正しいOWL DLオントロジになる。
すべての正しいOWL DLオントロジは，正しいOWL Fullオントロジになる。
すべての妥当なOWL Liteの結論は，妥当なOWL DLの結論になる。
-5-
z
すべての妥当なOWL DLの結論は，妥当なOWL Fullの結論になる。
OWLを採用するオントロジ開発者は，どの下位言語が自分の必要性に最も合うかを考慮するのがよい。OWL Liteを
選択するかOWL DLを選択するかは，利用者が，OWL DLが提供するより強力な制約表現を構成要素としてどの程
度必要としているかによる。OWL Liteの推論機構は，望みどおりの計算特性をもつ。OWL DLの推論機構は，決定可
能な下位言語を扱いつつも，最悪の場合，より困難な複雑性に支配されかねない。OWL DLを選択するかOWL Full
を選択するかは，主に，利用者が，クラスのクラスを定義するなど，RDFスキーマのメタモデル化機能をどの程度必要
としているかによる。OWL Fullを使用する場合は，OWL DLと比較して，推論支援の予測可能性が低くなる。この問題
に関する詳細は，OWL意味論規定を参照すること。
RDFからOWL DL又はOWL Liteへ移行する利用者は，元のRDF文書がOWL DL及びOWL Liteが課す制約に確実
に従っていることに注意を払う必要がある。これらの制約に関する詳細については， OWL機能一覧の附属書 Eを参
照すること。
この規定の中で，OWL DL又はOWL Fullだけで許される構成要素を導入する場合, それらを"[OWL DL]"と印付ける
ことにする。
1.2 この規定の構成
手引き全体を通じて一貫性のある例を提供するために，ワイン及び食品のオントロジを作成した。ここでの議論の幾
つかは，OWL Fullの能力に焦点をあてることになるが，その場合は，そのように印付けをする。ワイン及び食品のオ
ントロジは，歴史的な経緯をもつDAMLオントロジライブラリの一つの要素を大幅に変更したものである。これは，
元々，McGuinnessによってCLASSIC記述論理の例として開発されたものであって，記述論理の解説用に拡張され, さ
らに，オントロジの解説用に拡張された。
この規定では，RDF/XML構文 ([RDF], の 5)を使用して例を示し，XMLが大半の対象者にとってよく知られた言語に
なっていると想定する。規定としてのOWL交換構文は，RDF/XMLとする。 OWLがRDF及びRDFスキーマに最も互換
性をもつものとして設計された点に注意されたい。これらのXML及びRDFの書式は，OWLの規定の一部とする。
この規定で表示される例はすべてwine.rdf 及びfood.rdfに含まれるオントロジから採用されている。ただし，右下の隅
に, ¬ で印付けされたものは除く。
2. オントロジの構造
OWLは，セマンティクウェブ実現の活動の構成要素といえる。この作業の目的は，ウェブコンテンツを記述又は提供す
る資源に関する情報を追加することによって，ウェブ資源を，自動化された処理に対してより容易にアクセス可能とす
ることにある。セマンティクウェブは，本来分散されるものなので，OWLによって，分散された情報源から情報を集める
ことができなければならない。これは，他のオントロジから情報を明示的に取り込むことを含むオントロジの関連付けを
可能にすることによって，部分的に実行される。
さらに，OWLは，開かれた世界を想定している。すなわち，資源の記述は，単一のファイル又は有効範囲に限定され
ない。クラスC1は元々オントロジO1で定義されていてもよいが，他のオントロジでそれを拡張することができる。C1に関
するこれらの追加的な命題の結論は，単調とする。すなわち，新しい情報が，以前の情報を撤回することはできない。
新しい情報は，矛盾を含む可能性があるが，事実及び論理的帰結は，追加だけが可能であって，削除はできない。
こうした矛盾の可能性は，オントロジ設計者が考慮する必要のあるものとする。ツールによる支援が，こうした事例の
検出に役立つことが期待される。
あいまい性なく解釈可能であってソフトウェアエージェントによって使用可能なオントロジを書くために，OWLに対して，
構文及び形式意味論を要求する。 OWLは，RDFの語彙の拡張 [RDF Semantics]とする。 OWLの意味論は，OWLウ
ェブオントロジ言語の意味論及び抽象構文の規定で定義される。
-6-
2.1 名前空間
一連の用語を使用可能とする前に，どの固有の語彙が使用されているかを正確に示す必要がある。オントロジの標準
的な初期構成要素には，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番目の宣言は，接頭辞にvin:をもつ現
在のオントロジの名前空間を識別する。3番目の宣言は，この文書の基底URIを識別する(以下を参照)。4番目の宣言
は，接頭辞にfood:をもつサポートする食品のオントロジの名前空間を識別する。
5番目の名前空間宣言は，この文書では，接頭辞にowl:をもつ要素は，http://www.w3.org/2002/07/owl#と呼ばれ
る名前空間から取り出された事物を参照するとして理解されるのが望ましいということを表している。これは，慣習的な
OWL宣言であって，OWL語彙の導入に使用される。
OWLは，RDF，RDFS及びXMLスキーマデータ型によって定義される構成要素に依存する。この例の文書では，接頭
辞rdf:は，http://www.w3.org/1999/02/22-rdf-syntax-ns#と呼ばれる名前空間から取り出された事物を参照す
る。次の二つの名前空間宣言は，RDFスキーマ(rdfs:)及びXMLスキーマデータ型(xsd:)の名前空間に関して，同様
のことを示している。
長いURLを書く場合の手助けとして，オントロジ定義に先行する文書型宣言(DOCTYPE)の中で実体定義の集合を提
供することが，有用なことが多い。名前空間宣言によって定義される名前は，XMLタグの一部としてだけ意味がある。
属性値は，名前空間の影響を受けない。しかし，OWLでは，属性値を使用して，オントロジ識別子を参照する場合が
多い。それらは，完全に展開された形式で書き下すことができる。"http://www.w3.org/TR/2004/REC-owl-guide20040210/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/RECowl-guide-20040210/wine#merlot"に展開される。
ささらに重要なのは，rdf:RDF名前空間宣言を単純化でき，その結果として，実体宣言への変更がオントロジを通じて
一貫して伝搬できる。
さらに，重要なのは， rdf:RDF名前空間宣言を単純化することにより，実体宣言への変更がオントロジを通じて一貫し
て伝搬できることであると考えられる。
<rdf:RDF
xmlns
="&vin;"
xmlns:vin ="&vin;"
xml:base ="&vin;"
-7-
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#">
2.2 オントロジヘッダ
一度名前空間が確立されると，通常は，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では，オントロジという用語は，インスタンスデータを含むように拡張された。(上を参照)。
rdf:about属性は，オントロジに名前又は参照を提供する。属性の値が""の場合，それが標準的な場合なのだが，オ
ントロジの名前は，owl:Ontology要素の基底URIとなる。典型的には，これは，オントロジを含む文書のURIになる。こ
の例外は，xml:baseを使用する文脈であって，その場合は，要素の基底URIを現文書のURI以外の何かに設定す
る。
rdfs:commentは，オントロジに注記をつけるために明らかに必要な機能を提供する。
owl:priorVersionは，オントロジと連携して動作する版管理システムのためのフックを提供することを意図した標準的
なタグとする。オントロジ版管理については，以下でさらに議論する。
owl:importsは，取込み方式の機構を提供する。owl:importsは，単一の引数を取り，その引数はは，rdf:resource
属性によって識別される。
他のオントロジの取込みによって，そのオントロジが提供する言明の集合全体を現在のオントロジにもち込む。この取
り込まれるオントロジを最も効果的に使用するために，通常，それを名前空間宣言と組み合わせる。これら二つの機
構の相違点に注意されたい。名前空間宣言は，他のOWLオントロジで定義された名前を参照するための便利な手段
を提供する。概念上は，owl:importsは，対象オントロジの言明を取り込むという意図を示すために提供される。他の
オントロジ，02を取り込むことによって，02が取り込むすべてのオントロジをも取り込むことになる。
owl:importsが常に成功するわけではない点に注意されたい。セマンティクウェブを扱う際には予期されることだが，
ウェブをまたがって分散された資源にアクセスすることが常に可能なわけではない。それに対するツールの反応は，実
装定義になる。
OWL語彙を使用するためには，owl.rdfオントロジを取り込む必要はないという点に注意されたい。実際，このような取
込みは勧められない。
取り込むことが妥当と思われる追加タグの一つの共通的な集合は，標準のDublin Coreメタデータの幾つかである。そ
の部分集合は，値として単純型又は文字列を取るものを取り込む。題(Title)，作成者(Creator)，記述(Description)，発
-8-
行者(Publisher)及び日付(Date)が，例として含まれる。RDF宣言を参照されたい。
注記として使用される特性は，owl:AnnotationPropertyを使用して宣言されることが望ましい。次に例を示す。
<owl:AnnotationProperty rdf:about="&dc;creator" />
OWLは，現在のオントロジ及び取り込まれたオントロジを一緒にして結合する機構を他にも幾つか提供する。オントロ
ジマッピングを参照されたい
該当するオントロジの自然言語のラベルをサポートするために，rdfs:labelも含む。
オントロジヘッダ定義は，次のタグで終了する。
</owl:Ontology>
この前書きとしての記述の次に，オントロジを構成する実際の定義が続き，最後は次で終了する。
</rdf:RDF>
2.3 データ集約及びプライバシ
複数の文書中に現れるインスタンス群のオントロジ情報を表現するOWLの機能は，様々な情報源からのデータの関
連付けを一貫した手法で支援する。予期しない結果を生じ得るこれらデータにおける推論を，基礎となる意味論は，提
供し支援する。特に，owl:sameAsを使用して等価性を表現する能力は，表面上異なる個物が実際には同一であると
示すために使用できる。Owl:InverseFunctionalPropertyも個物を互いに関係付けるために使用できる。例え
ば，"SocialSecurityNumber"といった特性がowl:InverseFunctionalPropertyである場合，その特性の値が同じであ
ることに基づき，二つの(一見は)別々の個物が同一であると推論することができる。個物がこれらの方法によって同一
と決定された場合，異なる情報源から得られたそれらに関する情報を併合することができる。この集約関係の使用を
通じて，一つの情報源からは直接的に表現されない事実を決定できる。
複数の情報源からの情報を関係付けるセマンティクウェブの機能は，多くのアプリケーションで使用できる望ましく強
力な特徴である。しかし，複数の情報源から得たデータをOWLの強力な推論機能を用いて併合する能力は，誤用さ
れる可能性をもつ。 OWLの利用者は，潜在的なプライバシの問題を含んでいることに注意することが望ましい。セキ
ュリティ問題の解決の詳細は，OWLの作業グループの活動の範囲外となっている。多くの組織が，セキュリティ及び個
人の好みに配慮した様々な解決を用いて，これらの問題に取り組んでいる。例えば，SAML及びP3Pを参照されたい。
-9-
[附属資料－A.3]
OWL Reference 第２章まで抜粋
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 機能一覧
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公
開後の実用新案登録願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録願にかかわる確認について，責任はもたない。
この標準仕様書(TS)には，次に示す附属書及び解説がある。
附属書1(参考) 貢献者
附属書A(参考) 全言語要素の索引
附属書B OWLのRDFスキーマ
附属書C OWLの簡単な/機能 [quick reference] 一覧
附属書D(参考) DAML+OILからの変更
附属書E OWL DLオントロジのための簡単な規則/経験則 [rules of thumb]
附属書F(参考) 勧告案からの変更記録
附属書G 文献
この版:
http://www.w3.org/TR/2004/REC-owl-ref-20040210/
最新の版:
http://www.w3.org/TR/owl-ref/
以前/直前の版:
http://www.w3.org/TR/2003/PR-owl-ref-20031215/
編者:
Mike Dean, BBN Technologies
Guus Schreiber, Free University Amsterdam
著者:
Sean Bechhofer, University of Manchester
Frank van Harmelen, Free University Amsterdam
Jim Hendler, University of Maryland
Ian Horrocks, University of Manchester
Deborah L. McGuinness, Stanford University
Peter F. Patel-Schneider, Bell Labs Research, Lucent Technologies
Lynn Andrea Stein, Franklin W. Olin College of Engineering
原規定については，正誤表を参照されたい。標準的/規定の [normative] な修正をいくつか含むことがあ
る。
翻訳版も参照されたい。
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3Cの免責, 商標, 文書使用及びソフ
トウェア使用許諾の規則を適用する。
-1-
原規定の状態
原規定は，W3Cのメンバ及び他の関係者によってレビューされ，W3C 勧告として，技術統括責任者によって承
認された。勧告作成において， W3Cは，原規定を広く知らせ，/広範に普及させる役割をもつ。これによっ
て，ウェブの機能性及び相互運用性が高まる。
これは，六部分から構成されるOWL，/即ちウェブオントロジ言語のW3C勧告のうちの一つである。これは，
2004年2月10日の公開に向け，ウェブオントロジ作業グループによって，W3C セマンティクウェブ活動 (活
動声明, グループ憲章)の一環として作成された。
これらの規定の初期の版で示されたOWLの設計は，広くレビューされ，作業グループの技術要件を満たしてい
る。作業グループは，受理されたすべてのコメントを検討し/に対し，必要に応じて/規定に変更している/を
行うことにより対応を行った。原規定の勧告案版からの変更の詳細については，変更記録を参照されたい。
コメントは，public-webont-comments@w3.org (アーカイブ)で受け付けている。関連技術については，wwwrdf-logic@w3.org ( アーカイブ)で議論されている。
実装のリストを入手することができる。
W3Cは，この作業に関するすべての特許の明細リストを管理する。
ここでは，公開時における原規定の状態を記述する。他の規定が原規定に取って代わることもある。現在の
W3C刊行物のリスト及びこの技術報告書の最新改訂版については，http://www.w3.org/TR/./(ドット削除)の
W3C技術報告書索引を参照されたい。
-2-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 機能一覧
目
次
まえがき
序文
0. 適用範囲
1. 導入
1.1 この規定の目的
1.2 OWL Full，OWL DL及びOWL Lite
1.3 OWL 構文
1.4 OWL 及び RDFセマンティクス/の意味論
1.5 A/ (削除) 例についての備考
1.6 データ/の集約及びプライバシ
1.7 この規定の附属書
2. OWL規定/の文書
2.1 内容
2.2 OWL URI 語彙及び名前空間 (原文でも、目次のタイトルと本文のタイトルが異なる。ど
ちらが正しいのか?)
2.3 MIME型
3. クラス
3.1 クラスの/記述
3.2 クラスの/公理
4. 特性
4.1 RDF スキーマ特性の構成要素(原文でも、目次のタイトルと本文のタイトルが異なる。
どちらが正しいのか?)
4.2 他の特性との関係
4.3 特性に関する大域的なメンバ数制限
4.4 特性の論理的特徴
5. 個物
5.1 クラスのメンバ関係/クラスへの帰属関係及び特性値
5.2 個物の識別性/自己同一性
6. データ型
6.1 RDF データ型
6.2 owl:oneOfを使用する列挙データ型(原文でも、目次のタイトルと本文のタイトルが異な
る。どちらが正しいのか?)
6.3 データ型の推論の支援
7. 注記，オントロジヘッダ，インポート/取り込み及び版情報
7.1 注記
7.2 オントロジヘッダ
7.3 オントロジのインポート/取り込み
7.4 版情報
8. OWL Full, OWL DL 及び OWL Lite
8.1 OWL Full
8.2 OWL DL
8.3 OWL Lite
附属書1(参考) 貢献者
附属書A(参考) 全言語要素の索引
附属書B OWLのRDFスキーマ
附属書C OWLの簡単な/機能 [quick reference] 一覧
-3-
附属書D(参考) DAML+OILからの変更
附属書E OWL DLオントロジのための簡単な規則/経験則 [rules of thumb]
附属書F(参考) 勧告案からの変更記録
附属書G 文献
解説
-4-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 機能一覧
OWL Web Ontology Language — Reference
序文
この標準仕様書(TS)は，2004年2月にWorld Wide Web Consortium (W3C)から公表されたWeb Ontology Language,
Overviewを翻訳し，技術的内容を変更することなく作成した標準仕様書(TS)である。
0. 適用範囲
ウェブオントロジ言語 OWLは，World Wide Web上のオントロジを公開し，共有するためのセマンティクマーク付け言
語である。OWLはRDF (資源記述の枠組み)/(Resource Description Framework (資源記述の枠組み)) の語彙拡張と
して開発され， DAML+OILウェブオントロジ言語から来た/派生したものである。この規定は，OWL言語構成要素の
完全集合の構造化された非公式/形式的な記述を含んでおり，OWLオントロジを構築したいOWLユーザのための参
照として提供されている/役立つことが意図されている。
1. 導入
1.1 この規定の目的
この規定は，OWLの RDF/XML交換構文を使用して，OWLのすべてのモデリングプリミティブ/モデル化基本要素に
ついて，系統的で，緻密/簡潔かつ有益な記述を提供する。この規定には，OWL言語のユーザのための機能一覧手
引きとしての役割が期待される。
この規定は，OWL，ウェブオントロジ言語に関する記述の一つの構成要素であり，W3Cオントロジ作業グループによ
って作成されている。/この規定は， W3Cオントロジ作業グループによって作成されているOWL即ちウェブオントロジ
言語に関する記述の一つの構成要素である。 (分詞のかかりはdocumentではなくOWL) OWL概要規定の規定一覧
には，多様な各部及びそれらがどのように互いに適合しているか/ まとまりをなしているか ([fit together] 成句) が記
述されている。OWL に不慣れな読者は，最初にOWL概要規定 [OWL Overview] を，次に，より談話的な/進んだ
([narrative] 口数の多い、細かく説明されているという程度の意味) 記述及び言語の使用例/本言語の使用法の説明
と例 (ofのかかりが面倒だがこれが自然と思う) を見るために，OWL手引き [OWL Guide] を参考にしたいと考えてもよ
い/するのがよい ([may wish] はJIS的にはそう訳すのかもしれないが...)。
この規定では，読者がRDFの基本概念[RDF Concepts] に精通し，RDF/XML構文 [RDF/XML Syntax] 及びRDFスキ
ーマ [RDF Vocabulary] の実用知識をもっていることを前提としている。
OWL言語構成要素の正確な構文に関する標準的な/規定の [normative] 参照は，OWLセマンティクス/意味論及び抽
象構文規定 [OWL S&AS] で入手できる。その規定も/はまた，モデル理論セマンティクス/モデル論的な意味論
[model-theoretic semantics] の形式で，言語構成要素の意味の正確な定義を含んでいる。OWLオントロジの一貫性
などの概念は，その規定で議論されている。
OWL言語の使用例及び要件は，OWL要件規定 [OWL Requirements] に記述されている。OWLツールのテストケー
ス，例えば, 論理的帰結テスト，一貫性テストなどは，テスト規定 [OWL Test Cases] で指定されている。
1.2 OWL Full，OWL DL及びOWL Lite
OWL概要規定 [OWL Overview], 次にOWL 手引き [OWL Guide] で/も議論されているとおり，OWL言語は，実装者及
び言語ユーザ/の利用者に有益であると思われる二つの固有な部分集合を提供する。OWL Liteは，簡単な実装，及
び，ユーザ/利用者に， OWLの使用で開始される関数的な/がOWLを使いはじめるときに役立つ機能の部分集合を
提供することを目的に，設計された。OWL DLは，既存の記述論理事業区分/が用いられてきた分野をサポート/支援
-5-
し，推論システムに関して，望ましい計算特性をもつ言語部分集合を提供するために設計された。OWL DLのDLとは
"記述論理" を表す。部分集合と区別するためにOWL Fullと呼ばれる完全なOWL言語が存在し，多くのデータベース
及び知識表示システムに有益だが，記述論理推論システムの制約に違反する機能を利用するために，OWL DLに課
している制約のいくつかを緩和する。/OWL DLに課している制約のいくつかを緩和する。これによって ([so as to] は
目的ではなく結果として解釈するほうがわかりやすい)、多くのデータベース及び知識表現 [knowledge
representation] システムに有益な機能が提供されるが，逆に記述論理推論機構の制約に違反してしまう。
備考 RDF規定が特にOWL DL又はOWL Liteへの帰属を目的に構築されていない場合は，一般にそれらはOWL
Fullに帰属することになる。/RDFの文書は、特にOWL DLやOWL Lite用に構成されているのでない限り、一般に
OWL Fullの形式に合致する (あるいは、「OWL Fullの文書でもある」)。 (cf. 1.4の註)
OWL Full及びOWL DLは，OWL言語構成要素の同一の集合をサポートする。両者の相違は，それらの機能を使用
する場合に，機能の一部に制限があるか， RDF機能の使用に制限があるかである。/それらの機能のいくつかを使用
する際及びRDFの機能を使用する際の制限の仕方にある。OWL Fullを使用することによって，OWLとRDFスキーマ
を自由に混和させることができる。RDFスキーマと同様，OWL Fullもクラス，特性，個物及びデータ値を厳密に分離す
ることを強制しない。OWL DLは，RDFとの混和に制約を課し，クラス，特性，個物及びデータ値の分離性/が互いに素
であること [disjointness] を要求する。OWL DL部分言語が存在する主な理由は，ツールビルダが開発してきた/ これ
までにソフトウェアツールとして開発されてきた (「ツール開発者が開発してきた」では変なので意訳) 強力な推論シス
テムが，OWL DLに要求される制限によって制約を受けるオントロジをサポート/支援するためである。OWL Fullと
OWL DLの相違を形式的に定義するために，読者は，セマンティク/意味論及び抽象構文規定[OWL S&AS] を参照さ
れたい。 8.2項/ 節 "OWL DL"では，OWL FullとOWL DLとの相違が要約されている。
OWL Liteは，OWL言語構成要素の部分集合をのみをサポートするOWL DLの部分言語である。OWL Liteは，特
に，/OWLをサポートしたいが，比較的単純な言語機能の基本集合から始めたいツールビルダ/ソフトウェアツールの
開発者 [tool builders] (「ツール」だけでは不親切と思うので「ソフトウェア」を補う) を/特に対象としている。OWL Lite
は OWL DLと同じセマンティク/意味論の制限を遵守し/するので (後の分詞を結果と読む)，推論エンジンが特定の/あ
る (certain) 望ましい特性を保証するのを可能にする。OWL Liteで使用できる言語構成要素は， 8.3/節で要約されて
いる。OWL LiteがサポートするOWL言語構成要素の部分集合をより形式的に記述するために，読者は，セマンティ
ク/意味論及び抽象構文規定 [OWL S&AS] を参照されたい。
備考 OWLに格上げするRDFユーザ/RDFの利用者がOWLに移行する [upgrade] 際には，OWL Liteが単にRDFス
キーマを拡張したものではないことを意識していることが望ましい。OWL Liteは OWL DLより手軽/の軽量版であり，
例えば/(ここのEMタグは不要。原文はラテン語をイタリックにするために用いられているだけなので。以下i.e.等も同
様) ，クラス，特性の分離性などのRDF語彙の使用に制約を課している。/RDF語彙の使用に制約を課している (例え
ばクラス、特性等が互いに素であること)。OWL Fullは，RDF/との互換性を最大限に引き出すことを目的に設計されて
いるため，RDFユーザは違和感無く/使い始めることができる。OWL DL又はOWL Liteのいずれかを選択する場合に
は， OWL及びRDFの構成要素を使用する際，推論システムなどの/支援のような (EMタグ不要) OWL DL/Liteの利
点が，OWL DL/Liteの制限より重要であるかどうかを考慮するのが望ましい。
備考 OWL Liteは，この規定で，OWL DLのいくつかの追加制限として定義されている。すなわち，別の方法で明示さ
れない場合は， OWL DLの構成要素もOWL Liteの一部である。 8.3 項/節では，これらのOWL Liteの追加制限を要
約している。
1.3 OWL構文
OWLオントロジは，RDFグラフ [RDF Concepts] であり，同様にRDFトリプル/の三つ組の集合である。あらゆるRDFグ
ラフと同様に，OWLオントロジグラフも，RDF/XML構文規定 (改訂版) [RDF/XML Syntax]) で記述されるとおり，多くの
異なる構文形式での書込み/書くことが可能である。現在の規定は，手引き規定の場合と同様，トリプル/三つ組を表
示/表現 [representing] するために， RDF/XMLの固有の構文形式をいくつか/ある特定の構文形式を [some specific
syntactic forms] 使用する。しかし，OWLオントロジの意味は， RDFグラフによってのみ決定される。したがって，これ
らが，結果として， RDFトリプル/の三つ組の同一の基本集合/基礎となるRDFトリプル/の三つ組の集合が同一となる
限り，他のRDF/XMLの構文形式を使用して差し支えない。こういった他の構文形式は，この規定で使用される構文形
式と全く同じ意味をもつことになる。
結果として同じRDFトリプル/の三つ組となる，代わりの構文形式の簡単な例として，次のRDF/XML構文を検討す
る。:/(こういうところのコロンは消す。以下同様)
<owl:Class rdf:ID="Continent"/>
-6-
次のRDF/XML構文を考慮する。:/(コロン)
<rdf:Description rdf:about="#Continent">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description>
上の構文は，RDFトリプル/の三つ組の同じ集合を符号化し，その結果，同じ意味をもつことになる。
1.4 OWL 及び RDFセマンティクス/の意味論
OWLはRDF [RDF Semantics] の語彙拡張である。したがって，いかなるRDFグラフもOWL Fullオントロジを形成する。
さらに，OWLがRDFグラフに提供した意味には，RDFが/そのグラフに提供した意味が含まれる。したがって，OWL
Fullオントロジは，任意のRDFのコンテンツ/内容 ([content] 単数) を含むことができ，/それは [which is] RDFによる取
扱いと一致した方法で，取扱われる。OWLは，/(削除) OWLは特定のRDFトリプル/の三つ組に追加的な意味を割り
当てる。OWLセマンティクス/意味論及び抽象構文規定[OWL S&AS] は，どのトリプル/三つ組が固有の/どんな
[specific] 意味を割り当てられており，それがどういう意味であるか /その意味が何であるかを厳密に指定する。
備考前に述べたとおり，OWL DL及びOWL Liteは， RDF語彙を拡張するが，同時に，この語彙の使用に制限も課
す。そのため， RDF規定が特にOWL DL又はOWL Liteに帰属することを目的に構成されない場合は，それらは，一
般に，OWL Fullに帰属することになる。/RDFの文書は、特にOWL DLやOWL Lite用に構成されているのでない限
り、一般にOWL Fullの形式に合致する (あるいは、「OWL Fullの文書でもある」)。(cf. 1.3の註)
1.5 例についての備考
可読性のため，この規定の例は，XML実体&rdf;, &rdfs;, &owl;及びXMLスキーマデータ型の&xsd;が附属書 Bと
同じ方法で定義されることを前提としている。対応する名前空間 rdf:, rdfs:, owl:及び xsd:についても同じ前提が成
立する。
この規定の例は，OWL言語構成要素の使用の例図として提供されることになる。それらは，一つの一貫したオントロ
ジを形成しない。拡張された例については，読者は，手引き規定 [OWL Guide] を参照されたい。
1.6 データ/の集約及びプライバシ
複数の文書に現れる個物について，オントロジ的情報を表現するOWLの能力は，理に適った/首尾一貫した
[principled] 方法で，様々なソース/情報源からのデータのリンク/を結合することをサポート/ 支援する。基本的なセマ
ンティクスより，予期しない結果を生じる可能性のあるこのデータについての推論をサポートする。/基礎にある意味論
は、このデータに関する推論を行うための機能を提供するが、これによって予期せぬ結果が生ずる可能性がある。
(thatのかかりはdataではなくsupport for inferences) 特に，owl:sameAs を用いた等価性を表現する能力を使用するこ
とにより，表面上は異なる個物が実際には同一であると明示/言明 [state] することができる。同様に，
owl:InverseFunctionalProperty を使用すれば，個物を互いにリンク/結合させることができる。例えば，
SocialSecurityNumber/ (社会保障番号) などの特性が owl:InverseFunctionalPropertyである場合，二つの別々
の個物は，/この特性の値が同じであることから，同一であると推論することができる。こういった方法で個物が同一で
あると決定する場合，異なるソース/情報源から得たそれらに関する情報を統合することができる。この集約を使用す
れば，どのソース/単一の情報源 [any one source]でも直接表示/表現 [represented] され/ていない事実を決定するこ
とができる。
複数のソース/情報源からの情報をリンク/結合するセマンティクウェブの能力は，多くのアプリケーションで使用できる
魅力的で有効/強力 [powerful] な機能である。しかし，複数のソース/情報源からのデータを統合する能力は，OWL
の推論力/能力 [inferential power] と組み合わされた場合，悪用される可能性をもつ/が実際にある ([does have] 強
調)。データ保護法のある国々，特にEUでは，こういった処理について，妥当で正当な/法的に有効な理由がなけれ
ば，(こういった)リンク/このような結合された情報の生成又は処理は違法でさえあるかもしれない。そのため，他のデ
ータソース/情報源又はオントロジとリンク/結合される可能性のあるあらゆる種類の個人データとともにOWLを使用す
る場合は，細心の注意を払うのが望ましい/わなければならない (この [should] は「望ましい」より強いと思う)。詳細な
機密保持は，作業グループ外で検討された。/安全性を確保するための詳細は、本作業グループの活動範囲を越える
とみなされた。現在，他で進行中の作業は，様々な機密及び優先権保持を理解して，これらの問題に取り組んでい
る。 /安全性確保や個人嗜好保護の問題をいろいろな方法で解決するために、様々な場所でこの問題に対する取り組
みが行われている。(直訳では苦しかったのでやや意訳) 例については，SAML 及びP3Pを参照されたい。
-7-
1.7 この規定の附属書
この規定には，追加情報を含む一連の附属書がある。
この規定では，言語構成要素の定義に添付されたリンクは，OWLセマンティク/意味論及び抽象構文 [OWL S&AS] へ
のアクセスを提供する。附属書 Aは，各言語構成要素について，手引き及び/並びに (上位のand) セマンティク/意味
論及び抽象構文規定の対応する項/節へ /の組織的な一連のリンクを提供する/含む。
附属書 Bには，OWL言語構成要素のためのRDFスキーマが含まれる。このスキーマは，オントロジビルダ/の開発者
及びツール/の開発者にとって有用な基準/参照 [reference] 点となり得るOWL語彙についての情報を提供する。OWL
クラス及び特性に関してスキーマが提供する制限は，/参考のものであり [informative]、かつ、完全なものではない。
また、このスキーマは、(原案の訳は一行飛ばしている。) OWL Full，OWL DL及びOWL Lite を区別しない。例えば，
月並みだが，/慣習的に [conventionally] クラス/名は大文字で始まり，特性/名は小文字で始まる。したがって，
owl:Ontologyはクラスであり，owl:imports は特性である。
備考 OWLのRDFスキーマファイルは，例えばowl:importsを用いるなど，明示的なオントロジへのインポートを期待
されない。/OWLのRDF Schemaのファイルは、あるオントロジに明示的に (つまりowl:importsを使って) 取り込まれ
ることは想定されていない。/このスキーマには情報を提供する状態が存在し，/は参考の状態 [informative status]
であり、RDF/XML構文で使用されるクラス及び特性を提供されることになっている/することを意図している。このスキ
ーマを/あえて (強調のdo) インポートする/ 取り込む人は、結果として得たオントロジをOWL Fullオントロジであると考
えるのが望ましい/なければならない (shouldだが、これは絶対そうなる) 。
附属書 C は，組込み式のOWL/OWLに組込みのクラス及び定義域と値域をもつ/(下に移動) 特性について，表を用
いて，OWL/の語彙の概要を示す。/特性については定義域と値域も示す。
DAML+OILに精通している読者のために, 附属書 D では，DAML+OILとOWLとの間の多くの変更点を列挙してい
る。
最後に, 附属書Eは，RDFでOWL DLオントロジを指定するための実用的な一連の/一連の実用的なガイドライン/手引
を提供している。
2. OWL規定/の文書 (この [document] はspecの意味ではない)
OWLの/で記述される情報は，オントロジの中/(削除)に集約されており/(削除)，World Wide Web/ワールドワイドウェ
ブの文書として保存することができる。OWLの一面であるオントロジのインポート/取り込みは，ウェブでOWLオントロ
ジを保存するための/(削除) この能力に依存する。/(この段落pタグが無かったので追加。原文でも抜けていた。)
2.1 内容
/ひとつのOWL規定/文書は，/一般にたかだか一つしかない任意のオントロジヘッダに加えて、多くの/任意の数のクラ
スの/公理, 特性の/公理, 及び個物に関する事実に加え，一般に多くて一つしかない任意のオントロジヘッダ/(上に移
動) から構成される。"公理" がセマンティク/ 意味論及び抽象構文規定で使用される公式/形式的な用語であることに
注意されたい。これらの公理は，手引き規定及び概要規定では，/いくらか非形式的に "定義" と呼ばれているが，これ
は若干非公式な呼び方である/(上に移動)。
備考 OWLはOWL構成要素に何の命令/順序も強制しない。オントロジを書く人間が/人がオントロジを書くのなら，オ
ントロジヘッダを冒頭に置くなど，何らかの種類の命令/順序付けを使用する可能性はあるが/ことになるだろうが，こ
れは意味には影響しない。/ソフトウェアツールは，命令を前提としないのが望ましい。/いかなる順序も想定しない。(こ
この [should not] は、(1) OWLジェネレーターが生成するコードはいかなる順序でもよい; (2) OWLパーサーは読み
取るコードにいかなる順序も想定してはいけない. の二つの意味があると思うので、端的に「しない」と訳してみまし
た。)
ほとんどのRDF文書に関しては/と同様に [as with] ，OWL/のコードは，rdf:RDF要素の部分要素であることが望まし
い/なければならない (ここも必須要件)。この囲み要素は，一般に，XML 名前空間及び基本宣言を保持する。同様に/
また，OWLオントロジ規定/の文書は，複数の実体宣言で始まることが多い。この種の情報の一般/典型的な例につい
ては，手引き規定 [OWL 手引き] で議論されているワイン及び食物オントロジの例を参照されたい。
-8-
2.2 OWL/の組込み語彙(原文でも、目次のタイトルと本文のタイトルが異なる。どちらが正しいのか?)
OWLの組込み語彙はすべて次のOWL名前空間から来ている。
http://www.w3.org/2002/07/owl#
これは，本来/慣習的に，名前空間名owlと関連付けされている。組込み語彙を除き，オントロジがこの名前空間から
の名前を使用しないことを推奨する。OWLツールビルダ/の開発者は，この名前空間から他の名前が使用される場
合，即座に/(削除)警告を発するのが望ましい/してもよいが，そうでない場合は，通常どおり，継続するのが望ましい。
([should feel free . . . should otherwise] なんてのは規格の文書としていかがなものか)
2.3 MIME型
Webオントロジ作業グループは，OWL規定/文書について，分離/ 個別のMIME型を要求してはいない。その代わり
に，RDFコア作業グループが要求するMIME型，すなわちapplication/rdf+xml [RDF Concepts], 又は，XML/の
MIME型 application/xmlの使用を推奨する。
ファイル拡張/子としては，.rdf又は .owlのいずれかの使用を推奨する。
3. クラス
クラスは，類似する特徴をもつ資源をグループ化するための抽象/化 ([abstraction mechanism] 「抽象機構」だと機構
が抽象的な感じがするので) 機構を提供する。RDF/のクラスと同様，すべてのOWLクラスは，クラス式/の外延 [class
extension] と呼ばれる個物の集合と関連付けされる。クラス式/の外延の中の個物は，/そのクラスのインスタンスと呼
ばれる。一つのクラスには，関連性はあるが，そのクラス式と同等ではない内包的な意味，すなわち基本概念が存在
する。 /クラスは内包的意味すなわち基礎となる概念を持つ。これはそのクラスの外延と関係してはいるが、同一のも
のではない。したがって，同じクラス式をもつ二つのクラスが異なるクラスとなる場合もある。/二つのクラスが、同じ外
延を持ちながらも、(「内包において異なるがゆえに、」と補いたい) 異なるクラスである場合もある。
この規定で，"個物のクラス.." などの表現を使用する場合，これは，"個物を含むクラス式を/外延としてもつクラス..." と
して読まれるのが望ましい/むこと (このshouldも絶対)。
備考 OWL Lite及びOWL DLでは，個物が同時にクラスではあることはあり得ない。すなわち，クラス及び個物は，特
性及びデータ値と同様に，/(下に移動) 分離/互いに素な定義域を形成する /(特性及びデータ値も含め、互いに素であ
る)。OWL Fullでは，RDFスキーマの自由/性が保証されている。したがって，クラスは別の(メタ) クラスのインスタンス
として動作/作用してもよい。
OWLクラスは，"クラスの/記述" により記述され，/る。クラス記述は (whichはclass descriptionsにかかる) "クラスの/公
理" に結合できる。最初にクラスの/記述を記述/説明 (「記述」が続くとくどいので) し，その後クラスの/公理を記述/説
明する。
-9-
[附属資料－A.4]
OWL Semantics and Abstract Syntax 第 2 章まで抜粋
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 意味論及び抽象構文
まえがき
この規定は，工業標準化法に基づいて，日本工業標準調査会の審議を経て，経済産業大臣が制定した標準仕
様書(TS)である。
この標準仕様書(TS)の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公
開後の実用新案登録願に抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査
会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後の実用新
案登録願にかかわる確認について，責任はもたない。
この標準仕様書(TS)には，次に示す附属書及び解説がある。
附属書A(参考)
附属書B(参考)
附属書C(参考)
附属書D(参考)
附属書E(参考)
附属書F 文献
証明
例
最終審議案からの変更
語彙の索引
貢献者
この版:
http://www.w3.org/TR/2004/REC-owl-semantics-20040210/
最新の版:
http://www.w3.org/TR/owl-semantics/
以前の版:
http://www.w3.org/TR/2003/CR-owl-semantics-20030818/
著者:
Peter F. Patel-Schneider, Bell Labs Research, Lucent Technologies
Patrick Hayes, IHMC, University of West Florida
Ian Horrocks, Department of Computer Science, University of Manchester
原規定については，正誤表を参照されたい。標準的な修正をいくつか含むことがある。
原規定の標準形式は，複合HTML文書である。
翻訳版も参照されたい。
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3Cの免責, 商標, 文書使用及びソフ
トウェア使用許諾の規則を適用する。
原規定の状態
この項では，公開時における原規定の状態を記述する。他の規定が原規定に取って代わることもある。現在
のW3C刊行物のリスト及びこの技術報告書の最新改訂版については， W3C technical reports index
http://www.w3.org/TR/のW3C技術報告書索引を参照されたい。
-1-
これは，六部分から構成されるOWL，ウェブオントロジ言語のW3C 勧告うちの一つである。これは，2004年2
月10日の公開に向け，ウェブオントロジ作業グループによって，W3Cセマンティクウェブ活動 (活動声明, グ
ループ憲章)の一環として作成された。
これらの規定の初期の版で示されれたOWLの設計は，広くレビューされ，作業グループの技術要件を満たして
いる。作業グループは，受理されたすべてのコメントを検討し，必要に応じて変更している。原規定の勧告
案版以降の変更の詳細については，変更記録を参照されたい。
原規定は，W3Cのメンバ及び他の関係者によってレビューされ，W3C勧告として技術統括責任者によって承認
された。原規定は安定したものであって，参考資料として使用してよく，他の文書から標準参照として引用
してもよい。勧告作成において，W3Cは，原規定を広く知らせ，普及させる役割をもつ。これによってウェブ
の機能性及び相互運用性が高まる。
コメントはpublic-webont-comments@w3.org (アーカイブ)で受け付けている。関連技術についてはwww-rdflogic@w3.org (アーカイブ)で議論されている。
実装のリストを入手することができる。
W3Cは，この作業に関するすべての特許の明細リストを管理する。
-2-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 意味論及び抽象構文
目
次
まえがき
序文
0. 適用範囲
1. 導入
2. 抽象構文
2.1 オントロジ
2.2 事実
2.3 公理
3. 直接モデル理論セマンティクス
3.1 語彙及び解釈
3.2 組込み構成要素の解釈
3.3 公理及び事実の解釈
3.4 オントロジの解釈
4. RDFグラフへの対応付け
4.1 RDFグラフへの翻訳
4.2 RDFグラフ形式におけるOWL DL及びOWL Liteオントロジの定義
5. RDF互換性モデル理論セマンティクス
5.1 OWL及びRDFの世界
5.2 OWL解釈
5.3 OWL Full
5.4 OWL DL
附属書A(参考) 証明
A.1 抽象構文とOWL DLとの対応
A.2 OWL DLとOWL Fullとの対応
附属書B(参考) 例
B.1 抽象構文からRDFグラフへの対応付けの例
B.2 OWL DL及びOWL Fullにおける含意の例
附属書C(参考) 最終審議案からの変更
C.1 最終審議案後の重要な変更
C.2 最終審議案後の編集上の変更
C.3 勧告候補後の重要な変更
C.4 勧告候補後の編集上の変更
C.5 勧告案からの変更
附属書D(参考) 語彙の索引
附属書E(参考) 貢献者
附属書F 文献
F.1 引用規定
F.2(参考) 参考文献
解説
-3-
標準仕様書(TS) TS X 0xxx:2005
OWL ウェブオントロジ言語 — 意味論及び抽象構文
OWL Web Ontology Language — Semantics and Abstract Syntax
序文
この標準仕様書(TS)は，2004年2月にWorld Wide Web Consortium (W3C)から公表されたWeb Ontology Language,
Overviewを翻訳し，技術的内容を変更することなく作成した標準仕様書(TS)である。
0. 適用範囲
この規定は，W3Cウェブオントロジ作業グループが設計したOWL，ウェブオントロジ言語ついて，OWLの言語サブセッ
トであるOWL DL及びOWL Liteの両方に対し，高レベルの抽象構文を記述する。モデル理論セマンティクスは，この
抽象構文で書かれたOWLオントロジに形式的な意味を与えるために提供される。 RDFセマンティクスに拡張する形式
のモデル理論セマンティクスも，RDFグラフとしてのOWLオントロジ(OWL Full)に形式的な意味を与えるために提供さ
れる。抽象構文からRDFグラフへの対応付けが提供されると，抽象構文での書込みが可能なOWLオントロジでは，二
つのモデル理論の結果は同一となることがわかる。
1. 導入
この規定は，OWL，ウェブオントロジ言語の規定の一部である。 OWL概要 [OWL Overview]は，規定の中の様々な規
定をそれぞれ紹介し，それらが互いにどのように適応するかを記述している。
この規定は，W3C ウェブオントロジ作業グループ (WebOnt)が作成したOWL，ウェブオントロジ言語の複数のスタイル
のうち，いくつかの相互に関連する標準規定を記述する。最初に，2項では， OWLのサブセットであるOWL Lite，及
び，OWLを使用する上で，Liteよりは完全なスタイルをもつが，OWLオントロジの構成方法にまだいくつか制限が存在
するOWL DLの両方に対し，高レベルの抽象構文を記述する。これらの制限を取り除いた結果，OWL Fullと呼ばれる
OWLの完全言語が生まれた。これはRDFと同じ構文をもつ。標準的なOWLの交換構文は，RDF/XML [RDF Syntax]
である。 OWL機能一覧規定[OWL Reference]では，RDF構文をOWLでどのように使用するかを記述している。しか
し，OWL抽象構文からRDFグラフ [RDF Concepts]への対応付けは，4項で解説する。
この規定は，OWLの二つの形式的なセマンティクスを提供する。これらのセマンティクスのうち，一つは3項で定義され
ており，抽象構文で書かれたOWLオントロジの直接的で，基準的なモデル理論セマンティクスである。もう一つは，5項
で定義されており，RDFグラフの形式で，セマンティクスをOWLオントロジに提供するRDFセマンティクス[RDF
Semantics]の語彙外延である。この二つめのセマンティクスの版は二つ提供されている。一つは，直接セマンティクス
にさらに厳密に対応していることから，OWL DLのセマンティクスであり，もう一つは，クラスを個物として取扱う必要が
ある場合，又は，抽象構文で扱うことができないその他の状況の場合に使用可能であることから，OWL Fullのセマン
ティクスである。これらの二つの版は，実際に非常に緊密であり，談話の領域の分け方だけが異なる。
附属書Aでは，直接及びRDFS互換性セマンティクスが，OWL個物，OWLクラス，OWL特性，RDF，RDFS，及びOWL
構造語彙を区別する抽象OWLオントロジに対応するOWLオントロジにおいては，同じ結果をもたらすことを立証する。
附属書 Aでは，さらに，OWL FullのRDFS互換性セマンティクスの含意には，OWL DLのRDFS互換性セマンティクス
のすべての含意が取り込まれることを概略的に立証する。最後に，規定で定義された様々な概念の例を附属書 Bで
いくつか示す。
この規定は，OWLの技術的詳細に興味をもつ人間が読むことを念頭においている。特に，OWLの知識をもたない読
者を意図したものではない。そういった読者は，まず，OWL手引き[OWL Guide]を読むことが望ましい。 OWLの構文
解析プログラム及びその他の構文ツールの開発者は，特に2項及び4項に興味をもつと思われる。 OWLの推論機構
及びその他のセマンティクツールの開発者は，特に，3項及び5項に興味をもつと思われる。
-4-
2. 抽象構文
この項に記述するOWLの抽象構文は，OWLの交換構文から抜粋したものであるため，アクセス及び言語の評価が容
易である。この特定の構文は枠組みに似たスタイルをもち，そこでは，クラス又は特性に関する情報のコレクションを，
ほとんどの論理記述と同様に，相当数の原子レベルの塊に分割するか，又は， RDFグラフ [RDF Concepts]として
OWLを書く場合と同様に，さらに多くの三つ組に分割する代わりに，一つの大きな構文の構成要素で提供する。ここで
使用される構文は，抽象構文の場合でさえ，多少非公形式的である。一般に，ある構成要素の引数は，順序がその
構成要素の意味に影響しない場合はいつでも，順序付け不能であると考えられるのが望ましい。
抽象構文は，ここでは，拡張BNFの版によって指定される。これは，XML[XML]に使用されるEBNF記法に酷似する。
終端は引用符で囲まれる。終端以外は太字となり，引用符で囲まれることはない。代替部分は，縦線で区切られる
か，又は，別の生成で提供される。多くて一度出現できる構成要素は，角括弧で囲まれる。全く出現しない場合を含
み，何度も出現できる構成要素は，中括弧で囲まれる。ここでは，生成において，空白は無視される。
抽象構文の中の名前は，RDF URI参照, [RDF Concepts]である。これらの名前は，多くの場合，次の名前空間のうち
の一つを使用して，修飾名に略記されることになる。:
名前空間の名前
名前空間
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
xsd
http://www.w3.org/2001/XMLSchema#
owl
http://www.w3.org/2002/07/owl#
抽象構文の各構成要素の意味は，導入の際に，非形式に記述される。これらの構成要素の形式的な意味は，モデル
理論セマンティクスを介して，3項で提供される。
何人かのユーザにとっては，OWLなどの表現言語の中のすべての機能が重要であるということが広く知られている
が，こういった言語が，言語全体のツールスイートのサポートを試みるグループの気力を削いでいることもわかってい
る。より簡単な目標を実装に提供するために，OWL Lite [OWL Overview]と呼ばれる，より小規模の言語が定義され
た。このより小規模の言語は，ウェブアプリケーションをサポートするために重要であるが，RDFスキーマ[RDF
Schema]には欠落している機能性を提供するために，設計された。しかし，OWL DLもOWL LiteもRDFスキーマのすべ
ての機能を提供するわけではないことに注意されたい。抽象構文は，OWL Lite抽象構文と呼ばれる，このより小規模
の言語に対しても，OWL DL抽象構文と呼ばれる，OWLのより完全なスタイルに対しても表現される。
ここでの抽象構文は，OWLの交換構文ほど一般的ではない。特に，自己指示の構文構成要素の構造では使用はで
きない。クラス，特性及び個物が互いに素なコレクションを形成する場合の使用も意図されている。これらは，OWLの
推論を決定可能にするために必須となる制限である。したがって，この抽象構文は，OWL DLの構文と考えるのが望
ましい。
注: OWL Lite及びOWL DLは，SHIF(D)及びSHION(D)として知られる記述論理に厳密に対応しており，データ型の取
扱い方法に何らかの制限が存在する。 OWL Liteの抽象構文は，SHIF(D)と関連付けされる共通の明示的な構成体
を多く含まないが，その表現性に変わりはない。
2.1 オントロジ
抽象構文におけるOWLオントロジには，注記,公理及び事実のシーケンスが含まれる。 OWLオントロジは名前をもつ
ことができる。 OWLオントロジの注記を使用すると，出所及びオントロジと関連付けされる他の情報を記録し，参照を
他のオントロジへ取り込むことができる。 OWLオントロジの主な内容はその公理及び事実に伝えられ，そのオントロジ
のクラス，特性及び個物に関する情報が提供される。
ontology ::= 'Ontology(' [ ontologyID ] { directive } ')'
directive ::= 'Annotation(' ontologyPropertyID ontologyID ')'
| 'Annotation(' annotationPropertyID URIreference ')'
| 'Annotation(' annotationPropertyID dataLiteral ')'
| 'Annotation(' annotationPropertyID individual ')'
-5-
| axiom
| fact
オントロジの名前を抽象構文で使用することにより，ウェブ上のオントロジの公開に関連付けられる意味を伝える。し
たがって，抽象構文中のオントロジの名前は，意図的に，それを入手できるURIとなっている。ただし，これはOWLの
形式的な意味の一部ではない。取込み注記は，事実上，ウェブ文書を検索し，それをオントロジとして扱うための指示
文である。しかし，文書が欠落していたり，入手不能であったり，時間に依存するなど，ウェブのほとんどの局面は，
OWL規定の範囲外にある。すなわち，ここに記述されていることは，URIをOWLオントロジに参照解除できるというこ
と以外にない。そのため，この規定の複数の箇所で，この取込みの演算上の意味を理想化して使用している。
オントロジは，クラス，特性及び個物に関する情報を組込んでいる。それらは各々URI参照である識別子をもつことが
できる。これらの識別子のうちのいくつかは，公理を提供される。詳細については，2.3項を参照されたい。
datatypeID ::= URIreference
classID ::= URIreference
individualID ::= URIreference
ontologyID ::= URIreference
datavaluedPropertyID ::= URIreference
individualvaluedPropertyID ::= URIreference
annotationPropertyID ::= URIreference
ontologyPropertyID ::= URIreference
URI参照は，オントロジのdatatypeIDとなることもclassIDとなることもできない。同様に，URI参照は，オントロジの
datavaluedPropertyID, individualvaluedPropertyID, annotationPropertyID, 又は ontologyPropertyIDのうち，いずれか一
つにしかなることはできない。しかし，オントロジをOWL DL RDFグラフに変換することはできないが，URI参照は，個
物の識別子，特性の識別子ばかりでなく，クラス又はデータ型の識別子となることができる。
OWLでは，データ型は，そのデータ型の値空間であるデータ値の集合を示す。クラスは個物の集合を示す。特性は個
物を他の情報に関連付け，四個の互いに素なグループ，すなわち，データ値特性，個物値特性，注記特性及びオント
ロジ特性に分けられる。データ値特性は，個物をデータ値に関連付ける。個物値特性は，個物を他の個物に関連付け
る。注記特性は，個物，クラス名，特性名及びオントロジ名に注記を付けるために使用される。オントロジ特性は，オン
トロジを他のオントロジに関連付ける。特に，この特性は他のオントロジから情報を取り込むために使用される。個物
識別子は，資源を参照するために使用され，データリテラルはデータ値を参照するために使用される。
OWLには，二つの組込み式のクラスが存在し，それらは両者とも，OWL名前空間のURI参照，すなわち，
http://www.w3.org/2002/07/owl#で始まる名前を使用する。ここではOWLの組込みクラスに対して，名前空間名owlを
使用する。この規定を通して，修飾名は，URI参照の省略形として使用されることになる。識別子owl:Thingをもつクラ
スは，すべての個物のクラスである。識別子owl:Nothingをもつクラスは，空のクラスである。どちらのクラスもOWL
Liteの一部である。
次のXMLスキーマデータ型[XML Schema Datatypes]は，データ型，http://www.w3.org/2001/XMLSchema#nameに関
するXMLスキーマの規範的なURI参照によって，組込みデータ型としてOWLでの使用が可能となる。この場合の名前
はデータ型の局所名である。: xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time,
xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary,
xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer,
xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger,
xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte 及び xsd:positiveInteger。他の組込みXML
スキーマデータ型は，OWLにとって問題があるものである。これについては，RDFセマンティクスの5.1項 [RDF
Semantics]で議論されている。組込みRDFデータ型, rdf:XMLLiteralもOWLの組込みデータ型である。XMLスキーマ
では，URI参照からXMLスキーマデータ型に移動する標準的な方法がないため，OWLでは，ユーザ定義のXMLスキ
ーマデータ型を使用するための標準的な方法は存在しない。
OWLでは，組込み注記特性が複数存在する。すなわち， owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso, 及び
rdfs:isDefinedByである。 RDFにおけるそれらの定義との調和を保つために，rdfs:label及びrdfs:commentは，データリ
テラルとともに使用されるのみである。
組込みオントロジ特性も複数存在する。すなわち， owl:imports, owl:priorVersion, owl:backwardCompatibleWith, 及び
-6-
owl:incompatibleWithである。 owl:importsを使用するオントロジ注記には，目標のオントロジをインポートする特別な
効果がある。
OWL構成要素の多くは，注記を使用するが，注記指示文と同様，それらは，構成要素のある部分と関連付けされる
情報を記録するために使用される。
annotation ::= 'annotation(' annotationPropertyID URIreference ')'
| 'annotation(' annotationPropertyID dataLiteral ')'
| 'annotation(' annotationPropertyID individual ')'
2.2 事実
OWL抽象構文では，二種類の事実が存在する。
一種類目の事実は，個物がその個物の正の特性及び値に属するクラスの形式で，特定の個物に関する情報を明示
する。個物は，その個物を意味することになるindividualIDを提供され，その個物を参照するために使用できる。しか
し，個物に，individualIDを提供する必要はない。こういった個物は匿名(RDF用語の空白)であり，直接，他の場所を
参照することができない。ここの構文は，rdf:nodeIDを使用しなくとも，RDF/XML構文[RDF Syntax]にいくらか類似する
ものとして構成されている。
fact ::= individual
individual ::= 'Individual(' [ individualID ] { annotation } { 'type(' type ')' } { value } ')'
value ::= 'value(' individualvaluedPropertyID individualID ')'
| 'value(' individualvaluedPropertyID individual ')'
| 'value(' datavaluedPropertyID dataLiteral ')'
事実は，OWL Lite及びOWL DL抽象構文では同じであるが，型となれるものだけが異なる。 OWL Liteでは，型とな
れるのはクラスID又はOWL Lite制限である。 2.3.1.2項を参照されたい。
type ::= classID
| restriction
OWL DL抽象構文では，型となれるのは，一般的な記述であり，これには，他の構成要素と同様に，クラスID及び
OWL Lite制限が含まれる。
type ::= description
抽象構文のデータリテラルは，普通リテラルか型付きリテラルのいずれかである。普通リテラルは，RDF 普通リテラル
[RDF Concepts]の場合と同様，Normal Form CのUnicode文字列及び任意の言語タグから構成される。型付きリテラル
は，RDF 型付きリテラル [RDF Concepts]の場合と同様，字句表現及びURI参照から構成される。
dataLiteral ::= typedLiteral | plainLiteral
typedLiteral ::= lexicalForm^^URIreference
plainLiteral ::= lexicalForm | lexicalForm@languageTag
lexicalForm ::= as in RDF, a unicode string in normal form C
languageTag ::= as in RDF, an XML language tag
二種類目の事実は，個物識別子を同一又は対で識別可能とするために使用される。
fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
| 'DifferentIndividuals(' individualID individualID {individualID} ')'
2.3 公理
OWL Lite抽象構文とOWL DL抽象構文の最も大きな相違は，公理に現れる。公理は，クラス及び特性に関する情報
を提供するために使用される。 OWL LiteはDLに比べ小規模な言語であるため，最初に，2.3.1項で，OWL Liteの公
理を解説する。 OWL DL公理は，2.3.2項で解説する。OWL DL公理は，特殊な例として，OWL Lite公理を取り込む。
-7-
公理を使用することにより，クラス及び特性の識別子を，それらの特徴の部分規定又は完全規定のいずれかと関連
付け，クラス及び特性に関する他の情報を提供することができる。公理は定義と呼ばれていたが，用語の常識では，
すべてが定義ではないため，より当り障りのない名前が選択された。
ここで使用される構文は，いくつかの枠機構で使用される構文といくらか類似させている。 OWL Liteの各クラス公理
は，より一般的なクラスのコレクション，及び，制限構成要素の形式で，局所的な特性制限のコレクションを含む。制限
構成要素は，特性の局所範囲，どのくらいの数の値を使用できるか，及び/又は，要求値のコレクションを提供する。ク
ラスは，等価になるか，又は，これらのより一般的なクラス及び制限の共通部分の部分集合になるかのいずれかであ
る。 OWL DL抽象構文では，クラスの公理は，記述のコレクションを含む。このコレクションは，より一般的なクラス，制
限，個物の集合，及び記述のブール結合となることができる。クラスは，列挙によっても指定できる。そうでなければ，
等価になるか又は互いに素になる。
特性を，等価とするか，又は，他の特性の下位特性とすることができる。すなわち，関数特性，逆関数特性，対称特
性，又は推移特性とすることができ，大域的な定義域及び値域を提供する。しかし，特性に関するほとんどの情報は，
より自然に制限の中で表現され，それにより，局所範囲及びメンバ数情報を指定することができる。
クラスID又はデータ型IDとして使用されるURI参照は，区別されなければならない。そのため，組込みOWL クラス，デ
ータ型及びrdfs:Literalを除き，公理を必要とする。クラス又はデータ型には公理が一つ以上存在することもある。抽象
構文オントロジで使用される特性は，データ値特性，個物値特性又は注記特性のいずれかとして分類されなければな
らない。このため，特性も，少なくとも一つの公理を必要とする。オントロジが別のオントロジを取り込む場合，これらの
目的のために，取り込まれたオントロジ及びそれが取り込むあらゆるオントロジなどに存在する公理を使用することが
できる。
2.3.1 OWL Liteの公理
2.3.1.1. OWL Lite クラスの公理
OWL Liteでは，クラスの公理を使用して，クラスが，完全様式，又は下位クラスの場合，部分様式の場合，最上位クラ
スのコレクションの結合及びOWL Lite 制限に対して，全く等価となることを明示する。クラスの使用が非推奨であるこ
とを示すこともできる。
axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { super } ')'
modality ::= 'complete' | 'partial'
super ::= classID | restriction
OWL Liteでは，二つ以上のクラスが等価であると明示することができる。
axiom ::= 'EquivalentClasses(' classID classID { classID } ')'
データ型公理はさらに簡単であり，データ型IDが一つのデータ型のIDであることを示し，データ型の注記を与えるため
に役立つにすぎない。
axiom ::= 'Datatype(' datatypeID ['Deprecated']
{ annotation } )'
2.3.1.2. OWL Liteの制限
OWL Liteのクラスの公理では，制限を使用して，クラスの特性に局所的な制約を課す。制約のallValuesFrom部分は，
各々，クラスの個物に対する特性のすべての値が指定されたクラス又はデータ型に属さなければならないという制約
を課す。 someValuesFrom部分は，各々，指定されたクラス又はデータ型に属する特性には，少なくとも値が一つ存在
しなければならないという制約を課す。メンバ数部分は，クラスの各個物に対する特性について，どのくらい多くの異
なる値が存在するかを示す。 OWL Liteでは，メンバ数に使用できるのは，0及び1に限られる。
どの特性が制限の中にメンバ数の部分をもつことができるかに関する制限については，2.3.1.3項を参照されたい。
restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent ')'
| 'restriction(' individualvaluedPropertyID individualRestrictionComponent ')'
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
-8-
| 'someValuesFrom(' dataRange ')'
| cardinality
individualRestrictionComponent ::= 'allValuesFrom(' classID ')'
| 'someValuesFrom(' classID ')'
| cardinality
cardinality ::= 'minCardinality(0)' | 'minCardinality(1)'
| 'maxCardinality(0)' | 'maxCardinality(1)'
| 'cardinality(0)'
| 'cardinality(1)'
2.3.1.3. OWL Lite 特性の公理
特性も，枠組みに類似した構文を使用して指定される。データ値特性は，個物を整数などのデータ値に関連付ける。
個物値特性は個物を他の個物に関連付ける。これらの二種類の特性を最上位特性に提供することができ，特性階層
の構造の使用が可能となる。個物値特性をデータ値特性の最上位特性にしたり，又は，その逆の行為は道理に合わ
ない。データ値特性及び個物値特性を，定義域及び値域に提供することもできる。特性の定義域は，RDFSの場合と
同様に，どの個物が特性を述部としてもつ文の潜在的な主語であるかを指定する。 OWL Liteでは，特性の定義域は
クラスである。すべての定義域に属する個物のみが潜在的な主語となる場合は，複数の定義域の存在が可能であ
る。特性の値域は，どの個物又はデータ値が，特性を述部としてもつ文の目的語となり得るかを指定する。ここでもま
た，すべての値域に属する個物又はデータ値のみが潜在的な目的語となる場合は，複数の値域の存在が可能であ
る。 OWL Liteでは，個物値特性の値域はクラスであり，データ値特性の値域はデータ型である。
データ値特性を(部分)関数として指定することができる。すなわち，個物を考えれば，特性においては，その個物のデ
ータ値との関係は多くて一つとすることができる。個物値特性を別の特性の逆特性に指定することができる。部分関数
特性，部分逆関数特性，又は推移特性と同様に，個物値特性を対称特性に指定することもできる。
OWL Liteでは，推論の決定可能性を維持するために，すべての特性がそれらに課されたメンバ数の制限をもつことが
できるわけではない，又は，関数特性又は逆関数特性として指定はできるわけではない。個物値特性は， 1/ 関数特
性又は逆関数特性として指定される場合， 2/ それを使用するあるメンバ数の制限が存在する場合， 3/ 複合的な逆特
性をもつ場合，又は， 4/ 複合的である最上位特性をもつ場合は，複合的となる。複合特性を推移特性として指定する
ことはできない。
注記特性及びオントロジ特性は，データ値特性及び個物値特性よりもさらに単純である。それらに関する公理の中の
情報が注記となるにすぎない。
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' datavaluedPropertyID ')' } ['Functional']
{ 'domain(' classID' ')' } { 'range(' dataRange ')' } ')'
| 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' individualvaluedPropertyID ')' }
[ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitiv
{ 'domain(' classID ')' } { 'range(' classID ')' } ')'
| 'AnnotationProperty(' annotationPropertyID { annotation } ')'
| 'OntologyProperty(' ontologyPropertyID { annotation } ')'
dataRange ::= datatypeID | 'rdfs:Literal'
次の公理は，複数の特性を等価にするか，又は，一つの特性を別の特性の下位特性とする。
axiom ::=
|
|
|
'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID { datavaluedPropertyI
'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID { individ
'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'
2.3.2 OWL DLの公理
2.3.2.1. OWL DL クラスの公理
OWL DL抽象構文には，OWL Liteのクラス公理のより一般的な版が存在し，そこでは，これらの最上位クラス，より一
般的な制限，及びブール結合を使用できる。同時に，これらの構成要素を記述と呼ぶ。
-9-
axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { description } ')'
modality ::= 'complete' | 'partial'
OWL DL 抽象構文では，クラスを厳密に一定の個物の集合から構成させることも可能である。次に例を示す。
axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')'
最後に，OWL DL抽象構文では，記述のコレクションが対で互いに素となるか，同じインスタンスをもつか，又はある記
述が別の記述の下位クラスであることを必須とすることが可能である。これらの公理のうち，最後の二つは，注記が欠
落している場合を除き，上の一種類目のクラス公理を一般化する点に注意されたい。
axiom ::= 'DisjointClasses(' description description { description } ')'
| 'EquivalentClasses(' description { description } ')'
| 'SubClassOf(' description description ')'
OWL DLでは，EquivalentClasses構成要素の中の記述を一つだけもつことができる。これにより，オントロジは，何かに
結合されない記述を取り込むことができる。これは，意味論上有用ではないが，最適とはいえないオントロジの編集を
考慮に入れたものである。
データ型公理は，OWL Liteの場合と同様である。
axiom ::= 'Datatype(' datatypeID ['Deprecated']
{ annotation } )'
2.3.2.2. OWL DLの記述
OWL DL抽象構文の記述は，クラス識別子及び制限を取り込む。記述は，他の記述のブール結合，及び個物の集合
となることも可能である。
description ::= classID
| restriction
| 'unionOf(' { description } ')'
| 'intersectionOf(' { description } ')'
| 'complementOf(' description ')'
| 'oneOf(' { individualID } ')'
2.3.2.3. OWL DLの制限
OWL DL抽象構文の制限は，クラスがOWL Liteで使用できる記述を使用可能にしたり，データ型と同様，データ値の
集合を使用可能にすることによって，OWL Liteの制限を一般化する。データ型とデータ値の集合の組合せをデータ域
と呼ぶ。 OWL DL抽象構文では，クラスの特性について値を提供することもできる。さらに，メンバ数が，0及び1だけ
に制限されることはない。
restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent { dataRestrictionComp
| 'restriction(' individualvaluedPropertyID individualRestrictionComponent { individua
dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')'
| 'someValuesFrom(' dataRange ')'
| 'value(' dataLiteral ')'
| cardinality
individualRestrictionComponent ::= 'allValuesFrom(' description ')'
| 'someValuesFrom(' description ')'
| 'value(' individualID ')'
| cardinality
cardinality ::= 'minCardinality(' non-negative-integer ')'
| 'maxCardinality(' non-negative-integer ')'
| 'cardinality(' non-negative-integer ')'
データ値特性の値域として，及び，OWL DL抽象構文の他の場所で使用されるデータ域は，データ型であるか，デー
タ値の集合であるかのいずれかである。
-10-
dataRange ::= datatypeID | 'rdfs:Literal'
| 'oneOf(' { dataLiteral } ')'
特性がそれらの制限内でメンバ数の構成要素をもつことができるOWL Liteの制限は，OWL DLにも存在する。
2.3.2.4. OWL DL 特性の公理
OWL DL抽象構文の特性の公理は，クラスの代わりに記述を，定義域及び値域のデータ型の代わりにデータ域を使
用可能とすることによって，OWL Liteの特性の公理を一般化する。
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' datavaluedPropertyID ')'} ['Functional']
{ 'domain(' description ')' } { 'range(' dataRange ')' } ')'
| 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation }
{ 'super(' individualvaluedPropertyID ')' }
[ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ]
[ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transit
{ 'domain(' description ')' } { 'range(' description ')' } ')'
| 'AnnotationProperty(' annotationPropertyID { annotation } ')'
| 'OntologyProperty(' ontologyPropertyID { annotation } ')'
特性を関数的又は逆関数的に指定できる制限は，OWL DLにも存在する。
OWL Liteの場合と同様に，次の公理は，複数の特性を等価にするか，又は，ある特性を別の特性の下位特性とす
る。
axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID { datavaluedPropertyI
| 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
| 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID
{ individualvaluedPropertyID } ')'
| 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'
-11-
[附属資料－A.5]
TS X 0091:2005
まえがき
この標準仕様書（TS）は，財団法人日本規格協会（JSA)から，原案を具して標準仕様書（TS）を公表
（タ
すべきとの申出があり，日本工業標準調査会の審議を経て，経済産業大臣が公表した標準仕様書（TS）
イプⅡ）である。
この標準仕様書（TS）の一部が，技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は
出願公開後の実用新案登録出願に抵触する可能性があることに注意を喚起する。主務大臣及び日本工業標
準調査会は，このような技術的性質をもつ特許権，出願公開後の特許出願，実用新案権，又は出願公開後
の実用新案登録出願にかかわる確認について，責任はもたない。
この標準仕様書（TS）には，次の附属書及び解説が添付されている。
附属書 A（参考）例
（1）
-1-
TS X 0091:2005
目次
ページ
序文························································································································································································ 1
1.
適用範囲········································································································································································ 1
2.
引用規定········································································································································································ 1
3.
定義 ················································································································································································ 2
3.1
基本操作······································································································································································ 2
3.2
クライアント······························································································································································ 2
3.3
サーバ ·········································································································································································· 2
4.
SRW 1.1 の概要 ···························································································································································· 2
4.1
基本操作······································································································································································ 2
4.2
searchRetrieve 操作··················································································································································· 2
4.3
CQL·············································································································································································· 3
4.4
SRU ·············································································································································································· 4
5.
画像検索機能································································································································································ 4
5.1
機能の要件·································································································································································· 4
5.2
名前空間······································································································································································ 4
5.3
CQL·············································································································································································· 4
5.4
XML スキーマ ··························································································································································· 5
6.
画像検索機能の処理 ··················································································································································· 6
7.
SRU の使用··································································································································································· 6
附属書 A（参考）例··························································································································································· 7
解
説 ·················································································································································································10
（2）
-2-
標準仕様書（TS）
TS
X 0091：2005
XML 化情報検索プロトコル－画像検索機能
XML-based Information Retrieval Protocol - Query by image
序文
この標準仕様書（TS）は，2003 年度及び 2004 年度における日本規格協会／情報技術標準化研究セ
ンター／将来型文書統合システム調査研究委員会の調査研究をもとに工業標準化の促進に関連して特に重
要と判断される技術情報をまとめ，標準仕様書（TS）
（タイプⅡ）として公表するものである。
1.
適用範囲
この標準仕様書（TS）は, US の Library of Congress の ZING（Z39.50 International: Next
Generation）
グループが開発した XML に基づいた図書情報の検索プロトコル SRW 1.1（Search/Retrieve for the
Web 1.1）に，画像検索機能を追加する。
SRW は，
ISO で開発された ISO 23950:1998 "Information Retrieval (Z39.50): Application Service Definition and
Protocol Specification"を元にして，インターネット時代に対応するように改良された XML に基づく図書検
索プロトコルである。しかし，その検索は Unicode で登録された文字の範囲に限られており，図書で多く
存在する画像，特に，古文書などの文字コードでは表現しきれない各種の文字画像への対応がなされてお
らず，多言語環境での図書検索には不十分との認識があった。
この標準仕様書（TS）に従うことによって, 画像を送信でき，画像検索が可能になり，単純な Unicode
に従った検索以上のことを行えるようになる。
2.
引用規定
次に掲げる規格，標準情報（TR）
，標準仕様書（TS）及び規定は，この標準仕様書（TS）
に引用されることによって，この標準仕様書（TS）の規定の一部を構成する。これらの引用規格は，その
最新版（追補を含む。
）を適用する。
JIS X 0806:1999
情報検索(Z39.50) 応用サービス定義及びプロトコル仕様
備考これは，ISO 23950:1998 "Information Retrieval (Z39.50): Application Service Definition and
Protocol Specification"に一致している。
SRW 1.1: Search/Retrieve Webservice Version 1.1, 20th May
参考これは，http://srw.cheshire3.org/SRW-1.1.pdf から入手できる。
JIS X 4159:2005
拡張可能なマーク付け言語 (XML) 1.0 (Third Edition)
JIS X 4158:2005
XML 名前空間
TR X 0063: 2002
XML スキーマ
第 1 部構造
TR X 0064:2002
XML スキーマ
第 2 部データ型
TS X 0097:2004
統一資源識別子（URI）共通構文
TS X 0085:2004
ハイパテキスト転送プロトコル HTTP/1.1
-3-
2
TS X 0091:2005
3.
定義
3.1
この標準仕様書で用いる主な用語の定義は，次による。
基本操作
SRW 1.1 で用いる 3 種類の基本的なサービス。searchRetrieve 操作，scan 操作及び explain
操作から成る。
3.2
クライアント
3.3
サーバ
4.
基本操作を要求する側。情報検索の利用者側になる。
クライアントからの基本操作要求に応答する側。検索される情報を保持している。
SRW 1.1 の概要この標準仕様書（TS）は，SRW 1.1 の拡張という位置づけになる。そこで，規定を
自己完結させるために，拡張の規定に必要な SRW 1.1 の部分を，4.で示す。SRW 1.1 の詳細は，3.の SRW 1.1
を参照のこと。
4.1
基本操作
SRW 1.1 は，次の三つの基本操作からなるサーバ及びクライアント形式のプロトコルに
なっている。
－ serachRetrieve 操作。クライアントが問合せ及び検索の要求をし，サーバがこれに応答する。
－ scan 操作。クライアントが，サーバで定義された索引に基づいて項目を閲覧する。
－ explain 操作。サーバの能力を記述した文書を取得する。
これらは，XML で記述され，そのフィールドは，XML スキーマ（以下，xsd）で規定される型又はそれか
ら構築される型をもつ。
この標準仕様書（TS）では，serachRetrieve 操作の拡張機能だけを用いる。
4.2
searchRetrieve 操作 serachRetrieve 操作は，クライアントからサーバへの要求 searchRetrieveRequest，
及びサーバからクライアントへの応答 searchRetrieveResponse から成る。これらは，表 1 及び表 2 による。
この標準仕様書（TS）では，searchRetrieveRequest の extraRequestData だけを用いる。詳細は，5.を参照
のこと。
表 1
searchRetrieveRequest
フィールド名
version
query
startRecord
型
xsd:string
xsd:string
xsd:integer
必須かどうか
必須
必須
任意選択
maximumRecords
xsd:integer
任意選択
recordPacking
xsd:string
任意選択
recordSchema
recordXPath
resultSetTTL
xsd:string
xsd:string
xsd:integer
任意選択
任意選択
任意選択
sortKeys
styleSheet
xsd:string
xsd:anyURI
任意選択
任意選択
extraRequestData
XML 断片
任意選択
規定内容
要求の版。応答は，この版以下の版とする。
CQL で表現された問合せ。CQL は 4.3 参照。
合致したレコード内での最初のレコードの位
置。０以上とする。省略時値は 1。
返される最大レコード数。0 以上。省略時は，
サーバが決定する。
応答の中で別扱いするのが望ましいレコード
の別扱いの方法を決定する文字列。
レコードに仮定されているスキーマ。
レコードを返す前に適用される XPath 式。
検索結果集合の望ましいサーバ保持時間。サー
バは合意しなくてもよい。省略時は，サーバが
決定する。
結果に適用される整列キーの並び。
応答における XML スタイルシートとして用い
られるものを指定する URL。
付加的な情報を与える XML データ。
-4-
3
TS X 0091:2005
表 2
フィールド名
version
numberOfRecord
resultSetId
resultSetIdleTime
records
nextRecordPosition
diagnostics
extraResponseData
echoedSearchRetrieve
Request
4.3
CQL
searchRetrieveResponse
型
xsd:string
xsd:integer
xsd:string
必須かどうか
規定内容
必須
応答の版。これは，要求の版以下とする。
必須
検索によって合致したレコード数。
任意選択
検索によって生成された結果集合の識
別子。
xsd:integer
任意選択
生成された結果集合を削除する秒数。
record の並び
任意選択
検索によって合致したレコードの並
び。
。
xsd:integer
任意選択
返される最終レコードの後の結果集合
内での位置。
diagnostic の並任意選択
検索実行中に生成された診断の並び。
び
XML 断片
任意選択
付加的な情報を与える XML データ。
XML 断片
任意選択
SRU を使用した場合に，その要求を
XML 形式でクライアントに返す。SRU
については，4.4 参照。
CQL（Common Query Language）は，SRW 1.1 用に開発された簡易な共通問合せ言語とする。
その詳細規定は，SRW 1.1 の 32.～39.による。図 1 に，その文法を示す。
この標準仕様書（TS）は，その文法の一部だけを用いる。詳細は，5.3 を参照のこと。
cqlQuery
prefixAssignment
scopedClause
booleanGroup
boolean
searchClause
::=
::=
::=
::=
::=
::=
relation
comparitor
comparitorSymbol
namedComparitor
::=
::=
::=
::=
prefixAssignment cqlQuery | scopedClause
'>' prefix '=' uri | '>' uri
scopedClause booleanGroup searchClause | searchClause
boolean [modifierList]
'and' | 'or' | 'not' | 'prox'
'(' cqlQuery ')'
| index relation searchTerm
| searchTerm
comparitor [modifierList]
comparitorSymbol | namedComparitor
'=' | '>' | '<' | '>=' | '<=' | '<>'
identifier
modifierList ::= modifierList modifier
modifier ::= '/' modifierName comparitorSymbol modifierValue
| '/' modifierName
prefix, uri, modifierName,
modifierValue, searchTerm, ::= term
index
term ::= identifier | 'and' | 'or' | 'not' | 'prox'
identifier ::= charString1 | charString2
charString1 :=
＜空白，
“(”
，
“)”
，
“=”
，
“<”
，
“>”
，
“””
（二重引用符）及び“/”を含まない文字
の任意の並び。＞
charString2 := ＜二重引用符を除く任意の文字の並びを二重引用符で囲んだもの。ただし，二重
-5-
4
TS X 0091:2005
引用符で囲まれた文字の中に，
（日本語環境では円記号になることが多い）逆斜線
記号で別扱いした二重引用符を含めてもよい。＞
図1
4.4
SRU
CQL の文法
SRU（Search and Retrieve URL）は，SRW の要求 searchRetriveRequest を HTTP の GET 操作を
用いて簡便に実現する方式とする。SRW では要求が XML を用いて指定されるのに対して，SRU では要求
は URL の中に埋め込まれる。URL の構文については，URI の TRXXXX を参照のこと。
“?”で分離された searchpart とから構成された URL とする。Searchpart は，
SRU は，基底となる URL と，
“&”で分離され“key=value”という形式のキー及び値を“=”でつないだ（複数個の）パラメタから成
る。
“key”は，SRW における searchRetriveRequest の各フィールドのフィールド名とし，
“value”はその値
とする。
詳細規定は，SRW 1.1 の 30.～31.を参照のこと。
5.
画像検索機能
5.では，SRW 1.1 への拡張機能としての画像検索機能を規定する。例を，附属書 A に
示す。
5.1
画像検索機能は，SRW 1.1 への拡張機能とするが，その拡張を最小限にするために，
機能の要件
次の要件に従う。
－画像検索拡張機能は，SRW 1.1 に従わなければならない。
－クライアントは，問合せ要求 searchRetrieveRequest の中に画像又は画像への URI を指定し，サーバは，
CQL 及びこの情報を使って検索を実行し，クライアントに結果を返す。
－実際の画像検索の方式は，規定しない。それは，サーバに依存するか，クライアントとサーバとの間
であらかじめ決められた方式に従うものとする。
－画像は，要求だけで送信する。応答では送信しない。応答は，既存の SRW によるテキストに基づく
結果集合とする。
－ CQL は，拡張しない。
－画像又はそれへの URI は，
searchRetrieveRequest の extraRequestData の中に XML を用いて与えられる。
実際の画像データを送信するか，又はその URI を送信するかは，クライアントの任意とする。サーバ
は，どちらも受け付けられなければならない。
5.2
名前空間
画像検索機能は，XML を使うので，次の名前空間を用いる。
info:srw/extension/7/image-query-v1.0
ここで，
“7”は，画像検索機能の登録機関，JSA/INSTAC/AIDOS（Japanese Standard Association/Information
Technology Research and Standardization Center/Committee for Advanced Integrated Documents Standardization，
日本規格協会／情報技術標準化研究センター／将来型文書統合システム標準化調査研究委員会）を示す番
号であって，ZING で登録されている。http://www.loc.gov/z3950/agency/zing/srw/infoURI.html を参照するこ
と。
5.3
CQL
画像検索機能では，特に，CQL の次の部分を用いる。直接に画像検索機能とは関係しない部
分は，
“...”で示す。
cqlQuery ::= ... | scopedClause
...
scopedClause ::= scopedClause booleanGroup searchClause | searchClause
-6-
5
TS X 0091:2005
booleanGroup ::= boolean ...
boolean ::= 'and' | 'or' | 'not' | ...
searchClause ::= '(' cqlQuery ')'
| index relation searchTerm
| ...
relation ::= comparitor ...
comparitor ::= comparitorSymbol | ...
comparitorSymbol ::= '=' | ...
...
searchTerm,
::= term
index, ...
term ::= identifier | ...
identifier ::= charString1 | charString2
charString1 :=
＜空白，
“(”
，
“)”
，
“=”
，
“<”
，
“>”
，
“””
（二重引用符）及び“/”を含まない文字の任意の並び。
＞
charString2 := ＜二重引用符を除く任意の文字の並びを二重引用符で囲んだもの。ただし，二重引用符で囲ま
れた文字の中に，
（日本語環境では円記号になることが多い）逆斜線記号で別扱いした二重引
用符を含めてもよい。＞
さらに，画像増検索機能として，次の特殊化を行う。
index ::= “image.label”
searchTerm ::= ＜画像検索機能のための XML スキーマ（5.4 参照）における“label”属性の値＞
“index”として“image.label”を，
“searchTerm”として 5.4 で定義する画像検索機能用の XML スキーマの
“label”属性の値を使用する。この値は，検索する画像又はその URI を指定する。
5.4
XML スキーマ画像検索機能のための XML スキーマは，次による。
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="imageList">
<xsd:complexType>
<xsd:sequence>
<xsd:choice>
<xsd:element ref="imageData"/>
<xsd:element ref="imageURI"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="imageData" type="xsd:base64Binary">
<xsd:attribute name="label" type="xsd:string"/>
<xsd:attribute name="mimeType" type="xsd:string"/>
</xsd:element>
<xsd:element name="imageURI" type="xsd:anyURI">
<xsd:attribute name="label" type="xsd:string"/>
<xsd:attribute name="mimeType" type="xsd:string"/>
-7-
6
TS X 0091:2005
</xsd:element>
</xsd:schema>
一つの“imageList”要素が，searchRetriveRequest の extraRequestData に含まれなければならない。
“imageList”要素は，一つ以上の“imageData”要素又は“imageURI”要素を含まなければならない。
“imageData”要素は，base64Binary 形式で実際の画像データを含み，
“imageURI”要素は，実際の画像デ
“imageData”要素又は“imageURI”要素の選択はクライアントの任意とする。サー
ータへの URI を含む。
バは，どちらも受け入れなければならない。
“imageData”要素及び“imageURI”要素は，
“label”属性をもつ。その値は，一つの“imageList”要素
“label”属性は，省略してもよい。た
の中で一意でなければならず，CQL の“image.label”で参照される。
だし，その場合には，すべての“label”属性を省略しなければならない。SRU（6.参照）を使用する場合
が，これに対応する。省略した場合には，
“imageList”要素の中の“imageData”要素又は“imageURI”要
素の出現の順番が，
“label”属性の値とみなされなければならない。すなわち，最初に出現するものは，そ
の“label”の値が“1”とみなされ，2 番目に出現するものは，その“label”の値が“2”とみなされ，な
どとする。
備考省略する場合にはすべての“label”属性を省略しなければならない、という制限は，
“label”の
意味をあいまいにしないために提供されている。
“imageData”要素及び“imageURI”要素は，画像の MIME 型を指定する“mimeType”属性をもつ。
画像サイズなどの画像に関する他の情報も“imageData”要素及び“imageURI”要素に与えるのがよいか
もしれないが，これは，将来の課題とする。
6.
画像検索機能の処理
画像検索機能の実際の処理は，サーバに依存する。クライアントが指定する画
像検索固有の検索条件などの付加的な情報も，この標準仕様書（TS）では規定しない。
7.
SRU の使用 7.では，SRU を使用する場合を規定する。SRU の使用はクライアントの任意とするが，
サーバはこれを処理できなければならない。
SRU の指定方法は，4.4 による。ただし，画像検索機能に関しては，次の制限に従わなければならない。
－“key”として，5.4 で規定した要素名に，
“x-info-7-”を接頭辞として付加しなければならない。例えば，
“imageURI”に対しては，
“x-info-7-imageURI”とする。
－“imageData”は使用してはならない。
“imageURI”だけが許される。
－“label”属性は使用できない。したがって，
“imageURI”の出現の順番が，
“label”属性の値としてみな
される。
－ MIME 型は指定できない。MIME 型は，ファイル拡張子によって識別されることが望ましい。
－ “value”は，構造をもってもよい。この場合には，
“value”は，二重引用符（
“””，%22）で囲まれ，
その値は“key=value”形式で入れ子になっていなければならない。二重引用符で囲まれた中に二重引
用符が出現する場合には，
“¥＂”として別扱いしなければならない。
例を，附属書 A に示す。
-8-
附属書 A（参考）例
附属書 A では，画像検索機能を使用した場合の例を示す。
A.1 例の解説
次のシナリオを考える。
大変に猫好きのある人（仮に＂陽子“という名前の女性とする。
）が，その飼い猫であるタマと話をして
みたいと思っている。最近は，犬や猫の話を解釈するというツールもあるので，それほどおかしな話でも
ないだろう。
それらツールによれば，猫との会話を理解するには，猫の品種が分かった方がよいとされているらしい。
ところが，陽子はタマの品種を知らない。困った陽子は，タマの写真をとることにし，その写真を使った
画像検索を追加で行うことを思い付いた。画像は，タマの品種を知る手がかりを与えてくれるだろう。
さらに幸運なことに，陽子は，"http://www.x-books.org"というサイトが，最近，ZING SRW1.1 の画像検
索機能を提供したサービスを開始し，評判になっていることを知っていた。
そこで，早速，タマの写真を使って，タマと会話するのに役に立つだろう本を検索してみることにした。
A.2 SRW による検索
画像検索機能を用いて SRW 1.1 に従った検索要求は，例えば，次のとおりになる。
この例では，CQL で“cat“及び“speak”をタイトルに含み，タマの 2 枚の写真に基づいた検索を要求し
ている。
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<SRW:searchRetrieveRequest xmlns:SRW="http://www.loc.gov/zing/srw/">
<SRW:version>1.1</SRW:version>
<SRW:query>((dc.title any "cat speak") and (image.lable="1" and
image.label="2"))</SRW:query>
<SRW:startRecord>1</SRW:startRecord>
<SRW:maximumRecords>10</SRW:maximumRecords>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordsSchema>
<SRW:extraRequestData>
<imageQuery:imageList xmlns:imageQuery="info:srw/extension/7/image-query-v1.0"/>
<imageQuery:imageData label="1" mimeType="image/jpeg">
..... (JPEG data of Tama's picture 1 in base64Binary) .....
</imageQuery:imageData>
<and/>
<imageQuery:imageData label="2" mimeType="image/jpeg">
..... (JPEG data of Tama's picture 2 in base64Binary) .....
</imageQuery:imageData>
</imageQuery:imageList>
</SRW:extraRequestData>
</SRW:searchRetreiveRequest>
</SOAP:Body>
</SOAP:Envelope>
-9-
これに対して，例えば，次のような応答が返って来る。
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<SRW:searchRetrieveResponse xmlns:SRW="http://www.loc.gov/zing/srw/">
<SRW:numberOfRecords>2</SRW:numberOfRecords>
<SRW:resultSetId>8c527d60-c3b4-4cec-a1de-1ff80a5932df</SRW:resultSetId>
<SRW:resultSetIdleTime>600</SRW:resultSetIdleTime>
<SRW:records>
<SRW:record>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordSchema>
<SRW:recordData>
<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns:xlink="http://www.w3.org/TR/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.loc.gov/mods/"
xsi:schemaLocation="http://www.loc.gov/standards/mods/mods.xsd">
<titleInfo>
<title>How to Speak with Your Cats: Their Misterious Worlds!</title>
</titleInfo>
<name type="personal">
<namePart>Kitty, Furry.</namePart>
<role>creator</role>
</name>
...
</SRW:recordData>
<SRW:recordPosition>1</SRW:recordPosition>
</SRW:record>
<SRW:record>
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordSchema>
<SRW:recordPacking>string</SRW:recordPacking>
<SRW:recordData>
<?xml version="1.0" encoding="UTF-8"?>
<mods xmlns:xlink="http://www.w3.org/TR/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.loc.gov/mods/"
xsi:schemaLocation="http://www.loc.gov/standards/mods/mods.xsd">
<titleInfo>
<title>Japanese Bobtail Speaks! : A Story of A Japanese Cat</title>
</titleInfo>
-10-
<name type="personal">
<namePart>Tamako, Nekomata.</namePart>
<role>creator</role>
</name>
...
</SRW:recordData>
<SRW:recordPosition>2</SRW:recordPosition>
</SRW:record>
</SRW:records>
</SRW:searchRetrieveResponse>
</SOAP:Body>
</SOAP:Envelope>
画像検索の実際の機能はサーバ任せなのでサーバの実力が問われることになるが，今の場合は，どうやら
タマは“Japanese Bobtail”らしく，それ相応の応答が返って来たようだ。恐らく，陽子も満足したものと
思われる。
A.3 SRU による検索
SRU は，要求だけに使用できる。A.2 の SRW の場合の要求と等価な SRU は，次の
とおり。ただし，見易さのために改行を入れたが，実際には入らないことに注意。
http://myserver.com/myurl/?operation=searchRetrieve&version=1.1
&query=((dc.title%20any%20%22cat%20speak%22)%20and%20(image.lable=%221%22%20and%20image.label=
%222%22))
&startRecord=1&maximumRecords=10&recordSchema=info-1-mods-v3.0
&x-info-7-imageList=
%22x-info-7-imageData=http://myserver.com/imageData/TamaPicture-1.jpg
&x-info-7-imageData=http://myserver.com/imageData/TamaPicture-2.jpg%22
-11-
[附属資料－A.6]
日本語検索機能記述のための指針
適用範囲
この標準報告書(TR)は、日本語文字列検索を実行可能な情報処理システムにおいて、利用者が入力した検索語か
ら、それと同じ文字列を含むデータを検索する場合、どのような規則をいて、同じとみなしているかの仕様を記述する
指針を与えるものである。この指針では日本語文字列による検索を対象とし、外国語の文字列は対象としない。又、
意味による検索（主題検索）は対象としない。この指針を用いて各々の検索システムが使用している文字列検索規則
を明確にすることにより、利用者は、検索漏れがなく、無駄のない検索問合わせを実行することができるようになり、利
便性が向上する。
1. 背景
情報処理システムの利用が一般化し、図書館での文献検索やインターネットでの情報検索など、一般利用者も日常
的に検索システムを用いるようになった。検索語を入力して、それと同じ文字列を含むデータを検索する場合、「同じ」
とみなすための規則を正確に知らないと、目的のデータがあるのに見つけられなかったり、無意味な検索を何度も繰
り返すことになる。例えば、ある検索システムでひらがなとカタカナを同じとみなすかどうかを知らないと、「ぱそこん」と
いう検索語に対して「パソコン」が一致するのかどうかわからないため、同じとみなさないシステムで「ぱそこん」だけを
入力して「パソコン」というデータがあるのに見つけられなかったり、同じとみなすシステムで両方を入力して無駄な検
索をしてしまったりする。
このような検索漏れの問題をなくすためには、（１）検索規則を標準化し、実装者はそれに従って実装し、利用者はそ
の文字列検索規則を習得して使う方法、（２）実装によって文字列検索規則にばらつきはあるがその仕様を記述して
公開し、利用者はそれを見ながら検索システムを利用する方法、又は（３）検索語をもとに意味内容を含む高度な判断
を行って探しているであろうデータを類似度の優先順位つきで示す方法などが考えられるが、この指針で規定するの
は（２）の文字列検索規則を明確にする方法である。
検索プロトコルについては、相互運用性の確保のために、複雑になり過ぎないように配慮して、日本語や英語といった
言語に特有の機能はいれずに、標準化したほうがよい。しかし、「有益な情報を取り出すことができる」という観点から
は、言語に特有の機能、例えば、「異体字」や「よみ」など日本語に特有の機能を入れて利便性を向上することが望ま
れる。検索プロトコルと文字列検索規則は分けて標準化するほうがよい。このこの標準報告書(TR)では、文字列検索
規則について、説明書やヘルプに仕様記述を行って、利用者に周知したほうがよい項目について列挙する。
日本語文字列検索規則が不明であると、無駄な検索を何度も繰り返さなければならない。そのような例を、原因となっ
ている理由ごとに場合分けして、次に示す。
1. 異体字の問題
例）「齋藤」という姓の人名を検索する際、「斉藤」と入力して一致するか。
2. 漢字、ひらがな、カタカナ及びローマ字の間の関係の問題
例）「規格」と「きかく」とは同一なのか。
3. 表記のゆれの問題
例）「デジタル」と「ディジタル」とは同一か。
例）「サーバー」と「サーバ」は同一か。
4. 記号類の取扱いの問題
例）「C#.NET」と「CNET」は一致するのか。
5. 文字コード体系の差異
例）半角数字と全角数字は異なる検索語か。
2. 用語の説明
検索
データベースに蓄積された情報を探し引き出すこと。この指針では、さらに狭義に、"検索語"を検索システムに
入力して問い合わせると、検索システムから検索語に対応した情報の一覧が出力されるという一連の処理をさ
-1-
す。ここでは検索（retrieve）及び探索(search)は同義として取り扱い、検索という語を用いる。
検索システム
検索を行う情報処理システム。
検索語
問合せにおいて、検索対象として、検索システムに与える文字列。一般に、利用者は、端末画面上の検索語入
力フィールドにキーボードから入力し、「検索」等のボタンを押して検索を実行する。索引語、キーワードとも呼ば
れる。
文字列検索規則
検索語の文字列とデータベース中のデータに含まれる文字列を同じとみなすために用いる規則
3. 日本語検索機能記述項目
この箇条は、この指針の中心をなすものであって、日本語検索機能の仕様を記述する場合に、どのような項目を記述
すればよいかを列挙する。検索システムの実装者は、この箇条に示す項目を実装するか、しないか、実装する場合ど
のような仕様とするかを考慮したほうがよく、検索システムの取扱い説明書及びヘルプに仕様を完全に記述するほう
がよい。
3.1 使用する文字集合に関する記述項目
無駄のない正確な検索をするためには、使用する文字の範囲を明らかにする必要がある。
3.1.1 文字集合名
検索語に使う、又は、データベース中のデータに使われている、文字集合が何であるかを、記述する。文字コード名と
付加的な情報で記述するとよい。UNICODE Version XX、JIS X 0208:19xx、JIS X 0201:19xxなどの記述を行う。付加的
な情報として、第１水準だけとか、基本多言語面だけとかなどの情報を含める。複数の文字コードを使用する場合、例
えば、データベース中の文字コードと検索語の文字コードが異なる場合、それらの変換規則も明示する。
3.1.2 使用文字及び使用禁止文字
データベースに使用されている文字集合を指定したとしても、データベース作成時の入力規則として、使用禁止の文
字が存在する。例えば、ローマ数字のⅠ、Ⅱ、Ⅲは使ってはならず、「数学Ⅱ」は、「数学II」とデータベース入力しなけ
ればならないといった入力規則がある場合がある。又、JIS第２水準の文字は使ってはならずJIS第１水準相当の文字
に置き換えて入力するというような規則がある場合がある。このような使用文字又は使用禁止文字に関する仕様を記
述する。
3.1.3 １バイト文字コードと２バイト文字コードとの区別
日本では、いわゆる1バイト文字コード及び2バイト文字コードを混在して使用してきた経緯がある。 1バイト文字は、パ
ーソナルコンピュータでの実装上は、いわゆる半角文字であり、カタカナ・アルファベット・数字・記号を表すことができ
る。2バイト文字はいわゆる全角文字であり、1バイト文字で表すことのできる文字・記号を含んでいる。検索語として受
付けるのか、同じ文字に対する１バイト文字コードと２バイト文字コードとを同じとみなすのか、同じとみなす場合その
変換規則はどのようであるかを記述する。
8ビット文字コードを使用した半角文字は、16進の21-126にアルファベット・数字・記号があり、161-の範囲にカタカナ
（日本語表記のための記号を含む）があるが、このカタカナが使用可能であるかは、記述したほうがよい。
１バイト文字コードと２バイト文字コードとの変換は、例えば、１バイト文字コードで"カ"に続けて"゛"（濁点）を入力した
場合、２バイト文字コードで"ガ"にするのかどうかといった変換規則である。
２バイト文字コードのスペース及び１バイト文字コードのスペースを同じとみなすかを記述したほうがよい。
さらに、検索語入力フィールド中で利用することができる、検索演算のための特定の記号類について、全角と半角を区
別するかどうかも別途記述したほうがよい。例えば、スペース、＆、AND、|、OR、!、NOTなどについてである。
-2-
3.1.4 スペースの扱い
スペースを検索語の一部として扱うのか、検索語の区切り子として扱うのかを記述する。又、半角スペースと全角スペ
ースを区別して扱っているのかどうかを記述する。
3.1.5 外字の使用
人名、地名、その他の固有名詞、又は、古語は、外字を使わなければ表せない場合が多々ある。外字を使用している
かどうかを記述する。
3.2 表記上のゆれに関する記述項目
3.2.1 ひらがな・カタカナ・ローマ字
日本語の場合、同じ発音の文字列を、ひらがな、カタカナ、ローマ字、漢字であらわすことができる。このうち、ひらがな
とカタカナとを同じとみなすかどうかを記述する。加えてローマ字を同じとみなすかどうかを記述する。同じとみなす場
合、比較的単純に相互変換が可能であるが、完全な一対一対応とはなっていないため変換規則を明示する必要はあ
る。
3.2.2 漢字・ひらがなの区別及び読み
漢字の場合、読みがあり、読みについてどのように扱っているのかを記述する。例えば、全てのデータに対してひらが
なで読みデータが付与されてデータベース中にあり、ひらがなによる読みを使っても検索できるといった機能を記述す
る。
3.2.3 異体字に関する使用
異体字の取り扱い仕様について記述する。例えば、「齋藤」という姓の人名を検索する際、「斉藤」と入力して一致する
かどうかなど。使用のための処理が行われているか又は単に文字コードの比較だけで一致を判定しているのかにつ
いて、特に前者の場合は詳細仕様を記述する必要がある。
3.2.4 外字に関する使用
外字を許容している場合に限るが、どのように使用すればよいかを記述する。
3.2.5 カタカナでの日本語表記上の問題
カタカナの棒引き（ー）（例：サーバとサーバー）、小さいカタカナを使うかどうか（フィルムとフイルム）など。バイオリンと
ヴァイオリンなどカタカナで外来語を表記する場合にはかなりの表記のゆれが存在するので注意が必要であり、シス
テム側でこれらをどのように使用してくれるのかを記述する。
3.2.6 ひらがな・漢字での日本語表記上の問題
送り仮名や文法的な規則など、使用可能なものの取り扱いを行う場合にはその詳細を記述する必要がある。長音、拗
音、促音、音便等、表記上の規則はさまざまにあり、何らかの処理が含まれれば記述する。
3.2.7 記号類の使用
検索語中に文字とみなされる記号類を含めるかどうかを記述する。例えば、図書のデータベースでは、書名データに
は記号類を含んでいるが、検索時には、検索語中の記号類を全て無視して、純粋な文字だけの文字列に一旦変換し
たものを検索語として検索エンジンに渡すような場合が多い。例えば、".NET"（ドットネット）のつく書名を検索したい場
合"."（ピリオド）が無視されるためそのような検索は行えず、"NET"がつく書名が全て一致するといった事態が生じる。
利用者は、このような記号類の使用に関する規則を正確に知らないと、正しい検索ができない。
-3-
3.2.8 アルファベットの使用及び大文字・小文字の扱い
アルファベットは、外国語表記及び日本のローマ字表記に使用される。大文字・小文字の別などの仕様を記述する。
3.2.9 ローマ字表記法
ローマ字を含む検索では、ローマ字表記法の仕様記述が必要である。学術文献データベースなどでは、検索語として
は、著者名等をすべてローマ字で入力するようなシステムがあるが、その際、ローマ字表記法のばらつきをどう使用す
るか記述しておかない図した人名を探せないことなどがある。
3.3.10 外国語の文法項目
外国語を検索語に使えるようにする場合は、ある程度文法的な処理を考慮する必要がある。単数形・複数形の違い、
ハイフン等の用法、ドイツ語ならウムラウトやエスツェットなど言語ごとの考慮が必要である。どの外国語が使えるか、
それぞれの外国語に対しどのような処理がなされるかを記述する。尚、この指針では外国語の使用については適用
範囲外とするので、実装者が、詳細を検討して記述することが望ましい。
3.3 データの構造
3.3.1 フィールドごとの日本語検索規則の差異
検索は単に書名だけとか著者だけではなく、いろいろな検索条件で検索される。図書データベースの場合、書名、著
者名、出版社、出版年、分類コードなどの様々なフィールドがあり、それらのフィールドを使った複合的な検索ができ
る。そのこと自体は一般的な検索仕様の記述であり、この指針の内容である日本語検索機能記述の範疇ではない
が、もし、フィールドごとに、入っているデータの日本語検索上の違いがあり、又、使用を含む検索機能にも違いがある
なら、それらを明記する必要がある。
3.4.2 データコード、シソーラス、キーワードリスト、標目形（典拠）
日本語文字列を検索語とする検索であるが、文字列の直接の比較ではなく、別の形式に変換してから検索する場合
などは、その仕様を記述する。
出版社コードなどのようにある特定の日本語のデータについてコードを割り当てる場合がある。フィールドによっては、
検索語を一旦そのようなコードに変換して、検索する場合があり、そのような処理が含まれるのなら明示的に仕様を記
述する。
特に学術分類などの場合、シソーラスやキーワードリストを作成して、表記ゆれにある程度頑健な、内容的な検索を可
能にする場合がある。そのような処理が含まれるのなら明示的に仕様を記述する。
3.4 検索の基本的方策
3.4.1 検索単位
検索語を一致させるために使用する単位が、文字列なのか、単語なのか、又は、その他の単位なのかを記述する。
3.4.2 一致のための基本的方策
完全一致か、部分一致か、類似度計算による一致など、検索のために基本的方策を記述し、利用者の検索語入力を
助ける。
3.4.3 論理演算及び近接演算規則
AND又はOR等、複数の検索語の入力方法及び演算規則について記述する。例えば、大抵のウェブ検索エンジンで
は、スペースで区切って複数の語を入力すると、複数の語のOR検索となる。
-4-
文字列の出現語順を指定できる、近接演算をサポートしている場合、その詳細仕様を記述する必要がある。
4. その他の検討項目（参考）
この標準報告書(TR)では、日本語文字列の検索についてだけ、適用範囲としたが、単に単語や文字列の一致だけで
はなく、意味内容を含めた知識処理を用いて所望の情報を検索する主題検索、その他、有用な検索をするための
様々な技術開発がなされている。検索システムを実装する際に、検討したほうがよい事項の一部を参考のために次に
列挙する。
z
z
z
z
z
z
z
検索結果表示の優先順位
書誌データ作成における、内容に関するメタデータ付け。キーワード付け。
シソーラスの作成
データマイニング、自動要約技術、全文検索技術。
画像検索。
書評情報の相互リンク、ウェブページのハイパリンクなど、分散環境での内容検索。
ヒット数、ランキングなどの利用度、有用性評価を含む基準。
-5-
[附属資料－B.1]
B.1 OWLの現状（山田）
OWLの使用事例
以下はオントロジのポータルサイト (OWLに限らず)
Ontologies (from W3C)
* SchemaWeb (http://www.schemaweb.info/default.aspx) provides a comprehensive directory
of RDF schemas and OWL ontologies to be browsed and searched by human agents and also an
extensive set of web services to be used by agents and reasoning software applications that
wish to obtain real-time schema information.
* DAML Ontology Library (http://www.daml.org/ontologies/) which organizes hundreds of
ontologies in a variety of different ways (keyword, organization, submission date, etc.)
* Swoogle (http://pear.cs.umbc.edu/swoogle/) is a search engine for Semantic Web documents,
including OWL ontologies, built by the University of Maryland Baltimore County under funding
from the National Science Foundation.
このうち、SchemaWebの検索結果のサンプル
Schema Details :: Suggested Upper Merged Ontology (SUMO)
Name:
Suggested Upper Merged Ontology (SUMO)
Description:
This ontology is being created as part of the IEEE Standard Upper Ontology Working Group.
The goal of this Working Group is to develop a standard upper ontology that will promote
data interoperability, information search and retrieval, automated inferencing, and natural
language processing.
Namespace:
http://reliant.teknowledge.com/DAML/SUMO.owl#
Location:
http://reliant.teknowledge.com/DAML/SUMO.owl
Website:
http://www.ontologyportal.org
Contact Name:
Adam Pease
Contact Email:
adampease@earthlink.net
Local Version:
06/02/2005 08:50:31
以下は個別の例
Ontologies (from protege.Stanford)
Here is a small (but growing) selection of existing OWL ontologies that you might want to
try. Please feel free to contribute any interesting ontologies you find or develop. An
efficient way of detecting other owl ontologies is using Google:
http://www.google.com/search?q=filetype:owl+owl.
There is also a new Semantic Web search engine called Swoogle.
Download the .owl files and use the "Build..." function to load them into the OWL Plugin.
In most cases, you can directly open the ontologies from the web - just paste the URL of
the .owl file into the "Build..." dialog.
biopax-level1.owl ― An OWL ontology for biological pathways. It will be used as a
data exchange format between biological databases. Source: BioPAX group.
camera.owl ― An ontology about the individual parts of a photo camera. Source: XFront
OWL Tutorial.
countries.owl ― The ISO 3166 Code List of countries. Contributed by Dieter E. Jenz.
EHROntology ― An Electronic Health Records ontology based on openEHR work. Contributed
by Isabel Roma'n Marti'nez.
ESG ― An ontology describing very large simulation datasets and related information
for climate sciences such as those found in the Earth System Grid project. Contributed by Line
Pouchard.
family.swrl.owl ― A SWRL/OWL demo ontology about family relationships . Contributed
by Christine Golbreich.
fgdc-csdgm.owl ― Ontology for Content Standard for Digital Geospatial Metadata (CSDGM)
of Federal Geographic Data Committee (FGDC). Contributed by Akm Saiful Islam, Bora Beran,
-1-
Volkan Yargici and Michael Piasecki.
fsm.owl ― A simple ontology for finite state machines. Contributed by Peter Dolog.
generations.owl ― An ontology about family relationships that demonstrates classification.
Contributed by Matthew Horridge.
hu.owl ― A hierarchic division of hydrologic units. Contributed by Luis Bermudez.
iso-19108 ― Ontology for Geographic Information - Temporal Schema (ISO 19108). Contributed
by Akm Saiful Islam.
iso-metadata.owl ― An ontology representing Geographic Information Metadata - (ISO 19115).
Contributed by Akm Saiful Islam, Luis Bermudez, & Michael Piasecki.
ka.owl ― Defines concepts from academic research. Contributed by Ian Horrocks.
koala.owl ― A simple ontology about humans and marsupials. Contributed by Holger Knublauch.
MGEDOntology.owl ― A biological ontology about Microarray Gene Expression Data. Converted
from DAML+OIL and contributed by Paul Xu.
NCI Thesaurus ― A huge ontology developed by the National Cancer Institute (NCI). Source:
NCI Enterprise Vocabulary Services.
not-galen.owl ― A selective adaptation made in 1995 of an early prototype GALEN model;
content is not related to or representative of any current or historical OpenGALEN release.
Contributed by Ian Horrocks.
OGC Ontology for Geography Markup Language (GML3.0) of Open GIS Consortium (OGC). Contributed
by Contributors: Zafer Defne, Akm Saiful Islam and Michael Piasecki.
people+pets.owl ― From the ISWC03 tutorial on OWL by Sean Bechhofer, Ian Horrocks and
Peter Patel-Schneider.
Petrinet Semantic Web Infrastructure ― Contributed by Dragan Gasevic.
SemanticBible ― An emerging exploration of new applications of markup and computational
linguistic technology to the study of Scripture.
Surface-Water-Model-Ontology ― An ontology for surface water and water quality models
currently exists based on the list provided SMIC, US Geological Survey using Prote'ge'. Contributed
by Akm Saiful Islam.
SWEET Ontologies ― A Semantic Web for Earth and Environmental Terminology. Source: Jet
Propulsion Laboratory.
shuttle-crew-ont.owl ― An ontology about the crew from a space shuttle. Source: Dynamic
Research Corporation.
tambis-full.owl ― An biological science ontology developed by the TAMBIS project.
Contributed by Ian Horrocks.
travel.owl ― A tutorial ontology for a Semantic Web of tourism. Contributed by
Holger Knublauch.
wine.owl ― The infamous wine ontology (demonstrates project inclusion). Original
source: WebOnt OWL Guide.
Wood Ontology ― Contributed by Muhammad Abulaish & Lipika Dey.
-2-
[附属資料－B.2]
Ontology Application to AV Equipment and Systems
1. Background
G/W
XML Data
Receiver
ECHONET
Application
Door Phone
Application
G/W
GIS
Digital TV
PIM Ontology
Schedule
Management
XML Gateway
Personal Data
Management
Home System
XML Data Storage
G/W
Web Server
Sensor
G/W
Mobile net
Internet
Figure 1: Personal Portal Server based on PIM Ontology
2. Proposals
-1-
DB
Fig.2: Concept Diagram of TV Program Preference System
-2-
Type/Class
Object Types
(Class)
Char, String
Int, Float
Boolean
Fig.3: The Relationship between Various Media and Types
3. Other Important Items
-3-
-4-
Ontology Application to Network
Equipment Management
Kunio Ohno, and Ray S. Atarashi
1
Goals
• Easy setup for Internet connection from
home without complicated configuration.
• Home network building, maintenance and
management for audio visual systems on
LAN/wireless LAN network (by a home
server).
• SOHO network building, maintenance and
management for an high quality
environment.
2
-5-
Discussion Steps
• Modeling basic network equipment for home appliances
– Select a major (defacto standard) product and describe the setup
process.
– Define classes based on the product for abstraction and
generalization
– Define generalized sequence model for various manufacturers
– UML description using object analysis and design methodology
• Architecture model for network equipment
– Network configuration c.f. address, DNS
– Firewall policy
• Modeling automatic configuration
– Collaboration home router, home server, and configuration
server on the Intranet/Internet
– Policy adoption model
3
Ontology application
• Based on the prototype model described in UML,
classes can be defined and objects can be inplemented.
• OWL (Web ontology language) can be applied to the
classes to enhance the relationship description with
properties.
– To describe the relationship between various equipments and
absorb the differences
– To infer and select equipment due to user’s idea and preference
– To provide appropriate guideline and manual according to user’s
skill
• Configuration and diagnosis to various equipment can be
made by referring the specification and ontology under
certain namespaces.
4
-6-
B.2 IEC/TC100への提案
IEC(国際電気標準会議)には, 情報家電を含むマルチメディア関連技術の標準化を担当する技術委員会として
TC100が設けられ, 1995年からその分野の国際規格の開発を行っている。IECには, その将来活動の指針を検討
する委員会としてPresident's Advisory Committee on Future Technology (PACT)があり, 2000年10月に
"Final report of the project on Human interfaces in Multimedia network Era"という報告書(PACT
report)[1]を提出した。PACT reportは, IEC中央事務局経由でTC100に届けられ, TC100がこの報告書への対応
を求められた。
このPACT reportは, IECが扱うマルチメディア機器のヒューマンインタフェースの基本概念を示すものであり,
その中にオントロジ技術の必要性が示されている。PACT reportへの対処として, TC100は"Response to the
PACT Report"[2]をまとめ, それに従ってマルチメディア技術の標準化活動を推進している。
ここでは, オントロジ技術の情報家電への応用としてこのPACT reportの関連部分を紹介し, IEC/TC100におけ
る"Response to the PACT Report"に従った活動の概要を示す。
B.2.1 PACT Repot
PACTは, 今後のIECの標準化活動を検討するに際して, ネットワーク化社会の普及を考慮し, 次の課題に着目した。
(1) 局所的コミュニティに近接するサービスの開発
(2) トレンドとして現れた多様なサービスに使われるマルチメディアコンテンツの普及
つまり, 実世界とサイバー世界とを融合するための技術への要求があることを認識して, 次の二つのネットワーク
サービスを検討することの必要性を明らかにした。
- ホーム内外のネットワークサービス
- モバイルヒューマンインタフェース
さらに後述の8分野の標準化課題候補を抽出して, IECに対して次の勧告を行っている。
(1) IECは, TC100/AGSにおいて8分野の標準化課題を議論する。
(2) 特にIECは, オントロジ技術の標準化およびメディア変換技術の標準化をそのスコープの中に含める。
この勧告は, PACT Repotの冒頭にある概要と結びの提言とに示され, オントロジ技術をIECで標準化することが
強調されている。
8分野の標準化課題とは, 次のとおりである。
(a) 実世界とサイバー世界とを結ぶ技術
(1) 識別子提供
実世界に対応する情報をサイバー世界だけに存在する他の情報と区別する。
(2) 位置検出
屋内における位置を検出する。
(b) サイバー世界の情報を包括的に管理する技術
(3) 実世界での相互運用性を保つための属性情報を記述する枠組み
多言語とオントロジ
(4) 情報を実世界に反映する枠組み
サイバー世界がその情報を実世界に反映することを保障する。
(c) 利用者情報に基づくサイバー世界との相互動作の技術
(5) プライバシ保護技術
匿名性を保存する。
(6) 検索, フィルタおよびマッチングの方式
(さまざまな条件での最適な)経路検索
(d) 実世界とサイバー世界との間のメディア入出力の技術
(7) メディア変換技術
3D画像圧縮方式
デバイス間の相互運用性(デバイス非依存表示方式)
(8) 相互動作の技術
困ったときの容易な設定 (cf. 位置識別子による)
デバイスとの自動相互動作 (cf. 個人情報, プロトコルの保守)
B.2.2 Response to the PACT Report
PACT Reportは, その勧告どおり, TC100/AGS(Advisory Group on Strategy)に届けられ, TC100としての対応
の検討が開始された。PACT Reportへの対応方針をまとめた"Response to the PACT Report"[2]が, 2003年に
関係者に配布されると共に, PACT Reportへの対応案件がTC100/AGS会議の議題にとりあげられ, 専門家を含め
た議論が国際標準化の観点から続けられている。
"Response to the PACT Report"の概要を次に示す。
TC100は, 次の内容を標準化するための新規のTA(技術分野, ISOなどのSCに相当。)を設立することが望ましい。
(TC100の規定によれば, TAの設立には, 複数件の新作業課題の投票でプロジェクトが成立することが前提となる。)
-7-
(1) 利用者マニュアル(文書構造, 用語, ナビゲーション, ウィザード)に関する共通指針
多くの文化圏で使えるヒューマンインタフェースを標準化することは複雑であるので, この指針は, サイバー
世界のマルチメディアに対するヒューマンインタフェースの地域規格, 国内規格または国際規格を作るための
TS(技術規定)であることが望ましい。既に多くの記述的な解決, 規定およびアプローチがあり, このTSは, そ
れらを指示したり参照するものになる。
(2) 局所的所在検出の規格
局所的所在を検出(受動的または能動的)するための個人データ集合を含むハンドヘルド個人デバイスを対象と
する規格を開発することが望ましい。
(3) プライバシ保護とデータセキュリティに関するTS(技術規定)
バイオメトリクデータおよび個人履歴データと組合わせたセキュアトークンを用いた認可によってセキュリティ,
プライバシ, 個人データ保護を扱う。TR(技術報告)またはTS(技術規定)は, 国内法規による固有の要件に配慮
する必要がある。
(4) オントロジの語彙およびセマンティクスに関する規格
オントロジの語彙およびセマンティクスに関する規格は, 利用者マニュアルなどを作るためのオントロジライ
ブラリを作成するのに利用できる。
既存の国際的な語彙およびセマンティクスの規格が利用可能であれば, それを基礎とする。用語が技術固有で
あれば, 国ごとの違いと技術応用とに配慮が必要である。
(5) 資源の識別と分類に関するTR(技術報告)
TC100が扱う機器に関連する資源の識別と分類についての概要を作成する。それは, 多くの値をもつデータ要素
のデータ集合を含む。特徴的な資源の部品, 資源の応用およびサービス特性, 並びに利用種別を扱う。
(6) 多くのホームネットワークに対する共通ヒューマンインタフェースの規格
Hyperlan, WiHi, ZigBee, Bluetooth, PLCなどの多くの異種ネットワークに依存しない共通ヒューマンインタ
フェースを標準化する。それに際しては, OSGi(Open Services Gateway Initiative)が規定するような, 局所的
なネットワークとデバイスへの管理サービスの開放形ネットワーク配送を考慮する。
(7) 対話的受信資源への対応付け応用シナリオ
受信資源に対する応用シナリオの対応付けについては, 必要なヒューマンインタフェースを識別するために, 応用
とその内容とを記述し分類する方法を標準化する必要があ。
B.2.3 TC100における課題対応
AGSにおけるPACT Reportへのこれらの対応案件の中で, 特にオントロジ技術に関係の深い議論を次に示す。
(1) AV機器に求められるオントロジ技術
100/AGS/143, Ontology description for AV equipment and systemsを参照。
(2) ホームネットワーク機器管理に求められるオントロジ技術
100/AGS/158, Ontology application to network equipment managementを参照。
B.2.4 文献
[1] IEC/TC100/AGS/63, Final report of the project on Human interfaces in Multimedia network Era,
2000-10-31
[2] IEC/TC100/AGS/111, Draft response to the PACT Report, 2003-03-31
[3] IEC/TC100/AGS/124, Ontology description for AV eqipment and systems, 2003-11-05
[4] IEC/TC100/AGS/143, Ontology application to AV equipment and systems, 2004-05-14
[5] IEC/TC100/AGS/158, Ontology application to network equipment management, 2004-10-08
-8-
[附属資料－B.3]
B.3 TV 視聴者の嗜好に基づく番組推薦へのオンロトジー応用の可能性について
2005/2/18
出葉
はじめに
テレビジョン番組は、ハードディスクレコーダーの登場によって従来の放送局が編成した
番組を時系列に鑑賞するのではなく、ユーザ（TV 視聴者）の好みだけを選別して自由な時
間に見るものに変わりつつある。このことは、ビデオデッキによってすでに技術的には可
能ではあったが、全ての番組を予約録画することは現実的でなく、ビデオテープの録画時
間が最長でも 9 時間（VHS/EP モード）であったことから機械が適当に選択した番組を録
画するだけの容量を無人で持ち得なかったという理由による。しかしながらハードディス
クレコーダーは 200 時間を超え、ランダムアクセスができることから大雑把なユーザの嗜
好から機械が自動的に番組を録画していき、後でユーザが選別して番組を視聴するという
形態が実現可能となった。そこで、ユーザの嗜好にあわせた番組推薦（リコメンデーショ
ン）が想定されるが、その際にどのような手法によってこれを行うかが課題となっている。
本節では、オントロジーを用いたアプローチの可能性について考察する。
放送による番組情報の配信
テレビジョン番組には，Service Information (SI)と呼ばれるデータが番組とともに配信さ
れている。SI は放送メディアの形態によって配信方法や配信範囲が異なるが、テレビジョ
ン受信機に対して、番組情報を提供するという点においては、一致している。SI には，放
送事業者を表す Network ID や番組を表す event ID などの情報の他に，番組タイトル，番
組内容を表す情報も含まれる。番組タイトルは必須だが，番組情報は任意に指定される。
SI に含まれる番組情報には，二つの形式がある。
－短形式イベント
－拡張形式イベント
短形式イベントでは番組タイトル以外に不定形式の情報が含まれる。
－（長い例）ニュース NNN24 ニュース朝いち 430
・「朝４時３０分から始まるニュース番組。前日の世の中の動きから、
新聞にも載っていない最新ニュースまで幅広く、女性キャスターが元
気に明るくお伝えします。
」
－（短い例）笑点
・
「アナウンサー大喜利。歌丸里帰り。
」
これらの情報は、人手により入力され、付いていない番組も多数ある。
また、SI の中にはジャンルを表記する領域があるが，これもイベント内容の記述同様任意
であるため，付いていない場合が多い。
-1-
基本は大分類(0x0～0xD)と中分類(0x0～0xF)の 2 バイトで分類されるが，0xE からはじま
る拡張形式によって 4 バイトに拡張され，中分類に(0x0:BS デジタル，0x1：110 度 CS）
区分があり，それに続く 2 バイトによって分類されている。
メディアによって画一的なジャンル分けができず，110CS が独自路線を取っている。（BS
デジタルには，この部分の拡張定義はなされていない。
）
SI により取得できる情報としては、放送事業者名、ジャンル、番組名、放送開始時間・終
了時間、番組解説（短形式および拡張形式）ということになる。番組解説の自由文は、正
しい日本語の体裁をなしていない場合が多い。これは、ラジオ・テレビ欄（いわゆるラテ
欄）に埋め込むために字数を工夫しているため読者に推測可能な情報を省くことによって
起こる。よって、通常の構文解析などによって文の意味や内容を理解することは、非常に
困難である。
ユーザの嗜好
ユーザの嗜好については、ユーザが自身の嗜好を質問に答える形で事前に入力するか、視
聴した番組の情報に基づいて受信機が学習することで生成していくものが考えられる。ま
た、フリーキーワードの登録によって好みの辞書を作成することも考えられる。
ユーザの事前入力に基づき、ジャンル、登場人物、興味のある事柄などを受信機は知るこ
とができると思われる。また、視聴回数の多いジャンルや登場人物を記憶しておくことも
可能であろう。また、ネットワーク環境があれば、同様のジャンルや登場人物を好むユー
ザ同士を結びつけることができ、お互いがまだ見ていない番組を補完して推薦することが
できる。そのためには、ユーザ嗜好について統一したフォーマットを用意しておき、管理
することが必要となる。
オントロジー応用
以上を踏まえて、オントロジーを適用を検討する。現状の番組情報の内容が利用できるか
どうかだが、自由文形式で登録されている情報に OWL などで記述したデータを埋め込むこ
とは可能だが、現状の運用を大幅に変更することが必要であり、またこの自由文は、受信
機の番組情報表示に用いられているため、受信機への負担も大きい。よって、これら番組
データは、ネットワーク経由で取得することが望ましい。このデータをここでは番組情報
メタデータと呼ぶことにする。SI の情報は、これらの番組情報メタデータと SI の情報を結
びつけるために用いることになる。
番組情報メタデータは、
MPEG-7 や、
TVAnytime のスキーマを用いることが可能であろう。
MPEG-7 は映像情報に関するメタデータのスキーマであり、TVAnytime のメタデータは番
-2-
組名や放送事業者情報など、放送に特化したメタデータをつけることに用いることができ
る。TVAnytime における番組を表現するためのメタデータは、コンテンツ記述メタデータ
と呼ばれ、コンテンツに関する一般的な情報を記述する。個々のコンテンツの内容に関す
る情報と、複数のコンテンツをまとめたグループ単位で内容を記述することができる。
例えば、番組の情報は、次のように表現される。
<?xml version="1.0" encoding="utf-8"?>
<TVAMain xmlns="urn:tva:metadata:2004" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" …
xml:lang="ja" publisher="XXX Corp.">
<CopyrightNotice>Copyright(C) 2005 XXX Corp. All Rights Reserved.</CopyrightNotice>
…
<ProgramDescription>
<ProgramInformationTable>
<ProgramInformation programId="crid://XXX.com/00123">
<BasicDescription>
<Title>番組タイトル</Title>
<Synopsis>番組概要</Synopsis>
<Genre href="urn:tva:metadata:cs:ARIBContentCS:2004:3.2.11"/>
<ParentalGuidance><mpeg7:MinimumAge>5</mpeg7:MinimumAge></ParentalGuidance>
<Language type="original">ja</Language>
<CaptionLanguage>ja</CaptionLanguage>
<PurchaseList><PurchaseIdRef>price001</PurchaseIdRef></PurchaseList>
</BasicDescription>
<MemberOf crid=”crid://XXX.com/MondayDrama2005”/>
</ProgramInformation>
…
<ProgramInformationTable>
…
<GroupInformation groupId="crid://XXX.com/MondayDrama2005" numOfItems="48" ordered="true">
<GroupType value="series" … />
<BasicDescription>
<Title>シリーズ１</Title>
<Synopsis>番組概要その１ </Synopsis>
</BasicDescription>
</GroupInformation>
…
</GroupInformationTable>
…
</ProgramDescription>
…
</TVAMain>
この例では、タイトルが”番組タイトル”、概要が、”番組概要”ジャンル分類スキームの”
時代劇”に分類される。視聴対象は、
”5 歳以上”
、言語キャプションは日本語で、値段は”
price001 ”となっている。また、この番組のメンバー情報として番組のシリーズが
<GroupInformation>で表現されている。この場合、タイトルが”シリーズ１”というシリ
ーズで、全 48 話、順序のある内容であることが示されている。一部のスキームは MPEG-7
の枠組みを利用している。このように複数のスキームを組み合わせて使って重複したデー
タ構造の定義を避けて、情報を表現することできることは、メタデータ利用の効果の一つ
といえる。
一方、視聴者の嗜好情報について、TVAnytime では、次のように定めている。
-3-
視聴嗜好のためのメタデータは、
①
FilteringAndSearchPreference（フィルタリング&サーチ・プリファレンス）
②
BrowsingPreference（ブラウジング・プリファレンス）
に分類され、①は、コンテンツの選択の嗜好を表現し、②は、コンテンツ視聴時の視聴パ
ターンの嗜好を表現する。いずれも、嗜好を適用する際の条件（時間と場所）や、それぞ
れの項目に対する相対的な重要度・重みをつけることができる。これによって、エージェ
ント・ソフトウェアなどによる内容の自動更新の可否なども指定することができる。
これ以外に、視聴者履歴のメタデータも用意されており、コンテンツに対して起こした視
聴者の視聴動作を記録することができる。この視聴履歴メタデータを基に、視聴嗜好メタ
データを構成したり、視聴履歴メタデータをプロバイダに提供し、視聴パターンの統計解
析に利用するなどのアプリケーションも考えられる。
これらのメタデータを蓄積していくことで、TV 番組情報の知識を蓄積していくことができ
る。その結果、「楽しい番組」「怖い番組」といった抽象的な概念を表現することが可能に
なるだろう。その概念は、OWL などのオントロジー言語で表現することになることが予想
される。一般的に視聴者が無意識に理解している、タイトル、登場する人物（俳優）
、放送
時間帯にジャンルを補助的に用いることで、ジャンルで分類するよりもより的確なグルー
ピングを行うことが可能となる。そのような概念の表現は、視聴者が見たい番組の推薦を
行う上で有効な情報となる。一方、視聴嗜好メタデータや視聴履歴メタデータをサーバー
に蓄積していくことで、似通った傾向を持つユーザ同士が、まだ未視聴の番組を互いに交
換することを可能とする。これに上記の番組概念を組み合わせると、その視聴者が今見た
いと思っている番組の推薦がより良いものになると思われる。さらに、現在検討が行われ
ているサーバー型放送におけるデータ放送の機能としてメタデータの検索機能があるが、
これを用いることで、テレビ画面上で、番組推薦情報を得ることが可能となり、簡便な操
作によって高度なサービスを視聴者に提供することが可能となる。
まとめ
本稿では、番組情報とユーザの嗜好情報をメタデータにより表現することで、ネットワー
クによるデータ交換を可能にし、相互補完による番組推薦を行える可能性を示唆した。実
際の受信機においては、ネットワーク環境を搭載したものも発売されてきているので、実
現の可能性がないわけではないが、番組情報メタデータの作成や配布についてコスト面や
サービス面において放送事業者としてのメリットがあるようなビジネスモデルが構築でき
ないと運用することは難しい。しかしながら番組情報メタデータを作成していくことは、
長期的にみてテレビサービスの発展が望める下地作りになると考える。放送通信融合社会
のテレビジョンサービスを発展させるためにも、番組情報メタデータや視聴者嗜好情報の
標準化は、必須な要件であると考えられる。
-4-
[附属資料－B.4]
B.4 ネットワーク管理へのオントロジ適用
B.4.1 はじめに
ネットワークハードウェアの小型化により、ネットワークに接続可能な電子機器が次々と
登場してきている。新しい機器の接続だけでなく、2004 年は IP 電話にも注目が集まり、
一部の既存の通信網の IP への置き換えも行われている。ネットワークに接続可能な DVD
などの家電製品も実用化され、外出先からネットワーク経由で録画予約が可能になるなど、
電子機器の新しい使用法も模索されている。
ネットワークと電子機器の進歩によって便利になる一方で、様々な性質と機能を持つ機器
の管理は複雑さを増している。セキュリティや個人情報保護など企業情報の扱いも考慮し
なければならない。対策は多角的に行われなければならず、様々な知識や技術、ソフトウ
ェア、ハードウェアが必要となり、管理コストが増大している。家庭内の機器においても、
ネットワークと機器の設定は複雑になる一方で、必要な機能を使うにはかなり高度な知識
が要求される。
これらの状況に対応するには、機器設定および管理の抽象化と自動化が必要である。現在
は機器の統合的な管理モデルは存在しない。要求されるモデルは、各種機器の細かい差異
を吸収した形での管理と、最適な設定を行うための判断が必要であることから、オントロ
ジの適用が有効と考えられる。
本節では、ネットワーク管理のオントロジ適用の可能性を探るため、現状行われているネ
ットワーク管理の標準化についてまとめ、オントロジの応用を模索する。
B.4.2 ネットワーク自動制御/管理への取り組み
ネットワーク機器の遠隔制御に関しては、IETF (Internet Engineering Task Force) で、
XML をベースとした netconf と呼ばれるプロトコルの標準化作業が進んでいる。IETF で
は、主にバックボーンの運用に関わるエンジニアが多いことから、運用の高度化、低コス
ト化に対する関心が高い。netconf プロトコルは、主にバックボーンに使われる高機能のネ
ットワーク機器を意識して設計されているが、電子機器の高性能化がさらに進めば、ホー
ムサーバなども適用可能となるだろう。以下に、netconf プロトコルの適用範囲と概要を述
べる。
netconf プロトコルは、ネットワークデバイスを管理するためのプロトコルである。ネット
ワーク機器の設定ファイルやシステムの状態情報を検索したり、新しい設定ファイルを機
器に送ることで操作を行ったりする。ネットワーク機器をデバイス、またはサーバ、設定
を行う機器をクライアントまたはアプリケーションと呼び、その間のプロトコルを定義す
る。netconf プロトコルが規定する範囲を図 B4.1 に示す。
-1-
アプリケーション/
クライアント
netconf プロトコル
get-config
edit-config
reply
ネットワーク機器/デバイス
図 B4.1 netconf プロトコルの適用範囲
netconf プロトコルは、RPC を利用している。クライアントは RPC を XML にエンコー
ドし、安全なコネクションを張ってサーバに送る。現在のところ、コネクションとして ssh
を必須、オプションとして SOAP と BEEP をサポートすることが求められている。サーバ
は、XML にエンコードされたレスポンスを返す。リクエストとレスポンスの双方の内容は
すべて XML DTD か XML スキーマかその両方で記述され、その交換に課された文法の制
約が両方の組にわかるようになっている。
netconf プロトコルはクライアントとネットワーク機器とのプロトコルを定めただけであ
るが、これまで各機器ベンダ独自の CLI (Command Line Interface) を利用していた形か
ら、遠隔制御への転換と XML による情報管理技術の導入という点では評価されるだろう。
今後、各種情報の統合による管理や運用、ベンダ間の表現形式の差異の吸収などが期待さ
れるが、現在のところ、全体モデルの必要性は認識されているが具体的な提案はなされて
いない。
B.4.3 ネットワーク管理のアーキテクチャ
現在のインターネットにおいては、ネットワーク機器を直接設定し、ネットワーク機器か
ら出力される管理情報、MIB (Management Information Base) を収集することで運用管理
を行う。MIB は ASN.1 形式で実装されており、これを利用するネットワーク管理ツール
は多く開発され利用されている。現在、ASN.1 形式を XML で表記するための議論も進ん
-2-
でおり、管理情報の有機的な応用の可能性が広がりつつある。一方で、netconf プロトコル
のように制御側でも XML の応用が広がり、制御と管理の双方で統合的に情報を扱う基盤
ができつつある。ネットワーク分野にとっては、表記方式とその柔軟性から XML の利用が
選択されているところがあるが、本来は RDF やオントロジを応用してこそ有機的な情報の
統合が可能となる。そこでまずは、ネットワーク管理運用に関する全体アーキテクチャ
図 B4.2 に提案した。
Visual
XML
Design
tool
Configuration
System
RDF
Metadata
XML
Database
XML Config
Controller
ISP service area
NEW STUFF
Diffserv
P2P
Broadcast
etc.
Current
Management
System
SSH
Polices
Config rules
Devices
etc.
Netconf protocol
Router/
SW
Data Model
And
Description
Home/SOHO
PDA, Video
Devices
Router/
SW
Router/
SW
Router/
SW
SNMP/MIB
BB/
PolicyDB
NMS
Monitoring /Observation
Show
Using
XML
図 B4.2 ネットワーク管理情報アーキテクチャ
ネットワークには、設計、構築、運用、管理、というサイクルがある。まずは設計にあた
りネットワーク構成、規模、接続の情報などが決定される。このような情報は、一般的に
はトポロジ情報として描画される。描画の形式は標準化されていないが、最近では描画さ
れたオブジェクトが XML 形式に変化されるものもある。次に構築にあたって、ネットワー
ク機器やデバイスレベルの情報が詳細化される。ここまでの情報がデータベースに蓄積で
きれば、その後の運用の基礎となる。運用においては、データベースに蓄積された静的な
情報のほかに、運用方針などの情報も必要となる。これが総合的に扱われた上で、最適な
設定情報が決定され、netconf などの制御プロトコルによって各ネットワーク機器に送られ
る。動作する各ネットワーク機器は管理プロトコルによって管理情報を出力し、収集され
る。管理情報は機器からのフィードバックとしてやはりデータベースに入力されることで、
ネットワークのサイクルを統合的に扱う。現状では管理情報の形式以外は標準化されてい
ないためアーキテクチャとしてはまだ動作しないが、今後、これらすべての情報の表現形
-3-
式が標準化され、統合的に扱われていく必要があるだろう。
B.4.4 ネットワーク管理のシステムモデル
前章で述べたアーキテクチャは広範囲、高機能であり、そのまま大規模ネットワークシス
テムに応用するのは難しい。そこでまず、SOHO クラスの小規模ネットワーク管理につい
て考える。SOHO クラスのネットワークの場合、技術的、人材的、コスト的な面からいっ
て、SOHO ネットワーク管理者がすべての情報を管理して判断し設定を行うのは、あまり
現実的でない。特に今後の電化製品の多様化や機器やアプリケーションの組み合わせの複
雑さを考慮すると、詳細な技術情報は SOHO 内でなく SOHO 外に共有する方向が考えら
れる。Plug & Play や、ユニバーサルリモコン、zeroconf (Zero-Configuration, 設定無し
に動作すること) で議論されているのはこの方向性であり、特に小規模ネットワークのシス
テムモデルとしては現実的である。そこで、小規模ネットワーク管理のシステムモデルを
図 B4.3 のように定義する。
設定情報
リクエスト
設定情報
3
図 B4.3 小規模ネットワーク管理のシステムモデル
図 B4.3 に定義したシステムモデルでは、ルータあるいはホームサーバが 2 つの役割を果た
す。1 つは、管理下にある機器、ネットワーク機器、パソコン、家電などの情報を収集する。
さらに管理者の要望も表現する必要がある。ルータはこれらの情報を、小規模ネットワー
クの外に置かれた統合サーバに送り、必要な設定情報を得る。このようなシステムモデル
はユニバーサルリモコンなどで考案されているが、ネットワークの設定管理においてはま
-4-
だ実現されていない。いずれにしても重要となるのは機器や知識の表現である。
B.4.5 ネットワーク管理へのオントロジ適用の可能性
ネットワーク管理には様々なレベルの情報が必要とされているが、現在は人間の知識に頼
っており標準化も統合もされていない。ネットワーク機器はインタフェースがこなれてお
らず、いまだに設定にはネットワークレベルの知識が必要とされる。つまり実現したい機
能をそのまま設定に反映することができず、一旦ネットワークレベルに落として考えなけ
ればならないわけである。実際、ネットワークの運用には様々な条件がからんでおり、簡
単な条件で判定するのは困難であるが、ある程度使い方が限定された範囲であれば、自動
判定も可能になってくると考えられる。
現在のところ、自動設定が実現されないのは、必要な情報を統合的に管理するしくみが確
立していないのが大きな要因のひとつである。情報管理を実現するためには、情報のモデ
ル化と標準的な情報表記方法の確立が必要である。ネットワーク管理に必要な情報には
様々なレベルのものがある。人間が知識として持つものから、各分野にわたる機器の情報、
ネットワークと他の機器との相関関係など新たに記述が必要な情報まである。人間のもつ
知識や要求は、ネットワーク技術者、ネットワーク機器の開発者と、それらを利用するユ
ーザとではレベルが違い、現在では同じ言語でやりとりするのが難しいほど離れている。
ユーザが要求するのは利用にあたっての利便性や安全性であり、機器の設定ではない。こ
れらの言語の差異を埋めるために、オントロジの適用が期待される。ユーザ側の要求とは
例えば以下である。
ユーザの要求
-
セキュリティ状態を守りたい
-
あるソフトウェアを使いたい
-
家電製品をリモートから使いたい
それに対し、実際にネットワーク機器を設定する際には、例えば以下のような動作が必要
となるが、これでも完全ではない。
-
ポートを閉じ、パケット監視あるいはフィルタを行う
-
該当するポートを空け、安全に使えるようパケット監視などを設定する
-
該当するポートを空け、パスワードや必要な通信ソフトウェアをインストールして設定
し、パケット監視などを設定する
この時点ですでにユーザの要求とネットワーク機器に対する設定とでは、言語と動作に大
きな開きがあり、これらを埋めるためにはまず要求の表記とその解析ができるだけの判断
に必要な基盤が必要となる。
-5-
さらに、ネットワーク機器には特に共通モデルがないため、設定を実現するための操作方
法やコマンドなどは各ベンダやバージョンによって異なる。IP アドレスなどはどの機器に
とっても共通な情報であるが、その設定方法は各機器によって異なるのである。また、家
電機器など他の電子機器は、まったく違う設計思想にネットワーク機能が取り込まれてい
るため、言葉の使い方も設定のパラメータも異なってくることが予想される。しかしユー
ザから見た場合、要求事項は同じであるため、これらの差異を各ベンダが表記し吸収する
仕組みが必要である。このような差異の吸収にも、オントロジの適用が期待される。
B.4.6 まとめ
以上、ネットワーク管理に関する動向と問題点を挙げ、さらにオントロジの適用の可能性
を模索した。現在では不足するものが多く、実現には遠い状況ではあるが、ネットワーク
管理の高度化と設定の自動化は、近い将来必ず必要となる技術と考えられる。現在の技術
を組み合わせて限られた機器の相互接続性を実現することはできるかもしれないが、その
場限りの実装はいずれ破綻する。真に利便性のある世界を確立するためには、統合的なモ
デルとその表記方式が必ず必要である。その表記方法には、オントロジ技術が有望であり、
関連ツールも含め、今後の発展を期待したい。
-6-
[附属資料－B.5]
B.5 ベイズ理論の迷惑メール対策への応用
(株)インターネットイニシアティブ
新麗
迷惑メールはいまや社会問題になりつつあり、各事業者は協力して対策にあたっている。
迷惑メール対策には現在、大きく分けて 2 つの方法があり、1 つは、事業者間でのメールの
転送時に認証などにより対策する方法、もう 1 つはユーザへの配信時あるいはユーザが自
分でフィルタを設定して対策する方法である。後者のフィルタによる対策にはベイズ理論
が応用されたものがあり、ある程度の成果を上げている。ここでは、ベイジアンフィルタ
と呼ばれるベイズ理論の応用による迷惑メールフィルタについて簡単にまとめる。
ベイズ理論は、過去に起きた事象の確率を利用して未来を予測する手法である。迷惑メー
ルにはいろいろな種類があるとはいえ、大まかに、広告宣伝を目的とするものと、ウィル
スに感染したメールが大多数を占めるだろう。つまり迷惑メールには同じような用語が含
まれていることが多く、その確率を解析することにより送られてきたメールが、迷惑メー
ルであるかどうかを類推できるのである。以下に、迷惑メール対策への統計的手法の応用
の概略を述べる。
まず準備として以下を行う。
1.
迷惑メールと迷惑メールでないメールをそれぞれ集めたコーパスを作る。
2.
それぞれの集合のテキストをトークンに分割する。スペースや記号でトークンに分割
できる英語と違い、日本語ではトークン分割は簡単ではないが、辞書検索や形態素解
析による分割が考えられている。
3.
各トークンがそれぞれの集合に現れた回数を集計する。
4.
各トークンから、そのトークンが迷惑メールに含まれる確率を得る。
新しいメールが届いたときは、以下のように判定を行う。
ア) メールをトークンへ分解する。
イ) 最も特徴的な 15 のトークンを抽出する。ここで特徴的とは、その単語が迷惑メールに
含まれる確率が 0.5 を超えていることとする。
ウ) 抽出したトークンの結合確率を計算し、閾値を超えたら迷惑メールと判定する。
ここで問題となるのは、4 のトークンが迷惑メールに含まれる確率の計算と、ウ）の統合確
率を計算するところとなる。これらは様々な方式とその改良が提案されているが、以下に
代表的なものを挙げる。
-1-
Paul Graham 方式
Paul Graham 方式ではトークンごとの迷惑メールの確率 pg(w) を以下のように計算する。
あるトークン w が迷惑メールに出現した回数を b、通常のメールに出現した回数を g と
する。迷惑メールの総数を nbad、通常のメールの総数を ngood とする。迷惑メールでは
ないにも関わらず迷惑メールと判定されることを防ぐため、通常のメールに出現したトー
クンの登場個数は 2 倍にする。
pg ( w)
b
nbad
2*g
b
ngood nbad
また全体で 5 回以上出現していない単語は計算から外す。さらに、迷惑メールにしか出現
しないものは確率 0.99、通常のメールにしか出現しないものは 0.01 を与える。これは試
行錯誤の結果で確率的に計算されたものではない。
迷惑メール判定は、各トークンの確率が 0.5 から離れているものを 15 個選んで複合確率を
計算することにより行う。このとき、新しく出現したトークンの確率は 0.4 とする。これも
試行錯誤によって得られた値である。複合確率は以下のように計算する。最終的に得られ
た複合確率が 0.9 を超えた場合に、迷惑メールと判定する。
abc
abc (1 a )(1 b)(1 c)
Gary Robinson 方式
Paul Graham 方式の改良と言われる方法である。
まずトークンごとの迷惑メール出現確率 p(w) を求める。このときに、誤検出を避けるた
めのバイアスはかけない。また全トークンの p(w) の平均値を x とし、トークンの出現回
数を n、ある定数を s (例えば 0.001)としたとき、トークンごとの迷惑メール確率を f(w)
は以下のように与えられる。
f ( w)
( s * x) (n * p ( w)
s n
新しく出現したトークンも同様に計算する。このとき、あるメールが迷惑メールである確
率は、以下の s2 で与えられる。
-2-
P (1
Q 1
P
S
P
1
S2
f ( w1)) * (1 f ( w2)) * ... * (1 f ( wn))^ (1 / n)
( f ( w1) * f ( w2) * ... * f ( wn))^ (1 / n)
Q
Q
S
2
通常のメールに含まれるトークンは個人によって異なるため、個人ごとにトークンの確率
を計算するのが理想的である。しかしそうでなくともベイジアンフィルタによって 99%程
度の精度を得られるという報告は数多くある。なお、ベイジアンフィルタ方式と呼ばれる
迷惑メールフィルタには様々な実装の方式があり、トークンの作成や確率の計算、学習の
させ方も異なる場合がある。本稿は、迷惑メールフィルタにベイズ理論を応用し結果を得
られた一例の報告である。
[参考文献]
Paul Graham: A plan for spam, http://www.paulgraham.com/spam.html, 日本語訳
(Shiro Kawai), http://www.shiro.dreamhost.com/scheme/trans/spam-j.html
-3-
[附属資料－B.6]
B.6 企業組織における将来型文書
ビジネスプロセスとワークロー
ある目的の達成に向けて活動する集合体が組織であり，組織は目的を達成するために活
動する成員から構成される．個々の成員の持つ知識や知恵はドキュメントという目に見え
る形にして初めて，他者に伝達できる情報になる．つまり，ドキュメントは組織における
意思決定過程のコミュニケーションツールとして位置づけることができる．たとえば，企
画会議においては用意された企画提案書に基づいて議論が繰り広げられ，会議の内容を議
事録にするとともに決定事項を企画書にし，関連部署の合意を経て企画が実行される．ド
キュメントは組織の意思決定過程プロセスにおいて，情報を記録し，伝達するための手段
と位置づけられる．このような性質をもつドキュメントをここではビジネスドキュメント
と定義する．
ビジネスドキュメントには一般的に作成，レビュー，審査，承認，配布，保管，廃棄と
いうようなライフサイクルがある．さらに，このライフサイクルに関連した業務プロセス
が存在する．業務を円滑に推進するには，業務プロセスを自動化し，速やかに，正確に情
報（ビジネスドキュメント）を流通させ，必要に応じて情報を参照できる仕組みが必要で
ある．これを実現する1つの手段がワークフロー管理である．近代的な組織は，ビジネスド
キュメントによる記録と伝達，すなわちワークフローで組織内に周知させることにより効
果的に運営される[1]．
本報告では，ビジネスドキュメントに対するワークフローの現状の役割と今後期待され
る適用可能性について考察する．ビジネスドキュメントを本業との適性とビジネスプロセ
スの多様性という２つの要因で分析し，ワークフローの適用性と課題を明らかにする．
1. ワークフロー管理
ワークフローは，ある目的を達成するための業務の流れであり，複数の処理プロセス（以
下，単にプロセスと呼ぶ）からなる．その流れに沿って処理されるべき処理単位を案件と
呼び，案件はネットワークを通じて各プロセスを処理する作業者の計算機に電子的に流さ
れ，作業者は自分の計算機に到着した案件に対し処理を行う．この業務の流れを定義，管
理，制御するものがワークフロー管理システムである．ビジネスドキュメントは，案件を
構成する要素である．ワークフロー管理システムは，多数製品化され，適用事例も多岐に
渡っている[2,3,4]．
ワークフローシステムの導入の効果として，一般的に以下のものが挙げられる[5,6]．
(1) 処理時間(ターンアラウンドタイム)の削減
(2) 誤配・紛失の排除
(3) 追跡可能
(4) ペーパーレス化
(5) 業務プロセスの標準化
-1-
(6) 業務管理の効率化
(7) 業務改革の推進
(8) システム変更の容易化
ビジネスドキュメントとのかかわりという観点では，(1)～(5)の効果が大きい．
ワークフロー管理システムはあらかじめ定義されたビジネスプロセスと呼ぶ業務の流れ
に従って作業を処理する．ビジネスプロセス定義は，図 B.6.1 に示すように，業務の処理
を表す処理ノードと制御方法を表す制御ノードを矢印（アロー）で繋いで作成する．制御
ノードは，１つのドキュメントを複数の担当者に並列に送付したり，条件による分岐，不
在時などの代行，内容に問題がある場合等の差し戻しなど，各種処理の制御に関わるもの
である．多数決で処理を進めるような制御ノードを持つ製品もある．
図 B.6.1 ビジネスプロセス定義の例
2. ビジネスドキュメントの特性と伝達手段
ワークフローのタイプは，従来，対象業務の特性から「アドホック型ワークフロー」
，
「ア
ドミニストレイティブ型ワークフロー」，「プロダクティブ型ワークフロー」の３つに分類
されたり[7]，
「コラボレイティブ型」を加えた４つに分類されることが多い[6]．本報告で
はビジネスドキュメントとビジネスプロセスとの関係で分析を試みる．ビジネスドキュメ
ントを本業との適性とビジネスプロセスの多様性という２つの要因で分析する．本業との
適性は，本業に直接的にかかわるものか，間接的にかかわるものかという軸である．一方
の多様性の軸は，そのビジネスプロセスで起こる事象が反復的，定型的であるか，あるい
はユニーク（非定型的）なものであるかである．
この分類では，図 B.6.2 のような 4 つのセルに分割できる．
(1)本業に関わり，ビジネスプロセスは定型的（プロダクティブ型）
：
-2-
融資稟議書，保険請求書，クレーム問い合わせ票，目標管理など
(2)本業に直接かかわらず，ビジネスプロセスは定型的（アドミニストレイティブ型）
：
旅費申請書，精算書，購買伝票，勤務票など
(3)本業に関わり，ビジネスプロセスは多様（クリエイティブ型）
：
企画書，提案書，稟議書，設計仕様書，マニュアル，特許など
(4)本業に直接かかわらず，ビジネスプロセスは多様（アドホック型）
：
議事録，日報，儀礼的文書(招待状や委任状など)など
さらに，上記のビジネスドキュメントの分類に対して適切な情報伝達手段を考えてみる
と以下のようになる.
プロダクティブ型は，高度で複雑なプロー制御が必要とされるが，プロセスは固定的な
ためワークフローでの処理が向いている．アドミニストレイティブ型は，一般事務におけ
る各種伝票類の処理である．扱う情報は定型的で，処理するプロセスも固定的なため，も
っともワークフローが適した業務である．クリエイティブ型は，企画書，提案書，稟議書，
マニュアル，特許など創造性の高いビジネスドキュメントの作成が対象である．このタイ
プの業務は，共同作業で作成する場合が多いため，従来はコラボレイティブ型で分類され
ていた．このクリエイティブ型は，作成の複雑さや共同作業という特性により，ワークフ
ローだけで業務を実現することは極めて難しい．また，ドキュメントを長期間取り扱う業
務も多く，バージョン管理やビュー管理，コメント付与などの文書管理機能も必要となる．
アドホック型のドキュメントは不定期に発生し，プロセスも固定的ではないため，電子メ
ールや掲示板を利用する方法が一般的である．回覧や決裁の状況をモニタリングしたり，
記録を残したい場合などは，ワークフローが利用することがある．
プロダクティブ
クリエイティブ
直接
本業との関わり
企画書・提案書
契約書
稟議書
マニュアル
特許
議事録
日報
儀礼的文書
（招待状，委任状）
ＷＦ＋
ｸﾞﾙｰﾌﾟｳｪｱ
ﾌｧｲﾙ共有，
電子ﾒｰﾙ
非定型
ＷＦ
旅費申請・精算書
購買伝票
勤務票
アドホック
間接
ＷＦ＋
基幹ｼｽﾃﾑ
融資稟議書
保険請求書
クレーム・問合せ票
目標管理
アドミニストレイティブ
ビジネスプロセス
定型
図 B.6.2 ドキュメント特性と情報伝達手段との関係図
-3-
3. ビジネスドキュメントとプロセスのリエンジニアリング
ドキュメントのライフサイクルとそれぞれのフェーズで利用される IT ツールとの関係は，
図 B.6.3 のようになる．
ドキュメントのライフサイクル
創生
個別ツール
検索ｴﾝｼﾞﾝ
KM
流通
活用
保管
メール
文書管理
検索ｴﾝｼﾞﾝ
掲示板，ファイル共有
ワークフロー
KM
図 B.6.3 ドキュメントのライフサイクルと IT ツール
創生フェーズでは，目的にあったビジネスドキュメントの作成に直接役立つ最適なツー
ルはほとんど用意されておらず，ワープロソフトやスプレッドシートなどの汎用ツールあ
るいはそれぞれのドキュメントに適した個別ツールを利用しているケースが多い．創生フ
ェーズに役立つ汎用ツールとしては，過去に作成したドキュメントやインターネットを検
索するための検索ツールや類似検索などの機能を持つナレッジマネージメントツールがあ
る程度である．ドキュメントの流通，伝達フェーズでは，メール，掲示板，ワークフロー
などのツールが利用されることが多い．保管，利用フェーズでは，文書管理や掲示板，検
索エンジン，ナレッジマネージメントツールなどをドキュメントの特性に応じて利用した
り，組み合わせて利用されることが多い．
各フェーズで利用される IT ツールを見てみると，創造性や品質が期待され，もっとも時
間がかかる創生フェーズのサポートが不十分であることが分かる．
つぎに，図 B.6.4 により，業務改善（リエンジニアリング）という観点でビジネスプロ
セスを見てみる．アドミニストレイティブ型とプロダクティブ型は，定型的なビジネスプ
ロセスで定型的かつ単純なフォーマットをもつドキュメントが多く，創生フェーズより，
流通フェーズの方が時間を要するため，ワークフローの導入効果が大きい．なお，プロダ
クティブ型は，定型的なビジネスプロセスであるが，創生フェーズや流通フェーズでノウ
ハウやネゴシエイションが必要な人間系のプロセスであるため，意志決定プロセスを支援
する必要がある．クリエイティブ型では，主に創生フェーズで複数の人が複雑に関係し，
全体的には定型的ではあるが，伝達フェーズは定型的なプロセスも存在するため，部分的
にワークフローの適用が可能である．創生フェーズは，ドキュメントの作成に多大な時間
を要し，品質の確保も必要であり，複数の人が関与するドキュメントが多いため，ドキュ
メント作成支援ツールや共同作業の支援がリエンジニアリングに効果的である．アドホッ
ク型は，他の型と比べて創生，伝達フェーズとも多大な時間を必要とせず，主に人間系で
の処理が中心のため，リエンジニアリングという観点では優先度が低い．また，プロセス
-4-
の反復性も低いため，ワークフローの適用可能性も低い．
創生プロセスの
創生プロセスの
リエンジニアリング
リエンジニアリング
プロダクティブ
クリエイティブ
直接
本業との関わり
企画書・提案書
契約書
稟議書
マニュアル
特許
議事録
日報
儀礼的文書
（招待状，委任状）
ＷＦ＋
ＷＦ＋
ｸﾞﾙｰﾌﾟｳｪｱ基幹ｼｽﾃﾑ
ﾌｧｲﾙ共有，
電子ﾒｰﾙ
融資稟議書
保険請求書
クレーム・問合せ票
目標管理
業務プロセスの
業務プロセスの
リエンジニアリング
リエンジニアリング
ＷＦ
旅費申請・精算書
購買伝票
勤務票
アドホック
間接
非定型
アドミニストレイティブ
ビジネスプロセス
定型
図 B.6.4 ビジネスプロセスのリエンジニアリング
ワークフローは定型的なビジネスプロセスを持つビジネスドキュメントの情報伝達手段
には向いているが，非定型なビジネスプロセスを持つビジネスドキュメントには向いてい
ない．また，クリエイティブ型やアドホック型は人間系のかかわりが多く，ワークフロー
に載らない意思決定プロセスが必要である．特に，クリエイティブ型で作られる文書は，
経営に直接影響する製品･サービスの開発や意思決定に関する重要な文書が多く，さらに複
数の人間が複雑に関与し，文書のライフサイクルも長いという特性がある．これらの業務
を支援するためには，高度な支援機能が必要である．
以上の通り，ワークフローは限界はあるもののうまく使えば極めて有効なオフィスツー
ルである．ビジネスドキュメントベースのシステムを構築する際の指針をまとめると以下
の通りになる．
(1)定型プロセス…ワークフローでビジネスプロセスを自動化し，徹底的な業務のコスト
ダウンを図る．
(2)人間系プロセス…検討を含め，システム作りに時間とコストをかける．特に，ドキュ
メントを作成(創造)するための創生プロセスや共同作業を支援することが品質の向上とコ
ストダウンに大きく寄与する．
4. 人間系プロセスにおけるワークフローの適用可能性
人間系プロセスについて，ワークフローを適用した効果的な支援策をいくつかの具体例
により考察する．
-5-
5.1
特許創生～出願
近年，特許発明等の知的財産は，従来型の「権利による保護」の観点だけではなく，ビ
ジネスとして知的財産活用するという機運が高まっている．つまり，自社のビジネスにと
ってコアとなる知的財産により，企業競争力をつけ，ビジネスを優位に勧めることが企業
戦略の１つとなってきている．このような背景から，ビジネスを優位にする有効な特許を
いかに早く出願し，権利化するかが大きな課題となってきている．この特許創生から出願
までの業務プロセスは，図 B.6.5 のようなビジネスプロセスになっている．
図 B.6.5 特許出願業務プロセス
具体的には，アイディアを特許として作成する特許創生フェーズ，出願するための関連
書類を作成する出願書類作成フェーズ，これらの書類の部内審査・承認フェーズ，知財部
門の評価フェーズ，必要に応じて弁理士のブラッシュアップフェーズを経て，特許庁に出
願される．また，作成された特許はデータベース化され企業内で活用されるようなサイク
リックなプロセスになっているケースも多い．特許創生以降のビジネスプロセスは，ワー
クフルー化することが容易で，有効である．一方，もっとも時間がかかり，支援が要求さ
れる人間系プロセスの特許創生プロセスは各社毎にそれぞれの方法論やノウハウで進めら
れている．ほとんど公表されていないが，極めて IT 化が難しいプロセスである．この特許
創生プロセスをフェーズ毎の活動内容とそこで利用されると考えられるドキュメントある
いはツールについてまとめたものを表 B.6.1 に示す．
表 B.6.1 特許創生プロセス
フェーズ
活動
ドキュメント【ツール例】
アイディア
創生
特許調査
【特許検索ツール】
マップ作成
特許マップ
【マップ作成ツール】
ブレーンストーミング
アイディアシート
クレーム検討
クレーム検討シート
執筆
（キークレーム＋代替案等）
特許執筆
明細書、図面、要約書
ﾌﾞﾗｯｼｭｱｯﾌﾟ特許のブラッシュアップ
-6-
明細書、図面
特許創生のプロセスは，特許のアイディアを創生するフェーズ，アイディアを具体化し，
特許を執筆するフェーズ，さらに特許をブラッシュアップするフェーズの大きく 3 フェー
ズからなる．アイディア創生フェーズでは，特許検索ツールなどを利用して特許を調査し，
その結果を特許マップにまとめ，特許マップを利用して発明の分野や目的などを決めてア
イディアを検討する．また，アイディアシートなどを作成してチームでブレーンストーミ
ングを実施して特許のアイディアを固める．執筆フェーズでは，クレーム検討シートなど
を利用して，キーとなるクレーム（特許の請求項）を検討・拡充し，明細書テンプレート
などに基づいて明細書を執筆する．ブラッシュアップフェーズでは，作成した明細書や図
面をもとにさらにブラッシュアップする．
表 B.6.1 を見ても分かるように，各活動で利用されるツールはほとんどないのが実情で
ある．しかし，各フェーズにはプロセスがあり，そこで利用されるドキュメントの関連性
も強く，特許は XML で扱われているという実態からも，各種の知的支援が考えられ，知的
生産性の向上や品質向上が期待できる．
一方，筆者らの経験によれば，執筆フェーズでの特許執筆の書き方にはノウハウがあり，
このノウハウをツール化することにより，執筆の効率化が期待できる．今後の研究の中で
検討を進めていきたい．
5.2
ナレッジマネージメント
組織において意思決定や製品・サービス改善などを迅速かつ効率的に促進するには，企
業内で創生された膨大な情報・知識をいかに蓄積・活用するかというナレッジマネージメ
ントが重要になっている．
ナレッジを拡充し，組織的に利用できるようにするために，ビジネスドキュメントを知
識として取り込む仕掛けと利用する仕掛けが必要である．
この例を図 B.6.6 より説明する．
図 B.6.6 KM とワークフロー
まず，ビジネスドキュメントの作成(創造,起案)，業務処理（審査，承認）
，保管・廃棄
-7-
という一連の流れを業務プロセスとして定義する．この業務プロセスの中でビジネスドキ
ュメントを作成する際に，知識検索エンジンで過去に承認を得た文書の中から作成したい
文書の内容に近いものを検索する．次にこの文書を修正することにより，品質の高い文書
を短時間で作成できる．また，審査，承認，合議の過程でも過去の文書を参照することに
より，判断基準を明確化できるため，意思決定を迅速に実施できる．最後に，承認，合議
が終了した文書を蓄積する．業務で作成された文書をワークフローで自動的に取り込むこ
とにより，巨大なナレッジ・データベースができる．これをさらに，このナレッジ・デー
タベースを活用する仕掛けをビジネスプロセスに盛り込み，ワークフローで実現すること
により，文書の作成効率と文書の処理効率が上がる．ワークフローの役割は，業務毎にこ
のナレッジ活用サイクルをビジネスプロセスとして実現することである．これにより，様々
な業務の処理効率向上はもちろん，ナレッジの創造，流通，活用のサイクルをルーチンワ
ークとして取り込むことができる．日々発生する情報の正式バージョンや最終バージョン
をタイムリーに過不足なく蓄積して完成度の低い不要な情報を排除したクリーン化された
情報だけが入ったナレッジ・データベースの構築も可能となる．また，業務プロセスの起
案時や審査・承認時等必要な場面でナレッジ・データベースから適切な情報をスピーディ
に入手し，所望の起案書を短時間で作成し，審査や承認の工程で適切な判断のための一助
として利用することも可能になる．
ナレッジ・サイクルでは，ナレッジ創造のフェーズがもっとも時間がかかるところであ
り，システム化が難しい部分である．概念検索やあいまい検索，類似検索などの機能を持
った知識検索ツールが数多くでているので，これらを活用したシステム化が１つの解にな
るであろう．
5.3
プロジェクト管理
情報システム開発では，プロジェクト管理が重要である．情報システム開発のプロジェ
クトでは，仕様書やプログラムなどの膨大な成果物の管理が不可欠で，成果物，すなわち
文書を一元的に管理し，再利用を促し，作業効率を向上させ，円滑なプロジェクトが推進
できる仕掛けが必要である．これを実現するためには，主に以下の機能が必要となる．
①成果物の一元管理…各工程で作成した仕様書やプログラム，管理帳票等を一元管理し，
再利用を図る．バージョン管理や更新時の排他管理も実施する．
②開発プロセスの管理…全工程の作業プロセスを明確化し，その進捗，実績を記録する．
過去のプロジェクトのプロセスをテンプレートとして新規プロジェクトに活用する．
③成果物のライフサイクル管理…プロジェクトのプロセスの中で発生する文書(成果物)
のライフサイクル(作成,レビュー，審査，承認，検査など)を管理する．
上記において，①は文書管理機能の利用で実現できる．②は文書管理機能を拡張するか，
プロジェクト管理ツール独自の機能として実現する．③の実現にはワークフローの利用が
有効である．ここでのワークフローの役割は，成果物のライフサイクルの管理であり，モ
ニタリング機能による各成果物の進捗状況の把握や期限管理等の管理作業も含む．
-8-
一方，プロジェクト管理業務のシステム化においてもっとも重要な機能は，ユーザーイ
ンタフェースである．ユーザーインタフェースの操作性が悪ければ，業務効率も下がり，
システムも利用されなくなるので，ユーザーインタフェース部分の機能を十分に検討する
必要がある．メンバとして複数のプロジェクトに所属する場合もあるため，複数プロジェ
クトへのメンバ登録機能やプロジェクト全体をプロジェクトごとに見るためのビューや自
分が担当している作業のみを見るためのプライベートなビューも必要となる．
6.
おわりに
以上，ビジネスドキュメントに対するワークフローの現状の役割と今後期待される適用
可能性について考察した．ビジネスドキュメントを本業との適性とビジネスプロセスの多
様性という２つの要因で分析し，ワークフローの適性を明らかにした．特に，人間系のか
かわりがあるクリエイティブ型のビジネスドキュメントは，ワークフローに載らない創生
プロセスや意思決定プロセスを支援することが重要であり，特に人間系のプロセスをシス
テム化すことが課題であること示した．最後に，人間系プロセスを持つビジネスドキュメ
ントに対するワークフローの適用可能性と役割，新たなツールの必要性について考察した．
今回は，組織内でのビジネスドキュメントとワークフローを対象とした．ビジネスドキ
ュメントは，サプライチェーン・マネージメントやB2Bでは，社外とのやりとりが発生する
ワークフローになる．ここでは，ビジネスドキュメントのデータフォーマットとデータ交
換手順に関する標準化が必要である。代表的なものとして，ebXML[8]があり，OASIS[9]と
国連(UN/CEFACT)の標準として定められつつある．データフォーマットの標準化は，各業界
団体でXMLによるビジネス文書の標準化が積極的に推進されている．
購買注文，送り状などためのUBL(Universal Business Language)[10]や人材情報のHR-XML[11]
は，アドミニストレイティブ型のビジネスドキュメント用の標準XMLであり，証券取引のための
FIXML[12]，財務情報のためのXBRL[13]などは，プロダクティブ型のビジネスドキュメント用であ
る．これらの社外と関係するビジネスドキュメントとワークフローについては，今後の課題であ
り，本研究の一環として推進する．
文献
[1] 大野邦夫: オフィス文書と XML（その３：ワークフローとビジネスロジック管理）, 電子通
信学会オフィスインフォメーション研究会報告, OIS-2003-68, (2004.1)
[2] 電気学会ワークフロー調査専門委員会編：ワークフローの実際，日科技連出版社(1999)
[3] 宍戸周夫，杉山秋：Groupmax ワークフロー，IDG コミュニケーションズ(1999)
[4] 速水治夫，渋谷亮一,他 : ここまで来たワークフロー管理システム第 3 回(3)ワークフロー製
品の実際，情報処理，Vol.40，No.5，pp507-513(May 1999)
[5] 財部忠夫：ワークフローによる業務改善，オペレーションズ・リサーチ，vol.41, no.10,
pp.559-568(Oct. 1996)
[6] 戸田保一，飯島淳一，速水治夫，堀内正博：ワークフロー，日科技連出版社(1998)
[7] D. Georgakopoulos and M. Hornick : An Overview of Workflow Management: From Process
Modeling to Workflow Automation Infrastructure, Distributed and Parallel Database,
3, pp.119-153 (1995)
[8] ebXML: http://www.ebxml.org/
[9] OASIS: http://www.oasis-open.org/
[10]
OASIS Universal Business Language TC:
http://www.oasis-open.org/committees/ubl/
[11]
HR-XML:http://www.hr-xml.org/
-9-
[12]
[13]
FIXML: http://www.fixprotocol.org/
XBRL: http://www.xbrl.org/
-10-
[附属資料－B.7]
B.7 RSS 現状と将来
2005/2/18
鈴木潤一
はじめに
RSS は、RDF から派生した記述言語として、近年非常な勢いで広まっている。ニュースサ
イトやブログと呼ばれる個人の日記サイトでも利用されている。RSS は、Web 上のコンテ
ンツを要約した内容を XML 形式で表現したものであり、主に XML/RPC 形式で送受信さ
れ、RSS を読むことができるソフトなどで表示することができる。これによって、さまざ
まな Web 上の情報を集約することができ、効率的な情報収集手段として期待されている。
RSS の利用の仕方に決まりはなく、Web 上でのサービスでのさまざまな試みが実践されて
おり、今後も Web 上でのさまざまなサービスの中で利用されることが予想される。ここで
は、RSS の生い立ち、RSS のバージョンによる仕様の違いや問題点、RSS を利用したサー
ビスについて考察する。
RSS の生い立ち
RSS は、米 Netscape 社が自社の「チャンネル」を登録するための手段として、1999 年 3
月に開発した。0.9 と呼ばれるこのバージョンは、RDF をベースとしていた。しかしなが
ら、0.9 では定義されているタグが少なかったため、その後 RSS の功労者と呼ばれる
UserLand 社の創始者である Dave Winer が、同名のブログソフトで用いた RSS0.91 が登
場する。ブログの内容や著者を記述するためにタグを拡張したこのバージョンにより、ブ
ログでの RSS が一般化されることとなった。しかし、より拡張性を求めるグループが XML
の名前空間を用いて拡張できる RSS1.0 を 2000 年 12 月に提案した。しかし、それと並行
して RSS0.92,0.93,094 が提案されたことで２つの流れに分断され混乱が始まった。これら
の混乱を収めるために Dave Winer が UserLand 社を退社し、ハーバード大学の研究者に
なったことで、2003 年 7 月に 2.0 が公開される。しかし、IBM の Sam Ruby らのグルー
プがベンダーニュートラルな規格として ATOM を提唱した。ATOM は google で採用され
たことで有名となった。2004 年になり RSS がかなり普及したことで、RSS2.0 と ATOM
両者に歩み寄りの姿勢が見られ IETF のもと、統合の動きが始まり現在に至る。
RSS のバージョンの違い
現在よく利用されている RSS0.91,RSS1.0,RSS2.0,ATOM0.3 について、タグの種類である
要素名を記述し考察する。尚、考察にあたっては同一のブログから出力された内容を前提
とする。
-1-
RSS0.91
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
"http://my.netscape.com/publish/formats/rss-0.91.dtd">
<rss version="0.91">
<channel>
<title>J's Research</title>
<link>http://www.junbou.net/blog/research.php</link>
<description></description>
<docs>http://backend.userland.com/rss091</docs>
<language>ja</language>
<image>
<url>http://www.junbou.net/blog/nucleus/nucleus2.gif</url>
<title>J's Research</title>
<link>http://www.junbou.net/blog/research.php</link>
</image>
<item>
<title>ここにタイトルを書く</title>
<link>http://www.junbou.net/blog/research.php?itemid=101</link>
<description>ここに本文を書く
</description>
</item>
</channel>
</rss>
RSS0.91 の特徴は、XML 文全体が DTD によって定義されていることと、<channel>要素
がコンテンツを表現する全体の要素となっていることである。各コンテンツは、<channel>
要素の子要素である<item>要素で表現され、<title>、<link>、<description>でコンテンツ
のタイトル、リンク先、詳細な記事が記述される。
RSS1.0
<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:admin="http://webns.net/mvcb/" xmlns="http://purl.org/rss/1.0/" xml:lang="ja">
<channel rdf:about="http://www.junbou.net/blog/research.php">
<title>J's Research</title>
<link>http://www.junbou.net/blog/research.php</link>
<description></description>
<dc:language>ja</dc:language>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://www.junbou.net/blog/research.php?itemid=101" />
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://www.junbou.net/blog/research.php?itemid=101">
<title>ここにタイトルを書く</title>
<link>http://www.junbou.net/blog/research.php?itemid=101</link>
<description>ここに本文を書く
</description>
<dc:subject>General</dc:subject>
<dc:creator>junbou</dc:creator>
<dc:date>2005-02-11T01:17:56-07:00</dc:date>
</item>
</rdf:RDF><
-2-
RSS1.0 からは DTD の記述がなくなり、XML 名前空間が定義されている。またルート要素
が<rdf>になり、RDF ベースの記述となっている。<channel>要素と<item>要素は分離さ
れ、同一階層となっている。<channel>要素内は RDF プロパティとなっており、<items>
要素では item についての順序性を定義している。<dc:language>要素では、Dublin Core
における言語の種類を記述している。
RDF2.0
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>J's Research</title>
<link>http://www.junbou.net/blog/research.php</link>
<description></description>
<language>ja</language>
<generator>Nucleus v3.1</generator>
<copyright>©</copyright>
<category>Weblog</category>
<docs>http://backend.userland.com/rss</docs>
<image>
<url>http://www.junbou.net/blog/nucleus/nucleus2.gif</url>
<title>J's Research</title>
<link>http://www.junbou.net/blog/research.php</link>
</image>
<item>
<title><![CDATA[ここにタイトルを書く]]></title>
<link>http://www.junbou.net/blog/research.php?itemid=101</link>
<description><![CDATA[ここに本文を書く 
ここに続きを書く 
]]></description>
<category>General</category>
<comments>http://www.junbou.net/blog/research.php?itemid=101</comments>
<pubDate>Thu, 10 Feb 2005 18:17:56 -0700</pubDate>
</item>
</channel>
</rss>
RSS2.0 は、再び RSS0.91 をベースとした簡略的な記述に戻っている。<channel>がコンテ
ンツ全体を記述する要素となっており、<item>が子要素となっている。<category>要素や
<comments>など、新しい要素が加わっておりブログを意識した構成となっている。
ATOM0.3
<?xml version="1.0" encoding="UTF-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
<title>J's Research</title>
<link rel="alternate" type="text/html" href="http://www.junbou.net/blog/research.php" />
<generator url="http://nucleuscms.org/">Nucleus v3.1</generator>
<modified>2005-02-11T01:17:56Z</modified>
<entry>
-3-
<title type="text/html" mode="escaped"><![CDATA[ここにタイトルを書く]]></title>
<link rel="alternate" type="text/html" href="http://www.junbou.net/blog/research.php?itemid=101" />
<author>
<name>junbou</name>
</author>
<modified>2005-02-11T01:17:56Z</modified>
<issued>2005-02-11T01:17:56-07:00</issued>
<content type="text/html" mode="escaped"><![CDATA[ここに本文を書く 
ここに続きを書く 
]]></content>
<id>http://www.junbou.net/blog/research.php:18:101</id>
</entry>
</feed>
ATOM0.3 ではルート要素が<feed>となり、<rss>要素や<channel>要素がなくなり、今ま
で説明した RSS とは異なっている。<item>要素が<entry>に変わり、<modified>要素や
<id>要素が加ったことで、コンテンツ管理を意識した要素が加えられている。
以上、４つのバージョンを比較したところ、RSS1.0 だけ RDF をベースとしていて、拡張
性があり名前空間も複雑である。他は要素に同一の名前空間を用いた基本要素で構成され
ている。また、RSS2.0 は RSS0.91 は<rss>要素がルート要素となっているのに対して、
ATOM0.3 は、<feed>要素がルート要素となっている。これにより ATOM0.3 と他の RSS
とは互換性がないことがわかる。また、RSS2.0 と ATOM0.3 の要素からはブログを意識し
ていることがわかる。尚、現在では RSS1.0 と RSS2.0 および ATOM0.3 が普及しており、
RSS0.91 に対応しているサービスは少なくなっている。
RSS を利用したサービス
RSS はその簡略さから、ニュース情報やブログの記事に利用されているが、最近ではさま
ざまな分野での利用が増えつつある。ここでは２つのサービス例を紹介したい。
RSS ブックマーク(株式会社はてな)
ブックマークを RSS 化するサービスを用いることで、ブログにブックマークを表示させる
ことが可能となる。これによって、ブックマークの管理が一元化される。
<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF
xmlns="http://purl.org/rss/1.0/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:lang="ja">
<channel rdf:about="http://b.hatena.ne.jp/jumbou/rss">
<title>jumbou のブックマーク</title>
<link>http://b.hatena.ne.jp/jumbou/</link>
<description>jumbou のブックマーク</description>
<items>
<rdf:Seq>
-4-
<rdf:li rdf:resource="http://ascii24.com/news/"/>
<rdf:li rdf:resource="http://www.asahi.com/"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://ascii24.com/news/">
<title>ASCII24 - Top Page</title>
<link>http://ascii24.com/news/</link>
<description>米 HP 社は 9 日(現地時間)、会長兼 CEO のカーリー・フィオリーナ(Carly Fiorina)氏が辞任
したと発表した。CFO のロバート・ウェイマン(Robert P. Wayman)氏が暫定的に CEO に就任する。 NTT ドコモ、おちま
さと氏プロデュースの新プロジェクト“ダットエムオー”を発表──P901i のカスタムジャケットに採用 2005 年 2 月 10
日 (株)エヌ・ティ・ティ・ドコモは 9 日、都内・原宿の商業施設“ラフォーレ原宿”...</description>
<dc:date>2005-02-13T12:35:58+09:00</dc:date>
</item>
<item rdf:about="http://www.asahi.com/">
<title>アサヒ・コム</title>
<link>http://www.asahi.com/</link>
<description>北朝鮮外務省は、核開発問題に関して声明を発表し、第２期ブッシュ米政権が敵視政策を変
えていないとして、
「６者協議への参加を無期限、中断する」と表明。さらに「自衛のために核兵器を造った」と核兵器
の製造・保有を初めて公式に表明した。(18:48)</description>
<dc:date>2005-02-13T12:31:47+09:00</dc:date>
</item>
</rdf:RDF>
RSS1.0 で作成され、各<item>要素が一つのブックマークとなっている。<description>要
素については、ブックマーク先のサイトから記事を自動的に生成している。
RSS カレンダー(RSS Calendar 社)
RSS カレンダーは、スケジュール管理を RSS で行うサービスである。RSS ブックマークと
同様に RSS リーダーやブログで読ませることでスケジュールの公開や一元管理が行われる。
<?xml version="1.0" encoding="windows-1252" ?>

<rss version="2.0">
<channel>
<title>RSSCalendar Monthly - Junichi Suzuki</title>
<link>http://www.rsscalendar.com</link>
<description>RSSCalendar</description>
<language>ja</language>
<copyright>Copyright 2005 Junichi Suzuki. All Rights Reserved.</copyright>
<lastBuildDate>Sat, 19 Feb 2005 07:46:24 GMT</lastBuildDate>
<generator>RSSCalendar.com</generator>
<managingEditor>junichi.suzuki@oracle.com</managingEditor>
<webMaster>john@rsscalendar.com</webMaster>
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
<image>
<title>RSSCalendar.com</title>
<url>http://www.rsscalendar.com/rss/images/rsscalendar_logo.gif</url>
<link>http://www.rsscalendar.com</link>
<width>144</width>
<height>25</height>
</image>
<item>
<title>visit A company</title>
<link>http://www.rsscalendar.com/rss/view.asp?k=919807a68a8d275b2e7dd47c1ad6a69c</link>
<description><a
href="http://www.rsscalendar.com/rss/rsvp.asp?k=919807a68a8d275b2e7dd47c1ad6a69c">RSVP</a> | <a
href="http://www.rsscalendar.com/rss/comments.asp?k=919807a68a8d275b2e7dd47c1ad6a69c">Comments</a> Dat
-5-
e: Feb 23, 2005 (Wed) Location: kawasaki Address: nakahara-ku City/State: kawasaki,
kanagawa Postal Code: 211-0068  <a
href="http://maps.yahoo.com/py/maps.py?addr=nakahara%2Dku&csz=kawasaki%2C+kanagawa+211%2D0068
target="_blank">Map It</a>  <a
href="http://www.rsscalendar.com/rss/view_wx.asp?z=211-0068&k=919807a68a8d275b2e7dd47c1ad6a69c">Wx</a> Country: Japan Start: 10:00 AM End: 11:30 AM (Note: Junichi's local date/time) to
expain the products - <a
href="http://www.rsscalendar.com/rss/add.asp?k=919807a68a8d275b2e7dd47c1ad6a69c" title="Add This to My
RSSCalendar">Add This to My RSSCalendar</a> - <a
href="http://www.rsscalendar.com/rss/vcs.asp?k=919807a68a8d275b2e7dd47c1ad6a69c" title="Ensure application
is running prior to importing">Import to MS Outlook (VCal)</a> - <a
href="http://www.rsscalendar.com/rss/ics.asp?k=919807a68a8d275b2e7dd47c1ad6a69c" title="Ensure application
is running prior to importing">Import to Other (ICal)</a> - <a
href="mailto:junichi.suzuki@oracle.com">Contact Junichi</a> <a
href="http://www.rsscalendar.com/rss/public/signup.asp">Sign Up at
RSSCalendar.com</a></description>
<pubDate>Wed, 23 Feb 2005 01:00:00 GMT</pubDate>
<guid
isPermaLink="true">http://www.rsscalendar.com/rss/view.asp?k=919807a68a8d275b2e7dd47c1ad6a69c</guid>
<comments>http://www.rsscalendar.com/rss/comments.asp?k=919807a68a8d275b2e7dd47c1ad6a69c</comments>
<enclosure url="http://www.rsscalendar.com/rss/ics.asp?k=919807a68a8d275b2e7dd47c1ad6a69c" length="4096"
type="text/calendar" />
</item>
</channel>
</rss>
RSS2.0 で作成されており、<description>要素に細かい記述が書けるようになっている。現
在、日本語には対応していない。
まとめ
本稿では、RSS の生い立ちバージョンの違い、利用サービス例を紹介することで、RSS の
今後の利用の可能性を示唆した。RSS のバージョンが統一されてはいないが、方向性とし
て Web コンテンツを体系化させることでは一致している。特に RSS1.0 は RDF ベースと
いうことで拡張性が高く、セマンティック Web への発展が期待される。紹介した新しいサ
ービスでは RSS はニュースやブログでの限られた利用に留まらず、コンテンツ管理やグル
ープウェアでの利用も可能であることが実証されつつある。これは Web 上での作業を効率
化させることとなり、Web が新たな用途として活性化されるトリガーとなるだろう。
-6-
この事業は、競輪の補助金を受けて実施したものです。
平成 16 年度
将来型文書統合システムに関する標準化調査研究
成果報告書
平成 17 年 3 月
発行財団法人日本規格協会
〒107-8440 東京都港区赤坂 4-1-24
電話（03）3592-1408
印刷スタンダード・メンテナンス株式会社
〒107-8440 東京都港区赤坂 4-1-24
日本規格協会ビル内
電話（03）3585-4558
－禁無断転載―

Download Report

皮膚内活性酸素産生に及ぼすマグネシウムの影響

Page 1 Page 2 アウルービアノークインテット V。ー

将来型文書統合システムに関する標準化調査研究

皮膚内活性酸素産生に及ぼすマグネシウムの影響

Page 1 Page 2 アウルービアノークインテット V。ー

Paperzz.com

Your Paperzz