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

デジタル小技

ここしばらく、国立国会図書館デジタルコレクション（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 font や Releases · googlefonts/noto-fonts · GitHub など、選択肢が提供されている状況です。筆者としても、これを使って色々やるべく準備中です。

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

f:id:digitalnagasaki:20201231232724p:plain

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

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

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

JATS/XML オープンアクセス

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

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

というわけで、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応用 IIIF環境準備 Mirador

本日、初めての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上にあつまれ動物の森の動画に３つだけアノテーションがついたものが表示されるはずです。 この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）

JATS/XML オープンアクセス

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

  • あとで追記します。

６. というようなことで、全文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動画アノテーションのご紹介

IIIF応用 IIIF Mirador

追記：動画に色々描き込んだりするのは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

Methodological Commons: デジタル人文学で昔から定番の話

デジタル人文学

前回のブログ記事では、最近回顧されているデジタル人文学の話題としてScholarly primitivesを採り上げてみましたが、そうなってくると、そもそもデジタル人文学の基礎的な概念として常に採り上げられる Methodological Commons（方法論の共有地） についても、この機会にちょっとご紹介しておいてもよいのではないかと思いまして、それが最初に提示された、以下の著名な講演原稿の暫定訳を掲載いたします。（例によって、間違いなどあるかもしれませんのでご注意ください。）

eadh.org

追記： 著者の一人であるHarold Short先生から、最新版の画像をいただきましたので、掲載いたします。(2020/12/22)

Methodological Commons
Methodological Commons

著者のWillard McCarty先生と Harold Short先生は、いずれもキングスカレッジ・ロンドンの人文学コンピューティングセンター（当時）の教授で、今で言うところのDHを研究していました。キングスカレッジ・ロンドンは、欧州DH学会発祥の地であり、前回記事に登場したJohn Unsworth先生の話にも出てきたところですね。これもやはりデジタル人文学（DH）という言葉が出てくる前ですので、Humanities Computingと呼ばれていました。この後、2004-2005年頃に、ロンドンのHarold Short 先生と米国のJohn Unsworth先生が中心となって国際デジタル人文学組織連合（ADHO, Alliance of Digital Humanities Organizations）が設立されますので、その胎動期の象徴的なものの一つと言ってもよいかと思います。

このMethodological Commonsは、国際DH学会大会では必ずどこかで見るような、とても広く受け入れられているDHの基礎概念です。それで、象徴的な「地図」があるのですが、どうも本家のサイトからはリンク切れになってしまっておりまして、しかし、たとえば、現在のADHOの会長によるこちらの頁でも見ることができますし、色々なバリエーションも出現していることがGoogle画像検索ですぐにわかります。以下の文章は、この地図の説明が主な内容ですので、地図を見ながら読んでいただくとよいかと思います。

なお、Methodological Commonsは、「方法論の共有地」と訳されることが多いのですが、これも、海外のDHの議論と接続するには英語のままで流通していた方がわかりやすい時も あるかもしれないと思いまして、この用語だけは英語で記しています。

それから、この文書に登場する Humanities Computingという語は、「人文情報工学」という訳語をあてていますが、これは現在の文脈では「デジタル人文学」と読み替えていただけますと幸いです。

Methodologies

方法論

科学的研究には、2つの出発点がある。いずれにおいても、それ自体として権威がある。観察を否定することはできず、原理的なことに適合していなければならない。挟撃作戦を達成しなければならないのである。Gregory Bateson, Steps to an Ecology of Mind (Chicago, 1972): xxviii

分野をマッピングする

Mapping the field

誰もが知っているように、マッピングとは、複雑な地形を表現するための強力なツールであり、それは我々が地形を全体として理解し、その部分の相互関係をすばやく把握できるようにするためのものである。「ロードマップ」とは、当然のことながら、どこかの場所に行くためのものだが、しかし、それに先立って、そこに至るまでにどのような選択肢があり何が関係しているのかを確認するためのものである。それに先立ち、地図の歴史における最近の研究成果で主張されるように、地図を作成することは、地図に書かれた地形を所有し、それをそのままに明示することである。特徴があるところには名前が付けられ（あるいは名前が付け直され）、関係が表示され、境界線が示され、未知の部分にはラベルが付けられるなど、探査のためのしるしがつけられる。

　ここで示す知的な「地図」は、これらのうちの最後の役割を果たすことを企図している。これは、この半世紀の間人が住んでいたにも関わらず我々の視界に今まさに入ってきたばかりの地形を予想する仮の見取り図である。1990年代初頭まで、人文情報工学は様々な研究活動の事例のカタログを作ることによって説明されるべきものであると考えられてきたように思われる。しかし、その頃には、そのようなカタログを作ることは非常に困難なことになっていた。あまりに多くの分野において、多くの言語で、マイナーな場でもメジャーな場でも、あまりに多くの刊行物が出版されていた。さらに、既存の分野にコンピュータ利用が組み込まれていくことは、関連する研究活動の多くが、とくに言及されることもなく、タイトルから手がかりを得られないような論文や本に含まれるようになることを意味している。 我々が、全体像と、そして、我々の経験に対応する専門家自身の概念を把握しようとするなら、異なるアプローチが求められているのは明らかである。このことは、書誌学的なプロジェクトが放棄されるべきであると言っているわけではない（再考の必要性を提示しているのではあるが）。むしろ、ベイツソンの挟撃作戦を我々の現実に適用しなければならないということである。

ここで例示するマッピングの活動は、地図そのものというよりはむしろ、ポイントである。その領域の全体的な概念を明晰に表現する手段を提供することによってその作戦の補完的な動きを助けることを意図している。

Methodological Commons
Methodological Commons

Legend

The Methodological Commons

方法論の共有地

地図の中心には、この分野の中核として、「Methodological Commons」と我々が読んでいる大きくて境界の曖昧な領域がある。それは、様々な分野のアプリケーションが共有する計算可能な手法のための概念上の領域である。よく知られているように、たいていの場合、これらは、データのタイプに応じて適用されるものであり、データの主題やそれに対する解釈に応じてではない。したがって、ここにあるのは、散漫な（あるいは連続した）テキスト、表形式の（あるまとまりを持った）テキスト、数値、画像、音声等である。同様にして、時間的な次元を有する（画像と音声のような）数種類のデータについて考えてみたいと思うかもしれない。これらのテキストに適用される技術は、テキスト分析、データベースデザイン、数値解析、画像化、音楽情報検索などのような大まかな見出しで記述されるかもしれない。もちろん、常に新しい手法が考案されているのであり、このリストは決まったものでも安定したものでもない。

Disciplinary groups

分野ごとのグループ

このCommonsの上には、おおまかな分野ごとのグループで人文学（と場合によっては社会科学）の分野が描かれている。これらのグループは、部分的には分野についての我々の観点を反映しているが、部分的には我々の高等教育機関における新しい学際的なグループ化を反映している。両頭の矢印はそれぞれの分野のグループをデータのタイプや、それと一般的に関連のある計算手法と結びつけている。この矢印が両頭なのは、人々のグループと商人との間で行われる商品の流通のように、個々のグループとこのCommonsの間で活発な手法の交換が行われることを示している。この分野別のグループ化とこれらの矢印は、同様に仮説的なものである。というのは、制度的な整理の仕方は、国家や文化の境界を越えて変化し、多様化するからであり、そして、新しい技術は、古い分野が関連を持つと考える事柄を変化させることになるからである。

“Clouds of knowing”

知の雲

このCommonsの下に幅広く並べられているのは、我々が見出してきた、様々な分野の習得事項である。それらは、我々に求められていることに関して非常に重要な役割を果たしているために、それらへの理解がその分野のいずれかの知的な地図に影響を与えざるを得ないというものである。最初は、これを理解するという仕事は、超人的なものに見えるかもしれない。しかしながら、これらの雲は哲学などに包括的に精通していることを示そうとしているのではなく、むしろ、我々の実践に適用するための特定の領域の実務的な知識を示そうとしているのである。たとえば、伝統的なものを電子媒体に作り直すこと、すなわち、編集版や注釈、語彙集などの学術的な形式をもつものを対象とする場合、我々は、その対象が何を目指して、どのような用途を意図していたか、ということを復元できるように、可能な限り元の文脈に近い形で理解する必要がある。そういった知識は、多くは暗黙的なものであり、すなわち、当時は言わずもがなだったものである。この知識を獲得することに関する歴史学と民族学における豊かな議論は、この問題の深さを我々に警告し、そして、それに取り組むためのツールを提供してくれる。

Methodological Commonsを維持・涵養し、他の分野との知的な取引を運用する仕事に関する他の「知の雲」についても同様のことが言えるかもしれない。これらは、以下のようなことを示すために雲として表現されている。すなわち、（アリストファネスに、そして同様に、「知の雲」の中世の匿名の著者の両方に感謝しつつ）、思考体としての性質と、人文情報工学におけるそれらの役割についての我々の暫定的な理解、である。繰り返しになるが、それらは正典的な一覧ではない。我々は、どれが我々の地図の上にあり、それぞれがどのように適合するかを確認し始めたばかりである。

このような地図の価値は、「一枚の絵は千の言葉に値する」ということわざの概念にあるのではなく、むしろ、我々が考えることや知っていることを引き出し、そして、よりよい地図や、さらに、人文情報工学におけるより意識的な、そして直接的な活動へと至る議論を惹起するためのイメージの力にある。

History and new directions

これまでとこれから

厳密に言えば、上の地図にあるもののほとんどは新しいものではない。ほとんどすべては十年前には存在し、知られてもいたものである。しかし、我々が提示してきたように、マッピングの活動自体は、ここに示したような形において、この領域を二次的に（あるいはメタに）考えることについての根本的に新しい方向性なのである。

10年前には、我々は様々な分野に対して共通の技術を関連付けることについて十分な知識を持っていた。人文情報工学が分野としての境界が適用されないMethodological Commonsに関係していることについて、最初は疑問を持ち、その後、ある程度は理解していた。実際のところ、その頃には、人文学によくみられるいくつかの研究の側面に関連付けられる計算手法の抽象的な概念やソフトウェアの基本的なタイプを描くことが可能になっていた。当時、画像処理は（OCRを除いて）地図上に載せるほど重要なことではなかったが、今回新たに追加したことになる。その頃の「コミュニケーション」は、現在のように、Webを中心とするようなものではなかった。

　たとえばこの五年間の間に、最近の経験的知識には、明らかに学際的な成果やさらなる可能性を伴う、大規模なリソースを基礎とした多様な技術・多様なメディアの研究が増えてきている。事実上、ネットワーク化されたリソースは、単一で比較的変化のないリソースが多種多様で変化の激しい用途から分離され、個々のリソースが関連する多くの研究分野を横断した曖昧な再文脈化を許容するという研究図書館の古のモデルを顕在化し始めている。この学際的なデジタル図書館の出現は、Methodological Commonsを断片化するというよりもむしろ、その中心性と幅の広さを強調している。そして、Commonsの中心性と幅の広さは、我々が技術の適用に際して必要な方法論の受け入れをより体系的に研究するのに必要であるところの「知の雲」を実際に利用していることをいっそう明らかにした。

この地図は、人文学における知の雲と特定の研究プロジェクトの間で共有された技術を媒介として、人文情報工学の根本的な役割を描き出している。とりわけ、この媒介を通じて、人文学の研究事業においてこの知の雲はからみあいつつ成長していくのである。

Willard McCarty and Harold Short

Creative Commons Attribution 3.0 Unported License.

Scholarly primitives: 最近デジタル人文学で話題になっている話

デジタル人文学

欧米のデジタル人文学業界も、最近はオンライン会議がよく行われるようになったり、SNSでの発信もますます活発化したりして、海外に行かなくても海外の様子が垣間見えることが増えてきました。

そこで気づいたことの一つが、かつて話題になっていたScholarly primitivesという考え方が改めて脚光を浴びているようだ、ということです。

知る限りでは、DHにおけるScholarly primitivesは、Digital HumanitiesがまだHumanities Computingと呼ばれていた2000年頃に、当時はヴァージニア大学で Institute for Advanced Technology in the Humanitiesを率いておられたJohn Unsworth先生が提示されていたのが最初であったように思います。John Unsworth先生はその後イリノイ州立大学アーバマ・シャンペーン校に 移って図書館情報学研究科長までされて、さらにブランダイズ大のVice provost兼CIOを経て、現在はヴァージニア大学に戻って図書館長をされているなど、英文学出身の DH研究者でいらっしゃいますが図書館・図書館情報学に非常に縁の深い先生です。

さて、Scholarly primitivesの話に戻りますと、DH関係の会議等では、時々、John Unsworthが提示するScholarly primitivesは…ということで議論されたりするのを 見かけることがありましたが、最近、ヨーロッパの人文学デジタルインフラプロジェクトであるDARIAH (Digital Research Infrastructure for the Arts and Humanities )の 学術大会で、Scholarly primitivesがテーマとなって、さらにJohn Unsworth先生が基調講演をされたようです。

DARIAH Annual Event 2020 - Sciencesconf.org

これだけでも大変興味深いところですが、さらに、この会議で 3D Scholarly Editions: Scholarly Primitives Reboot という発表をされた Susan Schreibman先生がベストペーパー賞を取られたとのことで、3DとScholary primitives、という組み合わせにも なかなか興味をそそられるところです。Susan Schreibman先生と言えば、TEIで書いた校訂テキストをきれいに表示してくれるViersioning Machineというソフトウェアの 開発プロジェクトを率いておられたり、DHの代表的な教科書であるCompanion to Digital HumanitiesのエディタをJohn Unsworth先生達とされたりと、DH界では重要なお仕事を色々してきておられますが、最近は3Dの学術利用（＝学術編集版の構築）に力を入れておられるようで、すでにこの方面のフルペーパー "Textuality in 3D: three-dimensional (re)constructions as digital scholarly editions"も出しておられます。時間があれば、 このフルペーパーもじっくり読んで勉強させていただきたいところです。

というわけで、最近話題になっている、Scholarly primitivesですが、John Unsworth先生がWeb公開しておられる2000年の講演原稿がありましたので、

https://johnunsworth.name/Kings.5-00/primitives.html

みんなで原点回帰してみよう、ということで、とりあえずざっくり抄訳をしてみました。（抄訳というにはちょっと長いかもしれませんが…）。分野がちょっとずれると、日本語の学術論文でもなかなか手強いことがありますので、英語が 読めると言っても分野違いだったりDHを始めたばかりだったりするとなかなか読むのも大変かもしれない、ということで、誤訳もあるかもしれないのでご注意をお願いしたいところでも ありますが、英文で読むのはちょっとしんどいけどざっくり内容を知りたい、という人は、よかったらちらっとご覧になってみてください。

（なお、抄訳なので、原文に掲載されている画像は表示しておりませんので、図についての説明がでてきたら、原文のサイトの方でご覧ください。）

あと、Scholarly primitivesの良い日本語訳を思いつかなかったので、それは英語のままにしております。良さそうな訳語をみんなで考えてみましょう。

"Scholarly Primitives: どんな手法を人文学研究者は共通して有しているのか、そして、我々のツールはそれをどのようにして反映するのだろうか？"

part of a symposium on "Humanities Computing: formal methods, experimental practice" sponsored by King's College, London, May 13, 2000.

By John Unsworth

アリストテレスによれば、科学的知識（エピステーメ）は、自明な文（公理）の有限のリストから演繹的に従う文で表現されなければならず、そして、自己理解できる有限の用語リストから定義された用語（primitives）のみを使用しなければならない。『スタンフォード哲学百科事典』

「自己理解できる用語の有限なリスト」としてのPrimitivesという概念は、それ以上の定義や説明なしに公理的論理を進めることができるものだが、それは、（おそらくご存じのように）特に20世紀には、哲学や数学において困難に直面していた。しかし、ここでの目的はそれを解決することではない。ここでは、分野や時間、そして個々の理論的な方向性を超えて研究活動に共通する基礎的ないくつかの役割を表現しようとするために、「primitives」という言葉を自覚的に類推しつつ用いている。これらの「自己理解」の機能はより高いレベルでの学術研究に関するプロジェクトや議論、言明、解釈の基礎を形成する。それは、我々が本来持っている数学的哲学的類推や公理の観点からみたものである。私の「Scholarly primitives」のリストは網羅的なものではなく、その一つ一つを平等に扱うわけでもない。追加提案や変更・削除についての議論は歓迎するが、とりあえずの出発点として以下を挙げる。

Discovering／発見

Annotating／注釈

Comparing／比較

Referring／参照

Sampling／サンプリング

Illustrating／例示

Representing／表現

これらを提示することでとりあえず私が目指すのは、人文情報工学（現在のDH）において管理できるというだけでなくきちんと役立つツール開発の事業のための基礎となり得る関数（再帰的関数）のリストを提案することである。私の Primitives のリストには特に順序はない。実際のところ、そのうちの二つ、ここで真にprimitivesといえるものは、Referring／参照とRepresenting／表現である。というのも、これらはいずれも、他のどれにでも何らかの方法で含まれるからである。この二つに関しては、後述する。リストの全体に関して私が議論したいのは、これらの活動が時代やメディアを超えて学術研究の基礎となるものだということである。そして私が特に関心を持っているのは、デジタル情報、特に、ネットワークで接続されたデジタル情報に基づく学術研究である。

私が「Scholarly primitives」という言葉であり概念でもあるものと格闘し始めたのは、一年半ほど前、このキングス・カレッジ・ロンドンでのことであり、テキスト分析ツールに関するイギリス／米国の共同研究を資金的に支援するためのまったくうまくいかなかった努力の一環であった。（そういえば、私の Scholarly primitivesのリストでは「物乞い」という昔からの研究活動も含んでいるだろう）。この提案書では実際にはprimitivesという単語は使われなかったが、しかし、共通のアーキテクチャーがあれば、より高次の（公理的な）機能を達成するために組み合わせることができるいくつかのツールとして具体化できるかもしれない、学術研究のいくつかの基本的な機能を確かに想定していた。

この提案の次に行ったものは、それもまたうまくいかなかったが、米国人文学基金に提出したものであり、実際にその単語を用い、その概念を説明した。「人文学研究の機能的な原始関数」という章で、その提案書では以下のように述べた。

このプロジェクトが前提としているのは、「比較」が最も基本的な研究上の行動の一つ、すなわち、人文学研究の機能的な原始関数である、ということである。多種多様な資料を扱う様々な分野の研究者達が、いくつかの（時には多くの）分析対象を比較したいと考えている。それらの対象には、テキストであれ、画像であり、動画であれ、人が創り出したあらゆるものが含まれる。

少しの間その提案書から離れて、Scholarly primitiveとしての比較という点を止めて、いくつかの画像でそれを描写させていただきたい。まずはIATH（ヴァージニア大学のDHセンター）のユニコードブラウザ、次に、もうじき公開されるBlake Archive version 2.0のユーザインターフェイスである。

Babbleは、異なる言語系統・文化的伝統における共通の物語の要素を扱うテキスト群を比較しようとする宗教研究のプロジェクトの産物である。その比較は、潜在的には構造的なものであり、章や偈頌のような単位をキーにしたものになるかもしれないが、しかし、そのまま照合したり差分を確認したりできるわけではない。テキストそれ自体は概念的には対比可能であるものの、文字符号化という観点からは比較できないものだからである。Babbleを構築するという課題の大部分は、このような並置をWebを介して公開するという要件にあった。上記の図のような例では、三種類の文字セットがあり、これは画面に表示するためのUnicode文字エンコーディングとシステム依存フォントの間の水域を移行できるようにするJavaアプリケーションを開発することを意味している。（そして実際に、この種のシステムフォントを扱うJavaのメソッドに関するサンマイクロシステムズ（当時Javaを開発公開していた企業）の移行戦略があった）。言語を横断するテキスト比較のように、資料からは単に概念的な支援しか受けずに機能できるというのは、Scholarly primitivesの特徴であると言っていいだろう。これらのprimitivesは、減ずることのできない学術研究の通貨であり、原理的に言って、あらゆる形式やトークンの境界を横断して交換することができるはずである。

比較に関する二つ目の事例は、Blake Archiveである。研究者や学生がBlakeの彩飾本の様々な刷りを比較できるようにすることは、このアーカイブが初期に目指したことであった。このアーカイブの現在のバージョンでは、インターフェイスはアーカイブのSGMLデータのジャンル・作品・刷り・版という階層構造を（かなり厳密に）反映している。そのため、二つの版を比較するためには、ユーザは階層をたどって一つの版を見つけた後に、二つ目のブラウザを開いてもう一度やり直し、そして、同じ版から別の刷りへとたどっていく、ということをしなければならない。このような使い方は、このアーカイブの設計として禁止されているわけではないが、確かに有効になっているというわけではない。比較する必要性とはとても基本的な要件であるということを認識した上で、我々は、このインターフェイスを改良した。どの本におけるどの版からでも、ユーザは、同じ作品の異なる刷りにおける同等の版のセットを引き出すことができる。あるいは、ユーザは、あらゆる別の作品におけるあらゆる別の刷りへと直接に飛ぶこともできる。それは以下のようなものである。 （図）

ユーザインターフェイスへのこれらの変更はまったく単純なものだが、二つの理由から、それらの変更は研究ツールとしてのこのアーカイブの有用性を大幅に高めた。一つは、それらの変更により、様々な理由で操作中に呼び出せる機能が提供されたこと（つまり、それらは、一つのscholarly primitiveを実現している）、もう一つは、それらが構造的・非構造的という二つの方法で比較するという特殊なprimitiveを提供しているという点である。ユーザは一つの操作でパラレルな版を画面に呼び出すことによって構造的なデータを活用することができ、そして、そうすることで、ユーザは、比較される対象を含む構造によって比較に対して課された制限を回避することもできる。この階層構造は、資料の作成と維持に際しては絶対に必要だが、しかし、末端ユーザの観点からは同等な機能的重要性が必ずしもあるというわけではない。我々は、その一つの操作でアーナイブ内の二点をつながせてくれる操作方法により、階層構造からさらに自由になる。（そして、現在のインターフェイスのユーザにとっては常識となっているその場しのぎの比較の手順は新しいレベルに引き上げられる。）

米国人文学基金の提案書に戻ろう。

二つ目の機能的なprimitiveは、我々の観点では、selection選択である。比較のための対象の選択だけでなく、同様に重要なのは、選ばれた対象の中の関心を持つ領域の選択である。三つ目の機能的なprimitiveは、linking関連付けである。関連付けは、注釈という古典的な形式におけるものでもあり、二つのデジタルな対象の間の、それ以上の数のデジタルな対象の中で、そしてデジタルな対象の内部において、有用な関連を創り出すという、より抽象的な意味におけるものでもある。

これは、IATH(前出)で作成されたWeb配信可能なJavaソフトウェアInoteを用いて、画像の選択されたサブセクションへの注釈のリンクを可能にしている。

InoteのアイデアはBlakeアーカイブからではなく、むしろ、ロゼッティアーカイブと影の谷（南北戦争の歴史）プロジェクトの初期の頃に出てきたものである。二つのプロジェクトはいずれも、たとえば私が万能ワープロでしているような、一つのページ上でテキストを用いて情報を単純に囲むよりも、より明確な、画像ベースの情報に取り組むための方法を求めていた。Webの初期には、「注釈サーバ」というものがあり、ユーザは、注釈をつけられた資料を見ている他の人と、そのサーバ経由で注釈を共有することができた。しかし注釈はページ全体に付与することができるが、もっと小さな単位に付与することはできなかった。つまり、画像全体に対してであって、その特定の部分に対してではなかった。それは1993年のことであった。2000年も、状況は同じである。注釈の共有は、すべての学術的な意思や目的にとっては、Web上では不可能なものであった。いくつかの興味深いが格好のよくなスキームや回避策が開発されてきたが（この中では、Inoteは、欠点はあるものの、実際にはまったく良いものに見える）、これに関してユーザができることは多くはない。

この例でも「selection選択」というprimitiveが働いていることがわかる。Inoteにおける注釈は画像の一部の箇所に付与されているからである。Inoteの用語においては「detail」がそれにあたるものである。Selection選択は、一般的に言っても重要である。というのは、何かの関連する部分に取り組むことを許すからである。InoteとBlakeアーカイブの場合、これは画像検索においてもっとも明瞭に見られる。そこでは、ユーザは、（上の図のような「子供と蛇」を探す場合には）、一つもしくは複数の検索語を選択して、戻ってくる検索結果は、突き詰めて言えば「sector CD of America, Copy A, Plate 13（Americaの画像のCセクションとDセクション、刷りはA、版は13）」という風になる。このアーカイブの初期の頃から、我々はこのようなことをしたいと自覚していた。したがって、このアーカイブのためのマークアップは、編集者がBlakeの版の資格的な内容を記述できるように設計されており、それはグリッド状の位置情報に紐付けられていた。すなわち、四分割してAは左上、Bは右上、Cは左下、Dは右下、Eは全体、といった案配である。それらの位置は結合することもできる（したがって、上記の例では、蛇はCDに登場すると言うことができる）。そして、検索結果は、検索語に対応するその版のセクション編集上の説明を提示する。その下にはInoteボタンがある。ボタンをクリックするとInoteソフトウェアを起動し、特定の箇所にフォーカスをあてつつInoteを開くことのできるボタン（検索結果からスタイルシートで生成される）を表示する。そのようにして、ユーザの検索に応答できるようにBlakeの版を複数のパートに分割してそれらのパート、あるいは版自体を完全に表示するのではなく、むしろ、Blake向けに特化された有用性を発揮できる非常に単純かつ重要な機能的振る舞い（scholarly primitive）に対応するようにInoteを設計することによって、逆に、まったく異なる文脈においても一般的に同じような有用性を発揮できるのである。 　Inoteを話題としている間に、先ほど説明したように、そして他の方法でも指摘しておく価値があることだが、我々は、Blakeアーカイブのデータ構造や、より高い次元の（より公理的な）学術的な意図のためにソフトウェアをカスタマイズするという衝動に抵抗することにうまく抵抗してきた。その代わりに、我々は、このソフトウェアを、基本的な、しかし応用範囲の広いprimitiveな機能を提供するprimitiveなツールとして維持してきた。もし今日ここにいる我々が、共同の形であれ個人としてであれ、scholarly primitivesを実現する別のソフトウェアの開発に参加するとしたなら、これは守らねばならない重要な原則である。このようなprimitiveを実現しようとするソフトウェアは実際の学問的な利用の文脈で開発されテストされるべきだが、しかし、カスタマイズには抵抗するべきである。というのは、目的特化型のソフトウェアやプロジェクト中心のソフトウェアは機能的なprimitiveを幅広く支援できそうにないからである。

　もう一つのprimitiveは「Samplingサンプリング」である。これは、selection選択と密接に関連している。サンプリングとは、実際には、何らかの基準に基づくselection選択の結果である。その基準は検索語の場合もある（その場合には、selection選択の結果としてのサンプルは検索された資料の本文に登場する頻度のサンプルということになる）。あるいは、基準それ自体が頻度の割合、たとえば「1秒あたり5フレーム」のようなものかもしれない。その場合、そのサンプルは、5秒ごとにカメラのフレーム内に世界をサンプリングした画像が連なったもの、ということになるかもしれない。ここで、もう一つの画像の事例を提示しよう。これは、様々な種類の人々（聖書、神話、中世の人々）を参照する情報を検索するものであり、ダンテの神曲を扱うDeborah Parkerのプロジェクトである。ここでは、検索フォームは以下のようなものである：

ここにみえるのは、螺旋の形をした詩のモデルであり、この螺旋の中にある一つ一つの円は詩の編（カント）である。そして、それぞれの円にみられる一つ一つの点は、個々の編における一つの業である。円を越えて広がっているのは様々な色の三角の印だが、それらは最初の検索フォームでそれぞれの検索語に割り当てられた色と対応している。結果の全体は、VRMLのモデルとして表示されるため、我々は、その中で移動したり、上方に移動したり、結果表示に近づいて見ることができる。

ここで得られるのは、頻度のグラフ表示であり、サンプリングしたものがこのデータセットの中で生ずる割合を示すモデルである。この例が示すのは、サンプリングはそれ自体が（selection選択の単なる派生ではなく）、一つのscholarly primitiveである、ということであると提起したい。なぜなら、それは、ある種のユニークな機能すなわち、分散とクラスタリングを示す能力を暗示しているからである。

上記の例では、各フラグはTEIでタグつけされたテキストをDynawebで表示する際に、それが示す行へのハイパーリンク（リンク、あるいは参照というもう一つのscholarly primitive）である。このことは、scholarly primitiveのさらなる特質を浮かび上がらせる。すなわち、それは、他のprimitiveと組み合わせて、基本的なUNIXのツールのようにパイプでつないで最初の出力を次の入力とすることができるscholarly primitive の基本的な原則であり、このことは、ユーザにとっては可能であり一般的に行っているものでもある。このことが示唆するのは、さらに言えば、標準出力（STDOUT）と標準入力（STDIN）にあたるものが全体として重要だということである。我々がこれらのprimitivesを学術的な観点で具現化するために構築したツールは、その出力の次に何が起きるかを知らないままに標準的な形式で出力を生成する能力を持っていなければならないか、あるいは、その能力を持つプログラミング言語を用いなければならない。どこから来たのか、何が生成したのかを知らないままで標準的な形式で入力を受け取る能力についても同様である。

「reference参照」に関して言及すべきもう一つの原則は、参照における安定性の重要さである。このことは常に相対的な問題であり、完全に安定した参照というものは存在しないが、しかし、安定しているほど良い。Web上のリンクが機能しなくなるのはこの原則の典型例であり、我々は皆、その文脈における安定性のない参照の問題についてよく知っている。

私が先ほど「例示illustrating （もう一つのprimitiveに数える）」したNEHへの提案書はうまくいかなかったが、しかし、本日、ここでの私の目的の一部は、実際の所、それが良いアイデアであり、政府の助成金があるにせよないにせよ、我々が共同で目指すべきものである、ということを議論することである。なぜなら、まさに今、これらの非常に基本的な研究活動は、ネットワーク化された電子データに関してでさえ、まったく貧弱な支援しか受けていないからである。これらのすべてにおいて、ネットワークの重要性を強調しすぎることはできない。我々が著述authoringと呼んでいる活動のクラスを除けば、スタンドアロンのツールや資料を用いてできるもっとも興味深い事柄は、ネットワーク化されたツールや資料でできるもっとも興味深くないことよりも、興味深くもなければ重要でもない。真の乗数効果とは、他の人々と一緒に、非常に大規模で予測不能な資料の集合体を横断して、たとえ非常に愚かなことであってもできてしまうという時に生じてくるものである。巨大な、本当に巨大なWebの成功と文化的なインパクトは、私が提供できる最高の例である。ハイパーテキスト理論のコミュニティの誰もが述べるように、ほとんどすべての点で、Webはハイパーテキストの実装としては非常によくないものである。それが行ってきた唯一のことは、広く受け入れられた標準を用いるということであり、したがって、簡単にネットワーク化し、ソフトウェアを容易に書けるように前提の単純化を多く行ったということである。結果として誰もがそれを利用し、そして、そこにその価値が存在するのである。すなわち、多くの人がそれを利用し、多くのものを、それを利用している多くの場所で見つけることができるのである。

実際のところ、私は、もう一つのscholarly primitive、すなわち「discovery発見」についての議論の入口として、次のような命題、すなわち、スタンドアロンなツールや資料で実行できるもっとも興味深いことがネットワーク化されたツールや資料でできるもっとも興味深くないことよりも興味深くもなければ重要でもない、という命題を用いたい。それは、研究者が伝統的にアーカイブズにおいて行ってきたことであり、図書館の目録や棚で我々皆が行ってきたことであり、目録や学術論文の概要を検索する際に我々が行ってきたことであり、そして、今もなお発見のためのもっとも効果的な手法の一つであり、つねにそうであってきた、関心を共有したり、単純に共有すること自体に関心を持つ人と対話することである。それは、教師、仲間、そして、学生達である。彼らはしばしば、我々が予測しなかった、したがって求めることもできなかった方法で、我々の仕事にとって重要になるような資料に対する注意を引くことがある。

Webの世界では、発見discoveryのためのもっとも卓越したツールは検索エンジンである。（ポルノグラフィという例外を除いて、検索エンジンが最初に収益を上げたWebのサービスであり製品でもあるということは指摘しておく価値がある）。人文情報工学の世界にいる我々は検索に関していくつかのことを間違いなく知っている。たとえば、構造化データが、とてもよい、より正確で、より有用な検索結果をもたらしてくれることを知っている。そして、たとえ同じエンコーディングスキーマを使っているとしても、正確に同じ構造を持ったリポジトリが二つとないことも我々は知っている。そして、高度に構造化されたデータに対する高度に構造化されたアクセスから得られる利便性がコレクションの範囲に制限されることになり、そして、選択と符号化の原則、そのパースペクティブ、そして場合によっては、その利用規約によっても制限されることがある、ということも我々は知っている。そのことから、私が発見discoveryのプロセスを開始する時、私はいつも、最も構造化されておらず、もっとも一般的な検索から始める。すなわち、Webのグーグル検索である。非常に多くのデータが、ほとんど構造を持っておらず、コントロールしたり予測したり唯一の構造は、検索式だけである。

他の二つのscholarly primitives、注釈annotationと比較comparisonに関する資料を探し始めたとき、私はGoogleに行って「annotation and comparison」で検索を行った。私は学術的な活動としての注釈annotationと比較comparisonに関する議論や事例を探していた。興味深いことに、私が見つけたのは、ヒトゲノムプロジェクトを参照する検索結果であった。明らかに、注釈annotationと比較comparisonは分野横断的な機能的primitivesなのである。私が思うに、もしscholarly という単語を検索式に入れていたら、あるいは、もしGoogle（あるいはWeb上のデータ）がより構造化された検索を使わせてくれていたなら、私はこの検索結果をすぐにはみつけることはできなかっただろう。より構造的なものがあれば、私は、自分が見つけたいものに沿った少数精鋭の検索結果を得られるように自分の検索式を組み立てただろうし、生物学の領域で検索結果を得ることについては何の意図も特別な関心も持っていなかった。しかし、目的外の検索結果によるセレンディピティの価値についての経験を学んだがゆえに、そしてGoogleがどこからでも簡単に使えるがゆえに、私は、（本質的に）構造化されていない大規模なデータを横断する、構造化されていない検索、ただ検索式のみが構造化されているところから始めた。（おそらく、annotation and comparisonを検索する代わりに、もしcomparison and annotation を検索していたなら、それほど興味深い検索結果にはならなかっただろう。）

annotation and comparisonについて発見したのは以下の通りである。すなわち、生物学者もまたそれを行っているのであり、そして、遺伝学においては研究の基礎を成すものである。そのうえ、彼らは、人文情報工学の人々が取り組んでいるのと同様の社会的、技術的、知的問題の多くに取り組んでいる。私がここで最初に指摘したいのは、非常に大きなネットワーク化された情報を横断して実行されるprimitiveの機能の力は非常に大きいということであり、部分的にはさらに大きい、なぜなら、予期しないが意義のある結果をもたらすからである。疑いをさけるため、以下の資料を紹介しよう。左側の欄に掲載されているものだが、1998年にエネルギー省が出資した会議を記録したWeb文書から未編集の抜粋である。それはヒトゲノムプロジェクトに携わる計算機科学者と生物学者との間で行われたものであった。一方、私の二つ目のポイントは、修飾語句をさておくとしたら、scholarly primitivesというトピックから、情報学を特徴付ける一般的な実験の手法と問題点についての議論になるかもしれないものへのまさに出発点（そして出口）である。そして、資料の左側の欄には医療情報学についての議論があるが、右側の欄では、「ヒトゲノムプロジェクト」を「人文学分野プロジェクト」に、「生物学者」を「人文学者」に、「実験室」を「図書館」に置き換えている。しかし、それ以外にテキストには何も手を付けていない。私はこの改訂版を声に出して読みたい。というのは、私が思うに、我々はこの経験から重要な何かを学ぶからである。しかし、それをする前に、言わせていただきたいことがある。それは、私の検索結果を通じて私がしたことは、ある示唆的な方法でそれらを変形させるということである。そして、変形は表現の一種であり、もう一つのscholarly primitiveである。表現representation（左側）と変形deformation（右側）から学べることが、ここには示されている。 （以下、Human Genome ProjectとHumanities Genres Projectを並べたものが提示されているが、あとは原文を参照されたい）