なにか数日前より、いきなり OPDS 絡みの話が湧き上がってきた。
ろすさん ( @lost_and_found )が、 3月15日 第7回 JEPA EPUBセミナー ~EPUB3.0最新動向~ とか 「電子書籍元年」から3年目に考えていること みたいなことを表明したからでしょう。
さすが電書ちゃんのツンデレ人気はすご…
どちらにしても、コンテンツ本体(含むフォーマットやビュワ)でなく、コンテンツの配信に問題意識を持つ人が増えるのは、望ましいことだと思います。
関連は @kzakza さんが ここ数日のOPDSに関するTweet や OPDSのメタデータにヨミを入れるためにはどうすべきか の議論のまとめ などにまとめてくれている。
Facebook上で、OPDS.JP というグループもできた。
で、OPDSのメタデータとしての書名や著者名などの読みについて、話がでてたので自分なりの意見表明を。
読みをどうOPDSに組込むかという話で村田さん( @muratamakoto )が、 ONIX for Books なんかでは、要素や属性を追加するのではなく、htmlのルビで表現するという方向でいくことになっているという発言をしていた。(上記 まとめ参照)
もう相当昔になるが、以前、某所で OPDS の評価を行なった際、国内での利用だと、まず読みなどの項目がないだろう、という話をしました。
この時は、私は DC-NDL (ダブリンコアを国会図書館が拡張したもの)などの項目を OPDS のフィードに対して namespace を指定して付加するのがいいんじゃないか、と提案した。
多分 title や name に属性を付けるのが、一番てっとりばやい気がするんだけど、それだと勝手拡張になってしまう。
namespaceを指定した上で、独自に要素を追加するのが次善の策だが、 OPDS が不特定多数のOPDSの利用ツールによって使われることを想定すると、すくなくとも国内ではある程度デファクトで使われないとヤッテラレナイ。
もともと、OPDSにはダブリンコアの要素を足りない部分では使うという推奨があるので、なら国内向けに拡張され、すでに公開されているDC-NDLの要素をそのまま使うのが、受けいれられやすいだろう、という発想だった。
で、今回の一連の tweet で、はじめて HTMLルビとして読みを入れるという規格があるということを知りました。これまで全然意識したことがなかったので、ちょっとビックリした。
提案
読みを実装する際には、XMLのnamespaceを指定した上で、専用の要素に読みのデータを入れることを提案したい。
読みの要素としては、すでに存在するDC-NDLを利用することを提案したい。
HTMLルビを利用した読みの実装について
私は、以下の理由で HTMLルビの利用には反対です。
- 「読み」は親の項目(titleなど)に付随するデータではあるが、親の項目とは異なるメタデータだと思う
- 実装上の問題の可能性がある
特に、実装上の問題については、色々な観点から不安があります。
HTMLルビで入れるという方法は、要素や属性の追加がないというのが、一番のメリットだと思う。
しかし、結果として、以下のような問題がでるような気がします。
- titleなどを、そのまま利用して検索、ソートをするシステムでは、タグなどが意図しない処理操作対象となるため意図しない結果となる
- OPDSのフィードは、処理系からすると外部入力になる。セキュリティ上の観点からは、タグのエスケープなどをする必要がでてくると思われるが、HTMLルビを読みとして利用することになれば、単純にタグをエスケープしただけでは表示がおかしくなる。HTMLルビ(ないし、生かすべきHTMLタグ)だけ特別処理をするようなシステムが、読みを必要としない処理系でも必要になる
- title本体、title読みなどの項目にアクセスする為に、ある程度複雑な正規化処理(ルビタグの付けかたに依存しない読みデータの抜き出しルーチン)が必要になる
これらの影響は、本来読みを必要としない言語系のシステムであっても、読みが組みこまれたOPDSフィードを扱う時には問題が顕在化する。
読み用の要素を拡張する読みの実装について
既存の処理系や、本来読みを利用しない処理系に対してのインパクトがすくないというメリットがある。
本来の規格(OPDSなり、ATOMなり)に、元々読みの要素か属性を追加するというのが、一番すっきりして問題ないと思う。
しかし、村田さんの話にもあるように、元々利用する必要性のない人にそれらの話を納得させるのは、なかなか容易ではない。
さらに、実際の所はなんとも言えないが、中国なんかでは読みはほとんど求められていないらしい。断言はできないが、これほど読みを必要とする言語環境は、日本語くらい? そういう意味では、日本語の為に他に与える影響はすくない方がいい。
OPDSはもともとATOMに毛が生えたような仕様で、書誌として規定されている項目はごく僅かです。その為、必要ならダブリンコアの要素を使ったらいいと規格にもかかれている。
XMLのnamespaceを利用した拡張は、それほど悪くない方法ではないかと思っています。
ただし、規格に規定されていないので、フィードにより読みの表現がバラバラになってしまう可能性がある。OPDSの処理系は、多数のフィードをハンドリングする必要があるので、この問題はかなり致命的。
幸い、OPDS、特に国内でのフィードの実装はそれほど進んでいない。今の内、関係者が納得しやすい方法で、デファクトの指定を決めてしまうのが、一番てっとり早いと思う。
また、この方法だと、読みに特別対応していない環境へのインパクトがすくないのはメリット。
対応していない環境では、要素が読み捨てられるだけですむ。
フィードを保存する時、対応していない要素などが捨てられちゃうんじゃないかという懸念はありえると思う。
しかし、元々フィードを読んで、内部的なDBに展開する場合、titleやidのようなものは1 vs 1に対応したフィールドが用意されると思うが、ダブリンコアの要素などは対応したフィールドがDB上に用意されるとは想定しにくい。
エントリからメタ情報を落さない為には、EntryのXMLそのものか、その構造をある程度保存した生のentry情報に近いデータ(JSONなんかでもいいけど)を保存する必要があるだろう。こういう作りになっていれば、読みに対応していない処理系でも、entryから情報が脱落する可能性は低くなる。逆に、そういう情報になっていなければ、読み以外のダブリンコアや、独自に追加した要素や属性の情報はどうしても欠落してしまう。
こうしてみると、メタデータが欠落する可能性は処理系の作り次第だが、既存のシステムや読みに対応しないシステムへの影響は、要素を追加したほうがすくないと考えられる。
補足
えっと… なんかBLOG記事にまとめようなんて書いてたら、高橋さん( @takahashim )と村田さんあたりで、すでに話されてますね…
まあ折角書いたので、恥しながら公開しておくことにします。
色々と素人なんで、勘違い等はあるかもです。びしっと間違い指摘された、その都度補足していくことにします。