「フリーソフトで学ぶ - 森北出版 ·...

「フリーソフトで学ぶ

セマンティック Web と

インタラクション」

サンプルページ

この本の定価・判型などは，以下の URL からご覧いただけます．

http://www.morikita.co.jp/books/mid/084901

※このサンプルページの内容は，初版 1 刷発行当時のものです．

http://www.morikita.co.jp/books/mid/084901

まえがき

セマンティックWebは，一言でいうと，世界規模の機械可読なデータ群をWebの

仕組みを用いて作ろうとする試みです．人間が読むWebページであれば，お手本を見

て，なんとなく HTMLらしいファイルを作成すれば，多少規則違反があってもWeb

ブラウザがそれを適当に表示して，多少あいまいな表現でも読み手がそれなりに解釈

をしてくれます．しかし，データを機械処理可能にし，それらを知識とよべるレベル

にするためには，その構文や意味に関して厳密に決められた多くの約束事が必要にな

ります．現在は日々進化するWeb技術の中で，これらの約束事を積み上げている段

階だといえます．

一方で，Webにおけるインタラクション技術の分野でも新しい動きがあります．テ

キスト情報よりもリッチな，画像やマルチメディアによる情報提供や，携帯電話から

音声を用いたり，モバイル端末から音声とタッチを用いたりしてWebにアクセスす

るための「ことば」や枠組みが発展しつつあります．セマンティックWebが発展し，

より豊富な情報を引き出せるようになると，それに伴って必然的にインタラクション

技術も高度化していきます．当然，インタラクションを記述するための言語にも進化

が望まれます．

これら，セマンティックWebやWebインタラクションに関する約束事は，W3C

(World Wide Web Consortium)という国際標準化団体で決められています．W3C

のWebサイト (http://www.w3.org/)では，これらの約束事を記述した仕様書や技

術文書を多数公開しています．しかし，たいていの仕様書は，次から次へと定義が出

現し，正直，読み進めて行ってうんざりすることもあります．さらにW3Cの活動が

（すなわちWeb関連技術が）現在進行形でその範囲を広げていることが，この仕様書の

読みにくさに拍車をかけています．仕様を決めるべき対象が多岐にわたり，それらが

分散したグループで並行して議論されています．あるグループの作成した仕様書の中

で別のグループの仕様書を参照しており，さらにそれを理解するためには別のグルー

プの仕様書を理解しなければならないなど，これからこの分野を勉強しようとする人

には高い壁がそそり立っているように見えると思います．

本書は，この高い壁にアプローチする手段として，「必然性」からの視点を提供した

いと思います．約束事は「必然性」に基づく根本的な部分と，それを技術として成り

立たせるための補足的な部分からなると仮定し，説明を「必然性」に基づく根本的な

部分に集中します．仕様書は約束事を誤解なく伝えるための文書ですから，その約束

i

まえがき

事を決めるにあたって皆で共有しているはずの「必然性」が表に出てきにくくなって

います．逆に，この「必然性」さえ正しく理解すれば，約束事，すなわち「ことば」の

体系や，他の「ことば」との関係が見えてくるはずです．さらに，年月を経て「こと

ば」が進化しても，この「必然性」の根本は，それほどは変わらないはずです．

また，本書のもう一つの特徴として，フリーソフトウェアを用いながら例題を解い

て，知識を身につけるというスタイルを取ります．学んだ「ことば」を使って，自分

で表現を作成し，それが自分の意図していたことを意味しているかどうかを，フリー

ソフトウェアを動かして確認します．本書では，仕様書のすべての項目は解説できま

せんので，例題や演習問題を解くためには仕様書を読まなければならないかもしれま

せん．しかし，それは仕様書を先頭から受動的に読んでいく作業とは異なります．「こ

ういう機能があるはずだ」というように能動的に読む（あるいは探す）ことになりま

すので，短時間で重要な情報は頭に入ると思います．

本書は，情報工学を学ぶ大学生や専門学校生を対象に記述したものですが，「いつ捨

てられてしまうかもわからない取り決めを羅列しているだけだ」という批判を受ける

かもしれません．しかし，中森眞理雄氏はコンピュータと教育に関連する文献の中で，

「取り決めを覚えることは学問ではないが，どのような取り決めをすればうまくいくか

を考えることは学問である．取り決めの学という性格は，情報工学・情報科学におい

て著しい．」と述べています[1]．本書が「取り決めの学」としての情報工学を学ぶ人の

助けになれば，これに勝る喜びはありません．

2010年 10月著者しるす

ii

目次

第部未来のWebを作るために

第 1章セマンティックWebとは何か 2

1.1 現在のWeb ··························································· 2

1.2 データのWeb ························································ 3

1.3 セマンティックWebへの道筋 ·································· 8

第 2章インタラクションの高度化 11

2.1 情報を人に届けるために ·········································· 11

2.2 マルチモーダルインタラクションの実現 ···················· 14

2.3 人とのインタラクションを記述する方法 ···················· 16

第部セマンティックWebの基本技術

第 3章 RDF—情報の表現法 20

3.1 RDFの必然性 ······················································· 21

3.2 RDFの仕様 ·························································· 30

3.3 RDFの実践 ·························································· 32

第 4章 XML—「ことば」を作るための約束事 37

4.1 XMLの必然性 ······················································· 38

4.2 XMLの仕様 ·························································· 44

4.3 XML Schema—「ことば」の決まりを書く「ことば」 ··· 47

4.4 RDFの XMLによる表記 ········································ 50

第 5章 RDFを作る—マイクロフォーマット, GRDDL, RDFa 53

5.1 マイクロフォーマット ············································· 53

iii

目次

5.2 GRDDL ······························································· 57

5.3 RDFa ··································································· 64

第 6章 SPARQL—問い合わせの言語 68

6.1 SPARQLの必然性 ················································· 68

6.2 SPARQLの仕様 ···················································· 69

6.3 SPARQLの実践 ···················································· 76

第 7章 RDFS—いわれていないことを推論するために 78

7.1 RDFSの必然性 ····················································· 79

7.2 RDFSの仕様 ························································ 82

7.3 RDFSの実践 ························································ 86

第 8章 RIF—推論規則を書く 91

8.1 RIFの必然性 ························································ 92

8.2 規則記述の標準化—RIF-Core ·································· 96

8.3 RIFの実践 ··························································· 98

第 9章 OWL—オントロジーを作る 100

9.1 OWLの必然性 ······················································ 101

9.2 OWLの仕様 ························································· 102

9.3 OWLの実践 ························································· 108

第部マルチモーダルインタラクションの基本技術

第 10章 HTML—文書のWebのための「ことば」 112

10.1 HTMLの必然性 ··················································· 112

10.2 XHTMLの仕様 ··················································· 115

10.3 HTML5 ······························································ 122

iv

目次

第 11章 VoiceXML—会話の方法を教える「ことば」 128

11.1 VoiceXMLの必然性 ············································· 128

11.2 VoiceXMLの仕様 ················································ 130

11.3 文の規則を決める—SRGS ······································ 136

11.4 意味表現の作り方を決める—SISR ··························· 139

11.5 読み方を記述する—PLS ········································ 141

11.6 音声合成マークアップ言語—SSML ························· 142

11.7 VoiceXMLの実践 ················································ 143

第 12章 MMIアーキテクチャ—豊かなやりとりの実現に向けて 147

12.1 MMIアーキテクチャの必然性 ································ 147

12.2 MMIアーキテクチャの仕様 ··································· 150

12.3 MMIアーキテクチャの関連規格 ····························· 153

第 13章 SCXML—状態遷移を記述する 156

13.1 SCXMLの必然性 ················································· 156

13.2 SCXMLの仕様 ···················································· 157

13.3 SCXMLの実践 ···················································· 162

第 14章図形を表現する—SVGと canvas 164

14.1 SVGの必然性 ······················································ 164

14.2 SVGの仕様 ························································· 166

14.3 SVGの実践 ························································· 170

14.4 canvasの必然性 ··················································· 172

14.5 canvasの仕様 ······················································ 173

14.6 canvasの実践 ······················································ 173

14.7 InkML—手書き入力の表現 ···································· 175

v

目次

第 15章 SMIL—マルチメディアコンテンツを表現する 177

15.1 SMILの必然性 ···················································· 178

15.2 SMILの仕様 ······················································· 179

15.3 SMILの実践 ······················································· 181

付録A 演習問題の解答 183

付録B インストールガイド 192

参考文献 195

索引 197

vi

第部

未来のWebを作るために

Web の発展という言葉から，ブログ・Twitter・ソーシャルネットワークなどを連想する人が多い

かもしれません．それらは現在の Web のしくみを利用した新しいサービスの提供です．W3C ではWeb のしくみそのものを改良することによって，私たちを取り巻く情報環境をもっと便利に，

もっと人に優しくすることを目指しています．第

部では，もっと賢く，もっと優しい Web を実現するための基本的な考え方を説明します．

第1章セマンティックWebとは何か

この本を手に取られる方々ならば，普段からWebを使われていることと思います．

Webによって，様々な知識・情報が即座に手に入るようになりました．また，Webを

通じて様々な物品やサービスを購入・予約することもできます．しかし，こうだった

らもっと使いやすくなるのに，と思ったことはないでしょうか．古い情報に当たって

しまって間違った知識を得ていたり，検索語の表記を少し間違えたために探す情報に

辿り着けなかったりしたことはないでしょうか．第 1章では，Webをもっと賢くする

ためにはどうすればよいかを考えていきます．

ここでは，現在のWebの問題点から出発し，データのWebを作り上げていくため

の基本的なアイディアについて説明します．

1.1 現在のWeb

「現在のWeb」の利用例として，旅行の計画を立てる場合を考えてみましょう．旅

行には，移動・観光・宿泊が伴いますので，それぞれの情報を複数のサイトから集め

てくる必要があります．たとえば，お祭りなどのイベントに合わせて旅行を計画しよ

うとすると，観光案内サイトからイベントの日程とアクセス情報を，ホテル案内サイ

トから宿泊先を，鉄道会社のサイトから時刻表を調べたりして，旅行計画を作成する

ことになります．

さらに，行くと決めたら，イベントのチケット，交通手段の予約，ホテルの予約を取

らないといけないのですが，これらは普通，別々のサイトで予約作業を行います．日

付や時間に間違いがないか，それぞれのサイトで注意を払いながら同じような情報を

繰り返し入力するのは，わりと骨が折れる作業です（図 1.1(a)）．

こんなとき，すべての情報を集約して見せてくれて，複数の選択肢を提示してくれ

て，さらに，予約もまとめてできるようなサービスがあれば魅力的だと思いませんか．

現在でも，宿泊と航空券をセットで販売してくれるサイトはありますが，そこで提示

される価格やサービスが最善のものとは限りません．また，提示して欲しい情報の組

み合わせは，個人の趣味や要求するサービスのレベルによって，様々なものが考えら

れるので，既存のサイトで提供されるワンストップサービス†では，必ずしも満足のい†飛行機・レンタカー・ホテルの予約が Web サイトから同時にできるようなサービスです．

2

1.2 データのWeb

図 1.1 文書のWeb からセマンティックWeb へ

く情報は得られないでしょう．

なぜ「現在のWeb」で統合されたサービスが提供できないかというと，それは「文

書のWeb」だからです．ここでは，Webというのは原義の「蜘蛛の糸のように複雑

に絡み合ってつながっているもの」という意味で使っています．ユーザは検索エンジ

ンや，サービス提供者のトップサイトからのリンクを辿って，目的の情報が書かれた

Webページに到着し，その情報を解釈します．その解釈は人間の高度な能力を使って

行われているわけです．人間の情報解釈作業と同レベルの能力をもつソフトウェアが

できれば，統合されたサービスが実現できるのですが，人間の言語理解能力を機械に

よって実現するのはなかなか難しいのです．ソフトウェアがWebページを読み取っ

て意味を理解するのは，それほど近い将来には実現されそうにありません．

そこで，必要になるものが機械可読なWebです．Webが機械可読なデータで構成

されていると，それらを統合してユーザの要求に応えるような，高度なサービスを実

現することができます（図 1.1(b)）．そのような技術の実現を目指したものがセマン

ティックWebとよばれるものです．セマンティックWebは，Webの標準を決める団

体であるW3C (World Wide Web Consortium)† を中心に，標準化作業や関連ツー

ルの開発が行われています．

1.2 データのWeb

「セマンティック (semantic)」とは，「意味に関する」という意味ですが，セマンティッ

クWebとは，「意味のWeb」というよりも，「データのWeb」であるという捉え方の

方がわかりやすいと思います．現在のWebが，文書を結合単位としているのに対し

て，セマンティックWebが目指すものは，データを結合単位とするWebであるとい

† http://www.w3.org/

3

第1章セマンティックWeb とは何か

うことです．

上述の「文書のWeb」の例では，イベント案内のページから目的地の最寄り駅を探

し，その駅名を経路探索サイトの入力欄にコピーして，自宅からの経路を知ることが

できます．すなわち，データを結びつける作業を人間が行っているわけです．

この作業は単純に見えて，じつは相当知的な作業です．たとえば，京都五山の送り

火「妙法」を鑑賞するには，京都市営地下鉄「松ヶ崎」駅が最寄りなのですが，「松ヶ

崎」という駅は京都府だけではなく，三重県にもあります．経路探索サイトが提示す

る複数の「松ヶ崎」駅の選択肢の中から，今探したい「松ヶ崎」駅を選ぶためには，目

的地が京都府にあることを知らなければなりません．

この「五山の送り火『妙法』の最寄り駅である松ヶ崎」と，経路探索サイトが選択肢

に挙げる「松ヶ崎（京都）」が同一のものであるということが，ソフトウェアにわかる

ように表現されていなければ，自動的にこれらのデータを結合することはできません．

1.2.1 データの同一性をどう表現するか

そこで，セマンティックWebでは，対象とするデータを表現するためにURI (Uniform

Resource Identifier) という考えを用います†1．URL (Uniform Resource Locator)

という単語はよくご存じだと思います．Webページのアドレスを示す

http://www.example.org/index.html

のようなものですね．この URL をWebブラウザのアドレス欄に入力すると，イン

ターネットに接続されている環境であれば，世界中のどこからでも同じWebページに

アクセスすることができます．

すなわち，Webページに関しては，世界中の人あるいはソフトウェアが，URLを

使って同じものを指しているわけです．セマンティックWebではこの考え方を，デー

タに対しても適用します．世の中の物事や様々な関係（これらをセマンティックWeb

では，リソースとよびます）を URIによって表現します．URIは URLと表記は似

ているのですが，Webブラウザのアドレス欄に URIを入力しても何かが表示される

ことが保証されているわけではありません†2．ただ，あるリソースをある URIで表記

し，この URIが同じであれば，同じリソースであるということにしましょう，という

取り決めがあるだけです．

†1さらに，URI で Unicode を使えるようにした IRI (Internationalized Resource Identifier) という仕様もあります．

†2 URI が概念を表す場合，その内容を記述した文書が表示される場合もあります．

4

1.2 データのWeb

たとえば，「京都府の松ヶ崎駅」というリソースを，以下の URIで表すとします†1．

http://ja.wikipedia.org/wiki/松ヶ崎駅_(京都府)

そうすると，この駅までの経路を探索することや，この駅の周辺のホテルを探すこ

とが，同名の駅の情報に惑わされずに，ソフトウェアでも可能になるわけです．

1.2.2 情報をどう表現するか

次に，セマンティックWebで，情報をどのように表現するかを考えます．

「文書のWeb」では，HTML (Hyper Text Markup Language)によって情報を表

現しています†2．本来，HTMLは，文書の構造と他の文書へのリンクを表記するため

のものだったのですが，様々に拡張され，現在では情報を表現する以外の部分（スク

リプトや表示のスタイル情報）が大半を占めるページの方が多くなり，肝心の情報は

大量の記述の中に埋もれてしまっています．

そこで，セマンティックWebでは考え方を大きく変えて，情報を「リソースとリ

ソースとの関係」または「リソースと値との関係」に割り切ることにしたのです．

これは，英語の Subject-Predicate-Object構文で情報を表現するという発想から来

ています．主語に当たる Subjectにはリソースが入ります．目的語に当たる Object

には，リソースまたは具体的な値（数字・文字列・真偽値などで，リテラルとよびま

す）が入ります．そして，SubjectとObjectの関係を表す Predicateもリソースで表

します．とくに，述語として用いられるリソースをプロパティとよびます．

たとえば，「五山の送り火・妙法」（http://ja.wikipedia.org/wiki/五山の送り火

#.E5.A6.99.E6.B3.95）の最寄り駅（http://www.example.org/sightseeing-ont#最

寄り駅†3）は，「松ヶ崎駅」（http://ja.wikipedia.org/wiki/松ヶ崎駅 (京都府)）であ

る，ということは，図 1.2のような 3個のリソースの組み合わせで表現します．これ

をトリプルとよびます．

図 1.2 情報の表現（リソースとリソースとの関係）

†1これは，ネット上の百科事典ウィキペディアでの「京都府の松ヶ崎駅」のURLです．URIには日本語の文字は使えませんので，実際は ASCII文字で，http://ja.wikipedia.org/wiki/%E6%9D%BE%E3%83%B6%E5

%B4%8E%E9%A7%85 %28%E4%BA%AC%E9%83%BD%E5%BA%9C%29 のように%エンコーディングという方式で表現されています．

†2 HTML については，第 10 章で詳しく説明します．†3このリソースは架空のものです．

5


これは，「リソースとリソースとの関係」の表現です．主語または述語となるリソー

スは楕円で表します．なお，図 1.2中では，リソースを表すURIは短く省略して標記

しています．

「リソースとリテラルとの関係」は，図 1.3のように表現します．

図 1.3 情報の表現（リソースとリテラルとの関係）

京都市営地下鉄の各駅には駅番号が振られています．駅番号自体は概念というより

は値ですので，リテラルで文字列として表現します．リテラルは四角形で表されます．

図 1.2中の「松ヶ崎駅 (京都府)」と図 1.3中の「松ヶ崎駅 (京都府)」は同じURIで

表現されていますので，このリソースは同一です．したがって，この二つの情報は，図

1.4のように結合することができます．

図 1.4 情報の結合

このような情報の表現形式を定めたものが，第 3章で説明するRDF (Resource De-

scription Framework)です．このようにして情報をつなげていくことによって，多く

の知識を関連づけることができます．

1.2.3 集中管理と AAAスローガン

さて，ここでいくつか疑問が出てきたと思います．松ヶ崎駅を URIで表現すると，

同一性が保持されて，いくつもの情報を自動的に統合することができることはわかり

ました．でも，誰が松ヶ崎駅を，

http://ja.wikipedia.org/wiki/松ヶ崎駅_(京都府)

6

1.2 データのWeb

という URIで表現すると決めるのでしょうか．

また，誰が「五山の送り火・妙法」の最寄り駅は「松ヶ崎」であるという情報を発

信するのでしょうか．

これには二つの代表的な考え方があります．

一つは，世の中のありとあらゆるリソースと情報を管理する機関を設置して，そこ

が決めればよい，とすることです．自分が使いたいリソースがどんな URIで表現され

ているか，それに関する情報はどのようなものがあるかは，そこに問い合わせればよ

いのです．これが「集中管理」の考え方です．

しかし，このやり方が破綻することは目に見えています．人数さえ投入すれば，世

の中の多くのリソースにURIを割り振ることができるかもしれませんが，必ず漏れる

ものは出てきますし，逆に，作業人数が増えれば増えるほど，URIの割り振りに一貫

性がなくなってきます．また，時々刻々更新されるあらゆる情報を，一箇所で管理す

るというのは非現実的です．

もう一つの対立する考え方は，「何でもあり」です．誰もが，何に対しても，何でもい

える．これをAAAスローガンとよびます．AAAとは，“Anyone can say Anything

about Any topic” の略です．振り返ってみれば，現在のWebの発展も，この考え方

によるものです．

セマンティックWebでも，当然 AAAスローガンを採用しています．そうでない

と，文書のWebが辿ってきたような発展を望むことはできません．

ただし，AAAスローガンにも問題はあります．まず最初に思いつくのが，1.2.1項

で説明した URIによるリソースの同一性の問題があります．これは，「URIが同じな

らば同じリソースと考えてよい」，ということなのですが，AAAスローガンのもとで

は，「URIが異なっているからといって別のリソースとは限らない」ということにな

ります．誰が，何に，どの URIを割り当ててもよいからです．

また，情報の分散の問題があります．お祭りやイベントの情報を発信するサイトに

も，主要駅からのアクセスは記載されているかもしれませんが，自宅から目的地までの

移動手段を探すとなると，乗り換え案内サイトを利用することになります．また，時

期による混雑具合などは，個人のブログが有力な情報源になることもあります．すな

わち，Webにおいては「情報が分散して存在すること」は大前提なのです．これらを

どのタイミングで，どのようにして統合した情報にするかということは，ソフトウェ

アで情報を集めるときには本質的な問題になります．

さらには，間違っている情報が存在し得ることも問題になります．単なる思い違い

から間違ったことを書いてあるページもあるでしょうし，時間の経過によって，過去

には正しかったことが現在では間違っているということもあります．「Aは Bである」

7


という記述と，「Aは Bではない」という記述が同時にあるときに，これを利用する

プログラムはいったいどうすればよいのでしょうか．

やや極端ないい方をすると，セマンティックWebに関連するあらゆる技術は，この

AAAスローガンのもとで，いかに知的な処理を行うかという問題に取り組んでいる，

ということになります．

1.3 セマンティックWebへの道筋

さて，ここまで説明したようなセマンティックWebを実現するために，どのような

技術が必要になるでしょうか．すべてを新しく発明するのではなく，既存のよい技術

（とくに，「現在のWeb」を支えている技術）はうまく取り入れて，よりスムーズな発

展を目指すべきです．

そのような考えのもと，セマンティックWebを説明するために，必要な技術を階層

状に積み上げた「レイヤーケーキ」とよばれる図が多用されてきました．

初期の「レイヤーケーキ」を，図 1.5に示します．

図 1.5 初期の「レイヤーケーキ」

当初，図 1.5はイメージを説明するために用いられたようですが，これが一人歩き

したことが，セマンティックWebの理解を妨げていたように感じます．

セマンティックWebの理解は，RDFの概念を中心に，これを機械可読に表現する

技術である下位の方向と，これを知的処理に利用する上位の方向に分けて理解するの

がよいと思います．しかし，初期の「レイヤーケーキ」では，RDFを表現する方法

は XMLしかないように見えますし，RDFと RDF Schemaという役割の違うものが

8

第3章 RDF—情報の表現法

RDF (Resource Description Framework)は，セマンティックWebの中心的な概

念です．情報を，主語・述語・目的語のトリプルで表現する方法の概念的な定義なの

で，Language（言語）ではなく Framework（枠組み）と称しています．

RDFに関する仕様は，表 3.1に示す七つの文書†1によって表現されていますが，多

くの解説では，仕様全体を簡潔にまとめた “RDF Primer”のみを参照しています†2．

表 3.1 RDF に関する仕様

文書名内容

RDF Primer 入門的なまとめ

RDF: Concepts and Abstract Syntax 概念と抽象構文

RDF/XML Syntax Specification XML による表記

RDF Semantics 意味論

RDF Vocabulary Description Language 1.0: RDF Schema RDFS

RDF Test Cases 実装のテストケース

rdf:PlainLiteral 国際化テキストの表現

RDFは，レイヤーケーキにおいては，図 3.1で示す場所に位置します．

図 3.1 レイヤーケーキにおける RDF の位置づけ

下側は，RDFを実現する技術です．もっとも重要なものは，リソースの同一性を表

†1 http://www.w3.org/2001/sw/Specs.html†2この中の RDF Vocabulary Description Language 1.0: RDF Schema は，第 7 章で説明する RDFS の仕様です．RDFS に関する説明は RDF Primer や RDF Semantics にも含まれています．

20

3.1 RDF の必然性

現する URI/IRIです．機械可読表現の形式としては，第 4章で説明する XMLを選

択することもできますし，本章で説明するような，特定の規則に従ったプレインテキ

ストとすることもできます．

上側は，RDFを利用して，推論や検索を行う技術です．以降の章で，順に説明して

いきます．

それではこれから，RDFの必然性から始めて，その仕様を説明していきましょう．

3.1 RDFの必然性

RDFは，AAAスローガンに基づいて，誰でも，どのような対象に対しても，何で

もいえるということを実現する必要があります．このことを実現するために，RDFで

は，主語・述語・目的語のトリプルで情報を表現する，ということを第 1章で説明しま

した．ここではなぜ，このような形式で「データのWeb」を実現しようとしたのか，

ということについて説明します．

3.1.1 分散データ表現の実現

ここで，AAAスローガンに基づいて「データのWeb」を実現するという問題をや

や単純化して，巨大なデータベースをいくつかのサイトに分散して保持するという問

題に置き換えて考えてみます．ただし，このデータベースはそれぞれのサイトで頻繁

に情報が追加されたり，更新されたりするものとします．これは，現在のデータベー

ス技術を用いて「データのWeb」に近いことを実現する方法なのですが，このような

状況では，どのような方法で各サイトでデータを保持するべきでしょうか．

データベースは，レコードとフィールドからなります．レコードは 1件ずつのデー

タで，フィールドはデータのもつ属性です．データベースを表で表現すると，レコー

ドは行，フィールドは列に当たります．

巨大データベースを分散する一つの方法は，サイトによって保持するレコードを分

けることです．レコード IDの 1番から 10番まではサイトA，11番から 35番までは

サイト Bというようなイメージです．図 3.2に，タウンページで表現されている情報

を分散して保持する状況のイメージを示します．

この方式では，各サイトで簡単にフィールドを追加したり変更したりすることがで

きません．たとえば，各データに緯度・経度の情報を付与しようとすると，すべての

サイトがその変更に従ってフィールドを追加しなければなりません．

それでは，フィールドで分散させる（図 3.3）というのはどうでしょうか．

この方式では，フィールドは各サイトが（フィールド名が衝突しない限り）勝手に

21


図 3.2 レコードで分散したデータベース

図 3.3 フィールドで分散したデータベース

追加できるのですが，今度は，レコード（新たな項目）の追加が困難になります．ある

サイトが新たにレコードを追加しようとすると，すべてのサイトに対してそのレコー

ドに関する情報を伝えなければなりません．

いずれの方法でも，AAAスローガンに基づくデータのWebの構築は困難です．そ

22


図 3.4 レコード・フィールドとも分散したデータベース

こで，すべてのサイトでレコードの情報，フィールドの情報，その値というトリプル

でデータを保持する方法が考えられます（図 3.4）．

個々のサイトがもつ情報は，たとえば表 3.2に示すような主語（レコードの情報），

述語（フィールドの情報），目的語（その値）のトリプルの集合として表現できます．

表 3.2 トリプルによる情報の表現

主語述語目的語

http://example.org/data#id 1 http://example.org/ex ont#名称 “和み処”

http://example.org/data#id 2 http://example.org/ex ont#名称 “極み”

この方法ならば，レコードの追加やフィールドの変更も，そのサイト内だけで済みま

す．典型的なデータベースのように，すべてのレコードのすべてのフィールドに値が

設定されていることは保証されませんが，そこは現在のWebと同様に，AAAスロー

ガンに基づくと，「ある人が必要とする情報は，他の誰かが提供してくれる」というこ

とが期待できます．

このばらばらに発信される情報をまとめ上げるために，すなわち，サイト間でのレ

コード・フィールドの同一性を保持するために，何をもって「同じもの」とするか，と

いうことに関する取り決めが必要になります．そこで，URIを用いてこれらに名前を

付けるという発想が生まれてきたのです．

23


URLは，世界中のWebページを区別する仕組みです．現在のWeb技術の上に「デー

タのWeb」を実現することを目指すのなら，この考え方に基づくのは当然でしょう．

ただし，URIはURLとは異なり，その指し示すもの（たとえばWebページ）が存在

することを保証してはいません．ただ，ある概念を他のものと区別するために付けら

れている名前と考えればよいでしょう．

この URI がリソースの正式な表記なのですが，毎回この長い URI を書いている

と大変です．そこで，省略記法として QName という方法があります．URI の#の

前までを別名で宣言し，その後ろにコロン (:)，さらにその後ろに URIの#より後ろ

の部分をつなげます．この URI の別名のことを，名前空間とよびます．たとえば，

〈http://example.org/data#〉を data，〈http://example.org/ex ont#〉を exとい

う名前空間でよぶと，表 3.2の RDFは，表 3.3のように表現できます†．

表 3.3 QName による RDF の表現

主語述語目的語

data:id 1 ex:名称 “和み処”

data:id 2 ex:名称 “極み”

このように情報が分散してしまうと，どのサイトでも重複しないように注意深く設

定された ID番号を付けて対象を管理するよりも，その対象をもっともよく表す URI

（たとえば，店のHPのURL）を用いてリソースとして対象を表現し，それらにRDF

で情報を付与する方が，より AAAスローガンに沿ったやり方になります．

3.1.2 より豊かな情報の表現

RDFの仕様のもっとも基本的な部分は，「情報は主語・述語・目的語のトリプルで

表現する」ということなのですが，これだけでは個々の情報がばらばらに蓄えられて

いるという状況しか実現できません．このRDFを基に，知的な処理ができるWebを

実現しようとすると，「リソースの集合に対する情報」や，「ある情報に関する情報」を

表現できることが必要です．

RDFでは，豊かな情報の表現のために，いくつかの語彙を定義しています．その語

彙を使った RDFによって，知的処理に利用できる情報を表現することができます．

クラスに関する情報を表現する

まず，RDFの語彙の中でもっとも頻繁に使われ，重要な役割を果たす rdf:typeに

†以後，ex はあるタスクにおいて設定した名前空間として，例の中で断りなしに用います．

24


ついて説明します†．

ここまでの説明では，RDFは個々の事例に関する情報を表現するように見えたか

もしれません．しかし，個々の事例すべてに情報を付与していては冗長な場合もあり

ます．

たとえば，特定の地区のレストランの情報を RDFで表現しているとします．そし

て，この地区は公共の場での禁煙が義務づけられているとします．個々のレストラン

について，それらが禁煙であることを RDFで表現するという方法もあるのですが，そ

の地区のレストラン全体を概念としてまとめて，その概念が禁煙であるという表現に

すれば，簡潔で済みます．このような，まとまりを表す概念をクラスとよびます．

このような場合，特定の事例「和み処」がレストランクラスに属している，という

ことを，rdf:typeを用いて，図 3.5のように表現します．

図 3.5 クラスと事例の表現の例

リソースをまとめて表現する

たとえば，レストランのメニューを RDFを用いて表現したい場合，その目的語は

集合になります．今，表現したい情報が，「和み処のメニューは，天ぷら，刺身，茶碗

蒸しである」というものであるとします．一つの表現方法として，「和み処」を主語，

「メニュー」を述語，「天ぷら」，「刺身」，「茶碗蒸し」をそれぞれ目的語とする三つの

RDFを作成するという手段が考えられます．しかし，この方法では集合として扱う

べきものなのか，複数の情報源からやって来て，たまたま主語・述語が同一だったも

のなのかが区別できません．さらに，集合といっても状況は様々で，順序に関係なく

要素が複数あるもの（例：飲食店のメニュー），順序が重要なもの（例：飲食店への道

順），複数あるうちから一つを選ぶもの（例：メニューの多言語での表記）があります．

そこで，表現したい情報を，「和み処のメニューはこの集合である」と「この集合は

順序なしの集合で，その要素は天ぷら，刺身，茶碗蒸しである」という情報に分けま

す．そして，「この集合」という中継役を，空白ノードという概念を使って表します．

空白ノードは情報の結合のみに用いますので，対応する URIをもちません．そうする

と，前者の情報は，「和み処」を主語，「メニュー」を述語，空白ノードを目的語とす

† RDFの規則を表す正式な URIは，〈http://www.w3.org/1999/02/22-rdf-syntax-ns#〉なのですが，これには標準的な名前空間として rdf が割り当てられています．

25

第10章HTML—文書のWebのための「ことば」

Webのための「ことば」というと，最初に思い浮かぶのがHTMLです．まず，HTML

がどのようなもので，その決まりはどのようにして決められたかについて見ていきま

しょう．

10.1 HTMLの必然性

10.1.1 歴史的な背景

当初，HTMLはWebの創始者ティム・バーナーズ・リー氏によって，世界規模の

文書の共有という目的で考案されました．もっとも本質的なものは，共有する文書の

構造を記述する機能と，他の文書へのハイパーリンクの機能でした．

当時はまだ XMLが考案される前でしたので，その前身の SGML (Standard Gen-

eralized Markup Language)という文書の電子化の規格に，ハイパーリンクの機能を

付け加えるというアイディアに基づきました．

SGML は軍艦や原子炉などに関連するような大量の文書データを電子化するため

の規格で，膨大な約束事からなるのですが，HTMLはそのうちのいくつかを参考に，

ネットワークを通じた簡単な文書共有に必要なものに絞り込んで設計されました．

10.1.2 電子的な文書のための「ことば」

電子的な文書は目に見えませんので，文書の保管場所やタイトルなどの書誌情報が

必要になります．保管場所はURLを用いて指定し，その他の書誌情報は，文書のヘッ

ダ部とよばれるところに記述すると定めました．

次に，文書構造に関する情報が必要です．通常，ある程度以上の長さの文章は章・

節・項に分けられ，見出しが付けられます．そして，本文は段落に分けられます．

また，Webのもっとも根源的なアイディアである，本文中の特定の部分に他の文書

へのリンクを設定する「ハイパーリンク」を実現する必要があります．

これらの基本機能に，文書表現を豊かにする図・表・箇条書きなどを埋め込む仕組

みが加えられました．ここまでの機能で，ハイパーリンクで相互に結合した電子文書

が実現できます．

しかしこれだけでは，ユーザはリンクを辿って文書を閲覧することしかできません．

112

10.1 HTML の必然性

文書をキーワードや著者で検索するには，その検索条件の情報を，文書が保管されて

いるサーバへ送る仕組みが必要になります．

この「ハイパーリンク機能をもった構造化電子文書」＋「クライアントからサーバ

に向かって情報を送信する仕組み」を実現したものが，現在の HTMLの中心部分で

あると考えるとよいでしょう（図 10.1）．

図 10.1 HTML の基本概念

10.1.3 「ことば」は混沌へ向かう

HTMLの基本的なルールに基づいてWebページを記述すると，Webブラウザはそ

の電子文書を「それなり」に表示してくれます．「それなり」というのは，具体的にど

のように表示するかは指定しなくても，見出しは大きめの文字で，箇条書きはインデ

ントを付けて，などということです．

この「それなり」に我慢できないのが人の常で，HTMLは見栄えを操作する要素を

いくつか取り入れてしまいました．font要素や center要素などです．また，本来，表

を記述するための table要素がレイアウト調整のために用いられるようにもなりまし

た．これらは OSやブラウザが異なると振る舞いが異なることが多く，ユーザのブラ

ウザが Internet ExplorerかNetscapeかを判定して，それぞれに向けたコードで見栄

えの操作を行うなど，構造ではなく見栄えのマークアップとよんでもよいような状況

も生じてきました．

113

第10章 HTML—文書のWeb のための「ことば」

一方，ユーザとのインタラクションを，より高度なものにする機能も付け加えられま

した．form要素を用いて入力したデータにエラーがあるかどうかをチェックして，エ

ラーが発見されるとダイアログボックスを表示してそれをユーザに知らせる，といっ

たような手順を記述したスクリプトが，HTMLに付加されるようになりました．ス

クリプトはユーザがブラウザに対して行ったアクションに応答して起動されるので，

HTMLのコード中にスクリプトとの連係情報を記述する必要があります．

こうしてHTMLは，情報の構造・見栄え・振る舞いのそれぞれの記述が入り混じっ

てしまい，まるでスパゲティ状態のプログラミング言語のようになってしまいました．

10.1.4 HTMLから XHTMLへ

その後，Webにおいてはアクセシビリティ向上の流れと，セマンティックWebへ

の流れが生じてきました．セマンティックWebへの流れは，第 1章で説明したとおり

です．もう一方のアクセシビリティ向上というのは，画面が小さい携帯端末でも必要

な情報が取得できるという意味から，さらに，音声のみでWebの情報が取得できるよ

うにということまで含まれます．これらに共通するのは，ソフトウェアがWebペー

ジから情報を取得しやすくする仕組みの実現です．

ところが，前節で見たように，Webページに情報の構造・見栄え・振る舞いの記述

が入り混じっていては，そこから情報を取得するプログラムを書くのは大変です．

そこで，HTMLを第 4章で説明したXML形式にしてしまうという案が出てきまし

た．これが XHTMLです．

HTMLをXML化すると，機械処理が容易になるという点以外に，様々なXMLの

利点が活用できます．

まず，情報の構造と見栄えの分離が容易になります．第 4章で学んだように，XML

はレイアウト情報をもたないので，XMLで記述された情報をわかりやすく表示する

には CSSを使う必要があります．また，振る舞いの記述対象が XMLになると，要素

へのアクセスは DOM (Document Object Model)を用いた定型的な処理が中心とな

り，スクリプトの可読性が向上することが期待できます．

また，XMLの拡張性も魅力の一つです．数式表示のためのXMLや，図形表示のた

めの XMLなどと組み合わせて，表現豊かなWebページにすることができます．ま

た，音声対話記述言語と組み合わせると，音声とGUIを用いたマルチモーダルインタ

ラクションが実現できます．

10.1.5 もう一つの流れ—HTML5へ

文書のWebという流れから見ると，HTMLの XML化は必然なのですが，一方で

114

10.2 XHTML の仕様

はまったく異なったWebの使い方も広まってきました．Webをアプリケーションプ

ログラムの配信源およびデータの保存庫とみなし，ユーザの手元のコンピュータはブ

ラウザだけが動けば，新しいアプリケーションプログラムのインストールが不要で，

なおかつ，作成したデータは会社でも，自宅でも，モバイル環境でも，いつでもアク

セスできるという考え方です．これがクラウドの基本的なアイディアです．

このような方向でWebを利用することを考える人たちにとっては，HTML4では

あまりにも機能不足です．極端ないい方をすると，HTMLをアプリケーション記述言

語にする方向で拡張を目指したものが，現在仕様策定中の HTML5です．

このように，現在のWebを支えている中心技術である HTMLが分裂した方向に進

むのは，誰にとっても望ましいものではありません．W3Cでは，XHTML2 のワーキ

ンググループ活動を 2009年に終了させていますので，今後は HTML5の流れに一本

化されていくものと思われます．

これでXHTMLが消えるかというとそうではなく，これまでに述べたXMLの利点

があることや，HTML5の仕様と矛盾するわけではないので，「XML構文に基づいた

HTML」という仕様は残っていくものと思われます．

以後，XHTMLと HTML5について，それぞれの仕様を解説していきます．

10.2 XHTMLの仕様

ここでは，XHTMLの仕様†のうち，基本的な要素について説明します．

10.2.1 全体構造とヘッダ情報

まず，XHTMLは XML文書ですので，XML文書宣言が必要になります．次に，

XHTMLでは，その文書がどのタイプであるかを宣言する DOCTYPE 宣言を冒頭に

置くことが義務になっています．厳密にXHTMLの仕様に基づくのなら，以下のよう

に宣言します．

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html

PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML1.0には，厳密に仕様に基づく Strictの他に，現状のHTMLの記述に近い

† http://www.w3.org/TR/xhtml1

115


Transitional（移行型），フレームを使用する Frameが指定できます．

文書全体は html要素で囲みます．ここでも決まった約束事として，XHTMLの名

前空間を宣言します．また，ページ内で使用する言語も，xml:lang属性を用いてここ

で宣言します．属性値は，日本語の場合は ja，英語は enです．

<html xmlns="http://www.w3.org/1999/xhtml"

xml:lang="ja">

文書の中身は，head要素と body要素からなります（図 10.2）．そのページに関す

る書誌情報は，head要素の子要素として書きます．title要素は，そのページのタイト

ルを書きます．meta要素は，ファイルの種類を表す content-type，著者，キーワー

ドなどのメタデータを記述します．また，link要素で CSSなどの外部ファイルとの関

連や，ナビゲーションリンク情報を書くことになっています．

図 10.2 head 要素と body 要素

10.2.2 文書構造

文書構造は body要素の内容として書きます．ただし，部・章・節のような入れ子

として構造を書くのではなく，見出しの大きさである h1要素～h6要素で構造を区別

116

10.2 XHTML の仕様

し，その中に p要素で段落を書いていきます．

このように，文書の構成を決める要素をブロック要素とよびます．一方，文書中のあ

る単語に対してハイパーリンクを設定する a要素のように，文書の構造とは関係なく，

特定の文字・文字列に何らかの機能をもたせる要素を，インライン要素とよびます．

ブロックレベル要素の例としては，見出しを設定する h1要素～h6要素，段落を設

定する p要素などが代表的なものです．

その他，文書の構造を規定するものとして，以下のようなものが定義されています．

•箇条書き順序付き (1,2,3, …)で箇条書きを行う ol要素，順序なし（見出しに黒丸や白丸を

使う）の ul要素があります．項目にはどちらも li要素を使います．•用語とその定義箇条書きの変形のようなもので，見出しが単語，内容がその意味となるものです．

dl要素 (definition list)を使って全体を囲み，見出しを dt要素 (definition term)，

説明を dd要素 (definition description)で囲みます．•表

table要素で表全体を囲みます．最初に，caption要素で表のタイトルを書きます．

表の各行は tr要素で定義します．通常，表の第 1行は見出しになるので，最初の

tr要素 (table row)の中に th要素 (table header cell)で見出しとなる内容を書

きます．通常のデータは，続く tr要素の中に td要素 (table data cell)で書くこ

とになっています．たとえば，1行に三つデータを書くときは，一つの tr要素中

に三つの td要素を書くことになります．•引用別ブロックを設定しての引用は，blockquote要素を用います（インラインでの引

用は q要素）．これによってインデントが付いて，本文と区別されます．

なお，画像に関しては，インライン要素である img要素を使い，src属性で画像の

URLを指定します．これはインライン要素なので，他のブロック要素（たとえば，p

要素）の中で使います．

10.2.3 ハイパーリンク

HTMLではインライン要素として，文書中に他のページへのリンクを埋め込むこと

ができます．リンクを設定したい文字列を a要素で囲み，その href属性でリンク先の

URLを指定します．

117


10.2.4 グループ化

グループ化要素は，テキストの特定の範囲を指定し，CSSを適用する範囲を設定す

る用途などに用います．div要素はブロック要素，span要素はインラインに用いるこ

とになっています．

ただし，これらの要素はとくにブロック化する意味が定められていないため，乱用

されて HTMLのコードを読みにくくする原因にもなっています．

10.2.5 文書構造の確認

例題 10-1 XHTML1.0の仕様書 (http://www.w3.org/TR/xhtml1)のソースを見

て，その文書構造を確認せよ．

解答 XHTML1.0の仕様書をブラウザで表示させ，ブラウザのメニューから「ソース

の表示」（Internet Explorerの場合）や「ページのソース」（Firefoxの場合）を実行して

XHTMLを表示します．

まず，冒頭部分を見て下さい．XML宣言，DOCTYPE宣言，html要素，head要素

の記述を見ることができます．

次に，body要素の先頭部分（リスト 10.1）を見て下さい．実際にブラウザに表示され

る内容と見比べると，このページの見出しに当たる内容が書かれていることがわかります．

リスト 10.1 XHTML 仕様書本体の先頭部分

<h1><a name="title" id="title"></a>

XHTML™ 1.0 The Extensible HyperText Markup Language

(Second Edition)

</h1>

<h2><a name="title2" id="title2"></a>

A Reformulation of HTML 4 in XML 1.0

</h2>

<h2><a name="subtitle" id="subtitle"></a>

W3C Recommendation 26 January 2000, revised 1 August 2002

</h2>

じつは，この h1, h2要素の使い方はあまりいいものではありません．本来は div要素

で囲って，文書冒頭のタイトルとしての表示方法を CSSで指定すべきです†．

次に，この仕様書のバージョン等に関する説明が，定義リストを使って記述されていま

† HTML5 では，このような目的のために，見出しをまとめる hgroup 要素があります．

118

索引

英数先頭

AAA スローガン 7, 21

ABNF 137

canvas 164, 172

CSS 42

DOM 114

DTD 40

EMMA 17, 153

EmotionML 155

Galaxy アーキテクチャ 148

GRDDL 53, 57

GUI 11

HTML 16, 112

HTML5 115

InkML 17, 175

IVR 132

Jena 34

MIME タイプ 45

MMI アーキテクチャ 150

MVC モデル 148, 149

N3 フォーマット 30

OWL 10, 100

OWL DL 102

OWL Full 102

OWL Lite 102

PLS 17, 141

QName 41

RDF 6, 20

RDFa 53

rdf:Alt 26

rdf:Bag 26

rdf:first 27

rdf:List 27

rdf:nil 27

rdf:object 28

rdf:PlainLiteral 29

rdf:predicate 28

rdf:Property 31

rdf:rest 27

RDFS 10, 78

rdf:Seq 26

rdf:Statement 28

rdf:subject 28

rdf:type 24

rdf:value 29

RDF/XML 50

rdf:XMLLiteral 29

RELAX NG 40, 47

RIF 10, 91

RIF Basic Logic Dialect 92

RIF Core Dialect 92

RIF Production Rule Dialect 92

SCXML 18, 156

SGML 112

SISR 17, 129, 139

SMIL 17, 177, 179

SPARQL 10

SRGS 17, 129, 137

SSML 17, 130, 142

SVG 17, 164, 165

SVG Tiny 166

TTS 142

UML 156

URI 4, 23

URL 4

VoiceXML 17, 128

W3C 3

WSDL 70

XHTML 114

XML 9, 37

XML Schema 29, 37, 40, 47

XML 処理命令 45

XML 宣言 45

XPath 62

197

索引

XSL 60

XSLT 43, 60

あ行

アーキテクチャ 14

アクセシビリティ 11, 114

アプリケーションルートドキュメント 134

一階述語論理 92

インタラクションマネージャ 15, 151

後ろ向き推論 96

演繹的推論 81

オントロジー 100

か行

開世界仮説 78

概念 101

確定節 95, 97

関数的 106

記述論理 101

逆関数的 106

空白ノード 25

クラス 25

グラフィカルオブジェクト 165

グラフ構造 12

限定量化子 101

項 93

構成的意味論 139

個体変数 92

混合主導型 133

さ行

三段論法 80

システム主導型 132

終端記号 137

述語記号 92

スキーマ言語 40, 78

セマンティックWeb 3

属性 46

素論理式 93

た行

ダブリン・コア 64

短期記憶 96

単調性 95

長期記憶 96

データコンポーネント 151

トリプル 5

な行

名前空間 24, 41

は行

ハイパーリンク 112

非終端記号 137

ビューボックス 167

ビューポート 166

プロダクションシステム 95

プロパティ 5

プロファイル 55

文書型定義 45

閉世界仮説 78

ま行

マイクロフォーマット 53

前向き推論 96

マルチモーダルインタラクション 14, 147

命題演算子 81

命題記号 81

命題論理 81

命題論理式 81

メディアオブジェクト 180

モダリティコンポーネント 15, 152

や行

有限状態オートマトン 156

ユーザ主導型 133

ユニバーサルアクセス 128

要素 45

ら行

ライフサイクルイベント 151, 153

ランタイムフレームワーク 150

リテラル 5

ロール 101

論理結合子 101

論理式 93

198

著者略歴荒木雅弘（あらき・まさひろ）

1993 年京都大学大学院工学研究科情報工学専攻博士後期課程研究指導認定退学

同年京都大学工学部助手1997 年京都大学総合情報メディアセンター講師1998 年博士号（工学）取得（京都大学）1999 年京都工芸繊維大学工芸学部助教授2007 年京都工芸繊維大学大学院工芸科学研究科准教授

現在に至る

フリーソフトで学ぶセマンティックWebとインタラクション C© 荒木雅弘 2010

2010 年 12月 1日第 1版第 1刷発行【本書の無断転載を禁ず】

著者荒木雅弘発行者森北博巳発行所森北出版株式会社

東京都千代田区富士見 1–4–11（〒102–0071）電話 03–3265–8341／ FAX 03–3264–8709

http://www.morikita.co.jp/

日本書籍出版協会・自然科学書協会・工学書協会会員＜（社）出版者著作権管理機構委託出版物＞

落丁・乱丁本はお取替えいたします　

印刷/モリモト印刷・製本/ブックアート組版/ウルス

Printed in Japan／ISBN978–4–627–84901–3

「フリーソフトで学ぶ - 森北出版 ·...

Documents

Transcript of 「フリーソフトで学ぶ - 森北出版 ·...