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

1日目の福岡

初九州!という感じで福岡へきました。リードテック合宿 in 福岡です。
前々回のリードテック合宿 in 沖縄は台風の影響で一人だけ参加できなかったため、今回は初めての遠征合宿です。


ヒッチハイクの途中で - Katachi

茨城空港スカイマークにのって福岡空港へ。
福岡空港についたのが11時40分。定刻より10分早い到着。
その後、id:otani0083 が迎えにきてくれてそのままパンストックへ。
おいしいパンを4つ食べました。
二人の職場を見学させてもらいながら、 id:kitone とも合流。
夜は水炊き長野というお店でぐつぐつと水炊きを食べました。
その後は二日間お世話になる id:kitone 宅へ。
荷物を置いてから乱立する長浜屋に目を回しながら長浜ラーメンを。
今はmanu coffeeで3人でラップトップを3台開いている始末です。

井戸を掘る

あけましておめでとうございます。今年もよろしくお願いいたします。
2014年の振り返りも兼ねて2015年の初エントリ。

個人的にインパクトがあったのはcovo.jsを取り上げていただいたこと、担当号の刊行、CA原稿などでした。

C4LJで書きたかったことはデータを公開しつつレガシーデータはなんとかしようよ(公開する方も、使う方も)、ということでした。それがcovo.jsの最初の動機でした。なのでLinked Open Dataという側面で取り上げていただけて「おお」と思いました。

担当号は執筆してくださった方、サポートしてくださった編集委員のみなさまに本当に感謝。

CA原稿などは編集担当の方にさまざま迷惑をおかけしつつ、無事に公開までたどり着けた、という感じでした。ささくれさんから話をいただいたときから「ふうむ」とぼんやり原稿をイメージし始め、ほんとに依頼がきてから資料集め、「いやいや、レビューというものはむつかしいな」と終始思いながら書いていました。


CA1836に寄せて - ささくれ

の最後にも書かれているように、
「というわけで、IDマネージャーよりもウェブサービス屋としてのCrossRefにフォーカスした記事になっております。」
という感じに仕上がっているようです。

買ってよかった2014ベストはルンバですかね。

リードテック的には前述のcovo.jsと笠間合宿が2014年の思い出でしょうか。 id:kitoneid:otani0083 と茨城まできてくれて合宿をしました。成果はそのうち出る予定です(きっと)。

  • リードテック2014年早見表 (MLの件名「○月の○○」シリーズより)
    • 1月・2月のあといっしゅう
      • 気がつけばあと1週間で2月が終わる、という状況でした
    • 3月・4月・5月のとそう
      • とあるメンバーが必死に何かの塗装をしていた
    • 6月のしゅうしゅう
    • 7月のどうしよう
      • CiNiiからデータ収集時の相談
    • 8月のあまとう
      • あんみつを食べにいった
    • 9月のほうこう
      • お世話になった方々にお手伝いする方向で行きましょう、と
    • 10月、11月、12月のれびゅう

リードテックはちょっとぼり気味でした。
リードテックラボは「どこでもリゾルバ」を少し改良と「Colorful Cinage」の公開くらいしか動いていません。あまり活動できなかったので2015年は少しずつ、と思っています。

Linked Open Dataの事例集

データがもっとちゃんとオープンになって使いやすくなってしかもデータ同士が明示的につながってるとかなり便利だよね*1、というのがLinked Open Dataですが、NDLの解説サイトができました。NDLが提供しているNDL Web Authoritiesを活用しているからか、事例としてcovo.jsも載せてもらいました。感謝。

使う・つなげる:国立国会図書館のLODでつながる | 国立国会図書館-National Diet Library

特にLODを活用したこんなアプリがあったらの解説部分はLODの解説も含めて非常に丁寧でわかりやすいのでおすすめです。NDLのデータをもっと使ってみたい、と思いました。

*1:厳密?にはいろいろあるようですが、その目標としているところをざっと噛み砕いて表現すると。

Handle systemとDOI

はじめに

調べている途中で完全にはウラはとれてないし保証できないのだけど少し分かったことのメモです。主にHandle systemとDOIのカンケーです。DOIはHandle systemで動いている、についてシステム的にどこまでどんなカンケーなの、という視点です。DOI Handbookを通読するのはしんどいので、挙動から分かる部分(とDOI Handbookからちょっとの引用)を中心に。

doi.orgでもhdl.handle.netでも

たとえば、アジ研さんの機関リポジトリであるARRIDEでは各アイテムにHandleを付与しています。
http://hdl.handle.net/2344/1372

Handle側でアジ研さんのサーバであるARRIDEサーバにリダイレクトしてくれてめでたしめでたしなのですが。

http://doi.org/2344/1372

実はdoi.orgを指定した場合でもちゃんとARRIDEにリダイレクトしてくれてます*1。これ、びっくりですよね。何が起こっているのでしょうか。

少し調べてみた

まずdoi.orgとhdl.handle.netのアドレスを調べてみました。hostコマンドで。

host hdl.handle.net
hdl.handle.net has address 38.100.138.165
hdl.handle.net has address 134.76.10.174
hdl.handle.net has address 38.100.138.166

host doi.org
doi.org has address 162.13.3.127
doi.org has address 63.123.152.248
doi.org has address 38.100.138.163
doi.org has address 38.100.138.162
doi.org has address 54.191.229.235
doi.org has address 208.254.38.90

Handle用のproxyサーバが3つでDOI用のproxyサーバが6つ。DOIの方が多いんですねえ。まあそうでしょうけど。この情報を元に、次に実際にいくつかのケースでどんな遷移をしているのか見てみます。

Handleのみのアイテムの遷移

再度、アジ研さんのARRIDEのアイテムに登場していただいて。CNRIを通じたHandleのみ持っている、という例です。
http://hdl.handle.net/2344/1372
Chromeの「デベロッパツール」で見てみると、134.76.10.174 から 303リダイレクトで、ARRIDEへ遷移していることが分かります。134.76.10.174はhdl.handle.netのproxyサーバなので、当然の挙動ですね。

続いて問題の、
http://doi.org/2344/1372
を見てみると、63.123.152.248から303リダイレクトで、ARRIDEへ飛んでいることが分かります。63.123.152.248はHandle側のproxyサーバではなくdoi.orgのproxyサーバです。つまり、Handle用のprefixとsuffixがDOI用のproxyサーバを通じて解決されている*2、ということまでは何となく言えそうな雰囲気です。

DOIのみのアイテムの遷移

ARCHAEOLOGY DATA SERVICEというところのアイテムに登場してもらいます。DOIのRA*3の一つであるDataCite由来のDOIが付与されているアイテムです。
http://doi.org/10.5284/1000164
63.123.152.248というDOI側のproxyサーバから303リダイレクトでARCHAEOLOGY DATA SERVICEへ遷移しています。これは予想通りの当然の挙動ですね。

ARRIDEとは逆パターンですが、下記のパターンもちゃんと解決されます。ふむふむ。
http://hdl.handle.net/10.5284/1000164
で、どんな経路で解決されているかというと、134.76.10.174というHandle側のproxyサーバを通じて解決されています。さきほどとは逆パターンで、DOI用のprefixとsuffixがHandle用のproxyサーバを通じて解決される、ということはなんとなく言えそうな雰囲気です。

分かったと言えそうこと

DOIのprefixとsuffixであってもHandle用proxyサーバを通じて解決されて無事にリダイレクトされる。同様に、HandleのprefixとsuffixであってもDOI用のproxyサーバを通じて解決されて無事にリダイレクトされる。つまり、proxyサーバとしてのdoi.orgとhdl.handle.netはほぼ同機能だから、DOIとHandleなら「http://doi.org」「http://hdl.handle.net」のどちらを使っても(機能的には)良さそう、ということです。

下記のあたりがたぶん参考になります。

DOI Handbook - Resolution
「the proxy servers (at http://doi.org, and also the one at http://hdl.handle.net)

DOI System and the Handle System
「Technical infrastructure」の
「The Handle System consists of Global root servers, local handle servers, clients, and proxy servers.」

辺りを読んで、proxyサーバの後ろにあるシステム(Global root serversからデータをコピーされてるlocal handle servers)はHandle側もDOI側もほぼまったく同じシステムとデータ(local handle servers)で動いているのではないかと勝手に推測*4*5

20140914追記

DRFで以前こんなポスター発表があったようですね。
http://drf.lib.hokudai.ac.jp/drf/index.php?plugin=attach&refer=tech%2F%E9%96%A2%E9%80%A3%E6%8A%80%E8%A1%93%E6%83%85%E5%A0%B1&openfile=DRF9_DOI_Handle_poster.pdf
ただ、アドレスバーにdoi.orgとhdl.handle.netどちらでもリンク解決される、という部分のみで実際のところHandleとDOIのシステム部分の切り分けは依然わからないままです。また何かあれば追記します。

おわりに

以上のことから、識別子としての機能的にはHandleとDOIはほとんど同一の機能を持っているとみなしていいかもしれません。リゾルバサーバとしてのproxyサーバ名まで共有しているようですから。ただ、HandleもってればDOIいらないよね、という結論にはいたらないと思います。DOIを付与する過程でCrossRefやらJaLCさんやらのRAで付与してもらうわけですが、HandleだけではそういったRAの提供するサービスを受けられないからです。



というわけで2015年 Li:d tech 夏の自由研究はこれでおしまいです。

*1:dx.doi.orgでも問題ないですが、doi.orgの方がpreferだとDOI handbookに書いてあります

*2:その背後で何が起きているのかは分かりませんが

*3:Registration Agency

*4:間違っている可能性大です

*5:追記:この辺の記述はDOIとHandleシステムの関係ではなく、通常のHandleの仕組みを示していただけのようなのでとりあえず消しておきます。

Colorful CiNage

はじめに

とりあえずですが「Colorful CiNage (カラフル サイネージ)」を公開しました。

Colorful CiNage
http://haseharu.org/labs/cinage/

CiNiiとSignageを合わせて「CiNage」です。Colorfulをつけたのは、ゴロがいいのと、色んな図書館あるよ、って意味とインターフェースを少しカラフルにしたかったから。

流れとしては、

全国でX館が所蔵している図書を自館は何冊持っているか?―CiNii Booksでウィルキン・グラフを描く
http://cheb.hatenablog.com/entry/2013/08/24/173533

とか、

Code4Lib JAPAN Conference 2013に参加してきました。
http://otani0083.hatenablog.com/entry/2013/09/01/172422

の流れです。元は別の理由で手を動かして分析していたのですが、イベントで id:otani0083 がなんか発表してくる、というので、なんか見えるもの作っておこうか、といってとりあえず作っておいたのがRed Data Booksで「coming soon」のまま1年経過してしまいました。

Red Data Books
http://haseharu.hatenablog.com/entry/2013/08/28/202429

というわけで「Red Data Books」の続きです。CiNii APIを利用してごにょごにょして所蔵館数とか分析用データを取得して各図書館を可視化しよう、というものです。取得したデータはRed Data Booksのときとあまり変わりません。

何が分かるか

まだ機能があんまりないので分かることが少ないので続々追加できたらと思ってます、が続々追加されるかどうかは気分次第なので正直わかりません。

大学図書館の所蔵タイトル件数

単純ですが、CiNii Booksに登録されている分を所蔵タイトル件数と見なした場合の所蔵タイトル件数(述べNCID件数)が分かります。

全国で○館が所蔵している図書を○図書館では何冊持っているかのグラフを表示

たとえば、全国で2館しか所蔵していない図書(=NCID)を自分の図書館では何冊(=NCIDの件数)持っているかのグラフを表示。ささくれ、で紹介されているウィルキングラフ、というグラフです。たぶん、大抵ぐーっと横長のグラフになるので、ブラウザの横バーをうごかしてみてください。

“ウィルキン・グラフ”―他のX館が所蔵している資料をうちは何冊所蔵しているか?
http://current.ndl.go.jp/node/22526

○○図書館における出版年ごとの冊数のグラフを表示

出版年ごと(1年スパン)に何冊の図書(=NCID)を持っているかをグラフに表示。

使っているもの

CiNii API

CiNiiが提供するAPI

インターフェース

List.js

検索機能はこれで
http://listjs.com/

Chart.js

グラフはこれで
http://www.chartjs.org/

今後の予定

前回から、1年あいてしまったので正直なんともいえないのですが、機能追加していけたらと考えています。館としての可視化もあれば、一冊の図書を各館のフィルターを通して可視化してみる、というのも。もしリクエスト等あればお寄せいただけると嬉しいです。しかし、List.js使ったの2度目ですが使いやすいですね、これ。

List.js

去年、仕事で少し使ってたList.jsを別件で使っています。
http://listjs.com/

これ、かなり使えます。サーチ、ソート、フィルター、組み合わせも。とにかくシンプル。
今回、1200件のリストを読み込ませると「表示されない」、のでちょっとソースをいじる必要あり。そのメモ。

start: function()の、
 self.page = 200;

を好きな数字に変えてやればその数字が表示限度になります。

CiNii Booksの所蔵館情報からメールアドレスリストをつくってみる

はじめに

某MLでこんな感じの話題が少し前にあったのでCiNiiの所蔵館情報から正規表現を使ってメールアドレスを抜き出すスクリプトシェルスクリプトで書いてみました。

用意するもの

  • NIIの提供する所蔵館情報、FANOのリスト

https://illoffset.nii.ac.jp/icos/MainFrame.do

仕組み

FANOをつかってCiNiiにアクセスし所蔵館情報のページからメールアドレスを抜き出します。CiNiiでは幸いなことにRDFで提供しているのでそちらでもいいのですが、今回はなんとなくスクレイピングでやりました。

FANOが「FA007739」の場合、ベースURLは「http://ci.nii.ac.jp/library/」になりますので、

http://ci.nii.ac.jp/library/FA007739

が所蔵館情報のページになります。.rdfをつければ、RDFで取得できます*1。FANOのリストは千件以上あるので、何度かアクセスしたあと少し時間をおくように設定しています。

cat sosiki.txt | awk -F'\t' 'BEGIN{OFS=","} {print $1,$2}' > data.list
	EMAIL=""
	COUNTER=0

	while read file
	do
		FANO=$(echo ${file} | awk -F',' '{print $1}')
		KIKAN_NAME=$(echo ${file} | awk -F',' '{print $2}')
		echo ${KIKAN_NAME} , ${FANO}
		CINII_DATA=$(curl -s "http://ci.nii.ac.jp/library/${FANO}" | grep -e 'writeAtMark()' -e '@')

		SOURCE_DATA=$(echo ${CINII_DATA} | grep -e 'writeAtMark()' -e '@' -e '[at]' | sed -e 's/<script>writeAtMark()<\/script><noscript>&#64;<\/noscript>/\@/g'| uniq)
		EMAIL=$(echo ${CINII_DATA} | grep -e 'writeAtMark()' -e '@' | sed -e 's/<script>writeAtMark()<\/script><noscript>&#64;<\/noscript>/\@/g'| perl -ne '/([-0-9a-zA-Z._+]*@[-0-9a-zA-Z._+]*)/ and print "$1\n"' | uniq | tr -d '\r\n')
		
		#抽出データを出力する
		echo ${FANO},${KIKAN_NAME},${EMAIL} >> email.data
		echo ${FANO},${KIKAN_NAME},${SOURCE_DATA} >> source.data

		if [ ${COUNTER} -eq 30 ]; then
			COUNTER=0
			echo 'sleep'
			sleep 5
		fi
		
		COUNTER=`expr $COUNTER + 1`
	done < data.list

結果と感想

1222館*2から353件のメールアドレスが取得できました。Twitterアカウントのようなものも混ざっているので、全部ではないようですが。もう少し取得できるかなあ、と思っていたのですが。とり逃していることもあるかもしれません。メールアドレスの正規表現の部分は少しはまってしまったので結局Perlで書いてます。

*1:今回はやっていません

*2:FANOリストの行数