JP2007334894A - ドキュメントの注釈をソースドキュメントのコンテキスト内で視覚化すること - Google Patents

Abstract

【課題】意味的注釈と、オリジナルのソースドキュメントの視覚化されたレイアウト内の適切な位置とを関連付けることは、困難または不可能である。
【解決手段】ドキュメントアノーテータは、レイアウトを伴うソースドキュメントをコンテンツとレイアウトメタデータとを含むフォーマットへと変換するドキュメントコンバータと、受け取ったコンテンツに対してドキュメントの注釈を作成する注釈パイプラインと、ドキュメントの注釈をレイアウトメタデータに基づいて位置タグに関連付ける、位置タグがレイアウト内におけるドキュメントの注釈の位置を特定するマージャーと、フォーマットのうちの少なくともいくつかのコンテンツと１つ以上の選択された注釈とを、レイアウトメタデータと選択された１つ以上の注釈に関連付けられている位置タグとに基づいてレイアウトに準拠するようにレンダリングするドキュメントビジュアライザとを含む。
【選択図】図１

Description

以降の内容は、情報処理技術に関する。詳細には、意味内容に基づくドキュメントの注釈付け、解析、目録作成、および検索に関し、特にそれらに関連して説明する。しかしながら、以降の内容は、その他に基づくドキュメントの注釈付け、解析、目録作成、および検索にも、より広く関連する。

作成者の名前、ドキュメントのタイトル、主題などの意味内容に基づいてドキュメントの目録を作成することが、大きな関心を集めている。ソースドキュメントは、ＰＤＦ（ｐｏｒｔａｂｌｅ ｄｏｃｕｍｅｎｔ ｆｏｒｍａｔ）、ＨＴＭＬ（ｈｙｐｅｒｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）、ワードプロセッサフォーマットやスプレッドシートフォーマットなどの大もとのアプリケーションフォーマットなど、さまざまなフォーマットのうちの任意のものとすることができる。意味解析は通常、意味解析パイプラインによって行われ、この意味解析パイプラインは、たとえばトークナイザ、パーサ、および意味内容解析コンポーネントを含むことができ、通常は、文法、用語集、オントロジ、あるいはその他の外部の参照やリソースと共に機能する。

意味解析を行うためには、オリジナルのドキュメントを意味解析パイプライン内へインポートする。通常、これは、ドキュメントのテキストコンテンツを抽出すること、および抽出したテキストコンテンツを意味解析パイプライン内へ入力することを伴う。このパイプラインは、テキストコンテンツを処理して、ドキュメントの注釈を作成し、そしてこの注釈は、ドキュメントやドキュメントの集合の目録作成、インデックス付け、ラベル付け、あるいはその他の形での編成を行う際に使用される。その後、ユーザは、自分の関心を引く１つ以上の意味的注釈に基づいてドキュメントを識別および検索する。

米国特許出願番号第１１／２９６３９６号明細書 米国特許出願番号第１１／３１６７７１号明細書

しかし、ユーザがドキュメントを視覚化したいと希望する場合に、問題が生じる。通常は、注釈と、その注釈が適用されるソースドキュメントレイアウト内の位置との間には、つながりや結び付きがない。そのような結び付きを形成することは困難である。というのも、ソースドキュメントの大もとのレイアウトは通常、セマンティックアノーテータによって処理されるテキストベースの入力とは異なり、さらに複雑であるためである。したがって、意味的注釈と、オリジナルのソースドキュメントの視覚化されたレイアウト内の適切な位置とを関連付けることは、困難または不可能である。

１つのアプローチは、意味的注釈に関連付けられているキーワードのドキュメント内における出現に基づいて検索段階の最中にリンクを構築することである。たとえば、意味的注釈がドキュメントの作成者を識別する場合には、この注釈は、ドキュメント内における作成者の名前の出現に関連付けることができる。しかし、このようなキーワードベースのアプローチは、いくつかの点において不十分である。所与のキーワードは、ドキュメント内に複数回出現する可能性があるが、意味的注釈は、それらのキーワードの出現のうちの１つまたは一部にしか関連付けられていないかもしれない。たとえば作成者の注釈は、ドキュメントの最上部における作成者の名前の出現に正しく関連付けられているかもしれないが、キーワードベースの関連付けは、作成者の注釈を、テキスト本文内や、（たとえば、作成者が自分自身の過去の作成物を引用している場合には）出典内など、作成者の名前のその他の出現に誤って関連付けるおそれもある。このような場合、その注釈がソースドキュメント内の正しい部分または場所に関連付けられていないことは明らかである。

その一方で、意味的注釈そのものが、複数のキーワードを有する可能性があり、やはり、ドキュメント内におけるどのキーワードの出現をその意味的注釈に関連付けるべきかに関して、あいまいさが生じる。さらに、特定の意味的注釈は、容易に関連付けられるキーワードを有していないかもしれない。たとえば、世界の石油備蓄に関する記事は、「主題：エネルギーの保存」という意味的注釈を有しているかもしれないが、「エネルギー」および「保存」という言葉は、その記事のどこにも出現しないかもしれない。

その他のタイプの注釈を使用することもできるが、通常は、視覚化の最中に同様の問題が生じる。別のタイプの注釈の一例は、イメージ分類である。１つ以上のイメージが、ソースドキュメントから抽出され、抽出されたイメージが、イメージ分類子によって解析され、そのイメージ分類子が、イメージ分類注釈を出力する。そしてユーザは、ドキュメントを、そのドキュメントが対象のイメージ分類を含んでいることに基づいて検索する。やはり通常は、注釈と、その注釈が適用されるソースドキュメントレイアウト内の位置との間には、つながりや結び付きがない。さらに、イメージ分類注釈のためのキーワードベースの注釈の結び付きを視覚化の最中に構築することは、通常は不可能である。

本明細書に記載の態様によれば、ドキュメントアノーテータが開示される。ドキュメントコンバータが、レイアウトを伴うソースドキュメントを、コンテンツとレイアウトメタデータとを含む確定的なフォーマットへと変換するように構成されている。少なくとも１つの注釈パイプラインが、受け取ったコンテンツに対してそれぞれドキュメントの注釈を作成するように構成されている。マージャーが、作成されたドキュメントの注釈をレイアウトメタデータに基づいて位置タグに関連付けるように構成されている。位置タグは、レイアウト内におけるドキュメントの注釈の位置を特定する。ドキュメントビジュアライザが、確定的なフォーマットのうちの少なくともいくつかのコンテンツと、１つ以上の選択された注釈とを、レイアウトメタデータと、選択された１つ以上の注釈に関連付けられている位置タグとに基づいてレイアウトに実質的に準拠するようにレンダリングするように構成されている。

本明細書に記載の態様によれば、ドキュメントを視覚化する方法が開示される。関連付けられているソースドキュメントと、関連付けられている位置タグとを有するドキュメントの注釈の選択が受け取られる。関連付けられているソースドキュメントのコンテンツと、ドキュメントの注釈とが、関連付けられているソースドキュメントと、ドキュメントの注釈に関連付けられている位置タグとを表すコンテンツおよびレイアウトメタデータに従ってレンダリングされる。

本明細書に記載の態様によれば、ドキュメントに注釈を付ける方法が開示される。ソースドキュメントの最初の表示が作成される。この最初の表示は、ソースドキュメントの最初のコンテンツと、ソースドキュメント内の前記コンテンツのレイアウトを示す最初のレイアウトメタデータとを含む。ソースドキュメントの最初のコンテンツの少なくともいくつかが処理されて、ドキュメントの注釈が作成される。最初のレイアウトメタデータの位置タグが、作成されたドキュメントの注釈に割り当てられて、最初のレイアウトメタデータに対してそれぞれドキュメントの注釈の位置を特定する。少なくともドキュメントの注釈と、それらの割り当てられた位置タグとが保存される。

図１を参照すると、注釈システム８が、注釈を付けるためにソースドキュメント１０を受け取る。ソースドキュメント１０は、通常はソースドキュメント１０に組み込まれているまたは一体化されているレイアウトを有する。たとえばソースドキュメントは、イメージのサイズや位置、テキストのフォントのタイプ、サイズ、およびボールドやアンダーラインなどの属性、パラグラフの配置（たとえば、左ぞろえ、右ぞろえ、中央ぞろえ、両端ぞろえなど）、行間隔、ハイパーリンク、表、枠など、レイアウト上の特徴を指定するレイアウトタグを含むＨＴＭＬ（ｈｙｐｅｒｔｅｘｔ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ドキュメントとすることができる。別の例としては、ソースドキュメント１０は、ＰＤＦ（ｐｏｒｔａｂｌｅ ｄｏｃｕｍｅｎｔ ｆｏｒｍａｔ）とすることができる。ＰＤＦドキュメントは、フォントのサイズ、タイプ、あるいは属性、行間隔、ハイパーリンク等の組み込まれたまたは一体化されたレイアウト上の特徴や、ページＩＤやカラムＩＤ等のページ固有の特徴などを含むことができる。別の例としては、ソースドキュメント１０は、Ｍｉｃｒｏｓｏｆｔ（商標） Ｗｏｒｄのドキュメントフォーマットなど、大もとのワードプロセッシングアプリケーションフォーマットとすることができる。このワードプロセッシングアプリケーションフォーマットは、フォントのサイズ、タイプ、あるいは属性、行間隔、ハイパーリンクなどのレイアウト上の特徴、カラムや強制改ページなどのページ固有の特徴、目次やインデックスなどの論理的または意味的な編成上の特徴を指定することができる。別の例としては、ソースドキュメント１０は、ＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ドキュメントとすることができ、フォントのサイズ、タイプ、あるいは属性、ハイパーリンクなどのレイアウト上の特徴や、論理的または意味的な編成上のスキーマなどを含むことができる。ソースドキュメント１０のコンテンツは、テキストコンテンツ、イメージなどのグラフィカルなコンテンツ、オーディオコンテンツ、オーディオビジュアルコンテンツなどを含むことができる。

ソースドキュメント１０は、図示されているＸＭＬコンバータ１２などのコンバータによって処理され、このＸＭＬコンバータ１２は、ソースドキュメント１０の表示１４を出力し、この表示１４は、コンテンツと、レイアウト情報とを分離し、後者は、保存されるか、またはドキュメント内におけるパラグラフ、セクション、見出し、あるいはその他の構成要素の位置を示す位置タグを含むレイアウトメタデータによって表される。ソースドキュメント１０の表示１４は、レンダリングプログラムが、ソースドキュメント１０のレイアウトに実質的に準拠するレイアウトでコンテンツをレンダリングするのに十分なコンテンツおよびレイアウトメタデータを含む。コンバータ１２は、ＨＴＭＬ、ＰＤＦ、およびワードプロセッシングアプリケーションフォーマットなど、注釈を付けることを意図されている一連のフォーマットを処理するように選択または構築される。以降の例においては、ＸＭＬコンバータ１２が使用され、入門レベルのタグ付きのドキュメントがＸＭＬフォーマットで出力される。しかし、ＳＧＭＬ（ｓｔａｎｄａｒｄ ｇｅｎｅｒａｌｉｚｅｄ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）やＨＴＭＬなど、コンテンツとレイアウト情報とを分離または区別するその他のタイプの構造化されたまたはタグ付きのフォーマットを使用することもできる。

オリジナルのソースドキュメント１０をコンテンツ＋レイアウトメタデータの表示１４に変換することは、ソースドキュメント１０のフォーマット（たとえば、ＰＤＦやＨＴＭＬなど）に応じて、さまざまな処理ステップを任意選択で含み、ソースドキュメント内の推測的に想定される規則性や特徴には、注釈が付けられる（たとえばアプリケーションによっては、すべてのソースドキュメントが、特定のレイアウト上の共通点を有する新聞記事であるということが推測的に分かるかもしれない）。コンバータ１２は、既存のＰＤＦ／ＨＴＭＬコンバータ、アドホックコレクションｘｓｌｔスタイルシート、機械学習変換ツールなど、適切なフォーマット変換ツールを採用することができる。コンバータ１２によって任意選択で実行されるさらなる処理は、（たとえば、イメージ用のＰＤＦ／ＨＴＭＬバウンディングボックスを、実際のイメージコンテンツの抽出を担当するＵＲＬ属性と合わせることによって）イメージ抽出機能を活用するオペレーションや、空のノードを取り除くことなどのクリーンアップオペレーションを含む。図示されている実施形態においては、表示１４はＸＭＬであり、それぞれのレイアウト要素は、ＸＭＬ表示のノードとして描かれることが好ましい。適切なレイアウト要素のいくつかの例としては、ソースドキュメントの全体、ソースドキュメントの章、ソースドキュメントのパラグラフ、ソースドキュメントのセクション、ソースドキュメントのページ、ソースドキュメントのタイトル、ソースドキュメントのカラム、ソースドキュメントのイメージなどが含まれる。

コンバータ１２によって作成されるレイアウトメタデータは、位置タグを含む。それぞれの位置タグは、レイアウト要素の一意の識別子である。たとえば、それぞれの見出し、それぞれのセクション、それぞれのパラグラフなどが、位置タグを割り当てられる。図示されている実施形態においては、ＸＭＬコンバータ１２は、ソースドキュメント１０のレイアウト内におけるノードの位置を識別する（ドキュメントレベルで）一意の永続的な位置タグを用いて、それぞれのレイアウト要素を描くノードを豊かにする。このような位置タグは、たとえば、既存のｘｓｌｔプロセッサのgenerate_id( )メソッドを使用することによって作成することができる。図示されている実施形態においては、ＸＭＬの出力が使用され、コンテンツ＋レイアウトメタデータの表示は、下記のような一般的な構造を有する装飾された構造のツリーフォーマット（すなわち、任意の数のテキスト要素やイメージ要素を組み込んだ一連のページ）を有する。

Document(URL)
{
Page (Pos_Tag_ids, page-number, width, height))
{
(...),
Text (Pos_Tag_ids, x, y, width, height, font, font-size, ..., value),
(...),
Image(Pos_Tag_ids, x, y, width, height, URL) ,
(...)
},

(...)
}

ここでは、それぞれのPos_Tag_idsは、対応するノードの一意の永続的な位置タグを保存する属性値のペアである。Documentノードに関連付けられているＵＲＬ属性は、ソースドキュメント１０への永続的なポインタである。

コンテンツ＋レイアウトメタデータの表示１４は、オリジナルのソースドキュメント１０のレイアウトに実質的に適合するレイアウトでレンダリングできるように十分なレイアウトメタデータを含む。「実質的に適合すること」によって、レンダリングは、オリジナルレイアウトをほぼ正確に表示したものとなるが、ソースドキュメント１０のオリジナルレイアウトのレンダリングからは、いくらかのずれがあるかもしれないと理解されたい。そのようなずれは、たとえばソースドキュメント１０が、コンバータ１２によってサポートされていない、または正確にはサポートされていないレイアウト上の特徴を含むことに起因する可能性がある。たとえばコンバータ１２は、オリジナルレイアウト内で使用されている特定のフォントをサポートしていない可能性もあり、あるいはオリジナルレイアウトと比べてより粗い空間解像度を有する可能性などもある。レイアウトメタデータの位置タグは、注釈をレンダリング内の対応する位置にリンクさせるために使用される。したがって注釈は、作成されると、その注釈が関連するレイアウトの１つ以上の部分の１つ以上の位置タグに割り当てられるか、または関連付けられる。したがって、その後のレンダリングの最中に、割り当てられたまたは関連付けられた１つ以上の位置タグに基づいて注釈をレンダリング内に正しく配置することができる。

レンダリングは通常、ユーザが対象の注釈を見つけて、ソースドキュメント１０を表示するよう要求したことに応答して実行される。ソースドキュメント１０が表示されるのではなく、表示１４がレンダリングされる。このレンダリングは、オリジナルのソースドキュメント１０のレイアウトに実質的に適合し、注釈に割り当てられている位置タグによって、それらの注釈をレンダリング内に正しく配置することができる。したがって表示１４は、注釈付けの段階とレンダリングの段階との間で、たとえば図１に図式的に示されているようなドキュメントキャッシュ１６内に保存されるか、または別法として、たとえばコンバータ１２を呼び出して、その表示の新たなインスタンスを作成することによって、レンダリング時に効率よく再作成される。表示１４をドキュメントキャッシュ１６内に保存することは、たとえばストレージスペース上の制約や、著作権侵害の懸念などから、アプリケーションによっては困難または不可能あるいは不適切であるかもしれない。再作成アプローチが使用される場合には、コンバータ１２は、確定的なコンバータとすべきであり、この確定的なコンバータは、ソースドキュメント１０に対してコンバータ１２がそれぞれ呼び出されるたびに、同じ一式の位置タグを含む同じレイアウトメタデータを生成する。

引き続き図１を参照すると、コンテンツ＋レイアウトメタデータの表示１４が、注釈を付けるために使用される。図１においては、２つの例示的な注釈パイプライン２０、２２が示されている。しかし注釈パイプラインの数は、１つ、２つ、３つ、４つ、５つ、あるいはそれ以上とすることができる。図１においては、注釈パイプライン２０は意味的注釈パイプラインであり、その一方で注釈パイプライン２２はイメージ分類パイプラインである。しかし、１つ、２つ、３つ、あるいはそれ以上の意味的注釈パイプラインや、１つ、２つ、３つ、あるいはそれ以上のイメージ分類パイプラインなど、その他の注釈パイプラインや注釈パイプラインの組合せを使用することもできる。さらに、意味的パイプラインおよびイメージ分類パイプライン以外のその他のタイプの注釈パイプラインを使用することもできる。たとえばオーディオコンテンツを、たとえばタイプ（たとえば音楽コンテンツ、物語や会話のコンテンツ、自然の音など）ごとに分類するオーディオ分類子や、オーディオビジュアルコンテンツ分類子などを含めることが考えられる。

例示的な意味的注釈パイプライン２０を参照すると、任意選択のプリプロセッサ３０が、コンテンツ＋レイアウトメタデータの表示１４を、パイプライン２０の入力フォーマットに適合するように任意選択で前処理する。たとえば、テキストコンテンツの意味的な処理を容易にするために、プリプロセッサ３０は、テキスト要素をパラグラフへとセグメント化することや、一連のテキスト要素をそれらの読み取り順序に従って再構築することができる。注釈パイプライン２０を通じてコンテンツのレイアウトコンテキストを追跡把握する能力を保持するために、プリプロセッサ３０は、結果として生じる第２レベルの構造を、さらなるまたは更新された一時的なPos_Tag_idsを用いて任意選択で装飾する。たとえば、入門レベルの表示１４のいくつかのテキストノードが、プリプロセッサ３０によって新たなパラグラフノードへとグループ化されている場合には、さらなるPos_Tag_ids属性が、プリプロセッサ３０によってその新たなパラグラフノードに関連付けられる。プリプロセッサ３０は、この新たなPos_Tag_ids属性の値として、構成要素であるテキストノードのPos_Tag_ids値のリストまたはその他のグループを割り当てられることが好ましい。

プリプロセッサの出力は通常、表示と同じフォーマットである。図示されている例においては、表示１４と、プリプロセッサ３０の出力とは、双方ともＸＭＬフォーマットである。プリプロセッサ３０の出力は、注釈パイプライン２０に入力される。任意選択のプリプロセッサは、注釈パイプラインに固有のものであり、その注釈パイプライン用のデータを調整または準備する。さまざまな注釈パイプラインと同じ数だけ、さまざまな第２レベルの調和プロセスが存在することができる。例示的なイメージ分類パイプライン２２の場合のように、既にコンテンツ＋レイアウトメタデータの表示１４が、特定の注釈パイプラインへ入力するのに適切なフォーマットになっている場合には、プリプロセッサを省略することが好ましい。

引き続き意味的注釈パイプライン２０を参照すると、表示１４は、任意選択のプリプロセッサ３０によって前処理された後に、テキストエクストラクタ３２によって処理され、このテキストエクストラクタ３２は、セマンティックアノーテータ３４に入力するために、文、パラグラフ、セクションなどのテキスト部分を抽出する。セマンティックアノーテータ３４は、受け取ったテキストコンテンツにラベル作成、目録作成、あるいはその他の形の注釈付けを行うための意味的注釈を決定または構築するために実質的にいかなるタイプの意味的な処理も採用することができる。セマンティックアノーテータ３４は、たとえばトークナイザ、パーサ、１つ以上の一般的なまたはトピック固有の意味内容解析コンポーネント、１つ以上の文法や用語集、注釈オントロジなどを含む（あるいは、それらに直接または間接的に動作可能にアクセスする）ことができる。たとえばセマンティックアノーテータ３４が、医学関連の書類および刊行物を分類することを意図している場合には、このアノーテータ３４は、作成者、タイトル、医学関連のキーワード、医療機器の名前など、対象となる可能性のある意味的注釈の種類を識別するオントロジを利用することができる。セマンティックアノーテータ３４は、完全に自律的なものとすることもでき、あるいは、たとえば人間の注釈者やその分野の専門家による入力などを含む対話的なものとすることもできる。

エクストラクタ３２は、自分がアノーテータ３４へ送信する（文、パラグラフ、セクションなどの）コンテンツに関連付けられた位置タグを追跡把握する。注釈マージャー３６は、注釈を受け取り、レイアウトメタデータの適切な位置タグをそれぞれの注釈に割り当てるか、または関連付ける。場合によっては、コンテンツは、プリプロセッサ３０によって作成された前述のパラグラフなど、前処理されたグループとすることができ、この場合、注釈は、注釈マージャー３６によって、構成要素となるテキストノードのPos_Tag_ids値のリストやその他のグループを含む位置タグに関連付けられ、それによってパラグラフの注釈は、注釈を付けられたパラグラフを構成するテキストノードに正しく関連付けられる。注釈マージャー３６は、その他の処理を任意選択で実行する。たとえば注釈が、抽出された注釈のためのスキーマ（一例として、ここではExtractedDataＸＭＬスキーマとしてラベル付けされている）を採用している場合には、注釈マージャー３６は、その注釈をExtractedData注釈スキーマへと適合させるか、またはExtractedData注釈スキーマに適合するようにその注釈を修正する。

イメージ分類パイプライン２２は、同様の方法で機能する。図示されている例においては、イメージ分類パイプライン２２は、前処理を伴わずに、入門レベルの表示１４上で直接機能する。イメージエクストラクタ４２は、分類のためにイメージを抽出し、その一方で分類のために送信されたイメージの位置タグを追跡把握する。イメージ分類子４４は、それぞれの入力イメージごとにイメージ分類を決定する。イメージ分類は、イメージの注釈としての役割を果たす。イメージ分類子４４は、エッジフィーチャーの解析、特徴ベクトルのクラスタリングに基づく機械学習、ＰＣＡ（ｐｒｉｎｃｉｐａｌ ｃｏｍｐｏｎｅｎｔｓ ａｎａｌｙｓｉｓ）を採用する技術など、実質的にいかなる適切なイメージ分類アプローチも使用することができる。注釈マージャー４６は、注釈マージャー３６と同様に機能して、それぞれのイメージ分類注釈と、対応するイメージの位置タグとを受け取り、イメージの位置タグをイメージ分類注釈に割り当てるか、または関連付ける。

ExtractedDataスキーマのインスタンス内で収集された注釈は、注釈コンテンツコンパイラ５０によって、任意選択でさらに変形され、豊かにされ、この注釈コンテンツコンパイラ５０は、たとえばパイプライン２０、２２からの位置タグ付きの注釈を結合することができ、結果として生じる注釈は、適切なフォーマット、オントロジ、スキーマ、あるいはその他の表示に従って一式の注釈５２として保存される。たとえば、そのような注釈のＲＤＦ（ｒｅｓｏｕｒｃｅ ｄｅｓｃｒｉｐｔｉｏｎ ｆｒａｍｅｗｏｒｋ）フォーマットでの表示は、注釈を付けられたリソースのEntry_Level_URLおよびPos_Tag_Idsの値を指すrdf:about属性を必要とする。このようなアーキテクチャーは、保存された一式の注釈５２が、Pos_Tag_Idsと、したがってその注釈のドキュメントレイアウトコンテキストを検索する能力とを保持するならば、注釈を変形するまたは豊かにするいかなる処理にも拡張することができる。

引き続き図１を参照すると、典型的な目録作成アプリケーションにおいては、注釈システム８は、目録を作成される多数の異なるソースドキュメントに適用される。それぞれのソースドキュメントは、注釈システム８によって処理されて、対応する一式の注釈５２が作成され、これらの注釈５２は、位置タグを有し、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）やその他のポインタによってソースドキュメント１０にリンクされている。あるいは、コンテンツ＋レイアウトメタデータの表示１４が、任意選択のドキュメントキャッシュ１６内に保存され、対応する一式の注釈が、その保存された表示を指すＵＲＬを含む。目録作成アプリケーションにおいては、そのような処理は通常、多数のソースドキュメントに適用され、それによって実質的な目録が作成される。ソースドキュメントそのものは、インターネットの１つのウェブサイト上に、（たとえば、インターネット検索エンジンアプリケーションの場合には）インターネット上のさまざまなウェブサイト内に、あるいは企業ネットワークのデータストレージ設備内などに保存することができる。

図２を参照すると、例示的なドキュメントビジュアライザ５８が、図１の注釈システム８によって注釈を付けられたドキュメントを表示するために呼び出される。注釈を付けられたドキュメントの目録は、ドキュメントの注釈に基づいて対象のドキュメントを識別するためにユーザによってアクセスされることが好ましい。図２においては、それぞれのソースドキュメントの表示１４は保存されない（すなわち、図１のキャッシュ１６は省略される）ものとする。ユーザは、対象のドキュメントの注釈６０を選択する。対象の注釈６０の選択は、たとえば、ネットワーク接続されたパーソナルコンピュータ、ハンドヘルドＰＤＡ（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ）、携帯電話、あるいはその他のユーザインターフェーシングデバイス（図示せず）と共に機能する目録検索インターフェースプログラムを使用して行うことができる。対象の注釈６０を含むドキュメント１０へのＵＲＬやその他のポインタ６２も、一式の注釈５２から検索される。最初の表示１４は保存されなかったため、ドキュメントビジュアライザ５８は、ＸＭＬコンバータ１２を呼び出して、ソースドキュメント１０の検索表示６４を作成する。コンバータ１２は、呼び出されるたびに同じ入力に対して同じ結果を生成する確定的なコンバータであるため、検索表示６４は、最初の表示１４のコンテンツと同一の検索コンテンツを含み、同様に検索表示６４は、最初の表示１４のレイアウトメタデータと同一の検索レイアウトメタデータを含むことになる。有利なことに、一式の注釈５２の注釈は、コンバータ１２によって作成される位置タグ（または位置タグのグループ）を介してレイアウトにリンクされているため、図１に示されている処理の残りは、再び実行されないことが好ましい（図２には示されていないが、図１のキャッシュ１６を利用できる場合には、コンバータ１２を使用して検索表示６４を再作成するのではなく、代わりにキャッシュ１６から検索することができるという点が理解できるであろう）。

ドキュメント視覚化ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）６６やその他の視覚化コンポーネントは、検索表示６４のレンダリングを作成し、このレンダリングは、モニタ、ラップトップコンピュータのスクリーン、またはその他のディスプレイデバイス（図示せず）上に表示されること、あるいはプリンタ（図示せず）によって印刷されることなどが好ましい。検索レイアウトメタデータは、視覚化ＡＰＩ６６が、オリジナルのソースドキュメント１０のレイアウトに実質的に準拠するレイアウトでコンテンツをレンダリングするのに十分なものである。いくつかの実施形態においては、視覚化ＡＰＩ６６は、レイアウトメタデータをＳＶＧ（ｓｃａｌａｂｌｅ ｖｅｃｔｏｒ ｇｒａｐｈｉｃｓ）の記述へと変換するか、またはＰＤＦ指向のＡＰＩを使用するが、その他の視覚化アルゴリズムを使用することもできる。

注釈オーバーレイヤ７０は、作成されたレンダリング上に少なくとも対象の注釈６０をオーバーレイする。任意選択で、注釈オーバーレイヤ７０は、ドキュメントレイアウトの付近に位置する注釈、あるいはドキュメント内のすべての注釈など、その他の注釈もオーバーレイする。注釈をオーバーレイする前に、任意選択の注釈補正計算機７２が、レンダリング内における注釈の位置を精緻化するための前処理を実行することができる。精緻化は、たとえば、注釈を正しいページおよび／または正しいコンテキストゾーン上に表示するために、検索表示６４内にコード化されている幾何学的な特性に基づいて計算することができる。注釈補正計算機７２が採用されていない場合には、注釈は、その注釈に関連付けられているものとして位置タグによって識別される文、パラグラフ、セクション、あるいはその他のレイアウト要素と共にレンダリングされる。

注釈オーバーレイヤ７０は、検索表示６４の検索レイアウトメタデータと、注釈の割り当てられている位置タグとに基づくレイアウトで検索表示６４の検索コンテンツのレンダリングと共に、および任意選択の注釈補正計算機７２によって計算されるあらゆる位置の精緻化を伴って、１つ以上の注釈をレンダリングする。たとえば、関連付けられているレイアウト要素を強調表示すること、アンダーラインを引くこと、四角く囲むこと、あるいはその他の形でマークすること、およびその関連付けられているレイアウト要素を含むページの余白内に、あるいはその関連付けられているレイアウト要素の上にマウスポインタが近づいたときに現れるバブルとしてなど、適切な方法で注釈を表示することによって、注釈をレンダリングすることができる。注釈をレンダリングするその他のアプローチにおいては、注釈に関連付けられている１つの文字列または一式の文字列が、強調表示され、アンダーラインを引かれ、あるいはその他の形でマークされる。マークされたテキストは、注釈補正計算機７２によって、注釈の文字列の中身と、位置タグによって識別され関連付けられているレイアウト要素内の対応する文字列の中身とをマッチさせることによって、その位置を特定することができる。イメージ分類注釈の場合には、イメージの分類は、イメージの余白内に表示することもでき、あるいは、対応するイメージの上にマウスポインタが近づいたときに小さな読み取り専用のダイアログウィンドウとしてポップアップさせることもできる。

ドキュメントに注釈を付けるためのシステムを図式的に示す図である。 図１のシステムを使用して注釈を付けられたドキュメントを視覚化するためのドキュメント視覚化システムを図式的に示す図である。

符号の説明

８ 注釈システム、１０ ソースドキュメント、１２ ＸＭＬコンバータ、１４ 表示、１６ ドキュメントキャッシュ、２０ 意味的注釈パイプライン、２２ イメージ分類パイプライン、３０ プリプロセッサ、３２ テキストエクストラクタ、３４ セマンティックアノーテータ、３６ 注釈マージャー、４２ イメージエクストラクタ、４４ イメージ分類子、４６ 注釈マージャー、５０ 注釈コンテンツコンパイラ、５２ 一式の注釈、５８ ドキュメントビジュアライザ、６０ 対象の注釈、６２ ＵＲＬやその他のポインタ、６４ 検索表示、６６ ドキュメント視覚化ＡＰＩ、７０ 注釈オーバーレイヤ、７２ 注釈補正計算機。

Claims (4)

1. レイアウトを伴うソースドキュメントを、コンテンツとレイアウトメタデータとを含む確定的なフォーマットへと変換するように構成されているドキュメントコンバータと、
   受け取ったコンテンツに対してそれぞれドキュメントの注釈を作成するように構成されている少なくとも１つの注釈パイプラインと、
   前記作成されたドキュメントの注釈を前記レイアウトメタデータに基づいて位置タグに関連付けるように構成されているマージャーであって、前記位置タグが、前記レイアウト内における前記ドキュメントの注釈の位置を特定するマージャーと、
   前記確定的なフォーマットのうちの少なくともいくつかのコンテンツと、１つ以上の選択された注釈とを、前記レイアウトメタデータと、前記選択された１つ以上の注釈に関連付けられている前記位置タグとに基づいて前記レイアウトに実質的に準拠するようにレンダリングするように構成されているドキュメントビジュアライザとを含むことを特徴とするドキュメントアノーテータ。
2. 請求項１に記載のドキュメントアノーテータであって、前記ドキュメントの注釈を、関連付けられている位置タグと共に保存するように構成されている目録データストレージをさらに含むことを特徴とするドキュメントアノーテータ。
3. 請求項１に記載のドキュメントアノーテータであって、前記コンテンツが、テキストコンテンツを含み、前記少なくとも１つの注釈パイプラインが、少なくとも１つの意味的処理パイプラインを含むことを特徴とするドキュメントアノーテータ。
4. 請求項１に記載のドキュメントアノーテータであって、前記コンテンツが、イメージコンテンツを含み、前記少なくとも１つの注釈パイプラインが、少なくとも１つのイメージ分類子パイプラインを含むことを特徴とするドキュメントアノーテータ。

Images