SemCode2: オントロジーに基づくアノテーションとトランスコーディング

PDF
長尾 確
名古屋大学 大学院情報科学研究科

1 はじめに

コンテンツをより賢くするための常套手段としてアノテーション（あるいはメタデータ）を関連付けるというものがあるが、アノテーションがコンテンツに直接関連付けられた情報である限り、そのアノテーションを他のコンテンツに適用するのは一般に困難である。また、アノテーションを人手であるいは半自動で作成することに対する一般的な批判に、作成コストが応用のベネフィットに見合わないというものがあるが、これはアノテーションが他のコンテンツに利用できないことを前提としたものであろう。なぜなら、適用範囲が広い情報にかかるコストは相対的に下がっていくものであるからである。

作成コストが非常に高く、同時に適用範囲も広い情報の代表例は（領域）オントロジーであろう。本論文では、アノテーションの二次利用を念頭において、コンテンツに対する直接のアノテーション（第一層アノテーション）からオントロジーに相当する部分を抽出してメタアノテーション（第二層以降のアノテーション）として再構造化し、トランスコーディングに応用する。オントロジーには、世界に対する人間の解釈が含まれるため、なぜそのようなオントロジーを設定するのかということに対する客観的な根拠が必要になる。そこで、具体的なコンテンツとそれに付随する第一層アノテーションが、そのオントロジーを設定した根拠になり得るので、オントロジーからコンテンツやアノテーションへの逆リンクも用意する。

オントロジーを使ったトランスコーディングの例として、テキスト内の用語の言い換えを紹介する。これは、テキストに含まれる専門用語をより平易の言葉で置き換えるものであり、ユーザーがブラウザ上で語をクリックすることによって実行される。この処理はインタラクティブであると同時にインクリメンタルであり、言い換えられた結果にさらに用語が含まれる場合は、続けて言い換えを行うことができる。

本論文では、アノテーションを意味的に高度にするために避けては通れない問題と、その一つの解決策としてのオントロジーに基づくアプローチについて、そして、そのオントロジーの応用例としてのコンテンツのトランスコーディングについて述べる。

2 セマンティック・アノテーションの問題点

アノテーションとは、コンテンツに対するコンテンツつまりメタコンテンツ一般のことである。高精度の検索・要約・翻訳等のコンテンツの高度利用にアノテーションが有効であることはすでに多くの人が認めているところであるにも関わらず、意味的アノテーションに関する具体的な活動が遅々として進んでいない理由は、その作成コストが大きく、現在の技術では自動化できる部分が少ないためである。たとえば、テキスト情報に十分なアノテーションを作成するためには、言語処理を行って文構造、談話構造、語彙関連情報を解析なり検索なりしなければならないが、自動的に決定できる部分はほとんどなく、人間の介入を必要とする。この介入に関わる労力は意外に大きい。また、ビデオコンテンツに十分なアノテーションを作成するためには、映像処理、音声処理などと同様に精度のあまり高くない自動処理を行って人間が情報を補足しなければならない。これは、ざっと見積もって、コンテンツ時間の約10倍の時間を要する。という具合に面倒であるため、よほど時間と制作費に余裕がある場合でなければ、特定のコンテンツに詳細なアノテーションを作成しようという動機は発生しにくい。

さらに、よく考えてみると、コンテンツに直接関連付ける意味的アノテーションには以下のような問題があると思われる。

  1. 第一に、第一層アノテーションはコンテンツの変更に柔軟に対応できないことである。これはアノテーションが個々のコンテンツに固有の意味的内容を顕在化したものであるという性質上無理のないことである。これに対処するためには、ある程度の文脈依存性を犠牲にして、アノテーションを細かい単位に分解して管理し、コンテンツの変更になった部分のみを置き換えるようにする必要がある。しかしながら、あまり細かい単位にすると、もともとのアノテーションの作成意図がわからなくなってしまう場合がある。そのため、テキストのアノテーションの場合は、段落、あるいは文単位のアノテーションを管理するのが妥当である。

  2. 一つ目の問題と関連するが、第一層のアノテーションは、特定のコンテンツの特徴を明示的に記述したものなので、それ以外のコンテンツに流用することが一般に困難である。同様の意味的内容を持つコンテンツになら流用できたほうが適切であるが、そのためにはコンテンツが似ているということを厳密に定義しなければならない。意味的アノテーションは、コンテンツの意味的類似性を厳密に規定するための手がかりになると考えられるが類似性という概念が一筋縄でいかないものであるため、まだあまり有意義な成果が得られていない。

  3. そして三つ目は、意味的アノテーションというより意味表現一般に関する問題であるが、表現されている内容が適切な抽象度と論理性（あるいは推論可能性）を備えているか、という問題である。これは、コンテンツの意味をどう捉えるかによって問題の複雑さが変わってくる。コンテンツの要約や翻訳がある程度の精度で可能になるような補足情報でよいならば、要約や翻訳にとって都合のよい情報がアノテーションから取り出せれば十分である。しかし、意味的な検索や連想等の応用を考えると、より一般的な意味表現や推論の仕組みが必要になってくる。

結局、やるべきことは何かというと、意味的アノテーションの再構造化を行って一般性の高い部分を抽出し、コンテンツと独立に管理可能な形式にして、コンテンツが変更されても利用可能であり、他のコンテンツに対しても適用可能な、メタアノテーションを作成することである。

そのようなメタアノテーションは、明らかに第一層アノテーションよりも作成コストが高いと思われるが、より再利用性が高いこともほぼ間違いがない。第一層アノテーションは、汎用的な意味表現であるメタアノテーションと、多様で個別的なコンテンツの間に位置し、両者のインタフェースとしての役割を果たす。

3 オントロジーに基づくアノテーション

以上の問題を解決するための一つの有力なアプローチが、オントロジーの概念の導入である。オントロジーには今ではいろいろな意味があるが、ここでは、辞書的に用いられる概念体系（つまり、何らかの名前から検索される形式的で論理的な概念記述の集合）とする。

SHOEやTopic Mapsなど、これまでにもオントロジーに基づくWebアノテーションに関する研究は行われていたが、未だに実用化のきざしが見えてきていない。これはなぜかというと、Webコンテンツのオントロジーを真面目に作成するということが想像以上に困難だからである。また、規模が大きくなればそれなりの実験を経て、使えるかどうかの判断ができるようになるものであるが、未だにそうならないのはやはり考え方というより作り方が悪いのであろう。オントロジーの構築が難しいのは、概念という普段は特に意識していないものを明確にすることの困難さだけでなく、そもそも概念体系というものはその概念を取り巻く領域の全体像が見えていないと記述しようがないからである。そのため、実例から始まり抽象度を上げていき、しばらく考えてまた実例に戻る、ということを繰り返していくしかないだろう。

本研究でのオントロジーは、第一層のアノテーションから他のコンテンツでも使えそうな一般化可能な部分を抽出して、さらに必要な属性を考慮して再構造化していくことによって構築される。そのため、どのような状況で概念を記述したのか明白であり、その意義についても考察しやすい。ただし、他のコンテンツで同じ概念がどのように使われるかは想像しにくいので、ある程度のコンテンツを収集してから考察する必要がある。

ここでのオントロジー構築の手順は以下のようになる。

  1. テキストコンテンツの第一層アノテーションを作成する。これは主に言語構造の解析と修正である。ビデオコンテンツの場合も音声トランスクリプトなどのテキスト情報が生成できる場合は、それに対する言語的アノテーションを作成する。これらのアノテーションはXMLで記述され、XMLデータベースで管理される。

  2. 言語構造の末端となる語彙に関して、多義語か専門用語と考えられる場合は、辞書を検索して適切な語義のIDを付与する。たとえば、WordNetのsynsetやEDRの概念識別子などが利用できる。ただし、synsetは基本的に語義であって概念ではないし、概念識別子は網羅性が低いので、これらは参考にはなるが、十分というものではない。

  3. つまり多くの場合、オントロジーへのポインタとなるIDを決める必要がある。たとえば、語（の単数あるいは基本形）＋品詞（たとえば、名詞ならn、動詞ならv）＋通し番号（同じ語で異なる語義を持つ場合を考慮して）のようなIDを自動的に生成して、該当する語にアノテートする。

  4. 次に、このIDに対応したオントロジーのエントリーを作成する。これは単なるXMLではなく、RDF (Resource Description Framework)を用いて記述する。RDFの利点は、内部データ構造として有向グラフを扱えることである。オントロジーの特徴はネットワーク構造を用いた推論ができることであるため、RDFを用いる意義がある。このRDFは後述するオントロジーエディタで作成・検索・編集することができる。このとき用語の解説文に関しても言語的アノテーションを施し、オントロジーの各項目から参照できるようにしておく。また、オントロジーのエントリーにはその作者のメールアドレスが記述され、後述するブラウザ上のインタフェースからオントロジーに属性が付与された場合は、その作者に通知が届くようになっている。

本来、語義に関する情報もコンテンツに対する直接のアノテーションなので、第一層アノテーションに含めるべきであるが、ここからオントロジーに発展できる可能性が大いにあるので異なる形式で取り扱うのがよいと思われる。そのためにRDFを用いる。RDFは第一層アノテーションを記述するのは必ずしも都合のよい形式ではないが、オントロジーを表現するためには十分な記述力と柔軟性を持っている。

3.1 オントロジーエディタ

オントロジーエディタは、言語的アノテーションのオーサリングツールと連動してオントロジーデータを作成・編集するためのツールである。

オントロジーのオーサリングツールとしては、ProtegeやText-To-Ontoなどが知られているが、基本的には昔からあった知識表現のフレームシステムとあまり変わっていない。つまり、概念にIDをつけフレームを作り、is-a関係（上位下位関係）やpart-of関係（部分全体関係）などの概念間の関係をスロットとして定義していくのである。また、if-addedやif-neededのようなスロットに関するオペレーションを定義することもある。

ここでのオントロジーの従来システムとの大きな違いは、基本的に概念はすべて語義であると考え、必ず、その解説文に言語的アノテーションを付与したものを用意し、それへのリンクを含むことである。つまり、ここでのオントロジーのエントリーは必ずそれに関する解説文と関連付けられていなければならず、さらに、コンテンツの言語的アノテーションから参照されるものである。このとき、言語的アノテーションからオントロジーデータへのリンクの逆リンクをオントロジーに含めることによって、概念の作成された文脈を調べることができる。

概念が共有可能な人間の考えだとすると、語義を概念の一部とするのは妥当である。しかし、語義以外の概念をどうするかを考える必要がある。たとえば、「4本足の動物」を表す用語はないので、語義として扱うのは適切ではないが、それを一つの概念として、まとめて扱いたい場合があるかも知れない。このとき、まず「動物」の概念（フレーム）を定義して、それに「足」の「数」が「4」に等しいという関係を表すスロットを追加することによって「4本足の動物」に相当する概念を定義できる。ここで、「足」「数」「4」のそれぞれも別のフレームで定義されている（ただし、「4」に関するフレームは整数一般を表すフレームを継承して、必要に応じて自動生成されるものとする。すべての数に関するフレームを事前に定義しておくことはできないからである）。

このように、語義にはない概念を定義することは可能であるが、それをどのような場面で定義すべきかは決められないだろう。とにかく、語義にはない概念を定義するための枠組みは用意するが、それをアノテーションのプロセスの中に取り入れることはしない。つまり、われわれのオントロジー構築のガイドラインでは、一般に、語義に相当する概念以外のものは定義しない。

3.2 オントロジーの作成プロセス

オントロジーエディタを用いたオントロジーデータの作成プロセスは次のようになる。

  1. 図のように、テキストコンテンツに対する言語的アノテーションを作成する。このとき、専門用語と思われる語のタグを選択し、先に説明したオントロジーIDをsense属性の値として付与する。

  2. 図のように、WordNetやEDRを用いて語義の検索をし、該当する解説文が存在するかどうか調べる。存在しない場合は、他の辞典等を用いて解説文を検索する。

  3. 検索あるいは作成した解説文に対して言語的アノテーションを付与する。解説文に含まれる用語の検索と語義アノテーションもここで行う。

  4. 図のように、オントロジーの基本フレームが表示され、スロット情報を編集できる。この結果はRDF形式で保存される。具体的には以下のような形式である。

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:sc="http://www.nagao.nuie.nagoya-u.ac.jp/SemCode/semcode-onto-2005-01-01.rdfs#"
  xml:lang="ja">
 <rdf:Description rdf:about="urn:sense:agent-n-01">
  <sc:is-a>urn:sense:software-n-01</sc:is-a>
  <sc:resource>http://www.nagao.nuie.nagoya-u.ac.jp/text/agent/intro.html</sc:resource>
  <sc:definition>http://www.nagao.nuie.nagoya-u.ac.jp/sensedef/agent-n-01.xml</sc:definition>
 </rdf:Description>
</rdf:RDF>

4 オントロジーに基づくトランスコーディング

次に、オントロジーを用いたトランスコーディングを考える。ここでは、典型的な例の一つとして、専門用語の言い換えを取り上げる。これは、ユーザーの選択した専門用語をより平易な表現に置き換えるというものである。

専門用語の解説を表示するだけなら、語義IDのアノテーションとそのIDで検索できる辞書があれば十分であるが、本文をその解説を用いて言い換えるためには、もう少し複雑な仕組みが必要になる。つまり、解説文と本文の間で構文的・意味的な整合性を保つ仕組みである。

まず、オントロジーはコンテンツの第一層アノテーションと用語辞典の解説文に対する言語的アノテーションの二つのリソースを結びつける働きがあるとする。また、オントロジーはその概念を言語化するときに必ず含めるべき属性とそうでない属性の区別を持っているとする。後者の条件は、解説文を使って用語を言い換える場合、どの部分が省略可能でどの部分がそうでないかを決定するのに利用される。

また、ここでの言い換えは、インタラクティブであると同時にインクリメンタルである。つまり、ユーザーにとって理解が困難な用語や、文脈から自分が誤解している感じる用語をオンデマンドに言い換えるのが適切であり、自動的にすべての用語を変換するべきではないだろう。また、用語の説明に別の用語が含まれることはよくあるため、言い換え結果にまだ理解困難な用語が含まれている場合がある。このとき、ユーザーはさらに言い換えを要求することができるようになっているべきである。そのため、言い換え処理はインクリメンタルに実行可能である必要がある。

4.1 トランスコーディングプロセス

オントロジーに基づく、言い換えトランスコーディングのプロセスは次のようになる。

  1. 図のように、コンテンツサーバー、トランスコーディングプロキシ、アノテーションサーバー、オントロジーサーバー、そしてユーザークライアント（Webブラウザ）がネットワークで連結されている。

  2. 最初に、ブラウザを通してコンテンツサーバーへリクエストが送られる。このとき、トランスコーディングプロキシはこのリクエストを仲介し、同時に、アノテーションサーバーに、リクエストされたコンテンツに対する第一層アノテーションを要求する。

  3. トランスコーディングプロキシは、コンテンツサーバーからクライアントに向けて配信されたコンテンツに、アノテーションサーバーから得られた第一層アノテーションと共に、オントロジーサーバーとの通信モジュールを含むオントロジーインタフェース（Javaアプレット）を統合してブラウザに送信する。

  4. 図のように、ブラウザ上で専門用語を選択してクリックすると、オントロジーインタフェースを通してオントロジーサーバーにリクエストが伝達される。このとき、オントロジーサーバーは、関連するオントロジーデータを呼び出すと同時に、アノテーションサーバーから言語的アノテーションを含めた解説文データを受け取り、それらをトランスコーディングプロキシに伝達する。

  5. トランスコーディングプロキシは、オントロジーサーバーから受け取ったオントロジーデータに基づき、用語の周辺の文脈と解説文の言語構造、およびオントロジーデータに含まれる、概念の言語化に関する制約を考慮して、言い換え処理を実行する。

  6. 言い換え結果は、トランスコーディングプロキシを経由してブラウザに送信される。変換されたコンテンツに関して、同様の操作を繰り返し実行することができる。トランスコーディングプロキシは、ユーザーごとにプリファレンスとコンテキストを保存する仕組みになっており、ユーザーが要求した言い換えの履歴と現時点でのテキストの内容はユーザーごとのデータベースで管理されている。ユーザーの管理は、トランスコーディングプロキシがブラウザに設定するクッキーIDによってなされる。基本的に同じIPアドレスならば同じユーザーとしているが、IPアドレスが変わってもクッキーIDが同じならば同じユーザーであると認識するようになっている。

  7. オントロジーインタフェースは、言い換えだけでなくオントロジーの内容を確認したり、オントロジーに属性を追加する場合にも用いられる。たとえば、オントロジーの定義とコンテンツの文脈に食い違いがある場合は、オントロジーの修正を促すための属性を付与することができる。

  8. オントロジーサーバーは、定期的にメールでオントロジーデータの作者に修正や変更のきっかけとなる、ユーザーからのフィードバックに関する通知をする。前述のオントロジーエディタを使って、そのメールで通知されたオントロジーデータにアクセスすれば、容易に、属性の内容を確認しながらデータを編集することができる。

5 今後の課題

オントロジーの構築は容易ではないが、意味的アノテーションの作成コストを相対的に引き下げるためには、複数のコンテンツに適用可能なより一般的な概念体系を作って、意味的アノテーションの一部とするやり方が妥当である。

また、コンテンツに対する直接のアノテーションはその作成の指針や方向性が明確であるため、コストがかかっても着実に作っていくことができる。そのアノテーションの一部をオントロジーとして再構成していく作業は、一般に何をどう作っていけばよいかわかりにくいオントロジーの作成のガイドラインとなるだろう。

今後の課題の一つ目は、複数のコンテンツから別々に派生したオントロジーをまとめあげるための環境作りである。これは、コンテンツや第一層アノテーションを見比べながら文脈の類似性と差異性を考慮して、オントロジーを修正していくためのツール類である。

また、オントロジーは自然にネットワーク構造を構成するため、このネットワークが局所的に整合性を持っているとしても、ネットワークが巨大になれば明らかな矛盾や間違いが発生する可能性がある。人間の間違いはいたしかたないが、機械的な推論の中に本質的な間違いが含まれているのはまずいので、機械がこのような問題を自動的に発見して人間に注意を促す仕組みが必要になる。人間が注意深く作った辞書でさえ、同義語の連鎖をたどっていくと明らかな意味の歪みが発生することがままあるため、オントロジーが完全な整合性を持つことは期待できないが、人間の直感から大きく逸脱するのを防ぐようにしてオントロジーを拡張していくやり方があるだろう。このやり方を見つけるのは容易ではなく、当然ながら今後の課題の一つである。

さらに、ここでのオントロジーは、その概念が言語化された場合の表現と常に密接に関連付けられているから、オントロジーのネットワークを構成すると同時に、言語間の関係も明確になっていくと思われる。これによって、特定分野の用語辞典が自然に構築されていく仕組みや、既存の用語辞典を修正していくような仕組みができると思われる。これももちろん今後の課題の一つである。この仕組みは、巨大なWebから知識を構築していくメカニズムの根幹をなすものと考えられるだろう。

トランスコーディングを含むオントロジーの応用に関しても課題が山積している。オントロジーはコンテンツの類似性を定義する有力な手段になると思われるが、似ているということをどこまで詳細に考えるかは、その応用に依存する。たとえば、類似検索は似ているかどうかを最終的に判断するのは人間だから、どのような観点で似ているかを特に明確にしなくてもよい場合がある。また、類似性に基づいて翻訳を行うシステムの場合は、ターゲットの言語に依存して、言語化可能な最も適切な概念を自動的に選択しなければならないから、類似性と文脈との整合性を厳密に考慮する必要がある。このように、オントロジーが構築できれば、あとは応用システムが勝手に考えればよい、というわけにはいかないため、応用システムが要求する概念の定義の詳細度に応じて、オントロジーを拡張していかなければならない。これはおそらくエンドレスの作業である。しかし、オントロジーとは、非常に壊れやすくもろいものであるため、人間が常にメンテナンスしていく必要があり、そのような体制ができれば、あらゆるものの自動化・情報化がオントロジーによってさらなる発展を遂げることができるだろう。