OPDSのメタデータにヨミを入れるためにはどうすべきか　の議論のまとめ

@ryojin3 当然読みのためのデフォルト要素はありませんがXMLなので拡張可能というあたりはEPUBと同じですね。 @kzakza

2012-02-22 11:38:37

@lost_and_found @ryojin3 ヨミをいれるならば、DC-NDLやONIX日本仕様などの語彙を利用して拡張する必要があります（ONIX日本仕様が拡張に使えるかわかりませが・・・。名前空間ない？）。OPDSで入力できるメタ項目ってかなり簡易なんですよね。

2012-02-22 12:19:37

@lost_and_found @ryojin3 台湾では拡張していないのか、気になるところです。どう拡張しているのか、そういう情報は今のところ、見つかってません。

2012-02-22 12:20:53

ryojin3 @ryojin3

@kzakza @lost_and_found DC-NDLの部分利用はいいですね。ONIX日本仕様、ざっと見てみたら名前空間指定してないですね。フローは国際準拠だと聞いたことがあります。

2012-02-22 12:34:56

@kzakza EDItEURのONIXは、HTMLのrubyを使って読み情報を入れるという方針で出来ています。ただし、JPO 近刊情報センターのONIX http://t.co/u4KY792g は日本独自拡張です。

2012-02-22 12:45:31

@kzakza @lost_and_found @ryojin3 OPDSは、Atomがベースで、あちらにも読みは入ってませんよね？私が気付いていないといけなかったのかも。やるのなら、AtomごとIETFで直す。

2012-02-22 12:48:22

@muratamakoto 本家のONIXでヨミをいれることを想定しているのですね。それは存じませんでした。ruby要素使うのですのですか。ちょっと見てみます。

2012-02-22 12:50:00

オフィス文書フォーマットOOXML(OPC)では、「読み」を入れる方法はない。オフィス文書フォーマットODFでは、「読み」を入れる方法は規格にはなく、実装依存の方法が用いられている。

2012-02-22 12:51:41

@muratamakoto @lost_and_found @ryojin3 OPDSにはヨミについて特に規定してませんが、あの仕様の書き方だと必須項目等々とAtomとDCTERMSの項目がバッティングする場合はAtomを優先せよとかいてある程度です。（続く）

2012-02-22 12:55:12

@muratamakoto @lost_and_found @ryojin3 (続き)OPDSに限って言えば、OPDSのメタ項目がAtomに縛られているわけではないと思います。

2012-02-22 12:55:56

メタ項目にHTMLのruby要素を使うのか。どんな感じだろう。

2012-02-22 12:57:03

@kzakza @lost_and_found @ryojin3 縛られてはいないかも知れませんが、Atomで決めているタイトル等の読みだけをOPDSで決めるのはやはり変ですね。どうAtomを直すべきか簡単に合意はとれますか？ONIXと同じようにrubyでやるのならすでに可能？

2012-02-22 13:08:44

@muratamakoto Atomは拡張可能なシンプルさが美点だとも思いますし、そこまで切り込むと時間が掛かりそうな気がします。読み情報が欲しいと考える一握りの人たちの間で拡張方法を共通化できれば十分ではないでしょうか。 @kzakza @ryojin3

2012-02-22 13:33:04

@muratamakoto OPDSは配信が主眼であり、モバイルでも受信できる軽さも重要です（詳細に記述することもできますが）。ONIXのようにメタデータのマスターとして活用する類のものではないと思います。@kzakza @ryojin3

2012-02-22 13:37:34

@lost_and_found @kzakza @ryojin3 そう、atom+opdsはonixより遥かに軽いでしようね。

2012-02-22 13:46:13

ryojin3 @ryojin3

@lost_and_found 概ね同意ですが、配信にはタイトル・著者名・出版社名、及びこれらの読みは最低限必要かと思います。その意味でAtomを見直すのもありかと。現状の仕様で対応可能なら問題ありません。@muratamakoto @kzakza

2012-02-22 13:47:56

@ryojin3 タイトルを読みで検索してヒットした本をダウンロードするシナリオを考えてみます。ユーザが検索ワードを入力すると、アグリゲータがOpenSeach記述文書に従って検索エンジンに問い合わせ、結果をOPDSで受信します。 @muratamakoto @kzakza

2012-02-22 13:51:46

@ryojin3 この場合、検索エンジンのDBに読み情報があり、該当する出版物を探せることは重要ですが、出力されるOPDSに読みが含まれていようがいまいがどちらでもよいのではないですか。 @muratamakoto @kzakza

2012-02-22 13:52:26

@lost_and_found @kzakza @ryojin3 結局、日本で使う実装を作る人達に受け入れて貰おうとすると、どうせ手間はかかりますよ。なお、中国、香港、台湾は、一つの漢字に読みが一つしかないらしく、日本のようにこの件にこだわってはいません。

2012-02-22 13:54:41

文書のメタデータの話をしているので29500-1ではなく29500-2です。 RT @_sww_: @muratamakoto ISO/IEC 29500-1 18.4.6 rph は「読み」ではないのですか？文脈を私が間違っているかも知れませんが。 *Tw*

2012-02-22 14:40:48

@lost_and_found そういうシナリオはもちろんあるでしょうが、OPDSで出されたカタログを集積し、その中から探すという検索はどうします？

2012-02-22 14:45:30

@muratamakoto おっしゃるとおりクローラを介してのカタログ再構築には対応できませんね。

2012-02-22 14:49:13

ryojin3 @ryojin3

@lost_and_found 昨年台湾で聞いた学校等の機関をつないだ話を国内B2Bに置き換え、版元や取次、書店をつなぐのに最低限必要なコンテンツ管理のためのデータセットという観点で考えていました。ユースケースはいろいろありそうですね。@muratamakoto @kzakza

2012-02-22 15:20:27