JPWO2006085455A1 - 文書処理装置および文書処理方法 - Google Patents
文書処理装置および文書処理方法 Download PDFInfo
- Publication number
- JPWO2006085455A1 JPWO2006085455A1 JP2007502566A JP2007502566A JPWO2006085455A1 JP WO2006085455 A1 JPWO2006085455 A1 JP WO2006085455A1 JP 2007502566 A JP2007502566 A JP 2007502566A JP 2007502566 A JP2007502566 A JP 2007502566A JP WO2006085455 A1 JPWO2006085455 A1 JP WO2006085455A1
- Authority
- JP
- Japan
- Prior art keywords
- document
- context
- file
- data
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/35—Clustering; Classification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/12—Use of codes for handling textual entities
- G06F40/14—Tree-structured documents
- G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Document Processing Apparatus (AREA)
Abstract
Description
この装置は、閲覧の対象となる文書ファイルをソースファイルとして取得する文書取得部と、所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照し、各コンテキストに適合するコンテキストデータをソースファイルから抽出するコンテキスト解析部と、閲覧者によって指定される条件であって、閲覧対象となる1以上のコンテキストを特定すると共に各コンテキストに適合するコンテキストデータから新たに生成される文書ファイルの構造を定義するための閲覧条件を参照し、閲覧対象のコンテキストデータを構造化した文書ファイルとして閲覧ファイルを生成する文書生成部と、を備える。
この方法は、閲覧の対象となる文書ファイルをソースファイルとして取得するステップと、所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照し、各コンテキストに適合するコンテキストデータをソースファイルから抽出するステップと、閲覧者によって指定される条件であって、閲覧対象となる1以上のコンテキストを特定すると共に各コンテキストに適合するコンテキストデータから新たに生成される文書ファイルの構造を定義するための閲覧条件を参照し、閲覧対象のコンテキストデータを構造化した文書ファイルとして閲覧ファイルを生成するステップと、を備える。
図1は、前提技術に係る文書処理装置20の構成を示す。文書処理装置20は、文書内のデータが階層構造を有する複数の構成要素に分類された構造化文書を処理するが、本前提技術では構造化文書の一例としてXML文書を処理する例について説明する。文書処理装置20は、主制御ユニット22、編集ユニット24、DOMユニット30、CSSユニット40、HTMLユニット50、SVGユニット60、及び変換部の一例であるVCユニット80を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
インターネットの出現により、ユーザによって処理され管理される文書の数が、ほぼ指数関数的に増加してきた。インターネットの核を形成するウェブ(World Wide Web)は、そのような文書データの大きな受け皿となっている。ウェブは、文書に加えて、このような文書の情報検索システムを提供する。これらの文書は、通常、マークアップ言語により記述される。マークアップ言語のシンプルかつポピュラーな例の一つにHTML(HyperText Markup Language)がある。このような文書は、ウェブの他の位置に格納されている他の文書へのリンクをさらに含む。XML(eXtensible Markup Language)は、さらに高度でポピュラーなマークアップ言語である。ウェブ文書にアクセスし、閲覧するためのシンプルなブラウザが、Java(登録商標)のようなオブジェクト指向のプログラミング言語で開発されている。
[入力] → [処理] → [出力]
[コントローラ]→ [モデル] → [ビュー]
文書処理システムの実施例は、図11−29に関連して明らかにされる。
実行環境101のキーとなるコンポーネントはProgramInvoker(プログラムインボーカ:プログラム起動部)103である。ProgramInvoker103は、文書処理システムを起動するためにアクセスされる基本的なプログラムである。例えば、ユーザが文書処理システムにログオンして開始するとき、ProgramInvoker103が実行される。ProgramInvoker103は、例えば、文書処理システムにプラグインとして加えられた機能を読み出して実行させたり、アプリケーションを開始して実行させたり、文書に関連するプロパティを読み出すことができる。ProgramInvoker103の機能はこれらに限定されない。ユーザが実行環境内で実行されるように意図されたアプリケーションを起動したいとき、ProgramInvoker103は、そのアプリケーションを見つけ、それを起動して、アプリケーションを実行する。
プラグインサブシステム104は、文書処理システムに機能を追加するための高度に柔軟で効率的な構成として使用される。プラグインサブシステム104は、また、文書処理システムに存在する機能を修正又は削除するために使用することができる。さらに、種々様々の機能をプラグインサブシステムを使用して追加又は修正することができる。例えば、画面上への文書の描画を支援するように作用するEditlet(エディットレット:編集部)機能を追加することもできる。Editletプラグインは、システムに追加されるボキャブラリの編集も支援する。
コマンドサブシステム105は、文書の処理に関連したコマンドの形式の命令を実行するために使用される。ユーザは、一連の命令を実行することにより、文書に対する操作を実行することができる。例えば、ユーザは、コマンドの形で命令を発行することにより、文書処理システム中のXML文書に対応するXMLのDOMツリーを編集し、XML文書を処理する。これらのコマンドは、キーストローク、マウスクリック、又は他の有効なユーザインタフェイスアクションを使用して入力されてもよい。1つのコマンドにより1以上の命令が実行されることもある。この場合、これらの命令が1つのコマンドにラップ(包含)され、連続して実行される。例えば、ユーザが、誤った単語を正しい単語に置換したいとする。この場合、第1の命令は、文書中の誤った単語を発見することであり、第2の命令は、誤った単語を削除することであり、第3の命令は、正しい単語を挿入することであってもよい。これらの3つの命令が1つのコマンドにラップされてもよい。
Resource109は、様々なクラスに、いくつかの機能を提供するオブジェクトである。例えば、ストリングリソース、アイコン、及びデフォルトキーバインドは、システムで使用されるResourceの例である。
文書処理システムの第2の主要な特徴であるアプリケーションコンポーネント102は、実行環境101において実行される。アプリケーションコンポーネント102は、実際の文書と、システム内における文書の様々な論理的、物理的な表現を含む。さらに、アプリケーションコンポーネント102は、文書を管理するために使用されるシステムの構成を含む。アプリケーションコンポーネント102は、さらに、UserApplication(ユーザアプリケーション)106、アプリケーションコア108、ユーザインタフェイス107、及びCoreComponent(コアコンポーネント)110を含む。
UserApplication106は、ProgramInvoker103と共にシステム上にロードされる。UserApplication106は、文書と、文書の様々な表現と、文書と対話するために必要なユーザインタフェイスとをつなぐ接着剤となる。例えば、ユーザが、プロジェクトの一部である文書のセットを生成したいとする。これらの文書がロードされると、文書の適切な表現が生成される。ユーザインタフェイス機能は、UserApplication106の一部として追加される。言いかえれば、UserApplication106は、ユーザがプロジェクトの一部を形成する文書と対話することを可能とする文書の表現と、文書の様々な態様とを、共に保持する。一旦UserApplication106が生成されると、ユーザがプロジェクトの一部を形成する文書との対話を望むたびに、ユーザは簡単に実行環境上にUserApplication106をロードすることができる。
CoreComponent110は、複数のPane(ペイン)の間で文書を共有する方法を提供する。後で詳述するように、Paneは、DOMツリーを表示し、画面の物理的なレイアウトを扱う。例えば、物理的な画面は、個々の情報の断片を描写する画面内の複数のPaneからなる。ユーザから画面上に見える文書は、1又はそれ以上のPaneに出現しうる。また、2つの異なる文書が画面上で2つの異なるPaneに現れてもよい。
上述したように、アプリケーションコンポーネント102は、システムにより処理され管理される文書から構成される。これは、システム内における文書の様々な論理的及び物理的な表現を含む。アプリケーションコア108は、アプリケーションコンポーネント102の構成である。その機能は、実際の文書を、それに含まれる全てのデータとともに保持することである。アプリケーションコア108は、DocumentManager(ドキュメントマネージャ:文書管理部)1081及びDocument(ドキュメント:文書)1082自身を含む。
アプリケーションコンポーネント102の別の構成は、ユーザがシステムと物理的に対話する手段を提供するユーザインタフェイス107である。例えば、ユーザインタフェイスは、ユーザが文書をアップロードしたり、削除したり、編集したり、管理したりするために使用される。ユーザインタフェイスは、Frame(フレーム)1071、MenuBar(メニューバー)1072、StatusBar(ステータスバー)1073、及びURLBar(URLバー)1074を含む。
図12は、DocumentManager1081の詳細を示す。これは、文書処理システム内で文書を表現するために用いられるデータ構造及び構成を含む。分かりやすくするために、このサブセクションで説明される構成は、MVCパラダイムを用いて説明される。
文書を表現するDOMツリーは、Node(ノード)2021を有するツリーである。DOMツリーの部分集合であるZone(ゾーン)209は、DOMツリー内の1以上のNodeの関連領域を含む。例えば、画面上で文書の一部のみを表示し得るが、この可視化された文書の一部はZone209を用いて表示される。Zoneは、ZoneFactory(ゾーンファクトリ:ゾーン生成部)205と呼ばれるプラグインを用いて、生成され、取り扱われ、処理される。ZoneはDOMの一部を表現するが、1以上の「名前空間」を使用してもよい。よく知られているように、名前空間は、名前空間内でユニークな名前の集合である。換言すれば、名前空間内に同じ名前は存在しない。
Facet(ファセット)2022は、MVCパラダイムのモデル(M)部分内の別の構成である。Facetは、ZoneにおいてNodeを編集するために使用される。Facet2022は、Zone自身の内容に影響を与えずに実行することができる手続(プロシージャ)を使用して、DOMへのアクセスを編成する。次に説明するように、これらの手続は、Nodeに関連した重要で有用な操作を実行する。
文書処理システム内の文書は、少なくとも4つの観点から見ることができる。すなわち、1)文書処理システムにおいて文書の内容及び構造を保持するために用いられるデータ構造、2)文書の保全性に影響を与えずに文書の内容を編集する手段、3)文書の画面上の論理的なレイアウト、4)文書の画面上の物理的なレイアウト、である。Zone、Facet、Canvas及びPaneは、前述の4つの観点に相当する、文書処理システムのコンポーネントをそれぞれ表す。
上述したように、文書に対するいかなる変更(例えば編集)も取消可能であることが望ましい。例えば、ユーザが編集操作を実行し、次に、その変更の取消を決定したとする。図12に関連して、アンドゥサブシステム212は、文書管理部の取消可能なコンポーネントを実現する。UndoManager(アンドゥマネージャ:アンドゥ管理部)2121は、ユーザによって取り消される可能性のある全ての文書に対する操作を保持する。
前述したように、MVCのコントローラ部分は、カーソルサブシステム204を備えてもよい。カーソルサブシステム204は、ユーザから入力を受け付ける。これらの入力は、一般にコマンド及び/又は編集操作の性格を有している。したがって、カーソルサブシステム204は、DocumentManager1081に関連したMVCパラダイムのコントローラ(C)部分であると考えることができる。
前述したように、Canvas210は、画面上に提示されるべき文書の論理的なレイアウトを表す。XHTML文書の例では、Canvas210は、文書が画面上でいかに見えるかを論理的に表現したボックスツリー208を含んでもよい。このボックスツリー208は、DocumentManager1081に関連したMVCパラダイムのビュー(V)部分に含まれよう。
文書処理システムの重要な特徴は、XML文書を、他の表現にマップして取り扱うことが可能で、かつ、マップした先の表現を編集すると、その編集が元のXML文書に整合性を保ちつつ反映される環境を提供することにある。
ボキャブラリコネクションサブシステム300の機能は、VocabularyConnection301と呼ばれるプラグインを使用して、文書処理システムにおいて実現される。文書が表現されるVocabulary305ごとに、対応するプラグインが要求される。例えば、文書の一部がHTMLで記述され、残りがSVGで記述されている場合、HTMLとSVGに対応するボキャブラリプラグインが要求される。
Connector304は、ソースDOMツリーのソースノードと、デスティネーションDOMツリーのデスティネーションノードとを接続する。Connector304は、ソースDOMツリー中のソースノード、及びソースノードに対応するソース文書に対する修正(変更)を見るために作用する。そして、対応するデスティネーションDOMツリーのノードを修正する。Connector304は、デスティネーションDOMツリーを修正することができる唯一のオブジェクトである。例えば、ユーザは、ソース文書、及び対応するソースDOMツリーに対してのみ修正を行うことができる。その後、Connector304がデスティネーションDOMツリーに、対応する修正を行う。
上述したように、ボキャブラリコネクションサブシステムの目的は、同一の文書の2つの表現を同時に生成し保持することである。第2の表現も、DOMツリーの形式であり、これはデスティネーションDOMツリーとして既に説明した。第2の表現における文書を見るために、DestinationZone、Canvas及びPaneが必要である。
ボキャブラリコネクション(VC)サブシステム300の要素として、ボキャブラリコネクション(VC)コマンドサブシステム313がある。ボキャブラリコネクションコマンドサブシステム313は、ボキャブラリコネクションサブシステム300に関連した命令の実行のために使用されるVCCommand(ボキャブラリコネクションコマンド)315を生成する。VCCommandは、内蔵のCommandTemplate(コマンドテンプレート)318を使用して、及び/又は、スクリプトサブシステム314においてスクリプト言語を使用してスクラッチからコマンドを生成することにより、生成することができる。
XPathサブシステム316は、文書処理システムの重要な構成であり、ボキャブラリコネクションの実現を支援する。Connector304は、一般にxpath情報を含む。上述したように、ボキャブラリコネクションのタスクの1つは、ソースDOMツリーの変化をデスティネーションDOMツリーに反映させることである。xpath情報は、変更/修正を監視されるべきソースDOMツリーのサブセットを決定するために用いられる1以上のxpath表現を含む。
ソースDOMツリーは、別のボキャブラリに変換される前のボキャブラリで文書を表現したDOMツリー又はZoneである。ソースDOMツリーのノードは、ソースノードと呼ばれる。
実用のためには、プログラムはユーザからのコマンドに応答しなければならない。イベントは、プログラム上で実行されたユーザアクションを記述し実行する方法である。多くの高級言語、例えばJava(登録商標)は、ユーザアクションを記述するイベントに頼っている。従来、プログラムは、ユーザアクションを理解し、それを自身で実行するために、積極的に情報を集める必要があった。これは、例えば、プログラムが自身を初期化した後、ユーザが画面、キーボード、マウスなどでアクションを起こしたときに適切な処理を講じるために、ユーザのアクションを繰り返し確認するループに入ることを意味する。しかしながら、このプロセスは扱いにくい。さらに、それは、ユーザが何かをするのを待つ間、CPUサイクルを消費してループするプログラムを必要とする。
イベントは、イベントスレッドを用いて渡される。Canvas210は、イベントを受け取ると、その状態を変更する。必要であれば、Command1052がCanvas210によりCommandQueue1053にポストされる。
VocabularyConnectionプラグイン301を用いて、DestinationCanvasの一例であるXHTMLCanvas1106は、発生したイベント、例えば、マウスイベント、キーボードイベント、ドラッグアンドドロップイベント、及びボキャブラリに特有のイベントなどを受け取る。これらのイベントは、コネクタ304に通知される。より詳細には、図21(b)に図示されるように、VocabularyConnectionプラグイン301内のイベントフローは、SourcePane1103、VCCanvas1104、DestinationPane1105、DestinationCanvasの一例であるDestinationCanvas1106、デスティネーションDOMツリー及びConnectorTreeを通過する。
ProgramInvoker103及びそれと他の構成との関係は、図14(a)に更に詳細に示される。ProgramInvoker103は、文書処理システムを開始するために実行される実行環境中の基本的なプログラムである。図11(b)及び図11(c)に図示されるように、UserApplication106、ServiceBroker1041、CommandInvoker1051、及びResource109は、全てProgramInvoker103に接続される。前述したように、アプリケーション102は、実行環境中で実行されるコンポーネントである。同様に、ServiceBroker1041は、システムに様々な機能を加えるプラグインを管理する。他方、CommandInvoker1051は、ユーザにより提供される命令を実行して、コマンドを実行するために使用されるクラス及びファンクションを保持する。
ServiceBroker1041について、図14(b)を参照して更に詳細に説明する。前述したように、ServiceBroker1041は、システムに様々な機能を追加するプラグイン(及び関連するサービス)を管理する。Service1042は、文書処理システムに特徴を追加又は変更可能な最も下の層である。「Service」は、ServiceCategory401とServiceProvider402の2つの部分からなる。図14(c)に図示されるように、1つのServiceCategory401は、複数の関連するServiceProvider402を持ちうる。それぞれのServiceProviderは、特定のServiceCategoryの一部または全部を実行するように作用する。ServiceCategory401は、他方では、Serviceの型を定義する。
図14(e)は、ProgramInvoker103とUserApplication106との関係についての更なる詳細を示す。必要な文書やデータなどは、ストレージからロードされる。必要なプラグインは、全てServiceBroker1041上にロードされる。ServiceBroker1041は、全てのプラグインを保持し管理する。プラグインは、システムに物理的に追加することができ、又、その機能はストレージからロードすることができる。プラグインの内容がロードされると、ServiceBroker1041は、対応するプラグインを定義する。つづいて、対応するUserApplication106が生成され、実行環境101にロードされ、ProgramInvoker103にアタッチされる。
図15(a)は、ProgramInvoker103上にロードしたアプリケーションサービスの構成についての更なる詳細を示す。コマンドサブシステム105のコンポーネントであるCommandInvoker1051は、ProgramInvoker103内のCommand1052を起動又は実行する。Command1052は、文書処理システムにおいて、XMLなどの文書を処理し、対応するXMLDOMツリーを編集するために用いられる命令である。CommandInvoker1051は、Command1052を実行するために必要なクラス及びファンクションを保持する。
図16(a)は、全ての文書、及び文書の一部及び文書に属するデータを保持するアプリケーションコア108についての更なる説明を提供する。CoreComponent110は、文書1082を管理するDocumentManager1081にアタッチされる。DocumentManager1081は、文書処理システムに関連づけられたメモリに格納される全ての文書1082の所有者である。
図17(a)は、DocumentManager1081の更なる説明と、DocumentManagerにおいて文書が構成され保持される様子を示す。図11(b)に示したように、DocumentManager1081は、文書1082を管理する。図17(a)に示される例において、複数の文書のうちの1つはRootDocument(ルート文書)701であり、残りの文書はSubDocument(サブ文書)702である。DocumentManager1081は、RootDocument701に接続され、RootDocument701は、全てのSubDocument702に接続される。
図18(a)及び図18(b)は、アンドゥフレームワーク及びアンドゥコマンドについて更なる詳細を提供する。図18(a)に示されるように、UndoCommand801、RedoCommand802、及びUndoableEditCommand803は、図11(b)に示したようにCommandInvoker1051に積むことができるコマンドであり、順に実行される。UndoableEditCommand803は、UndoableEditSource708及びUndoableEditAcceptor709に更にアタッチされる。「foo」EditCommand804及び「bar」EditCommand805は、UndoableEditCommandの例である。
図18(b)は、UndoableEditCommandの実行を示す。まず、ユーザが編集コマンドを使用してDocument705を編集すると仮定する。第1ステップS1では、UndoableEditAcceptor709が、Document705のDOMツリーであるUndoableEditSource708にアタッチされる。第2ステップS2では、ユーザにより発行されたコマンドに基づいて、Document705がDOMのAPIを用いて編集される。第3ステップS3では、ミューテーションイベントのリスナーが、変更がなされたことを通知される。すなわち、このステップでは、DOMツリーの全ての変更を監視するリスナーが編集操作を検知する。第4ステップS4では、UndoableEditがUndoManager706のオブジェクトとして格納される。第5ステップS5では、UndoableEditAcceptor709がUndoableEditSource708からデタッチされる。UndoableEditSource708は、Document705自身であってもよい。
上記のサブセクションでは、システムの様々なコンポーネント及びサブコンポーネントについて説明した。以下、これらのコンポーネントの使用に関する方法論について説明する。図19(a)は、文書処理システムに文書がロードされる様子の概要を示す。それぞれのステップは、図24−28において、特定の例に関連して詳述される。
図19(b)は、MVCパラダイムを用いてZoneの構成の概要を示す。この場合、Zone及びFacetは文書に関連した入力であるから、モデル(M)はZone及びFacetを含む。Canvasと、文書を画面にレンダリングするためのデータ構造体は、ユーザが画面上に見る出力であるから、ビュー(V)はCanvas及びデータ構造体に対応する。Commandは、文書とその様々な関係に対して制御操作を実行するので、コントロール(C)はCanvasに含まれるCommandを含む。
図20を用いて、文書及びその様々な表現の例について以下に説明する。この例で使用される文書は、テキストと画像の双方を含む。テキストは、XHTMLを用いて表され、画像は、SVGを用いて表される。図20は、文書のコンポーネント及び対応するオブジェクトの関係のMVC表現を詳細に示す。この例において、Document1001は、Document1001を保持するDocumentContainer1002にアタッチされる。文書はDOMツリー1003により表現される。DOMツリーは、ApexNode1004を含む。
図22(a)−(c)は、それぞれ、プラグインサブシステム、ボキャブラリコネクション、及びConnectorに関連する更なる詳細を示す。プラグインサブシステムは、文書処理システムに機能を追加又は交換するために用いられる。プラグインサブシステムは、ServiceBroker1041を含む。ServiceBroker1041にアタッチされるZoneFactoryService1201は、文書の一部に対するZoneを生成する。EditletService1202も、ServiceBroker1041にアタッチされる。EditletService1202は、Zone中のNodeに対応するCanvasを生成する。
特定の文書と関係する処理を説明する例を続ける。ドキュメントタイトルのある「MySampleXML」というタイトルの文書が文書処理システムにロードされる。図23は、「MySampleXML」ファイルのための、VCManager及びConnectorFactoryTreeを用いたVCDスクリプトの例を示す。スクリプトファイル中のボキャブラリセクション、テンプレートセクションと、VCManagerにおける対応するコンポーネントが示される。タグ「vcd:vocabulary」において、属性「match」は「sample:root」、「label」は「MySampleXML」、「call-template」は「sample template」となっている。
図24−28は、文書「MySampleXML」のロードについての詳細な記述を示す。図24(a)に示されるステップ1では、文書がストレージ1405からロードされる。DOMServiceは、DOMツリー及びDocumentManager1406と対応するDocumentContainer1401を生成する。DocumentContainer1401は、DocumentManager1406にアタッチされる。文書は、XHTML及びMySampleXMLのサブツリーを含む。XHTMLのApexNode1403は、タグ「xhtml:html」が付されたXHTMLの最上のノードである。「MySampleXML」のApexNode1404は、タグ「sample:root」が付された「MySampleXML」の最上ノードである。
本明細書では、セマンティックコンピューティング(Semantic Computing)時代における新世代の文書処理の観点から、XML(eXtensible Markup Language)複合文書処理フレームワークを提供する本システムがいかに新しい文書処理パラダイムを築き得るかについて述べる。旧来の文書処理では、WISYWIG(What You See Is What You Get)が中心的な概念であり、見た目のよい文書を作成することが主要な目的であった。実際、見た目の分かり易さによって理解を促進する情報伝達機能は重要である。しかし、書き手にとっての分かり易さと読み手にとっての分かり易さは必ずしも一致せず、理解の同一化は読み手の努力に負わされている。また、文書中に含まれる情報を「知識」に昇華し、繰り返し活用することで付加価値を生み出していくことも文書のもう一つの重要な目的である。しかし、現行の文書処理環境では文書が局所的に利用されるに留まることが多く、さまざまな文書の情報が統合されて新たな知識を生むというプロセスに転化しきれているとはいえない。文書による情報伝達機能を高め、文書を再利用して新しい価値に転化するためには、文書中の情報を細粒度で扱えること、自由に複数の文書を統合できること、意味処理を包含できること、等の諸条件を満たす新たな文書処理基盤が必要である。
本発明者は、本システムを前述の条件を満たす新世代の文書処理基盤として構想し、中核機能を実装した。
現代の知識社会においては、発展的なナレッジマネジメントが志向されている。ナレッジマネジメントにおいては、知識を中心とした経営革新の方法論を実践と同期するためにIT技術による知識共有、知識活用が主たる課題となっている。ナレッジマネジメントシステムでは、形式知の表現系である文書の再利用、文書中からの知識の発掘など、文書を知識の源泉として知識創造につなげていくことが理想である。具体的な技術としては、情報検索、情報分類、テキストマイニングなどが適用されるが、情報の意味内容に踏み込んで良質の支援を与える水準には至っていない。
次に、第2章[2.メタ情報を利用した意味処理]にて、文書の部分的な構成要素を処理する際にメタ情報が有益である点と、意味処理を加味してメタ情報を動的に構成するためのフレームワークについて述べる。
さらに、第3章[3.本システムのフレームワーク]にて、本システムのコア技術に関して第1章、第2章の訴求点と併せて概説する。
本システムが新世代の文書処理基盤の存立要件を満たし得ることを、第4章[4.結論]で述べる。最後に、第5章[5.付言]にて、本実施例を更に詳細に補足説明する。
1−1.文書の情報構造
図30は、文書の情報構造を示す図である。
単一の文書の情報構造は、明示的、暗黙的な構造を踏まえて、次のような多層的な構造として捉えることができる。
レイアウト構造は、フォーマットや組版の配置など文書の表現系に関する情報構造である。論理構造は、SGML(Standard Generalized Mark-up Language)やXMLで規定する文書の論理的な構成要件から規定される構造である。メタ構造は、文書の論理的な構造以外に、文書に付属する情報や文章に内在する意味内容に係わる情報構造である。
文書本来の目的とは、情報や知識を伝達し、伝達者と被伝達者が共通の認識を得ることである。また、共通認識の上にさらに新たな知的価値を創造することである。契約書であれば、関係者が契約内容に合意した上で、契約書を元にビジネスが進展することで価値が生まれる。報告書であれば報告者と報告対象者が正確な情報を共有した上で、報告対象者の正しい判断や行動につながる。
電子化された文書は、広域に分散して存在する。構造的な観点からは、各々の文書がそれぞれ独立に存在する訳ではなく、相互に構造的な関係性を持っている。例えばウェブ情報は、明示的なハイパーリンクによる広域的なグラフ構造によって成り立っているし、明示的なハイパーリンク関係を有していないビジネス文書においても、仮想的には等価な構造性を有していると見なすことが可能である。
書き手と読み手の認識を統合し、相互理解の水準を高めるには、従来の一方的な若しくは画一的な情報伝達フレームワークを改める必要がある。つまり、共通の理解は必ずしも書き手が与える唯一無二の表現構造に一意に従う必要はないということであり、読み手の認識の多様性を吸収し表現構造を可変とするフレームワークを導入することが有効と考えられる。
2−1.メタ情報の利用
前章において、XMLを基盤として、文書を構成する情報の部分単位で、一貫性を保持しつつ、文書を再利用することの有用性を述べた。これは、再利用すべき情報の単位が事前にXMLのタグセットやスキーマとして適切に設計されている場合には、有効に機能すると考えられる。
任意の部分情報の抽出・選択や情報検索の精度向上などメタ情報を利用するメリットは多いが、メタ情報を手動で付与することはコストが大きいという問題もある。特に、テキストに対して詳細に情報を付与することは、現実的でないことが多い。
図31は、メタ情報の抽出と区分についての態様を示す模式図である。
元情報に対して事後的なメタ情報を作成して管理する場合、2つの方式が考えられる。一つは、単一のメタ情報オブジェクトに最も細かい粒度のメタ情報タグを全て付与して一括管理する方式である。もう一つは、一定の区分基準に基づいて分割した複数のメタ情報オブジェクトを個別に管理する方式である。一定の区分基準とは、例えば、研究者−研究テーマなどの人と関係する任意のテーマ、プロジェクト−規模−成否などのビジネス活動に係わる事象である。
図32は、メタ情報とコンテキストレイヤの関係を示す模式図である。
ある文書とコンテキストレイヤ集合をペアで管理しておくことにより、メタ情報を基にした情報の再構成が容易に行えるようになる。コンテキストレイヤ集合は、例えば、元文書へのリンクと同時にリポジトリに保存しておくことで管理することができる。リポジトリ内の情報アクセスに対しては、アクセス用API(Application Program Interface)を用意しておく。XML−DBのような専用のストレージに格納することでも構わない。
3−1.本システムの基本思想
本システムにおいては、文書処理を意味的に行うために、いかなるXML文書も一つの基盤上で透過的に取り扱うことを基本思想としている。
図34は、本システムが提供するフレームワークの概念図を次に示す。
同図において、本システムの概念的機能性を中心の矩形に4つのカテゴリーで示した。「認識の分解」、「認識の投影」、「知識の構造的貯蔵」、「認識の再合成」の4つである。また、同図において数字は各機能性が強く関連するフレームワーク中の構成要素との相互作用を示している。
実施例において、本システムが、任意の情報粒度で文書の構成要素をハンドリングできること、意味処理を含む任意の処理モジュールを目的に応じて動的に結合できること、WISYWIGによる操作性を提供すること、等の特徴的な機能性によって、従来の文書概念の限界を打破する新しい文書処理基盤に相応しいフレームワークとなり得ることを示した。
図35は、文書とコンテキストの関係を説明するための模式図である。
本実施例において処理対象となるのは、1以上のソースファイル3010である。ソースファイル3010は、各種情報がテキストデータとして表現される文書ファイルである。これら多種多様なソースファイル3010に含まれる情報の集合体のことを、本実施例においては「文書空間3000」と称することにする。文書空間3000は、たとえば、企業内のデータベースに保存されている文書ファイルによって構成されてもよい。あるいは、文書空間3000はインターネットを介して取得可能なHTMLファイルやXMLファイルなどの文書ファイルによって構成されてもよい。
論理構造とは、構造化文書ファイルのタグや属性など、文書構造を規定するために明示的に設定される文書構造である。たとえば、「vehicle」という名前のタグと「car」という名前のタグは、その名前そのものは異なっていても意味としては近い関係にある。このとき、あるソースファイル3010において「vehicle」というタグによって特定されるテキストデータAと、別のソースファイル3010において「car」というタグによって特定されるテキストデータBは、内容に関して類似関係があると考えることもできる。このとき、テキストデータAとテキストデータBは、同じコンテキストに属するとしてもよい。また、「rose」というタグと「flower」というタグの間には、前者が後者の下位概念となる親子関係にある。このとき、「rose」というタグによって特定されるテキストデータは、「花(flower)」というコンテキストに含まれると考えてもよい。このように、タグ名の類語関係や親子関係などをあらかじめ定めた辞書テーブルを参照して、コンテキストを規定してもよい。
レイアウト構造とは、テキストデータの表示フォントや文書中の配置など、ソースファイル3010の表示形式を規定するために明示的に設定される構造である。レイアウト構造に基づいてコンテキストを規定する場合、ソースファイル3010とセットになっているCSSファイルを参照してコンテキストが決定されてもよい。たとえば、「ボールド体」で記述されるテキストデータのグループは、「強調されている情報群」として同じコンテキストに属するとしてもよい。
すでに述べたように、メタ構造は、明示的なメタ構造(以下、「明示メタ構造」とよぶ)と暗黙的なメタ構造(以下、「暗黙メタ構造」とよぶ)に分類できる。
明示メタ構造とは、ソースファイル3010のテキストデータ中に明示的に現れる項目によって設定される構造である。たとえば、「第X章」、「第Y項」などの章立てや、特許明細書の「背景技術」のような定型項目などによってコンテキストが規定されてもよい。
一方、暗黙メタ構造とは、テキストデータによって形成される意味構造である。たとえば、暗黙メタ構造として「肯定的な文章」と「否定的な文章」、「どちらともいえない文章」という3種類のコンテキストを規定してもよい。このような文章の意味内容を判定するための方法としては、ベイジアンフィルタ法などの既知の自然言語処理技術を応用すればよい。
同図に示すノード3020の場合、暗黙メタ構造に基づく所定観点から、コンテキストA、コンテキストB、コンテキストCが抽出されているとする。
本実施例に示す文書処理装置は、このような複数のソースファイル3010を含む文書空間3000から、目的とするコンテキストに応じたデータを効率よく、かつ、任意の情報単位にて収集できる。
まず、文書空間3000の中から、所定のコンテキストに基づいて、複数種類のコンテキストデータが抽出される。これらのコンテキストデータは、コンテキストごとに分類されてデータベースに保持される。このデータベースから、閲覧ファイル3060が生成される。閲覧ファイル3060は、読み手のユーザが任意に設計できる。同図においては、コンテキストデータAとコンテキストデータBが列挙される形式にて閲覧ファイル3060が生成されている。閲覧ファイル3060もXML文書ファイルとして生成される。
ここに示す各ブロックは、ハードウェア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
文書取得部3120は、ソースファイル3010を取得する。解析部3140は、取得されたソースファイル3010を解析してコンテキストデータを抽出する。データ保持部3200は、抽出されたコンテキストデータを保持する。図36のデータベースに相当するブロックである。条件設定部3220は、ユーザからの入力に応じて、閲覧ファイル3060に含まれるコンテキストデータを特定するための閲覧条件を設定する。また、閲覧ファイル3060のタグ構造も閲覧条件として設定される。閲覧条件は、文書処理装置20の定義ファイルとして反映される。この閲覧条件にしたがって、文書処理装置20はデータ保持部3200のデータから、閲覧ファイル3060を生成する。条件設定部3220は、閲覧ファイル3060の表示条件を設定する。この表示条件にしたがって閲覧ファイル3060は画面表示される。条件設定部3220は、解析部3140におけるコンテキストの規定方法も設定する。これらの条件設定を介して、読み手となるユーザは任意の観点から情報を抽出して、任意の表示形式にて、任意の構造にて表示させることができる。
要素解析部3160は、ソースファイル3010において処理対象となる文章を構文解析し、文の成分を要素データとして抽出する。たとえば、「Aは、2005年にBに行った」という文章の場合、主語としての「A」、目的語としての「B」、述語としての「行った」、日時を示す「2005年」という4つの構成要素(以下、「要素データ」とよぶ)に分解できる。データ保持部3200は、RDF形式にて各要素データを構造化して保持してもよい。コンテキスト解析部3180は各要素データに基づいてその文章のコンテキストを判定する。たとえば、「肯定的な文章」であるか「否定的な文章」であるかという観点からコンテキストを規定する場合、述語にあたる要素データが「よかった」、「できる」などの肯定的な述語であるときには肯定的なコンテキストであると判定してもよい。このように、メタ情報に基づいてコンテキストを規定する場合、コンテキスト解析部3180は、要素データから文章の性質を判断し、同じコンテキストに属する一群のテキストデータを、所定のコンテキストに属すると判定する。
この設定画面3360の、タグ構造設定領域3260は閲覧ファイル3060のタグ構造を設計するための領域である。同図においては、データA、データB、データCとして、3種類のデータがそれぞれ要素化されている。また、データBに対応する要素は、データAに対応する要素の子要素となっている。
このようにして、文書空間3000から、その構造および表現形式のいずれにおいても読み手のメンタルモデルに応じた閲覧ファイル3060を簡易に設計することができる。
Claims (11)
- 外部装置から文書ファイルを取得する文書取得部と、
所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照して、前記取得された文書ファイルに含まれるデータから各コンテキストに応じたメタ情報を抽出するメタ情報抽出部と、
各コンテキストに対応するメタ情報の集合が前記取得された文書ファイルから抽出されたデータであることを示す関連情報を記憶する関連情報記憶部と、
を備えることを特徴とする文書処理装置。 - 前記コンテキスト情報に応じて、各コンテキストに応じた文書構造を定義した構造定義ファイルを記憶する構造定義ファイル記憶部と、
各コンテキストに対応して分類されたメタ情報の集合から、前記構造定義ファイルにより定義された文書構造にて文書ファイルを生成する文書生成部と、
を更に備えることを特徴とする請求項1に記載の文書処理装置。 - 前記コンテキスト情報を定義するための入力画面を表示する入力画面表示部と、
入力画面を介してユーザによる前記コンテキスト情報を定義するための入力を受け付ける操作入力部と、を更に備え、
前記メタ情報抽出部は、前記入力画面を介してユーザにより定義されたコンテキスト情報に応じてメタ情報を抽出することを特徴とする請求項1または2に記載の文書処理装置。 - 閲覧の対象となる文書ファイルをソースファイルとして取得する文書取得部と、
所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照し、各コンテキストに適合するコンテキストデータをソースファイルから抽出するコンテキスト解析部と、
閲覧者によって指定される条件であって、閲覧対象となる1以上のコンテキストを特定すると共に各コンテキストに適合するコンテキストデータから新たに生成される文書ファイルの構造を定義するための閲覧条件を参照し、閲覧対象のコンテキストデータを構造化した文書ファイルとして閲覧ファイルを生成する文書生成部と、
を備えることを特徴とする文書処理装置。 - 文の成分として文章の意味構造を構成する単位にてソースファイルから要素データを抽出する要素解析部を更に備え、
前記コンテキスト解析部は、一群の要素データによって形成されるコンテキストに基づいて、1以上の要素データを含むコンテキストデータを抽出することを特徴とする請求項4に記載の文書処理装置。 - 前記コンテキスト解析部は、文章中に設けられた項目を単位としてソースファイルからコンテキストデータを抽出することを特徴とする請求項4または5に記載の文書処理装置。
- 前記ソースファイルには、表示のためのレイアウト情報が付与されており、
前記コンテキスト解析部は、前記レイアウト情報に示される表示上の構成単位にてソースファイルからコンテキストデータを抽出することを特徴とする請求項4から6のいずれかに記載の文書処理装置。 - 閲覧対象となるコンテキストデータの表示方法を定義するための表示条件を参照して、前記閲覧ファイルの表示方法を特定する表示処理部を更に備えることを特徴とする請求項4から7のいずれかに記載の文書処理装置。
- 前記文書生成部は、複数種類のソースファイルから抽出されたコンテキストデータから、単一の閲覧ファイルを生成可能であることを特徴とする請求項4から8のいずれかに記載の文書処理装置。
- 閲覧の対象となる文書ファイルをソースファイルとして取得するステップと、
所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照し、各コンテキストに適合するコンテキストデータをソースファイルから抽出するステップと、
閲覧者によって指定される条件であって、閲覧対象となる1以上のコンテキストを特定すると共に各コンテキストに適合するコンテキストデータから新たに生成される文書ファイルの構造を定義するための閲覧条件を参照し、閲覧対象のコンテキストデータを構造化した文書ファイルとして閲覧ファイルを生成するステップと、
を備えることを特徴とする文書処理方法。 - 閲覧の対象となる文書ファイルをソースファイルとして取得する機能と、
所定の基準に応じてデータを分類するための区分として1以上のコンテキストが定義されたコンテキスト情報を参照し、各コンテキストに適合するコンテキストデータをソースファイルから抽出する機能と、
閲覧者によって指定される条件であって、閲覧対象となる1以上のコンテキストを特定すると共に各コンテキストに適合するコンテキストデータから新たに生成される文書ファイルの構造を定義するための閲覧条件を参照し、閲覧対象のコンテキストデータを構造化した文書ファイルとして閲覧ファイルを生成する機能と、
をコンピュータに発揮させることを特徴とする文書処理プログラム。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005035502 | 2005-02-14 | ||
JP2005035502 | 2005-02-14 | ||
PCT/JP2006/301626 WO2006085455A1 (ja) | 2005-02-14 | 2006-02-01 | 文書処理装置および文書処理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2006085455A1 true JPWO2006085455A1 (ja) | 2008-06-26 |
Family
ID=36793031
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007502566A Pending JPWO2006085455A1 (ja) | 2005-02-14 | 2006-02-01 | 文書処理装置および文書処理方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US20090019064A1 (ja) |
JP (1) | JPWO2006085455A1 (ja) |
WO (1) | WO2006085455A1 (ja) |
Families Citing this family (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007109180A (ja) * | 2005-10-17 | 2007-04-26 | Canon Inc | 文書処理装置及び方法 |
US7676455B2 (en) * | 2006-02-03 | 2010-03-09 | Bloomberg Finance L.P. | Identifying and/or extracting data in connection with creating or updating a record in a database |
KR101058481B1 (ko) | 2006-05-16 | 2011-08-24 | 리서치 인 모션 리미티드 | 애플리케이션의 사용자 인터페이스를 스킨화하는 시스템 및방법 |
US20080040363A1 (en) * | 2006-07-13 | 2008-02-14 | Siemens Medical Solutions Usa, Inc. | System for Processing Relational Database Data |
US8219407B1 (en) | 2007-12-27 | 2012-07-10 | Great Northern Research, LLC | Method for processing the output of a speech recognizer |
US20110137923A1 (en) * | 2009-12-09 | 2011-06-09 | Evtext, Inc. | Xbrl data mapping builder |
US9779092B2 (en) * | 2010-03-11 | 2017-10-03 | International Business Machines Corporation | Maintaining consistency between a data object and references to the object within a file |
US20110258202A1 (en) * | 2010-04-15 | 2011-10-20 | Rajyashree Mukherjee | Concept extraction using title and emphasized text |
US9262185B2 (en) * | 2010-11-22 | 2016-02-16 | Unisys Corporation | Scripted dynamic document generation using dynamic document template scripts |
US9563714B2 (en) | 2011-06-16 | 2017-02-07 | Microsoft Technology Licensing Llc. | Mapping selections between a browser and the original file fetched from a web server |
US9753699B2 (en) * | 2011-06-16 | 2017-09-05 | Microsoft Technology Licensing, Llc | Live browser tooling in an integrated development environment |
US9460224B2 (en) | 2011-06-16 | 2016-10-04 | Microsoft Technology Licensing Llc. | Selection mapping between fetched files and source files |
US8732574B2 (en) * | 2011-08-25 | 2014-05-20 | Palantir Technologies, Inc. | System and method for parameterizing documents for automatic workflow generation |
US8468449B1 (en) * | 2011-12-08 | 2013-06-18 | Microsoft Corporation | Generating CSS shorthand properties |
US8909656B2 (en) | 2013-03-15 | 2014-12-09 | Palantir Technologies Inc. | Filter chains with associated multipath views for exploring large data sets |
KR20140125488A (ko) * | 2013-04-19 | 2014-10-29 | 한국전자통신연구원 | 스마트 유비쿼터스 네트워크에서 상황 인지 기반 네트워크 장치 및 시스템 |
CN103399857B (zh) * | 2013-07-01 | 2017-02-08 | 北京航空航天大学 | 一种通用文档结构信息抽取方法 |
CN104111980B (zh) * | 2014-06-26 | 2017-07-28 | 小米科技有限责任公司 | 网页内容的提取方法、装置和终端 |
US9928269B2 (en) * | 2015-01-03 | 2018-03-27 | International Business Machines Corporation | Apply corrections to an ingested corpus |
US20170103368A1 (en) * | 2015-10-13 | 2017-04-13 | Accenture Global Services Limited | Data processor |
US9749483B2 (en) | 2015-11-13 | 2017-08-29 | Kabushiki Kaisha Toshiba | Image forming apparatus and method for displaying template in image forming apparatus |
CN108197095A (zh) * | 2018-01-30 | 2018-06-22 | 南京焦点领动云计算技术有限公司 | 一种基于poi的word模板生成方法 |
JP6638053B1 (ja) * | 2018-12-05 | 2020-01-29 | グレイステクノロジー株式会社 | ドキュメント作成支援システム |
US11138265B2 (en) * | 2019-02-11 | 2021-10-05 | Verizon Media Inc. | Computerized system and method for display of modified machine-generated messages |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08202737A (ja) * | 1995-01-26 | 1996-08-09 | N T T Data Tsushin Kk | キーワード自動抽出装置およびキーワード自動抽出方法 |
JPH1040253A (ja) * | 1996-07-19 | 1998-02-13 | Nippon Telegr & Teleph Corp <Ntt> | 文章中の単語の観点生成方法及び装置 |
JP2000112962A (ja) * | 1998-10-01 | 2000-04-21 | Hitachi Ltd | 電子情報表示装置及び電子情報閲覧方法 |
JP2003263459A (ja) * | 2002-03-08 | 2003-09-19 | Nippon Telegr & Teleph Corp <Ntt> | 情報源類似性処理装置、情報源類似性処理方法、プログラム及び記録媒体 |
JP2003345829A (ja) * | 2002-05-24 | 2003-12-05 | Hitachi East Japan Solutions Ltd | 情報の検索方法およびその装置および情報検索のためのコンピュータプログラム |
JP2004145586A (ja) * | 2002-10-24 | 2004-05-20 | Matsushita Electric Ind Co Ltd | 情報検索方法及び情報検索装置 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0647909B1 (en) * | 1993-10-08 | 2003-04-16 | International Business Machines Corporation | Information catalog system with object-dependent functionality |
US5864862A (en) * | 1996-09-30 | 1999-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for creating reusable components in an object-oriented programming environment |
US5923330A (en) * | 1996-08-12 | 1999-07-13 | Ncr Corporation | System and method for navigation and interaction in structured information spaces |
JP3887867B2 (ja) * | 1997-02-26 | 2007-02-28 | 株式会社日立製作所 | 構造化文書の登録方法 |
EP1292895A4 (en) * | 2000-04-07 | 2006-08-09 | Financeware Com | METHOD AND DEVICE FOR PLAYING ELECTRONIC DOCUMENTS |
US6694307B2 (en) * | 2001-03-07 | 2004-02-17 | Netvention | System for collecting specific information from several sources of unstructured digitized data |
JP2004062446A (ja) * | 2002-07-26 | 2004-02-26 | Ibm Japan Ltd | 情報収集システム、アプリケーションサーバ、情報収集方法、およびプログラム |
JP4350398B2 (ja) * | 2003-03-12 | 2009-10-21 | 株式会社野村総合研究所 | 広告文配信システム |
-
2006
- 2006-02-01 JP JP2007502566A patent/JPWO2006085455A1/ja active Pending
- 2006-02-01 WO PCT/JP2006/301626 patent/WO2006085455A1/ja not_active Application Discontinuation
- 2006-02-01 US US11/816,241 patent/US20090019064A1/en not_active Abandoned
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08202737A (ja) * | 1995-01-26 | 1996-08-09 | N T T Data Tsushin Kk | キーワード自動抽出装置およびキーワード自動抽出方法 |
JPH1040253A (ja) * | 1996-07-19 | 1998-02-13 | Nippon Telegr & Teleph Corp <Ntt> | 文章中の単語の観点生成方法及び装置 |
JP2000112962A (ja) * | 1998-10-01 | 2000-04-21 | Hitachi Ltd | 電子情報表示装置及び電子情報閲覧方法 |
JP2003263459A (ja) * | 2002-03-08 | 2003-09-19 | Nippon Telegr & Teleph Corp <Ntt> | 情報源類似性処理装置、情報源類似性処理方法、プログラム及び記録媒体 |
JP2003345829A (ja) * | 2002-05-24 | 2003-12-05 | Hitachi East Japan Solutions Ltd | 情報の検索方法およびその装置および情報検索のためのコンピュータプログラム |
JP2004145586A (ja) * | 2002-10-24 | 2004-05-20 | Matsushita Electric Ind Co Ltd | 情報検索方法及び情報検索装置 |
Also Published As
Publication number | Publication date |
---|---|
WO2006085455A1 (ja) | 2006-08-17 |
US20090019064A1 (en) | 2009-01-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5020075B2 (ja) | 文書処理装置 | |
JP5073494B2 (ja) | 文書処理装置および文書処理方法 | |
JPWO2006085455A1 (ja) | 文書処理装置および文書処理方法 | |
JPWO2006051905A1 (ja) | データ処理装置およびデータ処理方法 | |
JPWO2006051715A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051870A1 (ja) | データ処理装置、文書処理装置及び文書処理方法 | |
JP4521408B2 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006046666A1 (ja) | 文書処理装置および文書処理方法 | |
JPWO2006051975A1 (ja) | 文書処理装置 | |
JPWO2006051713A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051960A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051954A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006120926A1 (ja) | 入力フォーム設計装置および入力フォーム設計方法 | |
JPWO2006051904A1 (ja) | データ処理装置およびデータ処理方法 | |
JPWO2006051955A1 (ja) | サーバ装置及び名前空間発行方法 | |
JPWO2006051716A1 (ja) | 文書処理装置及び文書処理方法 | |
JP4723511B2 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051712A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006051959A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2006046668A1 (ja) | 文書処理装置および文書処理方法 | |
JPWO2006051956A1 (ja) | サーバ装置及び検索方法 | |
JPWO2007105364A1 (ja) | 文書処理装置及び文書処理方法 | |
JPWO2007007529A1 (ja) | 文書処理装置および文書処理モジュール | |
JPWO2006051972A1 (ja) | データ処理装置、文書処理装置および文書処理方法 | |
JPWO2006046667A1 (ja) | 文書処理装置および文書処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20090109 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20091202 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110809 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111011 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20120214 |