IPA


開発成果一覧へ

 



2005年度下期 未踏ソフトウェア創造事業  採択案件評価書

 


1.担当PM

   原田 康徳 (NTTコミュニケーション科学基礎研究所 主任研究員)

 


2.採択者氏名

開発代表者

 宮脇 文経  (株式会社エス・クルー)

共同開発者

 なし


3.プロジェクト管理組織


  NTT出版株式会社


4.委託金支払額


 1,991,162


5.テーマ名


  源氏物語の鑑賞支援ツールの実用化

 


6.関連Webサイト


  http://www.genji-monogatari.net/


7.テーマ概要


 IT革命の進展に伴い、デジタル技術やネットワーク技術を活用して、生活の質的向上を図ることが重要となっています。私は、最近、源氏物語に強く関心を抱くようになりましたが、この分野では、まだ、IT革命の恩恵を十分に活用しきれていないのが現状であると感じました。
  そこで、昨年、この未踏プロジェクトにおいて「源氏物語の鑑賞支援ツールの開発・整備」と題して、源氏物語の鑑賞に役立つ各種の情報を、IT技術を駆使し て使いやすい形に整理し、さらに源氏物語に興味を持つ人たちの新たなコミュケーションツールにもなりうることを目標にソフトウェアを開発しました。この結 果、「IT技術を駆使して使いやすい形に整理」する点と、「新たなコミュケーションツールにもなりうる」点には一定の成果が得られたと自負しております。

 しかし、「源氏物語に興味を持つ人たち」誰にでも簡単に使えるかという点においては、まだ以下のような課題が残っております。
  ●会員の登録・認証・管理・アップロードの仕掛けの整備。
  ●手入力困難な情報の入力支援


 また、現在の源氏物語の鑑賞支援ツールには以下のような改善の余地も残っています。
  ●縦書きのサポート(源氏物語の愛好家たちの間では、縦書きには根強いニーズがあります)
  ●古書の鑑賞支援(古書画像と本文の対応をとって、崩し字に慣れていない人が古書を読む一助とする)

 そこで、今回は、これらの課題を実現し、源氏物語に興味を持つ人たち誰にでも簡単に使えるツールに進歩させることを目標にした開発を行いたいと考えています。


8.採択理由


 前回の採択からの継続テーマである.前回開発されたXML+XSLTによるマルチドキュメントの提示ツールを,今回はマルチユーザで自由に投稿できるようにするシステムの提案である.
 このシステムが成功すると,源氏物語を専門家の鑑賞,解釈だけでなく,様々なユーザが自由な発想で鑑賞し,それが共有できるようになる.
 今回は開発すべき課題が明確であり,予想される問題も見えているので,前回以上の成果が期待される.想定されるユーザはITを上手に使えない人が大半であるため,それを考慮したインタフェースが望まれる.

 

 


9.開発目標


現在、源氏物語の本文、注釈、現代語訳などを使いやすい形に整理して公開するWebサイトとして、「源氏物語の世界 再編集版」があります。そのサイトでは、高千穂大学の渋谷教授がWebサイト「源氏物語の世界」で公開している源氏物語の本文、注釈、現代語訳などを読みやすい形式に再編集して公開しています。

この再編集は、専用の再編集プログラムを作って行っていますが、現状では、渋谷教授の本文、注釈、現代語訳に特化しているため、柔軟性に欠けています。

昨 年のプロジェクトでは、この再編集プログラムのデータ構造に着目し、それを整理・改善して、新たなコミュケーションツールに必要な柔軟性を獲得することを 主目的とした開発を行いました。その結果、一定の成果が得られましたが、実用に供しようとすると、まだ、改善の余地が残っていました。

 


10.進捗概要


(1)昨年の成果

次の図は、昨年のプロジェクトの目標のイメージを説明したものですが、これが、その成果も端的に現しています。白い部分は、「源氏物語の世界 再編集版 (HTML形式)」にすでにある部分、水色の部分が、昨年のプロジェクトで目標とした部分です。



 

 

 

この目標は達成されました。そして、例えば以下のような複数のXMLデータを入力して、動的に再編集処理

を実行

 することで、以下のようなページを動的に生成して表示できるようになりました。

 

 

 


 

(2)今年の目標

しかし、昨年のプロジェクトの成果だけですと、実際には第三者が現れたとしても、まだ、第三者がWebから簡単に登録することはできず、メールでアップロードファイルを受け取るなど方法をとる必要がありました。しかし、これでは、せっかく実現した高い拡張性を損なってしまうことになりかねないので、第三者がWebから簡単にアップできる仕掛けの整備を急ぐ必要があり、それが今後の課題になっていました。

また、再編集結果として出力されるページは、すでにあるHTML版と似たようなページであり、わざわざ利用者に動的再編集の操作をしていただくには、実用上の魅力に乏しいものにとどまっていました。

 

a)会員の登録・認証・管理・アップロードの仕掛けの整備

昨年のプロジェクトの今後の課題であった、第三者がWebから簡単にアップできる仕掛けの整備に対応するものです。

単に、第三者がWebか ら簡単にアップできるというだけであれば、必ずしも会員の登録・認証・管理の機能は必要ありません。しかし、会員認証などの手続きを踏まずに誰でも自由に アップできるようにすると、悪意を持って利用された場合に対処できません。せっかくアップロードしたデータを、悪意を持った第三者に改竄されたとしても、 誰がそのようなことをしたのかわからず、野放し状態になってしまうためです。

そこで、今回は、悪意を持った第三者によるデータ改竄を防止するため必要になる最低限の会員管理機能を実現することにしました。

そこで、今回は、以下のようなポリシーに基づく会員管理機能を実現することにしました。

        悪意を持った第三者によるデータ改竄を防止するための必要最小限の会員管理機能を実現します。

      このため、個人情報はメールアドレス、ニックネーム、パスワードのみを管理します。

       金銭授受を伴わないため、本人確認は重要ではありません。しかし、無確認では悪意を持った第三者に利用された場合に有効な対策が取れないので、最低限、メールアドレスの有効性だけは確認します。すなわち、登録されたメールアドレス宛に、確認用のURL(パスワード等の引数付き)を記入したメールを送信し、そのURLに正しい引数でアクセスされたことが確認できたとき、会員登録情報を有効化します。

 

(b)機能の向上

昨 年のプロジェクトで実現した動的再編集機能を使う上での実用上の魅力の向上を目指します。昨年のプロジェクトでは、基本的な骨格は出来上がりましたが、ま だ、肉付け(機能)は十分とは言えず、それが実用上の魅力に乏しい状態につながっていました。そこに追加したい機能は多数存在します。

今回は、その中から、以下の2つの機能を選んで実現することにしました。

        縦書きのサポート

       ルビの追加

 

 

(c)再編集形式を第三者が追加できるようにすること。

この目標は当初から設定されていたものではありません。上記(a)(b)の目標に向けての開発作業中にプログラム構造に関する疑問が生じ、その解消方法を検討した結果、その疑問を解消することは、この目標を達成することとほぼ等価であることが判明したため、途中で、この目標を追加しました。その詳細は、「4.開発内容」で述べます。


11.成果


4.開発内容

ここでは、プロジェクト遂行の過程で行ったことを、行った順を追って説明します。

 

4.1 ルビの追加

本 文を読んでいると、時々、読み方の分からないものが出てきます。また、渋谷教授は本文をローマ字で書き直したローマ字版も提供されているのですが、その ローマ字版を覘いててみると、意外な読み方をしているものに気づくことがあります。しかし、ローマ字というのは日本人には読みにくいもの。なかなか、ロー マ字版をチェックしてみようという気にはなりません。

そこで、このローマ字版をひらがな版に変換し、これと本文をつき合わせてルビを抽出しようというのがこの課題です。すでに、昨年のプロジェクトの中で、XML形式のひらがな版のファイルは作成済みなので、これと本文をつき合わせてルビを抽出するための適切な比較処理を作成することが、この課題のポイントでした。

比較処理は、行単位ではなく、文字単位になるため、diffコマンドなどの既存の比較ツールを利用できません。一般的な比較アルゴリズムは調べて参考にさせていただいたものの、最後は試行錯誤によって比較精度を向上させることになりました。

今回の比較対象は、源氏物語全54帖に限定されているため、個別に誤比較事例を蓄積して、その事例に該当するところは、強制的に正しい判定に倒すような処理も入れました。この結果、大きな比較誤りはなくなりました。計ったわけではありませんが、比較結果の正答率は既に99%を大きく超えているものと思います。

しかし、まだ、「殿(との)(うち)」とすべきところを「殿()(のうち)」としてしまう類の誤比較は少なからず残っています。このため、比較結果正答率99.9%には、まだ届いていないものと考えています。

このような誤比較は、プログラムロジックでは対応困難であり、誤比較事例を蓄積して対応すべきところと考えます。しかし、それを抽出するには全54帖全体にわたっての精査が必要で工数がかかること、プログラムとしては誤比較事例を蓄積する機能は実装済みであることから、このような事例だけを抽出するための精査は未踏プロジェクトにはなじまないと考え、本プロジェクト終了後に実施する予定です。

以上のようにして作成したルビデータのサンプルは以下のとおりです。

 

 

 

 

 

<?xml version="1.0" encoding="Shift_JIS"?>

<コメント name="本文のルビ" for="本文">

      < no="01" name="桐壺">

< no="1" name="第一章 光る源氏前史の物語">

< no="1" name="第一段 父帝と母桐壺更衣の物語">

<ルビ no="1" keyword="御時">おほんとき<開始 行="1" ="4"/><終了 行="1" ="6"/></ルビ>

<ルビ no="2" keyword="女御">にょうご<開始 行="1" ="9"/><終了 行="1" ="11"/></ルビ>

<ルビ no="3" keyword="更衣">かうい<開始 行="1" ="12"/><終了 行="1" ="14"/></ルビ>

<ルビ no="4" keyword="">きは<開始 行="1" ="38"/><終了 行="1" ="39"/></ルビ>

<ルビ no="5" keyword="">とき<開始 行="1" ="50"/><終了 行="1" ="51"/></ルビ>

                                    (以下略)

 

また、このルビデータを使用した再編集結果の一例を以下に示します。

 


 

4.2 縦書きのサポート

源氏物語の愛好家たちにとって、縦書きには根強いニーズがあります。横書きで書かれた源氏物語関係のWebサイトは多数ありますが、Webブラウザが縦書きをサポートしてくれないため、やむを得ず横書きを使っているだけです。

昨年のプロジェクトではXML/XSLTを使った動的再編集を実現したので、これをうまく使って、縦書きをサポートしたXMLスタイルシートを追加し、必要に応じて切り替えて使用することでサポートできると考え、今年のテーマの1つにしました。

今回は、以下の2つの縦書き用スタイルシートを追加しました。

  Internet Explorer上で縦書き表示するためのXMLスタイルシート。IE5以降限定。印刷はうまくいかない。

  Word 2003以降で印刷するための縦書き文書を生成するXMLスタイルシート。文字は90度左回転して表示される。

 


 

(1)Internet Explorer上で縦書き表示

Internet Explorerでは、5.5から縦書きをサポートしています。この機能を使って、以下のような縦書き表示ができるようにしました。

 

この機能の開発では、Internet Explorerのバグの回避に結構悩まされました。縦書きの印刷には大きなバグがあって使い物にならないことが最初から分かっていたため、印刷用に別途、Word 2003による縦書き印刷用文書作成機能を作ることにしていましたが、他にも以下のような問題がありました。

      ルビを表示すると、行の並びが乱れて読みにくくなる問題。回避策を色々試みてみましたが結局回避できなかったため、この機能では、ルビを非サポートにしました。本件、IE7Betaテスト結果として縦書き印刷の問題とともに報告済みです。

      段組の高さを自動設定できず、%指定で相対的に指定することもできません。結局、段組の高さはポイント数で絶対値を指定することにしました。省略すると、180ポイントを仮定します。上の例は、本文、渋谷栄一訳、与謝野晶子訳を各140pt、注釈等の記述を300ptに設定したものです。

 


 

(2)Word 2003による縦書き印刷用文書作成

 この機能は、Internet Explorerの縦書き印刷のバグの回避策として始めたものですが、実際に作ってみると結構使い勝手の良いものになったように思います。以下のような文書が作成されます。

 ただし、現在、以下の問題が未解決のまま残っています。これらの問題は今回のプロジェクト期間中には解決することができませんでしたが、プロジェクト終了後でも、できるだけ早い時期に解決したいと考えています。

   文書に挿絵を挿入する機能が未実装です。

  昨年のプロジェクトでは、挿絵だけでなく、動画や音声などのマルチメディアオブジェクトもHTMLで表現できるオブジェクトであれば文書中に挿

入できるようにするために、任意のHTMLタグをCDATA文字列としてXMLの中に持つ方法で実現しました。しかし、WordXML形式文書の中ではHTML

使えないので、このデータは、そのままでは使えません。
  もっとも、このWordの文書は印刷用なので、動画や音声などのマルチメディアオブジェクトは不要です。昨年のプロジェクトで作成した「ユネスコによる絵入源氏物語の挿絵と解説」のような静的なオブジェクトは、あれば便利ですが、HTMLに依存するため、Wordでは実現困難と考え、これも割愛できます。しかし、挿絵だけは必要だと考えています。Wordにも対応する機能があるので、XML内での挿絵の情報をCDATA文字列ではなく通常のXML要素で表現すれば、実現可能です。
  そこで、現在、挿絵をオブジェクトから独立させ、Wordでは挿絵だけをサポートすることを考えています。

     与謝野晶子訳の中に外字データがあると処理できない問題は未対策です。(全230ファイル中8ファイルに存在)
 この外字データは<IMG>タグで表現されており、それが非XMLタグとして与謝野晶子訳のテキスト中に埋め込まれています。これを、そのままテキストとして処理しようとするために問題が生じます。
 もともと、与謝野晶子訳には、ルビも<RUBY>タグで表現されてテキスト中に埋め込まれていました。これを昨年のプロジェクトでは、<RUBY>タグ部分を「与謝野晶子訳のルビ」として独立させ、テキストから<RUBY>タグを除外しました。
 そこで、今回も、この外字データの<IMG>タグ部分を「与謝野晶子訳の外字」として独立させ、テキストから<IMG>タグを除外することを考えていま 

す。こうすれば、XMLスタイルシートの中で外字を認識してWord文書にあわせた処理ができるので、本機能でも外字を使用できるようになります。

     外字にルビが振られていると処理できない問題(Wordの仕様)の回避は未実施です。
 この問題は、上の問題の解決後に控えている問題ですが、すでに実験によって、このような問題が生じることが分かっています。
対策は、「与謝野晶子訳のルビ」から外字のルビを取り除き、「与謝野晶子訳の外字」に外字のルビを追加した上で、本機能では外字のルビを無視することを考えています。

    1つのセルのデータが、1ページに収まりきらない場合、あふれた部分は表示されません。これはWordの仕様で、セルの幅を広げる、フォントサイズを小さくする、ページサイズを大きくする、行間を詰めるなどの対策で、なんとか1ページに押し込める必要があります。しかし、中には、1行が1000字を超えるものもあり、このような方法だけで対処するのは難しいものも少なくありません。
そこで、長すぎる行を2行以上に分割して短くしたデータを作り、私の名前で公開することを考えています。

 

4.3 CSSの活用による再編集仕様設定方法の変更

昨年、実現した再編集仕様の設定ページは左図のようなものでした。

このうち、特に「リンクするコメント」で指定できる内容には不満がありました。上部に「リンク 太字 斜体 下線 文字色 背景色 強調 拡大 ルビ」という見出しがありましたが、これは、それぞれ、HTML<A><B><I><U><FONT><SPAN><EM><BIN><RUBY>の各タグに対応するものでした。そして、そこには以下のような制限があったためです。

@    コメントとタグは1:n対応である。つまり、出典を太字にしたら、注釈や校訂を太字にはできない。

A    文字色は赤に、背景色は黄色に固定されている。

B    フォントサイズも<BIG>タグで多少拡大できる以外は固定されている。

このうち、@の制限には技術的な背景がありました。注釈、出典、校訂には互いに入れ子関係が無いため、その範囲を正確に表現するには、互いに異なったタグを割り当てる必要があるという点です。これが、コメントとタグは1:n対応という制限になりました。

しかし、この場合でも、タグとスタイルの関係には言及していません。CSSをうまく使えば、タグとスタイルの関係は変更できます。たとえば、注釈、出典、校訂の三者をともに太字にしたいが、斜体にしたいものは無いという場合、<I>タグと<EM>タグを<I style=font-style:normal; font-weight:bold;>のようにすれば、このタグを<B>タグの代わりに使うことができ、@の制限は事実上乗り越えることができます。そして、このようにCSSを使うのであれば、ABの制限も解消できます。

このような考え方で、上記の不満を解消した以下のような画面を作りました。(「リンクするコメント」だけ抜粋

このページは最終版ではなく上の考えを検証するために作ったものなので、不要な列があったり、ルビの指定方法が変だったりしますが、そこは無視してください。ポイントは注釈、出典、校訂の三者をともに太字にしたことと、互いに異なる色を割り当てたことです。CSSを使っているので、フォント名や行ピッチなどを指定可能にすることもできます。反面、ルビはコメントとして統一して処理するには無理があることも見えてきました。

補足 このページの変更は、前述の「4.2 縦書きのサポート」の開発作業中に並行して開発していました。Word 2003による縦書き印刷用文書を作成するとき、色やフォント属性はHTMLとは異なった発想で実現する必要があり、その実現方法の検討と合わせて画面での指定方法も検討したためです。縦書き印刷用Word文書作成処理のために、色やフォント属性を指定する画面を上のような画面にするのは自然な発想なのですが、この画面はInternet Explorerで縦書き表示や横書き表示する場合も共通にしたいという思いがあり、そのために考えたのが、上で述べた、CSSでタグとスタイルの関係を変更してしまう方式でした。

 

 


 

4.4 V2.5からV3へ

(1) データ管理の枠組み

以上の開発を終えた状態で、開発は大きな区切りを迎えました。私は、この状態をV2.5と呼んでいます。というのも、ここまでは、以下のような点で、いわばV2(昨年のプロジェクト)の延長だったからです。

      「ル ビの追加」は、もともと、V2の目標「第三者による注釈・解説の類を追加できる」の最初の適用例にしようと考えていたものでした。しかし、その奥が深く、 結局、V2ではひらがな版を作成するところまでにとどまりました。なお、ひらがな版はV2の目標「第三者による新たな現代語訳などのテキストを追加でき、 自動的に対象表示されるようになる」の最初の適用例になりました。

       「縦書きのサポート」も、V2の開発途上から、すでに、Word 2003XML形式を使えば、スタイルシートを替えるだけで実現できるのではないかという考えを持っていましたし、多少の実験を行って、実現方法を検討したりしていました。

この後の最初の課題は会員の登録・認証・管理機能とアップロード機能の追加です。しかし、その課題に着手する前に判断しなければならないことが1つありました。

こ れらの機能では、会員情報や、アップロードするコンテンツの情報などのデータを管理する必要がありますが、そのデータ管理の枠組みとして、既存の枠組みを 使い続けるか、新しい枠組みに乗り換えるかです。乗り換える場合には、プログラム構造は大きく変わり、かなりの部分を作り直す必要が生じるなど、もはや、 V2の延長とはいえない状況になります。

この2つの枠組みを比較すると、下表のようになります。

項目

既存の枠組み

新しい枠組み

プロバイダ

ぶっとびねっと

さくらインターネット

データ管理方法

テキストファイル 【×】

MySQLデータベース 【○】

独自ドメイン

使用不可 【×】

使用可 【○】

費用

無償 【○】

有償 【×】

\5000/年+\1800/(独自ドメイン)

セキュリティ

【×】

全ファイルをインターネットに公開する。

会員情報等もテキストファイルなので、.htaccessで保護したとしても、URLが分かり、パスワードが破られればアクセスできてしまう。

【○】

htdocsサブフォルダ配下のみをインターネットに公開。
(非公開ファイルを自由に作れる。)

今後の開発(新機能分)

作りにくい 【×】

(データの処理を、文字列処理と正規表現を駆使して実現要)

作りやすい 【○】

PHPMySQLAPIとツール(phpMyadmin)の両面でサポートしている)

今後の開発(既存機能分)

修正不要? 【○】

(新機能の影響が出る可能性あり)

修正要 【×】

(データ管理方法変更)

結論

×

私は、この両者のどちらにするかでずいぶん迷いましたが、最終的には新しい枠組みに乗り換えることにしました。既存の枠組みの良い点は「無償」と既存機能部分は「修正不要」だけで、他は新しい枠組みの方が良いこと、「修正不要」といっても「?」付きで、新機能の影響が出ることが見込まれることを考えて、そうしました。

 

(2) プログラム構造への疑問

V2.5のプログラムの構造には疑問も出てきました。それは、再編集形式が増えても、再編集仕様設定ページは1種類だけなのかということでした。ここで、再編集形式とは、横書き表示、縦書き表示、縦書き印刷用Word文書、といった、動的再編集処理で出力するデータ形式のことです。

確かに、再編集仕様設定ページで指定する項目は、この3つの再編集形式の間では同じでした[1]。将来、項目を増やしたとしても、そんなに大きく変わらないだろうという見通しもありました。

しかし、V2.5で縦書き印刷用Word文 書の再編集形式を追加したとき、再編集仕様設定ページも変更したので、横書き表示や縦書き表示の機能は動作しなくなっていました。これでよいのでしょう か。将来、指定項目を増やしたとき、全ての再編集形式で一斉に、その項目をサポートしなければならないのでしょうか。あるいは新しい再編集形式を追加した とき、その形式の特性上重要な項目を追加したとしたらどうでしょう。あまり重要ではない他の形式でも一斉に、その項目をサポートしなければならないとした ら、それでよいのでしょうか。

私は、この疑問に対してひとつの回答を考えていました。それは、分離・独立と部品化です。

再編集仕様設定ページで指定する項目を、共通項目と、再編集形式毎に個別に指定すべき項目とに分け、個別に指定すべき項目は再編集形式毎に専用のページを作って独立させます。そして、独立させた各ページ間で共通する部分は部品として切り出して共有します。

例えば、帖・章を選択する項目と、再編集形式を指定する項目は共通項目です。反面、再編集結果の書式を指定する項目は個別に指定すべき項目です。色やフォント属性、段組の幅、行ピッチといった属性がこれに該当します。

一 方、対象コンテンツを選択する項目はどちらなのか迷いました。例えば、左の段組には本文を表示し、中央の段組には渋谷栄一訳、右の段組には与謝野晶子訳を 表示するといった指定や、本文に注釈・出典・校訂などの情報を付加するかどうかの指定、挿絵・動画・音声などのオブジェクトを挿入するかどうかの指定など です。これらは、再編集形式によってはサポートできない項目が出てくる可能性があります。例えば、縦書き印刷用Word文書では、動画や音声などのオブジェクトの挿入には意味がありません。しかし、対象コンテンツは再編集形式によらず共通であること、サポートできないコンテンツの指定は動的再編集処理で無視すればよいことなどから、これらは共通項目と考えることにしました。

 

[1] 当時。現在は段組の幅や行ピッチが追加され、指定方法には微妙な違いがあります。

 

 

(3) V3に新目標追加: アップロード機能を使って新たな再編集形式を第三者が追加できること。

こ こまでは、再編集仕様設定ページだけについて触れましたが、同様な議論が動的再編集処理ページにもあります。このページはXMLスタイルシートを使って実 際に動的再編集処理を実行するページです。V2.5では、このページと再編集仕様設定ページの関係は以下のようになっていました。

 

 

し たがって、先の疑問「将来、指定項目を増やしたとき、全ての再編集形式で一斉に、その項目をサポートしなければならないのでしょうか」を解消するために は、再編集書式設定ページ(個別指定すべき書式情報などを設定するための再編集形式毎の専用ページ)と動的再編集処理ページの両方を再編集形式ごとに分 離・独立化する必要があります。(下図)

 

 

 

 

そ して、このような構成にした場合は、@再編集書式設定ページと、A動的再編集処理ページ、BXMLスタイルシートの三者一組で追加することで、新たな再編 集形式を追加できます。そこで、これをV3の新たな目標「アップロード機能を使って新たな再編集形式を第三者が追加できること」として追加しました。

 

4.5 会員の登録・認証・管理機能の追加

V3では、悪意を持った第三者によるデータ改竄を防止するため必要になる最低限の会員管理機能を実現することにしました。具体的には、以下のようなポリシーに基づく会員管理機能を実現しました。

      個人情報はメールアドレス、名前(ニックネーム可)、ユーザID、パスワード、自己紹介を管理します。このうち、メールアドレスとパスワードは非公開ですが、他は公開します。

      金銭授受を伴わないため、本人確認は重要ではありません。しかし、無確認では悪意を持った第三者に利用された場合に有効な対策が取れないので、最低限、メールアドレスの有効性だけは確認します。すなわち、登録されたメールアドレス宛に、確認用のURLを記入したメールを送信し、所定期間内にそのURLにアクセスされたことを確認することによって、メールアドレスの有効性を確認します。

       認証はユーザIDとパスワードで行います(基本認証)。ユーザID忘れやパスワード忘れには対応しません。

       ユーザID以外の個人情報は変更可能です。変更された場合は、登録メールアドレスに対して、その内容を報告します。

       メールアドレスが変更された場合は、再度、メールアドレスの有効性を確認します。

       簡単な更新履歴情報として、会員登録日時と最終更新日時を管理します。トップページの再編集仕様設定メニューに複数会員のコンテンツが列挙される場合は、会員登録日時の上昇順に列挙されます。

 

以上のように、この機能自体はオーソドックスなもので、新規性はあまりありません。そこで、この機能のために使えそうなオープンソースソフトが無いか探してみましたが、適切なものは見つかりませんでした。

しかし、この機能は源氏物語の鑑賞支援ツールを実用化する上では重要な機能になること、新しい枠組みではMySQLデータベースが使えるので開発は比較的容易と思われること、などを考え、未踏ソフトプロジェクトの一環として、この機能を開発しました。

開発したページのサンプルを以下に示します。

 

ログイン ダイアログ


 

 

 

4.6 アップロード機能の追加

この機能は、動的再編集処理の対象となるコンテンツをアップロードするための機能ですが、動的再編集処理との連携のためにいくつかの情報を管理するなどの関連機能を含みます。

具体的には、以下のような機能を実現しました。

     会員ごとにフォルダを割り当て、アップロードするコンテンツの種類ごとにサブフォルダを作成します。会員は、自分のフォルダ内のサブフォルダにコンテンツをアップロードできます。

      このサブフォルダを作成・変更・削除・一覧表示するためのフォルダ管理機能を提供します。以下、単に「フォルダ」というときは、このサブフォルダを指すものとします。

     フォルダを作成・変更・削除すると、その内容は、ただちに、トップページの再編集仕様設定メニューに反映されるようにしました。

      「コンテンツ名」と、その「概要」、および、コンテンツの表示「順序」も、このフォルダ情報として管理し、必要に応じて変更できるようにしました。

      再編集仕様設定ページは、このフォルダ情報からコンテンツ名、提供者名、概要を抜き出して、コンテンツの種類ごとに一覧表示する方式に変更しました。この結果、どのようなコンテンツがあるのかが分かりやすい再編集仕様設定ページに変身しました。

  フォルダ内のコンテンツファイルの操作としては、アップロードと削除を提供します。削除では複数のファイルをチェックして一括削除できるようにしました。反面、リネームは無く、削除と再アップロードで対応してもらいます。

   動 的再編集処理では、コンテンツファイル名が一定の命名規則に従って付与されている必要があります。そこで、ファイル命名規則をフォルダ情報として管理し、 必要に応じて変更できるようにするとともに、命名規則に従わないファイル名の場合はアップロード時のリネームを促すなど、命名規則に従ったファイルだけが アップロードできるような仕掛けにしました。

● 目標「アップロード機能を使って新たな再編集形式を第三者が追加できること」に対応するため、動的再編集処理も再編集形式ごとに1つのフォルダを割り当てることにしました。
新たな再編集形式を追加する場合は、このフォルダを追加して、そこに@再編集書式設定ページと、A動的再編集処理ページ、BXMLスタイルシートを三者一組でアップロードします。

 

これらの機能の実現後のページサンプルを以下に示します。


ページサンプル

概要

このページはログインした会員がフォルダの作成とフォルダ情報の変更を行うためのページです。そのためのボタンが、新規作成ボタンと、一括変更ボタンです。
一括変更ボタンでは、複数のフォルダ情報を一括して変更できます。内容を比較して変更の有無を認識するので、変更箇所をチェックするなどの操作は不要です。


 

                      ページサンプル  

概要

このページはログインした会員がファイルのアップロードと削除を行うためのページです。

最初の表は、アップロード先のフォルダを選択するためのもので、どれかをチェックすると、次のアップロードフォームと最後のファイル一覧が現れます。

次の表はアップロードフォームです。通常は、対象ファイルを選択して
アップロードボタンを押すだけでアップロードできます。しかし、選択したファイル名がXMLファイル命名規則に一致しない場合は、その下のリストボックスから帖と章を選択すれば、命名規則通りのファイル名に変更してアップロードされます。

複数のファイルをアップロードする場合も、操作は1ファイルずつ、繰り返して行います。

最後の表は、そのフォルダのファイル一覧です。各行の左端のチェックボックスをチェックして
一括削除ボタンを押すことでファイルを削除できます。複数ファイルチェックすることで、複数ファイルの一括削除にも対応しています。

フォルダ内にファイルが1つもない場合、ファイル一覧の代わりにフォルダ削除フォームが現れます。(このサンプルには表示されていません)


 

4.7 再編集書式設定ページと動的再編集処理ページの作成

ここまで開発してくると、機能的には、V3で目標にしていたものが出揃いました。しかし、まだ、連携して動作することができません。

縦書きとルビをサポートした新しい動的再編集処理はすでに動作していましたが、それは、データ管理の枠組みに古い枠組みを使用しており、古い再編集仕様設定ページと連携して動作するものでした。

こ れに対して、会員の登録・認証・管理・アップロードの仕掛けは、データ管理の新しい枠組みを使用して開発されました。そして、それと連係動作する新しい再 編集仕様設定ページもありましたが、そこには再編集書式の設定機能が省かれていました。代わりに再編集書式設定ページに遷移する書式設定ボタンがあります が、遷移先のページがまだ無いため、押しても何も動作しない状態でした。実行ボタンも同様で、データ管理の新しい枠組みで動作する動的再編集処理ページが 無いため、何もできない状態でした。

したがって、ここで、新たに、データ管理の新しい枠組みで動作する再編集書式設定ページと動的再編集処理ページを作成する必要がありました。

この2つのページの機能を整理すると、以下のようになります。

 

 

 

 

ただし、このイメージは分かりやすいのですが、そのまま実現しようとすると、セキュリティ上に問題があります。

このイメージはV2.5のプログラム構造がベースになっているのですが、V2.5では、再編集仕様設定ページと再編集書式設定ページは一体になっていて、PHPで書かれていました。サーバ側で会員情報やフォルダ情報を保持しているデータベース(V2.5ではテキストファイルで作られていましたが)にアクセスする必要があったためです。

V3では再編集書式設定ページと動的再編集処理ページは第三者がアップロードできることが目標になっています。しかし、PHPで記述するページを第三者がアップロードできるようにして良いのでしょうか。

PHP はサーバ側で実行されるスクリプト言語です。これを第三者がアップロードできるようにするということは、第三者が好きなプログラムをサーバにアップロード して実行できるようにすることなので、セキュリティ上、非常に危険なことです。決して許されるべきことではありません。

第三者がアップロードできるファイルは、以下のいずれかに制限する必要があると考えました。

@    クライアント側で参照されるデータファイル。XMLファイルや、XMLスタイルシート、GIF/JPEGファイルなど。

A    クライアント側で実行されるもの。HTMLJavaScriptJavaアプレット、ActiveXコントロールなど。

B    サーバ側で参照するデータファイル。その中には、上の@Aを展開するためのテンプレートファイルも含む。

 


私は、この制限の元で先の機能を実現する方法として、以下のような構成を考えました。

そのポイントは以下のとおりです。

     第三者がアップロードするものは以下の3つとなり、先の制限を満足します。

    再編集書式設定ページ(HTML & JavaScript

   動的再編集処理ページのテンプレート

     XMLスタイルシート

  再編集書式設定ページとサーバ側のPHPで書かれたページの間ではクッキー経由で情報を交換します。
このクッキーは30日間保存のアプリケーションクッキーとすることで、30日以内に再びアクセスされたときには再編集仕様設定や再編集書式設定をやりなおす必要が無いようにしました。

     動的再編集処理ページのテンプレートはHTML & JavaScriptの形式で記述し、単体でも実行できるようにします。
ただし、単体で実行した場合は、いつも決め打ちで固定の設定と帖・章のデータを使って再編集します。これにより、動的再編集処理ページの単体テストが簡単にできるようになります。

  動 的再編集処理ページ生成(PHP)では、動的再編集処理ページのテンプレートを読み込み、その中に決め打ちで固定の設定や帖・章のデータ参照を検出した ら、それを再編集仕様設定ページや再編集書式設定ページで指定された設定値や帖・章のデータ参照に書き換えて動的再編集処理ページを生成します。

 

今回は、私が、この3つのアップロード対象ファイル(再編集書式設定ページ、動的再編集処理ページのテンプレート、XMLスタイルシート)を、3つの再編集形式(@横書き表示、A縦書き表示、B縦書き印刷用Word文書作成)ごとに3組作成してアップロードしました。

 

以上により、V3の目標が達成されました。このV3の目標が達成された最初の版は 2006/8/18 にインターネットにアップしました。それ以後も、バグ修正やマイナーチェンジなどでしばしば更新しており、現在の最新版は以下のURLにアップしています。

http://www.genji-monogatari.net/xml/

 

 

 

 


12.プロジェクト評価

@      第三者が新たな現代語訳や注釈・解説等を追加できるようにするための「会員の登録・認証・管理・アップロードの仕掛け」が整備されました。これにより、昨年のプロジェクトで掲げたの当初目標(下図)が、ようやく、本来の意味で達成されたことになります。(水色の部分が本プロジェクトで目標とした部分です)

A      当初目標のようなデータの類だけでなく、再編集処理も第三者が拡張してアップロードできるようになりました。実際に、第三者がこれを行いのはデータの類よりも難しい問題がありますが、第三者でも拡張可能という高い拡張性は、私が今後機能拡張する上でも大いに役立ちます。
たとえば、昨年の成果では、まだ本文の朗読には対応できていませんでしたが、今年の成果では、本文の朗読に対応した再編集処理を追加することで実現可能になりました。

B      縦書きをサポートした2つの再編集形式とルビが追加され、古典を愛好するものにとっての魅力が増加しました。

 

再 編集処理を第三者へ拡張可能にした点など、期待以上の開発を行ったプロジェクトである。厳しいことをいうと、セキュリティホールの問題など、検討の余地は まだあるだろうが、まずは第一歩を踏み出したことのこの分野への貢献は大きいと思う。また、ここで培われたノウハウは、他の古典や多国語の文書など、互い に関連がとれているものを扱う際にも適用可能であり、面白い結果になったと思う。

 


13.今後の課題

    ボランティア作業者の勧誘
今 回のプロジェクトの目標であった、ボランティアなどの第三者が、コンテンツを容易に拡張できることと、複数の第三者が独立に拡張作業を行っても、混乱な く、容易にコンテンツが拡張できることは、達成されました。しかし、まだ、この第三者に該当する人がいません。現在、コンテンツ提供者になってくれそうな 人にメールで勧誘していますが、私が、その人のコンテンツをベースに新たなコンテンツを作って公開することを了承してくれた人はいるものの、新たなコンテ ンツを作って提供してくれる人はまだいません。この種の勧誘の難しさを実感しているところです。

    手入力困難なXML属性値の収集ツール
これは今年の実施計画書で開発項目に上げていたものですが達成できなかったものです。その理由は「7.実施計画書内容との相違点」を参照してください。
現在、注釈などのXMLには、pos="桁位置"などの手入力困難な属性が入っています。第三者が注釈や解説などをアップする場合、そのXMLファイルは手入力する場合も少なくないと思いますが、そのような場合に備えて、このpos属性などを設定するツールも別途作成する必要があります。

    「4.開発内容」の中で指摘した残留問題点の解決
この問題点は、ルビの追加と縦書きのサポートで指摘していますが、どれも入力XMLデータの整備が必要になり、手間がかかること、および、データの整備は未踏プロジェクトには馴染まないという考えが昨年のプロジェクトでPMから示されていたことなどから、優先順位を下げて後回しにした結果、本プロジェクトでは解決できなかったものです。本プロジェクト終了後の比較的早い時期に、これらを順に解決していきたいと考えています。

    本文の朗読データに対応する
本年3月頃、全54帖の朗読データを無償公開するWebサイトが現れました。現在、この朗読の進行に合わせて、本文の該当箇所のマーカが移動するようなコンテンツの追加を考えています。
この機能の実現には、XMLスタイルシートの変更が不可欠であることが分かっていましたが、今回、第三者でも再編集処理を拡張してアップロードできるという高い拡張性を獲得した結果、この機能の早期実現が現実味を帯びてきました。

 

 

  ページトップへ   

 

 

 


  Copyright(c) Information-technology Promotion Agency, Japan. All rights reserved 2004

 



[1] 当時。現在は段組の幅や行ピッチが追加され、指定方法には微妙な違いがあります。