Miradorの新機能で国デコの絵巻画像をつなげる（Gimpで位置合わせ編）

今回の記事は、前回の続編ということで、国デコ（国立国会図書館デジタルコレクション）の絵巻画像をサーバ上では分割されたままで配信しつつ、IIIF対応ビューワMirador上でつなげて閲覧するための位置情報の取得を比較的効率的に行うための作業手順についてのご紹介です。

＜ 用意するもの＞

ここでは、gimpを使ってみます。これは、GUIによるフリーの画像処理ソフトとしては最強クラスのソフトで、個人的にはこの20年ほどお世話になっております。（開発者のみなさまありがとうございます）

このソフトは、今時の多くのメジャーなフリーソフトウェアと同様に、機能拡張が簡単にできるようになっており、このソフトに組み込まれていない機能でも、誰かが機能拡張を作成公開している場合が多いです。「自分が困っていることは世界の誰かも同じように困っているはずで、そのなかにはプログラミングが得意な人もいるに違いない。そしてその人が機能拡張を作成しているかもしれない」と思うことは、特にこの数年、正しい想像であることが多くなってきたような気がします。

　それから、この作業をするにあたっては、対象となる画像のフルサイズのものが必要になります。なんとかしてダウンロードして入手しておいてください。ここではIIIF対応画像という話なので、画像一括ダウンロードツールもあったと思います。

＜ここでやりたいこととgimpのプラグイン＞

　さて、ここでやりたいことは、二つの画像をきれいに重ね合わせた上で、重ねた方の画像の相対位置情報を取得することです。きれいに重ねるには、以下のようなことができてほしいところです。

　1．マウスで簡単に画像を動かして位置合わせできる

　2．重ねる画像が透過していて位置合わせが容易

この2つの機能は、gimpの標準機能で実現できます。「レイヤー」機能を使うことになります。

さらに、位置合わせが終わったあとに、

　3．重ねた画像の相対位置情報を簡単に取得したい

　4．1つの作業が終わったあと、次の作業のために画像を定位置に戻したい

という機能があると便利です。この2つの機能は、gimpには標準装備されていないのですが、しかし、探してみると、ありました。プラグインでした。

　gimpにはプラグイン登録サイトがあって、そこに2つの機能のプラグインがそれぞれ登録されています。3.の方は、Layer informations、4.の方は、Move Layer Toでした。

　gimpのプラグインのインストールは、Windowsの場合、 C:\Program Files\GIMP 2\share\gimp\2.0\scripts にプラグインのファイルを置いてから、gimpを起動すればそのプラグインが読み込まれます。今回のプラグインの場合、メニュー中の「レイヤー」のサブメニューとして以下のように表示されますので確認してみてください。

さて、とりあえず、gimpのプラグインのインストールまで終わったはずですので、次に、位置合わせ作業用の画像を作成します。これは、大きささえ良い案配であれば、真っ白な画像でよいので、とりあえず大きさを検討して作成します。今回は、8630 x 8052というサイズで横につなげていくので、以下のように、大体18000 x 10000くらいで新規画像作成してみます。

ここで、画像が大きすぎてうまくソフトが立ち上がらない場合は、縦をもう少し狭めてみたり、色々工夫してみてください。

次に、これは、作業してみて勝負の分かれ道だと個人的に思ったのですが、キーボードショートカットを設定します。これはあくまでも好みの問題なのですが、いちいち右クリックしてサブメニューをたどっていくというのは、個人的には単純作業のなかでは心が折れやすい部類の作業です。幸い、gimpはキーボードショートカットを割と自由に設定できるので、以下のメニューから設定してしまいました。

私の場合は、

Layer informations は Ctrl + Shift + i

Move Toは Ctrl + Shift + m

に設定しました。

＜実際の作業＞

ではいよいよ、具体的な作業に入ります。一番左の画像を、作業用画像の画面にドラッグ＆ドロップします。そうすると、その画像が表示されますので、まずはベースとなるこの画像の位置合わせをします。Move To機能を選択すると以下のような画面が表示されますので、ここでは1,1を入力して「OK」です。（これは0,0にはならないようです）

次に、これに位置合わせをしたい画像を以下のようにドラッグ＆ドロップします。

この状態でもドラッグして位置合わせをすることはできますが、これだけだとちょっと見づらいです。そこで、重ねた画像（レイヤー）を半透明化します。以下のようなサブウインドウが開いているはずですので、そこを見ると、重ねた画像と重ねられた画像がそれぞれ別々のレイヤーとして表示されています。そのうち、重ねた画像（_0033.jpg）の方をクリックしてから「不透明度」というところの100という数字を50に変更します。

そうしますと、以下のように、重ねた方の画像が半透明化します。これで、重ね合わせは格段に楽になりますね。

なお、レイヤーを移動させる際には、gimpの

「ツールボックス」で以下のような十字キーを選択しておく必要がありますので、ご注意ください。

さて、重ね合わせに関しては、以下のような感じになりますので、さらに動かして…

以下のように、大体ぴたっと位置合わせできたら、Layer informationsを起動すると、以下のようにXYの位置情報が表示されます。キーボードショートカットを設定していれば、Ctrl + Shift + i ですね。（私の設定の場合）

ここで、この情報X Y 情報と画像ファイル名をメモします。それを続けていくと、以下のようなリストができていくはずですが・・・

続きの作業のためにやっておくことをもう少しだけ見ておきましょう。

メモが終わったら、次は「レイヤーの削除」をして、位置合わせされる方の画像のレイヤーを削除しておきます。（そうしないと作業パソコンがメモリ不足になりますので）

次に、今回位置合わせした方の画像を基準にするために、その画像をレイヤーウインドウで選択してから、・・・

以下のように、Move Toを使って左上に移動しておきます。

このあとは、同じように、作業していきます。慣れたら1画像あたり1分ほどでできるようになりました。1絵巻あたり40分くらい、ということになると思いますので、資料の希少性を考えるとまあ妥当な線ではないだろうかと思えるような感じになりました。

さて、位置情報が一通り集まったら、次は、これにあわせた数値データを作成します。これをどういうツールで実行するかは好みによると思うのですが、私はこういうときにはついエクセルを使ってしまうので、とりあえず以下のような表を作成しました。A列が画像番号、B列とC列が今回手入力した相対位置情報、D列とE列が、IIIF Manifestに書き込むためのShared Canvas上での絶対位置情報ということになります。

　なお、ここでは、途中まではすでに完全手作業でやってしまっていて、その続きからになっているために、D1が16781、E1が272になっていますが、通常はこれらは0となるはずです。

あとは、これをIIIF Manifestの当該位置に書き込むだけです。ここでは、このデータを使ってIIIF Manifestの一部を作成する以下のような簡単なスクリプトを用意して、できあがったものをIIIF Manifestにコピーするということで完成させました。

　以下のスクリプトでは、上記のエクセル上のデータのタブ区切りファイル(imageloc.txt)を読み込ませて、必要なJSONデータを作成しています。

<?PHP
//% php thisfile imageloc.txt
$arln = file($argv[1]);
$n = 6;
foreach($arln as $ln){
 list($imgn,$x,$y,$x2,$y2) = preg_split("/\t/", trim($ln));
 if($imgn != ""){
  $imgn = sprintf("%02d", $imgn);
print <<<anoJson
                        ,{
                            "@id": "http://dzkimgs.l.u-tokyo.ac.jp/iiif/yang2/2540981/ano$n",
                            "@type": "oa:Annotation",
                            "motivation": "sc:painting",
                            "resource": {
                                "@id": "http://dzkimgs.l.u-tokyo.ac.jp/iiifimgs/yang2/2540981/2540981_00$imgn.tif/full/full/0/default.jpg",
                                "@type": "dctypes:Image",
                                "format": "image/jpeg",
                                "width": 8630,
                                "height": 8052,
                                "service": {
                                    "@context": "http://iiif.io/api/image/2/context.json",
                                    "@id": "http://dzkimgs.l.u-tokyo.ac.jp/iiifimgs/yang2/2540981/2540981_00$imgn.tif",
                                    "profile": "http://iiif.io/api/image/2/level1.json"
                                }
                            },
                            "on": "http://dzkimgs.l.u-tokyo.ac.jp/iiif/yang2/2540981/p1#xywh=$x2,$y2,8630,8052"
                        }
anoJson;
  $n++;
 }// if($imgn != ""){
}//foreach($arln as $ln){
?>

　さて、このような感じの作業をすれば、分割された画像を並べてMirador上で閲覧することができるようになります。横方向だけでなく、縦方向もいけますので、色々な可能性があろうかと思います。

ちなみに、全部重ねて一枚の画像にすればよいのに、と思う人もおられるかもしれませんが、横巾15万ピクセル近い画像を作成したりサーバに載せて公開したりするのは今時の普通のコンピュータ環境だと微妙に難しいです。（何度か挑戦してみてあまりうまくいきませんでした）

勢いで書いてしまったので、誤字脱字や読みにくいところもあるかもしれませんが、お役に立ちましたら幸いです。

Miradorの新機能で国デコの絵巻画像をつなげる（Manifestの書き方編）

　何度かご紹介してきた、Miradorに新規搭載されたLayer機能ですが、これを応用すると、複数に分割された画像をまとめて表示する、ということもできるようになります。ここでは具体例として、カルガリー大学の楊先生のリクエストにより、国立国会図書館デジタルコレクション（国デコ）の「絵師草紙」を試してみました。これは、以下のように分割撮影・公開されています。

具体的な手段を省略すると、これらの画像をIIIF Image APIに対応させて、Mirador用にIIIF Manifestファイルを作成すると、以下のようになりました。

実際にこの画面をMirador上で見てみたい方は、こちらのURLにアクセスしてから、画面の左上にある「絵巻の全画像を表示」というボタンを押してみてください。あとは、通常のMiradorと同じように、すいすいと拡大縮小できたりすると思います。

追記(20170718 1:30AM)：その後、「百鬼夜行絵巻」も試してみました。以下のURLにてお楽しみください。

http://candra.dhii.jp/nagasaki/mirador201706/mirador/hyakki.html

これまで、絵巻画像の公開で難しかったことの一つは、横長の超巨大画像をWebからまるごと効率的にアクセスできるようにするためのサーバの準備や画像処理など、だったのですが、このやり方ですと、サーバや画像処理に関しては、通常サイズの画像を扱うのとほぼ同じようにできることになります。まだところどころ課題はありますが、このように、個別画像を公開した上でビューワ段階で統合するという路線は微妙に革命的ではないかと個人的には思っているところです。

＜IIIF manifestの書き方＞

では、実際にこれをどうするか、という話に入りましょう。

まず先にIIIF Manifest全体をみせろ、という方はこちらをご覧ください。

基本的には、IIIF Manifestで、Shared Canvasを大きくとってそこに画像を配置していくという形になります。ここでは、以下のように、150000x8500ピクセルのShared Canvasを設定して、そこに個々の分割画像を配置するようにしています。ちょっと見づらいですが、

http://dzkimgs.l.u-tokyo.ac.jp/iiif/yang2/2540981/p1

というのがこのcanvasのIDで、その下位に各画像の情報が記述されています。

以下に、個別の画像の情報についてもう少しみてみると・・・

"on": "http....

で始まる行があり、その最後が

/p1#xywh=0,200,8630,8052"

あるいは

/p1#xywh=4415,119,8630,8052"

などとなっています。

この箇所で、「canvas上のどの位置にこの画像が来るか」を決めています。 この 位置情報を適切に記述すれば、よい、ということになります。

ただ、ここで難しいのは、画像を並べる際の座標情報をどう取得するか、です。特に国デコの場合に難しかったのは、画像の境目がぴたっとあわないことでした。これは、絵巻を浮いたままで押さえつけることなく撮影するという国立国会図書館のデジタル化の方針によるもののようですが（ただしこの話は伝聞です）、とりあえず、ぴたっとあわないので機械処理はちょっと難しそうです。

そこで、手で画像の位置合わせをしてその座標情報を取得する、という途方もない作業が必要であるように思えてきます。これをなんとかして効率的にできないものか（しかも手元にあるソフトだけで）、ということで、GIMPを使って比較的効率的に位置合わせ＆座標取得をするワークフローを作ってみました。次回記事にて、その詳細をお知らせします。

公開されているIIIFコンテンツを収集・共同編集するツールがリリースされました

メールマガジン人文情報学月報のイベントレポートで何度か触れてきましたが、トロント大学図書館の「写本研究のためのデジタルツール」プロジェクトで開発されていた、「既存のIIIFコンテンツを収集・共同編集するツール」が、ついに公式リリースされました。このツールに関するGithubのページに、使い方に関する説明も一通り用意されていますので（ただし英語ですが）、基本的な使い方はそちらを見ていただくとしまして、ここでは、そのインパクトを感じられるようなご紹介をしてみたいと思います。

　これまで筆者はIIIFの紹介をあちこちでしてきておりまして、その時によく言われたことは「Miradorでアノテーション付けられるのはいいけどそれは共有できるの？」ということだったのですが、それについての筆者の答えは

「今のところ標準ではローカルに保存されます。が、ちょっといじればサーバに保存して共有することもできます。詳しい人がいればなんとかなると思いますし、そういうことが簡単にできるツールをどこかで誰かが開発していると思いますのでちょっと待ってください」

というものでした。それは、去年の3月までのことでした。今年の3月に別件でトロント大学に行く機会があったので、すでに話だけは聞いていたこのプロジェクトのチームにアポをとってご訪問して、小さな勉強会を開催していただきました。お互いに自分のプロジェクトの紹介などをしつつも、主眼はこのプロダクトの開発状況でした。実際に聞いてみて、デモを見せてもらって、さらに、プロジェクト全体のなかでのこのプロダクトの位置づけの話を聞いて、これはなかなか良い感じだ、と思ったのでした。その後、テスト用アカウントも発行してもらって、色々試してみる機会も得られたので、上記の返答には

「トロント大学図書館でOmekaというメタデータCMSを核にしたシステムが開発されているのでそれを待ってみるといいかもしれません」

という一言が追加されました。

　実はこの数年、前期の授業の最後の方でOmekaを使った実習をしていたので、今年、間に合うなら、このシステムを使って授業をしたいと思い、「できれば6月末にはリリースしてほしいので頑張ってください」という希望を、先方に会うたびにお伝えして（5月にスタンフォード、6月にバチカンで会って話をしていたので）、ついに、ようやく、間に合わせてくださったのでした。予定より数日早くリリースを知らせるメールをいただいて、感動もひとしおでした。

このツールでできたものをご紹介（デモあり）

　前置きが長くなりましたが、まずは、これでどういうことができるのか、を画像入りでご紹介したいと思います。まず、こちらの地図（デモ用）を見て、地図上にプロットされたいくつかの青丸をクリックしてみてください。そうすると、以下のような感じのものを見る事ができると思います。

地図上にプロットされた情報が表示されます。ここでは錦帯橋の画像がMiradorの中に表示されています。

Miradorですので、以下のように、画像を拡大して錦帯橋の部分に注目することもできますし、地図も拡大することができます。もちろん、この画像の全画面表示もできます。

ここで出来ていることは大体以下のようなことになろうかと思います。

「国立国会図書館デジタルコレクションで公開されている電子化古典籍資料画像のIIIF版（次世代ラボより公開）がページごとに地図上にプロットされていてそれぞれの画像にアノテーションもついている」

「アノテーションやタグで画像の検索ができる」（下記の図を参照してください）

アノテーション検索

タグ検索

タグ検索結果から「釣り人」のページ＆タグの対象領域を表示

これはこれで良いのですが、しかし、これだけなら、「頑張って作りましたね、でも、デザインをもう少し工夫してもいいかもしれませんね」、ということで済んでしまう話です。このツールの話がそれだけでは済まないのは、

1．「IIIFで公開されているあらゆるコンテンツをアノテーションも含めて取り込んで、さらにそれにアノテーションやタグを追記したりしつつ地図上にプロットできる」

2．「この作業を、Web上で共同で、かなり簡単にできてしまう」

3．「このツールを含むWebシステムの構築も、かなり簡単にできてしまう」

という点です。そして、これを実現するためにOmekaとNeatlineという、クラスルームでの教育等にもよく使われているメタデータCMSを採用しているのです。Omekaの紹介やインストールの仕方、Neatlineのインストールの仕方については、以前にこのブログでもご紹介したことがあります。Omekaがメタデータを中心としつつ画像やその他のマルチメディアコンテンツをパソコンやサーバ上で管理したり公開したりするCMSであるのに対して、そのコンテンツを地図・年表上に簡単にプロットできるようにするプラグインがNeatlineです。Omekaのインストールが簡単であることもすでにご紹介したとおりなのですが、今回は、その簡単インストールと簡単操作で、世界中で公開されているIIIFコンテンツを簡便に扱うことができる、というのが大きなポイントなのです。IIIF Toolkitプラグインに関しても、Omekaに組み込むには、Omekaのpluginsディレクトリにプラグインのファイルを置いてzipファイルを元に戻してから、管理者画面から「Install」ボタンをクリックするだけです。

実際の編集作業（デモ無し・ご紹介のみ）

　では、実際にどういう風に操作できるのか、以下に見てみましょう。ただし、これには編集者権限が必要になりますので、デモは無しで、画像と文章のみでのご紹介です。

まずは、IIIFコンテンツの取り込みです。

以下の図では、国立国会図書館次世代ラボから公開されている国デコIIIF版のIIIF ManifestのURLを、URL欄にコピペしています。この後、ボタンを押すだけで、IIIF Manifestに含まれる画像・メタデータ・アノテーションが全部取り込まれて（全部できるのだろうか…と思っていたら、確認できている限りでは全部できていたので感動しています）、Omeka上でメタデータCMSのコンテンツとして操作できるようになります。ここでは練習用に、

国立国会図書館デジタルコレクション - 西遊街道図絵. [2]

のIIIF Manifestを使ってみています。

そして、取り込みが終了すると、ステータス画面は以下のようになります。

各ページにアノテーションをつけられるようになっていますので、まずは以下のように図の表題にアノテーションをつけてみます。ついでに、地名に関する情報をタグとしてつけておきます。ここで使っているのはMiradorの標準のアノテーションダイアログですが、ここで「保存」すると、OmekaのコンテンツとしてOmekaに保存されることになります。

付けたアノテーションも含めて、この画像を管理するページは以下のようになっています。取り込んだ資料の各画像ごとにこの画面が用意されることになります。

アノテーションのダイアログでつけたタグは、以下の画面で一覧して管理することができるようになっています。

さて、アノテーションをつけてみましたので、次はこれを地図上にプロットしてみましょう。地図はNeatlineです。「Create an Exhibit」をクリックしてその作業用の地図を用意します。これはいくつでも作ることができます。以下の図では、すでに一つ作ってあります。地図を編集するときは、地図名をクリックします（この場合は「An Exeercise for a DH Class）。

Neatlineの地図編集モードは、デフォルトでは左側に作業画面が表示され、画面の大部分は地図が表示されます。地図はデフォルトではOpen Street Mapですが、他の地図も設定で選択できます。作業画面では、既存のプロットされたデータと、「レコード新規作成（New Record）」ボタンなどがあります。

とりあえず一つ新規作成ということで、「New Record」をクリックしてから「Item」タブをクリックしてから少し待つと、以下のようにつけた順番でアノテーションが表示されていきます。今回試しに作業している画像には「尼崎城之図」というアノテーションをつけましたが、それが一番上に表示されるので（最新のアノテーションが一番上にくるような感じです）、それを選んでみましょう。

そうすると、選んだだけで、いきなりその画像がMiradorごと表示されます。つまり、そのアノテーションを含む画像がここで選択・表示されることになります。Mirador上では画像を拡大したり全画面表示したりして確認することもできます。とりあえずここでは「Save」を忘れないようにしておきたいところです。

次に、「Text」タブをクリックして情報を色々つけておきましょう。Slugは外部からアクセスできるようにするものですので、ASCIIで入力しておいた方が後々楽です。そして、タイトルや本文（Body）などを・・・

とりあえず以下のように入力してみてから「Save」をしてみました。

さて、次に、いよいよ地図上にプロットします。「Map」タブをクリックすると地図プロットモードになりますので、目当ての場所を探して、地図上に位置情報を入力します。単なる丸でいい場合は「Draw Point」をクリックしてから地図上の目指す場所をクリックします。一応、丸以外にも色々な形を選べるようになっています。

「Save」してから編集モードを閉じると（編集画面右上の×印をクリック）、以下のようになります。今、追加した、尼崎城の情報もリストされています。

その後、公開画面に戻ってみると、以下のように、尼崎城の位置に青丸がついています。この青丸をクリックすると・・・

ダイアログ上にMiradorが表示されてそのなかに画像が表示されますね。

もちろん、Mirador上ですので以下のように画像を拡大することもできます。お城の様子を想起させますね。

先ほどアノテーションをつけた箇所にカーソルをあわせると、Mirador上で以下のように表示されます。

さて、すっかり長くなってしまいましたが、大体このような感じです。このプロジェクト全体としては、ここでつけたアノテーションなどは、半自動的に、より大きなサーバに戻されて統合的に扱えるようにするという話になっているそうです。IIIF、というより、Webに公開されている文化資料・文化資源の高精細画像の活用の幅を大きく広げることになる可能性を感じておりまして、みなさまにも試してみていただく機会をご用意できたらと思っております。

　もちろん、少しでも腕に覚えのある人は、ぜひ試してみていただけたらとも思っております。DockerやVMwareでもばっちり動きましたし、既存環境にインストールするよりも、新しいWAMP/LAMP環境にインストールする方が大変簡単ですので、そういう方向でご検討してみていただくとよいかと思います。

なお、上記でリンクを張った、このプロジェクトのgithubのページでは、さらに別の使い方も紹介されていますのでご参考にしてみてください。

ということで、まだ、年表へのプロットなど色々あるのですが、そろそろ寝ないとまずいので、ここまでとしたいと思います。今後ともよろしくお願いいたします。

赤外線写真とX線写真を重ね合わせてみる：IIIFの活用例

前回記事の続きのようなものですが、しかし、これも大きなトピックかもしれないと思いましたので、記事を分割しました。

一つの画像に、赤外線写真とX線写真を重ね合わせてみる、というものも、汎用ビューワでできるようになったようです。まずはこちらをご覧ください。以下のような写真が表示されるはずです。

ここで、前回記事と同様に、左上の「Layers」というタブをクリックしてみてください。そうすると、X線と赤外線の画像がそれぞれ選択できる上に、透明度も調整できるようになっています。もちろん、同時に拡大縮小することも可能です。たとえば以下のような感じです。

このような用途の場合、各地の画像をどうこうするというのとはまた少し違った話になってきそうですが、標準的な規格とツールを使ってこのような表示ができるようになるということには、色々なメリットがありますので、これも今後に期待されるところです。

バラバラになった各地の西洋中世写本断片をまとめて表示：IIIFの活用例

また少し時間がたってしまいましたが、今回は、6月にヴァチカンで開催されたIIIFカンファレンスで仕入れてきた話を一つご紹介します。IIIFが当初目標としていた、「バラバラになって各地の機関に保存されている西洋写本の断片をまとめて表示する」という機能が、ようやく、IIIFの規格に基づいて、IIIF対応の汎用フリーソフトMiradorビューワを用いて可能になったようです。

まずは、こちらのURLをご覧ください。ここでは、以下のように、挿絵の部分が切り取られた写本の画像が表示されます。

ここで、画面左上の「Layers」というタブをクリックしてみてください。そうすると、以下のようなパネルが表示されるはずです。

ここで「visible」というチェックボックスをクリックしてみてください。そうすると以下のようになって…

切り取られた挿絵のところに以下のようにしてこの絵が表示されました。

挿絵のところを拡大してみてみましょう。

この挿絵が本来ここに来るべきものなのかどうか、筆者にはよくわからないのですが、このような機能のデモンストレーションとしては十分ではないかと思います。今回はフランスの国立図書館が公開する画像とCNRSが公開する画像を組み合わせたということになっているようです。Manifestファイル（この資料の画像群の表示の仕方等を定義するファイル）のこのページの部分は以下のようになっていました。

ちょっと字が小さくて読めないかもしれませんが、ちゃんと見たい人は直接このmanifestファイルをご覧ください。IIIF Image APIで記述された二つの画像のURLを一つのキャンバスにリンクされています。書き方としては、もっとたくさんの画像を一つのキャンバスにリンクすることも可能であり、Miradorの今回のバージョンでは、実際に、もっとたくさんの画像を重ねあわせて、さらに透過度も変化させることができるようです。開発者の方々に大感謝です。

　これまでも何度も同じことを書いてきているようで恐縮ですが、10年前にはすでに、このようにして絵を重ね合わせる機能だけであれば、Webで提供することはできたはずです。しかし、IIIFが画期的なのは、その機能をオープンな共通規格として実現可能としたことであり、その規格がすでに世界中の多くの有力機関で採用されつつあるという点なのです。結果として、誰もがこのような機能を使って、世界中に点在する多様なデジタル文化資料を様々な形で自在に活用できる道を開いた形になっています。この重ね合わせる機能に関して言えば、今はまだManifestファイルを頑張って書かなければなりませんが、しかし、書き方は標準化されているので、近いうちに、これを簡単に書けるような仕組みを誰かが作って公開してくれるかもしれない、ということが期待されます。デジタル文化資料の活用において、オープンな共通規格の重要性は、これからますます明らかになっていくだろうと思っております。

 　なお、今度、7/27の午後に、人文学オープンデータ共同利用センター（CODH）にて、IIIFを主に扱うセミナーが開催されます。会場は、国立情報学研究所（NII）、です。そちらでは、こういった話を、私だけでなく、色々な専門の方々がそれぞれの視点からお話してくださる機会になりますので、なかなか稀有な機会になると思います。お時間がございましたらぜひご参加ください。

写本や貴重書等の書誌情報の書き方について(TEI/XMLのご紹介)

　最近、メタデータの書き方について相談を受けることが多いので、今回は、写本や貴重書的な資料の書誌情報の書き方に関して、ちょっと事例を紹介させていただきます。

　テクスト資料のデジタル化に関しては、いわゆるISOのような規格ほどかっちりとしたものではないのですが、人文学資料向けに TEI (Text Encoding Initiative)というガイドラインが公開されています。これは、人文学資料向けというくらいですので、希望すれば非常に細やかな構造化が可能で（しかし浅い構造化もできて）、対応可能な分野も様々です。（たとえば、コーパス言語学では各単語の属性に着目しますが、古典文献学ではどちらかというと書誌情報や異文に着目する、という風な違いがあります。）

　このTEIガイドラインでの構造化は、現在はXMLで行うのが主流になっています。TEIガイドラインは、本来は特定のマークアップ言語に束縛されるものではなく、当初はXMLの前に使われていたSGMLというマークアップ言語に準拠したものでしたが、XMLが策定されるにあたってコンセプトのレベルで貢献した上、XMLの策定後数年で、自らもXMLに移行した、という経緯を持っています。

　といっても、この動向はほとんど欧米で展開されてきたため、欧米・中東近辺の文献には比較的強いですが、それ以外の地域となるとまだ十分に対応できていません。それをなんとかするための動きがようやくアジア地域の研究者によって始まってきているところですが、そのご紹介はまた別の機会にして、今回は、TEIガイドラインの事例として紹介されている書誌情報の書き方についてちょっと見てみたいと思います。

　日本で書誌情報、と言えば、OPACに入るような情報や資料調査に入った方々の調査票など、様々なものがあります。もちろん欧米でも、すべての機関が同じやり方をとっているわけではないようなのですが、TEIガイドラインでは、なるべく担当者・利用者のニーズにあわせた詳細な書誌情報にも対応できるように、ということで、深い情報も書き込めるようなルールを提供しています。（なお、TEIガイドラインのエレメント名、属性名、それぞれの一言解説に関しては、鶴見大学の大矢一志先生が日本語訳を提供してくださったおかげで大部分は日本語でも参照できるようになっています。）

　これを理解するのに役立ちそうなエレメントとして<history>がありますので、TEI P5ガイドラインからその利用例をちょっとみてみましょう。これは、以下のように、オックスフォード大学ボドリアン図書館に所蔵されている手書き資料の目録をTEIガイドラインに従って記述（構造化）したというもののようです。（私の理解は十分ではないかもしれないので、修正すべき点がありましたらご教示ください）

この書誌情報には<history>という要素が含まれており、以下のようになっています。

ここでは、いわゆる来歴情報が書かれていますが、来歴の中で、<orgPlace>や<orgDate>などといったタグを用いて、最初にいつどこで書かれたかという情報がマークアップされています。<quote>というタグもありますので、何らかの引用ではないかと思われます。ただ、これだけですと、ちょっと情報量が少ないような感じがしますね。

おそらく、上記の<history>をさらに詳細にマークアップしたと思われる例も掲載されていましたので、ちょっと見てみましょう。

これをみると、来歴情報の本文が、まず<origin>と<provenance>と<acuisition>という風に分かれています。これで、出所の情報か、それがどこを渡ってきたのか、どうやって入手したのか、ということがそれぞれ機械可読（≒コンピュータが読んで処理できる形式）になっています。機械可読になっているということは、人にとっても読みやすい、つまり、この情報を元に、自動的にきれいなレイアウトを作って人が読みやすい形に提示することもできますし、もちろん、コンピュータが、複数の資料から出所情報だけ、あるいは入手情報だけを取り出して統計情報をとったり、それもまた人が見やすいように地図・年表上にマッピングしたりすることもできるようになります。

　そして、<origin>の中を見てみると、ここでは13th cent.となっているものに関して、「notAfter="1300"」、つまり1300年以前、ということが、機械可読の形でXMLの属性・属性値として追記されています。こうしておくと、13th cent.という表記はそのままにしておきながら、この表記が何を意味しているかをコンピュータに解釈させるためのプログラムを作成するという手間を省き、かつ、正確な情報をコンピュータに渡せるようになります。

　それから、次はその後の来歴ということで、<provenance>タグで囲まれた文章があります。ここでは、引用がラテン語であることが<quote>の属性として xml:lang="la"と記載されています。（これはISO639に基づくことになっています）言語の自動判定というのは、文章が短いとなかなか難しいのですが、このように書いておくと、自動判定に失敗したというような問題に悩まされることはありません。（もちろん、これには一長一短があります）。

　最後に、入手した際の情報が書かれています。これもまた興味深いものがあります。<name>タグで囲まれているのが、人名ですが、人名の表記には、略称も含め様々な表記があり、一括検索するのはなかなか難しいことがあります。この目録では、<name>タグに属性としてkeyを用意して、おそらく、この人物と同じ人物については、表記の如何に関わらずkey="MCRAYWD"としているのだろうと思われます。そうすると、あとからこのデータを見たり検索したりする人やコンピュータにとって、表記の仕方が違っていても同じ人物としての同定が簡単かつ確実になります。人物同定は、ある程度知識のある人でなければ難しいことですので、その知識を明示して継承できるようにするという意味合いもあるでしょう。（※XMLに詳しい人への補足としましては、このkey属性は、TEI/XMLではむしろ他のところで定義された人物情報のxml:idを参照する形でsameAsという属性を使用する例が多いように思います）。入手した日付に関しても、<date>エレメントのwhen属性としてW3C-DTFの形式で記述されており、これも記述の一意性を提供することで人にもコンピュータにも理解しやすいものとなっています。

　このように、来歴情報などに関しても、必要に応じてきちんとマークアップしていくという方法をTEI/XMLでは提供しています。データ公開・検索等の実際の運用では、たとえばDublin CoreのDescriptionのあたりにこれらをまとめて入れてしまうという手もあるかもしれませんが、いずれにしても、特定のフォーマットにあわせて書誌情報を記述していくというよりはむしろ、コンピュータに処理させたい、さらに言えば、他の人や後の人にも、ある程度明確な定義を伴う形で自分の知っている知識を継承したいという目的でTEI/XMLは用いられることがあり、そのような方向で発展してきている面があるということが言えるだろうと思います。このようなやり方が日本の古典籍・古文書等でも役に立たないだろうか、ということを日々考えておりますので、もしご関心がおありの方がおられましたらぜひお声がけください。

　ところで、この部分的なマークアップの説明からもわかるように、TEI/XMLでは、多様なマークアップの深さを許容しています。この点は他の諸々の規格と大きく異なるところではないかと思います。また、上記の2例のうち、最初の方は、<history>の内部を、どちらかといえばコンピュータに自動的に読み取ってもらうことを期待するやり方であり、二つ目の例は、人間が確実に記録してコンピュータに正確に読み取らせることを意図したやり方であるとも言えるでしょう。TEI/XMLが1987年から続いているものであることに鑑みるなら、当初は後者のやり方ですべて人が行うことが重要であったように思われますが、近年では、自動読み取りもそれなりの正確性を持つようになり、そのような状況では、2つめの例は、むしろ自動読み取りソフトウェアのための学習用データとして用いるという可能性も考えられるところです。また、写本・貴重書等の書誌情報では、大規模処理というほど多くのデータが集まらない可能性もあり、その場合にはむしろ、一度コンピュータで諸々の情報を判定させた後に、人が手で修正し、その結果を2つ目の例のフォーマットで書き残せるようにする、という方法もあるかもしれません。

　それから、ちょっと話が飛びますが、このようなマークアップを実際に作業する場合、普通のエディタで作業するとタグの入れ子関係等がおかしくなった時の確認などになかなか大変です。これを支援するためにXMLエディタというのが色々出ています。筆者は、商用ソフトではありますが、oXygen XML Editorというソフトウェアを使っています。（一応、30日間の無料使用期間があります）このソフトはXMLだけでなくJSONやその他色々なフォーマットの処理ができる上に、TEI/XMLのスキーマも標準装備していますので、初期設定も簡単です。タグ補完機能やフォーマットのチェックなどで非常に充実した機能を持っていますので、とりあえず初心者にはこのソフトをおすすめしています。とはいえ、このソフトは、使い方がわかるととても便利なのですが、最初のハードルが結構高いです。ので、この数年、無料講習会を各地で行っています。ご興味がおありの人がおられましたら、3人以上集まるならおうかがいして講習などいたしますので、ぜひお声がけください。

IIIF画像配信の高速化のために（HTTP2の可能性と課題）

HTTPSに関して説明する必要はもうあまりないと思います。Webで暗号化通信とサイトの身元保証をしてくれる仕組みですね。これまで、HTTPSは、主に送信されるデータに比較的高度なセキュリティが必要な状況、たとえばパスワードを送信する時などに主に使われてきたように思います。しかし、最近、IOSアプリでHTTPS通信が義務化されることが話題になり、通常のサイトでも必要になってきているような雰囲気が出てきています。

　IOSアプリのそのような動向の一方で、通常のパソコン用のWebブラウザでも、HTTPSのサイトを閲覧しながらWeb API的な形で他のサイトのデータをとってくるような仕組みを用意しようとした時には、セキュリティを高めるために他のサイトもHTTPSでなければならない、という縛りがかかるようになりました。ここで具体的に影響を受けるのは、Mirador等のIIIFビューワです。HTTPSのサイトに設置されたIIIF Viewerからはhttpsで配信されている画像しか見えないのです。そして、最近いよいよHTTPSのサイトが増えてきましたので、なんとか対応する必要に迫られそうになってきております。今からIIIFを導入する予定の人／組織は、HTTPSも必須だと思っておいていただいた方がよいと思います。

　今のところ、大手の中では、gallicaのIIIF画像はまだHTTPS化されていないのですが、これも、関係者はHTTPS化の必要性を認識しているようでしたので、そのうちHTTPS化されるのだろうと思います。

　そこで、せっかくHTTPSに対応するのだから、ついでに、画像配信が速くなるというHTTP2も導入できないかと色々調べてみました。

その結果、わかったことは、筆者が使っているRedHat LinuxやCentOSでは少々難しいようである、ということでした。というのは、OpenSSL1.0.2以上でないとブラウザ側がうまく対応できないことがあるらしいのですが、RedHat LinuxaやCentOSでは、まだOpenSSL1.0.1対応のものばかりで、いくつかのメジャーなRPMリポジトリを見てみましたが、まだOpenSSL1.0.2以上に対応しているものがないようなのです。Ubuntuの新しい方なら大丈夫、とのことなのですが、サーバにUbuntuを入れ直すのも大変なので、さてどうしたものかとしばらく止まっていました。

とりあえずHTTPS化だけはしなければ、ということで、最近話題のLet's Encryptを使って試しに設定してみたところ、今までの苦労はなんだったのか、というくらい、拍子抜けするほど簡単でした。これは所定のガイドに沿って作業するだけでできてしまうので、画像配信にしか使っていないサーバであれば、試してみるとよいかと思います。

さて、しかし、HTTP2にすると速い、という話をさんざん聞くので、画像配信をもう少し速くしたいと思っていたこともあり、結局、ソースコードからコンパイルという禁断の方法に手を出してしまいました。何が禁断かということ、セキュリティアップデートなどの際に、再度自分でソースコードからコンパイル・インストールを毎回やらねばならなくなるからです。20年前は一生懸命やっていましたが、これだと継続性に問題が生じがちなので、10年ほど前にはほとんどやらなくなり、パッケージからインストールするようになっていました。（意味がわからない人のために簡単に説明しておくと、Windowsアップデートのたびに必要なソフトを一つずつそれぞれのサイトからダウンロードしてインストールして設定も個々に行って、さらに互換性も自分で確かめる、というようなことになります。）　ですので、企業等に今の段階でこれをお願いする場合は、追加料金を結構払わねばならない場合があることに留意しておいてください。あるいは、仕様書にHTTP2と書いてしまうと、見積額が少々高くなる可能性があります。もちろん、発注の規模次第ではそんなに差はでないこともあると思いますが。

前置きが長いのは、HTTP2に関しては、今のところは安易に導入を決めないようにしていただきたいからなのですが（でも、これにごく安価に対応できる企業さんがおられたらお知らせいただけるとうれしいです）、それでも、画像配信は多少はやくなるようです。一つのサーバで、HTTP1.1、HTTPS+HTTP1.1、HTTPS+HTTP2で、IIIFビューワMiradorを設定して91個のファイルを一気に配信されるようにした時の計測結果は以下のような感じでした。サーバソフトはApache 2.4.25、サーバOSはCentOS7.2、opensslは1.0.2k、という感じでした。

HTTP1.1	3.742857143秒
HTTPS + HTTP1.1	4.511428571秒
HTTPS + HTTP2	3.8秒

7回アクセスして平均値をとってみています。こうしてみてみると、HTTPS化して遅くなった分をHTTP2で取り返す、というような感じになっているようにみえます。さらにアクセスが増えてくるとまた違う結果になるかもしれません。また、Nginxを使えばもっと速いかもしれません（今回は既存サービスとの互換性を考えてApacheにしてしまいました）。もう少しよい調査方法を試してみることができたら、またちょっとご報告してみたいと思います。

さて、このインストール方法ですが、とにかく必要なソースコードをダウンロードしてコンパイルしてインストール、設定、を繰り返しました。具体的な内容については、また次回記事にてご報告させていただきます。