タイトルや著者へ読みを付与する際の問題

[Yasuo Kida 🎿]

タイトルや著者によるソートを読みで行うためのプロパティに "file-as" があります。ソートが合理的で予測できる順番になるように、読みに落とすためのルールは重要だと思います。

その点、epubcafe の制作基本チュートリアルに「このチュートリアルでは，著者名の表記方法について，国立国会図書館の[書誌データ作成ツール]が定義する読みの付与基準を参考にしています（http://www.ndl.go.jp/jp/library/data/yomi.html）」と参考になる資料が示されているのはよいことだと思います。が、この資料のルールに気になる点がありました。一点は、このルールが現実的ではないように見える事、もう一点は、一般的なユーザーの期待と異なる排列になる事です。

分かち書きの指示

・現実的に、ここにある「分かち書き基準」に沿って分かち書きを行うには精通した人材と膨大な労力を必要するように思えます。既存のツールではこの通りになりません。これを精度よく処理する自動的なツールが開発できない限り、分かち書きは非現実的に思えます。また、正しい読みを生成するのみならず、分かち書きも正しい必要がある事は、自動化ツールの開発に負担となります。

http://www.ndl.go.jp/jp/library/data/wakati2008.html

ひらがなの綴りの変換

・ひらがなの綴りに対して、文字の単純な置き換えとは異なるルールを指定していること。『『JAPAN/MARC　MARC21フォーマット』における片仮名読み表記要領』の 1  において次のような変換を指示しています。

ア）旧仮名づかい てふてふ→チョウチョウ

イ）助詞「ハ」「ヘ」「ヲ」 こんにちは→コンニチワ

http://www.ndl.go.jp/jp/library/data/pdf/JM_MARC21revision_katakanayomihyokiyoryo.pdf

これらも、人手では非現実的で、また自動化ツールに旧仮名遣いの言葉を登録しておく必要があるなど、ツール開発の負担になります。

また、変換が精度よく行えたとして、一般のユーザーは「てふてふ」という書物を探すのに「ち」の欄を見るか、という問題があるように思えます。同じ問題は　ウ）で指示されている「ヂ・ヅ」の「ジ・ズ」への正規化にも言えます。また、3 イ）で指示されているキリル文字やギリシャ文字のラテンアルファベットへの翻字も期待に添うものではないでしょう。私は対応がわからず多分探せなくなります。また、ハングルは？ヘブライ文字は？と際限がありません。

自動化ツールの困難さ

上記における手間の問題を解決するような自動化ツールを開発するとして、それがどの程度の精度を達成できるかという問題があるように思います。このようなツールは形態素解析が中心的な処理になるのですが、日本語の形態素解析で最も困難な課題の一つが固有名詞の解析です。が、タイトルには頻繁に固有名詞が登場し、また著者名は固有名詞そのものです。

専門家のの使用する書籍データベースを作ろうとしているなら、書誌データのルールに会わせるのが合理的であるように思えますが、一般コンシューマーユーザーが使うためのインターフェースとしては問題があるように思えます。もっとユーザーの期待に近い、また、自動化処理が開発しやすく精度よく行えるようなルールが必要なように思えます。

例えば下のようなルールなら、もっと精度よく、作成時もランタイムでも自動的な処理がしやすく、またユーザーの期待に添った結果を出せるんじゃないでしょうか。

・分かち書きをしない。

・漢字以外は綴りのまま。

・文字種（全角など）の正規化を行う

・空白文字の正規化と掃除（例えば空白の連続）

・file-as は、対応する文字列の単純な変換である事。例えば、語の順番を入れ替えたり、新たな語や記号を付け足したり、削除したり、サブタイトルのために使ったり、タイトルの説明に使ったり、別名にしたり、しない。（これ、書かなくても当たり前のように見えますが、ここで「例えば」と挙げた例は全て iTunes の楽曲の読みに登場します。）

・など…

ご意見いただければ。

木田

[MURATA Makoto]

書誌情報ONIX日本独自変種では全角カタカナとしているぐらいで、明確な規定は
ありませんでした。あと、辞書の見出し語に対する読みについての規定がJIS X4081
にありますが、これは不統一な読み（たとえばズヅ）があってもなんとか検索するた
めのものでした。

読みを機械的に与えるための規則を作り、実効性のある"標準化"をただちに行うに
はどうしたらよいでしょう。メタデータ関係者がやってくれることは（過去の経験からして）
可能性はないでしょう。単純な規則が書ければ、いっそInternet DraftにしてRFCを
目指すか。W3C, OASIS, JISなどでは一年以上は先のことになるでしょうね。

そうだ、私が執筆することになっているIDPF公式EGLSガイドラインに入れてしまう
という手もあります。O'Reillyから秋に出ます。

村田

2012年5月17日 5:46 Yasuo Kida 🎿 <ki...@apple.com>:

--

Praying for the victims of the Japan Tohoku earthquake

Makoto

[Yasuo Kida]

> 単純な規則が書ければ、いっそInternet DraftにしてRFCを目指すか。

+1

協力します。

下に述べたのは排列用の読みの生成ですが、検索は検索で別の課題がありそうですね。

木田

[MURATA Makoto]

I-Dは最近も書いたので、ある程度は慣れてます。しかし、I-Dは英語
だけで書かないといけない（例すら出せない）のが辛いところです。
Atomの読みのI-Dでも「村田」と「ムラタ」を仕方なく&#x5165;とか
&#x30e0;で書きました。

IDPFへのsubmissionとするという手もあります。いままで前例はないで
すが、そんなものは作ればいいでしょう。

まず、規則を木田さんが英語で書いてみていただけません？

村田

2012年5月17日 8:49 Yasuo Kida <ki...@apple.com>:

[Yasuo Kida 🎄]

オッケー。たたき台を作ります。

iPadから送信

2012/05/16 18:14、MURATA Makoto <eb2m...@asahi-net.or.jp> のメッセージ:

[川幡 太一]

川幡です。

最初にOPACを使ったときは、この表記法にびっくりしたのですが…まぁすぐに慣
れました。

>> <53B121C3-8D0F-4A5B...@apple.com> で,
>> 木田さん は書きました.

> その点、epubcafe の制作基本チュートリアルに「このチュートリアルでは，
> 著者名の表記方法について，国立国会図書館の[書誌データ作成ツール]が定義
> する読みの付与基準を参考にしています
> （http://www.ndl.go.jp/jp/library/data/yomi.html）」と参考になる資料が
> 示されているのはよいことだと思います。が、この資料のルールに気になる点
> がありました。一点は、このルールが現実的ではないように見える事、もう一
> 点は、一般的なユーザーの期待と異なる排列になる事です。

多分、木田さんの課題は、(1) ある程度、file-as 属性に表記の揺れがあっても、
端末に依存することがない形で、比較・検索できるようにして欲しい、というこ
とと、(2) できるだけ、タイトルから file-as 属性は自動的に作れるようにして
欲しい、という２つに分かれるのではないかと思います。

で、多分、(1) についてはすでに規格として JIS X 4081 や、ISO/IEC 14651 が
あって（この中には正規化も含まれます）、これを「書誌データ」でも一般の人
が違和感なく検索できるよう、ある程度tailoring することはできるかもしれま
せんが、あまり規格から離れても追随できる端末は限られるのではないかと思い
ます。

(2) についても、書誌データの作成ルールが現在のようになった背後にある程度、
合理的な理由がある気がしていて、まずはこのようなルールになった背景も調べ
てみるのはいいんじゃないかな、と思います。素人考えですが、たとえば「蝶々」
の「ちょうちょう」というタイトルの本が、旧仮名遣いなら file-as が「てふて
ふ」になって、新仮名遣いなら file-as が「ちょうちょう」になって、ソート時
にこの２つの本の位置が離れるのは困ると思いますし、分かち書きについても、
たとえば「おおまめたいちろう」さんという人がいた場合、ソート時に「おおま
め・たいちろう」さんが、「おおまめた・いちろう」さんより前に来て欲しい、
という要望はあるんじゃないかな、という気もします。

日本語は表記と音の揺れが大きな言語だと思うので、タイトルから file-as を自
動生成するのは、（暫定で済むのでなければ）ある程度ツールの助けを借りても
本質的に難しく、それなりに本の製作者が汗をかかなければいけないものじゃな
いかな、と漠然と思っていました。

そもそも、一般コンシューマーの方が、「本のタイトルを付ける」機会がどれく
らいあるのか、特に、旧仮名遣いの本を作る機会がどれくらいあるのか、という
のもよく分かりませんでしたし…　

一方で、電子書籍のメタデータのfile-asがどうなっていたとしても、図書館の人
は電子書籍が納本された際、黙々と書誌ルールに従って本のタイトルをつけ直し
てデータベースに納め、結果として図書館のOPACを検索するときにはどちらでも
検索できるようになるのかもしれない、とも思います。

> 専門家のの使用する書籍データベースを作ろうとしているなら、書誌データの
> ルールに会わせるのが合理的であるように思えますが、一般コンシューマーユー
> ザーが使うためのインターフェースとしては問題があるように思えます。もっ
> とユーザーの期待に近い、また、自動化処理が開発しやすく精度よく行えるよ
> うなルールが必要なように思えます。

> 例えば下のようなルールなら、もっと精度よく、作成時もランタイムでも自動
> 的な処理がしやすく、またユーザーの期待に添った結果を出せるんじゃないで
> しょうか。

> ・分かち書きをしない。
> ・漢字以外は綴りのまま。
> ・文字種（全角など）の正規化を行う
> ・空白文字の正規化と掃除（例えば空白の連続）
> ・file-as は、対応する文字列の単純な変換である事。例えば、語の順番を入
> れ替えたり、新たな語や記号を付け足したり、削除したり、サブタイトルのた
> めに使ったり、タイトルの説明に使ったり、別名にしたり、しない。（これ、
> 書かなくても当たり前のように見えますが、ここで「例えば」と挙げた例は全
> て iTunes の楽曲の読みに登場します。）
> ・など…

--
---------------------------------------------------------------------
川幡 太一 (kawabat...@gmail.com) KAWABATA, Taichi

[MURATA Makoto]

川幡さん、

まず、

> 一方で、電子書籍のメタデータのfile-asがどうなっていたとしても、図書館の人
> は電子書籍が納本された際、黙々と書誌ルールに従って本のタイトルをつけ直し
> てデータベースに納め、結果として図書館のOPACを検索するときにはどちらでも
> 検索できるようになるのかもしれない、とも思います。

というのがいちばん本質的でしょうね。つまり、EPUBの中に埋め込む
メタデータは本当に使うの？どうせ、著者・出版社ごとに書き方が異なる（読み
の問題だけではなく）ことになって、一覧を作るのにもやりにくいのでは？
それより、オンライン書店や図書館で統一的につけるほうがまともな
ものができるのでは？

いっぽう、今後は出版社を通さない本が増えるのだとしたら、著者がつける
メタデータで探すしかないのではという気もします。つまり、EPUB内のメタデータ
に多少問題があろうが、それを使うことになっていくのではとも思います。

ということで、私には答えが出せません。おそらく、誰も出せないのではないかと
思います。使われることはあるという前提で進むしかないでしょう。

> 最初にOPACを使ったときは、この表記法にびっくりしたのですが…まぁすぐに慣
> れました。
>
>>> <53B121C3-8D0F-4A5B...@apple.com> で,
>>> 木田さん は書きました.
>
>> その点、epubcafe の制作基本チュートリアルに「このチュートリアルでは，
>> 著者名の表記方法について，国立国会図書館の[書誌データ作成ツール]が定義
>> する読みの付与基準を参考にしています
>> （http://www.ndl.go.jp/jp/library/data/yomi.html）」と参考になる資料が
>> 示されているのはよいことだと思います。が、この資料のルールに気になる点
>> がありました。一点は、このルールが現実的ではないように見える事、もう一
>> 点は、一般的なユーザーの期待と異なる排列になる事です。
>
> 多分、木田さんの課題は、(1) ある程度、file-as 属性に表記の揺れがあっても、
> 端末に依存することがない形で、比較・検索できるようにして欲しい、というこ
> とと、(2) できるだけ、タイトルから file-as 属性は自動的に作れるようにして
> 欲しい、という２つに分かれるのではないかと思います。
>
> で、多分、(1) についてはすでに規格として JIS X 4081 や、ISO/IEC 14651 が
> あって（この中には正規化も含まれます）、これを「書誌データ」でも一般の人
> が違和感なく検索できるよう、ある程度tailoring することはできるかもしれま
> せんが、あまり規格から離れても追随できる端末は限られるのではないかと思い
> ます。

(1)についてはその通りだと思います。JEPAのリファレンス委員会でまとめている
規則を、このメールに添付します。

> (2) についても、書誌データの作成ルールが現在のようになった背後にある程度、
> 合理的な理由がある気がしていて、まずはこのようなルールになった背景も調べ
> てみるのはいいんじゃないかな、と思います。素人考えですが、たとえば「蝶々」
> の「ちょうちょう」というタイトルの本が、旧仮名遣いなら file-as が「てふて
> ふ」になって、新仮名遣いなら file-as が「ちょうちょう」になって、ソート時
> にこの２つの本の位置が離れるのは困ると思いますし、分かち書きについても、
> たとえば「おおまめたいちろう」さんという人がいた場合、ソート時に「おおま
> め・たいちろう」さんが、「おおまめた・いちろう」さんより前に来て欲しい、
> という要望はあるんじゃないかな、という気もします。
>
> 日本語は表記と音の揺れが大きな言語だと思うので、タイトルから file-as を自
> 動生成するのは、（暫定で済むのでなければ）ある程度ツールの助けを借りても
> 本質的に難しく、それなりに本の製作者が汗をかかなければいけないものじゃな
> いかな、と漠然と思っていました。

国会図書館のルールはプロ中のプロしか使えなくていいという
規則のつもりで作っていると思います。そういう前提のもとで作られた
ルールと、著者や出版社でも使える規則はぜんぜん違うことに
なるのは仕方がないのではないでしょうか。国会図書館のルールに
はもちろん合理性・理由はあると思いますが、そのまま採用する
という理由にはならないでしょう。近刊情報センターも。読みについての
規則をどうやら持っていないようですね。

そして、ほかの図書館でもどこまで統一したデータを持っているか？
総務省のメタデータ事業の委員会に出席して質問してみた感触から
すると、実際のデータは相当にめちゃくちゃではないかと思います。
検索のときの自然言語処理で頑張っているようです。

結局、私の意見は、

- EPUB内のメタデータは使われると仮定して進むしかない

- 検索・ソートのときはどうせ多少の処理が必要だろう

- 著者や出版社で指示できる簡単な規則は必要だし、
国際の場に出された規則である必要がある

ということで、簡単な規則を作ることを支持します。

正直、私はメタデータ屋さんが「読み」に関して、きちんとした国際標準化
をしてくれる可能性はまったくないと思っています。

村田

[Yasuo Kida 🎿]

川幡さん、

確かに課題が二つあります。一つは、このルールで file-as を作ってそれでソートすると一般コンシューマーユーザーにとって驚きのソート順になってしまうことです。それをなんとかしたい。

もう一つは、より品質の良い揃ったデータになって欲しいということです。結局これも、誰にでも予測容易な排列を達成するという目的に帰着します。そのために、ルールが簡単である必要があります。ルールが複雑だと、人手で行うに、より難しく、間違いが発生しやすく、また自動化ツールも開発しにくいのです。

本を著作する際に著作者や専門家である編集者がメタデータを作る、と言ったシナリオではルールさえシンプルなら、比較的間違い少なくデータをつけることができるでしょう。しかし、例えば今までに日本で出版された書籍の 1/100 の量を電子書籍にしようじゃないか、とか、その手の作業ではエラーになりそうなところは全体で見ると必ずエラーになります。

> たとえば「おおまめたいちろう」さんという人がいた場合、ソート時に「おおま
> め・たいちろう」さんが、「おおまめた・いちろう」さんより前に来て欲しい、
> という要望はあるんじゃないかな、という気もします。

これはまさに仰る通りだと思います。この点は分かち書きを行う大きな利点だと思います。著者名だと十分可能のように思えます。

ただ、タイトルを含め一般的なテキストに対しては一般のユーザーや子供に十分予測できる分かち書きは存在しない思っています。これは、日本語が分かち書きをしないからです。誰もが考えずとも正解できるような分割がないのです。英語だとスペースがありますので、100% 誰もが語を数えられて即答できますね。San Francicso とか nevertheless が一語か二語かなんて悩む人はいません。でも「東京都庁」は何語？「られますよね」は何語？100%誰もが簡単に正当できるでしょうか？　そもそも正解はどのようなルールで「語」を定義するかに依って複数あり得ます。わかりにくいこと、正解が複数あること、間違えやすいこと。これらの理由で分かち書きを要求すると予測容易な排列にならないと思います。

ところで、話題がずれますが、面白い例に「充電池」があります。まあ、これは一語ですよね。でも検索の際には、これは電池なんですから「電池」とマッチして欲しい雰囲気があります。「充電」+「電池」の二語が縮退してしまっているので、二語に分けようがないのですが、二語の雰囲気が強く残っています。語の範囲が重複してはならないなんて誰が言った？と言ってこれを「充電」と「電池」の二語に分けるのもアリかも知れません。

木田

[川幡 太一]

川幡です。

>> <CALvn5EDvMKNZs6bB_DC4WmHb...@mail.gmail.com> で,
>> 村田さん は書きました.

> いっぽう、今後は出版社を通さない本が増えるのだとしたら、著者がつける
> メタデータで探すしかないのではという気もします。つまり、EPUB内のメタデータ
> に多少問題があろうが、それを使うことになっていくのではとも思います。

結局は、ある程度のメタデータの表記の揺れは想定して、それを端末が検索・照
合時に許容できるようにした方が良いかと思います。

> > で、多分、(1) についてはすでに規格として JIS X 4081 や、ISO/IEC 14651 が
> > あって（この中には正規化も含まれます）、これを「書誌データ」でも一般の人
> > が違和感なく検索できるよう、ある程度tailoring することはできるかもしれま
> > せんが、あまり規格から離れても追随できる端末は限られるのではないかと思い
> > ます。

> (1)についてはその通りだと思います。JEPAのリファレンス委員会でまとめている
> 規則を、このメールに添付します。

すみません、JIS X 4081とJIS X 4061を間違えていました。

> 国会図書館のルールはプロ中のプロしか使えなくていいという
> 規則のつもりで作っていると思います。そういう前提のもとで作られた
> ルールと、著者や出版社でも使える規則はぜんぜん違うことに
> なるのは仕方がないのではないでしょうか。国会図書館のルールに
> はもちろん合理性・理由はあると思いますが、そのまま採用する
> という理由にはならないでしょう。近刊情報センターも。読みについての
> 規則をどうやら持っていないようですね。

分かち書き等は確かに大変だと思います。ただ、数少ない明文化されたルールで
はるので、この表記法「も」使っても良い、程度には言ってもいいと思います。

> 結局、私の意見は、
> - EPUB内のメタデータは使われると仮定して進むしかない
> - 検索・ソートのときはどうせ多少の処理が必要だろう

端末の国際化を考えると、この「検索・ソート時の処理」はISO/IEC 14651・UCA
の範囲で収まるようにした方が良いかもしれません。

> - 著者や出版社で指示できる簡単な規則は必要だし、
> 国際の場に出された規則である必要がある

> ということで、簡単な規則を作ることを支持します。

一応、Unicode照合アルゴリズム（UCA）の枠組みでの日本語の文字列の照合ルー
ルは CLDR にまとまっています。

http://unicode.org/cldr/trac/browser/tags/release-21-0-1/common/collation/ja.xml

村田さんの添付されたファイルをざっと見るかぎり、これを多少、修正する程度
でいける気がします。（細かく検証はしていませんが…）

>> <3302F65D-A0B8-44A5...@apple.com> で,
>> 木田さん は書きました.

> 本を著作する際に著作者や専門家である編集者がメタデータを作る、と言った
> シナリオではルールさえシンプルなら、比較的間違い少なくデータをつけるこ

> とができるでしょう。しかし、例えば今までに日本で出版された書籍の 1/100
> の量を電子書籍にしようじゃないか、とか、その手の作業ではエラーになりそ
> うなところは全体で見ると必ずエラーになります。

そのような場合こそ、手入力よりは既存の情報資産を使った方がよいと思います。
既存の文献のJPNOかISBNかタイトルがわかれば、その読みは下記のようなクエリ
で取得できます。

（以下はJPNOが85026435の本のデータを取り出す例。）

http://iss.ndl.go.jp/api/sru?operation=searchRetrieve&recordPacking=xml&recordSchema=dcndl&query=(jpno=85026435)