図1： Xa2Tシステムの全体構成
白木澤佳子
科学技術振興事業団
〒102-0081東京都千代田区四番町5-3
Tel:03-5214-8402 Fax:03-5214-8420 E-mail:shirokiz@jst.go.jp
Yoshiko SHIROKIZAWA
Japan Science and Technology Corporation
5-3 Yonbancho Chiyoda-ku
Tokyo 102-0081
Meanwhile XML (eXtensible Markup Language) technologies draw attention as the means of utilizing the integrated data in data distribution, data exchange and database management. This report is about the experimental model of integrated electronic journal distribution system that we developed by applying XML technologies.
そのような中でドキュメントデータの蓄積、流通、交換を行なうシステムには新たな要求 が発生しつつある。例えば、他のネットワークシステムとデータ交換を効率的に行なうこ とや一度電子化したデータを低コストで多目的に応用するといった機能である。これらの 機能は、データ形式に高い互換性が要求され、その処理を行なうための様々なリソースが 体系的に用意されている必要がある。今回は、この要件を現時点で最もよく満たしている と思われるＸＭＬ技術を用いて、電子ジャーナル流通システムに対するその応用性を調査 実験するためのモデルシステムを開発した。本システムにおいては、学術論文の執筆から 投稿、データベースへの格納、公開、検索といった一連の電子ジャーナル処理機能をＸＭ Ｌ技術を用いて構築することにより、その利用法、問題点などについて調査を行なった。 特にＸＭＬ技術の特徴である他システムとのデータ交換、単一データの多目的利用と言っ た技術の調査が重点的に行なえるサービス形態を想定し試作及び運用実験を行なった。そ の他にも、既存データとの互換性を確保するための試みとして各種コンバータの試作開発 や数式データのレンダリング機能実験など周辺機能の調査も行なっている。これら一連の 機能により構成されたモデルシステムを 先進的XML応用技術調査実験：XML Advanced and Applied Technologies Experimentとし、その頭文字を取り、Xa2T（ザート）と命名 した。Xa2Tシステムは図1のような構成になっている。
図1： Xa2Tシステムの全体構成
仮に学術論文の出版公開および流通の業務形態の移行プロセスを三段階に分けてみると。
第一段階：紙、印刷雑誌を中心としたもの。
第二段階：オンライン化・電子化を行なったもの。独立したサービス提供。
第三段階：ネットワーク環境、標準化データに対応した分散・共有システム。
冒頭で述べたJ-STAGEはこの第二段階にあたるものである。Xa2Tシステムはこの第三段階 を担うシステムを開発するための調査実験プロジェクトである。現行のシステムの問題点 などを考慮し、それを解決するための様々なサービスやツールを開発・提供し、従来の資 産を生かしつつ、その目的を果たすために最も適切なシステム形態と応用技術について調 査を行なった。
表1： Xa2Tシステムを構成する技術要素
Xa2Tシステムにおけるメタデータ定義は２種類ある。一つは、サーバー間通信の実験を行 なうパートナーである米国イリノイ大学の電子図書館システム「DeLIver」の開発チーム が設計したメタデータセットを参考にして作成したものである。その開発呼称を 「Bronco」とし、その内容は表２に示されるようなエレメントセットで構成されている。 「Bronco」は広範囲な素材に対応可能なように数多くの項目を含んでおり、その利用法に おいても柔軟な対応が取れるように構造定義も特に行なっていない。さらに「Bronco」は ドキュメント系メタデータの標準とも言えるダブリンコアを包含しており、それに基づく 処理にも対応できる。
表2： メタデータ「Bronco」のエレメント表
もう一つのメタデータ定義は論文検索機能に必要とされる最小限の構成にまとめたエレメ ントセットで、その開発呼称を「Unicorn」とした。「Unicorn」は表３に示すエレメント を有し、図２に示すような構造を定義付けている。「Unicorn」はXa2Tシステム内部での 論文管理、情報検索、外部との情報交換という明確な目的に基づいて設計されている。そ のため、エレメント構成を必要なもののみを残してスリム化し、その意味付けもより具体 的に決めてある。
表3： メタデータ「Unicorn」のエレメント表
図2： メタデータ「Unicorn」の概念構造図
「WhiteHorse」は約120種類のタグから構成されている。これらのタグは可読性の向上を 図るために可能な限り表記をフルスペルを用いるようにしてある。（例：ISO12083では <aff>をしているのを「WhiteHorse」では<affiliation>とする）「WhiteHorse」の第二階 層までの概略構造図を図３に示す。「WhiteHorse」では最上位を表すタグである <article>の直下に5つのタググループを有する。
図3： XML形式論文文書定義「WhiteHorse」の概念図
１．<front>
<front>タグはその論文の書誌事項、ヘッダデータが所属する。
論文のタイトルや著者に関する情報、アブストラクト、キーワード
などがここに格納される。
２．<textbody>
ここには論文本体が格納される。段落分けなどにも対応。
３．<appendixgrp>
ここには追加情報が格納される。
４．<resource>
文字以外のデータグループ。論文内の画像、表、数式、化学
データなどに関する情報を格納する。
５．<back>
謝辞や文献情報を保持するグループ。
これら５つのタグはＸＭＬ形式で論文を記述する上での基本構造であり、それぞれがさら に細かな情報エレメントによって構成される。
図4： XML形式論文作成支援システム 動作画面
このエディタの基本的な操作方法は、
１．あらかじめ別のソフトで作成した論文草稿をコピーペーストし、[エディット部]
の所定の位置にあてはめてゆく。または一括して草稿を読み込みそれを各項目に
振り分けて行くという方法によりＸＭＬ形式論文の作成を進める。
２．著者名のように複数個のエレメントが存在する項目の追加は、[ツリー部]で
マウスを右クリックし、それを行なう。
３．入力の表示は[メニュー部]のリロードボタンをクリックすることで[HTML部]に
表示される。
４．[メニュー部]のファイル−保存を選ぶと「WhiteHorse」文書定義に従った
ＸＭＬ形式の論文データが保存される。
論文の作成そのものをまったく執筆開始の段階から行なうことを主流としてとらえず、あ らかじめ草稿レベルのデータを他のアプリケーションにより作成させ、最後にこの支援ツー ルによりXML形式論文を作成するというのがXeArの狙いである。つまり、あくまでも論文 にXa2T用XML文書定義「WhiteHorse」を適用させることを支援するのが目的であり、XML形 式論文の汎用ワードプロセッサではない。
XeArはいくつかの特徴的な機能を有している。例えば、引用文献の末尾リストと本文内の 参照位置のリンクを自動生成する機能や、ユーザーが任意に作成した属性タグの挿入、外 部参照データ（画像データなど）の直接挿入などである。将来的には執筆から査読審査、 修正、出版社など論文の最終的な公開までの作業の流れの中で係る作業すべてに対応可能 なアプリケーションに発展させることも検討する。
図5： ＸＳＬの動作概念図
Ｗ３Ｃ（World Wide Web Consortium）ではＸＳＬの仕様を、データ変換を行なうＸＳＬ Ｔ（XSL Transfomation）と表示整形を行なうＸＳＬ−ＦＯ（XML Formatting Object） の2つから構成するとしている。本システムにおいてはその両方の機能を検証するために 電子ジャーナルを表示するためのＸＳＬを試作した。今回試作したＸＳＬは以下の3点で ある。
１．論文の全体を整形してＨＴＭＬ化してブラウザで表示する。（図６）
２．論文の抄録情報のみを抜き出しＨＴＭＬ化してブラウザで表示する。
３．論文の全体を整形してプリンタ印字用にＰＤＦ形式で出力する。
図6： 論文表示の例
このうち、１および２はＸＭＬソースをＨＴＭＬに変換するＸＳＬＴの技術により処理を 行なう。また３はＸＳＬの表示整形機能であるＸＳＬ−ＦＯによって処理を行なう。いず れもＨＴＴＰサーバーを通じてインターネット経由でクライアントへ電子ジャーナルデー タを送信する仕組みの中で動作することを想定して試作をおこなった。この場合、基本的 にＸＳＬＴとＸＳＬ−ＦＯの処理の流れはそれぞれ図７に示すような形となる。
図7： Xa2TシステムにおけるＸＳＬ処理体系
サーバー側の構成は、LINUXコンピュータおよびＨＴＴＰサーバープログラムとして Apacheを導入、それに加えてＸＭＬ関連の様々な処理をおこなうServletであるCocoonと Servlet動作に必要なモジュールJDK(JAVA2SDK)およびApache JServを導入してある。ＸＭ Ｌデータはクライアント側からの読み出し要求に従い所定のＸＳＬを呼び出して変換を行 ないクライアントへその変換結果を送信する。ＸＳＬはCocoonに含まれるＸＳＬプロセッ サであるXalanによって処理される。ＸＭＬをＨＴＭＬ化して表示する2種類のＸＳＬ（論 文全体表示および論文抄録表示）はCocoonを通じて動作し変換結果をクライアントに送信 する。また、ＰＤＦ形式の出力に関しては、一度ＸＳＬ−ＦＯプロセッサによって処理可 能な形式のＸＭＬソースを生成し、それをＸＳＬ−ＦＯプロセッサがＰＤＦ形式のデータ に変換しクライアントへ送信する。なお、この仕組みではXSLはダイナミックに選択され ることになるが、通常XSLに対する宣言はXML内に静的に記述されていなくてはならない。 そのため、今回は静的に宣言されるXSLファイルには渡された引数に従い、指定された XSLファイルを用いるように再宣言するという動作を構成した。
図8：ＭａｔｈＭＬのサンプルリスト（左）およびレンダリング結果（右）
このようにＭａｔｈＭＬはXa2Tシステムの中で全く別の処理体系の文書定義を有している。 このため、ＭａｔｈＭＬで記述された情報が含まれているＸＭＬ文書を処理するためには、 それ専用の処理を付加する必要がある。その手法としては、
１．ＨＴＭＬおよびＣＳＳ(Cascading Style Sheet)、ＪａｖａＳｃｒｉｐｔなど
を用いてブラウザ上で表示可能なデータを供給する。
２．クライアント側でＭａｔｈＭＬをサポートした拡張機能（Plug-INなど）を
ブラウザに組み込む。（IBM techexplorerなど）
これらの方法の問題点は、複雑な数式処理をＣＳＳやＪａｖａＳｃｒｉｐｔで対応するの には限界があることやクライアント側の環境の統一性に裏付けが乏しく拡張機能の導入を 前提としたサービスの提供の有効性に疑問があることである。いずれ数式処理はクライア ント側で標準的に可能になるものと思われるが、将来に渡っても旧環境への対応を考慮す るならばほぼすべてのブラウザが表示を可能としているＪＰＥＧ画像にＭａｔｈＭＬを変 換することによりそれは解決できる。今回は、ＭａｔｈＭＬをＪＰＥＧ画像に変換する仕 組みを調査し、その機能を共有サーバーを通じて共同利用できるオンライン数式画像生成 機能を試作した。本機能の構成と処理の手順を図９に示す。
図9： オンライン数式画像生成機能の構成と処理手順
本システムが動作するXa2T-2サーバーの構成は、Windows NT4.0、Microsoft Internet Information Server、そしていくつかのActiveX componentから成っている。この図に示 されるように、ＭａｔｈＭＬをレンダリングしているのはXa2T-2サーバー側のActiveXコ ンポーネントである。ＭａｔｈＭＬのソースが最終的にＪＰＥＧ画像となってクライアン トに返される手順は以下の通りである。
１．クライアント側のブラウザ画面からＭａｔｈＭＬの部分のみを入力し、サーバー
へ送信する。
２．サーバー側のＣＧＩがそれを受け取りTechExplorerのActiveXコンポーネントを
用いて数式レンダリングを行なう。その結果は仮想的にサーバー側のスクリーンに
表示される。
３．サーバー側のスクリーンを同じくActiveXコンポーネントを用いてメモリに
取り込みそれをファイルに記録する。
４．ＣＧＩプログラムは最終的にそのファイルへの表示リンクをしたHTMLファイルを
生成しクライアント側に返す。
以上のような行程によりMathMLはレンダリングされた数式JPEG画像として出力される。
１．ＴｅＸ：ＴｅＸとは、スタンフォード大学のDonald E.Knuth氏によって作成された
文書組版ソフトウェア体系である。テキストベースのデータで構成され、その
内容はドキュメントの実データと体裁情報が含まれている。論文の執筆者には
古くから愛用され現存のデータの量も抜きんでて多い。
２．ＭＩＦ：Maker Interchange Formatの略。Adobe社の製品FrameMaker+SGMLなどで
用いられる文書の保存形式。独自のスタイルではあるが大部分をテキストデータ
形式で記述し、基本的に実データとそれを表示する際の体裁情報によって構成する。
３．ＲＴＦ：Rich Text Formatの略。Microsoft社が提唱した文書ファイルの
フォーマット。ＭＩＦと同じく実データと体裁情報から成るファイル形式。
テンプレートと呼ばれる体裁情報と意味付けの定義を対応させる仕様を用いる
ことにより単に体裁情報だけではなく固有の意味付けをデータに与えることが
可能である。
４．ＳＧＭＬ：Standard Generalized Markup Languageの略。マークアップ言語の
ひとつで、汎用マークアップ言語規約ともいう。ISO8879として規格化されて
いる。ＸＭＬはＳＧＭＬの文書定義の曖昧さを排除しオンライン流通の仕様を
加えたものであり、ほぼ兄弟関係にあるといってもよい。
ＸＭＬデータと各種フォーマットデータとの変換アプリケーションプログラムの開発にあ たって、最も問題となるのは、ＳＧＭＬを除く3つのデータフォーマットが、表示・印字 を主目的とした体裁情報中心の仕様であるということである。ＸＭＬはその特徴として、 データ本体から体裁情報を分離することによりデータの性質に基づいた処理を可能とし必 要に応じた体裁処理を随時あてはめることが可能となった。このようなＸＭＬ形式のデー タとＴｅＸ、ＭＩＦ、ＲＴＦの各データように体裁情報を中心に取り扱うデータとの変換 を行なうのは非常に困難である。無論、体裁情報からデータの性質を推測することも不可 能ではない、例えば、「一番最初に出てくる24ポイント、ボールド表記の行を論文タイト ルとする。」というような条件設定に基づいて変換を行なうというような手法が無いわけ ではない。しかしこの手法ではそのような条件が元来データの性質を決めることを目的と して設定されている保証はなく、同じ体裁条件が別の意味で用いられている可能性は否定 できない。ＲＴＦのテンプレート仕様のように、中には各体裁情報に名前をつけることで 属性情報を持たせることが可能なものもある。しかし、残念ながら既存データでそれらが 有効に活用されている例はさほど多くはない。このような観点から今回開発したアプリケー ションプログラムの最終的な形態を下記にまとめる。尚、すべてのプログラムに必要な条 件としては以下の３点である。
・コマンドラインで入力し動作させる方式を取り、ＧＵＩなどを持たせないこと。
これにより単一アプリケーションとして実行させるだけでなく、ＣＧＩなどからも
呼び出すことができる。
・ＸＭＬデータは本プロジェクトで策定した文書定義「WhiteHorse」に従ったデータ
を対象とする。
・開発言語は互換性を考慮してＰｅｒｌ言語を用いるのが望ましいがそれ以外の言語を
用いる場合は、Windows環境での動作を保証する。
１．ＴｅＸコンバータ
コンバータアプリケーションの仕様範囲は、約5000件の論文サンプルの中から
無作為に抽出した40論文を対象に完全な変換が双方向で可能であることとした。
吸収できない仕様の情報が紛れていた場合はコメントアウトし無効情報とする。
但し、何らかの形で再利用する可能性もあるので、削除はしない。
ＴｅＸは一定の表示出力に対する記述が何通りもありえる。そのため一度独立
した中間フォーマットであるＤＶＩ（DeVice Independent）ファイルに変換し、
それを変換の対象とすれば少なくとも記述を一本化することが可能である。
本件は実験終盤に明らかになったので実際には適用していない。
２．ＭＩＦ・ＲＴＦコンバータ
基本的にこの2つのデータ形式の場合は、仮想的な学会誌の投稿規程に従った
テンプレートを作成、それに則り記述された論文を変換の対象とした。これらの
情報には画像データなども含まれている。その場合は切り出して別のファイルと
して保管する。
３．ＳＧＭＬコンバータ
ＳＧＭＬはＸＭＬとの親和性が高く、変換の難易度はそれほど高くない。今回は
ＸＭＬ側は「WhiteHorse」に従ったものとなっているが、ＳＧＭＬコンバータ
では変換の中心にＸＳＬＴを用いるため、ＸＳＬＴを各種用意することにより
様々な形式のＳＧＭＬを入力して変換することが可能になる。
Xa2T-1は投稿を受付、それを蓄積し公開する。Xa2T-1サーバーを通じてクライアントは Xa2T-1内に蓄積された論文を検索、表示させることができる。さらに、外部のネットワー クにあるサーバーを検索することも可能である。今回はＸＭＬによるドキュメントデータ ベースの研究プロジェクトのパートナーである米国イリノイ大学グレンジャー技術図書館 の研究チームが開発中のDeLIverサーバーに対して同様に検索をかけることを可能とした。
また、引用リンクの自動生成の場合は、投稿から蓄積まで以下の手順で行なう。（図１０）
図10： Xa2T-1サーバにおける相互リンク作成の手順
１．ＸＭＬ形式論文作成支援ツール（ＸｅＡｒ）から作成された論文が投稿される。
このとき、投稿された論文からは書誌事項であるメタデータが抽出されデータ
ベース（PostgrSQL）に格納される。実際の論文データはXMLファイルのまま保存
される。
２．XMLファイルから引用文献情報を抽出する。
３．米イリノイ大学DeLIverシステムの検索用クエリとして抽出データを整形する。
４．クエリを送信する。
５．見つかった場合はリンクを張るための情報を送信してもらう。
６．受信した情報を論文に格納。
７．引用したことをDeLIverに通知。
８．DeLIverからメタデータの要求を受信。
９．リンクを張った側の論文のメタデータを送信。
また、DeLIver側から引用のための問い合わせがあった場合にも双方の受動の立場が入れ 替わるのみで同様の動作を行なう。
このように外部サーバとのメタデータの交換により、相互のリソースを効率的に、かつ自 動的に関連付けることが可能である。
今回の調査およびモデルシステムの開発と運用についてＸＭＬを主たるテーマとして選択 した理由はここに述べるようにジャーナルデータの統合化された流通システムを考慮した 場合にそれに最も適合した技術だったからである。Xa2Tシステムは今回の試作におい て特に基礎的な部分でのモデル化を図った。たとえば、投稿の手順は執筆してそれをサー バーにアップロードした瞬間から公開されるようになっているが現実にはそのようなこと は有り得ず、査読や審査などのいくつかのプロセスを経て公開される。今後はそのような 業務フローも充分に調査し、ＸＭＬ技術のさらに高度な応用技術も導入して行くことを考 慮したい。冒頭で述べた電子ジャーナルシステム「J-STAGE」は既に多数の学会誌の格納 を果たし、安定したサービスを供給している。しかしながらその将来性について考察する と外部のシステムとの情報交換や効率のよい業務フローの反映といったことが低コスト・ 短期稼動で実現が可能かどうかという面で、限界点がさして遠くない将来に訪れる可能性 が高いと言わざるを得ない。今回行われたXa2Tシステムの開発と運用実験で得られた 技術は今後「J-STAGE」システムにも積極的に応用して行く予定である。
[2]イリノイ大学の電子図書館システム DeLIver. http://dli.grainger.uiuc.edu/deliver/about.htm
[3]University of Illinois Digitial Library Initiative (IDLI) Metadata Schema Description. http://dli.grainger.uiuc.edu/iso11179/IDLI_ISO11179.xml
[4]The World Wide Web Consortium(W3C). http://www.w3.org
[5]ISO 12083 Information from XMLXperts Web site. http://www.xmlxperts.com/12083.htm
[6]Dublin Core参照記述. http://www.DL.ulis.ac.jp/DC/
[7]Dublin Core Metadata Initiative. http://purl.org/DC/
[8]小原満穂「米国の電子ジャーナル事情」、情報管理、42(11), 942-950, 2000. http://johokanri.jst.go.jp/e_journal/data/v42/n11/a04/index.htm
[9]時実象一「電子ジャーナルの現状と動向」、情報管理、43(5), 391-410, 2000. http://johokanri.jst.go.jp/e_journal/data/v43/n05/a02/index.htm
[10]時実象一「学術系電子雑誌の現状」、情報管理、41(5), 343-354, 1998. http://johokanri.jst.go.jp/e_journal/data/v41/n05/a02/index.htm
[11]白木澤佳子「学術情報のためのXMLツールの開発」情報科学技術研究集会, 37, 7-12, 2000.
[12]吉田幸二「J-STAGE:『科学技術情報発信・流通総合システム』電子ジャーナル作成と インターネットによる流通」ディジタル図書館. No.16. http://www.dl.ulis.ac.jp/DLjournal/No_16/7-k3yoshid/7-k3yoshid.html
[13]杉本重雄「メタデータについて-Dublin Coreを中心として-」情報の科学と技術 49(1), 3-10, 1999.
[14]ハーンク, デレク J「電子出版で百倍になる可能性−5年後にはもう冊子体なし (?) 学術出版の世界−」情報管理, 42(10), 887-891, 2000. http://johokanri.jst.go.jp/e_journal/data/v42/n10/b09/index.htm