読者です 読者をやめる 読者になる 読者になる

国文学研究資料館の古典籍等のデータベース群(の一部?)にパーマリンク的なものがついた模様

いつアナウンスされたのかよくわからないのですが、国文学研究資料館の古典籍のデータベースに「書誌URL」というものがつきました。これはいわゆるパーマリンクに近いものなのではないかと想像しています。たとえば、下記の引用画像の赤線部をご覧ください。

f:id:digitalnagasaki:20170322162158p:plain

 

これまで、公式には、こういったURLが書誌情報に関しては発行されておらず、普通のユーザからは、この書誌のページをリンクすることができませんでした。が、現在、それが、この「書誌URL」からできるようになっているようです。たとえば下記のブログなど、さっそく、専門の方々からも喜びの声があがっているようです。

d.hatena.ne.jp

これで、万単位の古典籍資料が「この資料を」と言って提示する時にURLで直接提示して公式サイトにリンクできるようになりますので、地味ですが、本当に大きな進歩です。

 

特に国文学研究資料館の古典籍のデータベースに関してのこれまでの問題点は、細かいところでもいくつかあるのですが、大きなものとして、(1)書誌情報に外からリンクを張れないために、URLで典拠情報を提示できなかったことと、(2)画像のページには外からリンクを張れるが、そこから書誌情報のページに戻れないために、画像を見ても何の画像だかすぐにはよくわからない(=画像自体を自分で見て判断するか、書誌情報を別途検索して探さなければならない)、という2点がありました。このうち、(1)が解消されたということになります。

 

このことを知ったときにすぐに思い浮かんだのは、先月に急逝された古瀬蔵先生のことです。古瀬先生は国文学研究資料館の情報部門の責任者としてこの十数年ほどお仕事をしておられ、2011年のもののようですが、お人柄をよくあらわした(ように個人的には思っています)ざっくばらんなご対談が、国文学研究資料館のある立川市タウン誌のサイトに掲載されています。研究領域が近かった古瀬先生とは色々な研究会を通じてお話しをすることがあり、この数年は国文学研究資料館の電子情報化委員というアドバイザー的な仕事をしていたこともあったので、上記の2点をやってください、と、ずっとお願いしていて、今年度に更新したシステムでは(1)はできるようにする、でも(2)は今回は無理だった、ということをうかがっていて、今か今かと待っていたのでした。結果として、1年近くかかってしまいましたが、ようやく(1)が達成されました。

 古瀬先生が時折私にお話ししてくださっていたことの一つに、自分がいなくなってもシステムが動くようにしないといけない、ということがありました。確かに私は先進的なシステムを提供しようとするあまりに自分がいなくなったら動かなくなるのではないかという懸念とは背中合わせの状況にあります。自分がいなくなっても稼働し続けられるように、続く人が継続できるようにと、いろいろな工夫をしてきていて、IIIFやTEI、Unicode等に入れ込んでいるのはそれを解消するための土台を皆で共有できるようにするということもあるのですが、まだ完全とは言えません。一方、古瀬先生が責任者として動かしておられた仕事は、事業として確実に動かせる形を目指して整備され、古瀬先生が亡くなった後にも着々と進められ、ついに公開にまで至り、とても地味ですが、しかし、国文学のみならず、日本文化研究全般を大きく前進させる1歩を刻むことになりました。それだけでなく、色々なデータベースがシステムの全面更改を経て今もなお普通に使えていることもまた、古瀬先生のご尽力に負うところが大きく、そこには学ぶべき事が多々あると思っています。国文学研究のデジタル化という極めて難しい仕事に取り組んでこられ、時折その大変さをおうかがいすることはありましたが、情報工学者と人文学者というギャップにはじまり、事業として研究を支援すること、日進月歩のデジタル技術を事業として扱わなければならないことなど、おそらくはおうかがいする以上に大変なことは様々にあったのだろうと思います。道半ばになってしまったことは古瀬先生としても残念なことだろうと思いますが、その着実なお仕事は、今後も、おそらくはほとんどそれと意識しない形で、我々に色々な恩恵を与え続けてくれることでしょう。

 

古瀬先生、ありがとうございました。

国立公文書館で紹介された「最新のIT技術を活用したデジタルアーカイブ・システムの調査検討報告書」について気がついたこと

ところで、先日、国立公文書館から、

というものが公開されたようで、「調査・報告書等」のページから閲覧できるようになっています。前の記事にてご紹介したブログを公開しているインフォコム株式会社さんの名前が最初のページに書いてあるので、インフォコムさんが作成されたのでしょうか?この調査報告の発注した文書などを確認すればわかるのだと思いますが、それは、どなたか、識者の方にご教示いただけますとたいへんありがたく存じます。

 

内容的には頑張って色々まとめておられて、「最新のIT技術(情報技術技術?)を活用した」というにはそんなに最新な感じはしませんが、現状を把握するにはよい文書なのではないかと思います。細部には色々気になる点もありますが、そういうところには突っ込みを入れつつ、これを使って読書会などをしてみるのもよいのではないかと思います。

 

ただ、拝読していて、ここは誤解を招きかねないのでちょっと書き換えていただいた方がよいのではないか、というところがあったので、念のため、ちょっと以下にメモしておきます。特に気になったのは、70ページの以下の記述です。

 

IIIF に対応したビューアである OpenSeadragonは、JavaScript で実装されたオープンソースの画像ビ ューアである。様々な解像度の画像を、解像度ごとにタイル画像に分割しておくことで、スムーズな拡大・ 縮小と移動を行える操作性が特徴である。ただし、この機能を構築するには、タイル画像を事前に用意 する必要があり、元の画像データの数倍から数十倍のディスク容量が必要となる。

 

先にまとめておくと以下の2点です。

(1)IIIF対応ビューアとしてOpenSeadragonを挙げるのは不適切

(2)「元の画像データの数倍から数十倍のディスク容量」を必要としないどころかJpeg画像そのままでもIIIF対応は十分可能。

 

まず、(1)ですが、

OpenSeadragonは、IIIF Image APIにしか対応していないので、「対応したビューアである」という例として挙げるのはよくないと思います。IIIFに対応したビューアを挙げるなら、Mirador, Universal Viewerなど、IIIF Presentation APIにも対応しているビューアを挙げないと、ミスリードになると思います。もし、OpenSeadragonを紹介したければ、別項を立てればよいと思います。

なお、OpenSeadragon自体はとても良い画像ビューワで、私もよく使っていますが、通常のIIIFビューアに比べると利用者に直接提供する機能はかなり少なめです。APIが充実しているので、開発者がユーザ向けにいろいろな機能を追加して提供することがかなり容易にできます。そこで、IIIF対応ビューアの中でもMiradorやUniversal ViewerはこのOpenSeadragonを内部で利用しています。

 

次に、(2)ですが、

OpenSeadragonが標準的に対応している画像配信(?)形式であるDeepZoom形式では、確かに、分割タイル画像を用意しておく必要があります。しかし、OpenSeadragonが対応している画像配信形式にはIIIF Image APIもあります。(ここではこの話のはずです)。IIIF Image APIの場合は、画像をどういう風に用意するか、というのは画像配信サーバに依存する形になります。そこで、画像配信サーバがどういう画像を配信できるか、タイル画像を事前に用意しなければならないのか、という話になるのですが、このブログでも以前にご紹介した digilibというIIIF対応画像配信サーバソフトでは、画像をJpeg画像のままで配信できます。そうすると、元画像の数倍のディスク容量、どころか、まったくディスク容量を増やす必要はありません。たとえばこちらのサイトではdigilibで400万枚ほどの画像を配信していますが、特に問題なく配信できていると思います。あるいは、Loris IIIF Image ServerというIIIF対応画像配信サーバソフト(これはUbuntuへの導入の仕方を2SC1815Jさんが紹介しておられます)では、ディスクにキャッシングをするようですので、キャッシュ用ディレクトリに多少ディスク容量を多めにとる必要があると思いますが、それでも元画像の数倍~数十倍、ということはないのではないかと思います。

 

まとめますと、この報告書を信頼して読んだ人は、OpenSeadragonを使ってみて「うーん、IIIF画像を読み込ませるのにこんなに手間がかかる上に、この程度のことしかIIIFではできないのか」と思ってしまうでしょうし、「数倍から数十倍のディスクを用意しないとIIIFには対応できないのか」と思ってしまうでしょう。もちろん、IIIFの本家のサイトを読んだりこのブログを見たりして自力で情報収集できる(時間のある)人には問題ないと思うのですが、この報告書は、そういう人向けではないと思いますので、なるべく、適切な情報を提示しておく必要があると思うのです。

 

そして、これを踏まえた上で気になるのは、85ページの、「コスト IIIF への対応にはコストがかかる。 」という記述です。確かに、0円ではできません。が、IIIF Image APIへの対応は、digilibでよければ、ソフトウェアを一つ入れるだけで済みますし、Lorisでいいなら、ソフトウェアを入れることと、キャッシュ用に多少のディスク容量を用意しておくだけでもなんとかなるはずです。(ただしLorisに関する私の知識は2年前なので現在は変わっているかもしれません)。「ディスク容量を数倍から数十倍に」というのと、「サーバソフトを入れるだけでも大丈夫」というのとでは、コストがかかると言ってもまったく印象が違ってくると思います。

それから、ついでに、数日前に、「資料が増えると対応の手間がその分増えて時間もかかるのではないか」という質問をいただいたので、そういうコストを想定することもあるのかと思って念のため書いておきますと、IIIF Presentation APIのファイルは、メタデータセットがあって、画像全体のディレクトリへのアクセス権限を持っているプログラムを作ることができれば、あとはそこから自動的にJSONファイルを出力するだけです。たとえば、こちらの約400万枚/1万9000点の古典籍資料と、こちらの12冊の本とでは、Presentation APIへの対応にかかる手間はほぼ同じです。プログラム作って、それを動かして自動的にファイルを生成するだけです。ファイル生成作業も、そもそも、動的にmanifestファイルを生成するようなシステムにすれば、不要になってしまいます。

 

IIIFへの対応には、確かにコストがかかります。ただ、そのコストを大きく見積もりすぎた結果、我が国がまたしても国際的な流れから大きく遅れをとるようなことになってしまいますと、さすがに今回はちょっと取り返しのつかないことになってしまうのではないかと心配しております。

 

今のところ、IIIFに対応してくれている「デジタルアーカイブシステム」提供企業としては、私が把握している限りでは、内閣府知的戦略本部のワーキンググループでも報告した話ですが、以下のようになっています。

 

• ㈱NTTデータ
 • ヴァティカン図書館
インフォコム
 東日本大震災アーカイブFukushima/国立歴史民俗博物館(総合資料学の創成プロジェクト)/岡山県立記録資料館
• ㈱メノックス 
 慶應大学メディアセンター(福沢諭吉コレクション・グーテンベルク聖書・奈良絵本・解体新書等)(公開予定)
• ㈱寿限無
 秋田県立図書館オープンライブラリ/高知県立図書館デジタルアーカイブ(試行版)(但し、IIIFでの運用方法が未定のため、来期以降運用等を検討予定)

基本的に、IIIFは、画像をうまく共有するための基盤の提供のための枠組みであり、そこはなるべく低コストに安価に提供していただいて、画像配信に関するビジネスとしては、配信した画像の上に何をどうのせていくか、というところで勝負をしていただけるとありがたいと思っております。IIIFが広まれば広まるほど、「その上に何かをのせる仕組み/サービス/ビジネス」の有用性は高まっていきます。また、みなさまがそれぞれに蓄積しておられる技術も、そこで改めて色々再展開できるものがあろうかと思います。Webが広まったことでいろいろなビジネスが開花していることと、規模の違いはあるにせよ、相似の関係にあると思います。そのような観点から、企業のみなさまには、ぜひとも、日本のデジタル文化資料を生かし、世界に貢献していけるような基盤を作り、ご提供していっていただけたらと思っております。

(なお、企業のみなさまにおかれましては、IIIF対応サービスや対応機関などの情報がありましたら、当方までお知らせいただけますとたいへんありがたく存じます。)

 

 

 

IIIF manifestファイルの書き方を神崎正英さんが解説しておられます

また更新の時間が空いてしまいましたが、今回はIIIF maniefstファイルの書き方について、Web標準の世界で有名なあの神崎正英さんがインフォコムのブログにて解説記事を書いてくださっています。

 

特に、まだ私が取り組んでいないrange等の書き方についても解説してくださっていますので、より利便性の高いIIIF manifestファイルを作成しようと思ったら、ぜひ読んでみて挑戦してみてください。

 

画像共有の新しい標準IIIF|LOD Diary|RDF/Linked Open Data等の最新情報ブログ【Infocom デジタルアーカイブシステム】

 

一歩進んだIIIFマニフェストの利用|LOD Diary|RDF/Linked Open Data等の最新情報ブログ【Infocom デジタルアーカイブシステム】

 

ちなみに、このdigitalnagasakiのブログでは、IIIF manifestファイルの書き方についてはまだ全然解説していません。見ればわかるだろうと思って敢えて書こうとしなかったのですが、結構リクエストがありまして、そのうち書いてみようと思っています。

東京国立博物館の一部デジタルコンテンツがCC BY-NC的な感じに!

昨日知ったのですが、東京国立博物館http://webarchives.tnm.jp/ 配下で公開しているデジタルコンテンツの利用許諾条件(ライセンス)が変更され、以下のようになったそうです。


当館で公開しているデジタルコンテンツ(画像、テキスト等)のうち、 著作権の生じるものについては、特別な記載のない限り当館がその著作権を保有しています。

http://webarchives.tnm.jp/ 配下で公開しているデジタルコンテンツ( 画像検索、データベース等)に限り、非商業目的で下記の「デジタルコンテンツ無償利用条件」(以下「本条件」という)を満たすご利用については、特別な手続きを経ることなく無償で複製、加工、出版物やウェブサイトへの掲載等を行うことができます。 利用者は条件に従ってご利用ください。

「東京国立博物館 - デジタルコンテンツの利用について」

 

これは、大変ありがたく、かつ、画期的なものだと思います。いわゆるクリエイティブコモンズライセンスで言えばCC BY-NC(表示・非営利)にあたるものだろうかと思います。

 

『仏鬼軍絵巻』をIIIF対応に

というわけで、さっそく、少しやってみました。こちらのサイトの「画像検索」にて公開されている『仏鬼軍絵巻』というデジタル化資料があります。これは如來や菩薩・明王らの大軍が地獄に攻め込んで亡者を救済するという絵巻で、壮大なスケールの戦いが描かれているのですが、公開中の絵巻のデジタル画像は分割されていますので、まず、それらを一通りくっつけて、IIIF対応にしてみました。マニフェストファイルは以下のURLとなっております。

http://dzkimgs.l.u-tokyo.ac.jp/iiif/bukkigun/manifest.json

このマニフェストURIさえあれば、どこのIIIF対応ビューワでも読み込めますし、色々活用できますので、ぜひ、利用許諾条件の範囲でご活用してみてください…と書きたいところですが、これだけだとなんだかイマイチですので、ちょっと実際にIIIF対応ビューワに読み込ませてみましょう。

 

変体仮名認識システムに

まずは、@2SC1815Jさんによる、変体仮名認識システム付きのIIIF Curation Viewerに読み込ませてみます。

IIIF Curation Viewer with Hentaigana Image Recognition

画像の解像度の関係でちょっと字が小さくて難しいかもしれませんが、文字によってはそれなりに認識できているような感じですね?

 

日本古典籍データセットの『仏鬼軍』と並べて見る

さて、次にいきましょう。実はこの『仏鬼軍絵巻』は、色々なバージョンがあって、特に江戸時代に何度か木版本で刊行されたものは結構流布したようです。ネットでもいくつか公開されています。

ドイツデジタル図書館の仏鬼軍

仏鬼軍 | 日本古典籍データセット

国文研データセット簡易Web閲覧: 仏鬼軍

早稲田大学古典籍総合データベースの仏鬼軍

このうち、国文研データセット簡易Web閲覧のものは、東京大学大学院生の北﨑有帆氏により本文の翻刻がIIIFアノテーションとして付与されていますので、これを例のMiradorで並べて表示させて対比してみると、木版本の挿絵がどういうもの表現をしようとしていたか、ということがちょっと想像できて面白いですね。

f:id:digitalnagasaki:20170122220456j:plain

f:id:digitalnagasaki:20170122220257j:plain

f:id:digitalnagasaki:20170122220128j:plain

f:id:digitalnagasaki:20170122220601j:plain

f:id:digitalnagasaki:20170122220737j:plain

f:id:digitalnagasaki:20170122220832j:plain

 

いきなりずらっと並べてしまいましたが、いくつか、以下に、Miradorでのビューへのリンクをご用意しましたので、自分でもビューワ上で眺めてみたいという方は、こちらから見ていってみてください。なお、ビューワでは、各ウインドウの左上のアノテーションボタンをクリックすると翻刻が表示されますので、よかったらそれも試してみてください。

不動明王と五大尊が鬼を攻めているところ

薬師如来と十二神将

船や動物に乗る菩薩達

 

とりあえず、比較的すぐにできそうなことを手元でやってみたのですが、東京国立博物館のコンテンツは面白いものがたくさんありますので、みなさまもぜひお試ししてみていただけたらと思っております。

 

それから、ちょっとテクニカルな話題として、Miradorに関してなのですが、元になっているOpenSeadragonではいわゆるViewport Navigatorが装備されているにもかかわらず、Miradorでそれを有効化する方法を見つけることができておりません。特に巻物的な横に長いものは、Viewport Nagivatorのようなものがないと「どこを見ているのか」わからなくなってしまうことがあり、なんとかしたいところです。この場合、「これだからMiradorよりも他のビューワを使った方がよい」と思う人もおられると思いますが、「とりあえずMiradorを改造してみよう(誰かにやってもらおう)」という方向もありではないかと思います。オープンソースですし、元々、OpenSeadragonでは実装されている機能なので、そんなに苦労せずになんとかなるのではないかと想像しております。あるいは、Miradorの開発チームにそういう要望を投げてみるのもよいかもしれませんが。

 

ということで、最後はやや脱線気味でしたが、今後ともよろしくお願いいたします。

 

 

 

絵文字の肌色も扱える「異体字セレクタセレクタ」

前回のブログ記事でご紹介した、王一凡さんによる「異体字セレクタセレクタ」ですが、一部で、絵文字も扱えると話題になっているようです。絵文字と言えば、Unicode Consortiumでもemojiと呼ばれているほどに、日本発のような感じになっております。文字表は、バージョン4とバージョン5ベータが、下記のように公開されているところです。

Full Emoji Data, v4.0

Full Emoji Data, v5.0 — Beta

この文字表を見るだけでも色々なことを思ってしまって胸がいっぱいになりますが、それはともかく、ここでご紹介しておきたいのは、人間が登場する絵文字の肌の操作もこの異体字セレクタセレクタでできるようになっている、という点です。

 そもそもこれは、Unicodeに(多分Unicode6.0から?)絵文字が入り、世界中で広く使われるようになる中で、人間が登場する絵文字の肌色が問題になったため、それを文字コードレベルで指定してサポートできるようにしよう、ということでUnicodeに組込まれたルールで、Fitzpatrick scaleと呼ばれているようです。この件に関する詳しい経緯は小形克宏さんによる下記の記事などをご参照ください。

「絵文字に平等をサポートしてください」人種差別の指摘にゆれるUnicode - INTERNET Watch Watch

しかしこれも、漢字の異体字と同様に、サポートしている環境で、サポートしているフォントがなければ、どういう絵文字が書かれているか確認できませんし、入力も困難です。ここでも異体字セレクタセレクタが活躍してくれます。漢字の場合と基本的に同じですが、以下に、ちょっと見てみましょう。

とりあえず、上記の絵文字表のページから、人の顔に関わる絵文字をコピーしてきて、検索してみましょう。ここでは🎅を使ってみています。そうすると、以下のように、肌の色が異なる絵文字のバリエーションがリスト表示されます。ここで「Fitz」というボタンをクリックすると、絵文字の肌の色を変えるためのセレクタがその上の蘭に表示されますので、適宜選んでみるとそれぞれのセレクタに対応する肌の色が表示されるはずです。

 

f:id:digitalnagasaki:20170119200202j:plain

 

あるいは、「上へ」というボタンが、検索結果リストのそれぞれの冒頭にありますので、それをクリックしていただくと、上のフォームにその文字が表示されます。その際、どのセレクタを使っているかということも表示されます。

 

f:id:digitalnagasaki:20170119201124p:plain

 

このような感じで、絵文字を扱うこともできますので、人に関する絵文字を扱う時にご利用していただくとよいかと思います。

 

以上、簡単で恐縮ですが、よかったらお試ししてみてください。

 

 

 

Unicodeの異体字操作に便利なツール「異体字セレクタセレクタ」

今回は、Unicode異体字を扱う際の便利ツール、「異体字セレクタセレクタ」のご紹介です。

 

みなさま、パソコンやスマホ・携帯などで文字入力をする時、最近は特に文字がUnicodeかどうかなど、気にすることもなくなってきていることが多いのではないかと思います。漢字だけでもそろそろ8万字種を超えようとしているような状況で、日常の利用で不便を感じる人はかなり少ないだろうと想像しております。

 

 しかし一方で、Unicodeでは同じ文字だとして「包摂」扱いにされた字形の相違にこだわりを持っておられる方も依然としていらっしゃることと思います。最近は、そのような「文字としては同じだけど字形が違場合」にもきちんとテクストデータレベルで区別できるようにする仕組みが広まってきています。すでにWindowsでもMacでも使えるようです。Unicode Consortiumが提供するこの仕組みは、IVS(Ideographic Variation Sequence)、と呼ばれているようです。詳しくは下記のURLなどをご覧ください。

IVD/IVSとは | 文字情報基盤整備事業

IVSとは - フォント専門サイト fontnavi

 

要するに、「枝番形式」と呼ばれるもので、技術的には目新しいものではないようなのですが、とにかく、支配的になってきている規格やOSで採用・サポートされるということで、とりあえずそういう仕組みが手元でも使えるようになってきているようです。

 

さて、枝番形式なのですから、枝番をうまく選んだりできれば済む話なのですが、これがまだそんなに便利な感じになっていないようで、まだまだ広く便利に使えるというわけではないようです。特に、フォントが希望するIVDに対応しているかどうか、ということがまだ難しく、さらに、枝番がついているかどうか、ついている枝番はどれなのか、という情報も、アプリケーションによって使いやすかったりよくわからなかったりするようです。

 

そこで登場するちょっと便利なツールが、言語学とDHに取り組んでいる大学院生の王一凡さんが作った「異体字セレクタセレクタ」です。

このツールでできることは、筆者が理解している範囲で恐縮ですが、

1.ある漢字にIVSでどんな異体字セレクタが用意されているかをIVDを横断して確認できる

  ⇒ここから、任意の異体字セレクタを選択して異体字を入力することもできる

2.操作している文書に登場している漢字にどんな異体字セレクタが使われているかを確認/可視化できる(手元に対応フォントがなくてもある程度対応できる)

 

特に、2.の機能がなかなか秀逸だと思いますが、とりあえずは、ざっと、機能について見てみましょう。

 

筆者は「記」という漢字の異体字で時々困っています。右側が「己」ではなくて「巳」になっているにも関わらず、Unicodeでは同じ文字として扱われてしまっています。このような場合に、その二つの「字形」を区別するのにIVSが使われています。

  というこで、まずは「記」で検索してみましょう。そうすると以下のようになります。

f:id:digitalnagasaki:20170118024819j:plain

 

では、字形を表示しているところをクローズアップしてみましょう。「画像」の列では、右側が「巳」になっている「記」が二つありますね。これらの字形の画像は、かの有名なglyphwikiからとってきているようです。

f:id:digitalnagasaki:20170118024815j:plain

セレクタ」の列をみてみると、U+E0102となっているものが、「画像」の列では、右側が「巳」になっている「記」ですね。

 

f:id:digitalnagasaki:20170118024814j:plain

 

このようにして、字形とセレクタ(枝番)の対応をシンプルに確認することができます。

 

さらに、左の方の列を見てみると「コピー」というボタンがそれぞれの行に設置されていることがわかります。この「コピー」をクリックすると、クリップボードにIVS付きでコピーされます。ただし、コピーしたものを適切な字形としてペーストするには、IVSに対応しているアプリケーションであり、かつ、対応できるフォントも用意されていなければなりません。少なくとも筆者が今使っている環境ではうまく表示できないようです。

 

f:id:digitalnagasaki:20170118024812j:plain

 

さて、コピーした文字ですが、筆者のような環境だと、そもそもIVSがついているのかどうかもよくわからないという状況になってしまいます。それを解消してくれるのが、頁の左上にあるインプットフォームです。IVS付きの文字をコピーしてからペーストすると、フォームに表示されている文字の字形はそのままですが、フォームの下に「8A18+E0102」という表示がでます。この、黄緑色の「E0102」と書かれているのがIVSの枝番号です。このコピー&ペーストによる異体字セレクタ(枝番)の確認は他のアプリケーションから持ってきても使うことができます。

f:id:digitalnagasaki:20170118024145j:plain

 

IVSは、最近は、OSだけでなく色々なアプリケーション等で対応するようになってきています。しかしながら、まだまだ便利なツールは十分に出来上がっておらず、今後の課題となっています。このツールは、そういった状況を多少なりとも改善するのに有益であるように思われます。みなさまにおかれましても、Unicode異体字やその便利な使い方にご関心がおありの方は、ちょっと試してみていただけますと幸いです。

 

 

 

 

 

『絵入り源氏物語』の分析サイトが公開されたようです:人文系オープンデータの活用事例

昨年11月、「国文研データセット」として、350点のデジタル化古典籍が公開されましたが、このたびは、それに続いて350点が新たに公開され、総計700点となりました。しかも、今回の公開は人文学オープンデータ共同利用センター準備室というまったく新しい組織からで、さらに、IIIF対応の形でも公開されるという、前回に比べてあらゆる面で前進がみられ、大変頼もしくありがたいことです。それについては、詳しくはまた別にブログ記事などにさせていただきたいと思っております。

 

オープンデータで公開する、ということは、第三者に再配布を許可するということであり、それによって様々な利活用を促進するということです。視点を変えると、オープンデータ化を推進するためには、それによって利活用されたという事例が増えていくことが何よりも大切であり、特に、オープンデータ公開した組織・機関が特に労せずともどんどん利活用が広がっていくという事例があれば、なおよいはずだ、と思っています。利活用に際しての交渉というコストを下げることは、公開者側にとってもメリットが大きいはずです。

 

ということで、筆者としては、特に人文学におけるオープンデータの利活用事例を心待ちにしていたのですが、先日、ついに一つ、登場しました。国文研データセット日本古典籍データセットにおける『絵入源氏物語』のテキストデータを統計解析するWebアプリケーション、です。『源氏物語』の統計分析を専門としておられる同志社大学研究開発推進機構の助教の土山玄さんが作成されたサイトであり、先日の人文科学とコンピュータ研究会でのご発表では、まだ試作段階とのことでしたが、オープンデータとして公開されている国文研データセットのテクストデータを多少前処理した上で、国立国語研究所が公開しているWeb茶まめの「中古和文」辞書で形態素解析を行い、統計処理できるようにしたそうです。

 

さて、その結果ですが、『源氏物語』の研究者ではない筆者にはあまり適切な調べ方ができず、いかにも素人な感じで恐縮ですが、たとえば以下のような感じになります。

 

まず、上記の発表のなかで土山さんが紹介しておられた例ですが、「あはれ」の巻ごとの出現頻度は以下のようにグラフ表示されます。

f:id:digitalnagasaki:20161124175850p:plain

「やんごとなし」は第42巻匂宮に突出して多く出現するようです。

f:id:digitalnagasaki:20161124175922p:plain

 

あるいは、「きこゆ」「聞こゆ」という表記の出現頻度を比較すると以下のようになっており、ひらがな表記が全体として多いようですが、いくつかの巻で突出して多くなっているようです。

f:id:digitalnagasaki:20161124175857p:plain

 

こういった結果からすぐに何かを結論づけることはできないと思いますが、何かを調べるためのきっかけとしては有益かもしれません。

 

他にも、巻ごとの品詞の比率や、巻ごとの主成分分析の結果も表示されるようになっています。今後さらに機能が拡充されていくようですので、期待させていただきたいところです。また、他の源氏物語の写本・版本もこういう形で簡単に分析できるようになっていけば、源氏物語も今までとはまた少し違った観点からも楽しめるようになっていくのではないかと思ったところでした。

 

 また、上記の土山さんの発表論文には具体的な作業手順なども公表されていますので、そちらを読んでいただいて、こういったことに取り組んでくる方々がでてきてくださるのも面白いのではないかと思っております。