ケンブリッジ大学デジタル図書館の日本資料の書誌情報を視覚化してみる

本日は、第3回 日本宗教文献調査学 合同研究集会という会合でパネルディスカッションの司会をさせていただきました。 司会が自分が言うのもなんですが、大変興味深い議論が行われたようにも思いまして、ご参加いただいたみなさまのおかげで意義のある場になったように思いました。

もし、このパネルディスカッションの場でこういう話になった場合に、ということで少し用意したネタがあったのですが、結局披露することができずに お蔵入りとなってしまったのでこちらで紹介させていただきます。内容は表題の通りです。

ケンブリッジ大学デジタル図書館では、幅広い分野をまたぐデジタル図書館を公開していて、サブジェクト・ライブラリアンが 付与したやや詳細なメタデータがCC BY-NC-NDで公開されています。(欧州の文化機関から公開されているメタデータですがCC0ではない という点も留意していただきたいところです。)

このメタデータは、TEI (Text Encoding Initiative) ガイドライン(本家英語版日本語解説版)に準拠して作成されており、用意された情報に関しては機械可読性がかなり高いものと なっております。当初はケンブリッジ大学図書館日本司書の小山さん等、当該図書館の人達がメタデータをつけていたような感じがしますが(この点、間違えていたら ご教示ください)、途中から立命館大学アートリサーチセンターの方々が参入してがんばってくださったようで、日本文化資料だけで463件が画像(IIIF対応)と ともに公開されています。

このTEIガイドラインに準拠したメタデータには、いくつかの特徴がありまして、特に興味深いのは、来歴情報、provenanceが割とよく書いてあり、 そこに登場する人物を同定できるようにしている、という点です。そうすると、この書誌情報データを一通り取得すれば、たとえば以下のような ことができます。

f:id:digitalnagasaki:20210220131545p:plain

これは、「ケンブリッジ大学デジタル図書館における日本資料の入手に関わった人の 貢献の割合をTEI ガイドライン形式の書誌情報データから取得・表示」したものです。 日本資料のTEI/XMLデータを一通りダウンロードしたあと、それをPythonでささっと処理してデータを数えて、 それをエクセルに入れてグラフにしたというものです。

さらに、この情報と、本の刊行年を組み合わせると、以下のようなものを作れます。こちらは、資料を入手した人ごとにわけて、それぞれの刊行年をタイムライン上に表示したものです。 なお、このインターフェイスはこちらでぐりぐり動かせます。

f:id:digitalnagasaki:20210220131809p:plain

f:id:digitalnagasaki:20210220131828p:plain

各資料名をクリックするとケンブリッジ大学デジタル図書館のその資料のページに飛ぶようになっています。

これはあくまでも一例ですが、TEIガイドラインは書誌情報記述のために色々な細かなルールを用意していて、これらを活用することで、上記のようなものだけでなく、様々な視覚化や分析が可能となります。

さて、これを実際にどういう風にやればいいのか…というあたりは、今度、そのうちまた書かせていただきたいと思います。とにかく、詳しい書誌情報をきちんと機械可読に書くことができれば、 資料についての分析方法がとても多角的になるということと、西洋中世写本ではこういうことがすでにかなり広く行われているようである、ということで、今回はここまでとさせていただきます。

一つのフォルダの中のファイルのファイル名をエクセルを介して一括で変更する方法@Windows10

Windowsで、一つのフォルダの中のファイルのファイル名を一括で変更したいときがあります。フリーソフトでそういうことをやってくれるものもありますし、玄人的な方法なら本当にいろんな方法があります。

でも、Windows10で普通にワードとかエクセルを使ったりしているくらいだと、玄人的な方法と言われても困ってしまうこともあると思います。そこで、エクセルを 使うことで、やや応用性の高い形で、一括でできるけどそんなに難しくない(かも)、という方法をちょっとご紹介します。

基本的に、ファイル名の変更というのは、Windows10だとパワーシェルにコマンドを打ち込むのが標準的にできる方法の基本です。たとえば以下のように、

パワーシェルのコマンド例

> mv test2.text test3.txt

というコマンドを入力すればできます。ですので、一つのフォルダの中のファイル名を一括変更したい場合は、

 mv test2.text test3.txt
 mv test21.text test31.txt
 mv test23.text test33.txt

というテキストを作ってパワーシェルに貼り付ければ、それぞれがコマンドとして機能することになります。そこで、このような テキスト(コマンド一覧)を作成することを目指してみましょう。

最初に必要なのは、変換したいファイル名の一覧の取得です。ここでは、 ファイル名を1行に一つずつ取得する必要があります。このための方法は色々あるのですが、簡単な 方法として、パワーシェルを使う方法があります。その場合、以下のように 「対象ファイルが入っているフォルダを開いてそこでシフトを押しながら右クリック」してください。そして、「Powershellウインドウをここで開く」を選んでください。

シフト+右クリックでパワーシェルを開く

ここで、以下のコマンドを入力してみてください。(以下のような場合、「ls」と入力した後にキーボードのEnterキーを押してください)

> ls

そうすると、以下のようにファイル名の一覧が表示されるはずです。ここで、名前を変更したいファイルのファイル名が一覧されるかどうか確認してみてください。

変更したいファイルの名前の一覧がでてきいたら、先に進みましょう。ここでは、ファイルの最終変更日付なども表示されていてちょっと使いにくいです。そこで、 以下のコマンドを使ってファイル名のみを一覧表示させます。

> ls -Name

そうしましたら、このファイル一覧をとりあえずテキストエディタなどにコピペします。

ここで注意しなければいけないのは、これらのファイル名では空白(スペース)を含んでいます。 スペースを含んでいる場合は「"」でファイル名を囲む必要があります。つまり

"スクリーンショット 2021-02-12 181746.png"

こういう感じです。

ここまでくれば、テキスト変換が得意な人ならテキストエディタでもできるかもしれませんが、そういうのもあんまり得意でない人は、エクセルでこういうデータを作るとちょっと簡単です。 繰り返しになりますが、目標は、以下のような文字列を作成してパワーシェルに貼り付けることです。

mv "スクリーンショット 2021-02-12 181746.png" "sc-2021-02-12 181746.png"

さて、これを以下のようにエクセルに貼り付けまして、変換後文字列も作成して、以下のようにしてみます。 元の文字列はB列で、A列には"mv " (mvの後ろに半角スペースを忘れずに)を入れておきます。C列の変換後文字列は、 たとえばテキストエディタなどで作成してから貼り付けてもいいですし、エクセルの検索置換機能で 作成してもいいでしょう。

それから、ファイル名(B列かC列)文字列に空白が入っている場合は、ダブルクオーテーションで囲む必要がありますが、これはテキストエディタで やってもいいですが、エクセルでもできます。エクセルだと以下のような関数をセルに書くことになります。

=""""&B1&""" "

最終的に、これをパワーシェルに貼り付けるわけですが、このまま貼り付けるとうまくいきません。これをうまく行うためには、 以下のような関数(=A10&C10&B10)で一つのセルにまとめて、それをパワーシェルに貼り付けるとよいです。

貼り付けてうまくいくと、以下のようになります。

このやり方は応用範囲が非常に広いので、プログラミングは覚える気はないけどWindowsで何か便利な小中規模の一括処理をしてみる際にはぜひ色々ご活用ください。

データクレンジング/大日本仏教全書の目次データを作成した話

ここしばらく、国立国会図書館デジタルコレクション(NDLデジコレ)で公開されている『大日本仏教全書』という仏典叢書のインデックスを作成する作業に没頭しておりました。

『大日本仏教全書』は大正時代に刊行されたものなのですが、大変面白いもので、仏典叢書と書きましたが、仏教思想に関するものだけでなく、日本のお寺の寺誌とか史伝とか、鴨長明の佛敎説話集『発心集』なども入っていたりして、基本的に日本で書かれた仏教に関連する色々な資料の集成です。

これは、すでにマイクロフィルム化されていたらしく、NDLデジコレではそのマイクロフィルムをスキャンしてデジタル化したもので、全体的に画像が不鮮明で、戦前の旧字体で印刷されていることもあり、拡大表示しないと文字を判別できないことも結構あって、デジタル化資料としてはちょっといまいちなのですが、それでもWebで無料で読めるということは大変貴重なことなので重宝しております。マイクロフィルムの時点でモノクロだったようで、デジタル画像もモノクロ(グレースケール)なのですが、この資料に関してはモノクロでも問題ないのでその点は大丈夫です。

さて、資料をうまく扱えるようにするためには、とりあえず叢書に入っているテキストのリストを作りたいところです。幸いにして、NDLデジコレでは公開資料の目次を作成公開する作業を連綿と続けてきているようで、ありがたいことにこの『大日本仏教全書』でも目次がついています。そこで、これを自動的に取得すれば割と簡単にテキストのリストを作れるだろうと思っていました。

とはいえ、自動的に目次を取得するのってどうやったらいいんだろうか…と思って、NDLサーチのWeb APIの説明などを見てみても、どうもいまいちピンときません。そういえば、7年くらい前に、面倒になってHTMLを取得して解析するという原始的な方法を用いたことを思い出したのですが…うーん…と考えていて、ふと思い出したのが、最近導入されたIIIF Manifestファイルを見たときに「sc:Rageを取得すれば目次がとれるぞ」と思ったことです。

たとえば、 https://www.dl.ndl.go.jp/api/iiif/952681/manifest.json このようなIIIF Manifest URIで、"structures"以下に配列として入っている要素のうち、"@type": "sc:Range"の"label"を取得すれば確実に機械的に取得できます。JSON形式データなので、Python等でも関数一発でdict/listとして処理できるようになります。これはなかなか便利です。URLの"952681"が資料のIDなので、資料IDをリストして IIIF Manifest URIを生成して自動取得して…と、もう大丈夫ですね。ただ、NDLのサーバは非常に頑強ですが、それでも、あまり一度に大量に取得し過ぎないように気をつけてください。日本文化に興味を持っている世界中のみなさんと共同で使っているサーバですからね。

なお、話がよくわからない、というときは、Python3, JSON, スクレイピング、といったキーワードでググってみてください。Python3の勉強は自分でしてください。

せっかくの機会なので、以下に今回作ったスクリプトを貼っておきます。ここでは、NDLデジコレの資料IDのリストはディレクトリ名を使っています。というのは、すでに必要な画像を資料IDごとに作成したディレクトリに格納しているのです。たとえば、以下のような感じのディレクトリで作業しています。

[nagasaki@localhost dainihon]$  ls -d 95*
952681  952704  952727  952750  952797  952822  952845
952682  952705  952728  952751  952798  952823  952846
952683  952706  952729  952752  952799  952824  952847

で、スクリプトの方はこんな感じで、とりあえずJSONでデータ取得しています。この時点ですでにいくつか問題点に気づいていたので、少しだけ例外処理を入れています。

#!/usr/bin/python3
import glob
import re
import os
import urllib.request
import json
import time
#https://www.dl.ndl.go.jp/api/iiif/952686/manifest.json
#p3 get_chapname.py > dh_sinindex.json
arfiles = glob.glob('95*');
alltit = {}
#113,114がNDLでは欠番なのでスキップしている。
alltit["name"]= "大日本仏教全書"
alltit["id"]= "DNall"
alltit["bv"]= ""
alltit["children"]= []
vol_num = 1
title_num = 1
for file in arfiles:
    time.sleep(1)
    url = 'https://www.dl.ndl.go.jp/api/iiif/'+file+'/manifest.json';
    req = urllib.request.Request(url)
    with urllib.request.urlopen(req) as res:
        titles = []
        vol_name = {}
        title = {}
        manifest = json.load(res);
        if "structures" in manifest:
            structures = manifest["structures"]
            for range in structures:
                if "標題" != range["label"]:
                    if "目次" != range["label"]:
                      if "canvases" in range:
                        cid = range["canvases"][0]
                        range_title = range["label"]
                        title = {}
                        if file == "952806" and "巻之" in range_title:
                            range_title = "本朝高僧伝"+range_title
                        if file == "952825" and re.match(r'^巻', range_title):
                            range_title = "東大寺雑集録"+range_title
                        title["id"] = 'DN'+str(title_num);
                        title["creators"] = [{"id":"c1","name":"","pname":""}];
                        title["name"] = re.sub(r'^一 ', '', range_title);
                        title["bv"] = "";
                        title["canvasid"] = cid;
                        title_num += 1
                        print (range["label"])
                        titles.append(title);
                        title = {}
        else:
            title["name"] = re.sub(r'大日本仏教全書. 第.+?巻\s*', '', manifest["label"])
            title["id"] = 'DN'+str(title_num)
            titles.append(title);
            title = {}
            title_num += 1
        if vol_num == 113:
            vol_num = 115
        vol_name["id"] =  "DNV"+str(vol_num)
        vol_name["bv"] =  "";
        vol_name["url"] = url;
        vol_name["name"] = '第'+str(vol_num)+'巻'
        vol_name["children"] = titles;
    alltit["children"].append(vol_name)
    vol_num += 1
    print (url);
with open('dn_sindex.json', mode='w') as f:
     f.write(json.dumps(alltit, indent=2, ensure_ascii=False))
#print (alltit)

さて、データは取得できたのですが、これを見て、ちょっと修正が必要っぽいところがいくつかあることがわかったので、細々みていくと…結構大変だったのですが、 とりあえず一般的な話だけをしておきますと、『大日本仏教全書』は150冊ほどあるのですが、目次のルールが統一されていないようで、冊によって記述されている 階層が異なっているということがわかりました。目次に階層があるのですが、その記述の仕方が冊によってまちまちである上に、そもそも 冊によっては目次がないものもあるのです。ですので、そもそも統一的な目次データを作るためにはただ目次を入力するだけでは済まないという ことになります。入力作業は企業に発注したのか館内の方々がされたのかよくわかりませんが、どなたが作業するにしても、そもそも この叢書に関しては分担して作業するための「統一入力ルール」を作ることが困難であるということがこの点からすでに明らかでした。

それから、含まれているテキストごとに著者や編者がいて、目次にはそれが大体書いてあるのですが、親切にもそれが入力されている冊とされてない冊があって、 しかし、全体の状況からみると著者や編者を入力することは発注仕様には入っていなかったのではないかと想像されるので、入力してくださったかたの親切心を感じたところでした。

というようなことで、全体の構造を把握した上でデータを修正していくという作業をすることになりました。

きれいな階層構造データを処理するならJSON形式は大変お手軽ですが、手で細々修正するにはちょっと向いてません。JSONを便利に書けるエディタは色々ありますが、 データ形式を気にしながら細々書くのはやっぱり面倒です。そこで出てくるのはエクセル…と思いましたが、他の人と共有するなら最近はGoogle Spreadsheetの方が 便利です。しかも、デフォルトで正規表現置換が使えます。というわけで、データをタブ区切りテキストに変換して、Google Spreadsheetに読み込みです。

あとは、これを前提にしてデータを作っていくわけです。

目次は3段階に分けることにして、「本」「本に含まれるタイトル」「一つのタイトル中の章等」を基本にしました。それから、著者・編者については、 ざっとみて大部分が「撰」だったので、デフォルトは「撰」ということにして、それ以外のケースについては、人名+役割を記述することにしました。 ここでは一度に登場する人名が増えるごとにspreadsheetの列を増やすという方針で、最終的に最大3名ということで済みました。

目次に書かれたテキスト名は、基本的に、「何巻で構成されているか」ということが付記されています。たとえば

「日域洞諸祖伝二巻」

といった感じです。これは本来、カラムを分けて

日域洞諸祖伝|2|巻

という風にするのが理想的ですが、とりあえず後でそういう風に処理することを前提として、とりあえずは正規表現置換をしてみます。

検索文字列
([^〇一二三四五六七八九十])([〇一二三四五六七八九十]+巻)

置換文字列
$1 $2

という感じで、半角スペースで区切っておきます。一括でやってしまうと意図しないものを区切ってしまうかもしれないので、一応、一つずつ見ながらやっていきます。 そうすると、一つのテキストが複数の冊にわたるものが結構ある上に、

『大日本仏教全書』vol. 10 
○○經疏巻1~10

『大日本仏教全書』vol. 11
○○經疏巻11~15
△△經疏

という風になってしまっているものが散見されます。これは大正新脩大藏經だと大般若経だけなのですが、『大日本仏教全書』は1冊がそれほど大きくないために、 分冊されてしまいやすく、しかも、隙間があれば別のテキストを入れてしまうので、微妙にややこしいことになってしまうようです。

これはややローカルな事情ではありますが、これはいわゆる複数構造のオーバーラップという話ですので、似たようなことは他のデジタルデータでも 結構みられるのではないかと思います。

解決の方法は…と言えば、とりあえず今のところはインデックスを作っているだけで、階層ごとに用途がありますので、その用途にあわせて、 なるべく『大日本仏教全書』に沿ったルールで名付けていくことにしました。

それから、文字の扱いもちょっと変更してしまいました。NDLデジコレのデータは基本的に新字体に寄せてあって、一定のルール(JIS第二水準くらい?)に入らない文字は 「〓」になってしまっていますが、これを、Unicode準拠で、旧字体で書かれている漢字はなるべく旧字体で入力する、ということにしました。 実際のところ、検索する際はこちらの変換データを使って検索をかけるので、新字体旧字体どちらでもかまわないのですが、 それならば、とりあえずは元資料になるべく沿った形にしておこうということで、旧字体としました。たとえば、手元のvueアプリから抜粋すると、以下のような関数で検索用文字列を 生成して正規表現検索をしています。

      getVarChars: function(e,sw){
        //swを'reg'にすると正規表現検索用文字列が返る
        //swがそれ以外なら配列で各文字が返る
        var arChars = Array.from(e);
        var vChars = [];
        var vChar = [];
        var vCharLine = '';
        arChars.forEach(function(ekc){
          vChar = [ekc];
          chars.forEach(function(ec){ // charsに、上記のmapping_char.jsonが入っている。
            if (ec.u1 == ekc){
              vChar.push(ec.u2);
            }
            else if (ec.u2 == ekc){
              vChar.push(ec.u1);
            }
          });
          if(sw == 'reg'){
            vCharLine += '['+vChar.join("")+']';
          }
          else{
            vChars.push(vChar);
          } 
        });
        if(sw == 'reg'){
          return(vCharLine);
        }
        else{
          return (vChars);
        }
      },

Unicodeで漢字を探すときは、基本的にCHISE IDS漢字検索を使います。

これの便利なところは、「探している漢字部品を含む漢字」から目当ての漢字を高い確度で探せる、という点です。

たとえば、「潡」を探したければ「敦」で検索すればすぐにみつかる・・・というあたりは初歩的ですが、 「濬」を探したい時に、同じような漢字部品を持っている「叡」を検索すると以下のようにヒットします。ここで 赤丸をつけたところをクリックすると、今度はその部品で検索できるようになります。

f:id:digitalnagasaki:20201231233616p:plain

さらに部品を追加して絞り込み検索することもできますし、そのままリストから探してもOKです。 Unicodeの新しい文字まで入っているので、Unicode で限界まで資料に沿った文字を表示させたいという 時には非常に便利です。

それから、悉曇も、最近は、Unicodeで使えるようになっていまして、フォントをインストールしないと文字の表示はできませんが 文字列として処理することができるようになっていますので、とりあえず2カ所、悉曇を入力しています。フォントとしては GitHub - MihailJP/Muktamsiddham: a free Siddham fontReleases · googlefonts/noto-fonts · GitHub など、選択肢が提供されている状況です。筆者としても、これを使って色々やるべく準備中です。

あとは、まあ、とにかく画像の確認と入力です。 たとえば目次がついていないものをなんとかするためには、 1頁ずつ見ていくのは大変なので、頁画像一覧をじーっとみて、章の始まりっぽい頁をみつけたらそれを表示して、 それが目的のものであれば、その画像番号と章タイトルをメモしていきます。

f:id:digitalnagasaki:20201231232724p:plain

でも、章のタイトルがきれいに出ないものもあるので、そういうものは結局、全ページをめくっていくことになります。 1頁2-3秒くらいですので、まあちょっと集中すればなんとかなります。

というようなことで、まだ作りかけですが、とりあえず一区切りということでこちらにご紹介させていただきました。今後、章タイトルを もう少し充実させる予定ですが、他のデータとのリンクという点ではここまでやればなんとかなるので、 次は処理の方を色々考えてみたいと思いつつ、そろそろ年が明けそうです。みなさま、来年もよろしくお願いいたします。

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

さて、前々回の記事の続きです。前回記事から引用すると、

総合的にみて現在おすすめのワークフロー

というわけで、J-Stageで全文XML登載をするにあたって、当方でおすすめの作業の流れは、大体以下のような感じです。

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

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

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

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

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

ということだったのですが、一つ、このワークフローの外側の、しかし重要なワークフローの問題として、できればJ-Stageになんとかしてもらいたい課題があります。

J-Stageでは、XMLファイルの他にPDFファイルの掲載を要求します。通常であれば、XMLファイルがあるのだからそこからPDFを 生成すればよいのではないかと思うところ、そういう仕組みが今のところ用意されていないため、全文XMLファイルを作っても、 結局、自前で別途、PDFファイルを作成しなければなりません。結論から言うと、貧乏な学会だと、ワードで整形して PDFに変換、ということになります。それだったらわざわざ全文XMLファイルを作成する意味はどこにあるのか…という ことになってしまいそうです。

こういう時にどうするのかというと、お金があれば アンテナハウス社の AH Formatterというソフトを買えばよいのですが、10万円ほどかかります。 これは、専門企業が業務のために購入するなら割と無理のない金額だと思いますし、APC30万円の時代からすると 全く些細な金額のようにも見えますが、元々、お金がなくて J-Stageを使うという話なのですから、こういう高額な上に使い方を調べるのも大変そうなソフトウェアを購入するのは なかなか難しく、どちらかといえば簡単に手が出せるような代物ではないということになってしまいそうです。

元々、J-Stageは専門企業(にお金を払って論文編集を依頼できる学会)向けのサービスなのだと割り切れば、 それはそれでいいのかもしれないとも思うのですが、 全文XML作成ツールのようなものを作って門戸を広げようとするのであれば、むしろそのあたりももう少し手厚くしていただけると いいのではないかと思うところです。

もちろん、JATS本家が提供している変換ツールもあるにはありますが、日本語対応が十分でないので、そのあたりで 少しJ-Stageの独自性を発揮していただけるとありがたいなあと思うところです。

つまり、AH Formatterほどきれいなものでなくてよいので、J-Stageが、簡素なPDFファイルを全文XMLから生成してくれるような ツールを提供してくれれば、そのあたりの効率も一気にあがって(=全文XMLファイルだけを作成すれば済む)、 全文XMLを採用するところも少し増えるのではないでしょうか、ということです。

それから、一連のやりとりを経て思ったのは、J-Stageセンターへの問い合わせのメールが先方に届いたか、 担当者が読める状態になっているかどうか(迷惑メールなどに仕分けされてないか)、といったことがそもそも よくわからなくて不安に包まれたまま返事が来るのを半日~数日待つという状況が続いたので、 とりあえず着信を知らせる自動返信メールがあるとありがたいと思ったのでした。

J-Stageセンターへの問い合わせメールに関して言えば、もう一つお願いしたいことがあって、 「回答をいつ頃出せるのか」という返事をなるべくはやくいただきたい、ということです。 現状だと、回答が来てから次の作業時間をスケジューリングすることになるので、 そもそも作業スケジュールが組めないという状況になってしまっています。 専門企業ならそれでもなんとかできるのかもしれませんが、J-Stageへの論文登載を 本業としていない者にとっては、作業時間の確保がそもそも大変なので、次に 取りかかれる時間を確認できることは結構大事で、逆に、少し遅くなっても、 回答が来る時間の目安があれば、(今回は16時頃、とか、これは時間かかりそうだから 翌々営業の夕方、とかでよいので)、作業スケジュールをちゃんと組めるように なるので、結果的に、効率的にできます。そのあたりもご配慮いただけるとありがたいと思っておりますし、 そういうことに取り組むことで、実質的な専門企業向けサービスという状況から脱することも できるかもしれません。(と言っても、元々そういう志向であるなら特に問題ないのかもしれませんが…)

J-STAGEに期待すること

ということで、全文XML作成を広めるということであれば、それにあたってJ-Stageに期待することをまとめると、

  1. 全文XML作成ツールでは、無理してXML編集機能を充実させるよりも、XML編集に関してはvalidation+アルファくらいに 済ませておいて、それ以外の細かな編集作業は外部のXMLエディタを利用しやすいような支援体制を整える。(XML編集ツールに あんまりお金をかけすぎないでほしい)

  2. XMLからHTMLへのJ-Stage独自の変換ルールをアクセスしやすい形で提供していただきたい。(主に修飾用タグの適用範囲など?)

  3. J-Stage独自のタグ利用制限について、確認しやすい形で提供していただきたい(独自のカスタマイズスキーマファイルをDTDやRNG等で配布するなど)。(主に、前出のyearタグやsourceタグの制限など)

    • これは、全文XML作成ツールの編集画面に貼り付けてvalidatorを使え、ということならそれでもいいですがその場合、なるべく本番サーバと同じ変換ルールにしていただきたい。
  4. 全文XMLを作成したら、別途PDFを作らなくても済むようなソリューションを、簡単なものでいいので用意してもらいたい。

  5. J-Stageセンター宛ての問い合わせメールは自動返信でよいのでとりあえず着信の知らせをいただきたい。

  6. J-Stageセンター宛ての問い合わせメールの、返事を出すまでの時間の目安をなるべくはやく知らせてほしい。

以上、J-STAGE関係者のみなさまがこういった点についてもご検討くださるとありがたいと思っております。

動画へのアノテーションを(サーバなしで)手元で試してみる

本日、初めてのIIIF動画アノテーション講習会を実施しました。受講者だか講師だかわからないような人たちが続々ご参加くださったおかげで大変有益な議論ができました。

これにあたって、どういう風にすると皆さんが試しやすいだろうか…と考えつつ準備をするなかで、やはり、IIIF Manifest のJSONファイルを手元で書いて、それに手元で アクセスして確認&閲覧できるようにするのが便利だろうという気がしてきたので、Miradorをローカルで動かす方法を考えてみました。これだと、 インターネットサーバがなくても、普通のパソコンでも試せます。

ただ、これをやるためには、自分のパソコンにHTTPサーバを立てなければなりません…と言っても、今時は、Python3でコマンド一発ですので、 これを機にPython3を入れましょう! (たとえばこちらのPythonインストールガイドをご参照ください

というわけで、Python3をインストールした状態になったとしましょう。そうしたら次に、 こちらのzipファイルをダウンロードして展開してみてください。

そうすると、「ws_iiifvideoanno」というフォルダができて、その中にいくつかファイルが入っていると思います。 ここで、この「ws_iiifvideoanno」の中に移動して、そこでPython3のHTTPサーバを立ち上げます。コマンドは

$ python3 -m http.server 8000

です。この状態で、 http://localhost:8000/ にWebブラウザでアクセスすると、ws_iiifvideoannoに入っているファイル名の一覧が表示されるはずです。 もし表示されなかったり別のファイルが表示されるようであれば、上記のコマンドを実行する際のパスがずれているかもしれませんので、確認してみて ください。

$ cd 実行先ディレクトリ (フォルダ)へのパス

で目当てのディレクトリ(フォルダ)に移行できる移動できるはずですが、うまくいかなければ適宜ググってみるなどしてみてください。

ファイル一覧が表示されたら、次は、まず、「cat_video.html」というファイル名をクリックして、Webブラウザで ネコの動画がMirador上でアノテーション付で表示できるかどうか、確認してみてください。これができれば、 Miradorがこの環境で適切に動作しているということが確認できたことになります。

次に、一つ前のページ(ファイル名の一覧)に戻って、「video_practice.html」というファイルを、同様に、ファイル名をクリックして、Webブラウザで 閲覧してみてください。今度はMirador上にあつまれ動物の森の動画に3つだけアノテーションがついたものが表示されるはずです。 このMiradorインスタンスでは、同じフォルダ(ディレクトリ)の mani_pra.jsonというファイルを読み込んで表示しています。

ここまでできていれば、あとは簡単です。mani_pra.json というファイルは、練習用に用意したIIIF ManifestのJSONファイルですので、 これをMirador上の表示と対照しながら色々試してみてください。

なお、IIIF Manifestのid (URI)は、最初が、http://localhost:8000/ となっていますが、これは、ローカルで動作させるためのものです。 インターネットサーバに載せようというときは、このURI部分をサーバ用のものに検索&置換してしまえばよろしいかと 思います。

あとは、以下のページを適宜読み替えながらご参考にしていただけばよろしいかと思います。

dh.l.u-tokyo.ac.jp

こうやって書いてみると、重たい動画編集ソフトを立ち上げたりラスタライズをじーっと待ったりしなくても、 テキストファイルをちょこちょこいじるだけで動画コンテンツをリッチにしていけるというのもなかなか 面白い点の一つかもしれないと思えてきます。

ということで、楽しい年末年始をお過ごしください!

新規開発された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. その他、気をつけて置いた方がよい点。

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だとエラーになる。

  • あとで追記します。

6. というようなことで、全文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年でもある程度は使えるものにしよう、というものです。こちらについて少し例を見てみると、 たとえば、

f:id:digitalnagasaki:20201225024418p:plain
動画アノテーションの例1

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

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

f:id:digitalnagasaki:20201225025745p:plain
動画アノテーションの例2

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

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

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

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

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

docs.google.com