般若心経をブラウザに読んでもらう(+簡単Javascript解説)

もうすぐ50歳になるおじさんなので、新しい情報にはかなり疎くなっております。若者達から色々教えてもらうように心がけているのですが、もう記憶力が弱いのか、周囲があまりカバーしてないのか、はたまた、色々問題があって人に言うほどではないと思ってしまうのか、よくわかりませんが、いつのまにかWebブラウザは日本語どころか般若心経もダイレクトに読み上げてくれるようになってるみたいですね。ツィッタで、ブラウザが日本語読み上げもできるという話が流れてきたので、そういえばこれでお経を読んでもらえばマニ車並みの功徳が積めるかも…と思って作ってみたのがこちらです。

knagasaki.github.io

もちろん、ひらがなで読み方を与えてごにょごにょすると普通に読めてしまうのですが、 大部分はそのままでも読めてしまうというのが少々感動するところです。

ソースコードは以下の頁でも確認できます。

github.com

ポイントはいくつかありますが、一番基本になるのは以下の箇所ですね。

         var ut = new SpeechSynthesisUtterance();
         if(e.getAttribute("data-r") == undefined){
           ut.text = e.textContent;
         }
         else{
           ut.text = e.getAttribute("data-r");
         }      
         ut.lang='ja-JP';
         ut.rate = 1.4;
         speechSynthesis.speak(ut);

般若心経のテキストは<span>で分割していて、共通のclassを与えることで、forEachで回して処理できるようにしています。 その上で、一部の<span>にはdata-r classで読み方の情報をひらがなで与えています。(あまりに間違い方がひどかったので!) 各要素のテキストは、.textContentでとれますので、あとは言語.langとレート.rateの値を与えて、さらにそれをspeechSynthesis.speak() に渡せば読んでくれます。

レートに関しては、こちらの頁に詳細が書いてあります。 0.1 から 10 の範囲で設定できるようで、デフォルトは1とのことです。

言語設定はこちらの頁に一応書いてあるのですが、 具体的にどの言語に対応するかという情報は書いてないようですね。こちらをみるとBCP47準拠の書き方をしろ、ということになっていますので、あとはブラウザ依存ということになるのでしょうか?

こちらの頁には他にもいくつか設定できるプロパティがリストされているので、ちょっと試してみると 面白そうです。

それから、上記の作例だと、読んでいるフレーズだけが赤くなります。このように色を変える方法には色々あるのですが、とりあえず「1. 読んでいるフレーズに色つきクラスを与える」「2. 読み終わったらそのフレーズから色つきクラスを外す」という風にしてみています。

「読んでいる」と「読み終わったら」というのは、こういうときは大体、イベントハンドラを利用することが多いです。 こちらの頁(再掲)には「イベントハンドラー」という項目がありますので、ここを眺めてみると、SpeechSynthesisUtterance.onstart (en-US)、SpeechSynthesisUtterance.onend (en-US)、というのがあります。これですね。 それぞれの頁の用例に沿って、クラスをつけたり外したりしてみます。

         ut.onstart = function(){
           e.classList.add('read-text');
         }
         ut.onend = function(){
           e.classList.remove('read-text');      
         }

もちろん、これができるということは、対応する画像があったらそれを頁のどこかに表示してみるとか、 地図も出してみるとか、いろんなことができてしまいますね。 これだけで、ああいうものが作れてしまうのですね。時代はどんどん進みますね。

「楽譜のデジタル化」という課題

筆者は、2000年くらいからTEI (Text Encoding Initiative) ガイドラインの勉強を開始し、デジタルテキストを用いた研究の可能性と課題について、探求と実践を繰り返してきた。デジタル化とは、単にデジタルカメラで撮影してメタデータをつけるだけでなく、全文テキストを作成し、その構造を何らかの方法で機械可読な形で共有することも含んでおり、そのようにすることで、テキストを主に用いるタイプの人文学を大いに振興することができるとともに、テキストを扱う研究の伝統的な営みを未来につなげていくことができる。

一方で、「楽譜」のことは横目に見つつ、いつも気になっていた。音として再現できるようにデジタル化するのは重要だが、それだけでなく、たとえば中世写本において、テキストの内容そのものが重要であるだけでなくそこに含まれる多層的な内容もまた歴史や思想の様々な痕跡の探求に寄与するが故に構造的にデジタル化する手法がTEIガイドラインを通じて高度に発達したのと同様に、音に関する情報だけでなく、楽譜の実際の書かれ方、あるいは演奏家によるメモなど、楽譜に含まれる様々な要素も何らかの形でデジタル化された方が研究の可能性を高めるのではないか、と思っていたのだった。

そうこうしているうちに、いつのまにか、Music Enconding Initiativeガイドラインというものが発生し、 主に北米やドイツ語圏で発達しはじめていることに気がついた。名前が想起させるとおり、TEIガイドラインと互換性があるようであり、TEIガイドラインの ように、研究者の要望に応じて柔軟に様々な記載内容を構造化できるものであった。そのように、技術的なことは なんとなく想定できるのだが、しかし一方で、これが音楽研究者、楽譜を研究対象とする方々にとってどのような 意義を持つのか、どのように有用なのか、ということはまったくわからずにいた。音楽や楽譜を研究しているわけでは ないので、それで困るというわけではないのだが、DHという枠組みで研究活動をしていると、デジタル音楽学を 研究する海外の方々ともそれなりに付き合いができ、話を聞いていると、このような、楽譜をデジタル化するための 重要と思われる手法の一つが日本であまり知られていないのはちょっとまずいのではないか、という気持ちもしてきており、それは 徐々に強まってきていた。

そのようにしてとても気になってきていた状況において、このMEIガイドラインを楽譜研究とそのデジタル化の流れのなかに 位置づけることを検討し、さらに論文まで書いてくださるという若手研究者が登場したのである。 ここでは、デジタル学術編集版楽譜、という、文献学にも通じる概念とともに、関連するMusicXMLとの対比の中でMEIガイドラインを位置づけている。 楽譜のデジタル化やその研究利用に関心をお持ちの方や、いずれそれに関わるかもしれないという人は、ぜひご覧になってみていただきたい。この論文は、 以下のURLにて、機関リポジトリで無償公開されている。

関慎太朗「デジタル楽譜の類型化とデジタル楽譜文化を支える フォーマットについての考察

そして、できることなら、ご自身の取り組みのなかでこれがどう位置づけられるかを検討してみていただけたらと思っている。 さらにわがままを言わせていただけば、それを、私信でも立ち話でもエッセイでも論文でもいいので、何らかの形で筆者にも伝えていただけると、なおありがたい。

KHコーダで形態素解析用の辞書に単語を追加する方法

KHコーダを使っていると、形態素解析がうまくできない単語をどうにかしたくなることがあります。 そんな時の対策の一つとして、形態素解析辞書に単語を追加するという方法があります。 ググればなんてことのない作業なのですが、一応、調べて、やってみた、ということで、 手順を間違えなければかなり簡単なので、ここでちょっとChasenでのケースをご紹介しておきます。

先日、大学生の授業に関するツィートを集めて分析してみたことがありました。 そのときの6万件とちょっとのツィートで「オンライン」という単語を前処理してから 見てみると、以下のようになりました。

f:id:digitalnagasaki:20210714171925p:plain

ここでは、抽出語で「オンライン」という単語を検索してみていますが、 この文脈だと「オンライン授業」という単語が出てきてほしいところ、 「オンライン」と、あとは謎の未知語しかでてきてませんので、おそらく 「オンライン」と「授業」は分割されてしまっています。そこで、 「オンライン授業」という単語を辞書に登録してみます。

まず、「khcoder」のフォルダの中の \dep\chasen\dic というフォルダに行ってみましょう。 そうすると、.dic という拡張子をつけたファイルがずらっと表示されます。

f:id:digitalnagasaki:20210714171620p:plain どれでもいいらしいのですが、とりあえず今回は一般的な名詞を追加したいので Noun.dic をテキストエディタなどで開いてみましょう。

f:id:digitalnagasaki:20210714173738p:plain

後々の整理のためには、文字列順に並べた方がいいかもしれないのですが、 とりあえずお試しということで、一番最後に以下の行を追加してみています。

(品詞 (名詞 一般)) ((見出し語 (オンライン授業 3929))  (読み オンラインジュギョウ))

品詞情報と、見出し語、読みを、一定のフォーマットで追記すればいいようです。 「3929」という数値がちょっと謎ですが、これは単語の現れにくさを表す値で、 数が大きいほど現れにくいということを示しているようです。とりあえずここでは 3929としてみていますが、もっと小さくしてもよいかもしれません。

辞書ファイルへの単語の追加が終わったら、次は辞書の生成です。 一つ上のフォルダにあがると、 Makefile.bat というファイルがあります。

f:id:digitalnagasaki:20210714174446p:plain

これをダブルクリックすると、黒いダイアログが開いてしばらく文字が 表示され、それが終わると勝手にダイアログが閉じます。これで、辞書は完成です。

あとは、KHCoderに戻って、もう一度前処理をやり直してみます…と、以下のような感じになります。

f:id:digitalnagasaki:20210714174557p:plain

なんと、半分近くは「オンライン授業」でしたね。こういう風になると、分析結果もちょっと変わってきそうですね。

という感じで、実は割と簡単にできますので、よかったら試してみてください。

曼荼羅上の菩薩の名前をIIIFで確認できます+あつ森対応の件

SAT大正蔵図蔵DBがアップデートされました。今回のアップデートで、IIIFアノテーションは2万件を超えました。 青山学院大学の津田徹英先生率いるチームによる作業で、科学研究費補助金の研究成果公開促進費(データベース)の成果でもあります。

今回の目玉はいくつかありますが、一つは曼荼羅画像の各菩薩等へのアノテーションです。 「等」というのは、たとえば獅子さんとか蟹さんなどもいらっしゃいますので。

f:id:digitalnagasaki:20210714024332p:plain

それはともかく、一つの曼荼羅に含まれる300~450くらいの各菩薩等に アノテーションが付与されましたので、これは大変に素晴らしいことです。 曼荼羅だけではありませんが、いわゆる「別紙」として大正新脩大藏經図像編に 含まれるもののうち、アノテーションが多くついているものを以下に並べておきます。 それぞれクリックしてみていただいて、津田先生達のチームの素晴らしいお仕事を堪能してみてください。

さて、改めて本件について簡単に解説しておきますと、このサイトは、SAT大蔵経テキストデータベース研究会(代表:下田正弘東京大学教授) のプロジェクトの一環であり、この研究会がデジタル化の主な対象としてきた大正新脩大藏經の 図像編に含まれる仏教関連図像の部分を属性から検索できるようにするためのシステムです。 詳しくはこちらの本chapter 01を読んでいただけるとありがたいのですが、 Web画像相互運用の国際的な枠組みであるIIIF (International Image Interoperability Framework)に準拠したアノテーションを 簡単に入力するシステムを開発して入力チームが数年かけて入力し、それを現在見ていただいている公開システムに 載せて検索閲覧できるようにしている、というものです。ちなみにこのブログの著者のここでの役割は、世間に 出回っているフリーソフトを組み合わせて、Webの入力システムや公開システムを作ったり、そのための 予算を獲得する書類作成のお手伝いをしたり、プロジェクトの進捗管理のお手伝いをしたり、といったところで、基本的に便利屋さんです。

さて、このデータベースを検索すると意外といろいろなものが出てきまして、たとえば「蟹」で検索するとこういう感じです。

f:id:digitalnagasaki:20210714031607p:plain

さらに、「あつまれ動物の森」に貼り付けるためのQRコード生成をすることもできまして、「あ」というリンクをたどると、 以下のような画面に来ます。

f:id:digitalnagasaki:20210714031741p:plain

ここで、切り出したい箇所を改めて選び直して、

f:id:digitalnagasaki:20210714031836p:plain

タイル数を選んで…

f:id:digitalnagasaki:20210714031917p:plain

「画像をタイルに分割」ボタンを押すと以下のように分割されます。

f:id:digitalnagasaki:20210714032027p:plain

そうすると、以下のように、QRコードがずらっと表示されますので、あとはひたすら取り込んでいくだけです。

f:id:digitalnagasaki:20210714032118p:plain

しばらく前にこの機能の開発にちょっとハマってしまって、任天堂の独自画像の フォーマットを分析してみたり、ビットごとに書いたものをバイナリ変換するプログラムを 書いてみたりと、結局以下のようなものを作ってしまったりして、さらに、こういうものを 公開しても問題ないかと任天堂の法務部門におうかがいを立てたりしておりました。

f:id:digitalnagasaki:20210714032411p:plain

さて、それはともかく、もう少しこのSAT大正蔵図蔵DBの説明に戻りますと、このDBでは「タグ」による検索ができます。 「検索」ボタンの隣にある「タグ」ボタンをクリックすると、以下のようにタグリストが表示されます。

f:id:digitalnagasaki:20210714032730p:plain

そこで たとえば「炎髪」を選んでから「検索」ボタンをクリックしてみると…

f:id:digitalnagasaki:20210714032914p:plain

このように「炎髪」を持つ尊格がリストされます。ここで、気になる尊格の名前のところに あるチェックボックスにチェックを入れると、そのサムネイル画像が、画面右上の「カート」に リストされていきます。

f:id:digitalnagasaki:20210714033319p:plain

その後、そのカートにある「並べて表示」ボタンをクリックすると、以下のように、 それぞれの頁が並べて表示されます。

f:id:digitalnagasaki:20210714033407p:plain

あとは、各画像を適宜拡大して比較すればよいのですが、右側の頁は90度傾いています。 こういう場合、画面右上のボタンをクリックすると…

f:id:digitalnagasaki:20210714033828p:plain

以下のように、画像を回転させたり色を調整したりするツールバーが表示されますので、ここで 画像を回転させます。

f:id:digitalnagasaki:20210714034000p:plain

そして、サイズを適宜ズームしたりすると、以下のように画像の比較ができます。 各ウインドウ左上のハンバーガーアイコンをクリックすると、左側のアノテーションパネルが 隠れて、以下のようにすっきりと画像のみを閲覧できるようになっています。

f:id:digitalnagasaki:20210714034118p:plain

さて、今日のところは眠くなってしまったのでここまでです。まだまだびっくり機能が あるのですが、また次の機会にということで、よろしくお願いいたします。

人文系研究者はデジタルに手を出しても評価されない?

(2021/07/06 午前、追記あり)

海外ではデジタル・ヒューマニティーズ(DH)が普及しつつあるのに日本では…という話は最近よく聞きます。 日本でDHについての話題が出ると、人文系のベテラン研究者の方々からは 「しかしデジタルに手を出しても評価されないんだよね…」という話をよく聞きます。

ではそれは 海外ではうまくいっているのかというと、海外でも完璧にうまくいっているわけではなさそうです。 ただ、多くの大学にDHセンターが設置されたり、DHのカリキュラムが提供されるようになったりして、 ポストがかなり増えてきていて、そうすると、そういったところで自分の分野での取り組みが なんらかの形で評価軸を持てるようになれば、そこで自分の分野の若手がポストを確保しやすくなると いった状況は生じるように思います。たとえば、文学や歴史学でデジタルに取り組んでいる人が そういったポストに採用されようと思った場合、ただデジタルについての知見のみで 勝負しろと言われたら基本的に分が悪いはずです。情報系の人よりちょっとデジタルが 苦手な人、以上の評価軸が出てこないからです。しかし、文学や歴史学において、 その人のデジタル的な仕事を評価する指標が用意されていれば、「デジタルについての知見は これくらいだが、それを文学(あるいは歴史学)において適用することについて、 文学(あるいは歴史学)においてはこのように評価されている」という形で 評価を受けることができます。そうすると、ただデジタルが苦手な人、として勝負するのとは まったく異なる展開になるであろうことは容易に想像できます。

しかし、そのために 評価指標を考えるような面倒なことをするのか…と思ってしまうかもしれませんが、 海外の一部学会ではすでにやっているようです。たとえば、アメリカ歴史学協会による 歴史学におけるデジタル研究を評価するためのガイドライン はまさにそういうものでしょうし、米国MLA(現代語学文学協会)も、 Guidelines for Editors of Scholarly Editionsというものを出しています。 さらに言えば、DHという領域自体も、MLAやAHAの研究者たちが米国では積極的に運営に関与してきた経緯があり、 歴史学や文学研究におけるデジタル研究の評価軸を作るというニュアンスが含まれているように思えます。 DHでは、査読付きジャーナルが複数刊行され、人文系ながら、SSCIにも登録することでインパクトファクターが つくようになったものもあり、これも若手に業績を作らせるためというニュアンスが強いようです。 査読付き国際カンファレンスも、大きなものが年1回開催されるだけでなく、世界各地で ローカルなカンファレンスが行われ、デジタル研究をすることで業績を積むことができる 仕組みも10年ほど前には確立していました。

さて、海外でやっているから、海外でうまくいっているからそれを日本にそのまま導入できるのかと言えば、まったく そんなことはなく、しかも、導入したからと言ってうまくいくとも限りません。日本の実情にあった 仕組みややり方を考えるのが大切です。

しかしながら、日本の実情、と言ったときに、 大小あわせて膨大な数の学会が乱立し、800近い大学が提供する多種多様なカリキュラムやポストを想定すると、 すべてに対応できるような汎用的な対応策を考えるのはなかなか難しそうです。一方、海外のように DHセンターが作られてポストがどんどん増えるということも少なくともすぐにはなさそうです。

とはいえ、最近は、「改革」の名の下に、データサイエンス系の学部をはじめ、横断的な教育研究を志向する組織が どんどん作られるようになってきています。また、新規組織でなくとも、伝統的な名称の 組織であっても内部でかなり体制を改築して学際的な研究ができるポストを作っていくことも 散見されるようになってきました。そうしますと、それにきちんと対応できるような横断的な対応のできる 人材を育成することも求められているように思われます。そこで、人文学の側から横断的な 教育研究のできる人材を輩出することができれば、若手のポストが確保できるというだけでなく、 研究分野としても幅が広がっていって、色々な面白い展開につながっていくことも期待されます。 その場合、必ずしもDHというわけではなく、化学だったり地学だったり、様々な分野との 横断の可能性を考えることはできるでしょう。ただ、他の多くの理系諸分野と異なり、 情報学、デジタルは習得するにも研究として利用するにも、費用もスペースもそれほど かかりません。デジタル技術のある部分はオープンムーブメントのまっただ中にあり、費用をほとんどかけずに なんとかしてしまうことさえ可能です。横断的な研究として取り組みやすいものとして、 DHは有用性が非常に高いと言ってよいでしょう。

そのように考えてきますと、デジタル技術を習得して横断的な研究、あるいは学際的な研究が できるようになることは、人文学や人文学を志す方々の未来を切り拓く上でもかなり有力な 選択肢の一つであるように思えます。とはいえ、デジタル技術を習得しただけでは、 たとえば横断的・学際的な研究の場にポストを得ようとしても何の評価もされません。 情報系の資格を持っていると少しアピールできますが、既存技術をマニュアル通りに 理解しているというだけでは、大学で教育研究を主導する立場になってもらうという 観点からの選考にはややアピール不足です。たとえば、競合する相手が情報系の 研究者であった場合、これはたとえば自動車を設計開発する人と運転免許を持っている 人くらいの違いになってしまうのであって、やはり、学術研究として取り組めているという 形になっていることが重要になるように思われます。

このようにして考えると、DHの研究業績を積むことは、研究者個人の生き残り戦略としては 有用のように思われます。もちろん、文学や歴史学そのものにおいて評価されているわけではないのですが、 DHという分野で評価されていることは示せます。文学や歴史学のポストにつこうと思ったら DHの業績はあまり(あるいはまったく)評価されないということもあるかもしれませんが、 スクラップ&ビルドが繰り返される大学の組織・ポストにおいては、評価軸を複数 持っておくことが保険として機能する場合も十分にあり得ます。JREC-INを見ていても、 DH的なポストの募集がかかる例は着々と増えてきていますし、デジタルと言わずとも 学際的な教育研究を求めるところでも、やはりDHとして研究業績を積んでいれば 評価されやすくなるように思われます。そのような観点に立つなら、 冒頭の「デジタルに手を出しても評価されない」というのは、そう言っている人やその周囲の人たち(=分野)が 評価しない、ということであって、研究者個人が評価されない、ということとは別の軸の話である のかもしれません。

また、そのように考えていくと、むしろ、文学にせよ歴史学にせよ、自分たちの分野で デジタル研究に関わる人の仕事を文学や歴史学として評価するような枠組みを用意しておけば、 自分たちの分野でそういった研究に関わろうとする人たち(特に若手)の将来を 選択肢を増やし、そして自分たちの分野の研究自体の将来的な幅も広げていくことにつながるのではないか、 という風にも思えます。これは全然突飛なことではなくて、米国ではもうずいぶん前に 始められていることです。

「デジタル成果物」の評価

さて、DHの評価には、もう一つ難しい問題があります。それは、論文や研究発表ではなく 研究者(の卵)が時間をかけて作成したデジタル成果物自体も評価の対象とすべきではないか、 という議論です。これには私は半分賛成、半分反対です。というのは、デジタル成果物を 評価の対象にしてしまおうとするなら、それはつまり、ある分野の資料や研究手法の 特徴と課題を知悉し、さらに、それらに適用すべきデジタル技術についても十分な知識を 有していなければ評価できないからです。そこで、海外先進国では、Text Encoding Initiative ガイドラインを作成して、これに沿って作っているかどうか、ということを軸とした 評価を可能にしているわけです。たとえば、デジタル校異本を作成した、と持ってこられた 時に、「校異情報をどういう風に扱っているか」を確認しようとしたなら、 まったく標準規格がない状態であれば、データの構造からそれを解釈・処理する アプリケーションまで、すべて評価者が一から確認しなければなりません。しかし、 欧米先進国ではTEIガイドラインがあるので、まず、それに準拠しているかどうかを 確認し、準拠していれば、あとは、すでに定められた記法をどのように適用しているか、 を確認すれば済みます。もちろん、TEIガイドラインに準拠せずに成果物を作成する こともあるでしょうが、その場合は、そのようにして簡便に評価してもらえる道筋が あることを前提として敢えて茨の道を歩くことになるわけですから…ということになりますね。 欧米先進国では、とりあえずTEIガイドラインはDHの基礎の一つとしてDHのカリキュラムに組み込まれている ので、DHの教育を一通り受けた人は皆知っているという、大変裾野の広い状態になっていますので、 そういうことも可能になっています。

 技術標準は、TEIガイドラインだけでなく、他にも資料の性質や状況に応じて色々なものが あります。それらを適切に採用・適用できているかどうか、結果として自分の分野なり その資料に関心をもつであろう誰かに十分に益をもたらせるようなものになっているかどうか、 ということを適宜判断していくことになるとしたら、やはりかなり専門知識を持った人に 委ねざるを得ません。また、もちろん、ソースコードやデータは評価者がすべて きちんとチェックできるようになっていなければなりません。(そして評価者は そういうものも一通りチェックしなければなりません!)そういうことを考えますと、 「論文」や「研究発表」というスタイルは、準備する方は大変な手間になってしまいますが、 評価する人に対して、どういう点が評価に値するのか、ということをきちんと説明する 機会になりますので、評価する側の負担はデジタル成果物に比べたらかなり少なくなり、 評価の質も高まるように思われます。

「論文」や「研究発表」を行うためには、単に「この技術を採用した」というだけでなく、 なぜその技術を採用したのか、他の類似技術を採用しなかった理由は何か、 あるいは、その技術の適用においてどういう課題が生じてどう解決したのか、 他に解決の選択肢はなかったのか、といったこともきちんと(調べて)書かねばなりません。 これはなかなかの手間ですが、評価する側の負担や、より適切に評価できる体制を 作っていくという観点からは、頑張ってデジタル成果物を作成した後に、もうひと頑張りして 「論文」や「研究発表」を作成するのがよいのではないだろうか、と、現時点では 思っているところです。

(以下、追記部分です)

なお、この課題については、人文系だけの問題ではなく、理工系も含む多くの研究分野で 同様の問題が発生しています。「研究のためのデータを誰が作って誰がメンテするのか」という問題です。

「デジタル成果物はデータだけではない…」と思われる人もいらっしゃると思いますが、 とりあえず、現在は、研究データとそれを処理して分析したり表示したりするシステムは 明確に区別できるようにしておいて、研究データはそれぞれの分野の国際標準規格に 準拠して作成し、それだけを単体で流通させるというのが国際的に広く行われるようになっています。 処理系のプログラムはどんどん進歩して数年で使えなくなってしまいますが、研究成果も そのペースで使えなくなってしまうと大きな問題ですので、そうならないように、 活用可能性が高く、作成者の意図を明確に提示できるようなフォーマットを 各分野で決めて、それに準拠したデータを作って公開するということになっています。 このやり方だと、研究データが長期間使えるというだけでなく、フォーマットが 決まっているので、データを処理するプログラム・システムを作る際にそのフォーマットを 念頭に置いて作れば、世界中の同分野のデータにそのまま適用できることになるため、 プログラム・システムを作った場合の波及効果が大きく、結果として、そういった ことを行うための予算も付きやすくなり、予算規模も大きくできる、といったこともあります。 予算規模が大きくなれば、その予算で人を雇用できることにもなりますので、 ボランタリーな片手間仕事という感じではなく、その仕事のために誰かが 雇用されるという状況を作ることも可能になります。

そこで、「研究データの構築運用」という横串を提供してくれるコミュニティが最近は 国際的に活発になってきています。国際的には Research Data Alliance (RDA) というコミュニティが横断的かつ活発に活動しており、しばらく前に日本でも大会を 開催したことがあります。日本でもこれに対応するようなコミュニティ活動として 研究データ利活用協議会というのがあります。 こういったところでノウハウを共有できるようにする一方で、研究データを供託し、 DOIをつけてくれるリポジトリやジャーナルなどもでてきています。

人文系だと、リポジトリとしては、Zenodoがよく使われるようであり、 最近、八代集のデータなども登録されたようです。 また、後者の例としては、最近は Journal of Open Humanities Data というのが出てきています。

こういったもののいいところは、データを作ったこと自体、あるいはデータの内容が 評価されるところまではいきませんが、DOIが与えられ、論文と同様に参照できる ため、データを使った際に、論文を引用するかのようにデータを引用し、 それが使われたということがサイテーションインデックスのコンテクストで 評価されるようになる、という点です。

「データを使ったら謝辞に書けば良い」という話を聞くこともありますが、 それでは結局、サイテーションインデックスのコンテクストにのらないので、 論文の謝辞まで読まなければデータが使われたかどうかの確認ができません。 しかも、謝辞ではフォーマットも様々なですので、自動読み取りもなかなか 難しいです。きちんと引用の形式で書くことが、評価につなげるためには重要です。

さて、もう一つ戻ってみると、「評価してもらいたいデジタル成果物」には、 データだけでなく、それを処理したり表示したりするためのシステムも含まれることが あり、そうすると、それらの見た目や使い勝手という側面もあります。上述のように、 一定のフォーマットに沿って作られた研究データを対象にしたものであれば、 汎用化がある程度可能ですので、規模感という意味では、分野全体、さらには フォーマットを共有する複数分野にわたって評価してもらうことも考えられます。 見た目や使い勝手は、 プログラムを作ったりCSSを書いたりと、これはこれで大変工夫の余地があります。 そのあたりも、Data visualizationなどの文脈で他の分野と同様に考えることは ある程度は可能ですが、ある部分からは、各専門分野固有の評価軸が可能でしょう。 データの構造などがわからない場合には、むしろそういった点に着目して 評価することになるかもしれません。そのあたりは、分野としてどうするか、 あるいは、フォーマットを共有する分野同士でどう考えるか、 色々検討してみる必要があるのかもしれません。

人文学向け電子テキストガイドラインTEI/XMLに準拠したファイルをPHPで処理するにあたって

人文学向け構造化ルールであるTEI/XMLガイドラインに準拠して作成したファイルは、とにかく色んな方法で処理して その都度必要な状態にして利用できるのが魅力です。それについて書き始めると長くなるので詳しくは 以下のページなどをご覧ください。

bungaku-report.com

なお、この記事は、PHPプログラミングをかなりやりこんでいる人向けで、TEI/XMLガイドラインに準拠した ファイルを処理するのに必須の知識ではありませんので、PHPをやってない人はここでお帰りいただく(?)のが 正しい時間の使い方だと思います。

ここでは、最近久しぶりにPHPで処理することになり、いくつかうろ覚えだったことに再びつまづいたので 忘れても大丈夫なようにここにメモしておくことにしました。(同様の理由でこのブログには DHに関連する開発についてのTipsが大量にため込まれていますので困った時にはこのブログで 検索してみていただくと解決策が見つかるときもあるかもしれません)。

さて、今回は、PHPでxpathがうまく通らない、という問題につきあたりました。基本的に、PHPで XMLファイルを処理するときは、simpleXMLかDOMDocument を使うのですが、どちらでも うまくいかず、うーん、となっておりました。

なお、最近は、 Zend_Dom_Queryというのがあるそうで、 これを使えばCSSセレクタでも処理できてしまうらしいので、PythonのBeautifulsoup並みに簡単に処理できるかもしれません。

それから、ここでなぜPHPを使っているのかというと、一部でPostgreSQLを使ってしまっていたりして全体としてまだPHP脳に 頼らざるを得ない状況になっているためです。PHPに深入りしていない人はPythonのBeautifulsoupとか Javascriptとか使っていただくのが幸せへの道だと思います。

それはともかく、しばらくあれこれ試行錯誤していて思い出したのは、名前空間の設定です。 xmlnsがついているXMLファイルは明示的に名前空間を設定しなければならなかったのでした。 たとえば以下のような感じです。

$xml = simplexml_load_file("zz2_new.xml");
$xml->registerXPathNamespace('tei', 'http://www.tei-c.org/ns/1.0');
$xml->registerXPathNamespace('xml', 'http://www.w3.org/XML/1998/namespace');

こうしておくと、たとえばこの後、以下のような感じで指定したIDを持つエレメントを取りだして処理することができます。

$pid = "TP11";
$eperson = $xml->xpath("//tei:person[@xml:id='$pid']");

なお、上記の$epersonを再度xpathで処理したい場合は、改めてregisterXPathNamespace() する必要があるようです。

大した話ではないのですが、忘れてハマると大変で、しかし、知っていれば一瞬で通り抜けられることなので、 一応メモしておきます。(メモしたことを忘れないようにしないといけませんね。)

Webで地図上にマーカーを載せたりグルーピングしたりする方法

地図上にマーカーを載せたり、マーカーをグルーピングしたりする機能、最近はかなり流行ってますね。 Wikipediaの充実等により地図上の座標情報を簡単にとれるようになってきてデータ作りが簡単になってきたというのと、 自由に使える地図がかなり使いやすくなってきたということで、あちこちでそういうものが提供されるように なってきています。

もちろん、Google mapで多くのことはできますし、少し凝ったことでもたとえばOmeka + Neatlineを使うことで、 マウスでポチポチするだけで地図上に色々なものを プロットできるようになっているなど、プログラミングなどはまったくしなくてもできるようになっている というのが基本的には重要な点だと思いますが、一方で、簡素なプログラミングによってこの種のことが できるようになってきているという手も割と重要です。

いずれにしても、プログラミングができた方が人生色々応用がきいて楽しいという時代になってきましたし、 プログラミングのスキルを高めたり確かめたりする上で、地図上に何かをプロットできるようなものを 作れるとちょっと面白そうです。

ということで、とりあえずやってみようと思うのですが、まず、目指すところをおさえておきましょう。

今回は、

・Webページに拡大縮小可能な地図を組み込んで、そこにJSON形式のデータを食わせて、グルーピング可能なマーカーをプロットする

です。具体的には、こういうもの↓を作ろうという話です。

f:id:digitalnagasaki:20210614004041p:plain
地図上で

いきなり目標が高いと思われる人もいるかもしれませんが、最近は例によって色々楽にできるものが 作成公開されており、これ自体はそんなに難しくはありません。というわけで、必要な技術や道具立てについて みてみましょう。

必要なもの:

Javascript + jQueryによるプログラミング 動的な地図を読み込むjavascriptのソフトウェア Leaflet マーカーをまとめてくれるLeafletのプラグイン JSONで作った位置情報データ

という感じです。

さて、ここで解説を始めようか…と思いましたが、実は以下のサイト

地図ライブラリ「Leaflet」にcluster機能を追加する - Qiita

に書いてあることに私から付け加えるようなことはあまりなくて、 とりあえずそちらの作例をコピペしてみれば、大体、なるほど、という感じになると思います。

ここからさらにカスタマイズということで、たとえば自分が作った位置情報データを読み込ませたければ、上記のサイトの中で

    for (var i = 0; i < 30; i++) {
        var marker = L.marker([51.5 + (Math.random() / 10), -0.09 + (Math.random() / 10)]);
        marker.bindPopup("<b>Hello</b>");
        markers.addLayer(marker);
    }

という箇所をちょっといじればよいということになります。

たとえば、以下のようなJSONデータを locations.json というファイル名で作ったとしたら、

[
    {
        "person": "卍山道白/ 復古道人/ 隨時子",
        "type": "Residence",
        "when": "",
        "plname": "永平寺",
        "lat": "36.053056",
        "long": "136.355556"
    },
    {
        "person": "卍山道白/ 復古道人/ 隨時子",
        "type": "Residence",
        "when": "",
        "plname": "大乘寺",
        "lat": "36.532556",
        "long": "136.658944"
    },
    {
        "person": "卍山道白/ 復古道人/ 隨時子",
        "type": "Found (Sect)",
        "when": "",
        "plname": "源光庵",
        "lat": "35.054814",
        "long": "135.731722"
    }
]

jQueryでやろうとした場合、htmlファイルと同じディレクトリ(フォルダ)に置いて以下のように書いておけば読み込めるはずです。

  $.ajax({ url: 'location.json',dataType:"json"}).done(function(data){
     var markers = L.markerClusterGroup();
     data.forEach(function(e){
       var plname = e.plname;
       var personat = e.person+'@'+plname
       var lat = e.lat;
       var long = e.long;
       if(lat != ""){
         var marker =  L.marker([lat,long],{title: plname}).bindPopup(personat);
         markers.addLayer(marker);
       }
     });
     mymap.addLayer(markers);
  });

やり方を調べるのが少し億劫かもしれませんが、わかってしまうと結構簡単です。よかったらぜひお試ししてみてください。