PythonのRequestsモジュールでCiNii Articlesのデータ取得
いままでPythonの標準モジュールのurllib2を使っていましたが、Requestsモジュールがとても便利だったのでメモ。
CiNii Articlesのデータ取得
import requests baseurl="http://ci.nii.ac.jp/opensearch/search?" query={"count":"200","format":"rss","journal":"図書館雑誌","api_key":********} #図書館雑誌掲載の論文をRSSの形式で200件取得 r=requests.get(baseurl,params=query) print r.text #レスポンスの内容を表示
get関数にparamsという引数で辞書を渡せば、URLエンコーディングも含めて自動的に処理してくるのがいいですね。
以前は以下のようなコードを書いていました。別に標準モジュールでももっと簡潔にかけるとは思いますが…。
import urllib2,urllib api_key=******** baseurl="http://ci.nii.ac.jp/opensearch/search?count=200&format=rss&journal=" query=urllib.quote_plus("図書館雑誌") search_url=cinii_url+urlquery+"&start="+str(start)+api_key url=urllib2.urlopen(search_url)
他にもポストでアクセスするときにはpost()というメソッドを使うといった直感的な命名、jsonで受け取ったデータを辞書やリストといったPythonのオブジェクトに変換してくれるといった便利な機能があるみたいです。
CiNiiにJSON出力機能が出たらもうちょっと追記するかも。
Code4Lib JAPAN Conference 2013に参加してきました。
台風の影響で直前までたどり着けるか不安でしたが、無事Code4Lib JAPAN Conference 2013に参加してきました。
このところ、id:kitoneやid:haseharuと一緒にあれこれやってきた成果についてLTもやりました。
Conferenceの様子は以下のURLなどをご参考に。
- C4ljp2013/program - Code4Lib JAPAN
- Code4Lib JAPANカンファレンス2013 #c4ljp - Togetter
- USTREAM: Code4Lib JAPAN 2013: Code4Lib JAPAN Conference 2013. 会議
参加者総計で60名で、大学・公共・専門図書館やベンダーとさまざまな立場の方が参加されていました。どの講演からもいろいろ刺激をうけましたが、とくにDan Chudnov（@dchud）の講演の中にあった"rough consensus and running code"が印象に残りました。他の方のお話しも含めて、技術の話だけではなくコミュニティの活動をどのように維持して活性化していくかということの工夫が随所にあっていろいろと我が身を省みる機会になりました。
プレカンファレンスでNext-L Enjuのチュートリアルからカンファレンス終了後の南三陸町図書館の見学まで参加したので満喫することができました。ブレイクアウトで遊んでたレゴとボードゲームがとても面白くて日付が変わるまで遊んでました。
- 出版社/メーカー: ホビージャパン
- 発売日: 2011/10/21
- メディア: おもちゃ＆ホビー
- 購入: 4人 クリック: 10回
- この商品を含むブログ (1件) を見る
LEGO レゴ mindstorms マインドストーム NXT2.0 8547 並行輸入品 （日本語訳付）
- 出版社/メーカー: LEGO/レゴ
- メディア: おもちゃ＆ホビー
- この商品を含むブログを見る
お久しぶりの方もずっとお会いしたいと思っていた方と何人もお目にかかることができ、はじめての東北訪問がとても楽しいものになりました。大会実行員会のみなさまおつかれさまでした&ありがとうございます!
来年は修論に追い込まれてそうなので怪しいですが、その次の年などは運営のお手伝いなどもしたいと思います。
はてなブログの評価指標 Hatena-Indexを実装しました
id:min2-flyのアイディアtitle=Hatena-Indexを実装してみました。*1どのくらい記事を書いているかと、どのくらいはてなブックマークされているかを表す指標になります。
Hatena-Indexの詳細はHatena-Index - かたつむりは電子図書館の夢をみるかをご覧くとして、Hatena-Indexは研究者の評価指標h-indexのはてな版です。記事を論文、はてなブックマークを引用に見立てており、Hatena-Indexが5であれば5以上ブックマークされた記事が5以上存在することを表します。本来は全エントリを対象に計算するのですが、今回は自分の技術的な制約から対象を30エントリに限定しています。
その他、はてなスター・Twitter・Facebook・Google+などの反応もグラフに表示します。
すこしでもブログ書くモチベーションやはてなブログへ切り替えの切っ掛けになれば幸いです。
利用にあたって
いろいろと能力不足で以下のような状態です、ひろいこころで利用ください。
やっていること
- 入力されたURLをもとに、そのブログの全エントリを取得。archiveのページからスクレイピングで全エントリを取得しています。スクレイピングはPythonのBeautifulsoupを利用しています。
- はてなのAPIからブックマーク数とスター数を取得。
- SharedCount: Social URL AnalyticsのAPIからTwitter・Facebook・Google+の情報を取得。
- 各エントリのブックマーク数からHatena-Indexを計算。
- htmlで整形。グラフはccchartというライブラリを、テーブルはTwitter BootstrapとjQuery plugin: Tablesorter 2.0を使用しました。
ソースコードは以下においています。
otani0083/hatenaindex · GitHub
Google app engineのタイムアウト設定が60秒なので、検索して60秒超過すると500エラーが生じます。もうちょっと自由度の高い環境であれば全エントリを対象にした結果を表示できそうです。さくらVPS解約したばかりですが…。
高速化・ほかのブログサービスへの対応・全件を対象とした処理・ランキング表示などは、もうちょっと自分の技術力があがったら対応したいと思います。
Google app engineの無料枠であと６つ作れるので、次はなにを作りましょうかね。
時空間情報をマッピングするOmeka+Neatline ＃しぶ旅
2013/08/09
さくらVPSのお試し期間終了にともない、構築したサイトも閉鎖しました。
メールマガジン人文情報学月報 [まぐまぐ！]のイベントレポートで使われていたり、id:haseharuが使いやすいと言っていて、気になっていたOmekaとNeatlineを使ってみました。
今回の直接的な切っ掛けはOmekaに対するつぶやきに対してid:kitoneから"やろうぜ #しぶ旅"といったコメントを貰ったことで、先週末友人9人でいったしぶ旅（福岡→長崎旅行）の写真をマッピングしてみることにしました。アイディアや写真ありがとうございます。
作成したWebサイト
Neatline
http://www32039ue.sakura.ne.jp/omeka/neatline/show/shibutabi
Omeka
http://www32039ue.sakura.ne.jp/omeka/
公式情報
Omekaの公式サイト情報の和訳がありますので下記をご覧ください。
Omekaについてのご紹介 - 変更履歴 はてな版
Omekaはオンライン展示や歴史・地理の教材を作るのにも利用できそうなCMSで、Neatlineは地理情報や時系列情報を可視化するためのOmekaプラグインです。
Neatline.org | Neatline in Actionのデモは面白いので是非。
手順
1.ローカル環境にインストール
Omekaをインストールしてみる - 変更履歴 はてな版の情報を参考にまずはhttp://www.mamp.info/en/index.htmlというソフトを使って、Mac上でOmekaを利用してみました。この段階では先のインストール手順に従えば特に問題なく動作しました。
2.さくらVPSの設定
ローカルで動かして問題なさそうだったので、さくらVPSの1GBをとりあえず契約してみました（月額1000円）。クレジット払いにしておけば2週間お試しで利用できます。Omekaを利用するだけなら、PHPとMySQLが使えればいいのでもっと安い選択肢*1がありますし、その方が設定することも少なくてお手軽です。ただ、今回はサーバー設定の勉強と余力があったら、Pythonも動かしたいということで自由度の高いさくらVPSを選択しました。
さくらVPSの設定あたりは以下の情報などを参考に行いました。
3.Omekaのインストール
1.と同様の方法で行ったのですが、ここで躓きました。
というエラーがでます。
mod_rewriteのエラーでリダイレクトがうまくいっていないみたいですが、mod_rewriteというApacheのモジュールはインストール・有効化されている、公式のドキュメントにある.htaccessファイルはアップロードされていると、ここで小一時間悩みました。結論としてはApacheのAllowOverrideが有効になっていなかったので、これを"None"から"All"に切り替えて解決しました。
項目を入力していくだけでインストール完了です。
その後、画像サムネイルを表示させるために、ImageMagicをインストール。デフォルトではjpegに対応していなかったので、http://www.ijg.org/からlibjpegをあらかじめインストールしておく必要がありました。
4.Neatlineのインストール
OmekaのプラグインフォルダにNeatlineと時系列情報を扱うNeatlineSimileというウィジェットをアップロードして完了。
あとは特に設定などしなくても項目を入力していくだけで冒頭に挙げたようなページが作れます。
サーバーの設定やインストールで躓いたのですが、半日程度で作成できました。
おわりに
OmekaのOAI-PMH Harvester - library labs
OAI-PMH関連のプラグインもあるみたいなので、もうちょっと遊んでみるつもりです。さくらVPSのお試し期間が10日ほどで切れるので、それ以降に継続するかは検討中です。折角だからようこそ - CKAN日本語とかも使ってみたいところ。
*1:例えばエクストリーム ライトプランで月額231円
論文紹介：行動は言葉より雄弁である：リサーチエクスペリエンス改善のための大規模ログ分析
Summonでどのようなアクセスログの分析が行われているのか"The Relevance Metrics Framework"という分析ツールの紹介と
それによって行われたSummonの機能向上を中心に訪問されています。
Code4Lib Journal Vol.21掲載の論文で、執筆者3名はSummonの開発チームのメンバーです。
例によって貧弱な英語力で読んでますので、誤りなどあればご指摘いただければ幸いです。
Code4Lib Conference 2013でも同様の内容で発表されていて、スライドと映像が公開されています。
映像
Actions speak louder than words: Analyzing large-scale query logs to improve the research experience | code4lib
スライド
Actions speak louder than words: Analyzing large-scale query logs t...
構成は
Actions Speak Louder than Words: Analyzing large-scale query logs to improve the research experience
1. Introduction
2. Web-scale discovery systems
3. The Relevance Metrics Framework
3.1. RMF Goals
3.2. Useful Underpinnings
3.2.1. Search Sessions
3.2.2. Clicks as a Proxy For Relevance
3.3. Dataflow in RMF
3.4. Metrics Computed in RMF
4. Gains from RMF
4.1. Data source for tools
4.2. User behavior and Insights
4.2.1 Patterns of search use
4.2.2. Optimizing default results per page
4.2.3 The nature of user searches
4.2.4 Query length and Abandonment
5. Improving RMF
5.1. Data Quality
5.2. The Implications of Simplifying Assumptions
6. Conclusions
１章
検索システム研究の伝統的な方法論、システム志向とユーザー志向のアプローチについて説明した後に、ログデータを利用したアプローチのメリットを述べています。
- 実験やユーザーテストで対象とすることができる数より、はるかに多くのユーザー対象とできる
- ログデータは実際にユーザーが行った行動なので、限定的な環境で行った実験よりも信頼できる情報である
- 調査結果をもとにシステムを変更し、その効果を計測することができる
といったことが挙げられています。*1
2章
背景としてWebスケールディスカバリサービスとしてSummonについて解説されています。SaaSのサービスであることや、セントラルインデックスを持つこと、シンプルな検索ボックスと複数のフィルター、ファセットを持つことなどがあげられています。また、この論文で述べられていることは、Summonに限らず他のサーチエンジンにも適用可能であるとも述べられています。
3章
ユーザーのリサーチエクスペリエンスを改善するための取り組みの一つとして構築したログ分析ツール"the Relevance Metrics Framework"（以下RMF）の目的・データ・測定基準が述べられています。
目的
- ユーザー行動の分析
- 検索品質の評価
- Summonの機能改善
データ
セッション*2・クエリ・クリックされた検索結果などの情報を用いています。匿名化されたセッション情報からユーザーの振るまいを、クリックされた検索結果を適合文書の代替として検索品質の評価を行っています。
4章
RMFによってSummonがどのようにかわったのかツールのデータソースとユーザーの振るまいの面から述べられています。
ツールのデータソース
オートコンプリートや関連するクエリにRMFのデータを用いています。*6
ユーザーの振るまい
検索のパターン・デフォルト表示件数の最適化・検索方法の特徴・クエリの語数と放棄の関係について述べられています。
- 検索のパターン
セッションの数は曜日によって周期的に異なる（平日に多く週末少なくなる）のに対し、セッション内での検索回数はほぼ一定です。原文Figure 4を参照ください。
- デフォルト表示件数の最適化
表示件数を多くすればユーザーは効率的に検索結果を確認できますが、送信するデータ量が多くなるので表示速度は遅くなります。Summonではほとんど上位10件までしかクリックされていないので、デフォルトの表示件数を25件から10件へと変更されました。デフォルト表示件数は各機関で変更可能にもかかわらずほとんど変更されていないことや、RMFの数値からユーザーにうけいれられていると考えられます。
- 検索方法の特徴
ほとんどシンプルなフリーワード検索が行われ、フィールド検索(クエリ単位で6%未満、セッション単位で4%未満)や演算子*7を用いた検索（2%強）はほとんど行われていません。一方でフィルタ機能はよく使用(クエリ単位で40%以上)されています。もっとも良く利用されているフィルタはコンテンツタイプです。
- クエリの語数と放棄
クエリの語数と検索やセッションの放棄の関連性を調査しました。いずれもクエリの語数が少ないほど放棄する割合が高まります。原文Figure 5・6を参照ください。さらに多くのクエリは3語以下で構成されています。これに対する改善の一つが関連するクエリの推薦であり、今後リリース予定のTopicペイン機能*8です。
5章
RMFのデータ品質や仮定を簡素化していることの意味について述べられています。
- データ品質
クローラーやプログラムによる機械的なアクセスなどは、RMFの分析をゆがめる可能性があります。一方で全てのデータを"Spam"といえるようなアクセスと実際のユーザーとのアクセスに分別するのは困難です。機械的なアクセスの特徴に当てはまるものは取り除く、判断が難しいものは"suspicious（容疑者）"タグをつけてデータは残し分析に加えることも除くことも出来るようにする、スパムを完全に取り除くのではなく分析の大勢に影響を与えないようにする、といったアプローチを組み合わせています。
- 仮定を簡素化していることの意味
セッションは、同一ユーザーによる単一の情報要求に基づく検索と仮定して、複数のユーザーが同一端末で短い間隔で検索を行った場合や、同一ユーザーが複数の情報要求に基づいて連続して検索する場合を考慮していません。クリックについてもクリックされた結果を適合とみなしていますが、リンク先を見て適合していないと分かった、本当は適合しているがクリックされなかった、検索結果でユーザーの情報要求が満たされてクリックする必要がなかった*9といったパターンが考えられます。こういった仮定に基づいた分析結果であることは配慮しておく必要があります。
6章
改めてRMFの意義やその効果、Summonの継続的な開発を行っていくことが述べられています。
-
-
- -
-
なぜデフォルトの表示件数を変更するのか、リリースが行われたときにちょっと疑問に思っていましたが、この論文でその根拠が理解できました。
全体の傾向だけでなく、各言語や機関ごとにRMFで行われている項目について比較分析ができると面白そうです。そのようなSerials Solutions社では手が回らないような機関単位のデータ分析や個別のセッションについての分析が各機関で実施できるようにデータが提供たり標準の統計ツール*10が充実することを願ってます。
*1:システム志向やユーザー志向のアプローチについては、 岸田和明. 情報検索における評価方法の変遷とその課題. 情報管理, 2011, vol. 54, no. 8, p. 439–448. 三輪真木子. 情報行動 : システム志向から利用者志向へ. 勉誠出版, 2012.などをご参考に
*2:一連のユーザーの振るまいを紐づける情報です。Summonでは90分以上の間隔が開いて無く、最大でも8時間となるように設定されています。
*3:一回も検索結果をクリックしない状況、セッションとクエリに対してそれぞれ放棄の状況を調査しています。
*4:Mean Reciprocal Rank:検索結果の評価指標です。検索結果の最上位にもっとも関連性の高い文書が表示されている状態が理想といえるので、１番上の検索結果がクリックされていれば1/1=1、5番目の結果がクリックされていれば1/5=0.2と、なにもクリックされなかったときは0とします。つまりMRRが1に近いほど良いシステムといえます
*5:Discounted Cumulative Gain:検索結果の評価指標です。複数の検索結果がクリックされることがありえますが、そのような場合の検索結果の品質を評価します。クリックされた検索結果で、上位に表示されているものに高得点、下位ほど低得点として特定を累積していきます。DCGの値が高いほどよいシステムとみなせます。
*8:原文Figure 7やSerials SolutionsがSummon 2.0を導入 ディスカバリーサービスに新たな進化no Topic Exploreの項を参照ください。Googleのナレッジグラフをイメージすればいいように思います。
*9:例えばある特定の書籍の著者情報などはクリックする必要がないといった例が論文中であげられています
*10:時間や曜日を導入している機関のタイムゾーンで設定するとか、どういったコンテンツによくアクセスされているのかといった項目が追加されないか、など標準の統計ツールにお願いしたいことはいろいろありますが
GibbsLDA++でトピック分析
なぜか唐突にブログを同時更新使用みたいな話が決まってしまったので、無理矢理エントリを書いています。
自然言語処理のトピックモデルの一つの手法であるLDAを使ってみました。
LDAについては以下のスライドが詳しいので、参照ください。
一部引用すると
・白鵬が単独首位 琴欧洲敗れる
・人は上の文を見て相撲に関係する文であることを理解できる
- 文中に相撲という単語は出てこないにもかかわらず
・単語は独立に存在しているのではなく、潜在的なトピックを持つ単語は同じ文章に出現しやすい
といったモデルです。
ギブスサンプリング*1によるLDAをC++で実装したソフトが公開されています*2。Pythonによる実装*3もいくつかありましたが、今回は研究室の人が利用しているこちらを。
インストール手順
- 以下のページからソースコードをダウンロード。
- ダウンロードしたファイルを解凍して、そのままmakeコマンドをたたくと失敗します。
- GibbsLDA++-0.2のmakeのエラーについて - Screaming Loud
を参考にファイルを修正。
- GibbsLDA++-0.2のmakeのエラーについて - Screaming Loud
- 念のためmake clean したあとにmake allでインストール完了。
使い方
satomacoto: LDAの実装を試してみるを参考にして貰うのがいいと思いますが。
LDAで解析するテキストデータを用意します。以下サンプルです。
n
{文書１}
{文書２}
{文書３}
{文書…}
{文書n}
文書i=単語1 単語2 単語3…単語m 形式は、1行目に解析対象とする文書数。2行目以降に1行1文書としてスペース区切りで単語を並べます。
1行目で定義した文書数より全体の文書数が少ないとエラーがおきて解析できません。
その後、ターミナルからGibbsLDA++のSRCフォルダ内にあるLDAを実行します。
src/lda -est -alpha 0.5 -beta 0.1 -ntopics 5 -niters 1000 -savestep 500 -twords 20 -dfile pyscript/result.txt
いろいろとオプションを指定しています。
主なオプションは以下のようなものです。
- -est…ゼロからLDAモデルを推定。（-estcオプションや-infオプションですでに構築したモデルを利用することもできます）
- alpha・-beta…LDAの為のパラメータ。アルファのデフォルト値は50/K（Kはトピック数）。
- -ntopics…分割するトピック数の指定。デフォルトは100。
- -niters…ギブスサンプリングの試行回数。デフォルトは2000。
- -savestep…指定した回数ごとに結果を保存。デフォルトは200。
- -twords…各トピックの特徴語を出力する個数。
- -dfile…データファイルの指定。実行結果も同じ場所に保存されます。
実行するとsavestepで指定したステップごとに５つのファイルが出力されます。
- model-name.others…αやθなど各パラメータ
- model-name.phi…トピックごとの単語の出現確率。
- model-name.theta…文書ごとの各トピックである確率。
- model-name.tassign…文書ごとに単語ID：トピック。
- model-name.twords…各トピックごとの特徴語。
また、単語と単語IDの組であるwordmap.txtというファイルも出力されます。
CiNii Articlesでトピック分析
CiNii Articlesで"IR"を検索した結果をトピック分析した結果です。文献数10000でトピックを10個、トピックの中で特徴的な単語を5個抜き出した結果です。
Topic 0th: IR 0.007441 ), 0.007109 acid 0.007052 NMR 0.006914 )- 0.006365 Topic 1th: larvae 0.000222 superstructure 0.000188 pyrophyllite 0.000188 calculus 0.000188 Studied 0.000154 Topic 2th: HEMA 0.000325 Andosols 0.000257 anodes 0.000222 BTC 0.000222 allophanic 0.000188 Topic 3th: VC 0.000730 vitamin 0.000221 SR 0.000221 binders 0.000187 kaolin 0.000187 Topic 4th: こと 0.012453 IR 0.008112 検索 0.007279 測定 0.005234 研究 0.005169 Topic 5th: tlae 0.002876 ir 0.001369 tl 0.000600 Tlae 0.000477 [' 0.000477 Topic 6th: 無し 0.001094 タイトル 0.001094 virus 0.000421 silk 0.000320 mosaic 0.000320 Topic 7th: наклонения 0.001031 что 0.000904 на 0.000809 пересказывательного 0.000809 времени 0.000809 Topic 8th: 大豆 0.000836 煮汁 0.000393 bentonite 0.000324 ACE 0.000256 ニコチアナミン 0.000222 Topic 9th: 品種 0.012668 IR 0.009663 こと 0.006451 細胞 0.005535 抵抗 0.005449 Topic 10th: Ir 0.020523 領域 0.009596 相関 0.009087 _< 0.008022 Co 0.007744 Topic 11th: IR 0.011768 system 0.005076 using 0.004087 method 0.004012 paper 0.003056 Topic 12th: 治療 0.005279 照射 0.004992 Ir 0.004322 線量 0.002951 組織 0.001994 Topic 13th: _??_ 0.001301 ]_ 0.000807 il 0.000774 del 0.000609 passato 0.000609 Topic 14th: IR 0.030421 企業 0.010087 特集 0.008930 -- 0.008591 情報 0.007713 Topic 15th: IR 0.012067 temperature 0.005610 films 0.005380 Si 0.004885 FT 0.004631 Topic 16th: IR 0.015041 cells 0.005403 ), 0.004770 ). 0.004047 patients 0.003404 Topic 17th: SUB 0.075021 </ 0.069534 SUP 0.025550 >- 0.007334 >< 0.005725 Topic 18th: UWB 0.015344 方式 0.011665 IR 0.011287 通信 0.007707 こと 0.007389 Topic 19th: BPH 0.000755 pesticide 0.000553 Meeting 0.000453 pesticides 0.000419 Society 0.000419
IRでは情報検索なり、機関リポジトリなり、インベスター･リレーションズなり、さまざまな意味があるので、それが分類できないかなと思っていました。英語がグルーピングされてしまったので、そんなにわかりやすい結果になっていませんでしたが、Topic4や14などは検索や企業に関するトピックというのが提示されています。
*1:ギブスサンプリングについては、こちらのページなどを参照ください。PRML 11章 二変量正規分布からのギブスサンプリング
*3:Gensim:Topic modekking for humans ・PythonでLDAを実装してみる-satomacoto
ディスカバリーサービスSummonのログ分析
7月6日第30回医学情報サービス研究大会 MIS30と7月17日学術情報セミナー2013 in 福岡 「学術情報ビッグバン～情報の効率的発見と提供について～」 | 九州大学附属図書館で、「ディスカバリーサービスSummonのログ分析」というタイトルの報告をしました。
九州大学のSummonの利用ログからどのようにSummonが用いられているか、利用状況・検索クエリ・セッション・アクセスされたコンテンツから分析を行いました。
報告スライドは以下のとおりです。
多くのユーザーは日本語検索の際に、
- 検索クエリをとくにスペースなどで区切ることなく検索している
- 検索結果からクリックされるのは2つ以下
といったことを数字で示すことができたのは良かったと考えています。
（おそらく大部分は日本の）リポジトリコンテンツへのアクセスが全体の7%もあったのは意外でした。東工大のリポジトリへのアクセスが単独で全体の1%を占めているのは、工学部の学生が多い九大の状況を表していると考えています。
一方で当初知りたかったことは、検索を行って望ましい結果が得られなかったときにどのような検索クエリの修正を行うのか（あるいは諦めるのか）ということでした。今回はデータの制約もあり十分に調べることが出来なかったので、引き続き調査するつもりです。
次の機会があればSerials Solutions社を噛まずに言えるようにしたいです…。
発表後、Code4Lib JournalでThe Code4Lib Journal – Actions Speak Louder than Words: Analyzing large-scale query logs to improve the research experienceというSerials Solutionsによるログ分析とその結果を用いたSummonの改善についての論文が掲載されました。また、The Code4Lib Journal – Relevance and Phrase Searching in Summon: looking under the hoodというSummonの検索結果のメカニズムについての論文も掲載されています。
