8

eコード(電子出版コード)は、どのように運用されるべきか?

eコードってなんぞ?

先のエントリでInternational ISBN Agencyの中の人(当時)による、電子書籍の識別子にまつわる諸問題および、階層デザインの可能性について紹介しました。

さて、ひるがえって我が国ではどうでしょうか。JPOでは、電子書籍における識別子に、「電子出版コンテンツ流通管理コード(通称eコード。以下、こちらの略称で記述します)」を利用する(参照「JPO電子出版コード管理研究委、電子書籍の流通コードを策定」)という発表がなされています。

ISBNにおける「日本図書コード管理委員会」のような管理組織こそまだ立ち上がっていませんが、上記発表のようにJPO内で「JPO電子出版コード管理研究委員会」が準備されており、また、「コンテンツ緊急電子化事業」において作成された電子書籍への付番が決定していることから、日本の出版社においては、このコードを電子書籍における共通識別子として利用していくことはほぼ既定路線である、と見て良いでしょう。

なお、急いで補足しておくと、International ISBN Agencyの日本支部である「日本図書コード管理センター」は一貫してISBNを付番する、という方針を堅持しています。「eコード採用=日本では、電子書籍の識別子にISBNを一切使わない」ということではありません。そのようなことは一切明示されていませんので、誤解のないように。

では、ざっくりとeコードを概観してみましょう。

策定の経緯や詳細な仕様のドラフトについては現時点での一次資料「次世代電子出版コンテンツID推進プロジェクト」にあります(総務省やら書協やらのサイトにちらばっているので、「新ICT利活用サービス創出支援事業報告書関連まとめリンク – 思っているよりもずっとずっと人生は短い。」から辿るのが分かりやすいです。探しにくい、と文句を言う前に、なければ作るこの姿勢。見習いたいものです)。

まず、コードの仕様はJDCN(Japan Digital Comic Number)を前提に決められています。JDCNとは、講談社・小学館・集英社をはじめ、多くの「漫画を出している出版社39社(2012年6月現在)」が参加している「デジタルコミック協議会」が推奨している、電子書籍コミック用の共通コードです。既に多数の商品に付番されていることもあり、これをベースにすることを決めたようです。

なお、JDCNは現状、出版社と電子書籍取次間のEDIのためにだけ利用されているようで、webで検索した範囲では付番状況が公開されたり、また、(ISBNがそうであるように)JDCNを手掛かりに一般のユーザが本を探す、といった使い方はできていないようです。

次に、eコードの利用については、

  • コード案A(雑誌系)
  • コード案B(コミックを含む、書籍系)

の二案が提示されています。

●コード案A

AAAAAAA-@-BBB-CC-DD-EEEE-F

それぞれ、

  • AAAAAAA: 出版社(者)記号
  • @: 雑誌の場合の特有記号
  • BBB: シリーズコード
  • CC: 発行年数
  • DD: 号数
  • EEEE: 話番号、記事番号
  • F: チェックディジット

を表します。

「「雑誌の場合」の特有記号」と、一見書籍・雑誌を包括した案であるような印象を受けますが、号数が入ってたり、また、後者のB案がISBNの書名部分を含むことを想定した作りになっていることから、「雑誌に特化した識別子で、さらに記事ごとの販売を想定して、マイクロコンテンツごとに付番/親本との紐付けができるようにする」ということを全体として志向した案と思われます。

●コード案B

AAAAAAAA-BBBB-CCCCCCC-D

それぞれ、

  • AAAAAAAA: ISBN(出版社(者)記号+書名記号部分=8桁)
  • BBBB: 話割、記事番号 ※推奨項目
  • CCCCCCC: 各出版社(者)自由コード
  • D: チェックディジット

を表します。

「AAAAAAAA」がISBNからの流用だったら、雑誌はどうするの? という疑問もありますが、その場合は「雑誌にもISBNに準ずるコードを付与する」とあります。しかし、A案でたっぷり割り当てられていた、年数、号数といった情報をここに入れ込むのは、大出版社では多くの雑誌同士でコード領域の奪い合いになるでしょうし、小出版社では書名記号のケタが少ないので、これまた苦労しそうです。

「B案」が、よりJDCNに近似していることからも、「コミック・書籍」への付番を志向した案、と言えそうです。

●システム要件的な観点から

以下の2点を押さえておけば、とりあえずは十分でしょう(というか、これ以上厳密なことはほとんど「決定」していない)。

  • 20ケタ固定長(末尾1ケタをチェックデジットとして利用。計算方法は未定)
  • 0〜9A-Za-z-%$/+の66文字が利用可能

●簡単なまとめ

さまざまな調査報告をばっさりと捨象すると、

  • 雑協主導の実証実験で提案された、マイクロコンテンツを意識したいくつかの桁ごとの意味づけ(A案)
  • デジコミ協におけるJDCNとしての利用のなかで、出版社ごとにハウスルールとして決められてきた、桁ごとの意味づけ(B案)

の二案が提案されています。

こちらも補足しておくと、すでに「緊デジ」においては、この事業が「紙の本の電子化」であることを前提に、当該事業で作成された電子書籍に付番するeコードは、前半の8ケタにISBNの一部を充て、残りの桁はブランク(0で埋めておく)にしておく、という方針が出されています (参照→ 仕様書/フォーマットポリシー(確定版:標準化委員会作) )。

つまり、「緊デジ=B案採用」ということなのですが、A案がどのように決着するかは、現時点では不明です。

この「次世代電子出版コンテンツID推進プロジェクト【調査報告書】」からは、否応なしに増えつづけるアイテム、増えつづけるフォーマット/デバイス、増えつづける供給先をハンドリングするために、現場ではさまざまな工夫がなされていることが伺われ、「個々のアイテムを識別し、かつ関係性を明示する」ためのさまざまな提案がされています。つまり、私が以下、得々と書いていることは、現場で格闘されている方々にとってはすでに認識されている、「んなこたァわかってんだよ」的な事実、だったりします。

重要なのは、これら無数の技術的選択肢の得失を、「合意形成」「普及促進活動」といったステージにいる方々にうまく伝えることである、と考えています。

eコードによる識別は、「ユニーク」で、「つながりの明示」を保証しうるか?

前回のエントリで提示した、二つの原則です。ざっくりさらっておくと、識別子の役割として、

  • Disambiguation (すなわち、曖昧でない。ユニークである)
  • Collocation (すなわち、つながりが明示されている)

この二つを満たす必要があります。

eコードは、この二つを満たしているのか、という視点で見ていきます。

●まず一つ目の「ユニーク」の保証

これはもう、運用次第、ですね。現時点で提示されているうち、「次世代電子出版コンテンツID推進プロジェクト【調査報告書】」では、詳細な運用案が出されていますが、付番ルールは未だ決まっていません。「緊デジ」は「底本 : 電子書籍」が一対一対応なので結果、ユニークになります。しかし「緊デジ」の延長には「出版デジタル機構」とJPOによるeコード運用が想定されているはずですが、そこで出てくるであろう、「ボーンデジタル(紙の底本を持たない)な電子書籍」「複数の親本(底本)を持つ電子書籍」等のケースについては当然ながら言及されていません。

いずれにしろ、現状は「出版社が付番主体」という前提になっています。ISBNが(業界の人はご存知の通り)、出版社の努力目標として「重複なきように」運用されている結果、しばしば付番ミスや確信犯的な「ISBN使いまわし」が発生しているように、eコードも「衝突」を避けられない宿命にあります。

また、そもそも「何にコードを振るのか?」という点についても、「記事、目次、章・節、話単位」「巻、書籍、雑誌単位」「配信ファイル単位」「最少課金単位」……等意見が見事に割れており(前掲の調査報告書のP.154〜155参照)、まず「何をもってユニークとするのか」というあたりから議論を固める必要がありそうです。

この識別子が、第一義的には出版社と電子書籍取次の情報交換を効率化するものとして使われることを想定されている以上、妥当なセンとしては、「流通を「期待」するものには全て、「オブジェクト単位」で付番する」といったところだと思うのですが、実体ありきで回ってきた業界としてはなかなか受け入れがたいでしょう。

IDには物理IDと論理IDがあってだな……。」とか言い出すといろいろ問題がありそうなので、現時点では、最低でもファイル単位、フォーマット単位でとにかく細かく振る、という合意をしておく必要はありそうです。

●では、二つめの、「つながりの明示」の保証

こちらは、そもそも単一の識別子だけで話を進めること自体、ちょっと分が悪そうです。ISBN(の一部)を底本コードとして先頭に持ってくる、という方法が提案され、「緊デジ」ではこの方法で付番が始まります(そして、「緊デジ」が既存書籍のデジタルコンテンツへの一対一の変換事業である以上、とりあえず破綻はしない)が、「つながり」のあり方はさまざまです。ONIX for booksにおいて、ISTCの併用を想定して策定されているであろう「P.22.1 Work relation code」のコードリストを見ても、

01 Manifestation of

Product X is or includes a manifestation of work Y. (この製品Xは、ある作品Yを「形にした」もの。あるいはそれを含むもの)

02 Derived from

Product X is or includes a manifestation of a work derived from related work Y in one or more of the ways specified in ISTC rules. This relation type is intended to enable products with a common ‘parent’ work to be linked without specifying the precise nature of their derivation.(この製品Xは、ある作品Yの派生作品を「形にした」もの。あるいはそれを含むもの)

03 Related work is derived from this

Product X is a manifestation of a work from which related work Y is derived in one or more of the ways specified in ISTC rules (reciprocal of code 02).(この製品Xは、ある関連元の作品Yから派生した作品を形にしたもの)

04 Other work in same collection

Product X is a manifestation of a work in the same collection as related work Y.(製品Xは、ある作品Yの同じシリーズの作品を形にしたもの)

05 Other work by same contributor

Product X is a manifestation of a work by the same contributor(s) as related work Y.(製品Xはある作品Yの同じ著者の作品を形にしたもの)

が策定されており、「さまざまなつながり」を識別子の内部を区切っただけの仕様で表現するのは極めて困難です。
また、ここまで風呂敷を広げなくても、ボーンデジタルの電子書籍の場合は、将来的に紙の本を出す際の、使うかどうかわからないISBNを「先食い」することになりますし、底本が複数ある、アンソロジー的な電子書籍を作りたい場合はそもそも底本ISBNが一意に決められません。あくまでも実体のある「物」に付番することを前提として設計されたISBNを電子書籍の識別子にまるまる盛り込む、「底本ISBN」という考え方はきわめてスジの悪い仕様であることは明白です。

ユニークに振る、ことを徹底していくと、最低でも億の単位(百万点超の既存コンテンツが、分冊、フォーマット違い等で数十〜数百通りの識別子を持つ可能性を折り込むとすれば、これくらい必要です)で識別子本体の割り当て数を予約しておく必要がありそうですが、そちらに桁を確保してしまうと、今後は「つながり」を盛り込む部分の桁が不足しかねません。痛し痒し、です。

じゃあ、対案を。

ここで「先進的な取り組みをしている欧米では〜」と一席ぶちたいところなのですが、残念ながら私の知っている限り、ISBNの後継仕様としてスジのいい識別子+書誌情報スキームを運用できている国はないようです(おそらく、海外での電子書籍は垂直統合モデルが主流なので、外部と連携する共通識別子、というニーズが薄いのが最大の要因ではないかと思いますが、ま、それは別の話なんで措いといて……)。

現時点での情報技術ベースでは、

  • ユニークであり、個々のつながりを表現可能な複数階層(最低二階層)から構築され、さらに外部からの自由な参照が保証されている識別子
  • (「底本」概念をより抽象化した)「作品」概念と電子書籍識別子の紐付けによって、「関連性」の記述が可能な書誌情報スキーム

の二本立てによる書誌情報システムの設計・構築が最低限、必要ではないでしょうか。

前者は、ユニークに運用する方針、およびデータベースの公開をセットで実現できるのであれば、それこそeコードでも十分その役目は果たせるでしょう(実際の策定コストや国際標準とのすりあわせ、独自データベースの運用コストを考えると、DOIを使って登録料一冊あたりの登録コスト(レジストラ次第、コンテンツの内容と分量次第ですが、crossref.org : : publisher feesなどを見る限り、最大でも数$程度でしょう)支払った方がオトクな気はしますが)。

後者は、「実体のないものへの付番」という課題解決に向け、新しい概念として導入すべきだと考えます。こちらもゼロベースから構築するよりは、ISTCなどと連携しながら導入していくのがスマートではないかと思います。

実は、先に示したように、「関係性の記述」については、すでにONIX for booksでは想定済です。特に、ISTCについてはすでに仕様書において、関連書籍の表示サンプルで使われています(以下参照)。

[code lang=”xml”]<RelatedWork>
<WorkRelationCode>01</WorkRelationCode> ←「Manifestation of」を意味する。「製品Xは、ある作品Yを「形にした」もの」
<WorkIdentifier>
<WorkIDType>11</WorkIDType> ←ISTCを意味するコード
<IDValue>A022009000001BE9</IDValue> ←実際のISTCコード。ISTCのサイトで検索すると、「The Mystery of the Blue Train」であることがわかる
</WorkIdentifier>
</RelatedWork>
(ONIX for Books 3.0.1 Specification + Guide + Codelists Issue 17.zip – http://www.editeur.org/93/Release-3.0-Downloads/#Tag%203.0 内、 P.22 Related works内コードサンプルより)[/code]

このXML要素は繰り返し記述することが可能な上、<WorkIDType>を指定することによってどのようなコード体系でも利用できるので、識別子が複数ある場合でも柔軟に対応することができます。DOIでもeコードでも、もちろんISBNでも、なんでもこいです(というか、現状のコードリストでは、固有コード/ISBN/DOI/ISTC/ISRCが想定されています)。
製品自体のIDを<RecordSourceIdentifier>で指定し、関連作品(製品)を
<RelatedWork>内に記述することによって、製品とその上位概念を結ぶことも、製品同士の関連を記述することも可能です。
その上で、JPO+出版デジタル機構がこれら書誌流通情報の交通整理を引き受けて、一般読者、ならびに小規模流通に対しては基本無料公開、APIを膨大に叩いてくるような大口利用のみ課金、というモデルで回せばずいぶん風通しが良くなるのではないでしょうか。

私の守備範囲は書籍のメタデータに偏っているので、雑誌・コミック系の流通の現場にいる方々の知見を是非伺いたいところです。頭の痛い電子書籍の識別子導入問題ですが、それこそ、「奇貨居くべし」ではないでしょうか。

広く議論できれば幸いです。

関連してそうなエントリ

日高崇

8 Comments

  1. コード案Aって,ISBN が 978-4 を食い尽くしたあとはどうするつもりなんでしょうか?

  2. えーと、ISBNの話をされているということは、コード案B、の方を指していらっしゃるんですよね。
    ご指摘には、「せっかく979が予約されているのに……」、というお話も含まれていると思います。そこら辺を視野に入れて議論した形跡は見つけられませんでした。まあ、いろいろと現場合わせの部分が多い方式だとは思います。
    いろいろ見聞した結果、私は徐々に「電子書籍にはISBNを振るべき」派に転向しつつあるので(別にわざわざ転向しなくても、IIAはそのように仰っているんだから、eコードがどうであろうと、並列してISBNは付番すべきです)、まあ、いっぺんみんなでつけまくってISBNを喰い尽くすのも一興ではないか、と思っております。

    その上で、978-4がすべて使われたら……? その暁には「eコードが底本対応するのだ」、という前提条件を崩して割り当て直すしかないでしょうけど、実際に使われるかどうか、は市場が判断することですから、そこまでこの方式に寿命があるかどうか、ですかね。好意的に考えれば、その頃にはそもそも「底本」という概念もあやふやになっているかもしれません、けど。

  3. ご返事ありがとうございます。
    はい,「コード案B」と書くつもりで誤って「コード案A」と書いてしまいました。

    で,「978-4 が食い尽くされる」というのは,実際に書名記号まで使い尽くされるという意味ではなく,「978-4」以下の出版者記号がすべてどこかの出版者に割り当てられる,という意味です。
    こうなってしまうと,コード案Bの先頭8桁のすべてが,どこかの出版者が自由に使える番号空間に対応するわけなので,それ以上,新しい番号空間を確保することができなくなるんじゃないでしょうか。
    ん? そうか,先頭8桁にアルファベットを入れればいいのか。うーむ。

  4. 連投ですみません。
    業界の方々が「ISBNじゃダメ」と思われた理由は,平たく言うと「フォーマット違いや微細な改訂まで別番号にすると ISBN の番号空間はすぐに枯渇する」というようなことなんでしょうか?

  5. ここいらはちょっと難しい話になってきますね。

    「フォーマット違いや微細な改訂まで別番号にすると ISBN の番号空間はすぐに枯渇する」から、というのは一応、正しいです。ですが、そうだとすると、「では、なぜ欧米(特に米)で、電子書籍による枯渇、が発生、あるいは発生を見越した議論が隆興していないのか?」という疑問が生じます。

    ここら辺については近日別エントリを立てましょう。ゼロ年代の日本=電子書籍大国、ガラケー対応、あたりのキーワードで分かる人には分かる話なんですが、まあ、丁寧に説明した方がいいですよね。。

  6. 別エントリよろしくお願いします。どうやって調べたり勉強したりすればよいのか,困っていまして。

    コード案Bについてもう一つ疑問があります。底本が他社の印刷本だった場合でも底本の出版者記号を使うのでしょうか。そんなの運用できませんよね?

  7. ……こまっちゃいますよねw

    eコードについては、仕様から読みとれる論理構造ではなく、「出版社はどういう風に行動しているか」という風に考えると少し理解できます。つまり、A社の本をB社が文庫化したら、それはB社のISBNが付きます。巻末には底本についての記述が多少入るかもしれませんが、少くともISBN上ではA社とB社の「つながり」は表現しません(というか、できません)。

    電子書籍であれば、A社の(紙の)本をB社が電子化した場合、B社のISBNを振り出して、それに対応するeコードを付番することになります。ボーンデジタルな本や、「合本」やアンソロジーの電子書籍を作る、ということで底本が複数存在する場合も同様です。出版社から見た場合、それらは「新しい本」であり、つながりが表現できそうだから、といってそこに拘泥してしまうと、「筋の見えないクソみたいなシステム」という結論になってしまいます。ディスるのは簡単ですが、まあ長い付き合いになりそうなんで、ゆるゆると行きますw

  8. born-digital と同じ扱いなのですね。分かりました(多分そうかなと思っていました)。

    なんか,市場がどんどん動いているのに,コードすらまだ決まってなくて,コードの仕様案はあっても,こういうこと(978-4 のパンクや他社底本の話)がそこに書いてないのって,大丈夫なのかな。
    ふぅ。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です