第64回「ライフログと生活環境」でも触れましたが、レシピシステムをずっと考えています。
インターネット上のレシピシステムは、『COOKPAD』『味の素レシピ大百科』『NHK今日の料理』などが代表的です。このうち、『COOKPAD』をターゲットにした『cookpadloger』と『firstCookPadViewer』をフリーで公開しています。
これはこれで悪くないのですが、レシピと料理の関係を考えると、
- レシピ
- 買い物
- 調理
- 食事
- ログの記録(外部のサービスではたとえば『FoodLog』)
というように、大きく5つほどの行程を考えることができます。
このうちレシピは、必ずしも『COOKPAD』からだけ得るわけではありません。雑誌を読んでいてふとレシピが気になったとか、テレビを見ていたとか、いろいろなところで情報を得るものです。
過去の日記を見ていて、同時期に同様のメニューをつくることもあります。たとえば筆者はけんちん汁/豚汁が大好物なので、秋になると頻繁にけんちん汁/豚汁を食べています。
このように入力がさまざまであると、問題になるのが表記のばらつきです。魚を例にすると、「さんま」をひらがなで書くかカタカナで書くかあるいは漢字で書くか、ということです。「さんま」「サンマ」「秋刀魚」「秋光魚」。最近では、環境の変化によって、「夏刀魚」と書くとかいう話も耳にしたことがあります。
そこでこれらを統一して検索するためには、表記のばらつきに対応した辞書が必要ということになるわけです。
デジタル書籍の検索
同様のことは、スキャナーを使ってデジタル化した書籍を検索する場合にも発生します。このようなデジタル化の場合、ふつうその書籍は文字ではなく、画像のかたまりになるため、基本的には検索することができません。これをどう扱うかは、たいへん難しい問題です。
たいへんむずかしいというのは、論理的にむずかしい面というよりは、物理的なむずかしさです。すなわち、よく行われているのは、OCRによって機械的にテキストを文字化する方法ですが、ご存じのように日本語の文字認識は99%程度、レイアウトや書体が複雑な場合には、この認識精度はひどく落ちます。
それをきちんと検索できる文字列にするためには、校正をする必要があります。筆者は、校正なしのOCRを文字化できたとは考えていません。きちんとした校正の手間は新規に入力するのに較べて大差ないのです。
それでは、全文を新規にテキストとして入力し検索可能にすればよいかというと、ここで問題となるのは入力の精度であり、OCRに較べればはるかにマシだと考えられますが、それにしても入力者のスキルによったり、かな漢字変換を通す場合には、かな漢字変換特有のミスがつきものです。
ここまでは物理的な、ある意味コストによって解決可能な問題ですが、さらに問題となるのは表記のばらつきです。
プログラムでの表記のばらつき
筆者は、プログラム初心者で、複数のC#の書籍を参考書として活用しています。それぞれで索引を引く場合に、この「表記のばらつき問題」に直面しています。
すなわち、「キーワード」を「キーワード」と書くか「keyword」と書くか、「メソッド」を「メソッド」と書くか「method」と書くかです。
これは先のサンマ問題と同じ問題で、単に書籍をデジタル化しても、解決しないと考えられます。サンマなら焼けば解決しますが、本を変える度に英語とカタカナで索引を調べ直してから該当のページに飛ぶという手間は、けっこう馬鹿にできないくらいめんどうなのです。
そこで、これらの問題を解決するために、表記のばらつき辞書を用意することにしました。検索のときには、この辞書を通してから検索することで、表記のばらつきに対応した検索できるようになります。
たとえば図は川俣晶著『究極のC#プログラミング 新スタイルによる実践的コーディング完全版』(技術評論社)の索引です。ここで、メソッド形式という項目は、methodでは引けないわけです。
任意の表記を追加して成長する辞書
単にOCRで読めばいいというものではない理由もあります。索引に追記した手書きの索引です。ここにあるように、「長い名前」とか、「プロパティ」のように、筆者自身が必要と思った項目を追記しています。
結局のところ、本を読む(本を引く/活用する)とは、その本から自分の身の丈にあったことを抜き出すことであるといえます。それは与えられた索引や本文だけでは足りず、自分で編集して追記していく以外にはないのではないでしょうか。
1冊の本にとどまらず、世界全体をというと大げさなので複数の本という程度にとどめたいと思いますが、複数の本を活用するためにも、自分なりに使える表記のばらつき辞書が必要なのだ、と考えます。
現在、レシピ辞書が150項目程度、プログラム索引辞書が700語程度の規模です。