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

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

 

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

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

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

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

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

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

 

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

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

f:id:digitalnagasaki:20170704015202j:plain

 

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

f:id:digitalnagasaki:20170704015241j:plain

 

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

f:id:digitalnagasaki:20170704015540j:plain

 

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

 

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

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

 

アノテーション検索

f:id:digitalnagasaki:20170704015703j:plain

 

タグ検索

f:id:digitalnagasaki:20170704015735j:plain

 

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

f:id:digitalnagasaki:20170704015914j:plain

 

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

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を使ってみています。

 

f:id:digitalnagasaki:20170704020151j:plain

 

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

f:id:digitalnagasaki:20170704020232j:plain

 

 

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

 

f:id:digitalnagasaki:20170704022302j:plain

 

 

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

 

f:id:digitalnagasaki:20170704022447j:plain

 

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

 

f:id:digitalnagasaki:20170704022600j:plain

 

 

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

 

f:id:digitalnagasaki:20170704022630j:plain

 

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

 

f:id:digitalnagasaki:20170704033931j:plain

 

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

 

f:id:digitalnagasaki:20170704022810j:plain

 

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

 

f:id:digitalnagasaki:20170704022832j:plain

 

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

 

f:id:digitalnagasaki:20170704022958j:plain

 

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

 

f:id:digitalnagasaki:20170704023104j:plain

 

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

 

f:id:digitalnagasaki:20170704023237j:plain

 

 

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

 

f:id:digitalnagasaki:20170704023328j:plain

 

 

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

 

f:id:digitalnagasaki:20170704023412j:plain

 

 

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

 

f:id:digitalnagasaki:20170704023522j:plain

 

 

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

 

f:id:digitalnagasaki:20170704023549j:plain

 

 

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

 

f:id:digitalnagasaki:20170704023616j:plain

 

 

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

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

 

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

 

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

 

 

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

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

 

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

 

f:id:digitalnagasaki:20170703032849j:plain

 

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

f:id:digitalnagasaki:20170703032816j:plain

 

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

 

 

 

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

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

 

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

f:id:digitalnagasaki:20170703024705g:plain

 

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

f:id:digitalnagasaki:20170703024834g:plain

 

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

f:id:digitalnagasaki:20170703024913g:plain

 

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

 

f:id:digitalnagasaki:20170703025002g:plain

 

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

 

f:id:digitalnagasaki:20170703025026g:plain

 

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

f:id:digitalnagasaki:20170703030012g:plain

ちょっと字が小さくて読めないかもしれませんが、ちゃんと見たい人は直接この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ガイドラインに従って記述(構造化)したというもののようです。(私の理解は十分ではないかもしれないので、修正すべき点がありましたらご教示ください)

f:id:digitalnagasaki:20170524211022p:plain

 

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

f:id:digitalnagasaki:20170524171927p:plain

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

 

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

f:id:digitalnagasaki:20170524172137p:plain

これをみると、来歴情報の本文が、まず<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 LinuxCentOSでは少々難しいようである、ということでした。というのは、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にしてしまいました)。もう少しよい調査方法を試してみることができたら、またちょっとご報告してみたいと思います。

 

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

IIIF対応ビューワMiradorの最新版に右⇒左ページめくり方向を実装してみました(5/8追記あり)

IIIF対応ビューワの代表格の一つ、Miradorですが、アノテーション機能と複数画像同時表示機能という大変便利な機能を提供してくれている一方で、右から左へのページめくりに対応していないため、東アジア系の資料に適用することがなかなか難しい状況でした。以前に、対応版を作ってみましたが、ちょっと機能的にいまいちでしたので、改めて、最新版をもとに追加しなおしました。それがこちらです。

Mirador Viewer

…と言っても、これだけですと、Miradorの使い方を知っている人でないとあまりよくわからないと思います。そこでご用意したのが以下のものです。

http://candra.dhii.jp/nagasaki/mirador20170506/mirador/index2.html

右から左へのページめくりと、左から右へのページめくりが一つのビューワで混在できていると思います。ただし、「ギャラリー表示ビュー」のサムネイル一覧だけは、残念ながらまだ対応できていません。力不足で申し訳ありません。(どなたかやってみていただけると大変ありがたいです)

※もう少し調べてみたら、できました!というわけで、以下のものが完成版(?)です。

http://candra.dhii.jp/nagasaki/mirador20170507/mirador/index2.html

 

 

慶応大学メディアセンターデジタルコレクションのIIIF対応画像も、これで右から左のページめくりができるようです。Miradorの使い方をある程度ご存じの方向けになってしまいますが、たとえば以下のIIIF Manifestかdrop iconなどをお試ししてみてください。

http://dcollections.lib.keio.ac.jp/sites/default/files/iiif/NRE/110X-274-3-1/manifest.json

IIIF Drag-n-drop

 

なお、ビューワ自体をダウンロードしたい場合はこちらからどうぞ。(.tgz形式です)

 

それから、この仕組みについて、少しだけ御説明しておきますので、まだご存じないという人で、かつ興味がある人はちょっと読んでみてください。

 

まず、IIIFでは、一つの資料ごとに「IIIF Manifest」というファイルを用意することになっています。IIIF Manifestは、JSON-LDというWebで今流行しているフォーマットに基づいて書かれているものです。JSON-LDは、World Wide Web Consortium (W3C) で定められている規格であり、このフォーマットに従うことでJavascriptのプログラムがデータ間のリンクを簡単かつ効率的に解釈できるようになります(この説明は簡潔すぎてちょっと語弊があるかもしれませんのでご注意ください)。そして、JSON-LDに従ってどういう内容を書くべきか、ということについてはIIIF Presentation APIにおいて規定されています。(もう一つ関連する重要な話としてWeb annotationというデータモデルがあるのですが今回はそれについては省略します。)

 このIIIF Presentation APIでは、プロパティと値、という形で、一つの資料に関する様々な情報をIIIF manifest記述してブラウザに渡すことになります。資料に含まれる各ページ画像のURL、資料のメタデータ、資料に付与されたアノテーションのURL等がここには含まれることになります。資料の提供者やライセンスの情報もここに書き込むことになります。Webブラウザに読み込まれたIIIF対応ビューワは、このIIIF Manifestを受け取って、必要な画像やその他の情報を集めて、適宜整形してWebブラウザ上に表示することになります。

 さて、このIIIF Manifestに書いてもよいプロパティの中でviewingDirectionというプロパティがあります。これによって、一つの資料に含まれる画像を見ていく方向を規定できるようになっています。日本語資料のように右から左にページをめくっていく資料の場合には、"viewingDirection:right-to-left"と書くことになっています。IIIFという規格では、このようにして、右から左にページをめくっていく日本語等の資料にも対応しています。

 しかし、これは、あくまでも、規格上の記述の仕方の話です。このように記述しておけば、あとは、利用者側(で使っているビューワ等のソフトウェア)がそれを読み込んで右から左にページめくりできるようにすればよくなるのですが、そのビューワは誰が用意するのか、という話が次に出てきます。

 実は、IIIF対応ビューワの代表格の一つであるUniversal Viewerであれば、すでにその機能が実装されています。()ただ、Universal Viewerも優れたビューワの一つではあるのですが、こちらだと、せっかくつけたアノテーションが表示されなかったり、複数画面表示ができない、といった感じで、やや不足感があります。そういう機能を使ってみたければ、やはりMiradorをなんとかしなければ、ということになります。そこで今回、改めて、新しいMiradorにこの機能を組み込むことに挑戦してみたのでした。

 基本的には、ページめくりに関しては画像の順番の変更、サムネイル画像の並べ方に関してはCSSのdirection:rtlで対応しています。ページめくりに関しても、ページめくり矢印の機能を左右逆にするだけでもよかったかもしれないのですが、以前に実装した際にすでに画像の順番変更で対応してしまっていたので、その続きということでそのようにしてしまいました。ページめくり矢印の機能を逆にする実装の仕方もおいおい検討してみたいとも思っております。

 

 なお、このIIIF Presentation API及びIIIF Manifestについてより理解を深めたい人は、LOD Diaryの神崎正英さんによる連載をぜひご覧ください。

デジタルアーカイブ学会設立総会に向けて期待すること

さて、本日は夕方からデジタルアーカイブ学会設立総会に参加する予定です。すでにWebサイトには「デジタルアーカイブ学会設立趣意書」が公開されていますので、目指す方向はここで提示されているものと思われます。

 これを拝見してまず思ったことは、学会に副題をつけるとわかりやすくなるかもしれない、ということです。たとえば、「デジタル知識基盤社会のための政策形成に向けて」などといったような感じです。「デジタルアーカイブ」という呼称だけだと、「何がデジタルアーカイブか」という終わりがなく生産性の低い議論を呼び起こしがちなので、それを避けるための一工夫があるとよいのではないかと思ったところです。

 趣意書を私が理解したところでは、かつてキャリア官僚が、最近はシンクタンクが担ってきたようなことを、これからは学会が担うのだ、という話のように読めます。かつて県立大学の教員をしていた頃に地方自治体で某総研会社の人と仕事をした身としては、確かに、シンクタンクの力は大きくて、しかもそこにそれなりのお金も流れているようだった、ということを思い出しつつ、ああいう仕事を学会と名付けられた組織が担うことが可能なのだろうか、ということは若干気になるところではあります。知る限りでは(すごく狭い経験ですが)、シンクタンクは、調査力だけでなく見せ方が上手で、そこにも相当のリソースを投入しているであろうことが想像されますので、それにとって代わろうとするなら、同じ事を肩代わりする必要はないにせよ、相当な説得力のある何かは提示できる必要があろうかと思います。それが、「中央省庁から民間企業、地域の草の根の活動までが、高い次元で車座的に話し合い、共に考え」ることなのだろうと想像していますが、そのような場をどういう風に形成していくのか、今後に期待したいところです。

 それから、「デ ジタルアーカイブに関わる諸学会、研究者を繋ぎ、共通の認識基盤を形成しながら、こうした具体的課 題に取り組んでいきます」とのこと、設立準備委員会が主導してこれを進めているのだと思いますが、これについては、とにかく、うまくやっていただけたらと思っております。

 最後の段落では、すべてのステイクホルダーへの呼びかけ、価値のあることだと思います。難しいことではありますが、声が大きな人だけでなく、関係者皆が参加意識を持てるような形になってもらえたらと思っております。ちょうど10年前に、この種のステイクホルダーの問題について人文科学とコンピュータシンポジウムで発表したことがありますが(「人文科学のためのデジタル・アーカイブにおけるステイクホルダー」)、この趣意書での議論は政策としての基盤というところから立ち上げていこうということなので、話としてはもっと大きくなるのだろうと思います。この種の問題に技術・実務・研究の面からそれなりの期間関わってきた経験からしますと、とりわけ、人事ローテーションでたまたまデジタル知識基盤に数年間の仕事として関わる人たちと、仕事でデジタル知識基盤を利用するユーザや所蔵者、創作者、提供者、作成者(企業含む)等の立場でずっと仕事として関わり続ける人たち、それから、たまにちょっと関心を持ったときだけ利用するようなライトユーザ(これは、ヘビーユーザと区別すべきでない、という議論もありますが、区別した方が良い状況が確かに存在します)との感覚の違いをうまく乗り越えて議論できるような場を作ってくださるとありがたいと思っております。