リブショカ(図書館書架)β版

リブショカ(図書館書架)に関する情報発信

openBD 始動と基盤APIの選択

openBDのキックオフが先日あった。都合により参加できなかったがかなり熱があるものだったようだ。それは十分理解できる。現役時代に望んでいたサービスが鼓動を始めた。嬉しい限りだ。

openBD | 書誌情報・書影を自由に

 

さて,現在開発中のWebサービスで基盤データサービスとして候補に挙げていたのは,AmazonAPIとPortaである。どちらか一方ではなく,AmazonAPIをプライマリ,Portaをセカンダリというイメージだった。やはり書影データを使えること,アフェリエイトがあることが大きい。書籍に係る広告報酬はデータを登録してくれた利用者のためのもので,このサイトの運営維持費の捻出は,google系の広告を予定している。

さて,openBDであるが,期待は高まるが,調査しなければいけない部分もありそうだ。今回のサービスは,

 1)図書館員の業務補助ツール

 2)利用者サービス

の2つの目的としているが,どこまで取得したデータを加工して渡せるかについては,特に確認の必要があるだろう。また収録範囲や収録項目についても調査が必要だ。

 

キックオフでは,API開発を担当したカーリル社の方が,データ流通としてのXMLはダメ的な発言があったそうだが,これは同意。たしかに,XMLは素晴らしいしなんでもできる。一方,非エンジニアや図書館員にとっては,あまりにも難解すぎて利用する気すら起きなくなってしまっている。書誌データ構造は確かに複雑であるが,XMLで記述できるからといって際限なく複雑化するのではなく,2次利用しやすいという視点からある程度制限的な記述であることが望まれると考えていた。その点,JSONはいい制限加減なのである。データハンドリングもよい。

本題に戻るが,思想的な部分ではopenBD一択である。今回開発するWebサービスが少しでもopenBDの普及に役立てれば本望だ。だが一方でAmazonAPIで提供されるデータ量や質の問題を無視するわけにもいかない。どのデータソースを使っているかは,利用者にとってはどうでもよいことであろう。

もう少し,調査・検討してみるが,openBDをプライマリ,セカンダリをAmazonAPIとするのが第一か。また,調査してみるとカーリルAPIが素晴らしい。図書館として利用者登録してもらった場合には,なんとかカーリルAPIを使って,入力の手間を減らせればと思う。

なによりopenBDの登場により,さらに本と読者がつながることになるのは素晴らしい。図書館はこの流れに取り残されてはいけない。

 

openBDへの賛辞とエールを込めて。