本文

　ISM研究会の皆さん，今井です。つーか，あっし，これからレジュメを書か
なきゃならず，こんなことしている場合じゃないんですが……。

　今後，会員の業績を公開するサービスを始めようと思い，その手始めとして
あっしのへなちょこ書評を試験的に公開しているわけですが，ちょこっとレイ
アウトとかを変えてみました。序でに言うと，場所も変えてみました。──
http://www.ism-society.org/works/imai_yusi/br_001/br_001.htm

　文書の内容は12月30日版と殆ど変わっていないのですが，文書の“見栄え”
がチョコチョコッと変わっています。どうかご笑覧くださいませ。もし“全然
読めなかった”とか，“文字が化けちゃった”という方がいらっしゃれば，ど
うかご報告ください。

          **************************************************

**********************注意！**********************
* この投稿の以下の部分は，コンピュータについての *
* 技術的な話題がでてきます。                     *
**************************************************

　上で「文書の内容は12月30日版と殆ど変わっていない」と申し上げました
が，ソースレベルでは根本的に変わっています。HTMLソースを読むことがで
きる方は，ご覧ください。

1. XML化（XHTML化）してみました。

　識者とか業界通とか名乗るヤクザ者どもが言っているとおり，これからのデ
ータ交換を考えると，Webドキュメントの中でXMLドキュメントが占める割合は
高くなっていくでしょう。

　てなわけで，ISM研究会会員の学術ドキュメント用の構造化された文書モデ
ルを作ってみました。

　既に文書モデルが出来上がっている以上，メタ記述そのものは，──DTDで
あろうとRELAXであろうと──，大したことではありません。もちろん，後々
に，スキーマに反した文書が出てくるでしょうが，その場合にはその場合で，
スキーマを変えるなり，文書を変えるなり，柔軟に，いいかげんに対応すれば
いいだけの話です。

　問題は寧ろXSLTの方にあります。現行のWebドキュメントの主流がHTMLドキ
ュメントであることを考慮に入れると，当然にHTML化してユーザにとって閲覧
可能なものにしなければなりません。ところが，柔軟で複雑なアカデミックド
キュメントについて，XSLTによるHTML変換を一から組み上げるのは面倒です。
（商品在庫表とか，そういうのなら楽なんですが……）。

　てなわけで，HTMLモデルで定義されている文書構造をそのまま流用すること
ができるXHTMLが便利です。また，XMLに関する技術は，毎日のように変更され
るので，あまり先進的なリコメンデーションに食いついても，バカを見るだけ
です。てなわけで，差し当たっては，XMLのお手軽バージョンであるXHTML形式
でのドキュメント公開を考慮に入れることにします。

　何がお手軽かって，XLSTを一から作らないでもいいのがお手軽なのであっ
て，お手軽とは言っても，XHTML文書はれっきとしたXML文書なのですから，あ
りとあらゆるXMLのメリットを享受することができます。

　もちろん，れっきとしたXMLドキュメントである以上，XHTMLでもネームスペ
ースを使えば，スキーマを独自に定義し（あるいは他人が書いたスキーマを利
用し），要素を拡張することは簡単です。実際にまた，数式なんかは，ネーム
スペースを指定してMathMLで書くしかないでしょう。

　但し，HTMLの定義済み要素だけでは，アカデミックなドキュメントの構造を
表現するのには，あまりに貧弱です。そこで，XHTMLでドキュメントを記述す
る際に，前述の文書モデルに基づいて，HTMLのdiv要素およびspan要素のclass
属性およびid属性で，ドキュメントの構造を明示しておきました。繰り返しに
なりますが，XHTMLドキュメントはれっきとしたXMLドキュメントなので，こう
すれば，例えば参照文献だけ，あるいは，例えば注だけを抜き出すなんてこと
もお茶の子さいさいです（ツールとスキルさえあれば）。また，後々に，独自
のスキーマを作成する際にも，エディタで一発変換することができます（例え
ば，XHTMLドキュメントでのclass属性を，独自DTDで定義された要素名に，ま
た，XHTMLドキュメントでのid属性を，独自DTDで定義された要素の属性名に変
換する，など）。

2.メタ情報としてDublin Coreメタデータエレメントに対応しました

　先ず，Dublin Coreについてご存じない方は，以下のページをご覧くださ
い。──
http://purl.org/dc/documents/rec-dces-19990702.htm
また，図書館情報大学の杉本さんによる，日本での事例紹介──
http://www.dl.ulis.ac.jp/DLjournal/No_14/1-sugimoto/1-sugimoto.html
もご覧ください。

　メタ情報としてDublin Coreの記述もやっておきましたが，和英混合のメタ
情報の定義の仕方にはまだ標準がないようです。杉本さんの事例紹介に安易に
従って，後々メンテが必要になるってのも，嫌です。

　そこで，ドキュメント内と外部RDFファイルとの両方に，DCメタデータの記
述を行っておきました（スッゲー間抜けです……）。外部RDFファイルのURL
は，──
http://www.ism-society.org/works/imai_yusi/br_001/br_001.rdf
です。ドキュメント内のメタデータの記述と外部RDFファイルのメタデータの
記述とを比べてみれば，あっしの苦労がしのばれることでしょう。

　あ，RDFはXSLTなしのXMLドキュメントなので，ブラウザでは，IE5.0以上，
ネスケ6.0以上でないと見れないかもしれません。

　以上の措置がどういうことなのか，説明しておきます。──和英（あるいは
他の言語）のメタ情報を定義するには，結局のところ，シンプルなDCではな
く，構造化されたDCが必要になります。けれども，構造化の標準自体がまだ決
定的ではありません。

　そこで第一に，XHTMLファイル内のメタ情報としてlang属性を指定し，同じ
エレメントを二回，定義して，片方は日本語でメタデータを指定し，もう片方
は英語（あるいは他の言語）でメタデータを指定しておきます。こうすれば，
取り敢えず，日本語（あるいは他の言語）のメタ情報と英語（あるいは他の言
語）のメタ情報とを分けることができますが，今度は両者の関連が不明確にな
ります。例えば，英語のキーワード（DCではsubject）の一番目と日本語のキ
ーワード（DCではsubject）の一番目とが同じものを意味している保証はどこ
にもありません。こうして，構造化が必要になります。

　そこで第二に，メタデータの構造化のやり方として将来，主流になると予想
されているのはRDFですから，外部XMLファイルとしてRDFファイルを作成し，
リンク要素として参照します。ところが，構造化の標準がない以上，このRDF
ドキュメントは，シンプルなDCとして記述されるしかありません。そこで，エ
ンコード形式をutf-8にして，日本語のメタデータと英語（あるいは他の言
語）のメタデータとを，同じ一つの要素として取り扱い，併記することになり
ます。これでは，日本語のメタデータと英語のメタデータとの関連を記述する
どころか，却って，日本語のメタデータと英語のメタデータとの区別を記述す
ることさえできません。ですが，RDFを使っていれば，将来的にDC構造化
の標準が出来上がった際に，その時点で，容易に構造化されたメタデータに移
行することができます。はぁ……

3.ユニコード化（具体的にはutf-8でエンコード）しておきました。

　ユニ“コード”と言われているキャラクタセットは，阿呆が作った阿呆なキ
ャラクタセットですが，これからの多言語表示環境では主流になるでしょう。
阿呆に逆らっても仕方がありません。

　ユニコードのいい点の一つは，対応したソフトさえあれば，日本語文書に含
まれているドイツ語文字なんかを一発で検索することができるということにあ
ります。「対応したソフトさえあれば」と申しましたが，例えば，Word 2000
なんかで十分です。Word 2000では，utf-8のユニコード文書もきれいに読み込
めます。

　けれども，HTMLを書く側としては，結構大変です。Windows上で動く，なか
なかいいutf-8対応エディタがないので困っています。現在のところ，秀丸と
Em Editorを使っていますが，秀丸のutf-8対応は不完全であり，また，Em 
Editorは──utf-8に完全に対応していますが──MSのVC++がないとマクロを
作ることができないようです。金払ってから気付きました。あっしはバカです
（笑）。Delphiにも対応していただかないことには，あっしには使い物になり
ません。どなたかいいutf-8対応エディタをご存じないでしょうか（秀丸並
み，あるいはVZなみのマクロが作れれば文句はありません）。

　てなわけで，utf-8でエンコードされたというのに，今のところ，非ASCIIの
ANSIキャラクタなんかは，実体参照しています。間抜けです。大間抜けです。
これじゃ前述の検索の容易性なんてどこかに吹っ飛んじゃいます。まぁ，どう
せWord 2000とかに読み込めば，実体参照も内部でユニコードに変換されて，
検索することができるようになるのですが……。

　ですが，ひょっとすると，このクソ間抜けにもいいとこがあるかもしれませ
ん。どうもネスケでは，クオテーションマークなんかは，Shift-JISで実体参
照しても表示されません（“[ism-topics.342] My Book Review [PS]”，
2000年12月27日 04:47，参照）。けれども，utf-8で直接指定すると表示され
るようです。それならば，utf-8で実体参照しても，表示されるような気
が……。いつもいつも済みませんが，確認お願いします>>窪西君。