新規開発されたJ-Stageの全文XML作成ツールにお付き合いした話（その1）

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点です。

1. 全文XML作成ツールのXML編集機能の不十分さ
2. 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ツールを使ってみようという方に向けて、今回気がついた 注意点を挙げていきたいと思います。

1. 全文XML作成ツールで作成したXMLファイルは、XML編集機能からコピペして使ってはダメで、 一度エクスポートしてzipファイルを入手してから、その中にあるXMLファイルを編集すべし。 （そうでないと画像ファイルとのリンクが壊れるので）

2. 全文XML作成ツールのXML編集機能は、J-Stage用のvalidationにはある程度使えるが、 原理的には本番サーバのXML形式チェックと同じではないので注意しながら使いたい。もし本番サーバとの違いに気づいたら、とりあえず J-Stageセンターに報告しておくといいかもしれない。（あとで情報集約して公開してくれることを期待して）

3. 全文XML作成ツールに読み込ませる前に、ワードのスタイルはなるべくマニュアル通りに作っておいた方が後が楽。ワードを 著者にテンプレで配っているならその段階からスタイルをあわせておいて著者にもそれを徹底すると楽だと思われる。

4. 書誌情報自動タグ付けツールがあって、ぴたっとタグ付けされる時があって感動するが、 ミドルネームのある著者が入っている書誌情報は大抵失敗する。 失敗した挙げ句、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登載をするにあたって、当方でおすすめの作業の流れは、大体以下のような感じです。

1. ワードで、全文XML作成ツールに沿ったスタイルを設定する。

2. 全文XML作成ツールにワードを読み込ませてXMLファイルを作成し、それを「エクスポート」する

3. エクスポートされたzipファイルを開いてXMLファイルをXML エディタ（Oyxgen XML Editor（有料）やVisual Studio Code + Scholarly XMLプラグイン（無料）等）に読み込ませてJATSスキーマを割り当てて編集作業をする。

4. 作業中は、全文XML作成ツールのXML編集画面を開いておき、適宜XMLエディタで作業中のソースを貼り付けてvalidationやHTMLプレビューを行う。

5. 一通り作業が終わったら、zipでまとめなおしてJ-Stageに一括アップロード。

という感じでしょうか。あとは、みなさまのご健闘をお祈りいたします！

終わりに

細々とJ-Stageのことを書いてきましたが、これは以前このブログでも日本学術会議の提言として採り上げた、将来の日本の学術情報流通の、おそらく要になるのがこの J-Stageであると思われるからです。誰がどういう風にこのことに関わり続けていくのか、今もってよく見えないところはありますが、 すでに存在するJ-Stageとは別にまた一から作り始めるということはさすがにないと思われますので、今後のためにはJ-Stageの状況を 皆でなるべく共有して、皆で改善に協力できるような流れを作っていく必要があるのではないか、と思ったところだったのでした。

（実は、XMLファイルをJ-Stageにアップロードして、HTMLに変換されるのを待ちながらこのブログ記事を書いていたのですが、いっこうに変換されないのは土曜日は変換サーバがお休みということなのでしょうか？そこら辺の情報もアクセスしにくくてなかなか難しいなと思っております。今のところは、専門企業向けのサービスといった趣ですね。）

（と思ったら、朝5:30の時点で、HTMLに変換されたのを確認しました。ほっとしました。深夜は自動化スクリプトも休みなんでしょうかね・・・？）

Web動画をアンロックする：IIIF動画アノテーションのご紹介

追記：動画に色々描き込んだりするのはYou○ubeやニコニ○動画でもできるんじゃないの…？と思われる人も多いと思いますが、 大きな違いが2点ありますので、それを挙げておきます。

1. まず、それらは今のところ基本的には「時間」に対して文字のアノテーションをするだけですが、IIIF動画アノテーションの仕組みでは、「時間」と「動画上の任意の位置」を指定して、さらに文字だけでなくあらゆるコンテンツのアノテーションができるということになっています。（ただし今回できるようになったのは文字と静止画像アノテーションです）。

2. それから、もう一つの大きな違いは、アノテーションの規格がオープンなものであるということです。これには色々なメリットがありますが、たとえば、特定の企業にデータ形式を左右されて急に使えなくなったりすることがなく、さらに、誰でもこれに対応するアプリケーションを開発できるため、たとえば今回のようにどこかが開発してくれればそれに準拠したデータは皆それを使ってよりよい環境を手に入れることができる、といったようなことがあります。

---

IIIFと言えば、デジタルアーカイブ界隈の方々はもう大体ご存じのことかと思います。IIIFを創った人たちが目指したWeb画像をアンロックするというスローガンは見事にキマって、世界中の極めて多くの文化機関がIIIF対応で画像公開を行うようになり、Webで画像を自由に利活用できる環境が飛躍的に充実したように思われます。そして、IIIFに対応しない積極的な理由を持っていないところでは大体IIIFで公開するという流れになったように思われます。

さて、Web画像はそういう風になりましたが、IIIFが目指すところは、その名前には「Image」と入ってはいるものの、ベースとなる Open Annotation Data Model ⇒ Web Annotation Data Modelでは、そもそもコンテンツの種類は問いません。Web上のコンテンツならなんでも対象にして、アノテーションで接続できるようにすることを目指していたはずです。

というわけで、その部分をよりきちんとできるようにしよう、ということで策定されたのが、今年（2020年）の6月に正式公開されたIIIF Presentation API 3.0ですね。 これまでとデータの構造を変えてしまったので、IIIF対応アプリケーションはどこもちょっと苦労していると思いますが、多言語切り替え機能 や Attributionに加えてProviderという項目を導入したことなど、ユーザ／公開機関レベルではより利便性が高まっていますので、 いずれは対応したいところです。・・・が、今のところ、IIIF Curation Platformをはじめとして、IIIF対応コンテンツを対象とした 外部利活用ツールがまだあまりIIIF Presentation API 3.0に対応しておらず、今、いそいでIIIF Presentation API 3.0に対応した公開をする 必要はなさそうな気がします。

それはともかく、IIIF Presentation API 3.0の大きな変更点の一つは、これまでは静止画像を載せるだけであったCanvasという概念に時間の考え方を導入したことです。これにより、 動画や音声コンテンツに対して、任意の時間帯に様々な種類のアノテーションを付与する、といったことが原理的にはできるようになりました。

すばらしい！

と言いたいところですが、神崎正英さんの Image Annotatorが動画上に文字のアノテーションを表示できるようにして くださっているものの、広く用いられているIIIF対応ビューワでは未対応であり、さらに言えば、「いろんなものを、動画を含むいろんなものに載せられる」という今回の仕様改定の意義を発揮するには、 全体としてまだまだこれからといった段階です。

そこで、今回は、動画に画像を載せるようなこともできてもいいのではないか、それも、よく使われるメジャーなビューワで できるとよいのではないか、ということで開発されたのが、以下のページで紹介されている、Mirador 改良版です。

https://dh.l.u-tokyo.ac.jp/activity/iiif/video-annotation

なお、 一応、このMiradorについても改めて説明しておきますと、 スタンフォード大学図書館の開発チームを中心として、世界中の開発者が協力してオープンソースソフトウェアとして開発されているものです。 学術利用を意識して作成されているもので、画像の比較やアノテーションなど、多彩な機能を持っており、この11月にバージョン3に アップデートされたことにより、IIIF Presentation API 3.0に対応して、言語切り替え機能を実装したり、動画音声の再生ができるようになる など、かなりの進化を遂げました。とはいえ、動画アノテーションについては特に開発の予定がないとのことでしたので、Miradorの 便利な機能を前提としつつ動画アノテーションをできるとよいだろうということで、Miradorの開発に踏み切ったのでした。 実際に開発してくださったのはフェリックス・スタイルさんですが、集中していた時期は毎晩明け方までお付き合いいただいて、 大変ありがたいことでした。

さて、上記のURLで紹介されている例のうち一つは、NHKクリエイティブライブラリーのネコ動画2本を連続して再生し、さらにそれに対する任意の位置・時間のアノテーションを付与して、 ビューワで表示されたアノテーションの一覧をクリックすると動画上の対応する位置・時間に対してジャンプしたり位置を表示したり画像を表示したりする、という ものです。

もう一つの事例は、筆者が2017年に講演した動画が京大オープンコースウェアで公開されていたのですが、部分的には明らかに内容が古い上に、動画の解像度の 問題で講演中に紹介しているWeb画面がうまく見えないことが多い、ということがありましたので、それを、動画アノテーションによって 補足して2020年でもある程度は使えるものにしよう、というものです。こちらについて少し例を見てみると、 たとえば、

動画アノテーションの例1

こちらの例では、スライド中の「受容」という漢字が間違っていたのでアノテーションで画像を貼り付けて修正しています。これは、動画を作成して 公開している方々はよくご存じかと思いますが、こういう間違いを修正するのは大変大きな手間と時間がかかります。特に、一般に公開している ものだったりすると、差し替え用動画を作成した後、差し替えるための手続きにも結構時間がかかることもあるかもしれません。しかしながら、 動画上への画像アノテーションが可能になると、割と簡単に修正できてしまいます。ここでは文字だけでしたが、文字以外にも色々な情報を 上書きすることができます。もちろん、外部サイトで閲覧できるようになっている（CORSヘッダが外部読み込みを許可している）動画が対象 ということになりますが、このあたりも、IIIF動画アノテーションの意義に対する認識が広まっていけば、そういうものも 増えていくのではないかと期待しております。

それからもう一つ、上記の動画からの例をみてみましょう。

動画アノテーションの例2

こちらも、動画上に絵を貼り込んでおりますが、こちらの場合、吹き出しの絵を貼り込むことで情報を補足すると同時に、 アノテーション側ではリンクを提示することで、視聴者がリンクをたどって元の情報にたどり着けるようにしています。 このように、新たな情報をテキストや画像を通じて追加できると言う点と、 外部情報へのリンクを頁内のある位置・時間に紐付けられるという点も、いちいち動画を作り直す手間に比べたら格段に 楽ですので、特に授業用動画などには便利なのではないかと思います。

これだけでなく、もっと色々なことができるはずですが、とりあえずその色々なことのうちのいくつかをできるようにする ことによって、Web画像をアンロックしたように、Web動画もアンロックされないだろうか、というのが当方の期待するところです。

Web画像においてそうだったように、オープンな国際標準規格に準拠して相互運用可能な形でアノテーション データを作成すれば、それは広く長く使えることになります。他の人がさらに利活用することができますし、 他に同様の機能をもった別のビューワが出てきた時にそちらでも使うことができます。 そして、バージョンがあがったり、そもそもIIIFよりもよい規格が出てきたとしても、 次の形式に移行する際には、独自形式に比べるとかなり容易に行えます。

もちろん、画像と違って動画は権利関係が格段に厳しく、アンロックしようにもできないものが大半だとは思いますが、 アンロックできるものだけでもしてしまうことで、Webに蓄積される知識を増やす方向に向かうとよいのではないかと 思っております。

ということで、とりあえず、12/26（土）13:30～15:30、Zoomにて、このIIIF動画アノテーションの書き方の 講習会を実施することになりましたので、これを機に動画アノテーションも押さえてみよう、という人、 ご興味がおありの人は、ぜひご参加ください。参加申し込みは以下のフォームにてお願いいたします。

docs.google.com

Methodological Commons: デジタル人文学で昔から定番の話

前回のブログ記事では、最近回顧されているデジタル人文学の話題としてScholarly primitivesを採り上げてみましたが、そうなってくると、そもそもデジタル人文学の基礎的な概念として常に採り上げられる Methodological Commons（方法論の共有地） についても、この機会にちょっとご紹介しておいてもよいのではないかと思いまして、それが最初に提示された、以下の著名な講演原稿の暫定訳を掲載いたします。（例によって、間違いなどあるかもしれませんのでご注意ください。）

eadh.org

追記： 著者の一人であるHarold Short先生から、最新版の画像をいただきましたので、掲載いたします。(2020/12/22)

Methodological Commons

著者のWillard McCarty先生と Harold Short先生は、いずれもキングスカレッジ・ロンドンの人文学コンピューティングセンター（当時）の教授で、今で言うところのDHを研究していました。キングスカレッジ・ロンドンは、欧州DH学会発祥の地であり、前回記事に登場したJohn Unsworth先生の話にも出てきたところですね。これもやはりデジタル人文学（DH）という言葉が出てくる前ですので、Humanities Computingと呼ばれていました。この後、2004-2005年頃に、ロンドンのHarold Short 先生と米国のJohn Unsworth先生が中心となって国際デジタル人文学組織連合（ADHO, Alliance of Digital Humanities Organizations）が設立されますので、その胎動期の象徴的なものの一つと言ってもよいかと思います。

このMethodological Commonsは、国際DH学会大会では必ずどこかで見るような、とても広く受け入れられているDHの基礎概念です。それで、象徴的な「地図」があるのですが、どうも本家のサイトからはリンク切れになってしまっておりまして、しかし、たとえば、現在のADHOの会長によるこちらの頁でも見ることができますし、色々なバリエーションも出現していることがGoogle画像検索ですぐにわかります。以下の文章は、この地図の説明が主な内容ですので、地図を見ながら読んでいただくとよいかと思います。

なお、Methodological Commonsは、「方法論の共有地」と訳されることが多いのですが、これも、海外のDHの議論と接続するには英語のままで流通していた方がわかりやすい時も あるかもしれないと思いまして、この用語だけは英語で記しています。

それから、この文書に登場する Humanities Computingという語は、「人文情報工学」という訳語をあてていますが、これは現在の文脈では「デジタル人文学」と読み替えていただけますと幸いです。

---

Methodologies

方法論

科学的研究には、2つの出発点がある。いずれにおいても、それ自体として権威がある。観察を否定することはできず、原理的なことに適合していなければならない。挟撃作戦を達成しなければならないのである。Gregory Bateson, Steps to an Ecology of Mind (Chicago, 1972): xxviii

分野をマッピングする

Mapping the field

誰もが知っているように、マッピングとは、複雑な地形を表現するための強力なツールであり、それは我々が地形を全体として理解し、その部分の相互関係をすばやく把握できるようにするためのものである。「ロードマップ」とは、当然のことながら、どこかの場所に行くためのものだが、しかし、それに先立って、そこに至るまでにどのような選択肢があり何が関係しているのかを確認するためのものである。それに先立ち、地図の歴史における最近の研究成果で主張されるように、地図を作成することは、地図に書かれた地形を所有し、それをそのままに明示することである。特徴があるところには名前が付けられ（あるいは名前が付け直され）、関係が表示され、境界線が示され、未知の部分にはラベルが付けられるなど、探査のためのしるしがつけられる。

　ここで示す知的な「地図」は、これらのうちの最後の役割を果たすことを企図している。これは、この半世紀の間人が住んでいたにも関わらず我々の視界に今まさに入ってきたばかりの地形を予想する仮の見取り図である。1990年代初頭まで、人文情報工学は様々な研究活動の事例のカタログを作ることによって説明されるべきものであると考えられてきたように思われる。しかし、その頃には、そのようなカタログを作ることは非常に困難なことになっていた。あまりに多くの分野において、多くの言語で、マイナーな場でもメジャーな場でも、あまりに多くの刊行物が出版されていた。さらに、既存の分野にコンピュータ利用が組み込まれていくことは、関連する研究活動の多くが、とくに言及されることもなく、タイトルから手がかりを得られないような論文や本に含まれるようになることを意味している。 我々が、全体像と、そして、我々の経験に対応する専門家自身の概念を把握しようとするなら、異なるアプローチが求められているのは明らかである。このことは、書誌学的なプロジェクトが放棄されるべきであると言っているわけではない（再考の必要性を提示しているのではあるが）。むしろ、ベイツソンの挟撃作戦を我々の現実に適用しなければならないということである。

ここで例示するマッピングの活動は、地図そのものというよりはむしろ、ポイントである。その領域の全体的な概念を明晰に表現する手段を提供することによってその作戦の補完的な動きを助けることを意図している。

Methodological Commons

Legend

The Methodological Commons

方法論の共有地

地図の中心には、この分野の中核として、「Methodological Commons」と我々が読んでいる大きくて境界の曖昧な領域がある。それは、様々な分野のアプリケーションが共有する計算可能な手法のための概念上の領域である。よく知られているように、たいていの場合、これらは、データのタイプに応じて適用されるものであり、データの主題やそれに対する解釈に応じてではない。したがって、ここにあるのは、散漫な（あるいは連続した）テキスト、表形式の（あるまとまりを持った）テキスト、数値、画像、音声等である。同様にして、時間的な次元を有する（画像と音声のような）数種類のデータについて考えてみたいと思うかもしれない。これらのテキストに適用される技術は、テキスト分析、データベースデザイン、数値解析、画像化、音楽情報検索などのような大まかな見出しで記述されるかもしれない。もちろん、常に新しい手法が考案されているのであり、このリストは決まったものでも安定したものでもない。

Disciplinary groups

分野ごとのグループ

このCommonsの上には、おおまかな分野ごとのグループで人文学（と場合によっては社会科学）の分野が描かれている。これらのグループは、部分的には分野についての我々の観点を反映しているが、部分的には我々の高等教育機関における新しい学際的なグループ化を反映している。両頭の矢印はそれぞれの分野のグループをデータのタイプや、それと一般的に関連のある計算手法と結びつけている。この矢印が両頭なのは、人々のグループと商人との間で行われる商品の流通のように、個々のグループとこのCommonsの間で活発な手法の交換が行われることを示している。この分野別のグループ化とこれらの矢印は、同様に仮説的なものである。というのは、制度的な整理の仕方は、国家や文化の境界を越えて変化し、多様化するからであり、そして、新しい技術は、古い分野が関連を持つと考える事柄を変化させることになるからである。

“Clouds of knowing”

知の雲

このCommonsの下に幅広く並べられているのは、我々が見出してきた、様々な分野の習得事項である。それらは、我々に求められていることに関して非常に重要な役割を果たしているために、それらへの理解がその分野のいずれかの知的な地図に影響を与えざるを得ないというものである。最初は、これを理解するという仕事は、超人的なものに見えるかもしれない。しかしながら、これらの雲は哲学などに包括的に精通していることを示そうとしているのではなく、むしろ、我々の実践に適用するための特定の領域の実務的な知識を示そうとしているのである。たとえば、伝統的なものを電子媒体に作り直すこと、すなわち、編集版や注釈、語彙集などの学術的な形式をもつものを対象とする場合、我々は、その対象が何を目指して、どのような用途を意図していたか、ということを復元できるように、可能な限り元の文脈に近い形で理解する必要がある。そういった知識は、多くは暗黙的なものであり、すなわち、当時は言わずもがなだったものである。この知識を獲得することに関する歴史学と民族学における豊かな議論は、この問題の深さを我々に警告し、そして、それに取り組むためのツールを提供してくれる。

Methodological Commonsを維持・涵養し、他の分野との知的な取引を運用する仕事に関する他の「知の雲」についても同様のことが言えるかもしれない。これらは、以下のようなことを示すために雲として表現されている。すなわち、（アリストファネスに、そして同様に、「知の雲」の中世の匿名の著者の両方に感謝しつつ）、思考体としての性質と、人文情報工学におけるそれらの役割についての我々の暫定的な理解、である。繰り返しになるが、それらは正典的な一覧ではない。我々は、どれが我々の地図の上にあり、それぞれがどのように適合するかを確認し始めたばかりである。

このような地図の価値は、「一枚の絵は千の言葉に値する」ということわざの概念にあるのではなく、むしろ、我々が考えることや知っていることを引き出し、そして、よりよい地図や、さらに、人文情報工学におけるより意識的な、そして直接的な活動へと至る議論を惹起するためのイメージの力にある。

History and new directions

これまでとこれから

厳密に言えば、上の地図にあるもののほとんどは新しいものではない。ほとんどすべては十年前には存在し、知られてもいたものである。しかし、我々が提示してきたように、マッピングの活動自体は、ここに示したような形において、この領域を二次的に（あるいはメタに）考えることについての根本的に新しい方向性なのである。

10年前には、我々は様々な分野に対して共通の技術を関連付けることについて十分な知識を持っていた。人文情報工学が分野としての境界が適用されないMethodological Commonsに関係していることについて、最初は疑問を持ち、その後、ある程度は理解していた。実際のところ、その頃には、人文学によくみられるいくつかの研究の側面に関連付けられる計算手法の抽象的な概念やソフトウェアの基本的なタイプを描くことが可能になっていた。当時、画像処理は（OCRを除いて）地図上に載せるほど重要なことではなかったが、今回新たに追加したことになる。その頃の「コミュニケーション」は、現在のように、Webを中心とするようなものではなかった。

　たとえばこの五年間の間に、最近の経験的知識には、明らかに学際的な成果やさらなる可能性を伴う、大規模なリソースを基礎とした多様な技術・多様なメディアの研究が増えてきている。事実上、ネットワーク化されたリソースは、単一で比較的変化のないリソースが多種多様で変化の激しい用途から分離され、個々のリソースが関連する多くの研究分野を横断した曖昧な再文脈化を許容するという研究図書館の古のモデルを顕在化し始めている。この学際的なデジタル図書館の出現は、Methodological Commonsを断片化するというよりもむしろ、その中心性と幅の広さを強調している。そして、Commonsの中心性と幅の広さは、我々が技術の適用に際して必要な方法論の受け入れをより体系的に研究するのに必要であるところの「知の雲」を実際に利用していることをいっそう明らかにした。

この地図は、人文学における知の雲と特定の研究プロジェクトの間で共有された技術を媒介として、人文情報工学の根本的な役割を描き出している。とりわけ、この媒介を通じて、人文学の研究事業においてこの知の雲はからみあいつつ成長していくのである。

Willard McCarty and Harold Short

Creative Commons Attribution 3.0 Unported License.

Scholarly primitives: 最近デジタル人文学で話題になっている話

欧米のデジタル人文学業界も、最近はオンライン会議がよく行われるようになったり、SNSでの発信もますます活発化したりして、海外に行かなくても海外の様子が垣間見えることが増えてきました。

そこで気づいたことの一つが、かつて話題になっていたScholarly primitivesという考え方が改めて脚光を浴びているようだ、ということです。

知る限りでは、DHにおけるScholarly primitivesは、Digital HumanitiesがまだHumanities Computingと呼ばれていた2000年頃に、当時はヴァージニア大学で Institute for Advanced Technology in the Humanitiesを率いておられたJohn Unsworth先生が提示されていたのが最初であったように思います。John Unsworth先生はその後イリノイ州立大学アーバマ・シャンペーン校に 移って図書館情報学研究科長までされて、さらにブランダイズ大のVice provost兼CIOを経て、現在はヴァージニア大学に戻って図書館長をされているなど、英文学出身の DH研究者でいらっしゃいますが図書館・図書館情報学に非常に縁の深い先生です。

さて、Scholarly primitivesの話に戻りますと、DH関係の会議等では、時々、John Unsworthが提示するScholarly primitivesは…ということで議論されたりするのを 見かけることがありましたが、最近、ヨーロッパの人文学デジタルインフラプロジェクトであるDARIAH (Digital Research Infrastructure for the Arts and Humanities )の 学術大会で、Scholarly primitivesがテーマとなって、さらにJohn Unsworth先生が基調講演をされたようです。

DARIAH Annual Event 2020 - Sciencesconf.org

これだけでも大変興味深いところですが、さらに、この会議で 3D Scholarly Editions: Scholarly Primitives Reboot という発表をされた Susan Schreibman先生がベストペーパー賞を取られたとのことで、3DとScholary primitives、という組み合わせにも なかなか興味をそそられるところです。Susan Schreibman先生と言えば、TEIで書いた校訂テキストをきれいに表示してくれるViersioning Machineというソフトウェアの 開発プロジェクトを率いておられたり、DHの代表的な教科書であるCompanion to Digital HumanitiesのエディタをJohn Unsworth先生達とされたりと、DH界では重要なお仕事を色々してきておられますが、最近は3Dの学術利用（＝学術編集版の構築）に力を入れておられるようで、すでにこの方面のフルペーパー "Textuality in 3D: three-dimensional (re)constructions as digital scholarly editions"も出しておられます。時間があれば、 このフルペーパーもじっくり読んで勉強させていただきたいところです。

というわけで、最近話題になっている、Scholarly primitivesですが、John Unsworth先生がWeb公開しておられる2000年の講演原稿がありましたので、

https://johnunsworth.name/Kings.5-00/primitives.html

みんなで原点回帰してみよう、ということで、とりあえずざっくり抄訳をしてみました。（抄訳というにはちょっと長いかもしれませんが…）。分野がちょっとずれると、日本語の学術論文でもなかなか手強いことがありますので、英語が 読めると言っても分野違いだったりDHを始めたばかりだったりするとなかなか読むのも大変かもしれない、ということで、誤訳もあるかもしれないのでご注意をお願いしたいところでも ありますが、英文で読むのはちょっとしんどいけどざっくり内容を知りたい、という人は、よかったらちらっとご覧になってみてください。

（なお、抄訳なので、原文に掲載されている画像は表示しておりませんので、図についての説明がでてきたら、原文のサイトの方でご覧ください。）

あと、Scholarly primitivesの良い日本語訳を思いつかなかったので、それは英語のままにしております。良さそうな訳語をみんなで考えてみましょう。

"Scholarly Primitives: どんな手法を人文学研究者は共通して有しているのか、そして、我々のツールはそれをどのようにして反映するのだろうか？"

part of a symposium on "Humanities Computing: formal methods, experimental practice" sponsored by King's College, London, May 13, 2000.

By John Unsworth

アリストテレスによれば、科学的知識（エピステーメ）は、自明な文（公理）の有限のリストから演繹的に従う文で表現されなければならず、そして、自己理解できる有限の用語リストから定義された用語（primitives）のみを使用しなければならない。『スタンフォード哲学百科事典』

「自己理解できる用語の有限なリスト」としてのPrimitivesという概念は、それ以上の定義や説明なしに公理的論理を進めることができるものだが、それは、（おそらくご存じのように）特に20世紀には、哲学や数学において困難に直面していた。しかし、ここでの目的はそれを解決することではない。ここでは、分野や時間、そして個々の理論的な方向性を超えて研究活動に共通する基礎的ないくつかの役割を表現しようとするために、「primitives」という言葉を自覚的に類推しつつ用いている。これらの「自己理解」の機能はより高いレベルでの学術研究に関するプロジェクトや議論、言明、解釈の基礎を形成する。それは、我々が本来持っている数学的哲学的類推や公理の観点からみたものである。私の「Scholarly primitives」のリストは網羅的なものではなく、その一つ一つを平等に扱うわけでもない。追加提案や変更・削除についての議論は歓迎するが、とりあえずの出発点として以下を挙げる。

Discovering／発見

Annotating／注釈

Comparing／比較

Referring／参照

Sampling／サンプリング

Illustrating／例示

Representing／表現

これらを提示することでとりあえず私が目指すのは、人文情報工学（現在のDH）において管理できるというだけでなくきちんと役立つツール開発の事業のための基礎となり得る関数（再帰的関数）のリストを提案することである。私の Primitives のリストには特に順序はない。実際のところ、そのうちの二つ、ここで真にprimitivesといえるものは、Referring／参照とRepresenting／表現である。というのも、これらはいずれも、他のどれにでも何らかの方法で含まれるからである。この二つに関しては、後述する。リストの全体に関して私が議論したいのは、これらの活動が時代やメディアを超えて学術研究の基礎となるものだということである。そして私が特に関心を持っているのは、デジタル情報、特に、ネットワークで接続されたデジタル情報に基づく学術研究である。

私が「Scholarly primitives」という言葉であり概念でもあるものと格闘し始めたのは、一年半ほど前、このキングス・カレッジ・ロンドンでのことであり、テキスト分析ツールに関するイギリス／米国の共同研究を資金的に支援するためのまったくうまくいかなかった努力の一環であった。（そういえば、私の Scholarly primitivesのリストでは「物乞い」という昔からの研究活動も含んでいるだろう）。この提案書では実際にはprimitivesという単語は使われなかったが、しかし、共通のアーキテクチャーがあれば、より高次の（公理的な）機能を達成するために組み合わせることができるいくつかのツールとして具体化できるかもしれない、学術研究のいくつかの基本的な機能を確かに想定していた。

この提案の次に行ったものは、それもまたうまくいかなかったが、米国人文学基金に提出したものであり、実際にその単語を用い、その概念を説明した。「人文学研究の機能的な原始関数」という章で、その提案書では以下のように述べた。

このプロジェクトが前提としているのは、「比較」が最も基本的な研究上の行動の一つ、すなわち、人文学研究の機能的な原始関数である、ということである。多種多様な資料を扱う様々な分野の研究者達が、いくつかの（時には多くの）分析対象を比較したいと考えている。それらの対象には、テキストであれ、画像であり、動画であれ、人が創り出したあらゆるものが含まれる。

少しの間その提案書から離れて、Scholarly primitiveとしての比較という点を止めて、いくつかの画像でそれを描写させていただきたい。まずはIATH（ヴァージニア大学のDHセンター）のユニコードブラウザ、次に、もうじき公開されるBlake Archive version 2.0のユーザインターフェイスである。

Babbleは、異なる言語系統・文化的伝統における共通の物語の要素を扱うテキスト群を比較しようとする宗教研究のプロジェクトの産物である。その比較は、潜在的には構造的なものであり、章や偈頌のような単位をキーにしたものになるかもしれないが、しかし、そのまま照合したり差分を確認したりできるわけではない。テキストそれ自体は概念的には対比可能であるものの、文字符号化という観点からは比較できないものだからである。Babbleを構築するという課題の大部分は、このような並置をWebを介して公開するという要件にあった。上記の図のような例では、三種類の文字セットがあり、これは画面に表示するためのUnicode文字エンコーディングとシステム依存フォントの間の水域を移行できるようにするJavaアプリケーションを開発することを意味している。（そして実際に、この種のシステムフォントを扱うJavaのメソッドに関するサンマイクロシステムズ（当時Javaを開発公開していた企業）の移行戦略があった）。言語を横断するテキスト比較のように、資料からは単に概念的な支援しか受けずに機能できるというのは、Scholarly primitivesの特徴であると言っていいだろう。これらのprimitivesは、減ずることのできない学術研究の通貨であり、原理的に言って、あらゆる形式やトークンの境界を横断して交換することができるはずである。

比較に関する二つ目の事例は、Blake Archiveである。研究者や学生がBlakeの彩飾本の様々な刷りを比較できるようにすることは、このアーカイブが初期に目指したことであった。このアーカイブの現在のバージョンでは、インターフェイスはアーカイブのSGMLデータのジャンル・作品・刷り・版という階層構造を（かなり厳密に）反映している。そのため、二つの版を比較するためには、ユーザは階層をたどって一つの版を見つけた後に、二つ目のブラウザを開いてもう一度やり直し、そして、同じ版から別の刷りへとたどっていく、ということをしなければならない。このような使い方は、このアーカイブの設計として禁止されているわけではないが、確かに有効になっているというわけではない。比較する必要性とはとても基本的な要件であるということを認識した上で、我々は、このインターフェイスを改良した。どの本におけるどの版からでも、ユーザは、同じ作品の異なる刷りにおける同等の版のセットを引き出すことができる。あるいは、ユーザは、あらゆる別の作品におけるあらゆる別の刷りへと直接に飛ぶこともできる。それは以下のようなものである。 （図）

ユーザインターフェイスへのこれらの変更はまったく単純なものだが、二つの理由から、それらの変更は研究ツールとしてのこのアーカイブの有用性を大幅に高めた。一つは、それらの変更により、様々な理由で操作中に呼び出せる機能が提供されたこと（つまり、それらは、一つのscholarly primitiveを実現している）、もう一つは、それらが構造的・非構造的という二つの方法で比較するという特殊なprimitiveを提供しているという点である。ユーザは一つの操作でパラレルな版を画面に呼び出すことによって構造的なデータを活用することができ、そして、そうすることで、ユーザは、比較される対象を含む構造によって比較に対して課された制限を回避することもできる。この階層構造は、資料の作成と維持に際しては絶対に必要だが、しかし、末端ユーザの観点からは同等な機能的重要性が必ずしもあるというわけではない。我々は、その一つの操作でアーナイブ内の二点をつながせてくれる操作方法により、階層構造からさらに自由になる。（そして、現在のインターフェイスのユーザにとっては常識となっているその場しのぎの比較の手順は新しいレベルに引き上げられる。）

米国人文学基金の提案書に戻ろう。

二つ目の機能的なprimitiveは、我々の観点では、selection選択である。比較のための対象の選択だけでなく、同様に重要なのは、選ばれた対象の中の関心を持つ領域の選択である。三つ目の機能的なprimitiveは、linking関連付けである。関連付けは、注釈という古典的な形式におけるものでもあり、二つのデジタルな対象の間の、それ以上の数のデジタルな対象の中で、そしてデジタルな対象の内部において、有用な関連を創り出すという、より抽象的な意味におけるものでもある。

これは、IATH(前出)で作成されたWeb配信可能なJavaソフトウェアInoteを用いて、画像の選択されたサブセクションへの注釈のリンクを可能にしている。

InoteのアイデアはBlakeアーカイブからではなく、むしろ、ロゼッティアーカイブと影の谷（南北戦争の歴史）プロジェクトの初期の頃に出てきたものである。二つのプロジェクトはいずれも、たとえば私が万能ワープロでしているような、一つのページ上でテキストを用いて情報を単純に囲むよりも、より明確な、画像ベースの情報に取り組むための方法を求めていた。Webの初期には、「注釈サーバ」というものがあり、ユーザは、注釈をつけられた資料を見ている他の人と、そのサーバ経由で注釈を共有することができた。しかし注釈はページ全体に付与することができるが、もっと小さな単位に付与することはできなかった。つまり、画像全体に対してであって、その特定の部分に対してではなかった。それは1993年のことであった。2000年も、状況は同じである。注釈の共有は、すべての学術的な意思や目的にとっては、Web上では不可能なものであった。いくつかの興味深いが格好のよくなスキームや回避策が開発されてきたが（この中では、Inoteは、欠点はあるものの、実際にはまったく良いものに見える）、これに関してユーザができることは多くはない。

この例でも「selection選択」というprimitiveが働いていることがわかる。Inoteにおける注釈は画像の一部の箇所に付与されているからである。Inoteの用語においては「detail」がそれにあたるものである。Selection選択は、一般的に言っても重要である。というのは、何かの関連する部分に取り組むことを許すからである。InoteとBlakeアーカイブの場合、これは画像検索においてもっとも明瞭に見られる。そこでは、ユーザは、（上の図のような「子供と蛇」を探す場合には）、一つもしくは複数の検索語を選択して、戻ってくる検索結果は、突き詰めて言えば「sector CD of America, Copy A, Plate 13（Americaの画像のCセクションとDセクション、刷りはA、版は13）」という風になる。このアーカイブの初期の頃から、我々はこのようなことをしたいと自覚していた。したがって、このアーカイブのためのマークアップは、編集者がBlakeの版の資格的な内容を記述できるように設計されており、それはグリッド状の位置情報に紐付けられていた。すなわち、四分割してAは左上、Bは右上、Cは左下、Dは右下、Eは全体、といった案配である。それらの位置は結合することもできる（したがって、上記の例では、蛇はCDに登場すると言うことができる）。そして、検索結果は、検索語に対応するその版のセクション編集上の説明を提示する。その下にはInoteボタンがある。ボタンをクリックするとInoteソフトウェアを起動し、特定の箇所にフォーカスをあてつつInoteを開くことのできるボタン（検索結果からスタイルシートで生成される）を表示する。そのようにして、ユーザの検索に応答できるようにBlakeの版を複数のパートに分割してそれらのパート、あるいは版自体を完全に表示するのではなく、むしろ、Blake向けに特化された有用性を発揮できる非常に単純かつ重要な機能的振る舞い（scholarly primitive）に対応するようにInoteを設計することによって、逆に、まったく異なる文脈においても一般的に同じような有用性を発揮できるのである。 　Inoteを話題としている間に、先ほど説明したように、そして他の方法でも指摘しておく価値があることだが、我々は、Blakeアーカイブのデータ構造や、より高い次元の（より公理的な）学術的な意図のためにソフトウェアをカスタマイズするという衝動に抵抗することにうまく抵抗してきた。その代わりに、我々は、このソフトウェアを、基本的な、しかし応用範囲の広いprimitiveな機能を提供するprimitiveなツールとして維持してきた。もし今日ここにいる我々が、共同の形であれ個人としてであれ、scholarly primitivesを実現する別のソフトウェアの開発に参加するとしたなら、これは守らねばならない重要な原則である。このようなprimitiveを実現しようとするソフトウェアは実際の学問的な利用の文脈で開発されテストされるべきだが、しかし、カスタマイズには抵抗するべきである。というのは、目的特化型のソフトウェアやプロジェクト中心のソフトウェアは機能的なprimitiveを幅広く支援できそうにないからである。

　もう一つのprimitiveは「Samplingサンプリング」である。これは、selection選択と密接に関連している。サンプリングとは、実際には、何らかの基準に基づくselection選択の結果である。その基準は検索語の場合もある（その場合には、selection選択の結果としてのサンプルは検索された資料の本文に登場する頻度のサンプルということになる）。あるいは、基準それ自体が頻度の割合、たとえば「1秒あたり5フレーム」のようなものかもしれない。その場合、そのサンプルは、5秒ごとにカメラのフレーム内に世界をサンプリングした画像が連なったもの、ということになるかもしれない。ここで、もう一つの画像の事例を提示しよう。これは、様々な種類の人々（聖書、神話、中世の人々）を参照する情報を検索するものであり、ダンテの神曲を扱うDeborah Parkerのプロジェクトである。ここでは、検索フォームは以下のようなものである：

ここにみえるのは、螺旋の形をした詩のモデルであり、この螺旋の中にある一つ一つの円は詩の編（カント）である。そして、それぞれの円にみられる一つ一つの点は、個々の編における一つの業である。円を越えて広がっているのは様々な色の三角の印だが、それらは最初の検索フォームでそれぞれの検索語に割り当てられた色と対応している。結果の全体は、VRMLのモデルとして表示されるため、我々は、その中で移動したり、上方に移動したり、結果表示に近づいて見ることができる。

ここで得られるのは、頻度のグラフ表示であり、サンプリングしたものがこのデータセットの中で生ずる割合を示すモデルである。この例が示すのは、サンプリングはそれ自体が（selection選択の単なる派生ではなく）、一つのscholarly primitiveである、ということであると提起したい。なぜなら、それは、ある種のユニークな機能すなわち、分散とクラスタリングを示す能力を暗示しているからである。

上記の例では、各フラグはTEIでタグつけされたテキストをDynawebで表示する際に、それが示す行へのハイパーリンク（リンク、あるいは参照というもう一つのscholarly primitive）である。このことは、scholarly primitiveのさらなる特質を浮かび上がらせる。すなわち、それは、他のprimitiveと組み合わせて、基本的なUNIXのツールのようにパイプでつないで最初の出力を次の入力とすることができるscholarly primitive の基本的な原則であり、このことは、ユーザにとっては可能であり一般的に行っているものでもある。このことが示唆するのは、さらに言えば、標準出力（STDOUT）と標準入力（STDIN）にあたるものが全体として重要だということである。我々がこれらのprimitivesを学術的な観点で具現化するために構築したツールは、その出力の次に何が起きるかを知らないままに標準的な形式で出力を生成する能力を持っていなければならないか、あるいは、その能力を持つプログラミング言語を用いなければならない。どこから来たのか、何が生成したのかを知らないままで標準的な形式で入力を受け取る能力についても同様である。

「reference参照」に関して言及すべきもう一つの原則は、参照における安定性の重要さである。このことは常に相対的な問題であり、完全に安定した参照というものは存在しないが、しかし、安定しているほど良い。Web上のリンクが機能しなくなるのはこの原則の典型例であり、我々は皆、その文脈における安定性のない参照の問題についてよく知っている。

私が先ほど「例示illustrating （もう一つのprimitiveに数える）」したNEHへの提案書はうまくいかなかったが、しかし、本日、ここでの私の目的の一部は、実際の所、それが良いアイデアであり、政府の助成金があるにせよないにせよ、我々が共同で目指すべきものである、ということを議論することである。なぜなら、まさに今、これらの非常に基本的な研究活動は、ネットワーク化された電子データに関してでさえ、まったく貧弱な支援しか受けていないからである。これらのすべてにおいて、ネットワークの重要性を強調しすぎることはできない。我々が著述authoringと呼んでいる活動のクラスを除けば、スタンドアロンのツールや資料を用いてできるもっとも興味深い事柄は、ネットワーク化されたツールや資料でできるもっとも興味深くないことよりも、興味深くもなければ重要でもない。真の乗数効果とは、他の人々と一緒に、非常に大規模で予測不能な資料の集合体を横断して、たとえ非常に愚かなことであってもできてしまうという時に生じてくるものである。巨大な、本当に巨大なWebの成功と文化的なインパクトは、私が提供できる最高の例である。ハイパーテキスト理論のコミュニティの誰もが述べるように、ほとんどすべての点で、Webはハイパーテキストの実装としては非常によくないものである。それが行ってきた唯一のことは、広く受け入れられた標準を用いるということであり、したがって、簡単にネットワーク化し、ソフトウェアを容易に書けるように前提の単純化を多く行ったということである。結果として誰もがそれを利用し、そして、そこにその価値が存在するのである。すなわち、多くの人がそれを利用し、多くのものを、それを利用している多くの場所で見つけることができるのである。

実際のところ、私は、もう一つのscholarly primitive、すなわち「discovery発見」についての議論の入口として、次のような命題、すなわち、スタンドアロンなツールや資料で実行できるもっとも興味深いことがネットワーク化されたツールや資料でできるもっとも興味深くないことよりも興味深くもなければ重要でもない、という命題を用いたい。それは、研究者が伝統的にアーカイブズにおいて行ってきたことであり、図書館の目録や棚で我々皆が行ってきたことであり、目録や学術論文の概要を検索する際に我々が行ってきたことであり、そして、今もなお発見のためのもっとも効果的な手法の一つであり、つねにそうであってきた、関心を共有したり、単純に共有すること自体に関心を持つ人と対話することである。それは、教師、仲間、そして、学生達である。彼らはしばしば、我々が予測しなかった、したがって求めることもできなかった方法で、我々の仕事にとって重要になるような資料に対する注意を引くことがある。

Webの世界では、発見discoveryのためのもっとも卓越したツールは検索エンジンである。（ポルノグラフィという例外を除いて、検索エンジンが最初に収益を上げたWebのサービスであり製品でもあるということは指摘しておく価値がある）。人文情報工学の世界にいる我々は検索に関していくつかのことを間違いなく知っている。たとえば、構造化データが、とてもよい、より正確で、より有用な検索結果をもたらしてくれることを知っている。そして、たとえ同じエンコーディングスキーマを使っているとしても、正確に同じ構造を持ったリポジトリが二つとないことも我々は知っている。そして、高度に構造化されたデータに対する高度に構造化されたアクセスから得られる利便性がコレクションの範囲に制限されることになり、そして、選択と符号化の原則、そのパースペクティブ、そして場合によっては、その利用規約によっても制限されることがある、ということも我々は知っている。そのことから、私が発見discoveryのプロセスを開始する時、私はいつも、最も構造化されておらず、もっとも一般的な検索から始める。すなわち、Webのグーグル検索である。非常に多くのデータが、ほとんど構造を持っておらず、コントロールしたり予測したり唯一の構造は、検索式だけである。

他の二つのscholarly primitives、注釈annotationと比較comparisonに関する資料を探し始めたとき、私はGoogleに行って「annotation and comparison」で検索を行った。私は学術的な活動としての注釈annotationと比較comparisonに関する議論や事例を探していた。興味深いことに、私が見つけたのは、ヒトゲノムプロジェクトを参照する検索結果であった。明らかに、注釈annotationと比較comparisonは分野横断的な機能的primitivesなのである。私が思うに、もしscholarly という単語を検索式に入れていたら、あるいは、もしGoogle（あるいはWeb上のデータ）がより構造化された検索を使わせてくれていたなら、私はこの検索結果をすぐにはみつけることはできなかっただろう。より構造的なものがあれば、私は、自分が見つけたいものに沿った少数精鋭の検索結果を得られるように自分の検索式を組み立てただろうし、生物学の領域で検索結果を得ることについては何の意図も特別な関心も持っていなかった。しかし、目的外の検索結果によるセレンディピティの価値についての経験を学んだがゆえに、そしてGoogleがどこからでも簡単に使えるがゆえに、私は、（本質的に）構造化されていない大規模なデータを横断する、構造化されていない検索、ただ検索式のみが構造化されているところから始めた。（おそらく、annotation and comparisonを検索する代わりに、もしcomparison and annotation を検索していたなら、それほど興味深い検索結果にはならなかっただろう。）

annotation and comparisonについて発見したのは以下の通りである。すなわち、生物学者もまたそれを行っているのであり、そして、遺伝学においては研究の基礎を成すものである。そのうえ、彼らは、人文情報工学の人々が取り組んでいるのと同様の社会的、技術的、知的問題の多くに取り組んでいる。私がここで最初に指摘したいのは、非常に大きなネットワーク化された情報を横断して実行されるprimitiveの機能の力は非常に大きいということであり、部分的にはさらに大きい、なぜなら、予期しないが意義のある結果をもたらすからである。疑いをさけるため、以下の資料を紹介しよう。左側の欄に掲載されているものだが、1998年にエネルギー省が出資した会議を記録したWeb文書から未編集の抜粋である。それはヒトゲノムプロジェクトに携わる計算機科学者と生物学者との間で行われたものであった。一方、私の二つ目のポイントは、修飾語句をさておくとしたら、scholarly primitivesというトピックから、情報学を特徴付ける一般的な実験の手法と問題点についての議論になるかもしれないものへのまさに出発点（そして出口）である。そして、資料の左側の欄には医療情報学についての議論があるが、右側の欄では、「ヒトゲノムプロジェクト」を「人文学分野プロジェクト」に、「生物学者」を「人文学者」に、「実験室」を「図書館」に置き換えている。しかし、それ以外にテキストには何も手を付けていない。私はこの改訂版を声に出して読みたい。というのは、私が思うに、我々はこの経験から重要な何かを学ぶからである。しかし、それをする前に、言わせていただきたいことがある。それは、私の検索結果を通じて私がしたことは、ある示唆的な方法でそれらを変形させるということである。そして、変形は表現の一種であり、もう一つのscholarly primitiveである。表現representation（左側）と変形deformation（右側）から学べることが、ここには示されている。 （以下、Human Genome ProjectとHumanities Genres Projectを並べたものが提示されているが、あとは原文を参照されたい）

IIIFで動画：『あつまれ動物の森』にSAT図像DBのIIIF画像を取り込む方法をIIIF動画で紹介してみる

しばらく前に実装したのですが、なかなか紹介するタイミングが作れなかったので、IIIFの動画コンテンツの扱い方の紹介にあわせて、SAT図像DBのIIIF画像を『あつまれ動物の森』に取り込む方法をご紹介したいと思います。

ちなみに「あつまれ動物の森」は、以下のツィッタアカウントにもみられるように、デジタル人文学（DH）界でも新たなコミュニケーションツールとして活用されるようになっており、先日のバーチャル国際学術大会 でも知る限り少なくとも2本のセッションが「あつまれ動物の森」を用いて開催されたようでした。

twitter.com

さて、話を戻しますと、IIIFのPresentation APIがバージョン3.oになったことにより、IIIFでは動画をうまく扱えるようになります。と言っても、これはビューワが対応しなければ何もできないのと同じことですので、ビューワ側での対応を待たねばなりません。これまで、Universal Viewerが動画の表示もできるということで、動画はそちらの独壇場だった感がありますが、もう一つのメジャーなビューワ、Miradorも、バージョン3のリリースにより、正式に動画を扱えることになりました。これで、最新API＋最新ビューワの組み合わせで動画表示ができるようになります。といっても、まだそんなに複雑なことはできないようで、たとえば、以下のように、動画を複数ならべてみたり、さらに別のウインドウには通常の画像表示をしてみたり、といったところです。

https://candra.dhii.jp/nagasaki/mirador3/mirador/video.html

IIIFで動画

上のリンクにて表示される3つの動画のうちの2つは『あつまれ動物の森』に曼荼羅の画像を取り込んだ状態を紹介しています。そして、残る1つの動画は、 『あつまれ動物の森』にSAT図像DBのIIIF画像を取り込む方法の解説です。このブログ記事の冒頭では「ご紹介したいと思います」と書いてしまっておりますが、 この動画をごらんいただけば大丈夫かと思いますので、ご興味がおありのかたは、ぜひ一度ご覧になってみてください。

さて、残念ながら、動画上に静止画像や別の動画等を載せたりするといった、IIIF Presentation API 3.0が実現しようとしている機能はまだ実装されていないとのことなのですが、 しかし、1つのブラウザウインドウ内で画像も動画も扱えるというのは、使い方によっては割と面白いことになるのではないかとも思います。発想力の高い人のヒントになればと思って、まだ 生煮えですがご紹介しておきます。今のところ、YouTubeに対する優位性は？と聞かれても、まだ具体的な機能としては特に見当たらないと言わざるをえませんが、 IIIF Presentation API 3.0の仕様が約束してくれる内容がある程度実装されれば、ある面ではかなり圧倒的な優位性が出てくると思います。

ちなみに、Mirador3で上記のようなことをするための設定ファイルの書き方は、上記のURLのHTMLソースをごらんいただければOKかと思います。 そんなに難しいことはなく、Mirador2よりもかなり洗練されました。Windowsの中の配列として、動画でも画像でもManifestIdを並べていけば それにあわせてウインドウが表示される、というかなり楽な感じになりました。

Mirador3で動画を表示させるためには、IIIF Presentation API 3.0に準拠したManifestファイルを用意しなければなりません。これは実は、最近IIIF協会が力を入れている 「レシピ」の中にVideo用の簡単なサンプルが掲載されています。 動画配信は、配信サーバは使わずに単にmp4のファイルをサーバに置いているだけですが、最近はWebブラウザが賢くなったせいか、それだけでもそこそこ使えるような感じになって います。

というわけで、基本的には、今後のさらなる実装の発展に期待したいところですが、Mirador v3はプラグイン機能が充実しているそうですので、 どなたか、動画アノテーション用のプラグインなど作ってくださるとよいかと思います。腕に覚えのある方や、旅費が使えなくて予算の使い道に 困っている方々など、ぜひ、Mirador v3のプラグイン作成に取り組んでみていただければと思っております。ちなみに、Mirador v3は、Reactという Facebookがオープンソースで開発公開しているJavascriptライブラリを用いて開発されており、個人的にはReactでないものを常用しているため、 今のところ、自分自身ではMirador v3の開発には手を出せないでおります。どなたか、Reactに通じておられる方がいらっしゃったら、ぜひ…

「デジタル人文学」以前の日本の人文系デジタルテキスト研究を探訪してみる

本日、日本デジタル・ヒューマニティーズ学会（JADH）の年次国際学術大会JADH2020が終了しました。リアル開催の予定だったものがバーチャルに途中で変更になり、日程も少し後ろに動かして、それでもなんとかきちんと開催でき、それほど人数は多くないながらも意義のある議論が展開され、相互に認識を深められるとても良い学会になったと思いました。開催を引き受けてくださった大阪大学言語文化研究科の田畑智司先生、ホドシチェク・ボル先生には感謝すること至極です。また、キーノートスピーチを引き受けてくださった東国大学のKim Youngmin先生、IIT インドールのNirmala Menon先生、それから、休日を返上して参加してくださった発表者・参加者の方々のおかげで会も盛り上がりました。大変ありがたく思っております。JADHは、国際デジタル・ヒューマニティーズ連合（Alliance of Digital Humanities Organizations, ADHO）の構成組織として活動をはじめてからもう8年が経っており、行きがかり上、筆者は現在JADH代表としてこのADHOの運営委員会にも参加しておりますが、今や、韓国やインドのDH学会など、新興グループを受け入れる側になっています。

そんなデジタル人文学（DH）ですが、この「言葉」が使われ始めたのは2004-2005年くらいのことで、それ以前はHumanities Computingなどと呼ばれていたようで、学会名としても欧州では Association for Literary and Linguistic Computing (ALLC)、米国では Association for Computers and Humanities (ACH)と呼ばれていました。Digital Humanitiesの語が使われるようになったのと同時期にこの二つが連携して作られたのがADHOで、それ以来、学術大会としてもデジタル人文学/Digital Humanitiesを正式に用いるようになったようです。

私は基本的にこの業界には新参者というか、あとから一人でひょこひょこ入っていったので、それ以前にこういった流れが日本とどういう関係を持っていたのかよく知らないまま活動して、当時、ジョン・バロウズ先生の薫陶を受け英語コーパス研究の文脈でALLCの運営委員をつとめておられた大阪大学の田畑智司先生と知り合い、その頃からお手伝いをしていたSAT大蔵経テキスト・データベース研究会代表の下田正弘先生も意気投合されて、日本にこの流れをきちんと持ってきて定着させねばということで、当時日本のDH的研究の中心であった情報処理学会人文科学とコンピュータ研究会のみなさまとともに、JADHを立ち上げ、2011年にADHOに正式加盟し、晴れて、国際的なDHの公式な日本の窓口を設定することができたのでした。

同様に、今一番力を入れているText Encoding Initiative (TEI)に関しても、一人でひょこひょこ国際会議に入っていって、鶴見大学の大矢一志先生は比較的よく参加していたのでお知り合いになることができましたが、それ以外の日本人にはあまり会うことがないまま、英語は苦手ながら中心メンバーの方々と一緒にご飯を食べに行ったりあれこれ議論を重ねるなかで徐々に雰囲気に馴染んでいったということがありました。もちろん、中心メンバーの半分くらいはADHOと重なっていたので、JADH/ ADHO関連での会合とあわせて仲良くなったということもありました。そういう流れもあってTEI協会の理事も1期だけですが務めることになり、TEI会議を日本に持ってきたり、それまでには認められていなかった特定言語文化圏のためのSpecial Interest Groupの設立に至ったり、ということにもなりました。

ついでに言えば、日本のこの業界にも一人でひょこひょこ、特に後ろ盾もないままに入っていたので、後から考えると何か空気の読めない困ったヤツだったのかもしれませんが、まあとにかく、科研の若手研究Bがとれたことで少し旅費が自由に使えるようになったので、当時は「日本一周研究会開催」という壮大な（当時きわめて交通の便の悪い地方大学につとめていた自分にとっては非常に大変な）プランを進行中だった情報処理学会人文科学とコンピュータ研究会（SIG-CH）にも継続的に参加しはじめて、とにかく自分がやっていることをこまめに発表してみるというところから始めて、そこから今に至っているのでした。

ということで、時期的に言えば、私は「デジタル人文学」が登場するころにこの分野に力を入れ始めたので、それ以前にこの分野が日本でどういう風に展開されていたのか、とくに、TEIをはじめとするテキストエンコーディングがどういう状況だったのか、ということについては、多少調べてはいたものの、基本的にあまりつながりのない状態でやってきていたようなのでした。日頃色々とお世話になっているCHISEで有名な守岡知彦先生にいただいたコンピュータ雑誌の記事を通じて、かつて長瀬真理先生が源氏物語のTEIエンコーディングに取り組んでいたという話を把握していたり、ポスドク時代にお世話になった豊島正之先生がSGMLのTEIやXMLに批判的な記事を書いておられたことは知っていたのですが、断片的な情報で、それらを集めつつ基本的な情報処理についての知識を総合するだけで、2008年くらいまでは日本語でTEIのエンコーディングをするのは高コスト過ぎて、もしやるならかなり周到かつ大規模な計画が必要だっただろうということは判断できたので、全体の文脈を追いかけるところまではやっていなかったのでした。

ところが最近、岡田一祐氏とやりとりをするなかで、情報知識学会のニューズレター等の刊行物のバックナンバーをざっと読む機会を得まして、そこで長瀬真理先生がニューズレターの編集長をするなどしてかなりいろいろな記事を書いておられ、TEIやテキスト・データベースにどういう風に関わっていたかという情報を得ることができました。情報知識学会の過去の刊行物をデジタル化公開してくださった方々には大感謝です。また、ここで、ある時期の長瀬先生のお仕事もかなり把握することができただけでなく、他にどういう人が関わっていたのか、ということも若干ですが見えてきました。

といっても、得られた情報を狭い知識で切り貼りするしかないので、当時の状況をご存じのかたが色々ご教示くださるとありがたいのですが、どうも、かつて、JALLC日本支部と、JACH（テキスト・データベース研究会）というのがあったようです。欧州のALLC⇒JALLC、で、米国のACH⇒JACH、ということだったようで、内実はともかく、名称はそれぞれ引き継いでいたようです。いずれにしても、テキストデータベースを作ろうという動きがそれなりに活発で、当時私でも聞いたことがあったヘーゲルデータベースやフッサールデータベースなどの哲学系の日本発の著名なテキストデータベースもそういう流れとリンクしていた面があったようです。自分が忘れているだけで、もしかしたら、情報処理学会人文科学とコンピュータ研究会の過去の研究報告や『人文学と情報処理』などにも書いてあったのかもしれませんが（特にイベント情報などがあったかもしれませんが）、ようやくそういった点と点が頭の中でつながってきたということかもしれません。ALLCやACHの仕事をする前にJALLC日本支部やJACHと言われてもそんなに関心を持てなかったかもしれないとも思います。

それはともかく、情報知識学会のニューズレターの1988年設立記念号には、なんと千葉大時代の坂井昭宏先生が、「コンピュータのなかの古典」という記事で、当時のJACH（テキスト・データベース研究会）の活動を紹介しておられます。これを見ると、当時千葉大でヘーゲルデータベースを作っておられた加藤尚武先生を中心として、千葉大の哲学系はテキスト・データベース構築の拠点の一つであったようにも想像されます。当時、哲学研究はテキスト・データベース構築をリードする存在であったこともこの記事からはうかがえます。また、後に人工知能学会会長を務められる堀浩一先生のお名前が見えるのもなかなか貴重です。もちろん、我らが塚本先生もコンピュータ梵語仏典研究ネタで名前を連ねておられます。この記事から想像するに、JACHは海外系、JALLCは日本語系だったのかもしれない…ということも想像されます。とにかく、第一号からいきなり盛りだくさんな感じでびっくりでした。

一連のニューズレターのなかではテキスト・データベースに関する情報とともにTEIの話もちょこちょこでてきます。特にTEIに関することが大きく採り上げられるのは、1991年10月の長瀬真理先生による「TEIの活動と今後の展望」です。この時には、長尾真先生が中心になってTEIの受け皿作りが検討されていたことがあったようで、なんともすごい話だったようです。前出のJACHとSIG-CH等が組んで当時TEIのチェアをしていた Susan Hockey先生を日本に招待されたことも書いてあります。守岡先生にいただいたコンピュータ雑誌の記事もこの時のものだったようで、長尾先生も出てくるような話ですので、かなり多くの人に注目されていたのかもしれません。もちろん、今の技術水準から考えると、当時、SGMLで日本語の人文学テキスト資料をあれこれするのはかなり高コストで、ちょっと難しかっただろうし、あまりうまくいかなくても仕方がないだろうな…と思わざるを得ませんが、当時、いろいろな可能性があったことは想像されます。

TEIに注目してみていくと、1992年4月の記事では、三木邦弘先生による「JACH第14回研究会に参加して」という記事のなかで、土屋俊先生がTEIの現状報告をしておられたこともうかがえます。なお、この記事では、JACH研究会が初めて東大大型計算機センターを離れて仙台で開催され、それにあたって尽力されたのが塚本先生であったことも書いてあり、これもなかなか興味深いところです。

しかしながら、このあたりから、TEIの話はちょっと見えなくなってきます。ベルゲン大学のヴィトゲンシュタインのDBの記事で長瀬先生がTEIの拡張的な利用に言及されますが、その後はちょっとうまく見つけられませんでした。ちなみにベルゲン大学でこのDBを担当していたEspen Oreさんは、その後2010年に日本に来てTEIのレクチャーをしてくださったことがあり、短い時間の中でTEIガイドラインのカスタマイズの仕方までやっておられたので、この記事をみて、ああ、なるほど、Espenさんは筋金入りなんだな…と思ったところでした。

さて、ここら辺である程度検索キーワードが見えてきますので、改めてちょこちょこググってみますと、なんと1994年3月の国立国語研究所によるアンケート調査報告「海外のテキスト・アーカイヴにおける管理・運営上の問題点について」のなかで「TEIを知っているか」「使うつもりはあるか」等の質問項目があります。まあ、94年3月だと、まだSGMLだし、そんなにのめり込んでいるところは多くないですよね…というところでした。さすがに、オックスフォードは前のめりのようでしたが。

その後、90年代後半～2006年くらいまで、TEIに関する日本語の記事は全般的にあまり見つかりません。1999年の人工知能学会誌に土屋俊先生が第一著者として「音声対話コーパスの共有化へ向けて」という論文を載せておられますが、この段階ではSGMLのTEI ガイドラインP3を使用していて、脚注のなかで当時W3Cで策定中のXMLについての記述が見られ、やはりSGMLでかつUnicodeも十分に使えない状況だと大変だっただろうな…という印象が先に立ってしまいます。

一方、この調子で、徐々に過去の様々な資料がWebで簡単に探索できるようになっていけば、もう少しそういったかつての実情も確認しやすくなっていくのではないかとも思っております。もしかしたら、他にも踏み込んで取り組んだ方々が日本におられたかもしれません。とはいえ、個人的な印象としては、この頃、このような草の根的なテキストデータベース的なものが下火になっていったように思っております。取り組む人たちの世代的にもちょっと隙間が空いているような感じがしています。

いずれにしても、TEIガイドラインがXMLの特性を大幅に活かしたバージョンであるP5をリリースし（2007年）、かつ、Unicodeがそこら辺のパソコンでも普通に使えるようになってくれないことには、日本語資料での利用はかなり難しかったのではないかと想像されます。

ところで、この件であれこれググっていたら、1997年の長瀬先生による「人文・芸術系のデータベース -今そしてこれから-：5. 文学データベース -急がれる総合的な環境整備-」という論考を発見しました。ここに今でも通じる大変示唆的な一文を発見したので引用させていただきます。

今後、日本でもハイパーテキストの開発が進むと思われるが、その場合、ぜひとも文学や古典の専門家、それも複数の研究者の協力を得て付加価値の高いハイパーテキストの作成を心がけて欲しい。とくにソフト開発者に希望することは、やはり現場の研究者や利用者の意見の尊重である。技術系主導で作られたデータベースは汎用性を考慮するあまり、小回りがきかず、実際の研究では役に立たないことが多い。また既存の技術から応用発想することが多く、冒険的、実験的、個別的・特殊なテーマへの挑戦を嫌う。予算の問題もあろうが、貴重な題材がただ切り刻まれて、どこにもでもある無難なできで留まってしまうのは非常に残念なことである。また、せっかくよいソフトやデータベースを作っても、開発が終わると、一件落着といわんばかりにテキストに対する興味を失ってしまう開発者が多い。古典作品の研究に終わりはないと同様、データベース開発にも終わりはない。

…（略）…またネットワークにより国際的な協同作業がやりやすくなると同時に、複数の研究者間の意見調整も難しくなる。少しずつ公開されるたびに、参加する研究者の数も増えてくる。こうしてハイパーテキストは新しい解釈を生み出しながらネットワーク上にシェアを広げていく。こうなるとサポートや技術支援は作品の研究と同様に永遠に続くかもしれない。こういった事情を考慮して長期の協力体制を組んでいただきたい。

これは、デジタル人文学のみならず、現在でいうところのデジタルアーカイブの課題そのものでもあり、さらに言えば、ここで要求されているレベルのことが、むしろ文学や古典の専門家の側でできているのかという反省も含めて受け止めていきたい文章です。このような見通しをお持ちだった長瀬先生が2002年に夭折されたことは、返す返すも残念なことでした。

技術は進展しても、それを扱う人間の側はそんなにすぐには変わりませんので、少しずつでも着実に、ということで、これからも進んでいければと思っております。TEIガイドラインへのルビの提案は9月末にようやくできたところですので、それがよい手がかりになればと思っております。

LMSに教材をアップできればJ-Stageでオンライン論文公開はできるはず

このところ、J-Stageにかかりきりです。あまりお金のない学会の論文誌の編集作業を引き受けてしまっていて、それでいながらちょっと面倒なことに手を出してしまったためなのですが、ちょうどいい機会なので、表題の件について書いておきたいと思います。

「LMSに教材をアップできればJ-Stageでオンライン論文公開はできるはず」

です。

このコロナ禍で、オンライン論文のありがたみが身にしみている人が多いと思います。そして、自分の学会の論文も、もうオンライン公開してしまってよいのではないかと 思っている人も極めて多いのではないかと思います。では、どうすればいいのか。お金もかかりそうだし時間もかかりそうだし…。と考え始めたら、まずは J-Stageを検討してみるのが今のところは極めて重要です。J-Stageは、学会活動をきちんと行っているところが申し込み手続きをすれば、 無料で論文公開をさせてくれます。バックナンバーの登載もさせてくれるようですので、何らかの方法でPDF化して書誌情報を用意できれば、あとはなんとかなります…が、 とりあえず、表題の件に戻りまして、

自分で書いた論文をオンライン公開する場合です。もちろん、編集管理の権限は学会単位で付与されますので、普通は編集担当者しか 論文公開はしませんし、ページ番号を連番にしたければ、やはり公開は担当者に任せるのが安全です…が、敢えて、表題の件を考えて みたいと思います。

J-Stageでは、学会に対して付与された雑誌管理者アカウントを用いて、編集搭載者のアカウントを作成することができます。 もしかしたらアカウント数に上限があるかもしれませんが、それはおいおい確認するとして、とりあえず表題のことをする ためには、著者に編集登載用アカウントを発行してしまうという手があります。そして、著者に対して「論文登載してね」 というわけです。ページ番号連番にならないよ！？という話がありますが、これには、情報処理学会研究報告方式（と私が 呼んでいるもの）がありまして、雑誌につけられる巻（Vol.）号（No.）のうち、号（No.）の方を1論文単位で付与して しまうのです。そうすると、一つの巻に載っている論文が8本あったら、Vol.1 No.1～Vol.1 No.8ということになります。 これにより、すべての論文は1ページ目から数えられることになるわけです。紙で出す雑誌だとええっ！？となりそう ですが、電子媒体ならそんなに気にしなくても大丈夫です。あるいは、すでに紙で出したものをPDF化して出すだけ、 ということであれば、そもそもページ番号もすでについているはずですので、むしろ話は簡単になりそうです。

さて、そうすると、たくさんのアカウントができて大変なのでは、とか、いつまでもやらない人が出てくるのでは、 などと運用上の課題が色々気になってきますが、J-Stageの賢いところの一つに、 アカウントの有効期限が設定できるようになっているという点がありまして、しめきりを設定してそれまでに 論文登載しなかったら終了、ということもできるようです。

というわけで、雑誌編集担当者が、巻（Vol.）号（No.）を設定して、各著者のアカウントを設定し、 「みなさんそれぞれ巻号を割り当てますので、そこに自分の論文をアップしてください」とお願いしたとすると… あとは、表題の通り、今年度に入ってみなさん急にガンガン使うようになったLMS、あそこに教材を アップロードする話とほとんど同じです。アップロード用Webサイトにアクセスしてログインして、 あとは、タイトルつけて、著者名つけて、検索しやすいようにする キーワードは面倒ならつけなくてもよくて、概要をつけるのは自分で書いたものなのでそんなに 難しくないですね。参考文献リストも載せろと言われますが、実は載せなくても論文の アップロードはできてしまいます。とはいえ、自分がお世話になった論文の価値を高めることに つながりますので、参考文献リストはできれば載せた方がよいです。で、あとは論文PDF ファイルを選択して、ポチっとすると、まあ大体OKです。公開日設定もする必要がありますが、 それくらいは、雑誌編集担当者に頼んでもそんなに大変な仕事ではないでしょう。

これでできあがりです。同じ雑誌に載せるみんなが載せてくれればまとめて公開できてありがたいですが、 ここでも、巻号を別にしている上に「早期公開」機能もあるので、作業をいつまでもしてくれない 人がいたら、その人は残して先に公開してしまってもよいのです。

もしかしたら、J-Stageとしては、各著者にアカウントを発行するようなやり方は推奨してないかも しれませんが（もしそうだったら申し訳ありません…）、それほど状況は身近なところに来ているし、 わざわざ予算を取りに行く必要もない、むしろ、それにかかる時間と手間があればアップロードは 終わってしまうこともありそうです、 ということで、ちょっとご紹介してみた次第です。

なお、大量のバックナンバーを公開したいとか、大量の論文を事務局で引き受けてアップロードしたい、 あるいは、高度な全文検索もできるようにしたい、などの状況がある場合には、そういうファンドを なんとかして調達した後に、企業にご相談するのが 早道です。現在、學術雑誌を印刷刊行してくれる印刷会社の多くが「 学術情報XML推進協議会 - XSPA 」という ものを結成してJ-Stageに対応したり大量一括処理したりするためのノウハウを蓄積共有している ようですので、ここのリストにあがっている印刷会社に相談すれば、あとは予算確保をするのみ、 という感じになろうかと思います。

しかしながら、それを自分（たち）でやりたい、あるいはやらざるを得ない、という場合には、 またいろいろな道が出てきます。次回（あるいはそのうち）、元気があれば、私がかかりきりになってしまっている、 高度な全文検索ができるようなアップロードの仕方の話も書いてみたいと思います。