CLARIN-ERIC/欧州の言語資源データインフラについて

欧州の言語資源データインフラとして運用されているCLARIN-ERICについて、ちょっと言及しなければならないかもしれないので 、CLARIN in a nutshell | CLARIN ERIC から、少しメモをしておきます。

CLARIN は、"Common Language Resources and Technology Infrastructure"の略。言語資源全般と技術のインフラ。

人文・社会科学分野の研究者を支援するために、シングルサインオン型のオンライン環境を通じて、 ヨーロッパ中のすべてのデジタル言語リソースやツールにアクセスできるようにするべく始まった研究インフラ。

2012年にCLARIN ERICが設立された。それは、人文科学や社会科学の研究のための言語データやツールの共有、利用、 持続可能性を支援するインフラストラクチャを構築し、維持することを使命とした。

現在CLARINは、社会科学や人文科学の研究者やもっと広範な研究者のために、デジタル化言語データ(書き言葉、話し言葉、マルチモーダル形式) への簡単で持続可能なアクセスを提供している。 さらにCLARINは、高度なツールも提供している。それは、データセットがどこにあっても、発見、探索、利用、アノテーション、分析、結合できるものである。 これは、言語データリポジトリ、サービスセンター、ナレッジセンターといったセンターのネットワーク化された連合によって可能となるものであり、 参加国のアカデミックコミュニティのすべてのメンバーがシングルサインオンでアクセスできるようになる。 データコレクションを組み合わせたり、異なるソースのツールを連結して複雑な操作を実行したりして、 研究者の作業をサポートすることができるようにするため、異なる機関のツールやデータは相互運用可能となっている。

CLARIN のインフラストラクチャは多くの国で完全に稼働しており、多くの参加機関がデータ、ツール、専門知識へのアクセスサービスを提供している。 同時に、最近参加したいくつかの国では、CLARINのデータセットとサービスが継続的に更新され、改善されている。 サービスのページでは、現在アクセス可能なサービスを紹介し、様々なサービスを誰がどのようにアクセスできるかを説明している。

ついでに、ERICって何?という話もCLARINのサイトに乗っている情報で簡潔に。

CLARINは分散型デジタルインフラストラクチャであり、ヨーロッパ中の大学、研究機関、図書館、公文書館などの機関が参加している。 すべての参加機関に共通しているのは、利用者である研究者のために、デジタル言語データコレクションへのアクセス、 それらを扱うためのデジタルツール、そして、専門知識を提供していることである。

CLARIN のガバナンスと調整機関は ERIC(欧州研究基盤コンソーシアム)である。 ERIC は、2009 年に欧州委員会によって設立された国際的な法人である。CLARIN ERIC のメンバーは政府または政府間組織である。2012年以降、いくつかの国が正会員として、 または オブザーバー(正式加盟に向けての準備をする)として参加している。最終的な目標は、すべてのEU加盟国とその関連国、および欧州内外の第三国を含めることである。

CLARINは、欧州研究インフラ戦略フォーラム(ESFRI)の欧州研究インフラロードマップに選定された研究インフラの一つである。 2016年に、CLARINはESFRIの新しいロードマップのランドマークという位置づけになった。

CLARIN インフラの構築は、9 名の設立メンバーで CLARIN ERIC が設立された2012 年 2 月 29 日に正式に開始された。 CLARIN ERIC の主な業務は、CLARIN インフラの構築、運営、調整、維持管理であり、研究活動を実施したり資金提供したりすることはない。

CLARIN ERICは、欧州委員会によるCLARIN準備段階プロジェクト(2008-2011年)の財政支援を受けて設立されたが、現在は参加国が全額を出資している。

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

本日は、第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ガイドラインは書誌情報記述のために色々な細かなルールを用意していて、これらを活用することで、上記のようなものだけでなく、様々な視覚化や分析が可能となります。

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

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

本日は、第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

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

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