付属資料
WG2成果レポート
1.まえがき . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.セマンティックWebの最新状況 . . . . . . . . . . . . . . . . . . . . . .
4
2.1 RDF仕様の最新動向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 RSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 開発の経緯及び版 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 RSS 1.0(RDF Site Summary)の概要 . . . . . . . . . . . . . . . . . . .
2.2.3 RSS 0.9x及びRSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 使用状況 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 OWL:Webオントロジ言語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 OWLとは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 OWLの仕様 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 OWL関連のツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 トピックマップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 標準化動向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 技術動向 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3 最近の事例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.4 その他 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.オントロジ技術の現状と応用 . . . . . . . . . . . . . . . . . . . . . . . .
4
6
6
7
10
11
12
12
12
12
13
17
17
19
21
22
23
3.1 TV視聴者プリファレンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.2 電子番組表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.3 パーソナルビデオレコーダ(PVR) . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.4 テレビ王国 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.5 視聴者嗜好プリファレンスの今後の課題 . . . . . . . . . . . . . . . . .
24
3.2 エコネット・白物系 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.1 生活家電機器をとりまく動向 . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.2 セマンティックWEB技術適用における課題 . . . . . . . . . . . . .
25
3.2.3 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3 ネットワーク管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.2 ネットワーク管理の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3.3 メタデータ技術の利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.4 Agentcities におけるオントロジー技術の応用 . . . . . . . . . . . . . . .
29
3.4.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4.2 アプリケーションとそこで用いられるオントロジー関連の技術 . . . . . . .
29
3.4.3 オントロジー記述言語及びコンテント言語の選択 . . . . . . . . . .
31
3.4.4 オントロジーサービスの開発 . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.5 サービスの記述とその実行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.4.6 おわりに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5 IEC/TC100への提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
1
3.5.1
3.5.2
3.5.3
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other important items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4..将来型文書への考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 ワークフロー管理とオフィス文書 . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 ワークフロー管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 オフィス文書と情報伝達 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 将来文書に対するワークフローの役割 . . . . . . . . . . . . . . . . . . .
4.1.5 おわりに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Voice BrowserとMultimodal Interactionに関する動向 . . . . . . . .
4.3 個人や家庭における情報管理と文書 . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 情報集合から人間関係の問題へ . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 情報技術に対して無防備な社会 . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 サイバースペースにおける社会的ルールの確立 . . . . . . . . . . . .
4.3.5 過去の技術からの教訓 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6 国立公文書館の碑文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 電子政府・電子自治体とXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 1. 電子政府・電子自治体の目標 . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 行政システムの現状と問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 書面主義とデータ主義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.4 非改ざん性、原本性、本人性の確保 . . . . . . . . . . . . . . . . . . . . .
5.あとがき . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
34
34
35
36
36
36
36
36
37
39
39
40
40
41
41
41
42
42
43
43
44
45
47
48
1. まえがき
当WGは, W3Cが今後のWebとして提唱したセマンティックWebとその関連技術の標準化を検討すること
を目標に平成13年(2001年)4月に発足した。平成13年度は,W3Cおよび関係機関が取り組んでいるセマン
ティックWebに関する検討作業を把握することに焦点を当て, W3Cの文書, 関連国際会議資料の抄訳などを
通じて, 現状の技術を把握した。また, W3Cの技術を把握する上で必要と思われた類似技術に関してもその
状況を把握した。類似技術の一つとしては, エージェント技術が挙げられるが, エージェント技術の標準化
コンソーシアムであるFIPA(Foundation for Intelligent Physical Agents)の活動をネットワークエージェ
ント標準化調査委員会の成果などを踏まえて調査した。セマンティックWebと関連する技術としては,
OMG(Object Management Group)のMOF(Meta Object Facility), XMI(XML Metadata Interchange), さらにそれらの技術に基づくMDA(Model Driven Architecture)などもあり, それらについても
調査を行った。なおその内容は平成13年度の報告書に記されている。
昨年度(平成14年度)は, 以上の検討を継続する一方で, 将来型文書という概念を形成する上で重要な,
ワークフロー,組織文化といった問題を検討した。前年度におけるセマンティックWeb関連技術の検討の結
果, 広範な領域をカバーするモノリシックな意味概念の実装は困難であるとの見通しを得ていたので, 領域
に特化したメタデータやオントロジの可能性を調査した。Dublin Core, MPEG7, TV Anytime といったコ
ンテンツ系のメタデータに関する専門家からヒアリングを実施したり,ワークフローの専門家から企業にお
けるビジネスロジックとコンテンツ管理の現状をヒアリングしたりした。さらにW3Cの活動におけるオント
ロジ領域の言語であるDAML+OILについても調査を継続した。以上から, メタデータやオントロジといっ
た用語を将来型文書に反映させるには, 有望そうな分野を抽出し, それに特化した技術を抽出し検討するこ
とが望ましいと思われた。
そこで, 本年度はメタデータ, オントロジといった用語が効果的に適用できそうな領域における可能性を
追及するとともに, W3Cが進めるRDF, OWL(DAML+OILの後継言語)などの進展についてもウォッチす
ることとした。昨年度の検討に基づき, メタデータ, オントロジの適用可能な具体的分野として発信情報の
メタデータ要素が容易に抽出できる携帯電話や,EPGなどを使って視聴履歴が収集可能で,かつMPEG7,TV
Anytimeといったメタデータが確立されたデジタル・サーバ型TV,さらに今後のネットワーク社会を支える
ネットワーク機器のパラメタ設定など,生活者にとっての電子的な機器とのインタフェースにフォーカスを
当てて検討を試みることとした。
3
2. セマンティックWebの最新状況
2.1 RDF仕様の最新動向
Resource Description Framework (RDF)は、W3Cが提案するメタデータに関する標準仕様である。メタ
データは、
「データに関するデータ」であり、RDFでは、URIでアドレスできるデータに対し、構造を持った
付加情報を関連づけることができる。Web資源に対する書誌情報の付与という従来のメタデータの使い方に
加えて、Web空間上に、計算機に理解可能な知識の空間を構築しようとするSemanticWebにおける基本要
素として、RDFは現在、注目を集めている。また、Webサイトの要約情報をメタデータとして記述する
RDF Site Summary (RSS)[9]は、Blobといった新しいコミュニティツールの中で利用が拡大している。
RDFは、1999年2月に、モデルと構文に関する仕様 (RDF Model & Syntax Specification [1])がW3勧告
(Recommendation)となり、スキーマに関する仕様 (RDF Schema)も、1999年3月に勧告の一歩手前である
ProposedRecommendation[2]となった。しかし、複雑であった仕様の精密化や簡略化作業、同時期に行わ
れていたXML Schema仕様、およびXML Infosetなど他のXML関連標準との整合性、Semantic Webにおけ
るメタデータ記述言語としての要件定義などの観点から、引き続いて改訂作業が行われ、現在に至ってい
る。本稿執筆時には、RDFに関する以下の6つの仕様が提案されている。すべての仕様が、2003年12月5日
版であり、Proposed Recommendationとなっている。
S RDF/XML Syntax Specification (Revised) [3]
1999年2月にW3C勧告となったRDF Model & Syntax Specificationの改訂版
S RDF Vocabulary Description Language 1.0: RDF Schema [4]
1999年3月にW3C Proposed RecommendationであったRDF Schemaの改訂版
S RDF Primer [5]
RDFのデータモデルやスキーマを簡単に説明したもの(とはいえA4で100ページ以上ある)
S Resource Description Framework (RDF): Concepts and Abstract Syntax [6]
RDFの抽象的構文や主要な概念をまとめたもの
S RDF Semantics [7]
RDFデータモデルそのものの詳細な意味論
S RDF Test Cases [8]
RDF仕様を満たすRDF文書のレポジトリ
これらの仕様のうち、最初の2つ、構文仕様とスキーマ仕様に関して、従来仕様からの変更点について簡
単に述べる。構文仕様においては、最新版であるRDF/XML Syntax Specification(Revised) [3] (以降2003年
仕様と呼ぶ)において、1999年のW3C勧告文書 [1] (1999年仕様と呼ぶ)で曖昧だった部分の精密化が図られ
ている。
RDFの基本要素は、(subject, predicate, object)の3つ組であり、1999年仕様では、subjectは、URIでアド
レスされるリソース(Resource)を表現し,predicateはリソースに対するプロパティ(property)を、objectは、
プロパティの値となるリテラル(文字列)あるいはリソースであると定義されていた。つまり、
「http://www,ibm.com/xml/ の編集者は,”Naohiko Uramoto”である」であるという知識(メタデータ)を
表現するRDF表現は、以下のように定義される。
4
Subject (Resource)
http://www,ibm.com/xml/
Predicate (Property)
Editor
Object (literal)
“Naohiko Uramoto”
2003年仕様では、この3つ組を構成する概念(subject, predicate, object)が、objectがリテラルである場合
を除いて、RDFURIreference(URIに相当する)によって同定されると明確に定義されている。1999年仕様
では、例えば、PredicateがURIで必ず同定されるべきかどうかは曖昧であった(例えばEditorを許していた
)が、2003年仕様では、Predicateは、RDFURIReference(例えばhttp://example.org/terms/editor)によって
定義される。これは、RDFの基本要素は基本的にURIで指定される、すなわち、Web空間上でアドレスで
き、その同一性が定義されるものとするという原則を押し進めるものである。
また、1999年仕様におけるRDFの特徴的な構成要素の一つとして、リソース・リテラルのコンテナ(Bag,
Alt, Seq)表現がある。コンテナ表現は、データモデルを複雑にするため、コンテナ表現を仕様から削除す
ることも含めて議論が行われたが、最終的には、2003年仕様でも定義されている。さらに、2003年仕様で
は、新しい概念として、線型リストとして定義されるcollectionが導入されている(JavaのCollectionクラスに
似た概念である)。
RDF Schemaは、RDF Vocabulary Description Language 1.0として再定義されている。XML Schema, 特
にデータ型の議論やオントロジ記述言語であるOWL[10]との整合性を反映したものになっている。オントロ
ジ記述に必要な仕組みは、OWLで定義されるため、この仕様で新しく追加された概念はそれほど多くない。
例としては、前述のCollectionに関するクラスとプロパティ、(リテラルに対する)データ型を定義するための
rdfs:datatype、XMLリテラルを埋め込むためのクラスrdf:XMLLiteralなどがある。
全体的には、曖昧さがなくなり、ツールの実装や使用が促進される傾向にある。ただ、上述の6仕様の役
割分担は必ずしも明確ではなく、複数の仕様で、微妙に違う説明の仕方がされている概念が見受けられる。
RDF関連ツールや応用事例も、前述したSemantic Web, RSSなどのプロジェクトを中心に数多く報告さ
れている。ブリストル大のDaveBeckettが管理するRDFに関するリソースガイドWebサイト[11]などが参考
になる。
[1] Resource Description Framework (RDF) Model and Syntax Specification,W3C Recommendation,
http://www.w3.org/TR/WD−rdf−syntax/, 1999
[2] Resource Description Framework (RDF) Schema Specification, http://www.w3.org/TR/WD−rdf−
schema/, W3C Proposed Recommendation, 1999
[3] RDF/XML Syntax Specification (Revised), W3C Proposed Recommendation (work in progress),
http://www.w3.org/TR/rdf−syntax−grammar/, 15 December 2003
[4] RDF Vocabulary Description Language 1.0: RDF Schema, W3C Proposed Recommendation (work in
progress), http://www.w3.org/TR/rdf−schema/. 15 December 2003.
[5] RDF Primer, Manola F., Miller E., Editors, W3C Proposed Recommendation (work in progress),
http://www.w3.org/TR/rdf−primer/, 15 December 2003
[6] Resource Description Framework (RDF): Concepts and Abstract Syntax, W3C Proposed Recommendation (work in progress), http://www.w3.org/TR/rdf−concepts/, 15 December 2003.
[7] RDF Semantics, W3C Proposed Recommendation (work in progress), http://www.w3.org/TR/rdf−
mt/, 15 December 2003
5
[8] RDF Test Cases, Grant J., Beckett D. (Editors), W3C Proposed Recommendation (work in progress),
15 December 2003
[9] RDF Site Summary (RSS) 1.0, http://web.resource.org/rss/1.0/, 12 December 2000
[10] OWL Web Ontology Language Overview, http://www.w3.org/TR/owl−features/, W3C Proposed Recommendation 15 December 2003
[11] Dave Beckett’s Resource Description Framework (RDF) Resource Guide, http://www.ilrt.bris.ac.uk/
discovery/rdf/resources
2.2 RSS
RSSは、RDF Site Summary、又はRich Site Summary、Really Simple Syndicationなどの略で、その名
前が示すとおり、Web上におけるサイト情報の要約(Summary)を与え、それを発表・配信(Syndication)するフォーマットを、XMLを用いて定義したものである。省略しない名前に各種あるのは、その開発
の経緯に根ざす版の違いでもあるのだが、大きく、RDFを使用するかどうかで分かれており、RDFを使用す
るものと使用しないものとの間には、互いに互換性がない。したがって、それらは、構文上及び意味上にお
いて異なっており、そもそものその目指すところは似通っていたのでは、と思われるが、最近の発展の状況
は異なってきているようである。
この報告では、Semantic Webにおけるメタデータ記述としてのRDF応用の一環としてRSSを捉えたいこ
と、拡張性に優れていること、最近のXML応用の流れに沿っていることなどの点から、主にRDF Site
Summaryに関して示し、それ以外はその差異を簡単に示すに留める。
なお、
−RDF Site Summaryは、http://purl.org/rss/1.0/spec。
−Rich Site Summaryは、http://my.netscape.com/publish/formats/rss−spec−0.91.html。
−Really Simple Syndication は、http://blogs.law.harvard.edu/tech/rss。
に仕様書がある。また、http://www.kanzaki.com/docs/sw/rss.htmlに、日本語によるよくまとまった解説
がある。この報告は、これらから情報を得ている。
2.2.1 開発の経緯及び版
RSSは、Netscape社が自社のポータルMy Netscapeに“チャンネル”を登録するための手段として
1999年3月に公開したRSS 0.9がその最初とされている。これはRDFに基づき(したがって、RDF Site
Summaryといえる。)、見出し一覧などを配信するためのものであった。1999年7月には、概要を記述する
descriptionなどの新たな要素型を取り入れたRSS 0.91が登場する。見出しだけでなく、要約、格付け、著
作権、更新日付など様々な情報も提供できるので、RichSiteSummaryと呼ばれた。また、この名前が示す
ように、RDFの採用は複雑だとして、rssをルート要素とする独自のXMLの構文に変更されている。
その後Netscape社はRSSから手を引くが、Site Summaryを提供する枠組みとしてのRSSへの要望はむし
ろ高まり、これに独自の要素型を追加して用いる利用者も出現するなど、混乱の様相を見せた。そこで、
−基本的な要約(Summary)の提供機能をコアRSSとして定義する。
−より高度な機能は、XML名前空間を利用したモジュールとして追加できるようにする。
6
という規定が、再度RDFに基づいて、開発者のグループ(RSS−DEV Working Group)で検討され、こ
の成果として、2000年12月にRSS 1.0(RDF Site Summary 1.0)が提供された。これは、RSS 0.9の上位互
換になっているが、RSS 0.91とは互換性がない。
一方、RDFの使用を嫌うRSS 0.91系統も独自の発展を続け、RSS 0.92を経て、Really Simple Syndicationという名称のRSS 2.0が2002年9月に発表されている。当然、RDFは採用されておらず、サイトのメタ
データ記述というよりも応用を目指し、ニュース記事などの発表・配信(Syndication)の方によりシフトし
ている感じを受ける。なお、名前空間は使用できるようになっている。
このように、いわゆるRSSには、
−RDFに基づく、RSS 0.9, RSS 1.0。
−RDFに基づかない、RSS 0.91, RSS 0.92, RSS 2.0。
という二つの流れがあり、各流れの中では互換性があるが、互いの流れの間では互換性がない。
2.2.2 RSS 1.0(RDF Site Summary)の概要
RSS 1.0は、2.2.1でも述べたように、RDFを用いたWebサイトのメタデータ記述を主とし、サイト情報の
要約のためのコア機能に絞って規定され、拡張機能は、モジュールとして、XML名前空間を用いて追加でき
るようになっている。なお、RSS 0.9との互換性も考慮されている。
規定の詳細は省略し、例を通じて解説する。例の中に、コメントとして解説を示す。
例1:コア機能だけを使用した場合
<?xml version=”1.0”?>
<!−−XMLインスタンスである。−−>
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22−rdf−syntax−ns#”
xmlns=”http://purl.org/rss/1.0/”>
<!−−RDFを使う。この例では、RDF及びRSS 1.0の名前空間を指定している。−−>
<channel rdf:about=”http://www.xml.com/xml/news.rss”>
<!−−必須要素。サイト情報の要約の一覧情報を示す。
ただし、実際の要約情報はchannel要素の後に記述する点に注意。
なお、RDFによる記述になっている点にも注意。−−>
<title>XML.com</title>
<!−−必須要素。channelのタイトルを与える。−−>
<link>http://xml.com/pub</link>
<!−−必須要素。サイトへのリンク。−−>
<description> <!−−必須要素。自然言語による説明。−−>
XML.com features a rich mix of information and services for the XML community.
</description>
<image rdf:resource=”http://xml.com/universal/images/xml_tiny.gif” />
<!−−オプション要素。
画像を与えることもできる。実際の画像データの情報は、後で与える。−−>
<items>
<!−−必須要素。要約の一覧を示す。
7
ただし、これらも実際の要約情報は、channelの後に与える。−−>
<rdf:Seq>
<!−−RDFのSequenceを使う点に注意。−−>
<rdf:li resource=”http://xml.com/pub/2000/08/09/xslt/xslt.html” />
<rdf:li resource=”http://xml.com/pub/2000/08/09/rdfdb/index.html” />
</rdf:Seq>
</items>
<textinput rdf:resource=”http://search.xml.com” />
<!−−オプション要素。
form送出のようにクライアント側から情報を送出できるようにする。
ただし、これらも実際の情報は、channelの後に与える。−−>
</channel>
<image rdf:about=”http://xml.com/universal/images/xml_tiny.gif”>
<!−−オプション要素。
channel内のimageの実際の情報を与える。−−>
<title>XML.com</title>
<link>http://www.xml.com</link>
<url>http://xml.com/universal/images/xml_tiny.gif</url>
<!−−実際の画像データを与える。−−>
</image>
<item rdf:about=”http://xml.com/pub/2000/08/09/xslt/xslt.html”>
<!−−必須要素。
channel内のitemsの一つのitem(rdf:li)の実際の情報を与える。−−>
<title>Processing Inclusions with XSLT</title>
<link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link>
<description>
Processing document inclusions with general XML tools can be
problematic. This article proposes a way of preserving inclusion
information through SAX−based processing.
</description>
</item>
<item rdf:about=”http://xml.com/pub/2000/08/09/rdfdb/index.html”>
<title>Putting RDF to Work</title>
<link>http://xml.com/pub/2000/08/09/rdfdb/index.html</link>
<description>
Tool and API support for the Resource Description Framework
is slowly coming of age. Edd Dumbill takes a look at RDFDB,
one of the most exciting new RDF toolkits.
</description>
</item>
<textinput rdf:about=”http://search.xml.com”>
8
<!−−オプション要素。
channel内のtextinputの実際の情報を与える。−−>
<title>Search XML.com</title>
<description>Search XML.com’s XML collection</description>
<name>s</name>
<!−−formデータを格納する変数名。−−>
<link>http://search.xml.com</link>
</textinput>
</rdf:RDF>
例2:名前空間を用いて拡張機能を用いた場合
<?xml version=”1.0” encoding=”utf−8”?>
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22−rdf−syntax−ns#”
<!−− dc及びsyがモジュールとしての拡張機能である。
dcは、Dublin Coreである。
syは、Syndicationであって、ニュースの記事などを配信するサービス。
それに便利な内容(記事更新の情報など)が規定されている。−−>
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:sy=”http://purl.org/rss/1.0/modules/syndication/”
xmlns=”http://purl.org/rss/1.0/”
>
<channel rdf:about=”http://meerkat.oreillynet.com/?_fl=rss1.0”>
<title>Meerkat</title>
<link>http://meerkat.oreillynet.com</link>
<description>Meerkat: An Open Wire Service</description>
<dc:publisher>The O’Reilly Network</dc:publisher>
<dc:creator>Rael Dornfest (mailto:[email protected])</dc:creator>
<dc:rights>Copyright &#169; 2000 O’Reilly &amp; Associates, Inc.</dc:rights>
<dc:date>2000−01−01T12:00+00:00</dc:date>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>2</sy:updateFrequency>
<sy:updateBase>2000−01−01T12:00+00:00</sy:updateBase>
<items>
<rdf:Seq>
<rdf:li resource=”http://c.moreover.com/click/here.pl?r123” />
</rdf:Seq>
</items>
</channel>
<item rdf:about=”http://c.moreover.com/click/here.pl?r123”>
9
<title>XML: A Disruptive Technology</title>
<link>http://c.moreover.com/click/here.pl?r123</link>
<dc:description>
XML is placing increasingly heavy loads on the existing technical
infrastructure of the Internet.
</dc:description>
<dc:publisher>The O’Reilly Network</dc:publisher>
<dc:creator>Simon St.Laurent (mailto:[email protected])</dc:creator>
<dc:rights>Copyright &#169; 2000 O’Reilly &amp; Associates, Inc.</dc:rights>
<dc:subject>XML</dc:subject>
</item>
</rdf:RDF>
2.2.3 RSS 0.9x及びRSS 2.0
2.2.1で示したように、RSSには、RDFに基づくRSS 0.9及びRSS 1.0と、RDFに基づかないRSS 0.9x及び
RSS 2.0があり、それらには互換性がない。RSS 0.9x及びRSS 2.0は、RSS 1.0と、細かい要素の違い以外に
も、次のような差異がある。
S RDFは使用しない。
S トップレベルはrssという要素になっている。
S rssの直下にchannelがある。
S channelの直下にitemを含むすべての要素を直接に記述する。RSS1.0のように、channel内には一覧だ
けを示し、channelの後に実際の情報を与える形式ではない。
S RSS1.0でchannelの必須の子要素、tittle、link及びdescriptionは、同じく必須である。itemsは存在せ
ず、代わりにitemが一個以上並ぶことになる。
S RSS 1.0ではDublin Coreなどのモジュールから取り込んでいた各種の要素が、独自に規定されてい
る。RSS 2.0では、名前空間を使用できるので似たことは可能だが、仕様上、モジュール化という考え
方はしていない。
S 直感的には、例1のchannelの中に、直接にimage、item、textinputなどの詳細情報が並んでいると思
えばよい。
こうした差異のために、RSS0.9x及びRSS2.0に対しては、一般に、次のようなことが言えそうである。
S RDFなどの他の規定を使用せずに、RSSだけで閉じているので予備知識が不要であり、比較的単純で分
かりやすい。書くのも容易な気がする。
S しかし、必要な要素がより多く定義されているので、さほど大変ではないが、それらの理解には若干の
手間がかかる。
S モジュール化の概念が明確ではないので、仕様として拡張するためには、新たにRSS自体に要素を追加
し、仕様の版を変更する必要がある。
10
最近のXMLの流れを見ると、名前空間を使用したモジュール化は自然であるし避けて通れない気もするの
で、拡張のたびに仕様追加が必要になるRSS0.9x及びRSS2.0には、個人的には疑問を感じる。しかしその
一方で、RDFなどの予備知識なしに気軽に記述できそうな点は評価できる。その意味では、今後どちらが生
き残るかは、微妙な気がする。
2.2.4 使用状況
RSSは、Webサイトの情報の要約を簡潔に提供しているメタデータなので、それが流布すればするほど、
それらRSSを集めてそのサイト情報の一覧を提供するのが容易になる。この一覧の提供をWeb上のサイトで
行えば、そのサイトは一種のポータルサイトと考えることができ、そうした応用が始まっている。こうした
例に、次がある。
−syndic8.com(http://www.syndic8.com/)
−NewsIsFree(http://www.newsisfree.com/)
−WebReference.com/internet.com RSS News Feeds(http://www.webreference.com/services/news/)
−Redland RSS 1.0 Validator and Viewer(http://www.redland.opensource.ac.uk/rss/)
−Bulknews(http://bulknews.net/rss/)
−Bulkfeeds: RSS Directory & Search(http://bulkfeeds.net/)
−rss−jp.net(http://rss−jp.net/)
−MyRss.jp(http://myrss.jp/)
これら以外にもWeb上で探してみれば、数多くのサイトが見つかる。一方、クライアント側PCにRSSを直
接に集めることができれば、そのPC上に各種情報を集めた一覧(ディレクトリ)を直接に表示することもで
きる。最近流行りのblog(ブログ。Weblogのこと。明確な定義はないと思われるが、頻繁に更新される、他
のサイトへのリンクが多い、リンクと短いコメントという形式が基本、などといった特徴をもつWebペー
ジ。)でも、その情報配信のためのメタデータとしてRSSを使うことも多いようである。
実際にRSSの情報を利用するためには、RSSを発行するためのソフト、RSSを理解するソフト(リー
ダー、ビューア)などが必要になる。Web上で探せば幾つも見つかるので、好みのものを使用すればいいだ
ろう。
なお、実際に使用されているRSSは、互いの互換性がない、RSS 0.9及びRSS 1.0と、RSS 0.9x及びRSS
2.0とがある。現時点でどちらがより多く使用されているかは定かではない。ただ、少し前、2001年頃の調
査では、RSS0.9(及びRSS1.0)とRSS0.91とが互いに半々ぐらいと言われている(http://www.webreference.com/authoring/languages/xml/rss/1/8.html)。現時点ではこの数字は大きく変わっているものと思われ
る。世界的に見れば、RSS 0.91がかなり普及しているという噂もある。このような非互換の版が両方とも
流布していることは残念なことではある。市場原理に基づいて時間が解決してくれるであろうか。それと
も、必ずしも容易ではないと思われるが、何らかの強制的な標準化が必要であろうか。いずれにせよ、すべ
ての版に対応したソフトもあるようなので、現状では必要に応じてそれらを利用するのが最も妥当な解決と
思われる。
11
2.2.5 まとめ
RSSについて、主にRDFの応用という観点から紹介した。仕様に関して互換性のない二つの流派があるの
は困ったものだが、Webサイトが公開している情報の要約をメタデータとして簡潔に与え、それを使って
Webサイトを検索できるという点でかなり成功しており、今後も普及していくものと思われる。リーダーな
どは、既存のWebブラウザ上で動くものもあるので、Semanticsというほど大げさではないにしても、Semantic Webへの最初の一歩といってもよいかもしれない。
2.3 OWL:Webオントロジ言語
2.3.1 OWLとは
OWL(the Web Ontology Language)は,Web技術の標準化団体W3C(World Wide Web Consortium)の
Web−Ontology (WebOnt)ワーキンググループで検討してきたオントロジ定義言語の規格案であり,
W3Cは2004年2月10日に最終承認を経て,改訂されたRDF(Resource Description Framework)とと
もにSemanticWebの標準技術として,W3C勧告(Recommendation)として公開された
(http://www.w3.org/2004/01/sws−pressrelease).
OWLの目的は,異なる分野にまたがるようなアプリケーション間で,Web上のリソースのためのメタデー
タをやりとりして,自動的に統合/連携したり再利用するために「意味」を扱うことである.OWLは
RDFおよびRDF Schemaの上に構築されている.RDFはXML上に構築されているので,XMLとRDFと
OWLは階層的な関係にあることとなる.XMLが(メタ)データの記述方式を,RDFが(メタ)データの交換方式
を,OWLが(メタ)データの意味を定義するという位置づけである.OWLでは,クラスやプロパティを記述
する上で,等価性や非重複性,唯一性といった性質を定義することができる.
OWLの前身であるDAML+OILは,DAML(DARPA Agent Markup Language)とOIL
ference
(Ontology In-
Layer)を結合した言語であるが,DAML+OILとOWLは非常によく似ている(W3Cの文書:Web
Ontology Language (OWL) Abstract Syntax and Semantics, http://www.w3.org/TR/owl−semantics/に相違
点がまとめられている).また,DAML+OILからOWLへの変換系(OwlConverter)も作られている.
2.3.2 OWLの仕様
OWLには,フルセット規格であるOWL Fullのほかに,制約を加えたOWL DL(Description Logic),な
らびに更に小さく実用的なサブセットであるOWL Liteというサブ言語がある(その相違は,W3C文書,
OWL Web Ontology Language Reference, http://www.w3.org/TR/owl−ref/の第8章ならびに前掲の抽象構
文とセマンティックスの文書を参照のこと.).
OWL関連のW3Cからの仕様書は6種のものが策定されている
(http://www.w3.org/2004/01/sws−pressrelease).
[1] OWL 策定の根拠となる利用例と要件
(http://www.w3.org/TR/2004/REC−webont−req−20040210/)
[2]OWL の機能と利用方法の概要
(http://www.w3.org/TR/2004/REC−owl−features−20040210/)
12
[3]利用ガイド(http://www.w3.org/TR/2004/REC−owl−guide−20040210/)
[4]言語リファレンス
(http://www.w3.org/TR/2004/REC−owl−ref−20040210/),
[5]適合性の試験例
(http://www.w3.org/TR/2004/REC−owl−test−20040210/)
と,適合性の試験データ集(http://www.w3.org/2002/03owlt/)
[6] OWLからRDFへのマッピングを規定する抽象構文とOWLのセマンティックスの規定
(http://www.w3.org/TR/2004/REC−owl−semantics−20040210/)
2.3.3 OWL関連のツール
最後に,W3Cの文書であるOWL Implementations(http://www.w3.org/2001/sw/WebOnt/impls )に基づい
て,OWL関連のツールの一部に関する情報を列挙する.
[a] 商用オントロジ支援ツール:オントロジの開発,利用,管理を支援するツール
[b] デモ/ポータル:ユースケースと要件
13
[c] 推論系
14
[d] パーザ/ヴァリデータ
15
[e] エディタ
[f] オントロジ
16
[g] API
2.4 トピックマップ
2.4.1 標準化動向
トピックマップに関する標準作成作業は、ISO/IEC JTC1 SC34 WG3にて行われている。現在は、以下の
3種類の標準策定作業が進められている。
S ISO/IEC 13250 Information Technology −− Topic Maps
S ISO/IEC 18048 Information Technology −− Topic Maps −− Topic Maps Query Language
(TMQL)
S ISO/IEC 19756 Information Technology −− Topic Maps −− Topic Maps Constraint Language
(TMCL)
以下、それぞれについて、現状を報告する。
(1) ISO/IEC 13250 Information Technology −− Topic Maps
今年中、または、来年初めの完成を目指して、作成作業が進められている。XML Europe 2004 と併設し
て開催される次回の国際会議は、4/14日からの4 or 5日間の集中審議が予定されており、標準作成作業が加
速されるものと予想される。
(a) 13250:2003 (Second Edition) Information technology −− SGML Applications −− Topic Maps
13250:2000の改訂版であり、既に、標準として承認されており、現在、出版待ちの状態である。
(b) 13250の改訂作業 (Multi−part standard)
17
現在、マルチパートスタンダード(5つのパートからなる)として、検討が進められている。HyTM (HyTime Topic Maps) については、利用者がほとんどいないという理由で、検討対象からはずされている。
− 13250−1 Information Technology −− Topic Maps −− Overview and Basic Concepts
パート1は、トピックマップの概要、13250の各パートの説明と位置付け、基本的な考え方を記述すべく、
他パートと記述範囲、内容などを調整しながら作業が進められている。現在は、Workingdraftを作成中で
ある。
− 13250−2 Information Technology −− Topic Maps −− Data Model
パート2は、トピックマップのデータモデルと併合ルールについての標準である。データモデルは、Information Set を用いて定義されており、8種類のInformation Item Type と、21種類のProperty から構成
されている。パート2は、2004年1月23日の投票で、CDとして承認された。
下表に、Information Item Type と、それぞれが持つPropertyを示す。
表
Topic Maps Data Model のInformation Item Typeと Property
− 13250−3 Information Technology −− Topic Maps −− XML Syntax
パート3は、XML形式のトピックマップの交換構文の標準である。パート3は、データモデル(パート2)と
のマッピングも定義する。本構文は、RELAX−NGスキーマで定義されている。CDとして承認するか否かの
投票のための準備が進められている。
− 13250−4 Information Technology −− Topic Maps −− Canonical Syntax
18
パート4は、トピックマップの規範化(canonicalization)のためのアルゴリズムについての標準である。
データモデル(パート2)で定義されたInformationItemの順序、および、データモデル(パート2)で定義され
たInformation Item と PropertyのXML上での記述順序を定義する。2004年5月6日までにCDとして承認す
るか否かの投票が行われる。
− 13250−5 Information Technology −− Topic Maps −− Reference Model
パート5は、トピックマップにおける主題の情報構造、トピックのプロパティ、トピックの併合条件等に
ついて、データモデル(パート2)に依存しない、より抽象度の高いレベルでの標準である。現在、Working
Draftの作成が進められている。
(2) 18048 Information technology −− Topic Maps −− Topic Maps Query Language (TMQL)
トピックマップのための検索言語の標準であり、13250−2で定義されるデータモデルをベースにしてい
る。TMQLに対する要求仕様の定義作業とともに、検索言語の仕様が検討されている。検索言語について複
数の提案がなされている。その主なものをデータベース問合せ言語的観点から比較する。
(a) Tolog
部分的にデータログに基づく言語である。”association”が述語となる。”topic”についてその型を指定する
組み込み述語”instance−of(instance, class)”が存在する。データログにおいてbodyに現れる変数全てを関
係として返す場合、bodyだけを記述する。bodyに現れる変数のうち必要な変数だけを返す場合、SELECT句
で指定する。新たに”association”を定義する場合、データログで記述する。否定については、層状否定デー
タログの意味を採用している。
(b) AsTMa
提案者は、タウ代数(タウ関数?) に基づく言語であると主張している。IN句で外延の指定、LET句、
FOR句で変数束縛、WHERE句でフィルタリング、RETURN句で結果の指定をするようになっている。一
見、XQueryやSQLに似ているようだが、手続き的な言語仕様になっているように思われる。
(c) TMPath
提案者は、XPathに基づくと主張している。必要に応じてXQueryのFLWOR式もどきを導入しているが、
XQueryとは異なり手続き的な言語仕様になっている。
(XQueryは、関数型プログラミング言語に基づいてい
る。)
(3) 19756 Information Technology −− Topic Maps −− Topic Maps Constraint Language
トピックマップのための制約言語の標準である。あるトピックマップについて、存在が許されるトピッ
ク、関連、出現の型や回数などの制約を記述可能にする。現在、要求仕様の定義作業が進められている。
2.4.2 技術動向
この1年の間にも、トピックマップに関連する新しい考え方、主張が誕生している。そのうちのいくつか
を紹介する。
(1) Curing the Web’s Identity Crisis: Subject Indicators for RDF
19
ISO/IEC JTC1 SC34 WG3のコンビーナであるSteve Pepper氏がXML Europe 2003やXML 2003で発表し
ていて、Ontopia社のホームページ (http://www.ontopia.net/topicmaps/materials/identitycrisis.html)で、
論文を読むことができる。
この論分の中で、Pepper氏は、現在のWebでのURLの識別性の問題点を指摘している。例えば、
http://www.w3.org がW3Cという組織を示しているのか、W3Cのホームページを示しているのか識別でき
ない。情報リソースが持つ主題が処理対象の中心になると予想される次世代のWebでは、これが大きな問題
となるとしている。
それを解決するために、トピックマップで定義する(標準化は、OASISの技術委員会の中で進められてい
る) 主題指示子 (Subject Indicator) の概念を使用することを薦めている。主題指示子は、W3Cという組織そ
のものを主題として処理対象にしたい場合に、URLでその主題を表現するためのコンピュータ内の情報リ
ソースを指示することにより、間接的に指定することができる。W3Cのホームページそのものを処理対象に
したい場合は、URLで直接そのアドレスを指定する。それにより両者の識別が可能なる。
(2) Topic Map Design Patterns For Information Architecture
イギリスのtechquila社のKhalil Ahmed氏が提唱している。Extreme Markup Languages 2003やXML
2003で発表していて、techquila社のホームページ (http://www.techquila.com/tmsinia_1.html) で、記事を
読むことができる。
トピックマップの作成時の主題(概念)の体系化において、ソフトウェアデザインパターンの考え方に相似
するトピックマップデザインパターンの作成、再利用、蓄積を推奨している。表記方法としてUML (Unified Modeling Language) の利用を提案している。
トピックマップデザインパターンの一例として、以下のものを挙げている。
− Hierarchical Naming Pattern
− Hierarchical Classification Pattern
− Topic Per Term Thesaurus Pattern
− Topic Per Concept Thesaurus Pattern
− Faceted Classification Pattern
(3) Semantic Web Servers − Engineering the Semantic Web
ノルウェーのOntopia社のGraham Moore氏が提唱している。XML 2003で発表していて、以下サイト
(http://www.ontopia.net/topicmaps/explorations.html#SWS) からスライドを入手できる。
Webのような環境では、トピックマップは分散されており、トピックマップの断片を交換可能にする必要
があり、そのための交換プロトコルも必要である、としている。
(4) Topic Maps Graphic Viewer
20
トピックマップは、ノードとしてのトピックとアークとしての関連からなるグラフモデルと考えることが
できる。トピックや関連の種類が増え複雑になったトピックマップを把握しやすくするため、視覚化のニー
ズは強いものがある。
Ontopia社は、視覚化ツールの開発を表明し、要求仕様の取りまとめにかかっている。また、シナジー・
インキュベート社では、視覚化ツールを開発しその評価を進めている。
2.4.3 最近の事例
(1) ヨーロッパ議会 (Europe Parliament)
ヨーロッパ議会では、より良い情報サービスを提供するための努力が続けられている。その中でビジネス
プロセスや情報体系の分析が進められ、業務手続、関係者、情報システム、活動、出力、その中で使用され
る語彙などの要素を、トピックマップを利用して体系化する努力が続けられている。
(2) ヨーロッパの公共部門での情報管理、保管、公開
イギリスにおいては、Public Record Office (PRO) や、National Health Service (NHS) での情報管理、保
管への適用が報告されている。
ドイツにおいては、German Environmental Authorities での環境関連の約9万の専門用語につ
いてのトピックマップの作成事例が報告されている。
(3) 韓国における製品情報共有
韓国の大手研究機関においては、Web上で製品情報を共有して、生産効率を高め競争力を向上さ
せる試みがなされている。製品構造を表現にトピックマップが利用されている。
(4) シェル石油
シェル石油では、トピックマップとXSLTを利用したビジネスプロセスモデルの出版の事例が報
告されている。
(5) プジョー (Peugeot)
プジョーでは、車のコンセプトについての知識ベースへの適用が報告されている。
(6) Topic Map−driven Web Portals
ノルウェーでは、多くのトピックマップ駆動型のWeb ポータルが開発され運用されている。そして、現
在も多くのWeb ポータルが開発されつつある。
以下にそのいくつかを示す。
− http://www.itu.no
− http://www.luna.itu.no
− http://www.forskning.no
21
− http://forbrukerportalen.no
− http://www.skifte.no
− http://www.hoyre.no
− http://www.nysgjerrigper.no
− http://matportalen.no
− http://www.udi.no
2.4.4 その他
(1) イギリスにおけるトピックマップカンファレンス
2003.11.5日、イギリスのDuxfordにて、トピックマップカンファレンスが開催され、多数の事例が報告さ
れた。また、そのカンファレンスにおいて、XML UKの中に、トピックマップSIG (Special Interest
Group) を設立することの可能性について議論がされた。
(2) RDFとの交換
2004.12月、Ontopiaが、OKS 2.0をリリースした。OKS 2.0 では、RDFをサポートしており、Topic
MapsとRDFの相互交換が進むものと予想される。
22
3. オントロジ技術の現状と応用
3.1 TV視聴者プリファレンス
3.1.1 はじめに
現状の家電におけるSemanticWeb/XMLの利用は,まだまだ一般的ではない。しかしながら,2003年12月
より地上ディジタル放送が一部の地域で開始されるなど,家電製品のディジタル化・ネットワーク化は著し
いものがあり,今後家電分野にメタデータの利用が進みXMLやSemanticWebの技術が適用されていくこと
が予想される。ここでは,ディジタルTVにおける視聴者プリファレンスという観点で,現状と今後につい
ての考察を行う。
3.1.2 電子番組表
アナログ放送時代から存在していたEPG(Electronic Program Guide:電子番組表) は,CSディジタル放
送,BSディジタル放送の開始とともにディジタル化され,インターネット上でもPCや携帯電話を対象に
ディジタル化されたEPGが配信されるようになった。アナログ放送においては,ADAMS−EPG(テレビ朝
日系列の提供するVBI(垂直帰線消去期間)を使った地上波データ放送によるEPG)が代表的だが,この
サービスはテレビ朝日系列の番組の配信のみであり,地上波放送すべてを網羅しているわけではない
一方,インターラクティブ・プログラム・ガイド社(IPG)がメガポート放送と提携して,国内で運用す
るG−GUIDE方式は,VBIとインターネットで配信を行っており,こちらは地上波すべてを網羅している。
G−GUIDE方式は,米国ジェムスターTVガイドインターナショナル社が特許を保有する2日分の番組欄と
8日分のジャンルによる番組検索が行える方式で,現時点では,アナログ放送だけでなく,BSアナログ・
ディジタル,110度CSディジタル放送を網羅している。また,iEPGと呼ばれるインターネットでの番組配信
サービスも行われている。(www.tvguide.or.jp)BSディジタル放送及び110度CSディジタル放送においては,
放送自体にEPG情報が映像,音声に重畳されて送信されている。
しかし,現在のEPG情報は,iEPGを例に取ると,その内容は,Content−typeと放送局名,放送年月日,
放送時間が改行で分割されたテキストデータであり,番組内容に対するメタデータは含まれていないという
のが現状である。
3.1.3 パーソナルビデオレコーダ(PVR)
1998年に米国Tivo社が発表したPersonal Video Recorder(PVR)は,従来のビデオ録画機とは発想の異な
る斬新な商品であった。
(日本国内においては,ハードディスクレコーダという形で販売されているものが多
い。ただし,PVRとは商品コンセプトが異なる。ハードディスクは従来のビデオレコーダのビデオテープの
ハードディスク及び記録型DVDによる置き換えがメインだが,PVRは常時タイムシフトと称される番組再編
成のような機能が中心となる。)発表当時に,リアルタイムでMPEG2にエンコードできるチップと大容量の
HDDがすでに存在していたため,技術的な新規性はなかったが,量産品ベースで開発販売したことは,当時
としては画期的であった。しかしながら,米国内においては,
(米国民の多くにとって)価格の割にユーザの
メリットが感じられなかったらしく,爆発的なヒットには至らなかった。ここで注意したいのは,この製品
が持つユーザ嗜好調査機能である。Tivoは,電話回線を使って番組の評価を集計する機能を持つ。ユーザ
は,番組を見ながらその都度,内容の評価をリモコンによって入力できるが,その結果を定期的にTivo社に
23
送ることによって番組評価を集計している。集計時には,二週間分のEPGも受信することで,ユーザに電話
回線を接続するメリットを与えている。
ユーザは事前に自身の嗜好を入力しておくことで,勝手に番組を記録する。また,Tivo Recommendと
いう形で,お勧め番組をユーザに提示する機能も持つ。これと同じような仕組みをインターネット上で展開
したサービスが次に挙げるテレビ王国がある。
3.1.4 テレビ王国
テレビ王国(http://www.so−net.ne.jp/tv/)は,番組表や録画予約状況などの様々な情報をもとに,一人
ひとりの好みにあった番組を推薦するサービスである。ユーザは,1)気に入った番組を指定,2)ジャン
ル,キーワードを登録,3)録画予約する,4)番組検索を行うという4つの行動を行うことでレコメンド
情報を入力することになる。2)を除きユーザは,お勧めサービスのためになにか入力することを強制され
ない。
テレビ王国では,VoyagerEngineと呼ばれる機械学習・ルールエンジン・協調フィルタリングから成る推
薦エンジンを持つ。推薦される理由は,登録したジャンル・キーワードや,よくみるジャンル・キーワー
ド・出演者が選ばれるのと同時に,同じ番組を録画した人の興味や,同じ番組に興味がある人の視聴スタイ
ルなどからも選ばれる。従って,会員数の増加とともに,意外性はあるが本人が気づいていない番組が紹介
されることが予想される。この仕組みは,書籍販売を行うウェブサイトであるAmazonが用いている手法に
似ているが,推薦対象の母数のオーダーが異なることから,より細やかな番組内容のメタデータ化が必要と
なることが予想される。
3.1.5 視聴者嗜好プリファレンスの今後の課題
テレビ王国の項目で述べたが,テレビ番組は,書籍などに比べると絶対量が遥かに少ない。また,ある時
点での放送中コンテンツは,受信機のHDDに保存されるものを考慮したとしても100タイトルに満たない。
これら数量の問題は,今後ビデオオンデマンドサービスなどが,インターネット経由などで行われること
で,若干は解消されると思われるが,チャンネルを合わせることによってそのブランド力を維持し,CMに
よる収入を得ている放送局にとっては,視聴者嗜好によるローカル番組編成を行われることは,その事業形
態を破壊することにもつながるため放送コンテンツの提供(あるいは,そのようなことが可能な機器の発
売)に抵抗感が強い。さらに,視聴者嗜好を行うためのメタデータを番組に付記するためのコストを吸収で
きるビジネスモデルが見えないため,放送局が積極的に詳細なメタデータをつけることがやりにくい。この
ような悪循環にならないためには,番組そのものに対するユーザからの視聴ごとのマイクロ課金や視聴形態
によらないCMや放送局の提示手法の検討が課題となる。また,より細やかな番組推薦を行うためには,表
層的なメタデータだけでなく,内容に踏み込んだメタデータ語彙を検討し,メディア横断で番組に付記する
ことが必要となる。このような語彙の雛形としてTVAnytimeフォーラムが規定するメタデータ構造をベー
スに検討が進められているが,これらのメタデータをすべての番組につける枠組みを構築するには至ってお
らず,今後の発展が期待される。
3.2 エコネット・白物系
3.2.1 生活家電機器をとりまく動向
24
セマンティックWEB技術の適用分野の一つとして、インテリジェント家電があげられることがある[1]。
「白物」と呼ばれる、冷蔵庫、エアコン、洗濯機、照明機器、などの生活家電についても、Echonetのよう
なネットワーク接続標準が制定され、問題とされた機器間の相互運用性についても解決に向けた試みが進展
しつつある[2]。また、ADSLや光ファイバーなどのブロードバンドネットワークも急速に家庭に浸透しつつ
あり、従来指摘されていた、セマンティックWEBのような高度なサービスを提供する上でのネットワークイ
ンフラに関する制約は急速に縮小しつつある。
実際、ネットワーク家電を発売しているメーカーは、WEB接続を前提にした会員制のサービスを提供して
いる。生活家電機器に関連するセマンティックな情報処理についても、パソコンやテレビを端末とした利用
形態については、提供するサービスの内容次第では、普及が進む素地が整っていると考えられる。
3.2.2 セマンティックWEB技術適用における課題
その一方で、生活家電機器に、直接、セマンティックWEB技術を利用させるためには、重要な課題が残さ
れているように見える。
(1)対象世界の認識
コンテンツのような論理的な括りを考えやすいAV機器等とは異なり、生活家電では、セマンティックな
情報処理を行えるように対象世界を認識すること自体が重要な課題になる。対象世界を認識するアプローチ
としては、画像、温度、圧力、のような物理信号のセンシングに基づく方法と、RFIDのようなあらかじめ
コード化された情報源を利用する方法、がある。これらについては、生活家電機器自体によりスマートな機
能を付与するものであり、現在、活発に研究開発が進められている[3]。一部では製品化も行われているが、
広い普及を期待するためには、一層のコスト低減や制限事項の解消、将来の標準化など、多くの問題が残さ
れている。
(2)安全性
生活家電機器は、日常生活を直接にサポートする機器であり、様々な人々が利用するものである。一方
で、生活家電機器の多くは、比較的大きなエネルギーを取り扱うため、誤動作が致命的な結果に結びつくリ
スクがある。そのため、生活家電機器はフェイルセーフを含む高い安全性を持つことが必要であり、義務付
けられてもいる。仮に、生活家電機器そのものが、インターネットを通じてセマンティックな情報処理を行
う機能を組み込むのであれば、いわゆる情報セキュリティにとどまらず、要求される安全性のレベルは非常
に高いものが要求されると考えられる。その意味で、生活家電機器でセマンティックWEB技術を利用する
ためには、セマンティックWEBの最上位層に位置付けられるトラストに目処がつく必要があると思われる。
3.2.3 まとめ
ここまで述べたように、生活家電機器そのものにセマンティックWEB技術を組み込むのは、少なくとも
現時点では機が熟していないように見える。一方で、パソコンやテレビを端末とする、システムとしては通
常の情報システムであるような形態のサービスが普及する環境は整っており、問題は、利用者にとって有用
なサービスを提供できるかどうかにあると考えられる。
参考文献
[1] http://www.net.intap.or.jp/INTAP/s−web/data/s−web1.pdf
25
[2] http://internet.watch.impress.co.jp/cda/news/2003/12/17/1547.html
[3] http://research.microsoft.com/easyliving/
3.3 ネットワーク管理
3.3.1 はじめに
近い将来、インターネットに接続する機器は計算機に留まらず、家電や携帯電話、センサーなど、あらゆ
るものに広がっていくのは必至である。IPv6をはじめとする次世代インターネット技術はアドレスの不足を
解決し、ルーティングの効率化も図っている。インターネットに接続する装置の増加と多様化に伴い、それ
を支えるルータやスイッチなどコアネットワーク機器も増加、多様化し、管理コストが増大している。ネッ
トワーク機器は運用者の知識と判断を入力し、設定により実行し、結果としてネットワーク構成に影響を与
え、その情報をさらにフィードバックすると考えると、メタデータをはじめSemanticWebのアイデアに応
用に適した問題と考えられる。本節では、ネットワーク管理の問題点と標準化動向を整理し、メタデータ技
術が利用できる点を考察する。
3.3.2 ネットワーク管理の問題点
現状のインターネット管理は、高度な知識と技術力を要求される仕事である。その理由のひとつは、現在
のインターネット管理、設定の状況は図1のように個別対応であるため、ネットワークの専門家でなければ
運用方法を把握しにくいことにある。従来の電話網は設計者と運用者が別であり、手順を明確化、簡略化す
ることによって品質を保ってきたが、インターネットでは、設計者と運用者が同じであることが多く、いま
だ限られた専門家に依存する部分が多々ある。
図1. ネットワーク管理の現状
これを解決するためには、インターネット運用の簡略化と一元化が必要となる。ここでの一元化とはイン
ターネット全体ではなく、ISPや組織などイントラネットドメインの単位である。理想的には、一箇所で集
26
中管理をし、リモートで監視や設定変更を行い、高度な言語でポリシーを記述することより、低コストで管
理を行いたい。そのモデルを図2に示す。
図2. インターネット機器管理のモデル
3.3.3 標準化動向
現在、インターネットの運用管理を高度化するために、IETF (Internet Engineering Task Force) におい
て標準化活動が行われている。
2002年7月に横浜で行われたIETFで第一回の会議が行われ、その後何度かの会議を経て、2003年7月に
ウィーンで開催されたIETFでnetconf(Network Configuration)というワーキンググループが設立された。
ワーキンググループの目的は、まずネットワーク機器にコマンドを送るプロトコルの標準化である。プロト
コルはxmlconf と呼ばれ、図3に示す階層から成っている。
図3. xmlconf プロトコルレイヤ
27
最終的に設定のインターフェースとして重要となるのは、最上位のコンテンツレイヤであり、データモデ
ルであるが、現状はまず、インターネット機器ベンダが実装することを目的とするため、現在はコンテンツ
レイヤに関しては議論されていない。議論と標準化が進められているのは、XMLを運ぶためのトランスポー
トプロトコル、RPCと実際のコマンドである。
ネットワーク機器に送られるコマンドは、XML形式で表記するよう標準化が進められている。これによ
り、これまでインタプリタ形式で処理されていたネットワーク機器の設定が、一定の処理をバッチ型で処理
できるようになる。表1にxmlconf プロトコルを用いたXMLによる設定ファイルの例を示す。
表1. xmldonfプロトコルによる設定ファイルの例
<configuration−text>
firewall {
filter test {
term one {
from {
address {
10.1.0.0/16;
}
port [ ssh telnet ];
}
then {
reject administratively−prohibited;
}
}
term two {
from {
address { 10.1.0.0/16; }
}
then discard;
} term three {
then accept;
}
}
}
</configuration−text>
3.3.3 メタデータ技術の利用
現在、標準化活動としては議論されていないが、いずれ、各ネットワーク機器の一元管理と設定、さらに
ネットワーク機器が記録するモニタ情報をフィードバックした効率的な管理が必要となる。図4はそのモデ
ル図である。RDFなどを利用した管理ポリシーの記述は、統一表記が求められるが、各ネットワーク機器へ
のコマンド送信、MIB (Management Information Base) のようなモニタ情報はベンダやバージョンによっ
て異なっており、一元管理には、これらの情報の差異を吸収する仕組みが必要である。
ネットワーク機器の設定は、基本的には各パラメータに値を設定していくため、パラメータをメタデータ
と考えれば、メタデータ関係技術を応用できる。ただし、どのベンダにも共通な標準機器を策定するのは事
実上困難である。ベンダごとに設計思想が違う上、新機能を追加した際にそれを有効に使えなければ、開発
した意味がないからである。各ベンダが新機能を追加したときに、それをメタデータとRDFとしても記述
し、利用者が入手し交換して、適切なメタデータ情報から設定情報へ変換する仕組みが必要と考えられる。
28
現在では、ネットワーク管理にメタデータの概念は導入されていないが、知識処理と異なり機能が限られた
技術であるので、メタデータの応用として適当であると思われる。
図4. ネットワーク機器の管理情報のモデル
3.4 Agentcities におけるオントロジー技術の応用
3.4.1 はじめに
Agentcities (http://www.agentcities.net, http://www.agentcities.org/) とは、世界各地のFIPAエージェン
トプラットフォームを、インターネットを用いて接続し、相互運用性の実証実験を行うとともに、エージェ
ント技術に基づくアプリケーションを作成し、現実の経済活動に寄与を行うことを目的としたプロジェクト
である。2004 年1 月現在、Agentcities はopenNet という次期プロジェクトに移行を計画中であるが、本稿
ではAgentcities という呼称を用いる。
Agentcities の中核であったものが、EC の競争的資金(IST−2000−28385) によって2000 年7月から2003
年6月まで行われたAgentcities.RTD(http://www.agentcities.org/EURTD/)である。本節では、同プロジェ
クトに参加した立場から、そこで用いられたオントロジー関連の技術について、とりわけ問題点を中心とし
て解説を行う。
3.4.2 アプリケーションとそこで用いられるオントロジー関連の技術
Agentcities.RTD では、国際会議を組織することと、それに参加することをシナリオとして用い、二つの
アプリケーションを作成した。一つは、飛行機、ホテル、レンタカーなど、旅行計画の作成支援とそのサー
ビスの提供を行う「イベントオーガナイザー」である。もう一つは、会議参加者に夜の観光案内の提供を行
う「イブニングオーガナイザー」である。次にイベントオーガナイザーの概略を示す。
29
次にイブニングオーガナイザーの概略を示す。
どちらもアプリケーションとしてはありふれたものであるため詳細は省く。このアプリケーションを実現
するために、オントロジー及び関連技術では、次の事項について議論された。
S オントロジー記述言語及びコンテント言語の選択
S オントロジーサービスの開発
S サービスの記述とその実行
30
これらについて以下に解説する。
3.4.3 オントロジー記述言語及びコンテント言語の選択
エージェント通信言語においては、コンテント言語がオントロジーに基づくオブジェクトやアクションを
記述するから、コンテント言語とオントロジー記述言語は密接に関連する。Agentcities.RTDでは、これら
の言語の候補として、次のものを比較検討した。
DAML+OIL (現在ではOWL だが、プロジェクト当時の名称を用いる)
S ebXML
S KIF
S Prolog
S FIPA SL
比較する項目は次の通りである。
S 表現力の強さ
S 動いて使えるソフトウェアがあるか
S 知識獲得、知識操作の手段
S 人間にとっての習得の容易さ
S 他の言語に簡単に移れるか
S 学界や産業界でのサポート
これらについての検討結果をまとめると次の表の通りである。
結論としては、オントロジー記述言語としてはDAML+OIL を用いることにした。また、コンテント記
述言語としては、プロジェクトとしては規定せず、エージェント毎に適切なものを用いることとした。
しかし、コンテント言語を一本化しなかったため、最終的には、プロジェクト全体ではKIF,Prolog,
FIPA SL が混在することとなった。このために、さまざまな問題が生じた。まず、共通のコンテント言語
を使うサブシステム単位で、そのエージェントプラットフォームに依存するかたちでアプリケーションエー
ジェントが作られることになった。そもそも、FIPAでエージェントの外部インターフェースを標準化した
目的は、異なるベンダーのエージェント同士が相互に通信し、アプリケーションを構成できるようにするこ
31
とであったが、コンテント言語の制約のため、あるアプリケーションにエージェントが参加するには、特定
のプラットフォーム上で動作するものでなければならなくなった。
この問題を解決するために、KIF とSL を相互変換するエージェントが作成された。KIF とSLは、適当
なサブセットをとれば、構文的にはほぼ一致するから、この翻訳は一見うまく行っているように見える。し
かし、意味論の厳密な定義にまで踏み込んで完全な相互変換を行うには至っていない。実情は、アプリケー
ションエージェントの側で、
「このKIFの表現がSLに変換されるとこうなるはずだから、このような処理を
行う」というように、かえって手間をかけている実装となっている。
また、オントロジーを記述するためのDAML+OIL と、コンテント言語の間のギャップが大きいのも問
題である。オントロジーをエージェントが動的に処理を行い、動作を組み立てるのが理想であるが、そのた
めには、DAML+OIL で記述された知識をコンテント言語の表現に写像し、必要であれば逆の処理を行う
必要がある。しかし今回の開発ではこれを実現することができなかった。DAML+OIL によるオントロ
ジー記述は、モデルとしてのみ用いられ、実際のアプリケーションは、それとはほぼ独立に作成された。
(LispやPrologによる古典的な知識処理システムでは、問題領域の記述と、処理の記述がほぼ同一の言語を
もってなされるため、このような問題は生じていない。)
3.4.4 オントロジーサービスの開発
FIPA ではオントロジーサービスの規定を行っている(http://www.fipa.org/specs/fipa00086/)。オントロ
ジーサービスは、エージェントに対してオントロジーの作成、登録、検索、削除、更新等のサービスを提供
するエージェントによって構成される。本プロジェクトでは、当初、これを忠実に実装したComtec Agent
Platformのオントロジーサービス(http://ias.comtec.co.jp/ap/)を用いる予定であったが、上述の通り、アプ
リケーションのプラットフォーム依存性の問題のため、新たにこのサブセットを開発した。また、FIPAで
は規定されていない部分として、DAML+OIL による記述をサポートするような拡張がなされた。次に
FIPA のオントロジーサービスのリファレンスモデルを示す。
オントロジーエージェントは、一方でACL により他のエージェントと通信を行い、オントロジーの格
納、検索、削除、更新等の処理を行う。オントロジーエージェントは他方でOKBC のインターフェースを
32
用いてさまざまな知識表現システムと接続される。今回の新たな実装では、OKBC
を用いずに、
DAML+OIL の記述を自前のデータベースに蓄えた。次にウェブブラウザーによるオントロジーサービス
の人間用のインターフェースを示す。
このようにして開発されたオントロジーサービスであるが、アプリケーションによって有効に活用されて
いるとは言いがたい。前述の通り、DAML+OIL の記述を動的に取得できても、それを処理に結びつける
ことが困難だからである。
3.4.5 サービスの記述とその実行
サービスの記述には、DAML−S (現OWL−S) を用いることにした。他の候補としては、FIPA の規定で
インタラクションプロトコルの記述に用いられているAUMLがあったが、XMIによるシリアライゼーショ
ンが困難であったため、却下された。ここでも、DAML−Sの記述と、実際の処理を結びつけることが困難
であることが判明した。DAML−Sによってサービスの記述を作成し、それをオントロジーサービスに蓄積
することは困難ではないが、それをエージェントが用いることによって、動的に処理を行うためには非常に
大きな手間がかかる。この問題を解決するために、DAML−S の構文をXML からS 式に変換し、それを
FIPASLの関数として実行するような試みがなされた。具体的には、次のようなDAML−Sの記述があると
する。
<daml:item>
<process:If−Then−Else>
<process:IfCondition>
<rdfs:Class rdfs:about=”#DetermineTripType”/>
</process:IfCondition>
33
<process:ThenCondition>
<rdfs:Class rdfs:about=”#SearchFlightOneWay”/>
</process:ThenCondition>
<process:ElseCondition>
<rdfs:Class rdfs:about=”#SearchFlightTwoWay”/>
</process:ElseCondition>
</process:If−Then−Else>
</daml:item>
これをS 式に構文を変換すると次のように表現することができる。
(If−Then−Else
:if−condition (eq DetermineTripType t)
:then (SimpleProdess :effect (SearchFlightOneWay))
:else (SimpleProcess :effect (SearchFlightTwoWay)) )
そして、これをSL の関数として実行する。このことによって、サービス記述言語と実際の処理を行うコ
ンテント言語のギャップを縮める。しかし、この試みも一部で実験的に用いられるにとどまっている。
3.4.6 おわりに
Agentcities.RTD プロジェクトで用いられているオントロジー関連の技術について、問題点を中心に述べ
た。本稿ではふれなかったが、ACL のコミュニカティヴアクトの形式意味論も、アプリケーション開発の
妨げにこそなれ、有益には使えなかったという問題点も明らかになっている。セマンティクスやオントロ
ジーといった技術が現実のアプリケーション開発で有効に用いられるようになるためには、モデルの記述と
実装の記述を密接に結合する仕組みが必要である。
3.5 IEC/TC100への提案
AV機器を中心とする家電製品へオントロジを適用する考え方を, IEC/TC100に提案することを検討し
た。原案の概要を下記に示す。
3.5.1 Background
Computerization and network connectivity in home electronics field are going to force consumers complicated operations. Ontology application will be a candidate to solve those problems .
Mobile phones which have already been widely introduced to consumers are convenient tool for personal data management. Integration of mobile phone network and computerized home electronics is now
making new technology to customize the complicated operation. The technology is based on personal deta
of calender, schedule, addresses, location of car navigation, favorite TV programs, and so on. Ontological
technology will be applied to evaluate various categories and to select suitable operation using those data.
3.5.2 Proposals
(1) Standardize network model to utilize daily personal data
A home portal server such as TV PDR will manage family personal data and home electrocics equipments.
34
Ontology modules (middleware) will be implemented to the home portal server.
The ontology modules will improve the services and interfaces to the home electrocics equipments.
Current practical applications will be
1) TV program preference evaluation based on the history of watched programs,
2) easier parameter setting to network devices, and
3) easier parameter setting to computerized home electrocics equipments.
(2) Classification of ontology modules
Ontology technologies are classified as follows.
1) logic method (propositional logic, predicative logic)
2) metrics (state space distance, statistical approach)
3) semantics (generalized vocaburaries)
(3) Communication protocols based on ontology
1) Client server system
2) Peer to peer system
3) Agent communication systems
3.5.3 Other important items
For personal activity history will be used for the ontology application services and operation, then,
(1) establishment of privacy policies to protect personal data, and
(2) study the guideline and model to utilize personal data,
(3) and standardize the related architecture
will be needed.
35
4. .将来型文書への考察
4.1 ワークフロー管理とオフィス文書
4.1.1 はじめに
ある目的の達成に向けて活動する集合体が組織であり、組織は目的を達成するために活動する要員から構
成される。個々の要員の持つ知識や知恵は文書という目に見える形にして初めて,他者に伝達できる情報に
なる。つまり、組織における意思決定過程のコミュニケーションツールとして位置づけることができる。た
とえば、企画会議においては用意された企画提案書に基づいて議論が繰り広げられ、会議の内容を議事録に
するとともに決定事項を企画書にし、関連部署の合意を経て企画が実行される。つまり、文書は意思決定過
程プロセスにおいて、情報を記録し、伝達するための手段と位置づけられる。
オフィス文書には一般的に作成、レビュー、審査、承認、配布、保管、廃棄というようなライフサイクル
がある。さらに、このライフサイクルに関連した業務プロセスが存在する。業務を円滑に推進するには,業
務プロセスを自動化し,速やかに,正確に情報(オフィス文書)を流通させ,必要に応じて情報を参照でき
る仕組みが必要である。これを実現する1つの手段がワークフロー管理である。本節では,オフィス文書に
よる情報伝達をプロセスとして捉え,ワークフローの情報伝達への適用性を述べ,将来的な適用可能性を考
察する。
4.1.2 ワークフロー管理
ワークフローは,ある目的を達成するための業務の流れであり,複数の処理プロセス(以下,単にプロセ
スと呼ぶ)からなる。その流れに沿って処理されるべき処理単位を案件と呼び,案件はネットワークを通じ
て各プロセスを処理する作業者の計算機に電子的に流され,作業者は自分の計算機に到着した案件に対し処
理を行う。この業務の流れを定義,管理,制御するものがワークフロー管理システムである。オフィス文書
は、案件に相当する。
オフィス文書とのかかわりという観点でのワークフローの効果は,処理時間の削減、誤配・紛失の除去、
追跡可能、ペーパレスの推進という4点が挙げられる。さらにこれを実現するために組織が具備する機能と
しては、開発機能、実行管理機能、役割管理機能、進捗監視機能、業務見直し機能がある。
ワークフロー管理はあらかじめ定義されたビジネスプロセスと呼ぶ業務の流れに従って作業を処理する。
ビジネスプロセス定義は,業務の処理を表す処理ノードと制御方法を表す制御ノードを矢印(アロー)で繋
いで作成する。制御ノードは,1つの書類を複数の担当者に並列に送付したり,条件による分岐,不在時な
どの代行,内容に問題がある場合等の差し戻しなど,各種処理の制御に関わるものである。多数決で処理を
進めるような制御ノードを持つ製品もある。
4.1.3 オフィス文書と情報伝達
オフィス文書を本業の適性とビジネスプロセスの多様性という2つの要因で分析する。本業とのかかわり
は,本業に直接的にかかわるものか,間接的にかかわるものかという軸である。一方の多様性の軸は,その
ビジネスプロセスで起こる事象が反復的,定型的であるか,あるいはユニークなものであるかである。この
分類では,以下の4つのセルに分割できる。
36
(1) 本業にかかわり,ビジネスプロセスは定型的(プロダクション型):
融資稟議書,保険請求書,クレーム問い合わせ票,目標管理など
(2) 本業に直接かかわらず,ビジネスプロセスは定型的(アドミニストレーティブ型):
旅費申請書,精算書,購買伝票,勤務票など
(3) 本業にかかわり,ビジネスプロセスは多様(コラボレーティブ型):
企画書,提案書,稟議書,設計仕様書,マニュアル,特許など
(4) 本業に直接かかわらず,ビジネスプロセスは多様(アドホック型):
議事録,日報,儀礼的文書(招待状や委任状など)など
さらに,上記のオフィス文書の分類に対して適切な情報伝達手段を考えてみると以下のようになる.
プロダクション型は,高度で複雑なプロー制御が必要とされるが,プロセスは固定的なためワークフロー
での処理が向いている。アドミニストレーティブ型は,一般事務における各種伝票類の処理である。扱う情
報は定型的で,処理するプロセスも固定的なため,もっともワークフローが適した業務である。コラボレー
ティブ型は,技術文書の作成やソフト開発等の共同作業が対象となる場合が多く,ワークフローだけで業務
を実現することは難しい。文書を長期間取り扱うため,バージョン管理やビュー管理,コメント付与などの
文書管理機能も必要となる。アドホック型は,これらは不定期に発生し,プロセスも固定的ではないため,
電子メールや掲示板を利用する方法が一般的である。回覧や決裁の状況をモニタリングしたり,記録を残し
たい場合などは,ワークフローが利用することがある。
4.1.4 将来文書に対するワークフローの役割
ワークフローは定型的なビジネスプロセスを持つオフィス文書の情報伝達手段には向いているが,非定型
なビジネスプロセスを持つオフィス文書には向いていない。また,コラボレーティブ型やアドホック型は人
間系のかかわりが多く,ワークフローに載らない意思決定プロセスが必要である。特に,コラボレーティブ
型で作られる文書は,経営に直接影響する製品・サービスの開発や意思決定に関する重要な文書が多く,さ
らに複数の人間が複雑に関与し,文書のライフサイクルも長いという特性がある。これらの業務を支援する
ためには,高度な支援機能が必要である。
以上の通り,ワークフローは限界はあるもののうまく使えば極めて有効なオフィスツールである。文書
ベースのオフィスシステムを構築する際の指針をまとめると以下の通りになる。
(1) 定型プロセス…ワークフローでビジネスプロセスを自動化し,徹底的な業務のコストダウンを図る。
(2) 人間系プロセス…検討を含め,システム作りに時間とコストをかける。特に,文書を作成(創造)する
ための思考プロセス,共同作業を支援することが重要である。
この人間系プロセスの支援について,例を挙げて紹介する。
(1)ナレッジマネージメント
組織において意思決定や製品・サービス改善などを迅速かつ効率的に促進するには、企業内で創生された
膨大な情報・知識をいかに蓄積・活用するかというナレッジマネージメントが重要になっている。
37
ナレッジを拡充し,組織的に利用できるようにするために,オフィス文書を知識として取り込む仕掛けと
利用する仕掛けが必要である。まず,オフィス文書の作成(創造,起案),業務処理(審査,承認),保管・廃
棄というの一連の流れを業務プロセスとして定義する。この業務プロセスの中でオフィス文書を作成する際
に,知識検索エンジンで過去に承認を得た文書の中から作成したい文書の内容に近いものを検索する。次に
この文書を修正することにより,品質の高い文書を短時間で作成できる。また,審査,承認,合議の過程で
も過去の文書を参照することにより,判断基準を明確化できるため,意思決定を迅速に実施できる。最後
に,承認,合議が終了した文書を蓄積する。業務で作成された文書をワークフローで自動的に取り込むこと
により,巨大なナレッジ・データベースができる。これをさらに,このナレッジ・データベースを活用する
仕掛けをビジネスプロセスに盛り込み,ワークフローで実現することにより,文書の作成効率と文書の処理
効率が上がる。ワークフローの役割は,業務毎にこのナレッジ活用サイクルをビジネスプロセスとして実現
することである。これにより,様々な業務の処理効率向上はもちろん,ナレッジの創造,流通,活用のサイ
クルをルーチンワークとして取り込むことができる。日々発生する情報の正式バージョンや最終バージョン
をタイムリーに過不足なく蓄積して完成度の低い不要な情報を排除したクリーン化された情報だけが入った
ナレッジ・データベースの構築も可能となる。また,業務プロセスの起案時や審査・承認時等必要な場面で
ナレッジ・データベースから適切な情報をスピーディに入手し,所望の起案書を短時間で作成し,審査や承
認の工程で適切な判断のための一助として利用することも可能になる。
ナレッジ・サイクルでは,ナレッジ創造のフェーズがもっとも時間がかかるところであり,システム化が
難しい部分である。概念検索やあいまい検索,類似検索などの機能を持った知識検索ツールが数多くでてい
るので,これらを活用したシステム化が1つの解になるであろう。
(2)プロジェクト管理
情報システム開発の需要は根強く、開発の効率化と品質管理が大きな課題となっている。これを解決する
ためプロジェクト管理が重要である。情報システム開発のプロジェクトでは,仕様書やプログラムなどの膨
大な成果物の管理が不可欠で,成果物,すなわち文書を一元的に管理し,再利用を促し,作業効率を向上さ
せ,円滑なプロジェクトが推進できる仕掛けが必要である。これを実現するためには,主に以下の機能が必
要となる。
①
成果物の一元管理…各工程で作成した仕様書やプログラム,管理帳票等を一元管理し,再利用を図
る。バージョン管理や更新時の排他管理も実施する。
②
開発プロセスの管理…全工程の作業プロセスを明確化し,その進捗,実績を記録する。過去のプロ
ジェクトのプロセスをテンプレートとして新規プロジェクトに活用する。
③
成果物のライフサイクル管理…プロジェクトのプロセスの中で発生する文書(成果物)のライフサイク
ル(作成,レビュー,審査,承認,検査など)を管理する。
上記において,①は文書管理機能の利用で実現できる。②は文書管理機能を拡張するか,プロジェクト管
理ツール独自の機能として実現する。③の実現にはワークフローの利用が有効である。ここでのワークフ
ローの役割は,成果物のライフサイクルの管理であり,モニタリング機能による各成果物の進捗状況の把握
や期限管理等の管理作業も含む。
一方,プロジェクト管理業務のシステム化においてもっとも重要な機能は,ユーザーインタフェースであ
る。ユーザーインタフェースの操作性が悪ければ,業務効率も下がり,システムも利用されなくなるので,
38
ユーザーインタフェース部分の機能を十分に検討する必要がある。メンバとして複数のプロジェクトに所属
する場合もあるため,複数プロジェクトへのメンバ登録機能やプロジェクト全体をプロジェクトごとに見る
ためのビューや自分が担当している作業のみを見るためのプライベートなビューも必要となる。
4.1.5 おわりに
以上,オフィス文書に対するワークフローの現状の役割と今後期待される適用可能性について考察した。
オフィス文書を本業の適性とビジネスプロセスの多様性の2つの要因で分析し,ワークフローの適性を明ら
かにした。特に,人間系のかかわりがあるアドホック型のオフィス文書は,ワークフローに載らない意思決
定プロセスを支援することが重要であり,特に人間系のプロセスをシステム化すことが課題であること示し
た。最後に,将来型文書に対するワークフローの適用可能性と役割について考察した。
4.2 Voice BrowserとMultimodal Interactionに関する動向
文書情報のコンピュータ間での交換や自動処理という観点とは別に、人間に対する文書内容の提示という
観点からみた場合、従来の文書は文字や図像を格納し、提示時にはそれをページイメージの形で表示すると
いう形態がもっとも一般的であった。ウェブ文書においても、CUIからGUIへの発展はあったものの、基本
的に視覚への提示に特化し、出力装置としてはディスプレイやプリンタが用いられている。また、文書との
インタラクションという点では、提示されるだけの文書から、ハイパーリンクやフォームを用いて、提示さ
れた文書に対して人間がはたらきかけることが可能となっているが、そこで用いられる入力装置はキーボー
ドやマウスなどのポインティングデバイスである。
これに対して、音声チャネルを指向した動きとしてVoice Browserがある。これは人間に対して音声で情
報を提供し、音声ないしダイヤルトーンで情報を取得しながら、対話形式でウェブにアクセスするためのも
のであり、W3CのVoice Browserワーキンググループにおいて仕様策定が進められている。
音声で情報を提供することにより、視覚を自由にでき、目の不自由な人や、他の目的で視覚を占有されて
いるような状況でも情報を得ることができる。また、入力も音声で行うことにより、手がふさがっている状
況でもアクセスが可能となる。VoiceBrowserの構成要素としては音声認識、音声合成、対話管理があり、
それぞれに関する技術文書が存在する。
・VoiceXML 2.0
特許問題などで遅れていたが、2004年2月に勧告案 (Proposed Recommendation) となった。対話制御の
方法を記述するための枠組みである。合成音ないし録音音声の再生、音声認識結果ないしダイヤルトーンに
よる対話制御を記述する。特許問題については、最終的にW3Cのロイヤリティフリーライセンスに従って入
手可能なオープンな仕様となった。
・Speech Recognition Grammar(SRGS)
2003年12月に勧告案となった。音声認識のための文法を記述するための枠組みである。
・Speech Synthesis(SSML)
2003年12月に勧告候補(CR)となった。テキストから音声合成を行うためのマークアップ言語である。
・Semantic Interpretation for Speech Recognition
39
2003年4月にワーキングドラフトが出ている。音声認識における認識結果の意味解釈を行うためのもの
である。
・Call Control(CCXML)
2003年6月にワーキングドラフトが出ている。通話呼び出し制御といった主に電話環境におけるリソー
ス制御を行うためのものである。
VoiceXMLは主に電話系を指向しており、従来のウェブ文書にそのまま組み込むというよりも、何らかの
変換をかけて、VoiceXML文書を新たに作成するという使い方になる。これに対して、従来のウェブ文書に
音声入出力機能を付加するものとして、
・XHTML + Voice Profiles
・Speech Application Language Tags (SALT)
がある。
前者はモジュール化されたXHTML文書に対して音声入出力用のプロファイルを追加するもの、後者は
HTMLに独自の拡張タグを埋め込むものである。
さらに、GUIや音声入出力にとどまらず、より広範な入出力チャネルを使ったインタラクションを指向す
る動きとして、W3CのMultimodalInteractionActivityがある。現状ではデバイスの制約などから身体の動
きをとらえることは難しいが、たとえばペンデバイスを用いたインタラクションが検討されている。関連す
るワーキングドラフトとしては以下のものがある。
・Extensible Multimodal Annotation Markup Language (EMMA)
2003年12月ワーキングドラフト。入力装置とインタラクション管理システムとのデータ交換に関する仕
様。
・Ink Markup Language
2003年8月ワーキングドラフト。ペン入力に関する仕様。
4.3 個人や家庭における情報管理と文書
4.3.1 背景
将来型文書として取り上げるべきカテゴリとして、モバイル環境を包含する個人環境の文書がある。イン
ターネットの普及に伴い、Eメールが個人間のメッセージのやりとりとして定着し、さらにWebが情報公開
手段として定着した。さらに携帯電話による同様な世界がiモードを発端にしてモバイル環境のメッセージ受
信、情報参照手段として普及しつつある。
従来の文書が企業や官庁におけるオフィス文書を中心に考えられていたのに対し、インターネットや携帯
の文書は個人を指向する。オフィス文書が生産者や行政者、管理者といったサービス提供カテゴリの情報流
通であったのに対し、個人指向の文書は、サービス利用者であり生活者としての個人や家庭に基軸を置く。
今後の検討対象としての文書は、このような時代の変化を視野に置いた分析を考慮すべきであると思われ
る。
40
4.3.2 情報集合から人間関係の問題へ
当委員会の本WGの中心テーマであるメタデータ、オントロジといったメタモデル的な領域は、データや
文書が包含する情報集合と要素あるいは、情報集合相互間、情報要素相互間の関係付けの議論に過ぎず、こ
のような検討が文書というカテゴリに占める位置は期待したほど大きなものではなさそうであるというの
が、過去3年間の検討結果であると思う。検討の経緯で見出したのは、インターネットや携帯がもたらす人
間関係の変化である。
Perpetual Contact[1]という本がある。これは、ケータイがもたらした世界各国の社会や文化へのインパ
クトの社会学者による報告である。この報告書は、ケータイのもたらした社会文化的影響で、公的な領域と
私的な領域の区分が不明確になったことを挙げる。携帯電話でもって常時通信可能となり、インターネット
で情報共有が可能となったことにより、オフィスにいなくても仕事が可能になった。その結果、外出時には
公的な仕事と私的な遊びが共存するような状況が生まれつつある。サテライトオフィスやインターネットカ
フェといった存在は、その産物であろう。さらにその結果、勤務時間という概念が厳密ではなくなった。
4.3.3 情報技術に対して無防備な社会
以上のような社会変化は、人間関係にも大きな影響を及ぼしつつある。人間同士のコミュニケーションが
場所に基づく場合は、オフィスや地域社会、家庭などが人間関係確立の支配的な要因であった。しかしサイ
バースペースと化したネットワーク社会では、人間関係は場所や地理的な関係を簡単に凌駕してしまう。
Eメール、Webサイトはその端緒であった。TV会議では、ネットワークが会議室になり、eラーニングは教
室の役割をネットワークが代行する。だが良いことばかりではない。インターネットや携帯が提供する人間
関係の深刻な状況は、出会い系サイトやそれらのもたらす社会的な問題に表われている。
ブロードバンドによるリッチコンテンツの容易な伝送は、ビデオ会議や教育、娯楽といった新たなビジネ
スやサービス領域を切り開いたが、ネットワークを介在させた違法コピーや企業情報、顧客情報の大量漏洩
といった新たな社会問題を引き起こしつつある。このような問題は、出会い系サイトと同様に、個人指向の
広帯域なネットワーク技術が無防備な社会と接触した過程で引き起こされた必然的な結果であろう。人間社
会が知的で聡明であるならば、そのような問題に対処する術を持つことを考えねばならない。
4.3.4 サイバースペースにおける社会的ルールの確立
上記問題の解決は、社会的なルールの確立に求められねばならないが、そのためには時間を必要とする。
インターネットがグローバルであるから、グローバルな合意を必要とするであろう。先進国から途上国ま
で、キリスト教から儒教、仏教、ヒンズー教、イスラム教までの多様な世界の合意を取るのは容易ではない
であろう。しかしそのような状況を置き去りにして技術はさらに進展し続ける。
人間関係を技術がコントロールする考え方も存在する、たとえばCRM(Customer Relationship Management)である。個人の生活履歴をデータベース管理して、個人の嗜好や属性に基づき最適なサービスを提供
する思想である。当WGが昨年から今年にかけて取り組んだ、視聴者プリファレンス、家電製品へのオント
ロジ適用、ネットワーク自動設定などの課題は、個人の履歴情報を活用するCRMの応用と言えるであろう。
しかし、この技術も一皮剥くと深刻な問題に突き当たる。携帯電話網は、携帯電話の持ち主の場所を基地
局レベルで常時監視しており記録が取られている。GPS付の携帯電話が使われ始めたが、この場合はさらに
高精度で位置情報が管理される。自動車のナンバープレートの監視装置が全国の主要道路に設置されている
41
が、これにより個々の自動車の位置は常時把握されていると考えられる。JRのSuicaカードは、改札口を通
るたびに記録され、持ち主の乗車履歴はJRのデータベースに記録されている。
以上のような情報が照合されると、本人の意図せざるところで、本人が知らない個人情報が第三者により
把握されることになる。これも無防備な社会が高性能なデータベース技術と接触した場合に必然的に引き起
こされる問題である。人類が賢ければ、このような問題に対処する術を持たねばならないであろう。
4.3.5 過去の技術からの教訓
自動車が発明された時、馬車に代わる便利な乗り物として注目されたであろうが、当時の社会は自動車に
対してはまったく無防備であった。それを社会に定着させるまでには、運転操作の標準化、交通規則の制
定、車検制度、自動車学校の整備、排気ガス規制、自動車専用の高速道路の整備など、社会化(ソーシャラ
イゼーション)のための数多くの努力が積み重ねられた。それでも多くの人が自動車事故により生命を落と
したり怪我を負わされたりしているのが実情である。
航空技術も似たような側面を持つ。この技術は、一つのミスが致命的な大事故につながる。そのために、
事故の度に原因を突き止めるための分析を行った。その結果、機体の製造、保守などに関する詳細な記録を
管理する手法を確立し、安全な交通手段としての地位を確立した。このような航空宇宙分野においてドキュ
メント管理技術は大いに貢献すると同時に進展した[2]。
インターネットやケータイの技術も、似たようなものであろう。便利なものではあるが事故も起こる。そ
の防止のために、これからの社会は努力を惜しんではならない。ISMS、個人情報保護法や企業コンプライ
アンスの議論などは、その第一歩にすぎない。
4.3.6 国立公文書館の碑文
人間同士のコミュニケーションを媒介するのは文字通り情報メディアであった。人間とネットワーク、人
間とコンピュータとのやり取りを媒介するのは電子化文書である。将来型文書の問題は、
「情報技術に対して
無防備な社会」の問題を包含する人間、コンピュータ、ネットワーク相互間のコミュニケーション領域の問
題を扱うことを期待されていると考える。しかしそれは漠としている。
The Heritage of the Past is the Seed that brings forth the Harvest of the Future.
この句は、ワシントンDCにある国立公文書館(National Archives)の碑に刻まれている一文である[3]。
訳すと、
「過去の遺産は将来の収穫をもたらすべき種である」ということである。この文は当委員会の名称で
ある将来型文書という言葉を考える上で気になる警句であった。さらに3つの文があり、その一つに
What is Past is Prologue.
という一文がある。これは「過去は幕開けである」とうことであり、現在が過去につながって存在するこ
とを提示する。別の碑文は語る。
Study the Past.
「過去から学べ」と。さらに最後の碑文は、
Eternal Vigilance is the Price of Liberty.
42
「永続的な警戒は自由の価格である」要するに、自由な世界を維持するには常に警戒を怠ってはならない
ということであろう。上記で取り上げた「情報技術に対して無防備な社会」の問題は、まさに現在の世の中
で警戒を要することであり、将来型文書のあり方を考えると必要な視点である。文書は常に人間相互間のコ
ミュニケーションの媒体であるとともに過去の事実の記録であり、現在はそれを「サイバースペースにおけ
る社会的ルールの確立」を目指して将来の社会に役立たせることが求められている。
文献
[1] E. Katz, et. al.; ”Perpetual Contact”, Cambridge University Press,(2001)
[2] 大野邦夫; ”オフィス文書とXML(その3:ワークフローとビジネスロジック管理)”, 電子
情報通信学会OIS研究会報告(2004.1)
[3] 大野邦夫;”WEBがデータベースとなる時代:米国の技術動向と日本企業が行うべき変革”,
XML Magazine 2001 07, pp.52−64,(2001.7)
4.4 電子政府・電子自治体とXML
4.4.1 1. 電子政府・電子自治体の目標
世界最先端のIT国家実現を目標においたe−Japan計画にあって、その重点施策のひとつに「行政の情報化
及び公共分野における情報通信技術の活用の推進」が挙げられている。電子情報が紙情報と同等に扱われる
効率的でサービスの良い電子政府を実現し、すべての行政手続の電子化等を可能とすることを目標においた
ものである。
一方、行政情報化基本計画策定以前より行政機関(政府・地方自治体)においては、さまざまな電子化へ
の取り組みがなされ、すでに多くのシステムが稼動している。今日の行政情報化の目標は、これまでの個別
の組織での電子化という枠を超えて、それぞれの機関が運用するシステム群の相互連携を実現し、住民・企
業等の利用者が利用しやすい、統合化された行政機構の実現を意味するものに移行していると捉えられよ
う。すなわち、住民・企業等が一つの窓口(One Stop)で、24時間いつでも(Non Stop)、どこにいても
(Any
Stop)行政サービスが受けられるよう整えることに目的が置かれる。
一方、広範に普及したWeb機構は、当初のあるサーバ(WEBサーバ)に蓄積されたコンテンツを利用者側
のブラウザで閲覧可能とすること、すなわちサーバ上のコンテンツを人間に対して提示するといった機能
(システム対人間インタフェース)から発展し、システム対システムの協調的なデータの授受と処理を可能
とすることを実現している。その構造の基礎とされるのがXMLによるシステム相互のアーキテクチャーの相
違を克服したメッセージ交換の方式(システム対システムインタフェース)であり、さらにWebサービス
(XML Web Services)による、ネットワーク上に接続された複数サーバ間の協調的連携の実現である。
これまで、それぞれの担当部署での手続き(Many
Stops)が必要とされたものが、相互連携可能となれ
ば、国民は一つの窓口において手続きが完了することとなり、多くの煩瑣な手続きから解放されるととも
に、行政側においても大幅な作業量の圧縮が期待できよう。
しかし、これらの実現に向けて解決しなければならない課題は山積している。ひとつは、行政システムの
相互連携を可能にするための標準化の課題であり、また長らく書面主義(書面を前提としてきた行政手続
き)にあった仕組みの「データ主義」すなわち電子データを基礎においた行政手続への移行である。他方に
おいて、今日社会問題ともなっているネットワーク・セキュリティの問題が大きく立ちはだかっている。
43
4.4.2 行政システムの現状と問題点
(1)ポータルサイトの設営
ポータルサイトとは、窓口として情報提供などを行うウェブサイトのことで、住民・企業等の利用者が
インターネットを利用する際に拠点として訪れるサイト(webサイト)とされる。現在、各自治体、行政機
関では、所管する業務を統合的に案内するポータルサイトの設営が進められている。
今日の行政情報化の実現に向けて、ポータルサイトが果たすべき役割は大きい。しかししながら、現状で
の行政ポータルサイトは、主に情報提供に主眼がおかれ、相互の業務連携を実現する目的とは、かなりの隔
たりがある。さらに、情報提供ポータルサイトとしても、各機関がそれぞれ独自に情報管理と運営にあたっ
ているため、ある自治体での掲示情報が他の自治体では存在しないといったサービス内容の相違も発生して
いる。
これらの相違は、統合された窓口の実現に向けては大きな障害となる。行政の情報提供ポータルサイトと
しては、これらの地域格差を是正し、各自治体のいずれもが一定のサービスレベルを実現するための標準化
が望まれる。政府機関においては、総合窓口(www.e−gov.go.jp)が整備され、利用者に向けて、各行政機関
のサービスを総合的に案内する試みが行われている。上記の自治体全体に亘る一定のサービスレベルの実現
を基礎として、今後この機構を拡張し、国の行政機関はもとより、各自治体、さらには、関係企業などに敷
衍し、総合的に行政情報(サービス)を案内できる機構を整備していくことが求められよう。
(2)情報提供ポータルサイトから、手続きポータルサイトへ
現在の行政ポータルサイトの多くは、上述のように情報提供サービスにとどまるものであり、一部に、申
請・届出のための電子的フォームのダウンロードサービスが実現されつつも、ネットワークを用いた申請・
届出等の手続が実施できるところには至っていない。行政ポータルサイトとしては、行政の総合窓口として
利用価値を高めるためにも、情報提供を主体とした情報提供サービスポータルから、電子的な申請・届出等
手続を行うことができる手続きポータルサイトとして進化していくことが望まれる。さらに、付属機関、公
益企業、民間企業のサイトとの効果的なリンクをとることも必要とされよう。このような統合化されたプロ
セスを、利用者視点にたって行政機関横断的に実現するためには、XMLやWebサービスに求められる役割は
極めて大きいものとなる。
(3)XMLの採用
今日の行政に求められるアカウンタビリティの確保、また公的文書としての保存性、行政相互間の手続き
連携などを踏まえ、扱う文書類(情報)自体のXMLを利用した記述が進められている。既に、総務省では、
「地方公共団体における申請・届出等手続に関する汎用受付システム」の開発にあたり、交換データの形式
についてはXMLを採用することを表明(平成14年度)している。同じく平成14年度に、国税庁は国税の電
子申告を行う際の添付書類(決算書部分)のデータ形式としてXBRLを受け入れることを発表している。そ
の後、平成15年8月に発表された、e−Japan重点計画−2003においては、輸出入および国内物流EDI基盤の
国際標準化を進め、国内物流EDI標準(JTRN)を国際標準化するため国際標準化検討機関への積極的な働きか
けと国内物流EDI標準のXML化を並行して行うとしている。併せて、アジア地域における事業者間電子商取
引の基盤整備のために、XML言語を利用したEDIの国際標準化規格(ebXML)の、アジア地域内の普及促進に
44
取り組むことがあげられている。また、GーXML規格に基づき、GISコンテンツの相互流通を促すことも目
標にあげているところである。
これら多くの分野において、XMLの適用が進展されつつあるが、一方で、行政機構間の手続き連携を実現
する上では、いわゆる「標準化」の課題は避けて通れない。手続きポータルサイトを実現する上では、基本
となる情報群(姓名、住所、本籍、資格その他)について、記述形式はもとより、関係するそれぞれのシス
テムが意味論的に解釈可能な標準化が不可避であろう。
4.4.3 書面主義とデータ主義
すべての行政手続きを電子的に行うことを可能とすることは、永らく「書面主義」のもとにあった行政手続
きを「データ主義」ともいうべき新たな枠組みに置きかえることを意味する。幸いにして、XMLをはじめ
とし、文書類を電子化しネットワークで可搬とする技術は成熟しつつあり、すくなくとも技術的な側面から
判断する限りにおいて、行政手続きの電子化は不可能ではなくなっている。
しかしながら、一方で「紙書面」に基づいて永らく運営されてきた法制度を含めた社会制度は、データ主
義を基礎としたものに大きく置き換わりつつあるとは言い難い。その結果、紙書面での手続きを温存したま
ま、データに基礎をおいた機構を構築せざるを得ない。ここに「二重開発、二重運用」の弊害が大きくク
ローズアップされつつある。書面による手続きを温存する以上、この弊害はいつまでも受け入れざるを得な
いものであるし、行政電子化が行政のスリム化どころか、肥大化を招く原因そのものともなる怖れが指摘さ
れる。データに基礎をおく手続きと、書面に基礎をおく手続きとの相違点を明確に把握し、ネットワークの
手続きが、従来の書面手続きと同様に法的にも扱えるように整備しておくことが求められる。以下に、書面
主義とデータ主義の相違点を挙げる。
(1)書面主義:書面(様式類)をそのままPDF等の形式で電子化し、書面の現行の様式、行政手続を踏
襲しつつ、ネットワークで可搬とすることにより、主として時間短縮の効果を発揮する。
(2)データ主義:書面(様式類)の構成要素を分解し、様式(プレゼンテーション)と、構成要素(ス
トラクチャー)、並びに内容(コンテンツ)に分け、それぞれの用途に応じて、使い分ける。
上記(1)の方法は、現行の書面をそのまま踏襲し、市民・行政双方の基本的手続を変化させることはな
い。言い換えれば、これまでボールペンと印鑑を用いて持参・郵送してきた書類を、コンピュータのキー
ボードにより入力し、電子署名を施して、ネットワークを介して、従来の受付部局にオンラインで提出する
こととなる。もちろん、この場合でも、郵送・持参に比較して、大幅な時間短縮が可能とされる。ただし、
現行の行政手続を反映した書面の様式が変化しないため、行政手続そのものの変化・改革を実現することに
は結びつかないことは明らかであり、IT基本法で謳われる「国民の利便性の向上」を実現する意味における
効果は期待し難い。
一方(2)の方法は、申請・届出のデータに着目し、入力時または出力・表示時には、該当する様式上で
入出力を行い、検索したり、処理手続に際しては、コンテンツならびに構成要素情報を用いたりする方式で
ある。この構造のもとでは、同じコンテンツを、異なる表示形式で開示したり、また、複数コンテンツ横断
的に、データを組み合わせ、別な情報として、他の部局に提供したりすることも可能とされる。異なる様式
上で共通に利用されるデータ(コンテンツ)に関しては、重複入力を不要としたり、また、毎年繰り返す届
出等に関しては、昨年度のデータを参照し、変化しない部分が特定できれば、あらかじめ該当する部分を埋
め込んだ申請様式を申請者に提示したりするなど、ネットワークの時間短縮効果にとどまらず、市民・行政
45
間での手続そのものを大幅に改革することが期待できることとなる。いわば、従来の紙書面主義とも理解さ
れる申請
・届出手続を、データ主義に置き換え、新しい業務構造をもたらすきっかけを与えるものでもある。
(1).内容・構造・様式データの分離
XMLは、
「タグ言語」と呼ばれるデータ表現言語を生成するためのルールを意味する。すなわち、ある
データの集合にあって、その構造を表現し、またそこで使用されている語彙(ボキャブラリ)の定義を与え
る文法である。言い換えれば、様式を指定する機能は持たず、関連規格である、XSL(eXtensible Style
Sheet Language)やCSS(Cascading Style Sheet) などを用いることとされる。
より一般化して言えば、書面上にある、内容(コンテンツ)と構造(ストラクチャー)データのみを対象
とし、版面・様式(プレゼンテーション)は、分離して扱うこととなる。構造データには、その申請データ
の、改版履歴などを記録し、内容データでは、様式上に設定されている「氏名」、「住所」、
「電話番号」など
のデータが、それぞれの意味をもって記録されることとなる。これにより、
「秋田」という文字列が、
「秋田
さん」という人名を意味するのか、
「秋田市」なのか、
「秋田県」なのかが、コンピュータシステムで判定可
能であり、もちろんXML表記された文字列データとして、人間にも判断可能とされる。ちなみに、今日多用
されているHTMLやPDFは、XMLと異なり、内容と表現様式は一体のものとして扱われる点は紙書面と同
様である。このように、紙書面では、一体化されていた「内容、構造、様式」情報を、それぞれ分離するこ
とにより、従来は、記載された書面をもって回付していた申請データが、当該部局が必要とする部分のみを
回付したり、複数の申請者から送られてきた申請データを、必要部分を集約して、一括して回付したり決裁
したりすることが可能となるなど、行政の内部手続きの電子化に際して、従来の紙書面中心型の処理手続で
は実現し得なかった、コンピュータ機能を活かした新しい業務フローが実現可能となる。すなわち、XMLの
積極的適用は、現存する様式類に依拠した業務フローの電子化ではなく、体裁、内容、構造の3つを分離し
て扱うことによる新しい行政上の業務フローの実現をもたらすことが期待されるものである。
(2) 文書の保存
文書を電子化する効果の一つとして、(1)保管スペースの削減、(2)検索効率の向上、など、保存に関わる
便宜の提供が挙げられる。上述したように、XMLでは、内容(コンテンツ)に加えて、構造(ストラク
チャー)情報も扱えるため、例えば、改版履歴など構成管理に関わる情報も、検索項目として指定可能であ
り、内容(コンテンツ)に付与されたマーク(住所、氏名などのタグ)とともに、柔軟な検索構造が実現で
きる。このような、柔軟な検索構造は、今日ウェブページに対して提供されているYahoo!などの検索エンジ
ンでは、実現が不可能であり、PDF形式についても、同様の制約を持つ。
一方、例えば著作権法の対象がそうであるように、文書の保存にあっては、その作成時点での版面そのも
のを保存すべきとの論もある。実際、本人の筆跡などが判定可能な自筆の書面にあっては、その原本を保存
することに意味がある。一方、電子化した場合、本人性の特定は不可能となる。だれでも同じドキュメント
を作成することが可能とされる。加えて、XMLは、内容と構造データのみを対象としているため、本人性を
検証可能とするためには、XML署名などの方途が必要となる。また、作成された文書の版面の保存に関して
は、作成時点でのスタイルシート(電子様式)と、内容・構造とをバインド(一体化)して保存するか、ま
たは、一旦PDFなどの版面と内容を一体として扱う形式に変換しなければならないこととなる。すなわち、
データ主義に移行する上では、おのおのの電子データを特定できる機構が必要とされる。
46
4.4.4 非改ざん性、原本性、本人性の確保
データ主義への移行に際して、もっとも大きな障害は、電子データの証憑としての脆弱性にある。すなわ
ち、寸分異ならない複写を可能とする電子データは、原本としての特定が不可能であることを意味し、また
改ざんされたものとオリジナルなものとの判別を大きく制約する。特に、XMLでの記述は、データの部分利
用、組み合わせ利用を可能とするものであるため、オリジナルでは可能であった本人性の確認が、これらの
処理の過程において制約されることとなる。
一方、税務監査を取り上げても、また今日話題となっている国民・市民に対する行政のアカウンタビリ
ティの確保を実現するうえでも、オリジナルのドキュメントを証憑として厳密な非改ざん性をもって保全し
ておかなければならないことは明らかである。その点において、電子データは致命的ともいえる欠陥が指摘
されるが、それを取り上げてデータ主義への移行を否定することは、批判を浴びているわが国電子化の立ち
遅れを一層際立たせる結果につながるものといえる。今日の課題は、
「電子化」を大原則におき、その前提を
受け入れた上で、書証、証憑類の非改ざん性、トレーサビリティをどのように実現していくかにあるといえ
よう。
47
5. あとがき
昨年度から今年度の活動を通じて, 将来型文書の方向性として,
(1) セマンティックWeb(オントロジ)関連技術の適用
(2) モバイル環境や家庭を包含する利用者指向環境関連文書とその活用
(3) ビジネスロジック, ワークフローに関連する組織文化, 企業文化の課題
などが課題として提起され、本年度は以上の項目に関して掘り下げた。以上の報告は、その個別領域の検
討内容の総括を、担当した委員が記述したものである。将来型文書という概念は、検討すればするほど高度
で奥深いものであることを痛感せざるを得ないのであるが、以上の報告は、その様々な切り口における最新
状況が記されている。
次年度も, 以上の課題を追求するとともに, 上記(1), (2)項に関連する具体的な規格案であるIEC/TC100の
AV機器へのオントロジ適用について検討をすすめたいと考える。
48
ダウンロード

付属資料 WG2成果レポート