- 映画記録アプリ Letterboxd のように、すっきりして実用的な読書記録アプリを作ろうとする中で、ISBN体系の構造的な問題が中核的な障害だった
- 書籍検索機能のために Google Books API を使ったところ、同じ作品の複数の ISBNバージョン がそれぞれ別項目として返される問題を発見した
- これは 書誌学的構造（FRBRモデル） で「作品（work）」と「表現（expression）」、「形態（manifestation）」が区別されるためで、ユーザーは単に「本を読んだ」という事実だけを記録したくても、データが細分化されている
- OpenLibrary は「作品」中心のデータ構造を提供するが、それでもなお 重複と不完全さ が存在し、完全な代替にはならない
- 映画データベース TMDB のような、高品質の 公開メタデータ基盤 が書籍分野には存在せず、これは本中心のソーシャルプラットフォーム開発の主要な障害要因となっている
Letterboxdと書籍プラットフォームの比較
- Letterboxd は すっきりしたインターフェース と 押しつけがましくないソーシャル機能 によって、映画鑑賞の記録を簡単に管理できる
- ユーザーは視聴した映画とその時点を簡単に記録できる
- 一方 GoodReads は複雑なUIと多段階のクリック構造のため、読書記録が不便だ
- 「読んだ本」「読みたい本」が1画面に混在し、読書チャレンジ・ニュースレターなどの付加要素 が場所を取っている
- GoodReads がこれほど使いにくい理由は、Amazon の書籍販売事業における優先順位の低い派生プロダクト だからだ
- Storygraph にも同様の問題があり、ユーザーは結局 Obsidianファイル で個人記録を管理するようになる
Google Books APIとISBNの問題
- 書籍検索機能を作るために Google Books API を使ったが、同じ作品が複数のISBNで重複して検索される現象が発生した
- 例として “The Last Unicorn” を検索すると、ハードカバー、ペーパーバック、eBook、改訂版など がそれぞれ異なるISBNで返される
- 各ISBNは 異なる判型や版 を意味するが、ユーザーは単に「本を読んだ」という事実だけを記録したい
- このような構造は 検索とデータ統合 を難しくし、作品単位の記録システム構築には不向きだ
FRBRモデルと「作品」単位のアプローチ
- 図書館学で使われる FRBRモデル は、書籍データを4つの階層に分ける
- Work（作品）: 抽象的な創作物そのもの（例: 小説 "The Last Unicorn"）
- Expression（表現）: 特定の版
- Manifestation（形態）: 特定の版の物理フォーマット（ペーパーバック、ハードカバーなど）
- Item（個体）: コレクション内の個別の物理的対象
- Google Books は主に「表現」または「形態」レベルのデータを返すが、ユーザーが必要としているのは「作品」レベルの抽象単位だ
- OpenLibrary は「作品」中心のデータ構造を提供するが、それでも 重複項目 が存在する
- 例: Yoko Ogawa の Hotel Iris を検索すると、同じ作品が4回重複表示される
データ品質とエコシステムの限界
- Letterboxd は The Movie Database (TMDB) を基盤として動作しており、TMDB は約 100万件の映画データ を保有している
- 一方 OpenLibrary は 4,000万件以上の作品 を含むが、不完全で整理されていないデータが多い
- 映画データは商業プラットフォームとコミュニティ貢献が結びついて品質が高いが、書籍データは 規模が大きく資金支援も不足 している
- このため、書籍版Letterboxdのようなサービス を作るための基盤データが存在しない
結論と今後の試み
- 完全な オープンソースの書籍メタデータ基盤 が存在しないため、読書記録プラットフォームの開発は映画よりはるかに難しい課題だ
- 著者は今後も 独立した読書記録システムの構築 を試みる予定だ
- 映画の好みを見つける体験のように、読書記録にもパーソナライズされたアプローチが必要だ
4件のコメント
そりゃ… ISBNは出版物の識別子であって、コンテンツの識別子じゃないからね…
タイトルがちょっと釣りすぎですね（笑）
コンテンツの識別子欄が空白のようです :(
ISBN体系がそれほど体系的な分類を考慮していないのも事実ではあるので……
規則上は増刷のたびに番号を別途付与することになっているのに、最下位カテゴリが出版社である以上、作品別に分類する必要性があるにもかかわらず、管理が簡単ではないんですよね
Hacker Newsの意見
MusicBrainzのデータベース構造を思い出した
たとえば Nirvana の Nevermind アルバムは1つの release group であり、テープ・CD・LP・プロモ盤など、さまざまな媒体や国別の再発版が存在する
カタログ番号やバーコードが違って区別できる場合もあるが、同じコードが表記されていても実際には別バージョンであることもある
同じ録音でも、リマスターや編集、検閲などで異なる場合がある
MusicBrainz はこうした違いを細かく追跡し、同一録音かどうかを明確に区別している
カバー曲やスタンダード曲のように複数のアーティストが録音した場合は、
work単位で作曲者・作詞者の情報を結び付けているこのような 精巧なリレーショナルデータベース設計 は、創作物の同一性と差異を記録するのに非常に有用だと感じる
関連リンク
bookbrainz.org/about
MusicBrainz と似たスキーマなら、データ抽出は非常に容易になるだろうと期待している
アカウントを作ってデータを直接アップロードし、何度も修正した末に登録に成功した
中国のウェブサイトで同じオーストラリア盤 CD の情報を見つけて参考にしたが、市場ごとに微妙に異なるバージョンが存在することに気付いた
人々は「固有識別子」の更新にあまりにも無頓着だという点で、MusicBrainz チームに深く共感する
1987年版と1989年版（
Peace Train削除版）の UPC 番号が同一だった90年代半ばに中古 CD 店で削除前バージョンを探して苦労した記憶がある
残りは地域ごとにトラック数が異なる複数バージョンが存在していて混乱した
トラックごとのアーティスト情報を明示できる機能があれば、検索精度はもっと高くなったと思う
誤字修正程度の違いしかなくても区別が難しい
Wikidata は FRBR 互換の公開データベースで、ここ数年で書籍関連の品質が大きく向上した
例に挙がっていた小川洋子の ホテル・アイリス は、同じ作品ではなく 異なる翻訳版 だ
翻訳は原作とは異なる派生著作として見るべきだ
ただし一覧が混在しており、誤りも多い
OpenLibrary では1つの work にまとめ、言語と翻訳者情報を edition に保存している
現在の重複は、言語別の自動マージ過程で生じた問題のようだ
利用者が原作と翻訳版を一緒にたどれるようにするのが理想的だ
LibraryThing を勧める
Goodreads よりずっと良いと感じる
本の WEMI 構造(work, expression, manifestation, item) を区別することが重要だ
「ドン・キホーテを読んだ」は work レベルの話で、「自分の本にコーヒーのしみがある」は item レベルの話だ
州単位の読書大会で本を ISBN だけで管理していたため、生徒が見つけにくかった
そこで WorldCat の ISBN マッピングデータベース を使って、同じ内容の別 ISBN を結び付ける SQL JOIN を追加した
その結果、10年間で生徒たちは さらに100万冊以上 の本を読むようになった
Anna’s Archive は ISBN 関連データの整理に大きく貢献している
WorldCat を スクレイピングして活用しており、現在は ISSN（定期刊行物）データベースも構築中だ
ISSN は書籍に比べてかなり不十分な状態だ
Open Library は Brewster Kahle（Internet Archive 創設者）と Aaron Swartz の初期の仕事から始まったことを思い出した
関連ブログ
実際の書店で本を見て買ったものの、家に帰ると 同じ版をすでに持っていた ことがよくあった
ISBN で自分の蔵書リストを検索できていれば、こうした重複購入は防げたはずだ
個人プロジェクトで ISBNDB API を使った蔵書管理サイトを作った経験がある
タイトル検索時に大量の版、言語、製本形態が入り混じり、結果が非常に複雑だった
Jaccard 類似度ベースで結果を整理したが完璧ではなかった
OpenLibrary を代替候補として検討中だ
StoryGraph アプリは悪くないと感じる
AI 機能を避けたい利用者 に配慮したインターフェースが良い
検索機能も優れている
個人的には 2017 年以降使っており、脱オリゴポリー を目指して選んだ
ISBN には 出版社識別子 が含まれており、同じ本でも市場ごとに異なる ISBN を持つことがある
無料サービスなので国ごとに異なる可能性がある
したがって出版社名そのものが直接入っているわけではないが、構造上は識別可能だ