Oxygen XML EditorでTEI/XMLのファイルを作っていて、人名や地名、アイテムなどのリストを作成していくことがありますが、複数のファイルから同じリストを参照したいということがしばしば発生します。そういう時に、リストだけを別ファイルにして、他のファイル群から参照できるようにすると、リストの追加の手間が減るだけでなくIDの管理が楽になったりして大変便利です。
そういうことをしたい場合には、まずはリストだけを含むTEI/XMLファイルを作成します。ここではファイル名を「linked_list.xml」としておきます。それから、そのリストを参照したいファイルの方では、以下のように「 xmlns:xi="http://www.w3.org/2001/XInclude"」という名前空間の情報を
その上で、ファイル中のどこか適切な場所で、<xi:include href="linked_list.xml"/>というタグを入れます。そうすると、linked_list.xmlのなかに含まれているxml:idを参照できるようになります。
つまり、これが
こうなるわけです。
便利ですね。
古典の引用手法としては、長らく CTS (Canonical Text Services) というものが西洋系を中心に広まっていました。 たとえば Canonical Text Services protocol specification を見ると、以下のように書いてあります。
Canonical Text Services (CTS) プロトコルは、クライアントとサーバー間での相互作用を定義し、テキストの識別および正規的に引用されたテキストの節の取得を可能にする。
あるいは、デジタル古典学wikiには以下のように書いてあります。
Canonical Text Services (CTS) は、正規的な参照によって引用されたテキストの節を識別し、取得するためのプロトコルである。
Canonical（以前は "Classical"）Text Services 仕様は、テキストを識別し、その断片を取得するためのネットワークサービスを定義する。このとき「作品 (work)」や「引用 (citation)」といった、古典研究やその他の文学分野で伝統的に用いられてきた概念を利用する。
CTS は CITE アーキテクチャの一部であり、Homer Multitext プロジェクトのニーズに応えるために Blackwell と Smith によって開発された。
先日、リスボンでのDigital Humanities 2025 に参加した際に、これの後継になりそうなものとしてのDTS (Distributed Text Services) のポスター発表があり、少し話を聞いてみたところ、心意気はなかなかのもので、テキスト引用におけるIIIFのような存在になりたい、というようなことをおっしゃっていました。サイトを見ると概ね以下のような説明があります。
Distributed Text Services (DTS) 仕様は、テキストコレクションを機械可処理データとして扱うための API を定義する。
デジタルテキストコレクションの発行者は、DTS API を利用することで、自身のテキストデータを Findable, Accessible, Interoperable, Reusable (FAIR) にすることができる。
DTS はデジタルテキストコレクションの機械的利用を可能にし、データ分析やユーザーインターフェース、ツール、サービスの開発など、さまざまな形でコレクションの利用者に活用されうる。
DTS は API の仕様であり、それ自体が API の実装ではない。参照実装が用意されており（下記参照）、個々のテキスト発行者は、自身のプロジェクトに応じてこの API を実装することが推奨される。
詳細や DTS に関する FAQ（よくある質問）の一覧については FAQ を参照のこと。
説明がなんだか現代的な感じがするところが面白いですが、とにかく、これに対応してみると、有用性が高まるかもしれないですね。
身近に Records in Contexts (RiC) に関心を持っている人がいたので、とりあえず、Omeka Sで使えるようにしてみました。
これが正しい方法なのかどうかよくわからないので、もし間違いなどありましたらぜひご教示ください。
国際アーキビスト評議会、ICA が提唱する新しいアーカイブズの標準、 Records in Contexts ですが、基本的にハードルが高いので、うまく入り込むのに何か便利なツールはないかと思って色々みていたところ、 RDF/XMLのファイルが提供されているようでしたので、これを使って Omeka Sに取り込んで使えるようになるのではないか、ということでちょっと試してみました。
まず、RiCの概要は以下のURLのとおりです。
https://www.ica.org/standards/RiC/RiC-O_1-1.html#namespaces
これをOmeka S で簡便に使えるようにするには、NamespaceのURI (IRI)と、スキーマのファイルが必要になります。NamespaceのURIは、上記のページの中に以下のような表がありますので、これを手がかりに、まずはオントロジーを使えるようにします。ricoの行にある 「https://www.ica.org/standards/RiC/ontology#」をコピーしておきます。
それから、スキーマのファイルの方は、以下のように書いてありますので、GitHubの方に行ってみて…
ontology/current-version というディレクトリに入っていくと、RiC-O_1-1.rdf というファイルがありますので、このraw fileをダウンロードします。
これで準備は終了です。
次に、Omeka Sへのインストールですが、まずは「左側のメニュー」から①「語彙の一覧」を選んでから、②右の上のボタンを押してください。
そうすると、新しい語彙セットを登録する画面になりますので、先ほど用意した情報やファイルを用いて以下のように入力します。
成功すると以下のような画面になって、一覧の一番下に、Records in Contextsが追加されてますね。
これで、アイテムを追加する場面などで RiCの語彙を使えるようになります。
タグの操作に慣れるのが大変なので、MSワードでタグ付け作業をしたい、というニーズが最近は見られるようになってきました。そこで…
MSワードで背景色をつけて、それに対応するTEIタグに変換するスクリプトを作ってみました。
MSワードは、実はXMLで構造化されたデータなので、TEIへの変換は原理的にはかなり簡単です（ただしレイアウトが複雑になると難易度が増します）。
Python の場合、この変換を簡単にしてくれる便利なモジュールがありますので、まずは以下のコマンドにて、それをインストールしておきます。
$ python -m pip install python-docx
Google Geminiなどに聞けば色々教えてくれるので、細かいことはそちらに聞いていただくとよいので、ここでは概要だけ。
MSワードの docx ファイルを 7zなどのZIPファイル展開ツールで無理矢理ZIP展開すると、ファイル名と同じ名前のフォルダができます。そのなかの「word」というフォルダの中の document.xml というファイルが、本文のファイルです。これをなんか便利なツールで（Googleとかでもよい）開くとXMLタグのついたテキストが表示されます。
ここで、たとえば、イベント名のところにシアン色の背景色をつけた場合は、以下のようになります。
「<w:highlight w:val="cyan"/>」という風になっていますね。この「w:val=」の値である「cyan」が、つけた背景色の名称です。これをキーにして、対応するタグ名を設定することになります。
以下のプログラムはかなり単純な構造のファイルの場合に有効なものですが、この「tag_hl_dict=」という辞書の値に、背景色とそれに対応する変換したいタグの名前を入れていくと、あとは…（以下に続く）
from docx import Document import sys doc = Document(sys.argv[1]) all_text = '<body>' ns = {'w': 'http://schemas.openxmlformats.org/wordprocessingml/2006/main'} #以下のところに背景色名と対応するタグ名を記入していくとそれに対応するタグが追記される tag_hl_dict={'yellow':'placeName','green':'orgName','cyan':'eventName' } for p in doc.paragraphs: all_text += '<p>' for run in p.runs: rpr = run._element.xpath("w:rPr/w:highlight") btext = run._element.xpath("w:t")[0].text if rpr: atval = rpr[0].get('{http://schemas.openxmlformats.org/wordprocessingml/2006/main}val') if atval != '': all_text += '<'+tag_hl_dict[atval]+'>'+btext+'</'+tag_hl_dict[atval]+'>' else: all_text += btext else: all_text += btext all_text += '</p>' all_text += '</body>' print (all_text)
（上から続く）以下のようなコマンドで変換できます。簡単ですね！
$ python [このスクリプトのファイル名] [変換したいワードのファイル名]
ちなみに、上記の例では、placeName, orgName, eventNameのタグを、それぞれの背景色に対して付与している例です。ワードの文書は以下のような感じに書いていて、
そこから、以下のようなXMLが出力されます。
ごく簡単なものですが、これで概ね必要事項は提供できていると思います。
ついでに書いておきますと、ルビを処理したいときは、またちょっと異なるので、以下のものを参考にしてください。以下のものは、ワードのルビ機能を使って正規化テキストを書いている場合に、それを変換するものです。ルビを単にルビに変換したいだけという場合は、choice, reg, origのタグを、それぞれruby, rb, rtに修正すれば大丈夫です。
from docx import Document import sys doc = Document(sys.argv[1]) all_text = '<body>' for p in doc.paragraphs: all_text += '<p>' for run in p.runs: all_text += run.text ruby = run._r.xpath("w:ruby") # runに振り仮名が存在するか調べる if ruby: r = run._r.xpath("w:ruby/w:rt/w:r/w:t")[0].text t = run._r.xpath("w:ruby/w:rubyBase/w:r/w:t")[0].text all_text += '<choice><reg>'+t+'</reg><orig>'+r+'</orig></choice>' all_text += '</p>' all_text += '</body>' print (all_text)
このスクリプトと上のスクリプトの合わせ技をすれば、両方できるはずですが、「ルビ付きの人名」のようなものだと微妙にややこしいことになるかもしれないですね。そのあたりはまたいずれ…
くずし字や手書き文字を認識してくれるソフトウェアやサービスが最近ちょこちょこと出てきています。多くは商用サービスだったり、フリーだったとしても、サービス提供サイトにアクセスしなければ利用できなかったりします。
このような流れのなかで、フリーソフト／オープンソースソフトウェアとして開発・公開されているものもいくつかあります。海外で代表的なものに、escriptoriiumというソフトウェアがあります。日本でも、国立国会図書館が古典籍OCRを開発してフリーソフトウェアとして公開しています。
6月3日（火）の午後に、この二つのくずし字・手書き文字認識のオープンソースソフトウェアの開発プロジェクトの方々が慶應大学三田キャンパスに来てくださって講演をしてくださいます。ディスカッションの時間もありますので、色々有益な話が聞けるはずです。お時間がおありのかたは、ぜひご参加ください。
シンポジウムの詳細は以下のサイトをご覧ください。
ついでにこれらのソフトウェアについてごく簡単に解説しますと、
escriptoriiumは主にフランスのチームで開発されているもので、元々はアラビア系文字などの右から左に書く言語向けに開発されていたものだったようで（詳しくは宮川創氏の論考をご参照ください）、ラテン文字以外のものへの対応にも優れています。フランスINRIAのサイトでサービスとして提供されていますが、オープンソースソフトウェアなので、自分のコンピュータにインストールして使うこともできます。dockerでインストールできるようになっていますので、dockerに慣れている人なら簡単にインストールして動かせます。これなら、用途に応じてはやいコンピュータを用意してみるなど色々工夫もできますし、何より、サービス提供者側の都合に振り回されずにこういうものを動かせるということには、時として少し安心感があります。
日本の国立国会図書館による古典籍OCRは、上記のオリジナル版以外に、最近 Lite版も出て、パソコン上で簡単に動かせるようになったのですが、性能面では、オリジナル版の方がかなり性能は良いです。オリジナル版の方は、GPUを使用する必要がありますので、GPUチップを装備したパソコンを用意する必要がありますが、いわゆるゲーミングPCには大体ついているものですので、すごく高価なものではありません。デスクトップPCなら15万円くらいで入手できるのではないでしょうか。そして、ここでもやはり、dockerを使うことで簡単にインストールできるようになっています。
ということで、dockerを使えるようになることで、以上の二つのソフトウェアは比較的簡単にインストールできますので、dockerの使い方を覚えるのは有用です。これ以外にも、dockerを使えばインストールが簡単になるソフトウェアというのが各地で開発されています。もしちょっと時間があって何か新しいツールの勉強をしてみようかな…と思っている人は、具体的なツールに手を出す前に、dockerを少し覚えてみてから、dockerを介してインストールできるツール、を探してみると、一気に幅が広がって面白い展開になるかもしれません。
デジタルアーカイブのシステムは、依拠しているOSやサーバソフトウェア、開発フレームワークのアップデートや機器のハードウェアの寿命等により、概ね5年程度で更新しなければなりません。2018年頃から日本でも広まってきたIIIF対応デジタルアーカイブのサーバも、そろそろ各地で更新・更改・アップデートの時期を迎えているかと思います。その際に、担当者の方々に気をつけていただきたいことがあります。それは、URIを変えないでいただきたい、ということです。これは、IIIF Imageサーバや IIIF maunifest URIだけでなく、 IIIF Presentation APIの中の Canvas URIも変更されると困るものの一つです。
とはいえ、担当者の方々が、「変えないように自ら作業する」ことは基本的にないと思いますので、これは、発注時に仕様書に書いたり、担当企業にきちんと伝えていただきたい、ということです。
これまで、すでにいくつかうまくいかなかった事例がありますが、なかには、最初に導入する際に、「システム更新すると同じURIを維持できないような設定」をしてしまっている企業もあるようです。技術的には、HTTPリダイレクトをすることによって解消できる場合もありますが、ですので、最初の導入時、あるいは、それが間に合わなければ次の導入時に、URIを変えずに済むようなシステム導入の仕方をしていただく、ということになります。
特に変えてしまうとまずいURIは、具体的には、以下のものです。
IIIF Image API URI
IIIF manifest URI
IIIF manifest の中の Canvas URI （何ページ目の画像かを表す）
IIF manifest の中の AnnotationPage URI (IIIF Presentation API version3の場合）
これに加えて、IIIF manifestをバージョン2からバージョン3にアップデートするときは、 同一のIIIF manifest URIで入れ替えをしてしまうと、外部からの内部リンクが切れてしまうので、バージョン2を残したままでバージョン3を新規に別のURIで作成してください。
これがうまくできないと、結局、IIIFに準拠して作成された研究データの寿命がシステム更新とともに終わってしまう、ということになります（実際、某大学図書館のデジタルアーカイブを対象に相当人件費をかけて作成したものがすでにダメになってしまったので途方に暮れております）。目立つ事例としては、各地の絵巻から顔画像を切り出したURIのデータが、IIIF Image API URIが変わったことによってまったくアクセスできなくなってしまった、というものもありました。
昨今、大学図書館ではデジタルアーカイブを研究データの一環として扱ってくださるような流れもできているようでありがたく思っておりますが、研究データのサスティナビリティ、という観点から、この課題にもきちんと取り組んでいただけるとありがたいと思っております。
このあたりでお困りの方は、企業でも図書館博物館文書館文学館でもご相談にのりますので、ぜひご連絡ください。 特に、この関連の仕事を担当し始めたけど、何の話をしているのかよくわからない…という人は、なるべくサポートいたしますので、当方までご連絡をお願いいたします。
あるいは、自力で勉強しようという人には、『IIIFで拓くデジタルアーカイブ』（文学通信）をおすすめします。書店で購入することもできますが、オープンアクセスでも公開されています。
なお、データ作成側でも自衛措置を講じた方がよいのですが、それを可能とするためにはオープンライセンスで公開していただくことが重要になります。
昨日・一昨日に開催した国際シンポジウムで、人文学資料に人工知能技術を応用する研究をしているが発表する場がない（から知りたい）…とおっしゃっている人がいたので、改めてそういうことに関する情報をまとめておきます。
まず、分野名としては、国際的にはデジタル・ヒューマニティーズと呼ばれるもので、日本ではこのカタカナ表記以外にもデジタル人文学や人文情報学、文化情報学と呼ばれるものも概ねこの種の研究が対応しています。
ということで、まずは情報処理学会の分科会を見てみると、これに関連しそうな色々な研究領域が存在していて、基本的には査読無しで発表できる研究会を開催しています。なかでも「人文科学とコンピュータ研究会」は、年間3回の査読無し研究会を開催しており、人文系でも幅広く色々な分野の人が集まりますので発表しやすいと思います。もちろん、査読無しの発表ですので評価はそれなりにしかなりませんが、むしろ色々と議論できるということに着目していただくのがよいかと思います。
それから、この人文科学とコンピュータ研究会は、毎年12月頃に査読付き発表を集めたシンポジウム「じんもんこんシンポジウム」を開催しています。査読を経るのでそれなりに良いクオリティの発表が集まるように思います。2024年は東北大学で開催され、人文学をターゲットとしてAIを扱う研究発表が多く見られました。
また、そもそも人工知能研究の本拠地である人工知能学会も査読無しで発表できるスロットがありますので、そちらで発表するという手もあります。私は今年人工知能学会でポスター発表をしましたが、結構色々な人が興味を持って質問やコメントをくれました。
もう少し人文系に寄った学会としては、日本デジタル・ヒューマニティーズ学会（JADH）もあります。こちらは年一回の査読付き国際会議を日本で開催しており、来年は大阪で開催です。また、日本語と英語の論文誌も刊行しています。
海外に目を向けると、このJADHが加盟しているAlliance of Digital Humanities Organizations (ADHO)が世界最大級のデジタル・ヒューマニティーズの国際会議を毎年世界のどこかで開催しており、来年はリスボン、再来年は韓国が予定されています。また、このADHOはオックスフォード大学出版局から論文誌を出したり、オープンアクセスジャーナルも刊行したりしています。いずれもSCOPUSに収録されている雑誌ですので業績評価基準が厳しいところでもカウントしてもらいやすいですが、特にオックスフォード大学出版局のものはインパクトファクターもついているので、業績評価という観点ではこの種の分野では結構おすすめなのではないかと思うところです。
他にもたくさんあるのですが、とりあえずこのあたりにしておきたいと思います。お役に立つことがありましたら幸いです。
