ひまつぶし雑記帖

書誌情報データを求めて三千里

2019/4/3 [09:18:16] (水) 天気

一昨日、新元号の発表があった4月1日に国立国会図書館の書誌データAPIが解禁となった。
今までも検索などに使えていたけど、データベースとしてガツガツ使うには登録が必要だったり面倒くさかったのが、4月1日からは誰でも自由に使ってもかまわんぜ!になった。

てことで、今さら国立国会図書館の書誌データAPIをごそごそ覗いてみた。

国立国会図書館サーチについて>API仕様の概要 
https://iss.ndl.go.jp/information/api/riyou/

わたしの、というかわたしが公開しているサイトの使い方は前にも書いた通り。
「ISBNをキーにして書誌データと書影URLを取得したい」
たとえば、スティーヴン・キングの『シャイニング』
ISBNは978-4167705633

これを国立国会図書館のAPIで探すには以下
https://iss.ndl.go.jp/api/opensearch?isbn=978-4167705633
→書誌情報のXMLが返ってくる
https://iss.ndl.go.jp/api/openurl?isbn=978-4167705633
→検索結果ページが返ってくる
https://iss.ndl.go.jp/api/sru?operation=searchRetrieve&maximumRecords=10&query=isbn%3d9784167705633
→書誌情報XMLが返ってくる(このsruはさらに細かく検索方法の指定もできる)

うちの場合、必要な書誌情報はopensearchで十分。
著者についてももろもろ考慮されて(同性同名や読みなど)おり、データのクオリティは信用できる。さすが。
https://www.ndl.go.jp/jp/data/faq/author.html

蔵書のある図書館の情報なども取得できるので、位置情報と合わせて「目当ての本がある最寄りの図書館」なんて検索も実装できるし、その手のアプリがすでにあるのは、国会図書館のデータが元ネタじゃないかな。

だけど、書影がないのはほんと残念。
本棚を眺める楽しみのひとつ、というか欠かせないのが表紙だもんなあ。
基本的な書誌情報は国立国会図書館で、書影・表示画像はamazonなどのショップサイトのURLを別途取得…とか1冊の本のために2回も外部にリクエストしてるとサイトの表示がもたつく原因になってしまう。

てことで、うちのサイトのデータ取得方法は現状のままとする。
国会図書館のデータはまた何か別の用途で利用させてもらおう。しっかりとしたデータは見ていて気持ちいい(データオタク)


ちなみに。
「一般社団法人 日本出版インフラセンター」という版元主導のところも3月25日に書誌データベースのサイトをオープンしたけど、APIもなく、手入力でポチポチ検索できるだけ、なのでスルー。
image

»電子書籍制作代行についてはこちら

スクレイピングをブロックされるの巻

2019/3/19 [16:25:45] (火) 天気

ISBNをキーに本の情報(タイトル、著者、書影)を求めて三千里、だ。

あらすじその1
かれこれ15年以上、ずっと利用させてもらっていたAmazon(PA-API)の利用条件が変更となり、うちのように売上のほとんどないサイトだと利用するのが難しくなった。
状態を見ていると、使えたり使えなかったり、というかほとんど使えないんだけど、時々使えることがある、といった感じ。その条件がよくわからない。

あらすじその2
PA-APIがそんな状態なもんだから、Amazonの商品ページをスクレイピングしてのデータ取得に変更。すんなりデータが取れた、と思う間もなく(ほとんど7日以内)スクレイピングがAmazonにブロックされてしまった。
データが取れなくなったんで、取得するHTMLを眺めたら、自動アクセスしているようだけどAPIがあるからそちらを使いなさい、というコメントが入っていた。
そもそもアマゾンは規約でスクレイピングが禁止されてるので、やっちゃいかんのだ。

てことでamazonについては、ほぼ利用できなくなった。
(アフィリエイトタグ、リンクやアカウントには問題はない。データベースとしてAmazonが使えなくなったということ。念のため)

何度も書いてるように4月になったら国立国会図書館がAPIを公開するので乗り換えを検討。
ただ、どんなAPIなのかどんなデータが使えるのか、実際に公開されてから確認となる。
いま公開していて、ユーザーさんが利用してくれているサイトもあり、いままさにどうするのかということで、繋ぎでいいのでなんとかしなければならない。

AmazonのPA-APIが不定でたまにしか使えない(たまに使えるからかえって未練たらたらとなる)
Amazonに対するスクレイピングは規約も不可。

ということで、その場しのぎのでっちあげ、というわたしの得意技。
AmazonのAPIを使ってページを公開しているサイトをピックアップして、そちらをスクレイピングすることにした。
アマゾン本家ではなくAPIを利用しているコバンザメからデータを持ってくる便所バエ作戦だ。

本のデータを取得するためだけに、文字通り機械的にアクセスするわけだから、そのサイトにとっては何の利益にもならない、ただの無駄なアクセスとなる。amazonのようにインフラも強固巨大なサイトならともかく、規模的に小さなサイトだとちょっとした負荷も迷惑でしかない。
さすがに申し訳ない。
のべつ幕なしリクエストを投げるようなことを避けるために自鯖内で期間限定のキャッシュすることにした。

図式的には
・本の情報が欲しい時はまず自鯖のキャッシュを確認
・キャッシュされていればそれを利用
・キャッシュになければPA-APIを利用してデータ取得を試す
・PA-APIでデータ取得できればそれを利用。取得したデータをキャッシュ
・利用制限でデータ取得できなかったら他サイトをスクレイピング。
・スクレイピングでデータ取得できればそれを利用。取得したデータをキャッシュ
てことにした。

キャッシュするのは、ISBN・タイトル・著者の基本3点セット。さらにデータがあれば書影のURL。
本のタイトルや著者をキャッシュすることは問題ないはずだけど、書影(画像)についてはたぶん権利関係がらみで面倒くさいことがあるだろう。
画像をダウンロードして利用するなどもちろんアウト…というかただの犯罪行為。
公開されている書影のURLについては問題ないと思うけど、書影を公開しているサイトと書影(画像)の権利者とでどのような約束があるのか不明で、おそらくずっと同じURLで公開しない。もしかしたらアクセスのたびにURLが変わることも考えられる。なので自鯖でのキャッシュを期間限定とした。


今回のことでちょっと調べてみたら、スクレイピング行為がなにやらマーケティングだのなんだので使われていて、スクレイピングについてのスキルを持っているといろいろ重宝されて優位に立ち回れるとのこと。

いやいや、ちょっと待てよ、だ。
公開されているものとはいえ、他人の著作物から、自分の都合の良いデータだけ切り取ってもってくるのがスクレイピング。そしてそのデータは権利者の意図とは違う使い方をされるのがほとんどだろう。カタカナ言葉でなんかごまかそうとしているけど、単なるタダ乗り行為。

なんちゃら猛々しいんじゃねえのかとか、便所バエの自覚はないのかと昭和老害は思うわけですな。
image
て、オライリーからこんな本まで出てるんだなぁ。ううううむ。ほんまかいな。

 

»電子書籍制作代行についてはこちら

Amazon PA-APIの代わりにスクレイピング

2019/3/5 [01:40:20] (火) 天気

ウチのサイトで売上がなく、AmazonのPA-APIの利用制限に引っかかって使えなくなったのが前号までのあらすじ。
充実した本のデータベースとしてありがたく使わせてもらってたんだけど、Amazonも営利企業だ、売上に貢献できてないのだからやむを得ない。

しかたがないので、Amazonのページをスクレイピング(クロール)、ページを解析して必要な情報を取得することにした。

Amazonが公式に提供してくれるAPIは仕様も明らかにされていて使い勝手がいいし、変更も予告されるので事前準備ができる。
その点スクレイピングは自力でhtmlを解析しなきゃいけないし、サイトのちょっとしたリニューアルのたびに解析のやり直しとなる。て、そのちょっとしたリニューアルなんて頻繁なので追随するのが大変。

APIを使わず、サイトをスクレイピングするメリットなどない。
売上がたってAPIの利用制限を回避できるようになるまでの暫定手段…て、現状、まるで期待できんけど。


とりあえず目先必要なモジュールを書き換え・置き換えたので、忘れないうちにメモ。

わたしが公開しているサイトのほとんど、Amazonから取得する本の情報が使われている。
馬鹿のひとつ覚えで、どれもisbnをキーに本のデータを取得してその中から、タイトル、著者名、レビュー、書影をサイト表示に使っている。また、検索結果を表示させているページもある。

今回APIからスクレイピングに変えることで、検索は止めることにした。
最初はAmazonの検索URLの検索結果からデータを取得しようと思ったんだけど、アマゾンのページを見ればわかるように、検索対象以外の本が、ベストセラーだのオススメだのと入り混んでくる、雑音が多いページなので却下。APIだと雑音はなかったんで、それなりに有意だったのに、このありさまじゃわざわざ実装する意味がない。
てことで、ISBNをキーにして、タイトル、著者名、書影、レビューが取得できればそれでOKとした。

…と、なんだか小難しいことをおおげさに言ってるけど、そんなことは全然なくてAmazonのページURLを見ればなるほど簡単の種明かしだ。
たとえば。
https://www.amazon.co.jp/dp/4575513393
↑『アレルヤ』桜井鈴茂の商品詳細ページ
ページのURLにASIN(4575513393の部分)が使われている。ISBNさえわかればASINに変換してURLにしてリクエストしてやればページのHTMLが取得できる。
あとはHTMLを解析して必要なデータを取ってくればいいだけだ。

13桁のISBNを、Amazonの10桁のASINに変換するネタが2006年の雑記帖に。
「来年からのISBNの13桁に」
https://t2aki.doncha.net/?id=1167061487
この時作ったモジュールが今も現役。

Amazon商品ページのHTMLのどのタグ、どの文章を正規表現で切り取ってるか、など具体的な詳細をここで今書いたところで上記したように明日にも構造が変わってしまうことがありうるんであまり意味がない。

スクレイピングする時のわたしなりの定石というかポイントだけ。

クロールする対象はPCサイトではなくて、スマホ版。
スマホ版の方がHTMLが素直なので解析しやすいから。PC版だとテーブルが邪魔になることが多い。HTML解析のモジュールもあるのでそれを利用すればいいんだろうけど、汎用的なモジュールは、結局は対象サイトに合わせてカスタマイズが必要となる。だったら、最初から解析が比較的ラクなスマホ版を対象にすればいい。

何はなくてもタイトルタグ。
SEOのこともあるので、大きなサイトは、タイトルタグの内容に関しては安直に変更したりしないので信用できる。
Amazonの商品ページで言うと、書名・著者が必ず入っている。ウチ場合、ISBNをキーに欲しいデータはこれだけといってもいいほど。ページ本文(HTML)の解析なんて必要がない。

とはいえ、書影のURLやレビューはHTMLを解析する必要がある。
それには、HTMLの中にあるhタグとページで一意(ユニーク)なidをチェックするだけでほとんどことは足りる。
perlなら欲しいところを
@buf = $contents =~ m!tag(.+)tag!g
で一網打尽

くどいようだけど、スクレイピングはamazonが公式にサポートしてくれるAPIと違う。
APIだと変更などはアナウンスされるのでそれを待ってればいい。でも、スクレイピングしてデータを取ってるとHTMLの変更を検知、追随する必要がある。
ヘルスチェックのスクリプトを書いてクローンで走らせる必要があるなあ。

来月、2019年4月から国立国会図書館で書誌情報の提供、APIでの提供が始まるらしいので、そちらに乗り換えることも考えておこう。
http://www.ndl.go.jp/jp/news/fy2018/190219_01.html

image

[2019/03/12 04:18:29]


てことなので良い子はマネしないように。
そりゃそだな。公開されているとはいえ、スクレイピングって、他人の著作物から勝手にデータを抜き出して使うわけだから、あまり行儀のよいことじゃない。
解散。

国立国会図書館のAPIに期待…だけど、電子書籍とか書影とか対応してるのか気になるところ。

»電子書籍制作代行についてはこちら

Amazon Product Advertising API利用制限

2019/2/19 [13:14:51] (火) 天気

AmazonのAPIが2019年からポリシー変更となった。

ひらたく言うと「売上のないサイトやアカウントはAPIを利用できなくなる」
さらにひらたく言うと、わたしのアカウントは売り上げがないので利用できなくなった。

Product Advertising API (PA-API) の利用ガイドライン
https://affiliate.amazon.co.jp/help/topic/t32/

[重要] Product Advertising API 利用ポリシーの変更について
https://affiliate.amazon.co.jp/help/topic/t52/

Amazonの商品データベースを利用できるAPIはかなり便利で、また使い勝手もよかったので残念。
もちろんアフィリエイトで小遣い稼ぎになるならありがたい話だけど、うちのような辺境にそれは見込めないので、もともと「充実した本のデータベース」として重宝していた。
ISBNさえあれば、ほとんどの本の情報が揃ってるから。

わたしが利用しているのは
・書名
・著者(作者、翻訳者、挿絵など)
・書影
の3点。価格については変動してるのでおまけ程度。

なので、その3点に絞ってamazonのサイトをクロールして情報を取得するように順次変更する。

とりあえず、まずはお問い合わせ(本が登録できんぞ!)をいただいている
「趣味は読書2」https://doncha.net/
をあわてて修正。

これはWEB本棚で、本が登録できないなど論外だ。
amazonの検索結果からも登録できるようにしてあったんだけど、これはちょっと無理。サービスレベルが落ちるがしかたなく諦め。
また、やはりサイトをクロールするより、APIの方がレスポンスが断然早いなあ。クロールだとひと呼吸待つ感じになってしまった。

わたしが公開しているサイトのほとんどはamazonを利用しているので全部の修正は時間がかかりそうだ。とほほ。

»電子書籍制作代行についてはこちら

読者コミュニティ「趣味は読書2」の登録データ

2015/5/14 [09:50:39] (木) 天気

image
「趣味は読書」というweb本棚サービスを2006/4/1から公開している。

今日時点

登録会員:310名
登録冊数:49,780冊
登録タイトル:38,851タイトル
登録著者:14,264人

【人気タイトル(会員10人以上が登録)】

17空の中
15太陽の塔, 陽気なギャングが地球を回す, 重力ピエロ, 告白, 夜のピクニック
14予知夢, しゃばけ, 死神の精度, 海の底
13西の魔女が死んだ, アヒルと鴨のコインロッカー, 探偵ガリレオ, 夜は短し歩けよ乙女, 博士の愛した数式, 四畳半神話大系, 阪急電車, 華胥の幽夢(ゆめ)—十二国記
12魔性の子, 容疑者Xの献身, オーデュボンの祈り, 終末のフール, 火車, ラッシュライフ
11光の帝国—常野物語, レインツリーの国, クジラの彼, グラスホッパー, 手紙
10鴨川ホルモー, 天使, 夏への扉, 図書館戦争, アルジャーノンに花束を, 少女には向かない職業, 村田エフェンディ滞土録, 夏と花火と私の死体, 氷菓, 六番目の小夜子, ハサミ男, ゴールデンスランバー, 向日葵の咲かない夏



【人気著者ベスト20(登録された本の総数)】

376恩田陸
345東野圭吾
340茅田砂胡
307小野不由美
302栗本薫
299宮部みゆき
229田中芳樹
215伊坂幸太郎
206有川浩
178藤子・F・不二雄
168浦沢直樹
158浅倉久志
157村上春樹
156西尾維新
153秋本治
150CLAMP
150荒川弘
146京極夏彦
144桜庭一樹
142大森望
141スティーヴンキング




「趣味は読書2」
http://doncha.net/about.pl

図書館で本を借りて図書カードを見て
「あれ?あのコもこれ読んだのかぁ」とか「おっあいつこんなの読むんだ」と、ニマニマしたり
ひとんちに呼ばれたら、まず本棚を覗いて
「これ、わたしも読んだよ」と言いたくなったり
図書館とか本屋で、どの棚の前に立っているかで、そのひとの属性がわかって、うれしかったり
なんだか「ありきたり」な趣味なので履歴書にも書けない気がしたり
本を読んでも難しいことを考えたり感想文は面倒くさかったり
ヲタクだと思われそうで嫌だったり

でもって、だけど本好きとか本読みですが、なにか?

というようなことを、思ったことはありませんか? ぼくは、あります。なので、そんな本棚のようなサイトを作ってみました。



『読者のコミュニティ』
↑にも書いたけど。
東日本大震災の時、自宅サーバーで公開していたものを一度閉じて、レンタルサーバーで再開。
2006年公開当時、流行りのmixiもどきで掲示板や日記などつけたんだけど、利用パターンの8割以上が「本棚直行直帰」だったのでリニューアルして現在の形に。

現状は月に20人ぐらいのアクティブユーザーといったところ。
特に告知などしてなくて、ニュースサイトの古い記事や紹介されているブログ、twitter連携などから新規に登録・利用してくれている。


手前味噌。
設計もデザインも古くさくなってダサイのはすみませんだけど。
もともとわたしは「あれ?これ読んだっけ?持ってたっけ?」のトリ頭、重複買いがわりとあったのに、「既読・未読」フラグのあるこのweb本棚のおかげで重複買いはなくなった(ログインして検索、あるいは、twitterにリプを飛して本棚検索結果を返してもらう)


『「趣味は読書2」など読書記録WEBサービス』
2011年時点のWEB本棚サービスのリスト。なくなったサービスがけっこう多いけど。

本を読むひとの数を増やしたい、小説を面白がってくれるひとを増やしたい、たくさん面白い小説を読みたい、というのはどのサービス提供者にも共通することだと思うんで、みんなで盛り上げられればいいなあ、と思うですよ。




面白い小説はまだまだたくさんあるので、残り時間を有効に使わないとなあ、とあらためて初老はしみじみするのでありました。

»電子書籍制作代行についてはこちら

ツイートとレビューを取得する

2013/2/24 [10:07:32] (日) 天気

この雑記帖スクリプトでは、公式APIが使いにくい・デザインが合わないブログパーツなどに関しては、HTMLから直接取得している。

twitterの「その他」→「ツイートをサイトに埋め込む」
この機能は便利なのに、表示・デザインに自由度がなくて、サイトに埋め込むと
image 
このありさま。どっちが本文でどっちが引用(ツイート)なのかわからない我が侭な自己主張。ユーザビリティ、デザイン的にこれはない。
twitterとしては、表示をコントロール下において広告などで収益を視野に入れて展開したい、んだろうけど。サイトはこちらのもの。大きな顔をされては困る。

Amazon AWS の API でレビューが取得できなくなっていた(もう2年も前の話。今さら気づくのんきな父さん)
商品情報に含まれているのは、ユーザーレビューがあるかないか(true false)ユーザーレビューページのURL(24時間の期限付き)。このURLをインラインフレームで埋め込んでね、ということらしい。インラインフレーム表示させると、サイトの統一感を壊してしまって、楽天のチラシのような見た目になってしまう。
Amazonとしては、レビューの品質を上げるためにレビューをコントロール下において、レビューの精査・削除などしていきたいんだろう。

しかたないので、twitterもAmazonも公式APIを使わずに、HTMLを解析して取得、スタイルシートなど調整して、サイトにおさめるようにした(スクリプトのソースはちょっと内緒。HTMLのどこを見てるかあまりおおっぴらにするのは良くない=ルール違反かなあ)


見やすいサイト、使いやすいサイトは、サイトに掲載される情報の分類がきちんとわかりやすくレイアウトデザインされていて、動線も明確でリンクをクリックしたら何が起こるのかわかりやすくなっている。

アートは感性・デザインは理屈。サイトもデザインと同じで、どうしてこの位置にこのブロックがあるのか、なぜ動線はこっちに向けてるのかなどなど、いちいち説明がなければならない。

情報設計=インフォメーションアーキテクチャ=IA というらしい。初めて聞いたときは、また妙な、きっとくだらないカタカナ言葉でひとを騙そうとしやがって、だったんだけど本を読んでみると、IAに関してはWEBに関わるひとにとって必須。

 

 

»電子書籍制作代行についてはこちら

profile

profile

 
doncha.net
名前:
飯田哲章
mail:
t2aki@mrh.biglobe.ne.jp
twitter:
t2akii

WEBサービス制作/電子書籍制作

検索
<<2019/5>>
   1234
567891011
12131415161718
19202122232425
262728293031

リンク

WINDOWS版サウンドノベル
おかえりください PC WINDOWS版サウンドノベル
『おかえりください』体験版

iPhone電子書籍アプリ
小説同人誌Select iPhone電子書籍アプリ
『小説同人誌Select』

[4 Page] »
1 2 3 4

TOTAL:2873

2019 (12)
1 (3)
2 (4)
3 (2)
4 (2)
5 (1)
2018 (21)
1 (3)
2 (2)
3 (2)
4 (1)
5 (1)
6 (6)
8 (1)
9 (1)
10 (2)
12 (2)
2017 (32)
1 (2)
2 (1)
4 (2)
5 (1)
6 (6)
7 (3)
8 (5)
9 (3)
10 (2)
11 (2)
12 (5)
2016 (41)
1 (5)
2 (5)
3 (2)
4 (3)
5 (4)
6 (6)
7 (2)
8 (2)
9 (3)
10 (1)
11 (4)
12 (4)
2015 (99)
1 (11)
2 (12)
3 (9)
4 (6)
5 (8)
6 (8)
7 (3)
8 (5)
9 (16)
10 (6)
11 (1)
12 (14)
2014 (112)
1 (16)
2 (5)
3 (6)
4 (12)
5 (16)
6 (19)
7 (9)
8 (6)
9 (4)
10 (8)
11 (6)
12 (5)
2013 (145)
1 (24)
2 (15)
3 (18)
4 (23)
5 (14)
6 (11)
7 (7)
8 (11)
9 (5)
10 (4)
11 (6)
12 (7)
2012 (103)
1 (1)
2 (1)
3 (4)
4 (3)
5 (7)
6 (26)
7 (17)
8 (5)
9 (8)
10 (10)
11 (11)
12 (10)
2011 (54)
1 (4)
3 (7)
4 (4)
5 (14)
6 (6)
7 (3)
8 (3)
9 (1)
10 (4)
11 (2)
12 (6)
2010 (70)
1 (12)
2 (7)
3 (6)
4 (6)
5 (3)
6 (10)
7 (6)
8 (4)
9 (3)
10 (4)
11 (3)
12 (6)
2009 (144)
1 (15)
2 (12)
3 (12)
4 (6)
5 (15)
6 (6)
7 (10)
8 (9)
9 (17)
10 (12)
11 (14)
12 (16)
2008 (148)
1 (10)
2 (6)
3 (10)
4 (11)
5 (13)
6 (10)
7 (13)
8 (19)
9 (18)
10 (12)
11 (13)
12 (13)
2007 (106)
1 (7)
2 (5)
3 (3)
4 (7)
5 (5)
6 (9)
7 (8)
8 (13)
9 (18)
10 (11)
11 (8)
12 (12)
2006 (158)
1 (28)
2 (28)
3 (25)
4 (7)
5 (9)
6 (7)
7 (12)
8 (13)
9 (10)
10 (7)
11 (6)
12 (6)
2005 (350)
1 (31)
2 (26)
3 (26)
4 (27)
5 (29)
6 (30)
7 (32)
8 (30)
9 (30)
10 (32)
11 (29)
12 (28)
2004 (292)
1 (24)
2 (24)
3 (29)
4 (27)
5 (28)
6 (25)
7 (26)
8 (24)
9 (12)
10 (19)
11 (26)
12 (28)
2003 (318)
1 (22)
2 (25)
3 (21)
4 (28)
5 (28)
6 (28)
7 (28)
8 (29)
9 (26)
10 (29)
11 (28)
12 (26)
2002 (317)
1 (29)
2 (26)
3 (26)
4 (25)
5 (28)
6 (30)
7 (27)
8 (21)
9 (25)
10 (27)
11 (28)
12 (25)
2001 (277)
1 (17)
2 (21)
3 (23)
4 (20)
5 (31)
6 (18)
7 (26)
8 (25)
9 (29)
10 (19)
11 (24)
12 (24)
2000 (53)
6 (9)
7 (4)
8 (2)
9 (3)
10 (1)
11 (15)
12 (19)
1999 (3)
7 (1)
10 (2)
1998 (18)
9 (9)
10 (7)
11 (2)