難点、苦労

各学会が選定する標準和名の調査

達成目標

• 「公式な」和名である標準和名が存在する場合、それらは全て集める。
  
• 各学会において標準和名を選定済みか、選定中か、あるいは取り組んでいないか等を調べる。
• 選定済みの標準和名を収集する。
  

紆余曲折

• 過去の議事録等の調査

  個々の学会に、和名等に係わる委員会が存在するか、過去の議題で和名に係わる事柄が取り上げられた事があったか、等を読み直す。

書籍の電子化

達成目標

• 標準和名が選定されていない場合、 web や書籍などから集める。
  
• 書籍の内容を勝手に端折ることなく、全てをデータ化する
• データの正確度は99.8%以上

紆余曲折

• 書籍の分解

  以前は、以下の手順で分解していました。

  • 1. 背に沿って表と裏の見返しをカッターで切断する(表紙を除いた中身が得られる)
  • 2. 中身は綴じ代部分をカッターで少しずつ切り落とす

  このやり方では、カッターによる切り屑が出たり、切りすぎたりするなどの問題がありました。
  しかし、書籍の綴じ代部分をよく観察してみると、以下の特徴があることに気がつきます。

  • 8ページほどの小冊子の束でできている。
  • 小冊子の中心ページを開いて、のどの部分を見ると、糸が見えて背に縫いつけられている。
  • 接着剤も用いられているが、接着剤による固定は見返しと表紙の間を除けば、あまり強くはない。

  これを踏まえて、以下の手順で分解すると、比較的楽にできることがわかりました。

  • 1. 見返しと表紙の間の接着剤を慎重に剥がす。
  • 2. 小冊子ごとに掴み、背から引きちぎる。（縫いつけの糸を引きちぎる）
  • 3. 小冊子の綴じ代部分を裁断する。

  紙の薄い本や、小型の書籍ではうまくいかないと思いますが、大型の辞典などではこの方法でうまくいきます。

   

• OCRによる読取文字化けがひどすぎるため、確認作業が大変。特にラテン語表記部分やウムラウト記号などの特殊符号付きのアルファベットが不正確となる。この画像は、日本語と英語が混在する文書のOCR読取の例です。
  

  • 原文 [環境省　「移入種（外来種）への対応方針について」の「資料１b 我が国の移入種（外来種）リスト（本文）」]※原文は画像ではなくテキストデータですが、例を示すために一度画像にしてOCRの入力としています。

    

  
  

  • 日本語として読取(アルファベット部分の文字化けがひどい)

    

  
  

  • 英語（アメリカ）として読取(カタカナ部分は文字として認識されず、画像のままになっている)

    

  
  
• 打ち込み作業の外注

  仕様書に「入力精度は99.8%以上」と条件を付けることにより、正確度を確保できる。しかし、仕様書の作成そのものに難点がある。

  • 書籍内の書式パターンの洗い出し

    仕様書に明記していないことを独自に判断されては困るため、作業指示を漏れや曖昧さの無いように書く必要がある。また、実際の作業が単純操作の繰り返しになるようにし、且つ読み取り位置や書き込み位置の判断などを避けて、作業の大半が打鍵のみになるように心掛ける。
    
    この画像は字下げの情報を正確にテキスト化する必要がある事と、その情報を曖昧さなく読み取る為の指示内容を把握する為の例です。赤い縦線を基準線とします。青い二重横線の長さは一致しており、つまり青い縦線の字下げ位置が同じ深さになります。補助線がない場合、ページを跨った際の字下げ位置が曖昧です。実作業の指示として、赤い縦線の位置からのずれを物差しで測って、字下げ情報を正確に読み取るように指示します。また緑の縦線の位置の例の通り、フォントの違いの情報も読み取る必要が出てくることもあります。それらの情報の内の、読み取る必要がある情報だけを残していき、最終的には作業を効率よく進められる手順を仕様書に指示書きします。
    大抵の場合は、書籍に記述されている凡例を参考にし、指示を書ける。しかし、多くの書籍には凡例には記載されていない例外的な表記も多く含まれる。また、凡例すら記載されていない書籍もある。凡例に記載されていない部分は、不定形なものや、同一表記でありながら、場所によって解釈・意味が異なると考えられるものが多い。この画像は魚類に関する書籍のページの一部だが、和名と思える「イトヨ」の前に「降海型」、「陸封型」などの接頭辞が付いている。また学名の後ろに「;」で連結されて「anadromous form」、「land-locked form」という注記のような英語が記載されている。これらの記述をどのように読み取るべきかを判断して、仕様書において指示する。
     

• 納品物の確認と訂正、ならびに補正
  仕様書に指定された通りの書式になっているか確認して、誤りがある箇所を訂正する。
  外注時の仕様は、テキスト化作業の効率化のために打鍵しやすい書式で出力させてある。そのために、その書式のデータを更にスクリプト等で構文解析が必要となる場合もある。その場合には、構文解析用のスクリプトを実装してデータを読み取る。
  
• 手入力による打ち込み

  書籍のレイアウトがあまりにも不定形で、打鍵スピードが重視されるテキスト化外注には適していないものについては、プロジェクトメンバー内で打ち込みを行う。その際、正確度の確保が問題になる。

  • 正確度の算出

    打ち込んだデータの正確度を求める必要がある。入力内容が正しいかどうかを検証するにはあまりにもデータの量が多すぎる。また、確認作業での見逃し率も不確定なので、正確度は曖昧なままとなる。

    そこで、打ち込み作業を二人の人間で独立に行い、二人の入力が異なる部分を検証することにより、正確度を計算する。

    正確度の導出は テキスト化/手作業での入力精度.ppt を参照。
    この導出法により、目標の正確度が得られない場合は、独立に入力する人数を増やす必要がある。

一次データベースへの保存

達成目標

• 様々なデータ書式に対応できる汎用的な構造
• 作業担当者の解釈を混ぜ込まない

紆余曲折

• 列名のような一種のメタ情報をデータとして保存
  情報源においてデータを記載していた「列名」をデータとして扱って、一次データベースに保存する。列の数や種類が情報源ごとに様々に異なっていても、データとして保存できるのでその変化に対応できる。
  
• 原稿通りの記載を維持
  列名や情報源自身のメタ情報、およびその項目名なども含めて、全ての記載内容を原稿に記載されていた通りのテキストを保存する。作業の担当者による勝手な読み替えなどを行なわない。意味の解釈などは、必要であれば後続の作業ステップに於いて実施することにして、一次データは情報源の保全を優先する。
  

収集したデータの公開

達成目標

• データの信憑性の確保
• 利用者にとって可能な限り、わかりやすいものにする
• すべてのデータを同一の書式で表現する

紆余曲折

• データの信憑性

  辞書構築を行っている作業者は、このプロジェクトで取り扱っている分野の専門家ではないため、情報の由来を明確に表記する必要がある。情報の由来が無ければ、このプロジェクトにおいて独断で宣言しているだけのものとみなされるので、利用者からみたデータの信憑性は皆無となる。

• データの利用価値

  データの源泉となる情報源は複数あり、そのそれぞれでデータの呼び名が異なり、意味するものも異なっている。データを正確に表記するには、情報源ごとに異なる表示をする必要があるように思われる。しかし、情報源ごとにバラバラになっている状態では、利用者が求めるデータの所在をある程度理解していることが必要になってしまうため、利用者への敷居が高くなってしまう。一般的なリレーショナル・データベースも同様に、利用者がデータを利用するにあたって、データの構造などを深く理解していることが前提となってしまうため、利用者への敷居が高くなってしまう。そこで自然言語による形式「ナンセンス・フォーマット」（仮称）により、自然文に近い形式で表示を行う。これにより、前提知識が無くても、読めば理解できるようになるため、敷居を下げることができる。

• 各種データ書式の考案
  データの情報を漏れなく保存する汎用的な書式が幾つか挙げられてきた。単一 XML ファイル、個別タブ区切りテキストファイル、 RDB など。現在採用しているものは、単一の自然文形式のテキストファイル。