Goobi3.0 続編:画像チェック・メタデータ付与・IIIF閲覧編

さて、前回前々々回の記事に続き、デジタルアーカイブにおけるメタデータ作成と画像チェックを飛躍的に便利にするコラボソフトウェア、Goobiの使い方です。前回までの手順を経て、ようやく具体的に画像をチェックできるところまできました。画像チェック画面には、先ほどの「Process details」の「List of tasks」の中で、「Quality Control」のところで「Execute plugin」アイコンをクリックすることで入れます。そうすると、前回記事の最後にアップロードした画像が以下のように表示されます。画面右側に拡大縮小回転可能な大きめの画像を表示し、左側はサムネイルです。これで画像に問題がないかどうかチェックすることになるようですが、

f:id:digitalnagasaki:20190424044415p:plain

 

サムネイルにカーソルをあわせると以下のように部分拡大されるという便利機能もあります。

f:id:digitalnagasaki:20190424044422p:plain

 

さて、これも終わったら、Process detailsに戻り、List of tasksの次の項目として「Image processing」の「Execute plugin」アイコンをクリックしておきましょう。(でもこの操作は不要かもしれません。要確認)

 

なお、各taskには「Status」という項目がありますが、これは自動的にどうにかなるものではなく、作業者がメモしたり申告したりするために手動で切り替えるようです。作業中・完了・などといった状況を選べるようになっています。

f:id:digitalnagasaki:20190424044951p:plain

 

あとは、「Metadata enrichment」というタスクがありますが、これは一度Processの一覧に戻ると、一覧の右側に「Edit metadata」というアイコンがありますのでこれをクリックしてメタデータ編集画面に入ります。

f:id:digitalnagasaki:20190424045458p:plain

メタデータ編集画面では、やはり画像を閲覧しながらかなり詳細なメタデータをつけられるようになっています。

f:id:digitalnagasaki:20190424045335p:plain

さて、これも終了したら、いよいよ「Export」です。これもやはり、Processの一覧の右の方にある「Export」アイコンをクリックすると・・・

f:id:digitalnagasaki:20190424045526p:plain

うまくできた場合、画面の左上の方に以下のようなメッセージが表示されます。

f:id:digitalnagasaki:20190424045641p:plain

 

これで、IIIFで閲覧できるようになります。閲覧は、ビューワモードでの閲覧になります。以下のURLにアクセスしてみてください。

 

http://localhost:8888/viewer/

 

そうすると、右側の「New objects」等に、今回作成した資料のタイトル等が表示されるはずです。このタイトルをクリックすると・・・

f:id:digitalnagasaki:20190424045931p:plain

 

以下のような感じで、エクスポートした資料がGoobiのIIIF対応ビューワで閲覧できるようになります。ただし、ローカルのパソコン上で作業している場合、外部からアクセスさせるのはちょっと大変です。(不可能ではないですが、かなり面倒です)。IIIF対応ローカル表示、と割り切るか、あるいは、IIIF対応で一般公開までしてしまいたければ、Webサーバを兼ねたコンピュータ上でGoobiを動かすという手もあるでしょう。

 

f:id:digitalnagasaki:20190424050046p:plain

 

さて、ここまでで、Goobiを使った作業については大体把握できたかと思います。無料で使えるソフトウェアを、ダウンロードしてダブルクリックしただけで、ここまで高度な作業ができるようになっているというのは、インターネット老人会会員としては、もはや驚く以外のことをあまり思いつかないですが、先進国で流通するこのような利便性の高い高度なソフトウェアと整備されたワークフローの恩恵を、日本でも少しでもたくさん受容できるようにして、日本人のワークライフバランスの向上に貢献できればと思っているところです。

 ただし、Goobiの最大の魅力は実は今回ご紹介した点ではなくて、こういう作業を、管理者・作業者に権限を分けつつ進捗管理できるようにする機能です。これが出来ると協働作業の進捗管理が非常に効率化できるのですが、その仕方まではまだ十分に確認できてないので、また機会がありましたら確認&お知らせできればと思っております。

 また、特に細かいTips的なことも多少蓄積されてまして、それも(できれば)進捗管理の仕方とともにお知らせしたいと思います。

 

なお、再掲になりますが、この一連の作業手順は、3月のデジタルアーカイブ学会公式懇親会後の非公式な集まりにて、以下のメンバーにて確認したものです。(敬称略)

 大西亘(神奈川県立生命の星・地球博物館)、岡田一祐(国文学研究資料館)、亀田尭宙(京都大学)、中西智範(早稲田大学)、中村覚(東京大学)、宮本隆史(東京大学)+永崎

 

 こういうものの動作手順の確認は、普段は一人で取り組んで煮詰まってしまいがちなところ、このときには皆でわいわい楽しく進めることができましたので、個人的にも貴重な経験でした。

Goobi3.0 続編:基本的な使い方:準備編

ずいぶん時間が経ってしまって大変申し訳ありません。前々回の記事の続きです。みんなで動作確認できたはずだったのですが、改めてやってみたらまたうまくいかなくなってしまってしばらくハマってました。が、そのおかげでさらなるTipsも得ることができましたので、変な穴にはまらないようなインストラクションを作ることができそうです。

 

ということで、いよいよ、Goobiの基本的な使い方です。全体的な作業の流れは前々回記事を参照してください。

 

まず、前回記事を引用しますので、インストール⇒ログインまでいってみましょう。

 

一応日本語でも書いておきますと、Goobiのダウンロードは以下のURLからです。

http://files.intranda.com/g2g5

g2g5.zipというようなファイルがダウンロードできますので、このzipを元に戻します。(ダブルクリックするだけだと、うまく起動しません。きちんとファイル圧縮解凍ソフトを使って解凍してください。)

そこでできたフォルダを開くと、 GoobiToGo.jarというファイルがあるはずですので、それをダブルクリックします。それで起動します。なんと、たったこれだけです。

Java8を使っているようですので、Java8環境がなかったり、Java環境のパスがおかしかったりすると動かないこともありますので、お気を付けください。

 

次に、このGoobiにWebブラウザでアクセスしてみます。以下のURLに、以下のLogin/ Passwordでアクセスしてみましょう。こちらは、画像に関する作業をしたり、作業を管理したりする画面です。

 

以下のようなログイン画面に、上記のID passwordでとりあえずログインしてみます。

f:id:digitalnagasaki:20190424034417p:plain

 

ログインに成功すると、以下のような画面が表示されるはずです。

 

f:id:digitalnagasaki:20190424034458p:plain


次に「プロジェクトを作る」ので、上部メニューバーから「Administration」⇒「Projects」を選びます。f:id:digitalnagasaki:20190424034728p:plain

すが、ここで注意しておきたいのは、いきなり「新規作成」しないことです。(ここで私はハマりました。)この「project」は設定項目が結構多く、それらをきちんと設定しないとエクスポート後の表示がうまくいかなかったり、色々制約があります。そこで、既存のProjectを複製してから名称や内容を変更する、という風にしてみます。Projectリストの右の方に、 Duplicate projectというアイコンがありますのでそれをクリックしてみてください。そうするとそのプロジェクトのコピーが作成され、リストに追加されます。

f:id:digitalnagasaki:20190424034929p:plain

 

そうしましたら、わかりやすくするために、Project名を変更しておきましょう。追加されたコピープロジェクトの右側の方にある「Edit Project」アイコンをクリックすると編集モードに入ります。

f:id:digitalnagasaki:20190424035123p:plain

 

 

以下のような編集モードに入ったら、Titleやページ数、冊数、開始・終了日付など、適宜修正してください。終わったら右下の「Save」ボタンをクリックして保存しましょう。そうすると、自分が名付けたProjectがリストされているはずです。

f:id:digitalnagasaki:20190424035329p:plain

 

次に、Process templateを作成します。これも、既存のものを複製するのが吉です。上部メニューバーの「Workflow」⇒「Process templates」を選んでください。

f:id:digitalnagasaki:20190424035746p:plain

 

そうすると、以下のようにProcess templatesがリストされます。以下の例は、すでにたくさんのtemplatesを作ってしまっていますが、デフォルトではManuscript_WorkflowとSample_workflowが表示されているはずです。

 

f:id:digitalnagasaki:20190424035827p:plain

ここでも、先ほどと同様に、いずれかをduplicate(複製)してから名前を変える、という方向でいきましょう。(一から作成すると、タスクを自分で設定しなければならないので最初は結構大変です。)

f:id:digitalnagasaki:20190424040300p:plain

 

Process templateの編集は以下のようなダイアログで行いますので、まずはタイトルをつけてください。それから、今回の場合、プロジェクトと紐付ける必要もありますので、「Project」の項目も記載します。と言っても、この入力欄は、クリックすると登録済みの Projectが一覧表示されますので、その中から今回利用するものを選ぶだけです。

f:id:digitalnagasaki:20190424040331p:plain

Process templateの編集が終わって、一覧画面に戻ってきたら、次はいよいよProcessの作成です。以下のボタンをクリックするとProcessの作成が始まります。このProcess一つが、一つの資料のメタデータ作成・画像チェックに対応するということになるようです。ですので、一つのProcess templateは、一つのコレクションの一つのタイプの資料に対応する(もしくは資料タイプ別の処理をしない場合は一つのコレクションに対応する)ということになるようです。

f:id:digitalnagasaki:20190424040842p:plain

 

さて、Processを作成すると、まずメタデータの入力を要求されます。以下のような画面です。ここで、ちょっと「おおっ」となるのは、米国議会図書館等のいくつかの機関/組織の資料識別子を入力すると、自動的にメタデータを入力してくれるようであるという点です。

f:id:digitalnagasaki:20190424041653p:plain

 

たとえば、米国議会図書館のLCCN(NDLにおける永続的識別子のようなもの)を入力すると以下のような感じです。ここら辺でWeb APIの意義のようなものも大きく実感されますね。

f:id:digitalnagasaki:20190424042113p:plain

LCCNは、たとえば、以下の画面は米国議会図書館での「妙法蓮華経」のページですが、左下を見ていただくと記載されているのがわかります。

f:id:digitalnagasaki:20190424042327p:plain

 

 

これで、processが作成されました。以下のような画面になりますので、さっそく「Open created Process」をクリックして先に進んでみたいところですが、

f:id:digitalnagasaki:20190424042523p:plain

上部メニューバーの「Workflow」⇒「Processes」で、一覧表示させることもできます。

f:id:digitalnagasaki:20190424041324p:plain

 

一覧表示させた場合、右側の「Edit process」アイコンを押してください。いずれにしても、以下のようなProcess details画面が表示されます。

 

f:id:digitalnagasaki:20190424042940p:plain

ここで、画面下半分の「List of tasks」に注目してください。ここでは、メタデータ入力や画像のチェックに関して、ステータスを記載しつつ、一つ一つ作業を進めていけるようになっています。(ようやくここまできました。)

 タスクのリストはデータインポート等色々ありますが、まずは「Scanning」からやってしまいましょう。Scanningの右の方にある「Execute plugin」というアイコンをクリックすると、画像アップロードが可能な画面に遷移します。

f:id:digitalnagasaki:20190424043247p:plain

 

以下の画面では、右上の「Files」という領域に注目です。ここで「Upload images」というボタンがハイライト(白抜き?)になっている状態で、画像ファイルアップロードができます。この領域の真ん中に「Select files」というボタンがありますのでこれをクリックするとファイル選択モードになりますが、Google Chrome等、一部のWebブラウザではここにファイルを1つでも複数でもドラッグするとアップロードが始まります。それができないブラウザの場合はファイル選択モードで画像を選択してアップロードしてください。

f:id:digitalnagasaki:20190424043342p:plain

 

アップロードしたファイルを確認したい時は、右上の「Upload images」ボタンの隣にある「Overview」ボタンをクリックします。そうすると、以下のようにアップロードされたファイル名がリストされ、削除することもできるようになっています。アップロードが終了したら、右下の「Exit plugin」ボタンをクリックしてScanningタスクを終了します。

 

f:id:digitalnagasaki:20190424043825p:plain

 

さて、ここまででようやく画像チェックの準備が整いました。長くなってしまいましたので、続きは次のブログ記事にて。

TEI P5ガイドラインの最新版(v3.5.0)でルビを。

 Goobiの記事の続きを書こうと四苦八苦していましたが、その間にまた色々別な仕事も入ってきておりまして、その関係で一つ便利なものを作りましたのでお知らせです。

 

 TEI P5ガイドラインは着々とアップデートを続けておりまして、現在はv3.5.0となっております。日本語訳も、エレメント・アトリビュートの説明に関しては、かつて鶴見大学の大矢一志先生がやってくださったものに、TEI協会東アジア/日本語分科会を中心とした翻訳会のボランティアによる追加作業が加わり、日本語でもずいぶん使えるようになってきています。

 ところで、TEI P5ガイドラインには、まだ「ルビ」がありません。既存のタグを流用することでなんとかしのいでいるところではありますが、「ルビ」という融通無碍なルールにぴたっとハマるエレメントは、やはり既存のものではちょっと難しいところがあります。ルビは、発音を示すものであることもあれば、意味を示すこともあり、もう一つの本文として扱うこともできます。それぞれの文章中での位置づけを既存のエレメントに対応づけるという方向性も考えられなくはないですが、それをしてしまうと「ルビ」の多義性を損なってしまうこともあると思います。作業効率から考えても「ルビ」は「ルビ」として扱った方が日本の文化的コンテクストには適切なのではないかと思うのです。

 

 そのようなことで、「ルビ」タグを使えるようにTEI P5ガイドラインをカスタマイズしたいのですが、もちろん、TEI協会ではカスタマイズのためのツール Roma を提供しています。このツールの使い方は、簡単なものですが、こちらの記事に日本語のものが用意してあります。で、ごにょごにょとカスタマイズした結果、以下のように記述できるようになりました。

<eaj:ruby>
 <eaj:rb>第一巻</eaj:rb>
 <eaj:rt>だいいっかん</eaj:rt>
</eaj:ruby>

これを使えるようにして、かつ、大半のスキーマの説明等も日本語で表示されるようにしたRNC形式のスキーマファイルはこちらにご用意しておきます。ダウンロードしてOxygen XML EditorなどでTEIファイルにスキーマ割り当てをすればルビタグを使えるようになります。

 ただ、ここで、一つ注意しておいていただきたいのは、カスタマイズしたスキーマを割り当てた際に、ルートエレメントを以下のように書き換える必要があるということです。

<TEI xmlns="http://www.tei-c.org/ns/1.0" xmlns:eaj="http://www.example.org/ns/eaj">

カスタマイズの際に追加した名前空間をルートエレメントに追記するということです。このままコピペしていただいても大丈夫かと思います。

 これで、「<eaj:ruby>はどこでも使えて、<eaj:rb>と<eaj:rt>はその中でのみ使えて、同時に後者2つがなければ<eaj:ruby>はエラーになる」という風に検証されるはずです。

 

 ついでに、Romaで作成したODDファイルもこちらに置いておきますので、このスキーマをよりよく改良したくなった人はぜひご利用ください。

 

 なお、TEIによる日本語資料の作成のための環境整備につきましては、TEI協会東アジア/日本語分科会のサイトで着々と進められています。日本語によるガイドラインや、青空文庫テクストのTEI化・ツールの作成など、徐々にではありますが、日本でもとっつきやすいものにしていく予定ですので、今後ともよろしくお願いいたします。

 

デジタルアーカイブでの画像の取り扱いにお悩みの方へ:Goobiその1

 2日間、京都大学で開催されたデジタルアーカイブ学会が終了し、みなさまそれぞれに課題を持ち帰られたことと思います。かくいう私も、色々な方の発表をおうかがいし、様々な示唆をいただいたところでした。具体的な実践の発表から得られる情報と教訓も、いつもながら貴重なものがありました。

 ところで、初日の懇親会の後、一部有志で集まり、Goobiというソフトウェアの使い方の検討会を行いました。参加メンバーは、敬称を略させていただきますが、大西亘(神奈川県立生命の星・地球博物館)、岡田一祐(国文学研究資料館)、亀田尭宙(京都大学)、中西智範(早稲田大学)、中村覚(東京大学)、宮本隆史(東京大学)+永崎という感じで、この便利なソフトを日本でデジタルアーカイブ関連の仕事をしている方々がみんなで使って仕事を効率化できるようにするには(=みんなで幸せになるためには)どうしたらいいのか、和気藹々と喫茶店で皆で深夜までノートPCを広げて知恵を出し合ったのでした。

 

 Goobiの説明は、以下のようになっています。

デジタル化プロジェクトのためのオープンソースソフトウェアです。Goobiを通じて、自由に定義できる生成プロセスを、モデル化し、運用し、管理できます。そして、多くの機関による日常業務で、デジタル図書館を構築するためのすべてのステップを扱うことに役立ちます。そこには、図書館の目録やスキャン、コンテンツベースの索引からのデータの取り込みや、デジタル保存、書物からオンライン展示に移行した際の一般的な標準フォーマットでの成果の配信が含まれています。

もう少し分かりやすく言うと、書物をデジタル撮影した場合に、その画像を一つずつ拡大縮小しながらチェックして、メタデータをつけて、IIIFで公開できるようにエクスポートするという一連の作業を行う際に、それらの工程をWebブラウザ上でできてしまうだけでなく、個々の工程がどれくらい進んだか、どういう状況か、といったことの管理までもWebブラウザでできてしまうシステムです。あんまり大きな規模の仕事だと、別途データベースサーバも用意しなければならないようで、ちょっと大変ですが、小・中規模であれば、Javaで書かれたプログラムをダブルクリックするだけで使えるようになりますので、おそろしく手軽です。これを知った時、欧州のデジタルライブラリアン・デジタルキュレイター・デジタル○○の人達(つまり日本で言うところのデジタルアーキビスト)のワークライフバランスはこういうソフトウェアによって支えられているのか!と感心した次第です。もちろん、公開用システムにはIIIFがばっちり組み込まれており、やはりIIIFもそこに貢献し得るものかと改めて思ったところでした。

 

 さて、昨晩、上記のメンバーで検討したのは、このGoobiの使い方の確認でした。皆で検討した結果、まだ「これで何もかもばっちり」というところまでは行っておりませんが、まあ大体こうすると動いた、というところまではいきました。ただし、Windows10環境のみです。MacLinuxではまだ以下の動作をすべて確認するところまでは行っておりませんのでご注意ください。

というわけで、以下、ちょっと説明を試みます。

 

まず、Goobiを使った画像管理の全体の流れとしては、以下のような感じです。

全体的な作業の流れ

1. Projectを作る

2. Process templateを作る

 2.1必要に応じてtaskを作成・追加する

3. Processを作る

 3.1元資料のメタデータ、プロセスの情報を入力

 3.2デジタル化に関する情報を入力

4. Process中の個々のtaskを進めていく

 4.1 taskの例:

  ・画像を(まとめて)アップロード

  ・画像をチェック

  ・画像を処理

5. Processesリストで「Edit Metadata」をクリックしてメタデータを整備(METSの

メタデータエディタが起動する模様)

6. Processesリストでエクスポートボタンをクリック

⇒IIIFで公開できる

 

という感じです。普通(?)に考えると、こういうことができるソフトは、かなり設定がややこしかったりしそうなのですが、なんとこれが、JAVAのソフトをダウンロードして起動する(Windowsの場合、ダブルクリックする)だけでできます。セットアップの仕方は以下のURLに書いてありますので英語を読める方はそのまま進めてみてください。

https://www.intranda.com/en/digiverso/goobi/goobi-to-go/

 

一応日本語でも書いておきますと、Goobiのダウンロードは以下のURLからです。

http://files.intranda.com/g2g5

g2g5.zipというようなファイルがダウンロードできますので、このzipを元に戻します。(ダブルクリックするだけだと、うまく起動しません。きちんとファイル圧縮解凍ソフトを使って解凍してください。)

そこでできたフォルダを開くと、 GoobiToGo.jarというファイルがあるはずですので、それをダブルクリックします。それで起動します。なんと、たったこれだけです。

Java8を使っているようですので、Java8環境がなかったり、Java環境のパスがおかしかったりすると動かないこともありますので、お気を付けください。

 

次に、このGoobiにWebブラウザでアクセスしてみます。以下のURLに、以下のLogin/ Passwordでアクセスしてみましょう。こちらは、画像に関する作業をしたり、作業を管理したりする画面です。

作業が終わったものは、以下の ViewerでIIIFコンテンツとして閲覧することができます。(IIIF Viewerも組み込まれているようです)。

あとは、タスク・タスク管理画面(http://localhost:8888/goobi/)の方から、上記のような流れで作業をすることになるのですが、続きはまた次回に!(上記の説明だけで画像公開までできた人は、ぜひお知らせください。)

 

IIIFでフルサイズ画像ダウンロードをさせないためのお手軽設定

 IIIFの導入にあたって、「画像ダウンロードさせたくない」という理由で反対されるケースが未だにそこここで聞かれるという話をうかがいましたので、簡単ソリューションを考えてみました。

 この件は、そもそも画面キャプチャをすれば画像入手はできてしまうというという前提を共有できるはずなので、分割画像をダウンロードして自分で組み合わせるという人は画面キャプチャと同様であると考えることにして(それでいいのかという話もありますが…)先日このブログでご紹介したような、あるいは、otani0083 さんがGUIで作ってくださったようなダウンローダーなどで簡単に大きなサイズの画像ダウンロードをできないようにする、ということを目指してみます。

 今回の条件は、.htaccessを許容するapache2.4系のサーバで動いているIIP Image Serverです。.htaccessを許容しなくても直接httpd.confに書き込むことができるならそれでもよいかと思います。

 さて、フルサイズ画像や大きなサイズの画像ダウンロードをさせないということをIIIF Image APIとして考えてみると、画像サイズをURIで指定する箇所がありますので、そこで、禁止したいサイズの画像アクセスURIが来た場合には書き換えてしまえばいいということになります。普通にビューワ上で大きな画像を表示したいときは分割画像で送出することになりますので、その分割サイズよりも大きなサイズであれば禁止してもあまり問題はありません。分割画像のサイズとしては、256x256や512x512が多いように思われます。(時々一辺1000ピクセル以上の分割画像を見ることもありますが。)そこで、とりあえず一辺600ピクセル以上の画像を要求された時は256x256の画像を返戻してしまうようにすることを考えてみます。

 これは、Apacheだとごく基本的な機能の一つですね。mod_rewriteの機能を使います。.htaccessを使えるのであれば、iipsrv.fcgiの置いてあるディレクトリに以下のような.htaccessファイルを置いたらできました。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} iipsrv.fcgi
RewriteCond %{QUERY_STRING} ^IIIF=(.*)/!?(([6-9][0-9]{2}|[0-9]{4,}|),([6-9][0-9]{2}|[0-9]{4,}|)|full)/([0-9]+/default\.jpg)$
RewriteRule ^.*$ iipsrv.fcgi?IIIF=%1/!256,256/%5
</IfModule>

これは、以下のようなパターンのURIを前提としています。

https://candra.dhii.jp/iipsrv/iipsrv.fcgi?IIIF=/kakouzou_pub/021_1/0002s.tif/full/1000,/0/default.jpg

https://candra.dhii.jp/iipsrv/iipsrv.fcgi?IIIF=/kakouzou_pub/021_1/0002s.tif/full/full/0/default.jpg

 

上の.htaccessでの設定を介すると、上記のImage API URIが以下のようになります。

https://candra.dhii.jp/iipsrv/iipsrv.fcgi?IIIF=/kakouzou_pub/021_1/0002s.tif/full/!256,256/0/default.jpg

 

ちょっとベタな書き方になっていますが、とりあえずこれでなんとかなりました。ディレクティブや記号の意味はググっていただけば色々出てきますので詳しくはそちらを参照していただくとして、基本的な流れとしては、まず、RewriteCond %{REQUEST_URI} iipsrv.fcgi のところでIIP Image Serverへのアクセスのみを対象にします。次に、ここのサーバはIIP Image Serverのデフォルト設定のままで、Image URIのパラメータ指定がクエリ文字列(URI中の?より後ろ)になってしまっていますので、mod_rewriteでは普通に変換することはできません。そこで、次のRewriteCond では%{QUERY_STRING}という変数を用いてクエリ文字列を正規表現マッチさせます。(文字列一致で600以上を表現しようとしているのですごくベタになってしまっていますがご容赦ください。もっと良い書き方もあると思いますのでぜひご検討ください。)その次に、置換したい文字列を後方参照(ここでは%1 や%5)も含めてRewriteRuleのところで記述します。

 すごく拍子抜けしてしまう人もいるかもしれませんが、これだけで「大きなサイズの画像は分割画像の組み合わせで見せつつ、1辺600ピクセル以上の画像を丸ごとダウンロードさせない」ことができてしまいます。何か穴があるかもしれませんので、お気づきの方はぜひお知らせ&改良していただければと思います。

 IIP Image Serverでは、もしかしたらこれを自身の設定でできるかもしれませんが、設定パラメータをざっと見た限りではうまくみつけることができなかったので、Apacheの設定ファイルで対応してみました。Apacheに限らず、WebサーバのレベルでURLの置換はできる場合がありますし、URLでImage API URIを書き換えるという話ですので、IIP Image Serverだけでなく、IIIFのImage serverをWebサーバ経由で利用しているところでは、同様に対応可能だと思いますのでぜひトライしてみてください。

 あるいは、Image Server側を色々いじってこういうことができるようにするという手もあり得ますが、サーバソフトがセキュリティアップデートをした時等にとても大変なことになってしまう上に引き継ぎも難しいので、比較的安定していて引き継ぎしやすい.htaccessファイルでできるのであればそれにこしたことはないでしょう。

 このことからわかるのは、認証に関することも同様にhttpdのレベルでラッパーをかませれば割と簡単に実現できるだろう、ということです。それについても、ニーズはかなりありますので、いずれちょっとやってみる予定です。(が、どなたかやってみて手法を公表していただけると大変ありがたく・・・)

 もちろん、オープンサイエンス・オープンデータといった観点、あるいは単に文化を広くひらいていくという観点からも、このようなことはまったく好ましいことではありません。画像を丸ごとダウンロードできるようにしておくことは、利便性向上だけでなく、データ保全の観点からも極めて重要です。また、結局、画面キャプチャすればつなげることができてしまいますので本当に意味があることなのかどうかは気になるところです。ただ、所蔵者・公開者の方々の中には、とにかく画像丸ごとダウンロードはさせたくない、という人がおられるようですので、そういう方々にIIIFへの対応を前向きにご検討していただく上で多少お役に立つことがあるソリューションかもしれないと思います。何事もステップというものがあり、一つずつ、少しずつ、心理的障壁を取り除き、それによって利便性が高まったり有用性がより広く認知されたりするという体験から理解を深めていただけることも少なくありませんので、そういうステップの一つとして捉えることはできるだろうと思います。

Europeana APIでIIIF manifestのURIを取得

 いよいよジャパンサーチのベータ版が公開され、日本でも統合検索が一層本格化しそうな流れになってきて素晴らしいことです。

 ところで、諸般の事情により、EuropeanaからIIIF manifest URIを取得する必要が生じたので、色々試してみました。一応、やりたいことはできるようになりましたが、しかし、「答え」や「やり方」をお知らせするほどきちんと理解できていないので、「どんなことを試みたか」を中心に、ちょっとご紹介して、そこから先はみなさまに取り組んでいただくという方向にしたいと思います。

 

 まず、メタデータをがばっと取りたいなら、本来は、OAI-PHMで一通り取得するのが筋のような気がします。とはいえ、58,000,000件のメタデータをダウンロードするのはちょっと大変そうですし、おそらく、こちらが必要としているデータはそのうちのごく一部のはずなので、とりあえずEuropeana Search APIの方で試してみることにしました。この種のAPIは、ローカルにダウンロードするというよりはWebサイト同士で動的にデータをやりとりすることが主目的ですので、ローカルダウンロードにはちょっと向いてない面もありますが、むしろ後々そういう使い方もしたいので、とりあえずSearch APIを試してみます。

 

 この種のものはWeb API等と呼ばれていて、コンピュータプログラムを使ってばんばん検索をかけることができるようになっています。コンピュータプログラムを使った検索では、1秒間に10回などといった途方もないアクセスを延々と続けることもできてしまうので、そういったアクセスを対象とするWeb APIは、大量アクセスに耐えられるようにサーバをかなり頑強に作っておくと同時に、あまりに目に余る大量アクセスが行われる場合には、ちょっとアクセスを遠慮していただくといった措置も必要になる場合があります。そこで、「APIキー」などと呼ばれるトークンのようなものをAPI利用者(≒プログラム作成者)に発行することでうっすらと管理することが多いようです。これが無料だったり有料だったりするわけですが、Europeanaの場合は、もちろん無料です。で、こちらから取得できるようです。

 APIキーを取得したら、いよいよ、ほしいデータをさくさく自動的に取得できるはずです。さて、IIIF Manifestの取得方法は…と思ってAPIの解説記事を見てみますが、どうもよくわかりません。ほしいのは、それを行うためのそのものずばりのやり方なのですが、そういう情報は公式ドキュメントではなかなか提供されないような感じです。そこで、とりあえずググってみるのですが、そうすると良い案配にGithubのissueが見つかりました。これによると、 q=sv_dcterms_conformsTo%3A*iiif* というクエリを投げると IIIF対応コンテンツをごそっと検索できるようなのですが、ヒット件数は 2,505,662 results となりました。フランス国立図書館のgallicaがほぼIIIF対応しているので、その数が 1,536,506件ということで圧倒的ですが、Europeana Newspapersというプロジェクト の一環で、403,549 件の新聞記事がIIIF対応で公開され、これらはOCRによるフルテキストデータもついているようで、こちらで検索もできるようです。

 さて、これでとりあえず検索のためのURLはわかりました。APIだと、以下のようになります。(以下のURLはクリックしただけでは動作しません。registrationページからAPI Keyを取得してそれを追記する必要があります)

https://www.europeana.eu/api/v2/search.json?query=sv_dcterms_conformsTo%3A%2Aiiif%2A&rows=10&wskey=ここにAPI keyを

ここからさらに、絞り込みをかけようと思ったら、たとえば以下のようにするとできるようです。(タイトルに「北斎」が含まれるもの、という絞り込みをしています)

https://www.europeana.eu/api/v2/search.json?query=sv_dcterms_conformsTo%3A%2Aiiif%2A&rows=10&qf=title%3A%2A%E5%8C%97%E6%96%8E%2A&wskey=ここに自分のAPI Key を

 

さて、このようにして、IIIF 対応しているコンテンツをAPIで検索できるようになりましたが、これだけではIIIF Manifest URIを取得するにはちょっと足りません。検索結果から、各アイテムのメタデータを取得することで入手できるようになります。

 各アイテムのメタデータの取得に際しては、各アイテムには「id」がついていますので、そのidをrecord APIに埋め込んで問い合わせを行います。たとえば、先ほどの北斎の例では、ヒットした一つ目のアイテムのid 「/9200518/ark__12148_btv1b8304309t」ですので、これを使って以下のようなURLを作成します。

https://www.europeana.eu/api/v2/record/9200518/ark__12148_btv1b8304309t.json?wskey=ここに自分のAPI Keyを

そうすると、dctermsIsReferencedBy というキーにIIIF Manifest URIが入っていることが多いようです。ただし、ここに IIIF Image APIのベースURIが入っている場合もあるので、処理に際しては注意が必要です。

 

それから、APIで取得できるのは1000件目までなのですが、gallicaがヒットしすぎて1000件を超えてしまい、gallica以外のコンテンツを探せないという事態が結構生じます。そこで、gallicaを除外する設定ができるとよいのですが、とりあえず以下のパラメータをSearch API向けのURLに追加すると除外できるようです。

&qf=-PROVIDER%3ABiblioth%C3%A8que%2Anationale%2Ade%2AFrance

 

 というわけで、あまり腕がなまってもいけないので、時々は素振りでもしておかなければと、 これをやや簡単にできるようにするためにPython3で以下のスクリプトを作成しました。

$ python3 europeana_mani_get.py 自分のAPI_Key 検索語

という風にすると、検索語.txtというファイルが生成され、dctermsIsReferencedByに入っている値(IIIF Manifest URIかIIIF Image APIのBase URI)が書き込まれるようになっています。gallicaを除外したいときは

$ python3 europeana_mani_get.py 自分のAPI_Key 検索語 exga

という風にしていただくと除外できます。

github.com

 

それから、この場合はSparql を使うとうまくいくのではないかと思って色々試してみたのですが、どうもうまくIIIF Manifest URIを取り出すことができませんでした。もしうまくいった人がおられましたらご教示いただけますと大変うれしいです。

 

この種の巨大統合検索としてはDPLAもありますので、いずれあちらもやらねばと思っておりますが、いずれにしましても、こういう感じでデータを取り出して、ジャパンサーチと良い案配につなげて便利なサービスを提供できるようになると、あるいは、そういうサービスを色んな人がちょこちょこ作れるようになるといいなあと思っております。

海外の文化資料系の開発者コミュニティと技術トレンド

 以前からあちこちで言及してきているのですが、海外先進国の大手文化機関では、システムを自前で導入するためにエンジニアを雇っています。1人ではなく数人~数十人雇ってチームを組んでいるところもあるようです。雇用のための費用は、組織として支出しているところもあるようですが、アンドリュー・メロン財団をはじめとする各種外部研究助成金で雇用することも多いようです。そうすると、助成金が切れたら、それで雇われていたエンジニアの人達はどうなってしまうのか・・・と言えば、どうも、外から見ている限りでは、新たに助成金をとった他の機関に転職したり、そもそも文化機関系ではないところに転職したりしているような感じです。そのようにして仕事を続けていく中で、ではその仕事は雇用している各文化機関からのみ評価されているのかと言えば、それだけではなく、世界各地で大中小様々な会合が催されているようです。これらの会合を通じて情報交換や仕事の相互評価といったことが行われ、さらに、こういった仕事をしている人達にとってよりよい成果をあげていくためにはどのように仕事をしていくべきなのか、といったことも検討されているようです。

 この種のコミュニティの動向で面白いと思ったのは、このブログでもよくご紹介しているIIIFを通じた動きです。日本で文化資料データベースの仕様を決める時は、発注担当者が色々勉強したりIT企業の担当者から話を聞いたりしながら、よさそうなものを選んでそれにあわせた仕様書を作成する、という感じになるところが多いと思います。一方、IIIFに関しては、一部のメジャーな文化機関に属するエンジニアの人達が、自分達で規格を作ろう、と決めて、自分達で研究助成金を取ってそれを活動資金としつつ規格の仕様を定め、できあがった仕様を自分の所属する機関に採用させた、という流れになっているようです。このような流れは以前からうっすらとありましたが、IIIFについてはそれがかなり強く表れたような感じがあります。また、今後、エンジニア同士の横のつながりがますます強化されていく中で、こういったコミュニティにおける議論はさらに重要になっていくのではないかと想定されます。

 そのような会合の多くは、デジタル図書館連合がWebサイトにて情報集約しています。

www.diglib.org

 

中でも特に大きめの規模のものについては、(個人的には参加したことがないものもありますが、その場合はプログラムや登壇者から見て判断しています)、以下のようなものがあるようです。

(ほぼ)毎年開催:

pro.dp.la

code4lib.org

members.tei-c.org

iiif.io

www.euromed2018.eu

 

隔年・数年に一度開催:

pro.europeana.eu

 

他にも大きめのものがあるかもしれませんが、海外先進国で進められている文化資料デジタル化の雰囲気を味わったり、今まさに議論されていることを把握したかったりした場合は、こういう会合に顔を出してみるとよいのではないかと思います。

 また、日本でも、文化資料関連のデジタルアーカイブ方面の活動が、こういった流れにうまく対応できるようになると、投資がより効率的になって良いのではないかと思っております。その意味では、企業の若手のエンジニアやこの種の開発に興味がある研究者の方々にご参加いただけるような形になるととても良いと思いますので、周囲にそういう若手をかかえておられるシニアの皆様は、ぜひ彼らをご支援していただけますと幸いです。