J-Stageに論文登載をする作業を時々しています。一部にはよく知られていますが、J-Stageは、 学会等に無料でオープンアクセス論文の公開をさせてくれてDOIまでつけてくれるという信じられないくらいありがたいサービスです。 普通はお金を取るものですが、J-Stageは手続きさえ通れば無料です。こんなにありがたいものを 使わない手はない、ということで、すでに私が関係している学会の多くはJ-Stageで 論文をオープンアクセスにしています。（注：J-Stageでは、有料アクセス論文、というか、アクセス制限を かけることもできるようです）。
さて、J-Stageに掲載するのが無料と言っても、論文公開には編集作業が必要で、ややこしい文字や数式を 印刷するのはなかなか大変なので、通常は専門企業に外注ですね。これは一般に、印刷会社が請け負ってくれる ことが多いようです。学術情報XML推進協議会という大変ありがたい名前の会があって、 ここで印刷会社同士で情報交換や勉強会などもしているようです。ここの会員リストに載っている会社に 発注すれば、J-Stageへの登載は問題なくやってもらえます。
しかしながら、外注する金のない学会もあります。そういうところでは、アルバイトで若手に 編集作業をお願いしたり、それもできないときは自分でやってしまったりすることがあります。 そして、筆者は一番ダメなパターンで、アルバイトで引き受けてくれる人を見つけられずに 自分でやってしまうことが結構あります。今回もそういう流れで論文誌を2冊、手がけることに なりました。
J-Stageに論文を載せるためのデータの作成方法は、まず、大別して2種類あります。(1) 書誌情報＋PDF＋全文テキストファイルと、 (2) 全文XMLファイル＋PDFファイル、です。後者は、論文全体をXMLで記述して掲載する方法であり、 全文検索や構造的な検索・データ抽出もできますし、システムが変わった場合にも柔軟に対応できます ので、夢はなかなか広がります。ここでは、JATSという、米国で割と強力に 推進されているようである標準規格が採用されています。
しかしながら、図をリンクするタグを書いたり、そもそも 全体にわたってタグを付けたりするのはなかなか大変ですし、外注する場合も費用がかさむことになるので、 普通は(1)を採用します。
(1) 書誌情報＋PDF＋全文テキストファイル の手法は非常に簡単で、しかも、Webのフォームにちょこちょこ 入力していくだけでも作業が完了します。PDFはワードで作って、全文テキストファイルはワードで 保存する時にテキストファイル形式を選択するだけです。少し高度だけど効率的な手法として、 書誌情報だけをXMLで記述して一括アップロードするという方法も提供されていて、これに 習熟するとさらに便利になります。
というわけで、筆者としては、これまでは、あまりこの作業に時間を使ってしまうと他の仕事が止まって しまうので、基本的に (1) で作業をしてきていました。本年9月に、「全文XML作成ツール」を リリースしたという情報はキャッチしていましたが、人柱になりそうだしな…と思って遠巻きに 眺めておりました。しかしながらその後、その筋の専門家である知り合いに、ちょっとやってみては どうか、というお誘いを受けて、なぜか地雷を踏んでもいいような気がしてしまって、結果として 見事に踏み抜いてしまったのでした。
筆者がXMLにそこそこ通じていることは、このブログの読者の方々はご存じかと思いますが、 実は、JATSの開発に携わったWendell Piez氏を日本に招待して講演していただいたことがあり、 JATSとTEIのコンセプトの違い、のような話もこってりと教えていただいたこともあり、 もちろん、最初にJ-Stageを使い始めたときにも一応全文XMLは試してみていたので、 まあ大丈夫かな…と、安易にも思ってしまったということもありました。
今にして思えば、 ツール開発1つ分か論文1本分くらいの時間を費やしてしまったので、本当に失敗だったと 思っていますが、結果として作業に慣れてしまったということと、ここまでやったのだから その試行錯誤を残しておくことで、後に続く方々（あまり続くことはおすすめできませんが）が 少しでもワークライフバランスのとれた生活をできたり、他の生産的なことに時間を使ったり できればということで、少し細々書き残しておきたいと思います。
さて、全文XML作成ツールは、ワードやLaTeXのファイルを読み込んでJATS/XMLに変換してくれるという ものです。それだけ聞くと非常に便利そうです。以下にマニュアルもあります。
https://www.jstage.jst.go.jp/static/files/ja/documentToJatsManual.pdf
おそらく、特に難しさのない形式で、ワードの文書を完全に作ることができれば、 修正の必要もあまりなく、割とさくっとJATS形式のデータを作って、手順通りに アップロードして終了、ということなのだろうと思います。試験用に作った 論文ファイルを使って検収したときには、完璧に動いたのかもしれません。
しかしながら、そうは問屋が卸さない、というか、とにかく、論文というものは 細々と例外的な事象が発生します。そこで、この「全文XML作成ツール」では、 XML編集機能、というのが用意されています。ただ、XMLの現代的な 利便性を十分に提供できていない感じのもので、正直、これを使っていたらXMLの編集作業上のメリットをあんまり享受できません。そこで、早々に諦めて、これをOxygen XML Editorに コピペして、修正作業を始めました。…と、この手順がまたあとから問題になるわけ ですが、それは後述しますので、ここで読むのをやめて真似しないようにご注意ください。 とにかく、修正作業です。このコピペしたファイルはサーバ上のDTDファイルと 紐付けられているのでこのままではvalidationがうまくできません。さてどうした ものか…と、ちょっと探してみると、ちゃんと、RelaxNGのスキーマが用意されてる じゃないですか。って、当たり前ですね。J-Stageで採用しているのは最新の1つ前の バージョン1.1 ですが、そのスキーマも公開されているので、それをダウンロードして、 適当なディレクトリに置いて、作業中のファイルにこのスキーマを割り当てると…、これで 作業は進められることになりました。
さて、着々と進めていって、なんとかできたので、アップロードです。さて、ここで あれれ？となります。アップロードしたXMLファイルが、J-Stageサーバ上でHTML として閲覧できるように変換されるのは、30分に1度、0分と30分、なのだそうです。 書いてみてできあがったものを確認するにはそのタイミングをまたなければいけない ようで、まあ、サーバの負荷を上げすぎないためにはそういうことも大事か…と 思いながら、しばらく待っていたりしていたわけです。で、あれれ？JATSでは エラーにならないのに思ったとおりに表示されないぞ？ということになって、 書き方を少し変えて試してみます。あれれ？と思って…というのを4回繰り返せばもう 2時間溶けます。仕方がないので、J-STAGE全文XML利用者向けマニュアル というのを見てみると、確かにできると書いてあるように見えるが…？
という感じで、どんどん時間が溶けていきました。
そういえば、J-Stageに問い合わせればいいのか！と思って電話番号を探すと、 メールでしか問い合わせを受け付けていないということで、メールを出してみる…と… 大体、前の晩に送ったものが翌日の夕方くらいにお返事をいただけるようなペースです。
- 我「これこれこういうことをしたいのですが」
- J「J-StageはJATSに準拠しているのでJATSに沿ってデータを作ってください」
- 我 「JATSのスキーマはOKと言ってますが」
- J「このマニュアルを見てやってください」
- 我「このマニュアルのここに書いてあるようにやっているのですが」
- J「そのマニュアルはJATSの翻訳であって、J-Stageは全部対応しているわけではないです」
…要約するとこういう風な感じのやりとりが6日間かけて行われたようです。
全文XMLを広めるために公金を投入して開発した全文XMLツールのサポートがこういう感じで 一体全体どういうワークフローを想定していたのか、利用者が殺到してサポートが返事を なかなかできない状況なら大当たりということでよかったのではないかと思いますが、 何かこう、これは本当に大丈夫なんだろうか、と思わなくもなかったですが、そんなこんなで、 色々な学びを得ながら、やっとこさっとこ、全文XMLによる論文公開はできたのでした。
やっていくなかで特に気になったのは、上にも書きましたが、特に2点です。
- 全文XML作成ツールのXML編集機能の不十分さ
- J-StageでのXML⇒HTML変換ルールの確認に非常に時間がかかる
まず、2. に関しては、全文XML作成ツールにvalidation / HTMLプレビュー機能がついているので これで大丈夫かと思ったら、よく確認してみると微妙に挙動が違うようです。今のところ 明確に確認できているのは、<ref-list>が2つある場合に、こちらのHTMLプレビュー機能 だと表示されないけど本番サーバだと表示できる、ということくらいでしたが、そもそも 変換スクリプトが異なるわけですし、JATSもあれで意外とゆるゆるなので、ゆるい 規格に大がかりなシステムを対応させるには細かいローカルルールを色々決めねばならず、 それを厳密にドキュメント化しないと2系統のシステムで同じ変換スクリプトを 走らせることができない…という大変面倒なことになっているようです。まあ、 常に同じ変換スクリプトを使うようにシステム設計を工夫すればいいだけのことでは あるのですが、それはJ-Stageの開発部隊さん達に頑張っていただきたいところです。 ということで、一般の編集作業者には、全文XMLがどういう風にWebページ上で表示されるかを 確認するためには、修正するたびに30分待ち、ということになるようです。もちろん、 ダミー論文を作っていろんなパターンのタグ付けを試してみて、その情報を手元に 蓄積していくという方法はあり得ますし、仕事でやるならそれくらいはどこでも やっていて、それなりに蓄積をお持ちなのだろうと思いますが、とはいえ、全文XML 作成ツールのようなものを作るからには、かなり門戸を広げようということなのでしょうし、 それで30分ごとでなければ修正結果を確認できないというのはなかなか厳しいものだと 思ったところでした。
一方、1. の方については、これはやや謎のツールで、validationしてくれるのと HTMLプレビューをしてくれる点は大変ありがたいのですが、上述のように、HTMLプレビューは 「ちょっと違う」みたいなので、何がどう違うのかという情報も提供していただきたい ところです。とはいえ、公金で働いている方々の大事な時間をそういうことを確認するために費やして しまうのも納税者としてはもったいないような気がするので、どちらかと言えば、 私のようなユーザからの情報をきちんと集約して、みやすい形で提供していただけると ありがたい、と思うところです。また、一番謎なのは、最近のXML Editorだと、 指定したスキーマに基づいて、その場に必要なタグを提案してくれたり、文字列を 選択してタグ付けすればそれで開始・終了タグを前後に付与できる、といった機能がついている ものですが、このツールが提供しているのは、「スニペット」と呼ばれるまとまったタグの一括入力だけで、 そのスニペットはどこにでも入力できてしまう…という…これが何か変であるということは XMLエディタをある程度使っている人にしかわからない話かもしれないのですが、この状況だと 作業効率の向上にはあまり役立ちません。この機能を偉い人の前でプレゼンする時にはとても 便利なツールのように説明することはできると思いますが、実際のところ、この機能だと、 おそらく、JATSのタグの階層構造を完全に覚えて居ないと使いこなせません。しかし、 今時のXML Editorは、それを覚えて居なくてもデータ作成できるというのが売りなので、 そこを実装できていないというのはどういうことなんだろうか、というのが、謎、 というか、大変気になったところでした。その種の機能は、知り合いで最近VSCodeのプラグインとして実装した 人がいて、一人で作っちゃったみたいです。
もしかしたら、色々難しいことがあってそういう便利機能の実装ができないのかもしれませんが、 もしそうだとするなら、XML編集機能に関しては、これ以上投資をするよりはむしろ、最初から 外部エディタを使うことを前提としたワークフローにしてしまった方がよいのではないか、 という気がしております。いわば、公金でXMLエディタを作るようなものなのですが、普通に 考えると、そういう部分は汎用的ツールで対応できるので、もう民間とかオープンソースのもの等にまかせて、 J-Stageに特化した部分に費用をかけていただくのがよいのではないか、という気がしたところでした。
というわけで、以下、今後J-Stageで全文XMLツールを使ってみようという方に向けて、今回気がついた 注意点を挙げていきたいと思います。
全文XML作成ツールで作成したXMLファイルは、XML編集機能からコピペして使ってはダメで、 一度エクスポートしてzipファイルを入手してから、その中にあるXMLファイルを編集すべし。 （そうでないと画像ファイルとのリンクが壊れるので）
全文XML作成ツールのXML編集機能は、J-Stage用のvalidationにはある程度使えるが、 原理的には本番サーバのXML形式チェックと同じではないので注意しながら使いたい。もし本番サーバとの違いに気づいたら、とりあえず J-Stageセンターに報告しておくといいかもしれない。（あとで情報集約して公開してくれることを期待して）
全文XML作成ツールに読み込ませる前に、ワードのスタイルはなるべくマニュアル通りに作っておいた方が後が楽。ワードを 著者にテンプレで配っているならその段階からスタイルをあわせておいて著者にもそれを徹底すると楽だと思われる。
書誌情報自動タグ付けツールがあって、ぴたっとタグ付けされる時があって感動するが、 ミドルネームのある著者が入っている書誌情報は大抵失敗する。 失敗した挙げ句、JATSとしてもエラーになってしまうことがあるほどなので要注意。以下、失敗しやすい パターンをいくつか。
ミドルネームのある著者名（再掲）
著書。出版社・出版地はとれないことが多い。
URLにアンダーラインがついているとアンダーラインタグしかつけてくれない時がある
<source>は比較的失敗しやすい。
中国人のアルファベット名は認識に失敗しやすい
５. その他、気をつけて置いた方がよい点。
5-1. J-STAGE全文XML利用者向けマニュアル には書いてあってもできないことがあるようだ。J-Stage側でも十分に把握できていない可能性があるので（これは仕方がないことなのだ）、 気がついたことがあればJ-Stage センターに連絡して情報を集約していくのがよいと思っている。J-Stage側でも集まった情報は積極的に 開示していただけるとありがたい。積極的に開示されるとわかれば、情報も集まりやすくなることが期待されるので、その意味でも ぜひともお願いしたい。とりあえず以下にリストしておくと、
- 文字修飾という項目が各タグの説明に書いてあるが、J-StageのHTML上では有効になるものとそうでないものがあるようだ。たとえば
<list><list-item><label>
における文字修飾として
<bold>,<italic>,<monospace>,<overline>,<roman>,<sans-serif>,<sc>,<strike>,<underline>,<sub>,<sup> ,<ruby>,<chem-struct>
が記されているが、少なくとも<bold>は実は効かないとのことだった。
5-2. もちろん、JATSのスキーマもまったく同様に実装されているわけではないので、JATSスキーマで手元で記述する場合にはその点も注意が必要だ。今のところ気がついた点を挙げると
JATSスキーマだと<source> や<year>は<ref>の中に複数書くことが許容されているがJ-STAGEだとエラーになる。
JATSスキーマだと<year>の中は数字以外の文字が入ってもエラーにならないが、J-STAGEだとエラーになる。
あとで追記します。
６. というようなことで、全文XML作成ツールのvalidation機能はある程度使えるようなので、外部のXML EditorにJATSスキーマを割り当てて そちらで書きつつ、ときどき全文XML作成ツールの編集機能に貼り付けて validationしてみる、というくらいが、効率を考えると妥当な線なのでは ないか、というのが現時点での暫定的な結論です。
総合的にみて現在おすすめのワークフロー
というわけで、J-Stageで全文XML登載をするにあたって、当方でおすすめの作業の流れは、大体以下のような感じです。
ワードで、全文XML作成ツールに沿ったスタイルを設定する。
全文XML作成ツールにワードを読み込ませてXMLファイルを作成し、それを「エクスポート」する
エクスポートされたzipファイルを開いてXMLファイルをXML エディタ（Oyxgen XML Editor（有料）やVisual Studio Code + Scholarly XMLプラグイン（無料）等）に読み込ませてJATSスキーマを割り当てて編集作業をする。
作業中は、全文XML作成ツールのXML編集画面を開いておき、適宜XMLエディタで作業中のソースを貼り付けてvalidationやHTMLプレビューを行う。
一通り作業が終わったら、zipでまとめなおしてJ-Stageに一括アップロード。
という感じでしょうか。あとは、みなさまのご健闘をお祈りいたします！
終わりに
細々とJ-Stageのことを書いてきましたが、これは以前このブログでも日本学術会議の提言として採り上げた、将来の日本の学術情報流通の、おそらく要になるのがこの J-Stageであると思われるからです。誰がどういう風にこのことに関わり続けていくのか、今もってよく見えないところはありますが、 すでに存在するJ-Stageとは別にまた一から作り始めるということはさすがにないと思われますので、今後のためにはJ-Stageの状況を 皆でなるべく共有して、皆で改善に協力できるような流れを作っていく必要があるのではないか、と思ったところだったのでした。
（実は、XMLファイルをJ-Stageにアップロードして、HTMLに変換されるのを待ちながらこのブログ記事を書いていたのですが、いっこうに変換されないのは土曜日は変換サーバがお休みということなのでしょうか？そこら辺の情報もアクセスしにくくてなかなか難しいなと思っております。今のところは、専門企業向けのサービスといった趣ですね。）
（と思ったら、朝5:30の時点で、HTMLに変換されたのを確認しました。ほっとしました。深夜は自動化スクリプトも休みなんでしょうかね・・・？）
