人工知能学会から会長名で会費の請求が来た。田中穂積さんが会長なんだ。ふーん・・・年会費は10,000円だが、年間6冊の「人工知能学会誌」はA4判100ページで、日本の人工知能の動向が掴めておもしろい。
日経産業新聞を読んでいたら、世界屈指の新技術発表会が開かれたという記事が出ていた。クールな企業ベスト10が選ばれていたが、自然言語処理技術を使うMeaningful Machinesと処理自動化関連のActiveWordsが気を引いたのでリンクを張っておこう。VMwareも選ばれていたね。
Web上の情報抽出について、本サイトではAWKING Projectをスクリプト言語の応用、パーソナル・コンピューティングという観点から提唱(^^;)している。今や、誰もが豊饒なWebの大海から望む知識や情報を得ることができるのだ。また、逆に発信することができる。Webが重要なのは、低コストで情報を発信することができるために様々な情報が公開され始め、知識の交換において相互恩恵的な関係が世界的に構築され始めているからである。しかもそれは大変便利であり、もうWeb無しでの生活は考えられないほどになっている。
スクリプト言語を使うと、関心のある指定のURLにアクセスして、HTMLから欲しい部分を取り出し、その結果をまとめてWebに送り出すということは簡単にできる。しかし、HTMLから必要な情報を取り出すためにHTMLのタグを使うと、表現方法が変えられた場合にはその度に抽出用スクリプトのマッチングを変更する必要がある。このメンテナンスは大変である。しかも対象とするサイトが多いほど大変になる。従ってこの方法は対象が少ない場合に使うべきである。RSSでニュース・フィードをしているサイトのみを対象にすれば簡単だが、対象が限定される。Webサービスも同様であろう。さて、どうすればよいだろう。
自然言語処理の分野においては、情報抽出、機械翻訳、テキスト要約、質問応答システム等の研究がなされており、昨日紹介したGateもその成果である。HTMLやXMLのようなタグを使うだけでなく、自然言語処理を援用する方法も考慮すべきというのが今後の方向性である。
知識表現という言葉はよく考えると、へんな言葉だ。自然言語によって知識を表現できる。なぜ、別に知識表現を考える必要があるか。やはり、XMLと同様にMachine readableを想定した言葉なのかな。AIを実現して人間の知的生活を支援させるために、人間がどのように知識を獲得するのか研究することは大変おもしろいことだろう。機械に知識を理解させるための言語としては、まさにプログラミング言語が該当する。プログラムを書くことは知識を表現することだと、以前から思っている。しかし、知識をプログラムに追加して、それによってプログラムの動作を変えたりというようなことを自動的に行なう例は少ないかもしれない。それに近い例としてはいろいろ考えられるだろうが・・・そういったプログラム構造を容易にするためには知識ベースと知識処理の部分を分離すること、知識ベースが狭い意味で知識表現になるのだろうが、知識を管理しやすく、且つ操作しやすいものになっている必要があるだろうというようなことを漠然と考えている。
自然言語処理の領域は調べれば調べるほど、新しい要素が見つかる。2,3年は勉強しないと理解することは難しいだろう。Webの歴史は新しいが、AI、自然言語処理、言語学の歴史は長い・・・流れとしてSemantic Webと自然言語処理は次第に融合していくはずである。
自然言語処理については当然日本語と他の言語には違いがある。言語特有の問題がある。日本語を処理する場合、形態素解析がまず必要になると思われる。単語に区分けしないと処理が進まない。このような問題を専門家はどう捉えているのか、教科書が欲しいとアマゾンを検索して選んだのが、田中穂積監修、「自然言語処理 -基礎と応用-」、電子情報通信学会、平成13年6月1日初版第二刷、352ページ、5400円。この本を読むと、"part of speech tagging"を「品詞タグ付け」と訳している。なあんだと思ったり・・・章立てをリストアップしておこう。
この文献は、Marin Dimitrovのソフィア大学情報数学部情報技術科(ブルガリア)の修士論文である。シェフィールドのカニンガムらが指導している。Gateを使って情報抽出をする試みである。[modified: 2003-2-3]
中野不二男、『メモの技術-パソコンで「知的生産」-』、新潮選書、1997年10月5日4刷、230ページ、1000円。もう何が書いてあったか忘れているが、いい本だったという記憶だけが残っている。記憶なんていい加減なものだ。京大型カード・パソコン版がメインの話題だが、電子手帳の話もおもしろい。システム手帳の代わりに使う。システム手帳ではデータの更新や紙の痛みへの対応など結構大変との見解。電子手帳では住所録とスケジュール管理が使えれば良い。シンプルで、入力はパソコンで行い、データを転送できるものという条件が必須。システム手帳はメモ専用になる。なるほど。パソコン側で何を使うかが問題。それでPDA側も決めることになるかな。Outlookは使っていないし・・・アナログ紙情報とデジタルの世界を如何にうまく相互に行き来するか、デジタルとアナログの両立、このことに言及した唯一の本かも。
地球シミュレータは前に日記で話題にしたが、たった今、NHK教育「ETVスペシャル」で紹介していた。ベクトル型プロセッサと並列計算を組み合わせた高速演算技術は日本で発達したものなのだそうだ。冬型の気圧配置での雲の動きや台風の生成と消滅などのシミュレーションを見ると現実と見間違えてしまう。いずれはこうした計算をデスクトップのPCで動かせる時代が来るのだろうか。まあ、しばらくは無理だろうね(^^;)
今日は気温が上がるので、雪が溶けるのを期待していたが、夕方になっても家の屋根からずり落ちて大量に蓄積したカーポートの屋根の雪は片持ちの支えの信頼性を揺るがせたままだ。今朝はカーポートの出口と車のドア周りに堆積した雪をまず取り除いた。太陽に照らされた屋根が雪解け水を滴らせるぐらいでは昼間の時間は短すぎる。場所を確保すると、脚立を持ち出して屋根の雪を少しずつ降ろした。撓んだ屋根が少しずつ持ち上がった。問題のなさそうなレベルまで取り除いて終了。やれやれ、腕がだるい。久しぶりの本格的運動。雪ネタはいつまで続く・・・
残雪(^^;)
コロンビアの悲劇的な空中分解の調査、イラク攻撃理由付けの動向、北朝鮮からの脱出の話などをテレビで眺めながら、ニュースだけには事欠かない世界だと思う。次から次へと事件が起こる。平和で穏やかな日々が世界に訪れるのは何時のことだろう。それに向かって我々は努力しているのだろうか。ただ無力感に囚われながら、テレビの向こう側の他人事のように感じている。
どうもうまくないこと。正月に買ったプリンタが正月明けに7800円で販売されたこと。紙の汚れが出ること。インクが長持ちしないこと。やはり、安物はダメかな(^^;)汚れについてはマニュアルを調べてみないと・・・インクが出すぎなのかも?
シャープの新しいLinux Zaurusを見たが、小さい。画面の高精細さは凄いが、使いやすいかということになると疑問な感じもする。これはSONYの小型のVAIOにも通じることだ。昨年通販で購入したIIYAMAのB5ノートの問題、筐体の滑り止めになるシリコンゴムの小さな足が接着剤で小さな窪みに貼り付けてあるのだが、これがはがれること。最近はだいぶ安定してきたかな。他には余り文句ない。が、残念ながら余り使わない。結局家ではデスクトップの前に座ってしまうし。会社のデータをLAN経由でコピーして家に持ち帰るぐらいしか、使い道がないんだな。ノートを膝の上に載せては意外に使いにくい。ノートは携帯デスクトップだよね。モバイルはやはりノートよりはPDA。ケータイの代わりに待ち時間に遊べるPDAには何がいいだろうね。
NHKの再放送、「未来への教室」、カルロス・ゴーンさんの「困難をチャンスに変えよう」を途中からだが感動をもって見た。カルロス・ゴーンと小学生との顔合わせで、困難に立ち向かう人生の知恵のようなものと子供達から世界の明るい希望を読み取ることができる良い番組だった。小学生の日本をもっと良くするためにはどうしたらよいかという質問に、一つあるとすれば「若い人と女性に権限を与えて、活用すること。」という言葉も興味深い。
眠くて目が閉じそうなので、車の窓を開けたまま帰ってきた。居眠り運転事故からはなんとか逃れることができた。朝は7時前に日の出になる。ライトを点けずに出発するようになった。西広島バイパスから降りるときに太陽を真正面から眺めることになるのだが、太陽の上がる位置が次第に北側に移っていく。季節も確実に移っていく。
一週間サイクルで天候が循環する。雨の中を帰ってきた。疲れた。来週の土曜日も出か(;_;)
プリンタはSWI-Prologのマニュアルを打ち出している。なぜか、エプソンのPM600Cが動いている。何、BJS330のインキが切れたままだから。シャープのマルチユースペーパーのせいか、紙送りも今のところトラブルなし。紙との相性もあるなあ。
にゃん、にゃん、にゃんで、2月22日が猫の日になったとさ。雨の中をカーラジオを聞きながら、遅い出勤。10時からの会議に間に合うように。午後4時半と早めに終わったので、さっさと帰宅した。猫がエンジンの上のボンネットにちょこんと座って暖を取るのを、隣家は嫌って、様々な工夫を凝らすがなかなか効果がない。猫の土の付いた足跡や引っかき傷が絶えないのだ。雨で濡れては猫も今日は寄り付かないだろう。
昼のお散歩は、快晴だが少し風の強い中を防波堤を歩いた。空気は透明で宮島や周囲の山々は鮮やかな色彩に彩られ、エメラルドグリーンの海は時折白い波を立てながら恵川の河口に満ちてきていた。花粉センサーの鼻の状態もそれほどひどい状態ではない。帰りはもう8時をだいぶ回っていた。空は曇っているようだ。星が見えない。うーむ、明日も出か。疲れてるけどね。明日はもう3月。
記憶の構造作成スクリプトをdmlに移植した。前の記事の階層リストはそれで出力している。dmlは次のように記述する。
|uls: |list1 | list1-1 | list1-1-1 | list1-2 |list2 | list2-1 |/uls:
階層型リストは、情報の階層を記述できるので、属性を見やすく表現できる。しかも、HTMLの中に論理的な構造を残すことができる。
FeedreaderをUpdateすると、Python Newsから興味深い記事が入ってきた。昨年の各主要スクリプト言語動向のまとめである。Lua以外はTS Networkで取り上げている主要なスクリプト言語である。Rubyも完全にグローバルな言語として定着した。ruby-talkの活性度は驚くべきものである。メールが着信すると大抵はruby-talkのものだ。今日もまだお昼にもならないのに50通届いている。一日中世界のどこかで途切れなく何かが起こっているという感じだ。PerlのコミュニティもRubyに注目している。TPJを読んでいてもRubyに関する記述は多いし、2月号の記事ではSimon CozensもRubyを使っていると書いていた。
この際だから、Luaへのリンクを書き残しておこう。
luaのハローワールドとシェル
偶々、言語比較ネタが重なるけど、Luaのリンクを追いかけていると、Win32上のコンピュータ言語のベンチマークテストを見つけた。スクリプト言語とコンパイル型言語と比較してスピードの優劣は明白だが、一昔前と比べるとスクリプト言語でテキスト処理をする場合には昔のように処理を待つということはほとんどなくなった。実用的にはスピードも十分になってきたのだ。キーワード別にテキストを100程度のファイルに切り分けるのもほとんど瞬時に終わる。これからはむしろ開発速度に重点が置かれるのではと思う。物によるのだろうが、コーディング量はCなどと比べて1/10で済む(例えば、カーニハンとパイクの「プログラミング作法」の118ページ)。以前、NIFTYのログからBecky!のメール保存形式でメールを切り出すスクリプトをメーリングリストに載せたら、「えっ、これで済むの」とプログラミングに詳しい人はびっくりしていた。Cで文字列の終端がNULL文字になると考えながらテキスト処理を書くのは無駄だと思うというか、正規表現によるパターンマッチングが使えるPerl等を知っていればそちらを使うのが自然である。RubyやParrotのデータも掲載されている。
昨日からSWI-Prologを調べている。もう10年ぐらい前にS-Prologを使って遊んでいた。しかし、MS-DOS(おーっ、懐かしい言葉だ。久しぶりに使うね)の640KBの制約の中ではすぐ壁にぶつかる。Perlなどがdjgppでメモリの束縛を打ち破ったので、Prologはお蔵入りに(^^;)自然言語処理やGate関連で知識表現にPrologを使っている文献が出てきたので、SWI-Prologを試し始めた。コンソールではSJISも通るみたいだし、使えるのかも・・・しばらく前はCiao-Prologに注目していたが、結局積極的な用途を見出せないままにズルズルきていた。Ciao-Prologのマニュアルも凄かったが、SWIのマニュアルは洗練されているし、270ページもある。SWI-Prologはアムステルダム大学の社会科学情報学部で開発されているが、単なる研究用の実装ではなく実用的なプログラミング言語としても相当なレベルにあるようだ。WindowsのDDE Client/Serverのインターフェースも持っている。
SWI-Prologのハローワールド
[modified: 2003-2-15]
10年ぐらい前に、まだ私がPC9801BXを購入する前、MyPC有史以前のこと、OASYS30AX301上でMS-DOSを動かしていた頃、Dennis Merritt著、岩谷宏訳、「Prologの冒険」(ソフトバンク、1992年10月21日初版、212ページ、3500円)という本がS-Prologを収録したフロッピーを添付して発売された。その頃試して、MS-DOSの限界を感じたPrologプログラムをフロッピーの山を掻き分けて見つけ出した。テキストデータからAWKを使って書いたデータ内蔵型データベースプログラムだ。S-Prologの2.5が佐藤さんのページにあり、それを元に梅田さんがUnixに移植したソースがある。これはCygwin等でmake可能である。Cygwinでは私は-lxpg4をはずしてmakeしている。以前のソースはMac用に改行コードがなっていて、うまくmakeできなかったのをわたなべひろふみさんに教えてもらって、BOWでmakeした。これも随分以前のFGALTSの話だが、有史以後である。梅田さんに報告したので、改行コードを変更してもらったのだろう。今回は問題なくmakeできた。SWI-PrologはSJISのコードはそのままでは通らないようなので、メモリの制約のはずれたUnix版S-Prologの再登場になったわけだが、どこまで使えるか。有料だが、SJISも使えるK-Prologというのがあるけど、文字コード関係でエラーが出るので取り敢えず購入中止。Prologの冒険は原文がAdventure in Prologで読めるので、Prologの勉強には役立つと思う。通常の手続き型プログラミングとは違った世界を味わえる。
ペンギンが蠅叩きで、青と緑のMSカラーと橙と黄色のSunカラーの羽を持つ蝶を叩き落そうと睨んでいる。世界中のソフトウェア・ギークがマイクロソフトとサンを脅かし、コンピュータの世界をひっくり返そうとしているという記事がBusiness Week 3月3日号に特集された。「驚くべき創造者」の写真には、「Torvaldsはリナックスをホビイストとハッカーの自由なおもちゃとして見た」と説明がある。「良いプログラミングには楽しむことが必須である。人々はのらくらできることが必要だ。」というわけだ。それこそがLinuxが成功した原動力だろう。これが義務になり、仕事になると、没落への道が待ち構えている、かな? 既に仕事にしている人もいるし、そこから利益を得る人も会社も増えている。さて、この格差をコミュニティはどう考えていくのだろう。高潔な創造者の存在がコミュニティの崩壊を押し留めるだろうか・・・成功はいつまでも続かない・・・Torvalds自身は成功にスポイルされないと目されているが、没落の芽は成功の中に潜んでいる。マイクロソフトの利益率の高さがOfficeの値引きを抑制するように(^^;)
記事は次のよう。
ホームオートメーションはアメリカでは結構ポピュラーになっているみたいだ。オープン・ソースのMisterHouseというプログラムもあって、Perlで書かれている。他のリンクも載せておこう。日本で使えるかどうかは疑問だが・・・
TPJの記事をJon Orwantが再編集した"Computer Science and Perl Programing"を、北米のTPJ購読者は15ドル引きの24.95ドルで買えるのだが、日本の読者はあきらめてAmazonに行くと15%引きで買えた。
Perl5.8をShift_JISで使いこなしたい人への追加情報。鈴木紀夫さんのページ。でも、まだよくわからない。モジュールを使ったりすると、いつのまにかUTF8になったりするしね。結局、JPerl5を使うことになるのだが、モジュールが5.6以降の機能を本格的に使うと困ってしまう。ローカライゼーションの悪夢から逃れることができるのはいつのことやら(^^;)
プレステ2の次を狙うSCEの特許が米国で成立という記事が出たので、野次馬で見に行ってきた。Memory protection system and method for computer architecture for broadband networksだ。最初のクレームからして長ったらしいが、簡単に言うと、プログラムとプログラムと統合されたデータを格納する一番目のメモリと、それらを処理する複数の一番目の処理ユニットと、一番目の処理ユニットによる一番目のメモリへのアクセスを制御するメモリ・コントローラと、一番目のメモリへのアクセスを統合するためのアクセス・テーブルとキー・テーブルを格納する二番目のメモリとメモリ・コントローラからなるコンピュータ処理システムである。要はネットワークで動く並列コンピュータシステムなのかな。日経は特許をウオッチするのも仕事なんだよねぇ。パテントになったのは2/25だ。
昨日のCellに関する米国出願に対応する日本出願を調べてみた。出願人のソニー・コンピュータエンタテイメントの識別番号と発明者名の「山崎」を掛け合わせて、IPDLの公報テキスト検索をしたらすぐ見つかった。6件引っ掛かるだけだから、探すのは簡単。米国で出願して優先権主張しているので、対応がすぐわかる。図が47もある。
【発明の名称】コンピュータ処理システム及びコンピュータで実行される処理方法
【出願人】株式会社ソニー・コンピュータエンタテインメント
【発明者】鈴置 雅一、山崎 剛
【要約】【課題】 広帯域ネットワークを介する高速処理用コンピュータ・アーキテクチャとプログラミング・モデルが提供される。【解決手段】 上記アーキテクチャは、均一なモジュラー構造と、共通のコンピューティング・モジュールと、均一なソフトウェア・セルとを用いる。共通のコンピューティング・モジュールの中には、制御装置と、複数の処理ユニットと、処理ユニットがプログラムを処理する元となる複数のローカルメモリと、ダイレクト・メモリ・アクセスと、コントローラと、共用メイン・メモリとが含まれる。共用メイン・メモリからのデータの調整された読み出しと書き込みを処理ユニットによって行うための同期システムと方法とが提供される。
【請求項１】 プログラムと前記プログラムと関連付けられたデータとを格納する第１メモリと、前記プログラムとそれに関連付けられた前記データとを処理する複数の第１処理ユニットと、前記第１処理ユニットによる前記第１メモリへのアクセスを制御するためのメモリ・コントローラと、アクセス・テーブルとキー・テーブルを格納する第２メモリであって、前記アクセス・テーブルは、複数のアクセス・エントリを有し、各アクセス・エントリは、アクセス・キーと、前記アクセス・キーと関連付けられた前記第１メモリ内の１つのメモリ・スペースの識別子を含み、前記キー・テーブルは、複数のキー・エントリを有し、各キー・エントリは、前記第１処理ユニットの識別子と前記第１処理ユニットと関連するリクエスト・キーを含んで成る第２メモリと、前記第１処理ユニットによる前記プログラムとそれに関連付けられた前記データの処理を制御するための第２処理ユニットであって、前記アクセス・テーブルと前記キー・テーブルの作成と更新の操作が可能で、更に、前記第１処理ユニットによる前記プログラムの１つの処理を行う指示を出すことが可能となる前記第２処理ユニットとを有し、前記第１処理ユニットの１つは、前記１つのプログラムの処理において前記メモリ・コントローラにリクエストを出して、前記第１メモリ内の格納位置をアクセスすることが可能であり、前記メモリ・コントローラは、前記リクエストに応答して、前記キー・テーブル内の前記第１処理ユニットの１つと関連付けられたリクエスト・キーと、前記アクセス・テーブル内のアクセス・キーとを比較して、前記アクセス・キーの１つが、前記キー・テーブル内の前記第１処理ユニットの１つと関連付けられたリクエスト・キーと一致して、かつ、前記格納位置が、前記アクセス・テーブル内の前記１つのアクセス・キーと関連付けられたメモリ・スペースと一致する場合は、前記リクエストの実行が可能であることを特徴とするコンピュータ処理システム。
【代表図面】 本発明によるハードウェア・サンドボックス用メモリ・アクセス・キーの格納方式を例示する図である。
【図１】 本発明によるコンピュータ・ネットワークのアーキテクチャ全体を例示する。
出典: 特許電子図書館
巨大ホッチキス(12000円)でSWI-Prologのリファレンスマニュアルを綴じるには、手持ちの針では無理なので、メガに出掛けた。マックス針の1217FA-H(1000本で550円)なら120から160枚が綴じれるはずだ。135枚、270ページのマニュアルは一冊の書籍並の分厚さである。切れていた製本テープも35mm(10m、600円)と20mm(10m、400円)のものを購入。35mmでは270ページは厳しい幅だろうと50mmを購入する選択肢もあったが、めったに使わないと思って止めた。帰宅して、早速綴じて製本すると、案の定、マックス針がテープに隠れるギリギリの状態だった。これが限界だが、見事に一冊の本が出来上がった。パラパラと捲って感触を確かめる。人間って、アナログだよね。270ページの自作本消耗品コストは、インク代がよくわからないが500円程度だろう。インクを除けば、紙代、製本テープ等で250円。巨大ホッチキス以外には、インターネット接続費用、PC、インクジェットプリンタの設備等の固定費を要しているわけだが、個人で本が作れるのがうれしい。一昔前を考えると夢のような話だ。
知識に関しても、素晴らしい世界がインターネットに広がっている。昔、日経バイトでPD-Prologを配布したことがあった。5inchのフロッピーを送るとコピーして戻してくれたのだ。今なら、そのようなサービスは想像もできないということになるだろう。今や、誰もが共有できる知識の塊がGPLでインターネット上のあらゆるところで配布されている。感謝。ここで宣伝するぐらいしかお返しもできないが・・・インターネットの活用こそが究極の知的生産の技術だろうと思う。
Gate 2.1-beta1に更新日記を読み込む
随分以前に2.0をダウンロードして、インストール、162ページもあるユーザーガイドを印刷。そのままになっていたので、再度Gateのサイトを訪問した。2.1-beta1が出ていたのでダウンロードしてインストールしてみた。ガイドを読むとHTMLを読み込めることがわかったので、更新日記を読み込んだ。おもしろい。Javaで書かれているので、基本的に国際化がなされているとは言え、ShiftJISの文書がそのまま読めて、HTMLタグが適切に除去され、整形されて表示されたのには唸ってしまった。マルチバイト文字を入力検索してマーキング表示が可能だ。内部的にはUnicodeを使っているからできるのだろうが、入力の文字コードの認識はどうしているのだろう。Annotation Editorを内蔵、元のHTMLタグの場所は記憶されていて、タグを編集できる。やはりXMLのような構造化文書の編集用だろう。タグのない可読性の高い文書を見ながらタグの位置をマーキングで確認しつつ、タグの属性等を編集できるわけだ。元々Unicodeエディタも内蔵していて、Windows上から日本語の入力表示が可能だったし、ユーザーガイドのGUI画面にベンガル語と英語が同時に表示されているのを見ていたので、なかなか凄い技術だなと思っていた。シェフィールド大学のハミッシュ・カニンガムらが作っているGNU Library General Public License(LGPL)のJavaアプリケーションである。
GATEとは"a General Architecture for Text Engineering"の意である。
Feedreaderを起動してUpdateすると、登録している各ニュースサイトのニュースリストが浮かび上がって消えていく。SlashdotのXBOX Media Playerの記事からどうやって辿りついたのか最早わからないが(^^;)、With X#, Microsoft may popularize functional programmingに辿りついた。インタビューを受けているSean McGrathはPropylon Ltd., a Dublin, Ireland-based XML integration firmのCTOだ。X#はLISPに似ているらしい。CLR上で動くLispなんだろう。
Lisp系の言語がWebで有用であるという話はYahoo! StoreのViaWebで有名になっている。この間の事情は、Paul Grahamの普通のやつらの上を行け ---Beating the Averages---に詳しい。Paul Grahamは、久野雅樹・須賀哲夫訳、"ANSI Common Lisp"、ピアソン・エデュケーション、2002年9月1日初版第一刷、305ページ、3400円の著者である。
XMLのデータツリーを関数のツリーにマッピングすると意味論的にすっきりするので、取り扱いが容易になるという話が、渕さんの盆栽的プログラミング、XML Functional Mappingにある。これを元にもう一つのXML APIがRubyやJavaに実装されている。人工知能言語のLispやPrologは意味を取り扱う場合には、得意とする分野だけに特に注目すべき言語であることは間違いないだろうが、他の言語で不可能なわけではない。もっともPaul GrahamのLispのプログラミングとしての優位性についての主張はマクロにあるようだが・・・
日記マークアップ言語dmlはHTML化を前提に考えられているのだが、表現と内容は分かち難く結びついているので、内容だけについてxml化を考えると表現に関する情報が失われる。具体的には日記の内容の部分にはパラグラフとリストがある。パラグラフの中にはイメージがある。複数のパラグラフやリストの構造は、日付、タイトル、リンクやカテゴリ等の意味的な構造とは異質な存在である。従来、xmlは意味的な内容と表現を分離して、内容だけを取り出すと言われていたが、実際に取り扱ってみるとよくわかることだが、表現を完全に分離してしまうと、内容だけからは表現を再現することができない場合が多い。更新日記のような簡単な構造のものでさえそうである。dmlはHTMLと完全に相互に変換可能だが、はて、xmlと相互変換可能にするためにはどのようにすればよいだろう。スマートにxml化できるだろうか。
XMLを本格的に勉強し始めた頃に購入した有限会社マークアップ著、「PHP,Perlで使うXML/XSL、Sablotronで実現するWEBサイト管理の効率化」、ディー・アート、2001年7月1日初版、255ページ、2600円が参考になるかもしれないと引っ張り出した。XML/XSLを使えばWEB製作の編集者、デザイナー、ライターが本当の意味で分業可能となるというコンセプトの元に書かれた本なのだが、最初、読んだときは、私のXMLの捉え方は意味と表現の分離にあったので、実際のXMLのタグを見ると、HTMLのタグを単に置き換えたもののように感じ、そりゃないだろと、放り出してしまったのである。しかし、意味と表現の分離は難しい。xhtmlもxmlだが、表現を司るものだ。表現にも当然意味がある。リストは複数の要素を集合として捉えている。一つ一つの要素も意味を持つが、集合としての意味もある。表はどうするのか。画像はどうするのか。内容の記述にはあらゆる表現形態への対応が要求される。うーむ。News Industry Text Formatぐらいだと表現力は完璧なので、これに準拠するのがよいのかもしれない。こちらももう一度調べてみよう。RSSの構造は単純すぎるので更新日記に対応するのは無理だ。日記の要約をニュースとして発信するためには使える。RSSの2.0は調べる価値はあるかもしれない。
Documentation for NITFを調べてみた。バージョンは3.1になっている。xmlとhtmlのサンプルを比較してみるとよくわかる。表現に関わる部分はHTMLに近い。リストやパラグラフはそのままだが、テーブルにはメタデータを記述するためのタグがある。イメージはmediaというタグで属性を細かく指定することができる。結論、XMLにも表示用タグは必要。メタデータ用タグ(メタデータ) + 表示用タグ(コンテンツ) = XML である。表示用タグはメタタグで包まれる関係になる。意味・内容はXMLで、表示はXSLでという図式は思い込みの幻想だった。コンテンツと表現の分離はどう考えても原理的に無理があるということ。XML + XSL = HTML + meta data のほうが実際的な表現かもしれない。ただ、HTML化するとメタデータが失われるのがおもしろくないというか・・・何かそんなことを感じている。すべてがHTMLで表現されるべきではと思ったり・・・まあ、XMLはmachine-readableに重きが置かれているので、人間ならメタデータを表現から読み取れるということかな。