コンテンツの構造化とは何か? 構造化の目的、手段は? Word文書のスタイル付けとマークアップの関係

自由奔放に記述された文書は構造化文書とは言わない。そうではなく、予め定めた一定の型にはめて記述した文書が構造化文書である。ここでは構造化文書とはなにか? 構造化の目的、構造化の手段について簡単に整理してみる。

1.構造とはなにか?

例えば、書籍は、表紙、前書き、目次、本文、後書き、奥付という大枠の構造を持つ。本文はさらに大見出し、中見出し、小見出しを必要に応じて繰り返すという構造をもつ。さらに本文の文章の中には、箇条書き、引用、表をもつという階層構造になっている。また、章や節、図表には番号をつける。注釈、参考文献は、参照元と参照先への対応関係をもつ。

これらはすべて書籍に関わる構造である。こうした構造は文脈・意味と強い関係をもつ。一般には、文脈を明らかにし、意味を捉えやすくするように構造化する。

2.印刷における構造の表現

印刷した書籍においては、表紙、前書き、目次、本文、後書き、奥付はそれぞれの体裁で表現される。見出し、段落の位置(上下・左右の余白の量など)や箇条書き、文字の修飾(強調、斜体、ゴシック体、文字の大きさ)などは文章の文脈や意味が明確になるような書式になる。たとえば、見出しの文字を本文よりも大きくしたり、前後に空き(行間)を広くとるのは見出しであることを分かりやすく示すためであるし、ある特定の段落の左余白を広く取った場合、それは、引用や注記など本文とは異なる段落であることを示すためなのである。注釈であれば、参照元には合印をつけ、参照先に注釈のテキストにも同じ印をつけて参照関係を表す。

3.意味の認識

人間が書籍を捲り、テキストを読む目的は意味を認識することである。テキストを読みながら、構造の認識の支援を得て、テキストの意味を、より容易に、正しく認識できるのである。

4.文書のコンピュータ処理と構造の表現

プログラムによるコンピュータ処理では文書の構造を取り扱うことが多い。構造の取り扱いの主な例は、構造の変換と可視化である。構造変換の例としては、オーサリング形式から配布用の形式への変換がある。オーサリング形式とは編集作業に最適化された形式である。例えばDITA(Darwin Informaton Typing Archtecture)はオーサリング形式である。配布形式とは読者の手元で可視化するのに向いた形式である。可視化には、スクリーンへの表示、紙への印刷、音声で読み上げなどを含む。現在の2大可視化ツールはPDFリーダとブラウザである。DITAでコンテンツを作成したとき、最後に配布形式であるPDFやHTMLなどに変換する。DITAではこれをパブリッシングという。

このようなコンピュータ処理では構造が必須である。しかし、コンピュータでは人間のようにテキストを読みながら構造を認識することができない。そこで、テキストの中に明示的に構造を表す印をつける必要がある。これがマークアップである。

5.XMLマークアップ方式

現代のマークアップ方式の代表はXMLである。XML方式では構造を要素や属性というマークアップで明示的にあらわす。

例えば、見出しは、人間にとっては本文と比べて大きな文字であることをキーにして認識する。一方、XMLでは見出しの範囲をマークアップすることで明示的にあらわす。見出しというマークアップした場合、文字が大きいこと・文字がゴシックであることなどの見出しを視覚的に区別するスタイル指定はマークアップの方で担う。見出しの文字列は、本文と同じテキストで表す。

そこで、マークアップをすることは狭義のコンテンツである見出し文字列と見出しに指定するレイアウトという視覚要因を分離することであるといっても良い。このような意味で、コンテンツとレイアウトを分離するという言い方をすることもできるだろう。

XML方式で文書をマークアップすることで文書をコンピュータで簡単に加工処理できるようになる。XMLを使うメリットは、さまざまな基盤ツールが提供されていることである。先ほどのDITAの場合は、DITA-OTというパブリッシング用のツールがオープンソースとして提供されている。こうした基盤ツールを自分で作らなくても済むというメリットは大きい。

6.XMLの作成

XMLでマークアップするのは、あくまでもコンピュータ処理のためである。つまりXMLにしても、人間にとってはうれしくない。こうしたことからXMLは一般の人には無縁である。このため専門家以外にはあまり好かれないのだが、これはやむを得ないだろう。

しかし、文書をXML化することで、メリットが生まれる場合もあり、あるいはXML化しないとどうしようもない場合がある。どういう場合にメリットがあるかを考えてXML導入しないと無駄になる。また、XML化のコストはかなり大きい。そこで、これをどうやって簡易的に実現するかを考えることも必要である。

7.Microsoft Wordのスタイルを使う方法

Microsoft Wordにはスタイル機能がある。見出しというスタイルを定義しておき、ある文字列に見出しスタイルを適用すると、その適用された文字列の文字がいっせいに大きなゴシック体になる、というものである。

こうしてみるとMicrosoft Wordのスタイル機能は、XMLにおけるマークアップに近い機能であることが分かる。このようなことでスタイル機能を使って記述したMicrosoft WordはXMLで構造化した文書に比較的容易に変換することができる。

一方、同じMicrosoft Wordを使って、スタイル機能を使わずに、見出し文字列をその都度、文字修飾(フォント機能)と段落修飾(インデント、改行幅)をつかって外見を指定して作成した文書を作ることができる。このような作りかたをした文書はXMLに変換しにくい。XML化するときに、すべての見出しをいっせいに特定のマークアップに変換しにくいのである。それは、ときどき、修飾を忘れるなどの例外があるからである。

CAS-UBのWord変換は、スタイル機能を推奨している。Wordが標準でサポートしている機能であり、スタイル付けは比較的簡単だからである。

しかし、Microsoft Wordで作成した文書をXML化する方法として、Wordのスタイル機能を使う以外にもまだ他に方法がある。例えば、大見出しにするテキストには、特定の色を付けるなどが考えられるだろう。これをCAS-UBのWord変換で実現している事例もある。

コンテンツ構造化の視点―大域構造化と局所構造化(メモ)

コンテンツの構造化にはいくつかの視点がある。ひとつは、大域か局所かというレベルである。

大域構造化とは、書籍で言えば記事を目次のレベルで分類したようなものである。すなわち、書籍は、前付け、目次、本文、後付といった大きな枠組み構造をもち、その下に、たとえば本文であれば、章、節、項という枠組み構造があり、全体としては木構造になる。

章、節、項という構造とは別に、柱、ページ番号(ノンブル)、脚注と言う構造がある。これは、本文の流れと関係するが、主にコンテンツにアクセスするための構造である。柱、ページ番号や脚注は可視化するときに内容と場所が決まるものである。分かりやすい例として柱をあげると、書籍の頁に片柱で章の表題を付けるとすると、その表題が現れる回数や場所は判型や版面によって異なることになる。

索引なども表示に依存する構造である。索引語を整理して配置して、索引から本文への参照をつける。印刷した書籍ではページ番号、Webや電子書籍ではリンクによる参照になる。電子書籍では検索があるので、索引は要らないのではないかというかもしれないが、全文検索ではヒットする箇所が多すぎて、情報を探すのに却って時間がかかるケースが少なくない。情報にアクセスするための構造としての索引は重要である。

局所構造化とは、テキストの中のセマンティックスに沿うものである。具体的な例は、先日紹介した「DITAの実践」の説明がある。節や段落よりも小さな断片情報を構造化することで検索・変換・表示などの便宜を図るものである(下記の「セマンティックスの役目とは」を参照)。

構造化における大域構造化と局所構造化の一つの例はDITAにおけるTopicとMapである。これはまさに大域構造化と局所構造化の使いわけであると考えている。実際のところMapの中にもかなり細かい指定があるのでそう簡単ではないのだが。

但し、大域構造化と局所構造化の概念は述べている人は少ない、というかこれは私の造語に近くあまり市民権はないし、まだ論理構成がずさんであるが、分かりやすいと思う。今後、もっと精密化したいと考えている。

◎過去の関連ブログ記事
1.セマンティックスの役目とは
12月11日CAS-UBブログ
2.コンテンツの構造化とは何か?Word文書のスタイル付けとマークアップ
http://d.hatena.ne.jp/cassupport/20110906/1315262225

セマンティックスの役目とは

以下の話は、CAS-UBとは直接は関係ないのですが、「DITAの実践(第2版)」を読んでいましたら、「セマンティックスの役目」という節(3.8節、pp.30~35)に次のような言葉が出ていました。

1.セマンティックスは意味的に適切な要素でカプセル化して情報をすばやく見つけることができるようにする。
2.コンテンツの表現よりも、情報に正しくセマンティックスを追加することで情報提示に一貫性を持たせる。
3.意味的な要素とは、「である」というコンテキストを提供するメタデータである。
4.節や段落よりも小さな断片情報にクエリを通じてアクセスできる。
5.「ボールド」、「イタリック」のような表示方法を変更するマークアップは、翻訳などで問題が生じる。
6.XSLTを用いて、表示を組織的に統一できる。変更も容易になる。

以下にセマンテッィクス要素の例示があります。

・apiname
・cite
・cmdname
・codeblock
・codepath
・filepath
・lines(歌詞や詩など、行が意味を持つ)
・lq
・menucascade
・msgblock
・msgpath
・option
・parname
・screen
・state(状態)
・synph(コマンドや構文の一部)
・systemoutput
・term
・uicontrol
・varname
・wintitle

ここでいうセマンテッィスはかなり局所的で、マニュアルの中で使うものが多いようですが、参考になる考え方です。

○出典「DITAの実践(第2版)」(Julio Vazquez著、DITAコンソーシアムジャパン訳、エスアイビー・アクセス発行、2011年11月、ISBN978-4-434-15881-0)

EPUBのネイティブコンテンツと生成コンテンツ

11月27日に「JBasic08を一読。JBasicのテンプレートは不要ではないでしょうか。」(11月27日記事へのリンク)で書いたことと一部重複しますが、もう一度、別の観点から論点を整理してみます。

EPUBコンテンツのオーサリングを効率的に行なうためには、プログラムで生成できるコンテンツと人手で入力するコンテンツを予め分離しておき、プログラムで作り出すことのできるコンテンツはプログラムで生成して付け加えるという方法が有効と考えられます。

一般の書籍を想定して、著者や編集者などが入力するコンテンツをネイティブ・コンテンツと呼び、プログラムで作るコンテンツを生成コンテンツ(generated contents)と呼ぶことにします。

例えばJBasicが対象としているような書籍の中では、次の項目を生成コンテンツとすることができると思います。

1.目次
2.表一覧
3.図版一覧
4.索引
5.章番号
6.節番号
7.図番号
8.表番号
9.注の合印
10.注番号
11.後注一覧
12.番号箇条の項目番号
13.箇条書きの項目ラベル(記号)
14.ヘッダーの内容
15.フッターの内容

このほかにもあるかもしれないですし、どれを自動生成し、どれを手入力とするかは原稿やユーザの好みにも依存します。しかし、一般的には、できるだけ多くの生成コンテンツをプログラムで生成することで制作者の負担を減らすことができるはずです。そして、こういった自動化ができることがXMLによる構造化マークアップを使うメリットといえます。

そこで問題は生成コンテンツをどのタイミングで生成するかということです。大きな分類としては、配布形式であるEPUBに生成結果を含めるのか、それとも生成結果を含めずにEPUBを表示するリーディング・システムに生成をゆだねるかということがあります。

例えば、箇条書きの項目番号や箇条書きの項目ラベルは、Webの場合は、CSSで形式を指定しておき、ブラウザで生成することが一般的と思います。

しかし、書籍の場合はそうはいかないことがあります。例えば、極端な例として、番号箇条の項目を後続段落から参照して、「一項の。。。」などというときは、項目番号:”一”は確定している必要があります。そうでないと、リーディング・システムによっては、”一”とならずに”1”となるかもしれず、そうなると箇条書きブロック中の項目番号とそれを参照している箇所の番号が異なってしまうからです。図表の番号や章番号なども同じことが言えます。

こうしてみますと、一般論として、配布形式としてのEPUBについては生成コンテンツはできるだけ配布時に確定させておくべきということが言えると思います。できるだけというのは微妙ですが、いままでの印刷出版では完全に確定していたのに対して、Webの世界では、箇条書きなどはブラウザ任せが普通に行なわれていたという違いがありますので、電子書籍ではどうしたら良いか、ということです。

一方、オーサリングシステムの内部では、できるだけネイティブ・コンテンツのみを編集するようにしておく方が生産性が高くなると予想します。つまり、目次、後注、索引などは手では編集しないで、生成コンテンツとする方が明らかに効率的だし、章番号、節番号、図・表番号も、文書のアウトラインを使ってプログラムで生成することで加除や順序入れ替えのときの付け直しの手間を無くすことができるので良いと思います。

ちなみに、ここで述べた、ネイティブ・コンテンツと生成コンテンツの分離と生成タイミングに関する考え方はCAS-UBによる書籍制作で基本的としている考え方です。

《広告》

JBasic08の大域構造化に関して、別のアイデアを提案

昨日、JBasic08についての問題提起の中で、「出版物の内容の区分とHTMLファイル化」のところで取り上げた問題をもう少し掘り下げてみます。

JBasic08では、EPUB3を構成するXHTML文書はすべてルートを同じくする兄弟でなければならないと想定しているようです。この想定は、次の記述と表裏一体をなしています。

「見出しを持たないbody 要素は、暗黙的に出版物の標題が見出しに指定されたものと見做し許容する。body 要素に見出しを明示的に指定する場合には、それは出版物の標題でなければならない。」(p.25)

そしてそこから、昨日取り上げたp.29の説明図にあるような大きな内容を分割するときは、section要素の終了タグと開始タグを補って分割するという考え方になります。

そういう意味では一貫性がありますが、果たしてこれが最適なのでしょうか?以下で、この問題を検討してみましょう。

分かりやすくするためにJBasic08のp.29のXHTMLファイルの分割を絵で表しますと次の図のようになります。

JBasicの分割方法

分割したファイルは、EPUB3にspineにこの順に登録することで閲読順序を指定します。この分割方法の問題は、第二節と第三節sectionの親であるsectionが第一節sectionの親sectionとは別になることです。このため第一節、第二節、第三節が兄弟ではなくなります。分割後の3つのXHTMLを結合しても元のひとつのXHTMLに戻りません。

こうなると、編集作業で、第一節と第二節の入れ替えを行なったり、XSLT(XSL Transformations)などでXMLのツリー構造変換するときに、ややこしくなると思います。

では、どうしたら良いでしょうか。一つの代替案は次の図のように分割することです。

XHTMLの分割・代替案

つまり、節のsectionを単位として切り離して、別のXHTMLファイルにしたうえでspineに登録します。spineに登録された3つのXTMLをもとの大きなXTHMLと同等にするために、レベルという考えを導入して章のsectionをレベル1、節のsectionをレベル2とします。

これによって、分割後のXHTMLを元のXHTMLに戻すことが簡単にできますので、節の順序入れ替えやXSLT処理もより簡単になると思います。