4 漢籍リポジトリの使用例

研究者から研究者への電子テキスト

概要

この章では漢籍リポジトリのデータを活用する四つの例を紹介する:

  • (I)データ中の問題を訂正し報告する
  • (II)翻訳する
  • (III)共同作業
  • (IV)分析的な処理

これらのプロセスは順を追って複雑になるが、それぞれの節は独立しており、別々に読んでも理解できる。

(I)データ中の問題を訂正し報告する

漢籍リポジトリの編集者は、ユーザーコミュニティからの貢献に頼ってテキストの正確さを向上している。効率と透明性を高めるためには、その目的のためにGitHubとgitに組み込まれている報告メカニズムを使うことを勧める。それをどのようにして行うかの例をここに紹介する。その手順はソフトウェアのソースコードの問題を報告する一般的なプロトコールに準じているので、いくぶん面倒であり、ひどく複雑である。ユーザーが踏むべきステップを減らすためにこの手順が簡素化されることを期待するが、そうなったとしても主要なステップはまだ必要である。ここにそれらの概要を述べる:

(1)テキスト中の誤りや問題を見つける。その問題が見つかった翻刻バージョンとデジタルファクシミリがテキストの同じ版を表していることを確認する1

(2)当該テキストを自分のアカウントにフォークする。

(3)GitHubで編集するためにテキストを開き、必要な変更を行う。

(4)変更をコミットする。これで、kanripo.orgの自分のアカウントにログインしてこのページを見ると、これらの変更が反映されているはずである。

(5)すべて問題なければ、プルリクエストをすることでこの問題を@kanripoに報告できる。

(6)編集者がこのリクエストに応対し、何の問題もなければ、その変更を@kanripo上のブランチにマージする。

(7)これで、訂正されたテキストがすべてのユーザーに提供される。

以下の例がこれらのステップをより詳細に説明している。

(1)問題

ここでの場合、図1にある太極圖図を論じるテキストを見ている時に、私たちはある問題に気づいた:テキストには円で囲まれた文字が記載されているのに、その五行の文字が入力されていないことである。

krp-pr-problem.png

図 1:私たちが訂正したい問題

(2)テキストをフォークする

1において、ユーザーkrptestはすでにkanripo.orgにログインしている。それでGitHubリンクをクリックすると、図2に示されているように、@kanripoのGitHubアカウント上の対応ページが表示される。

krp-pr-kanripo.png フォークボタンをクリックするとフォークするプロセスが開始される。ほんの少しの間を置いて、図2に示されているように、テキストがユーザーのアカウントに表示されるはずである。これでユーザーがkanripo.orgウェブサイトのテキストを見る時、@krptestのアカウントにあるコピーが@kanripoのアカウントのそれよりも優先して使われる2

krp-pr-krptest.png

図 2:テキストが@krptestのアカウントにフォークされた

(3)編集のためにテキストをGitHub上で開ける

テキストのフォークされたバージョンが準備されたので、図1にあるGitHubリンクをクリックすると、今度はテキストが直接、編集するために@krptestのアカウントで開かれる。これが編集するためにファイルを開けるのに常に最も早くて安全な方法である。自動的に正しいブランチ、この場合にはWYGに置かれるからである。

krp-pr-editing.png

図 3:編集モードにあるテキストKR3a0023

3はGitHub上の編集モードにあるテキストを示している。145行目の私たちが変更したい箇所がハイライトされている。ここでは、翻刻テキストとデジタルファクシミリが並んで表示されているkanripo.org上のページをもう見ることができないので、新しいブラウザーウィンドウにGitHubリンクを開けるとよい。図4に示されているように、両方を同時に見ることが可能になる。この図はまた、望みの文字を入力するために使われる文字ビューアーも表示している。もちろんこれは常に必要ではなく、またパソコンの環境によっては利用できないかもしれない。

(4)変更をコミットする

文字が追加されて変更をコミットする準備ができた状況が図5に示されている。何がなされたかを説明するコミットメッセージを付けることを習慣にしておくとよい。その下の図6はユーザー@krptestのリロードしたページを示している。今では五行がきちんと載っている。

(5)プルリクエストをする

すべて問題がなければプルリクエストをすることができる。これはそのテキストの@krptestのGitHubページから行う。図2にある緑のボタン「Create pull request」をクリックすることでプルリクエストを開始できる。図7に示されているように、正しいブランチを指定するよう注意しなければならない。ここでは「ベースフォーク」(プルリクエストの対象)が「kanripo/KR3a0023」の「WYG」ブランチに設定されており、「ヘッドフォーク」(プルリクエストの出所)が「krptest/KR3a0023」の同じブランチに設定されている。ブランチが正しく設定されていなければ、プルリクエストは何の役にも立たない。すべてが正しいことを簡単に確認できるように、スクリーンの下部に二つのバージョンの比較が表示されている。 システムメッセージ「Able to merge」はブランチが自動的にマージされることを示している。これはプルリクエストの成功に必要な条件である。すべて問題がないので、@krptestは緑のボタン「Create pull request」をクリックしてこのリクエストを実際に実行する。このボタンの隣りに書かれているように、これによって編集者と、また事によれば他のユーザーとも、変更についての話し合いが開始される。

(6+7)編集者からの応答と統合

8はプルリクエストが@kanripo上で編集する許可を持つユーザーにどのように見えているかを示している。この変更についての話し合いはすべて、編集者が最終的に「Merge pull request」ボタンをクリックすると決定するまで、ここで行われる。ボタンをクリックした時点から、この変更は@kanripoのすべてのユーザーに提供される。しかしながら、この変更の前に自分のバージョンをフォークしたりクローンしたユーザーは、この変更を利用するためには、それらのコピーを更新しなければならない3

結論

ここで説明したステップは、漢籍リポジトリのテキストにどのように変更を加えるかを示している。誰が、いつ、なぜこの変更を提起したかの記録は継続して入手でき、すべてのユーザーが確認できる。 現在のところ、変更を提起する一連のステップはまだいくらか複雑である。ウェブサイトの今後の更新でこのプロセスはより簡単になるだろうが、フォークし、編集し、コミットし、ユーザーがプルをリクエストし、編集者と変更を話し合い、そして最終的に編集者がマージするといった全般的な順序に変わりはないであろう。 このプロセスが複雑すぎるようなら、あるいはテキスト中の問題を簡単に解決できそうにないなら、テキストの「issue」を開くという方法をいつでも使うことができる。これはGitHub上の@kanripoアカウントにあるテキストにアクセスすることで行う。特定のテキストを見ている時、そのページの「GitHub」リンクからその場所に行くことができる。(しかし、すでにテキストをフォークしてある場合、このリンクはあなたのコピーを表示する。しかしそこからフォークされたテキストのページ上のリンクを通り、簡単に「origin」に行くことができる)。円で囲まれた「?」と「Issues」の小さなボタンから「Issues」ページに行くことができる。そこでは緑のボタン「New Issue」をクリックして新しい問題を開くことができる。それに短い題を付け、その問題の版、巻番号、ページ番号も含め、それをできるだけ明確に説明すること。

krp-pr-two-windows.png

図 4:二つのブラウザーウィンドウと文字ビューアー

krp-pr-ready-to-commit.png

図 5:変更が完了し、コミットする準備ができた

krp-pr-changed.png

図 6:kanripo.orgで変更を確認する(@krptestにのみ見える)

krp-pr-create-pr.png

図 7:変更を確定し、プルリクエストをする

krp-pr-pr-ready.png

図 8:プルリクエストの準備完了

(II)テキストと翻訳

よく行われる作業でクロースリーディングが必要とされるのはテキストの翻訳である。この節では、翻訳のためのブランチの準備やテキストのリフォーマットのプロセスを概説し、またこの作業を行う方法について紹介する。

この手順はいくつかのステップに分けられる。

  • 翻訳を保持するための新しいブランチを作る。
  • テキストをリフォーマットし、必要な場所に句読点を付ける。
  • テキストに翻訳を追加する。
  • 翻訳をGitHubアカウントにプッシュする(任意)

新しいブランチを作る

krp-trans-prep.png 翻訳はテキストと一緒に新しいブランチに置かれる。翻訳には長く継続した努力が必要とされるので、ウェブブラウザーはこのような作業に向いておらず、それでマンドクが使われる。このマンドクプログラムは、第三章で説明されているようなインストールと設定がなされているとみなす。興味のあるテキストは、例えば、F7を押して呼び出す「題名で検索」機能を使って調べることができる。すでに説明したように、テキストは「C-c d」を使って表示し(その行にテキスト名を入力する)、ダウンロードする(クローンする)。ここでの場合、フォークが作成され、リモートが追加される。 ほとんどの場合、マスター(master)ブランチから翻訳を始めると都合がよい。表示テキストと共に図10に示されているように、「C-x g」が押されており、ウィンドウの下部に表示されたMagitオーバービュースクリーンにはブランチマネージャーを表示するために「y」が押されている。このブランチマネージャーは三つの部分に分けられている。一番上の部分は「Branches」で、これはローカルのブランチを表示している。次の部分は「Krptest」で、@krptestのフォークされたテキストにつながっているブランチを表示している。また三つ目の部分は、テキストの元の位置である@kanripoにあるブランチを示している。カーソルはローカルのマスターブランチに置かれている。ここで私たちは、このブランチを基にした新しいブランチを作ろうとしている。それで、(「branching」の)「b」を押し、続いて「creating and checkout」の「c」を押す。(前にも述べた通り、「?」を押すことで利用可能なコマンドの記されたヘルプスクリーンを表示できる)。ウィンドウの一番下の行で、プログラムが使用するブランチの名前を聞いてくる。その名前として、カーソルがそこに置かれているので、「master」を提案してくる。「enter」を押すとこれが確定され、次の質問、新しいブランチの名前を聞いてくる。私たちは、これが英語翻訳のためのブランチになることを示すために「trans-en」という別の名前を選んだ。大文字だけを使わないという勧めに従うことは推奨されているものの、もちろん名前はまったくユーザー次第である。もう一度「enter」を押すとアクションが実行され、ローカルブランチの下に新しいブランチが現れる。名前の前の「@」はブランチがアクティブであることを示している。テキストを表示しているウィンドウ上部のヘッダー行が変わり、アクティブブランチが「trans-en」であることを示している。これで「q」キーを二度押すことでブランチマネージャーとMagitステータスウィンドウを閉じることができる。これでテキストを表示しているウィンドウがフルサイズに戻る。

krp-trans-show.png

図 9:マンドクメニュー“Display->Show markers”

krp-trans-markers.png

図 10:可視文字[visible markers]の付いたテキスト

krp-trans-start.png

図 11:翻訳のためにリフォーマットされたテキスト

krp-trans-done.png

図 12:翻訳が完了

krp-trans-kanripo.png

図 13:kanripo.orgウェブサイト上の翻訳

翻訳を開始する

実際に翻訳を始める前に、テキストと同じ行にその翻訳が書けるようテキストを少しリフォーマットする。これはすでに出てきた用語の翻訳を探しやすくするので、下訳の役に立つ。ここでは「一句一行」の形式を使う。このようにファイルを編集している間、改ページや改行を示す不可視文字を表示するとよい。これはメニューから「Mandoku->Display->Show markers」を使って行う(図9)。図10に示されているように、各行の終わりに「¶ 」文字が見られるが、これはマンドクテキストのフォーマットではベース本における一つの行の終わりを意味している。更に、ページ番号がそのフルフォーマットで表示され、現在のページだけでなく、テキスト番号(KR6q0332)と版(この場合は『新纂大日本續藏經』を意味するX)も示している。この情報はシステムが正しく機能するために重要であり、削除してはならない。しかしながら、必要であれば、そして文字の順序さえ変更しなければ、ファイルは問題を起こすことなく整理し直すことができる。

翻訳を開始する

11は、必要に応じて行がリフォーマットされ、翻訳開始の準備が整ったファイルを示している。これはもちろん、翻訳者がそちらを好むのであれば、一行ずつ行うこともできる。より快適にテキストで作業できるように、再び不可視文字を非表示にしてもよい(上記と同じメニューコマンドを使う)。図12は最初の数行を翻訳した結果を示している。翻訳とテキストは「tab」文字で分けられている。(「tab」を入力するには「C-q C-i」を使う。このいくぶん複雑な入力方法が必要なのは、tabキーがすでに別の目的に割当てられているからである)。tab-stopは30に設定されている(M-x set-variable tab-width<enter>30)。

GitHubアカウントにプッシュする

krp-trans-magit.png 翻訳がGitHubアカウントにプッシュされたなら、kanripo.orgを使っている時に@krptestでも利用可能になり、他のコンピューターでも使えるようになる。緊急事態の場合のバックアップとしても使える。

プッシュを開始するには、Magitを呼び出すために再び「C-x g」を押す。この時、表示は図16のようになる。ここで留意点が二つある:(1 )プッシュの宛先が欠けている(ブランチがローカルで作られており、リモートからプルされていないため)、及び(2)「unstaged changes」がある、つまり内部レジストリーにまだコミットされていないファイルの変更がある。それゆえ、プッシュする前に、この変更をステージし、コミットする必要がある。これを行う最も簡単な方法は、「c」を二度押すことである。図14に示されているように、これがコミットメッセージを編集するバッファーを呼び出す。カーソルがウィンドウの下部、コミットメッセージを入力すべき位置に置かれている。その他の部分はすべて情報のみである。ウィンドウの上部はコミットすべき変更を表示しており、下部のカーソルの下は変更を反映したファイルを表示している。何がなされたかを示す短いメッセージを書いた後、「C-c」を二度押すことでアクションが行使される。今では「Unstaged changes」についてのウィンドウの部分が消えている。

krp-trans-commit.png

図 14:メッセージエディターと変更ディスプレイをコミットする

krp-trans-magit-popup.png

図 15:Magitポップアップメニュー:「p」がkrptest/trans-enにプッシュする

これで実際のプッシュを開始できる。「P」(つまり大文字の「P」あるいはshift-「p」)を押すと図15に示されているようなもう一つのポップアップバッファーが表示される。このバッファーはアクションを完了するのにどのキーが利用できるかを示している。ここでは二番目のエントリー「Push trans-en to」が最も適切である。私たちが必要としているのはその一つ目の項目である。これが、今作ったばかりのコミットをGitHub上のユーザーアカウントへプッシュする。これを開始するために「p」を押した後、GitHubのユーザーアカウントとパスワードが以前に保存されていなければ、プログラムがそれを聞いてくるかもしれない。しかし通常はうまく行き、今入力したばかりのローカルとリモート両方のブランチのコミットメッセージを表示する。

これで変更がGitHub上で入手可能になり、kanripo.orgにアクセスするとそれを見ることができる。しかしながら、これからはテキストのマスターブランチではなく翻訳ブランチが見たいということを、まずウェブサイトに伝える必要がある。これは 「KR6q0332=krptest/KR6q0332/trans-en」 (user account/text number/branch) を図23に示されている設定ファイルの一つに追加することで実行できる。これがひとたび設定されロードされれば、図13にあるように、その結果がユーザー@krptestに見えるようになるはずである。GitHubリポジトリ上の変更はオーナーだけでなく、そのページにアクセスする誰にも見えるようになることにも留意すること。それゆえに、未完成の仕事でまだシェアしたくなければ、次の項で説明するプライベートリポジトリを使うか、あるいはただ単にGitHub上のリポジトリをプッシュしなければよい。

(III)テキストにアクセスし共有するためのワークフロー

時として、リサーチグループの複数のメンバーでテキストを読んだり翻訳したりすることがある。このような場合、そのリサーチグループ用の別のアカウントを設定し、ユーザーアカウントとしてではなく「organization」(組織)アカウントとして指定しなければならない。そしてグループのメンバーはこの組織アカウントに追加される。そうすることで、各メンバーは、それぞれのアカウントに保持しているコピーに加えて、あるいはその代わりに、共通で共有されたテキストコピーを持つことができる。

ここではリサーチグループのアカウントを「krp-zinbun」と呼ぶことにし、プライベートリポジトリを作るのに必要な許可を持っているものと仮定する。プライベートリポジトリはパブリックリポジトリから直接フォークすることができず、ローカルクローンを経由しなければならない。そのようなローカルクローンを作る簡単な方法はマンドクを使うことである。上記で説明したようにテキストを表示し、そのテキストをダウンロードするために「C-c d」を押せばよい。この場合、フォークは必要ないので、それを聞かれた時には「no」と答えること。このクローンがGitHub上でプライベートとして作られたリポジトリへとプッシュされる。このグループの管理者はリポジトリの設定をしなければならない。(その詳細はここでの説明の範囲外である)。

更に、アカウント@krp-zinbunにあるこのテキストのマスターブランチが、kanripo.org上ですべてのユーザーが見ているテキストを持っているものと仮定する。一方、各ユーザーはそれぞれ自分のブランチを持ち、そこで自分の仕事をし、その仕事が完了した時にだけそのブランチを共通のmasterにマージするものとする。更に、ユーザーはそれぞれがテキストの異なる部分を担当し、それをそれぞれ個人で準備し、後でその結果をグループに提供するものとする。

この作業のために完了すべきステップは、仕事がマンドク上で行われるかkanripo.orgウェブサイトで行われるかによって異なる:

  • マンドクでの作業の場合:
    • @krp-zinbunからテキストをクローン(=ダウンロード)する
    • ブランチを作る
    • テキストを準備する
    • 翻訳と注釈を追加する
    • マージとプッシュ
  • kanripo.orgでの作業ぼ場合:
    • テキストをユーザーアカウントにフォークする
    • ブランチを作る
    • テキストを準備し、翻訳を追加する(これはブラウザーの外で行なってもよい)
    • マージとプッシュ
  • 誰にも見えることを確認する(両方の方法)

マンドクでの作業の場合

マンドクのワークフローは、すでに説明した個別で準備する翻訳の場合ととても似ている。ここでは異なっている点に焦点を当てて説明する。

準備

ユーザー@krptestはこのリサーチグループのメンバーであり、上記の設定の元で担当箇所の仕事を始めるところである。ここでまず、このユーザーは他からの貢献がすでに記録されているかもしれないプライベートリポジトリからファイルを入手する必要がある。まず目録から必要なテキストを探し、「Don’t edit this file. If you want to edit, press C-c d to download it first.」を含むファイルを表示する。しかし、@kanripoアカウントからファイルを入手するための「C-c d」を使う代わりに、今回は「Mandoku->Maintenance->Download this text from other account」エントリーを使うことにする4。この機能を選択することで、使用するアカウント名を入力するよう促され、そこに「krp-zinbun」と入力する。これはもちろん、このリポジトリへのアクセス権を持っていてこそ可能である。すべてがうまく行ったなら、図16に示されているように、テキストがクローンされ、編集に利用できる。

krp-collab-ready.png

図 16:Magitディスプレイ:ローカル・マスターブランチ上で、ここから始まる新しいブランチを作る準備ができた

仕事を開始する

実際にこのテキストを編集し始める前に、@krptestはこのユーザーが他から影響されることなく働けるブランチを作る。このブランチは「work」と名付けられるが、他のどんな名前でもよい。図16のスクリーンに示されているように、このユーザーは上記で説明された方法でブランチを作る。

リンク「@work」が「Branches」の下に現れたなら、この「work」ブランチは使用でき、設定は完了し、実際の仕事が始められるということである。仕事をしている間、図21に示されているように、「C-c i」を押すことで、いつでもそのページのデジタルファクシミリを表示できる。

仕事が終了したなら、いつもの方法でそれをコミットできる(C-x g、そしてcとc)。その仕事はまだローカルコンピューター上にあるだけで、他の誰にも提供されていない。

マージし、プッシュする

@krptestがその仕事に満足した場合、このユーザーはグループの他のメンバーにも見えるようにしたいと考える。これは仕事をGitHubにプッシュして戻すことで実行できる。しかしながら、このユーザーは別のブランチ上にいるので、まずこの仕事をマスターにマージする必要がある。それをする前に、この仕事をしている間にも他の誰かがマスターにプッシュしていないかチェックする。マスターが最新のものであることを確認するために、ブランチマネージャーに行き(C-x g、そして「y」)、マスターブランチに変更する(「master」の行で「enter」を押す。「@」は使用できるブランチを示している。これをするにはすべての変更がコミットされていなければならない)。

ここで@krptestは、変更をGitHubからマスターへとプルするために「F」(shiftl「f])を押す。ポップアップスクリーン(図18)では、これは「u」を押すことで行われる。これでマスターブランチは最新のものになり、@krptestはこのユーザーの変更をマージしプッシュできる。マージは「m」を押すことで行われる。これは図19に示されているように、追加オプションのスクリーンを表示する。何がマージされるかを見るためには「p」を押してプレビューを表示する。これがどのブランチからマージされるか(「work」)を確認し、何がマージされるかを表示する。図20において、下部がプレビューを表示している。赤い線が削除されるものを、緑(部分的に表示)が置き換えられるものを示している。「q」を押すことでプレビューを閉じ、すべてが良さそうであれば「m」を押して実際のマージを行う。

22が新しい状態を示している。マスターの後に「[origin/master: ahead 1]」とある。これは、今では私たちがリモート「origin」からのマスターブランチより1コミット分先であることを意味している。このウィンドウの下部にはorigin/masterがこれより前のコミットの状態であることを示している。「P」(プッシュ)を押し、続いて「u」(宛先「origin/master」)を押すことでプッシュを実行する。このアクションの後、グループのアカウント@krp-zinbunにあるKR5e0001のマスターブランチは、@krptestのコンピューターのバージョンと同じ内容を持つことになる。

krp-zinbun-fork-branch.png

図 17:krp-zinbun/KR5e0001からブランチを作る

kanripo.org での作業の場合

テキストをフォークする/新しいブランチを作る

チームの方針次第で、ブランチを別のフォークに、あるいは直接グループのリポジトリに作成できる。ここでの場合、図17に示されているように、前もってフォークすることなくブランチが作られている。

テキストを準備し翻訳する

これで、テキストをGitHubサイト上のブラウザーで直接編集することができる。あるいは、テキストを別の場所にコピーして、後でそれをペーストしてもよい。

マージし、プッシュする

マージは上記「(I)(5)プルリクエストをする」と同じ方法で、「プルリクエスト」によって開始する。しかしここでの場合、グループのメンバーが、masterにマージすることでプルリクエストを完了するのに必要な権限を持つ必要がある。

すべてのメンバーに見えるようにする

変更がどのように開始されたとしても、それがグループ@krp-zinbunのメンバーであるすべてのユーザーに、彼らが図23に示されているようにそれを設定中でリクエストしたならば(設定にはプロファイルページのglobal.cfgファイルへのリンクから最も簡単に行き着くことができる)、kanripo.orgウェブサイト上で見えるようにしなければならない。これは、すべてのメンバーが、マンドクを使っていない者でさえ、この結果を見られることを意味する。

結論

マンドクと漢籍リポジトリの組合せは共同作業のための新しいツールを提供する。最初は複雑で面倒に思えるかもしれないが、実は説明の方が実際に使うよりもずっと複雑である。そのうちにツールも改良されるであろう。例えば、それは研究会議のために、ワードプロセッサーを使う必要なく、直接プリントアウトを準備するようになるはずである。

krp-collab-pull.png

図 18:Magitディスプレイ:「u」を押してmasterにプルする

krp-pull-merge-confirm.png

図 19:Magitポップアップメニュー:「p」がkrptest/trans-enにプッシュする

krp-collab-merge-preview.png

図 20:Magitディスプレイ:ローカルマスターブランチにマージする変更

krp-collab-complete-w-fac.png

図 21:右にデジタルファクシミリを表示しているマージ完了後のテキスト

krp-collab-merge-complete.png

図 22:マージ後:originより1コミット分先

krp-collab-kanripo.png

図 23:@krp-zinbunメンバーのためのkanripo.orgでのディスプレイ

(IV)分析的な処理

この最後の節では、漢籍リポジトリを使って作業する、より高度な方法を紹介する。ここで検討する研究課題の例は以下の通りである:

「与えられた用語のリストについて、これらの用語に最も関連のあるテキストは何か?」

この質問に答えるためには、これらの用語の一つ一つをデータベースで検索しなければならない。そしてその一つ一つの用語について、その用語を含むテキストを記録し、テキストごとに一致した用語数を計算しなければならない。この作業が自動化を必要としていることは明らかであるが、問題はそれをどのように行うかだ。

これは実のところマンドクを使えばわりと簡単にできる。マンドクの基盤であるorg-modeは、実行可能コードを「文芸的プログラミング」と呼ばれる形でドキュメントに埋め込むことを可能にする。そのようなドキュメントはまた、ワードプロセッサー形式に、あるいはPDFにさえ簡単にエクスポートできる。これがいくつかの分野で話題になっている再現可能な研究(reproducible research)の理想的なツールにしている。なぜなら、これが研究の記述、研究の基礎となるデータ、そしてデータを分析するのに使われるプログラムを単一パッケージの中にひとまとめにするからである。

このことを実証するために、データのレポートを作成するのに使われるドキュメントを準備した。

ドキュメントをダウンロードしデータを準備する

用語リストの入ったテキストについてのレポートを作成するのに使われるドキュメントは mdplus から入手できる。このドキュメントをダウンロードし、(例えば自分のDocumentsフォルダーに)保存し、そしてこれをEmacsで開ける。

このドキュメントへのインプットはこのファイルと同じレベルに位置する「input」と呼ばれるフォルダーの中に置く。ここでの場合は「Documents/input」である。この例では、以下の用語リストが入っているbing.txtという名前のテキストファイルが使われる。

分析を実行する

krp-babel-srcblock.png

図 24:「C-c C-c」で実行されるコード

24は実行されるべきコードの入ったいわゆる「source block」を示している。コードを実行して分析を始めるためには、カーソルを「#+BEGIN_SRC」で始まる行に移動させ「C-c C-c」を押す(つまり、「control-C」を続けて二度押す)。Emacsがスクリーンの下のミニバッファーの中に「Evaluate this emacs-lisp source block on your system? (yes or no)」という問いでコードを実行する意図を確認してくる。「yes」をタイプし「enter」キーを押す。これもまた二度行う必要がある。

これでEmacsは「input」フォルダーに置かれたファイルの中の用語一つ一つを漢籍リポジトリで検索する。この結果は後で分析を行うために保存される。長いリストは検索にだいぶ時間がかかることに留意すること。この段階が終了するとこのプログラムの別の部分が結果を見てレポートを作成する。

結果

この検索の中間結果は「data」と呼ばれるフォルダーに置かれる。各インプットファイルごとに「data」フォルダーが作られ、各フォルダーには更に二つのフォルダー、rawとindexが入っている。rawフォルダーは漢籍リポジトリのインデックスサーバーから戻されたこの検索の結果を記録する。これらの結果はレポートを作成するのに使われる。二つ目のフォルダー、indexはマンドクで表示されるようにフォーマットされたインデックスを含んでいる。このレポートは結果についてより詳細に検査するために、これらのファイルとリンクできる。

25は作成されたレポートの最初の部分で、用語の一致結果の多い順にテキストを示している。青いテキストコードはハイパーリンクになっており、これが図27の上部に示されているように、より詳細なディスプレイを表示する。これらの用語もまたハイパーリンクになっている。ディスプレイの下の部分は用語「鬼病」の詳細を表示している。これは、この用語をライブサーチした時に表示される情報と同じものであり、これらのリンクもまた同様にしてテキストのその場所にジャンプするために使うことができる。(実のところ、ファイルに保存された結果を呼び出す代わりにライブサーチを行うようにリンクの設定を変えることもできる)。これは漢籍リポジトリのテキストと同じ形式のファイルなので、例えば現在の質問には関係のない一致結果を削除したり、研究者からのコメントをアノテートするために、編集し、保存し、コピーすることができる。

krp-babel-results-by-texts.png

図 25:レポートの冒頭

krp-babel-results-by-section.png

図 26:検索結果の多い順でのセクション

krp-babel-results-with-index.png

図 27:テキストKR6k0206の詳細と鬼病のインデックスディスプレイ

結論

レポートはファイルに含まれているmdplus-print-results機能で作成される。この特定の機能はEmacs Lispで書かれているが、さまざまな他の言語(Python、Ruby、R、Perlなど5)のどれで書くこともでき、同様にしてEmacs内からの実行が可能である。異なった分析が必要な場合、この機能を望みの結果を生み出す別の機能に変えるだけで通常は事が足りる。 分析のためのソースコードを、分析の指示や結果、集められ分析されたデータと一緒に、このような形でまとめて持つことは、他の研究者とソースコードや研究成果を共有することを容易にし、また他の研究者が結果を簡単に再現することを可能にする。

最後の節で実証したこの機能性は、そのほとんどをEmacsの拡張でありマンドクの基盤でもあるorg-modeに依存している。org-modeは研究者が活用できる更に多くの機能を持っている。例えば、研究出版物をorg-modeで書き、それをLibre OfficeやHTML、PDF形式にエキスポートすることを可能にする。実のところ、今回のこのレポートを作成するためにもこの機能性は使われた。

1
マスター版は一つの版だけを表しているのではないので、もちろん例外である。しかしながら、それは解釈的版なので、どのような不一致も、それは編集者が意図したものかもしれない。それで変更のリクエストも異なった形で議論されるべきである。
2
これはデフォルト設定であり、後で実証するように(図26を参照)、必要であればこの設定を変更できる。
3
フォークの場合、フォークを「リベース」すること。クローンの場合、それが元々クローンされた場所であるリモートからプルを行うこと。
4
このコマンドはテキストをまだダウンロードしていない場合にのみ利用できる。テキストをすでに@kanripoからダウンロードしているならば、そのテキスト@krp-zinbunを追加リモートとして加えればよいだけである。
5
この機能についての更なる情報はOrg Manualの第14章にある。orgman

参考文献