JPH08501166A - 総合オーサリング及び翻訳システム - Google Patents

Abstract

(57)【要約】 本発明は、一言語情報開発及び多言語翻訳用の統合コンピュータ系プロセスのシステムである。対話テキストエディタ（140）は、テキストを作成するために著者が使用する自然言語サブセットに対して、テキストの曖昧さを取り除き、翻訳可能性を保証するための支援となる語彙制約及び文法規約の準拠を実施する。この結果得られた翻訳可能ソース言語テキストは、翻訳後の後編集を必要とすることなく、ターゲット言語の中の１言語に機械翻訳される。

Description

【発明の詳細な説明】統合オーサリング及び翻訳システム 発明の背景 １．発明の分野 本発明は、コンピータに基づく文書作成及び翻訳システム、特に、前編集や後編 集を行うことなく、制約言語テキストを外国語へオーサリング及び翻訳するため のシステムに関するものである。 ２．関連分野 膨大な情報を様々な文書として作成することが要求される組織団体では、分かり 易い文書作成の必要性に直面している。コミュニケーションの最適化を図るため には、このような文書は、必要なすべての表現を備え、簡潔且つ率直な言語でオ ーサリングすることが理想的である。この言語としては、単一で着実な言葉使い となるような一貫性が必要である。言語に曖昧さがあってはならない。 このような優れた執筆の追求は、オーサリングプロセスを統制するための各種規 定の設定へと発展した。しかし、技能や履歴の異なる著者達を、決められた技能 標準に従わせることは容易ではない。執筆のガイドライン、規則、及び標準は捕 らえどころがなく、定義及び実施が困難である。また、執筆の標準化や品質向上 を目的とする研究では、明白な結果が得られることはまれである。得られた結果 は、手段や成果を問わず、ドキュメンテーションのオーサリングコストを増大さ せる要因となってしまう。 執筆作業の生産性と品質向上を目指し、ソフトウェア環境で行われた最近の試み では、スペルチェッカーの提供がその成果として得られただけだ。その他の執筆 ソフトウェアに関しては、現在のところ、思わしい成果は得られていない。 言語的国境を超えることが、情報の提供に必要となる場合、このチャレンジは数 倍にも増大する。このような情報の通路を突破しなければならない組織団体は、 その全部又はほとんどを翻訳に頼っている。 ある言語から他言詔への翻訳は、数百年にもわたって行われてきた作業である。 コンピュータが登場する前は、元のテキスト（ソーステキスト）言語及び目標テ キスト（ターゲットテキスト）言語に精通した翻訳者と呼ばれる専門家によって 、このような翻訳作業 が、完全手動で行われていた。翻訳者としては、一般に、まず目標言語を母国語 として習得し、その後ソース言語を習得することが好ましいとされている。最も 正確で効率の良い翻訳は、このようなアプローチから得られるものと考えられて いた。 テキスト１ページの翻訳には、最も優れた翻訳者でさえもかなりの時間を必要と する。たとえば、専門の翻訳者が、技術テキストを英語から日本語へ翻訳する場 合、翻訳速度は１時問に付き約300語（約１ページ）と見積もられている。これ からも分かるように、特に技術文書では、かなりの時間と努力が、翻訳作業に要 求されることになる。 ビジネスや通商分野での翻訳の必要性は、過去100年間を通じ着実に増大を続け てきた。これには、いくつかの要因がある。第１の要因は、国際ビジネス業務に 伴う、テキストの急速な増加である。第２は、企業が世界貿易に携わるためには 、このようなテキストを多数の言語に翻訳しなければならないということ。第３ は、通商の急速化に伴い文書の頻繁な改版が発生し、その結果改版の翻訳が必要 になることである。 多数言語での情報の作成と配給は、該当する組織団体の責務である。世界市場で は、目標市場の標準言語でマニュアルが入手できることを、製造メーカー側で保 証しなければならない。外国語へのマニュアルの翻訳は、コストや時間が掛かる だけでなく、効率の悪い作業となる。翻訳者が、ドキュメンテーションで使用さ れているアプリケーション特有の用語に精通しているとは限らず、翻訳者自身の 個人的解釈に依存せざるを得ない結果、一貫性に欠ける翻訳となってしまうケー スが一般的である。これらの問題から、実際翻訳に回される文書量は、理想量よ りも少なくなっている。 研究開発分野でも、前世紀に起こった知識の拡大によって、文書翻訳の必要性が 急激に増大している。研究開発分野では、文書に対する優勢言語と言うものは全 くない。一般に、このような研究開発活動は、米国、英国、フランス、ドイツ、 及び日本などの高度産業国で行われている。また、特定の研究開発分野に関する 重要書類では、その言語数に追加の発生することが多い。特にエレクトロニクス やコンピュータ分野では、その技術の発展から、全言語でのテキスト作成にさら に拍車がかかっている。 テキストの作成能力は、適用する技術の能力と比例する。文書を手動で書く場合 、一定時間内に作成できる語数には限りがある。しかし、タイプライター、謄写 器、印刷機などの装置の出現によって、この作成量は大幅に増大している。また 、電子技術、コンピュータ技術、及び光学技術の発展は、著者の作業効率をさら に増大させている。現在、一般の著者が、決められた時間内に作成できるテキス ト量は、過去の手動作業による量をかなり上 回っている。 このようなテキスト量の増加は、技術の進歩と相まって、ソース言語からターゲ ット言語へのテキスト翻訳が注目される要因となっている。翻訳者の介入なしに 行う翻訳達成法の追求に関しては、民間や政府研究所を初め、数々の大学でも行 われてきた。 機械翻訳(MT)を試みるコンピュータシステムも考案されている。このようなコン ピュータシステムでは、ソーステキストを入力とし、ターゲットテキストを出力 として自動翻訳を行うようにプログラムされている。しかし、このような自動機 械翻訳用のコンピュータシステムは、現在の技術や理論だけでは達成できないと いうのが、研究者達の結論である。専門の編集者又は翻訳者による修正なしに、 ソースの自然言語からターゲットの自然言語へ機械翻訳できるようなシステムは 、現在のところ全く存在しない。１つの方法を、以下に説明する。 前編集と呼ばれるプロセスでは、ソースエディタが、ソーステキストの初期編集 を行う。ソースエディタの任務は、機械翻訳システム用テキストの最適状態とし て知られる形式に、ソーステキストを変更することである。このような形式の適 合性は、ソースエディタが、試行錯誤を通じて身に付けた知識である。 上記の前編集プロセスは、より経験の多いソースエディタによって繰返し行われ る場合もある。このようにして準備したソーステキストが、機械翻訳システムの 処理に回されることになる。システムの出力はターゲット言語であり、翻訳の目 的やユーザの品質条件に依って、後編集の要否が決定されることになる。 堪能な人間の翻訳者が行った翻訳に匹敵するような品質が必要とされる場合は、 恐らく、有能な翻訳者によって、機械翻訳の出力を後編集することが必要になる 。これは、人間の言語の複雑性が原因になっているだけではなく、現在の技術を 駆使し、時間と資源の制限やコスト面での条件も満足するように構築した機械翻 訳システムでは、その機能が比較的お粗末になってしまうことも原因になってい る。現在構築されているシステムでは、事実、手段はどうであれ、人間の翻訳者 による品質に近いものを得ようとすれば、後編集が必要になるケースがほとんど である。 このようなシステムの１つとして、Carnegie Mellon UniversityのCenter for M achine Translationが、英語から日本語への翻訳及び日本語から英語への翻訳用 として設計したKBMT-89がある。これは、対話式明瞭化（つまり、文書を明瞭に するための編集）を支援 する、知識系ドメインモデルで動作すろ。しかし、この対話式明瞭化は、通常、 著者と対話的に行うものではなく、明瞭化できない曖味な文章に遭遇すると、シ ステムはそこで一旦処理を停止し、一連の多肢選択式質問を著者又は翻訳者に尋 ねながら、曖味さを解決しようとするものである。さらに、KBMT-89は、定義の 行き届いた制御入力言語を適用していないため、いわゆる翻訳者支援相互明瞭化 で作成されたテキストには、後編集が必要となる。 このような事情から、前編集及び後編集の不要な翻訳システムが、有利になるも のと考えられる。 発明の概略 本発明は、一言語文書開発及び多言語翻訳用統合コンピュータ系プロセスのシス テムである。対話式コンピュータテキストエディタは、テキストの作成で著者が 使用する自然言語サブセットに対する語彙及び文法上の規約を厳守し、翻訳可能 なテキストを作成するために、テキストの明瞭化に関して著者を支援する。この 結果得られた翻訳可能ソース言語は、ターゲット言語の内の１言語に機械翻訳さ れ、翻訳後のテキストの後編集は一切必要としない。 図の簡単な説明 図１(a)及び１(b)は、本発明の構造の高水準ブロック図である。 図２は、本発明の動作の高水準フローチャートである。 図３は、MT120の高水準の情報の流れ及び構造ブロック図である。 図４は、情報要素の例である。 図５は、ドメインモデル500のブロック図である。 図６は、言語エディタ130の動作を示す、高水準フローダイアグラムである。 図７は、用語チェッカー610の動作を示すフローダイアグラムである。 図８は、明瞭化ブロック630の高水準フローダイアグラムである。 図９は、MT120の情報の流れ及び構造ブロック図である。 本発明の詳細な説明 １．統合システムの概要 本発明のコンピュータ系システムは、以下の機能統合を達成する。 1) 文書開発のためのオーサリング環境 2) 前編集及び後編集を必要としない、多言語への正確な機械翻訳モジュール 多言語文書の作成にこの技術を適用すれば、常に正確、迅速、且つコスト面でも 有利な翻訳が、量の大小に関係なく、ソース言語及び翻訳ターゲット言語両方で 、情報の発行とほとんど同時に得ることができる。 ソース言語オーサリング機能と翻訳機能を連係するかどうかは、以下の２つの方 針に基づいて決定する。 1) 多国籍・多言語ビジネス環境では、情報が様々なユーザ言語で提供できる ようになるまでは、開発が完了したものとは考えられない。 2) 一体化したフレームワーク内でオーサリングプロセスと翻訳プロセスを組 み合わせれば、効率の向上につながる。 図１(a)は、統合オーサリング及び翻訳システム(IATS)105の高水準ブロック図で ある。 IATS 105は、任意の言語でのドキュメンテーションのオーサリングや様々な他言 語への翻訳において、組織団体を支援するための専用コンピューティング環境を 提供する。これら２つの機能は、以下のブログラムグループを統合することによ ってサポートする。 1) オーサリング：プログラムの１つのサブグループは、対話式コンピュータ テキストエディタ(TE)140を提供する。このエディタは、自然言語のドメイン依 存サブセットである、サブセット指定規約ソース言語(CSL)の語彙及び文法規約 内で、著者が、一言語テキストを作成できるようにするものである。さらに、TE 140は、前編集することなくテキストを翻訳するために、テキストの明瞭化ブロ セスで著者を援助し、翻訳用テキストが準備できるようにする。 2) 翻訳：プログラムの別のサブプログラムとして、機械翻訳(MT)120機能が ある。これは、ジェネレータモジュールにプログラムされているあらゆるターゲ ット言語へ、後編集の必要がないようにCSLを翻訳するための機能である。 翻訳を中心コンポーネントとするシステムに関しては、現在のところ、本発明に よる一体化フレームワーク内でのオーサリング機能と翻訳機能の統合が、前編集 及び後編集を除去するための唯一の考案である。 テキストエディタ(TE)140は、CSLによる文書作成で、著者及び編集者を支援する ための一連のツールである。これらのツールは、著者が、適切なCSL語彙や文法 を用いて文書を書くための助けとなる。TE 140は、著者160と（又は、その逆方 向に）直接通信する。 図１(b)では、IATS 105が、オーサリング機能及び翻訳機能を実行するために、( 1)規約ソース言語(CS)133、(2)テキストエディタ(TE)140、(3)MT 120、(4)ドメ インモデル(DM)137の４つの主要部に分類されている。テキストエディタ140には 、言語エディタ130と図形エディタ150が含まれる。さらに、全プロセスの制御を 行うために、ファイル管理システム(FMS)110が提供されている。 CSL 133は、翻訳すべき著者の文書のドメインを、文法及び用語に含むソース言 語のサブセットである。CSL 133は、前編集や後編集なしに翻訳を行うために必 要となる、用語及び文法構造を指定することによって定義する。 TE 140は、CSLでの文書作成で、著者及び編集者を支援するための一連のツール である。これらのツールは、著者が、適切なCSL語彙や文法を用いて文書を書く ための助けとなる。LE 130は、テキストエディタ140を介して、著者160と（又は 、その逆方向に）通信する。著者に対しては、テキストエディタ140との両方向 通信が、ライン162を通じて可能になっている。LE 130は、使用した語や句がCSL にあるかどうかの情報を、著者160に伝える。該当文書の情報ドメインに関連す る用語がCSLに見つからない場合、このLE 130が、CSL内の類義語を提案する機能 を備えている。LE 130は、また、テキストがCSL文法規約を満足しているかどう かを著者160に伝えるとともに、構文は正しくても意味的に曖昧な文章が存在す る時は、その明瞭化において著者を支援する。 MT 120は、MTアナライザ127とＭＴジェネレータ123の２つの部分から構成されて いる。MTアナライザ127の機能としては、文書をCSLに準拠させるための文書解析 とインターリングア テキスト生成の２つがある。ここで得られた分析済みのCSL準拠テキストが、該 当する外国（ターゲット）言語180へ翻訳されることになる。MT 120は、インタ ーリングアに基づく翻訳アプローチを採用している。つまり、文書を他言語へ直 接翻訳するのではなく、まずMTジェネレータ123で、インターリングアと呼ばれ る言語に依存しないコンピュータ可読形式に文書を変換し、次に、得られたイン ターリングアテキストを翻訳するようになっている。この結果得られた翻訳物に 対しては、後編集が不要である。MT 120のバージョンは、各言語別に作成し、イ ンターリングアテキストから外国語テキストへの翻訳を支援するよう設計された 一式の知識ソースが、その主な構成要素となっている。ただし、新しいターゲッ ト言語を追加する場合は、MTジェネレータ123を個別に新規開発することが必要 である。 全機能の稼動時、CSL文法規約は満足していても意味が曖昧となっている文章が 見つかった場合、その文章の別の解釈から適切なものを選択する由の問い合わせ が、LE 130から著者160に対して行われることがある。これは、明瞭化として知 られるプロセスである。該当するテキストが、CSL用語だけから構成され、しか もCSL文法規約を全て満足するものとLE 130が判断すれば、このテキストにCSL承 認ラベルが付けられ、この明瞭化は未定状態となる。以降で説明するように、明 瞭化に関しては、著者に見えるテキスト形式を変更する必要はない。テキストの 明瞭化が完了すれば、ターゲット言語180への翻訳が開始できることになる。 このLE 130は、実際には、テキストや表の作成で著者及び編集者に必要となる、 ワードプロセッサ機能を備えたテキストエディタ140の延長機能として提供する 。図形エディタ150は、図形の作成に使用する。図形エディタ150は、テキストエ ディタ140を介し、図形のテキストラベルをアクセスするためのものであり、こ れらのテキストラベルに対してもCSL承認が得られるようにする。 LE 130は、(エディタ140を介して)MTアナライザ127と通信し、明瞭化処理中は、 両方向ソケット間ラインで、このMTアナライザ127を介してDM 137と通信する。 本発明の好ましい具体化では、DMが、MTアナライザ127へ情報を提供する知識ベ ースの１つとなる。DM 137は、MTアナライザ127及びLE 130が使用するCSL用語に 関する宣言知識の記号表現である。 図２は、IATS 105の動作の高水準フローチャートである。MT 120、LE 130、テキ ストエディタ140、及び図形エディタ150は、全てFMS 110によって制御されてい る。IATS 150が正しく動作するために必要な制御情報は、制御ライン111〜113を 介して提供される。 まず、著者160が、FMS 110を使って編集の対象となる文書を選択すると、FMS 11 0は、テキストエディタ140を開始し、指定された文書のファイルを表示する。こ こで著者は、ブロック160及び220に示すように、テキストエディタ140を使って 、制約がなく、曖味さを含むテキストをIATS 105へ入力することができる。著者 160は、標準エディタコマンドで文書を作成・修正し、CSL準拠チェックの準備を 行う。なお、ここでは、著者が、CSL規約を十分考慮した上でテキストを入力す るものと仮定する。次に、CSLへの準拠を達成するために、著者は、システムの フィードバックに応答しながら、決められた語葉や文法規約への違反箇所を修正 する。これは、当然、全く制約のない初期のテキスト入力よりも効率的であるが 、最初から全く制約のないテキストを入力した場合でも、本システムは正しく動 作する。 著者とLE 130との対話は、マウスのクリック又はキーボードのキーストロークコ マンドによって行う。ただし、この入力方法に限定せず、本発明の適用範囲内で 、スタイラスや音声などの別の入力方法を適用することも可能である。入力の一 例としては、CSLチェックを実行するためのコマンドや、与えられた語や句を定 義し、その用例を見つけるためのコマンドを挙げることができる。 明瞭さやスタイルの点で、CSLテキストにまだ問題が残っている場合は、ブロッ ク230に示すように、さらにCSL準拠を分析し、知識ベースの文法規約の準拠をチ ェックする。このフィードバックは、間違いを訂正するために、フィードバック ライン215を介して著者に与えられる。つまり、CSLに準拠していない語、句、及 び文章に関する情報は、LE 130から著者160に伝えられることになる。最後に、 曖昧な文章がテキストにあるかどうかのチェックが行われる。この時LEは、文章 の意味として適切な解釈を選択するよう著者に問い合わせる。このプロセスは、 テキストが完全に明瞭となるまで繰返される。 著者が、必要な箇所全部の訂正を終えると、分析段階230が完了し、明瞭化及び 制約済みテキスト240が、MTアナライザ及びインタプリタ250へ送られる。インタ プリタは、アナライザの構文部と共にMTアナライザ127内に存在し、明瞭化及び 制約済みテキスト240をインターリングア260へ翻訳する。インターリングア260 は、さらに、ジェネレータブロック270によってターゲットテキスト280に翻訳さ れる。なお、インターリングアテキスト260は、図３に示す通り、多言語306〜31 0への翻訳が可能な形式となっている。 このように、特定の用語及び文法規約に準拠する文書の作成を、著者に規定し、 可能とすることによって、後編集を必要とすることなく、制約言語テキストから 外国語への正確な翻訳を達成することができる。曖味と思われる文章や翻訳不可 能と思われる語は、翻訳前 の段階で、LE用語チェックブロック217及び分析ブロック230で、著者に修正及び （又は）明瞭化させているため、後編集は不要である。 ＩＩ．機能ブロックの詳細な説明 本発明の好ましい具体化では、32メガバイトのRAMを備えたDECstation、400メガ バイトのディスクドライブ、及び19インチのカラーモニタを、各著者の専用装置 として準備する。各ワークステーションには、ローカルディスクからのスワップ 用として最低100メガバイトを準備する。さらに、著者のワークステーションに 加え、２つのオーサリンググループに付き１台のDECserverを適用し、ユーザ数 は、ファイルサーバ１台に付き45以下とする。また、オーサリングワークステー ションは、イーサネットローカルネットワークに存在する。システムとしては、 ユニックスオペレーシングシステム（システムＶ(SYSV)系に対しては、バークレ ー標準分散(BSD: Berkeley Standard Distribution)系が好ましい）を適用し、 Ｃプログラミング言語コンパイラ及びOSF/Motifライブラリが利用できるように する。LEは、Motifウィンドウマネージャ内で稼動する。なお、本発明は、上記 のハードウェア及びソフトウェアプラットフォームに限定されるものではなく、 他のプラットフォームに対しても適用することが可能である。 Ａ．テキストエディタ 本発明の具体化では、最終的に分析され外国語へ翻訳されるべき情報を、著者が 入力できるようにするためのテキストエディタ140を提供することが好ましい。 市販のワードプロセッシングソフトウェアなら、任意のものを本発明で利用する ことが可能である。 ArborText(ArborText Inc., 535 West William St., Ann Arbor, MI 48103)が提 供するSGMLテキストエディタ140の利用は、好ましい適用例である。SGMLテキス トエディタ140は、著者及び編集者に必要となる基本的なワードプロセッシング 機能を提供し、(Annapolis, Marylandの)Intercapが提供する図形作成用ソフト ウェアと組み合わせて使用することができる。 本発明は、標準汎用マークアップ言語(SGML: Standard Generalized Markup Lan guage)タグを使ってテキストを作成するため、SGMLテキストエディタ140を適用 している。SGMLは、電子文書の構造を記述するための国際標準マークアップ言語 であり、広範囲の文書処理や交換タスクの条件を満足するように設計されている 。SGMLタグを利用すれば、文書の内容(テキスト、両像など) 及び論理構造（章 、段落、図、表など）を記述することができる。より多量で複雑な電子文書の場 合は、文書の物理構造をファイルに記述することも可能で ある。このように、SGMLは、複雑さや量に関係なく、任意の種類の文書を、シス テムやアプリケーションに依存しない形で記述できるように設計された言語であ る。この独立性によって、誤解釈やデータの喪失を心配することなく、異なるア プリケーションのシステム間で文書を交換することが可能になる。 SGMLは、マークアップ言語、つまり、任意のテキストから得られる従来の構造情 報に加え、コード化情報を使ってテキストに″マーク付け（マークアップ）″又 は注釈付けを行うための言語である。ほとんどの場合、この言語は、電子文書内 の様々な位置に、文字列として挿入される。この文字列は、その初めと終わりを 示す特別な文字によって、回りのテキストと区別することができる。正しいマー クアップがテキストに挿入されているかどうかは、SGMLタグをチェックするため のソフトウェアを使えば、適時確認することができるようになっている。このマ ークアップは、汎用的であり、特定のシステムやタスクに特有のものではない。 SGMLタグについての詳細は、国際規格(ISO)8879、Information processing-Text and office systems-Standard Generalized Markup Language(SGML), Ref. No.I SO 8879-1986(E)を参照のこと。 SGMLの利用によって、以下の機能が達成できる。 (1) 文書の分断又は翻訳単位への分割。テキストエディタ140ソフトウェアは 、ソース入力テキストの翻訳可能単位を識別するために、句読点とSGMLタグの両 方を使用する（たとえば、セクションのタイトルを識別するためには、SGMLタグ が必要となる）。 (2) 翻訳すべきでない単位の保護（隔離）。全ての語や文章は、前もって予 想することのできない制約言語（たとえば、名称や住所など）や、（容易には） 完全に指定しきれない用語のクラス（たとえば、部品番号や機械からのエラーメ ッセージなど）に属することが前提となってはいるが、SGMLタグを使えば、チェ ックの対象とならない部分をシステムに指定することも可能である。 (3) (2)で述べた内容（たとえば、部品番号など）の識別。 (4) 部分的な文章の翻訳（たとえば、丸付き項目など）。 (5) テキストの構造を識別することによって行う表翻訳支援（一度にセル１ 個）。この機能は、(1)で述べた機能と似ている。 (6) (2)、(3)、(4)、(5)を通じ、（以降で述べる）品詞解析プロセスの支援 。 (7) 曖味な文章の正しい解釈を指定できるようにするために、ソーステキス トに不可視タグを挿入することによって行う明瞭化の支援。 (8) 特別な扱いを必要とするテキスト種類の識別による、通貨や数学単位の 翻訳支援。 (9) テキストの一部を、翻訳可能な部分としてラベル付けするための手段の 提供。言い換えれば、任意のテキストが、以降で述べるプロセスを経て、後編集 することなく翻訳できる明瞭な制約テキストになった由を承認することである。 これまで、完全な″本″を表現する電子文書（図形を含まないテキストのみ）は 、著者によって（テキストエディタ140を使って）作成せれてきた。これは、全 ての作業が一人の著者によって行われ、作成した情報の再利用が容易でないこと を意味する。一方、本発明は、より小さな部分又は情報要素の集まりから、本（ マニュアル、文書）を編集（又は作成）するようになっているため、複数の著者 によって作業を行うことができる。これは、再利用性の向上につながる。１つの 情報要素は、特定ドメインに関するサービス情報の最小単位として定義される。 なお、ここでは、情報要素の利用が、本発明の好ましい具体化となってはいるが 、本発明によれば、情報要素を利用しなくても、正確で明瞭な翻訳文書を作成す ることができる。 図４は、情報要素410の例を示すもので、″ユニーク″なヘッダ415、″ユニーク ″なテキストブロック420、″共用″図形430、″共用″表435、及び″共用”テ キストブロック425から構成されている。 ″ユニーク″な情報とは、それを含む情報要素にのみ適用できる情報のことであ る。従って、″ユニーク″な情報は、情報要素450の一部としてファイルされる ことになる。 ″共用″オブジェクト（図形、表、又はテキストブロック）とは、情報要素内で ″参照される″情報のことである。″共用″オブジェクトの内容はオーサリング ツールで表示されるが、ファイルされた情報要素450内のみで″ポイント″され る。 ″共用″オブジェクトと情報要素の違いは、″共用″オブジェクトが、それだけ では意味をもたない（つまり、それだけでは、独立的な情報を伝えることができ ない）という点である。それぞれの″共用″オブジェクトは、ブロック450に示 すような個別のファイルを形成する。 情報要素は、″ユニーク″な情報ブロック（テキスト及び（又は）表）と１つ以 上の″共用″ オブジェクトから構成される。なお、″ユニーク″なヘッダ415及び″ユニーク ″なテキスト420は、″共用″図形430、″共用″表435、及び″共用″テキスト4 25と組み合わさっている。１つの完全な文書（本）は、１つ以上の情報要素から 構成される。 ″共用″オブジェクトは、″共用″ライブラリに保存される。ライブラリの種類 としては、″共用″図形ライブラリ460a、″共用″表ライブラリ460b、″共用″ テキストライブラリ460c、″共用″音声ライブラリ460d、及び″共用″ビデオラ イブラリ460eがある。共用オブジェクトは、１回保限り存されるだけである。個 別の情報要素内で使用する時は、元の共用オブジェクトへの″ポインタ″が、情 報共用ファイル450に配置される。これによって、必要となるディスク容量を最 小限に抑えることができる。元のオブジェクトを変更すると、そのオブジェクト を″ポイント″している情報要素全部が、自動的に変更される。共用オブジェク トは、任意の種類の出版物に使用することができる。 ″共用情報要素″とは、１つ以上の文書で利用される情報要素のことである。た とえば、リリースライブラリ470の中の４つの情報要素は、文書480及び485を作 成するために利用されている。 著者とLE 130間の通信は、メニューオプションなどの標準SGMLエディタ機能の拡 張又は別ウィンドウとして提供されるLEユーザインタフェース(UI)の仲介の下で 行われる。UIは、CSLチェッカー及びCSL用語ルックアップへのアクセスや制御を 提供・管理するもので、ユーザがCSL LEと対話するための主なツールでとなって いる。″ユーザインタフェース″という用語は、ソフトウェアシステム全体への インタフェースを意味する場合が一般的であるが、ここでは、CSLチェッカー、 用語ルックアップ機能、及び明瞭化機能へのインタフェースを意味するものと仮 定する。 UIでは、さらに、(a)LEのとる動作、(b)それらの動作の結果、及び(c)その結果 発生する動作に関する明確な情報を提供することが必要である。たとえば、UIを 介して起こった動作によって、規定時間以上のリアルタイム休止が発生した時は 、簡潔なメッセージを使って、遅延の可能性をUIから著者へ通知することが必要 である。 著者は、テキストエディタ140のプルダウンメニューのオプションを選択するこ とによって、LEの機能を実行することができる。著者の利用できるオプションと しては、CSLチェック（用語チェック及び文法チェック）及び用語ルックアップ の開始やこれらの機能からのフィードバックの確認がある。この場合、著者は、 現在表示中の文書からのチェックの開始、又は与えられた語やフレーズの用語ル ックアップを依頼することができる。 UIは、文書内に見つかった非CSL言語のインスタンスを、それぞれ明確に指摘す る。非CSL言語の指摘方法としては、色の利用や、SGMLエディタウィンドウ内の 字体又は文字サイズの変更が考えられる。UIは、非CSL語に関する全ての既知情 報を表示する。たとえば、ある語は非CSL語であるが、CSLの類義語がある由のメ ッセージを、類義語リストとともに表示することが考えられる。 非CSL語の代用語リスト（たとえば、代用スペルやCSLの類義語）が、用語チェッ カーの結果報告に含まれている場合、著者は、それらの代用語の中から１つを選 択し、文書内の用語と自動的に置き換えるよう指定することができる。場合によ っては、適切な形式になるように、選択した代用語に修正を加えなければならな いこともある（つまり、適切な語尾の追加など）。 著者から用語情報の依頼があると、UIは、代用スペル、類義語、定義、及び（又 は）指定した用語の用例を表示する。 UI内では、著者は、チェッカー情報と用語ルックアップ情報間を、迅速且つ容易 に移動することができる。これによって、非CSL言語を削除するための文書修正 プロセスで、情報検索（たとえば、類義語のルックアップ）を行うことが可能に なる。 ほとんどの場合、UIは、非CSL用語を自動的にCSL用語と置き換えるため、ユーザ は、CSL語が正しい形式になるよう修正を加える必要はない。しかし、用語チェ ッカーでは、（以降で述べるように）文書の品詞解析は行わないため、語の正し い形式を識別できない場合も発生する。以下のキャプションを例にとると、動詞 ″view″はCSLではないが、CSL類義語として″see″が存在する。 Direction of Crankshaft Rotation (when viewed from flywheel end) 用語チェッカーでは、″viewed″の代用語として″saw″を提供すべきであるか 、それとも″seen″を提供すべきであるのか分からない。この場合、当然、両方 を提供し、著者に正しい方を選択させるのが適切である。しかし、置き換え用と して適切な代用語を、毎回提供できるとは限らないため、許される限り、LE 130 によって、正しい形式での置き換えオプションリストを提供するようにしている 。ただし、提案のCSL語や句を、実際に文書へ挿入する前に、著者が編集しなけ ればならない場合も発生する。 最後に、LE UIは、文章の意味を明瞭化するための支援を行う。これは、代用の 解釈リストを著者に提供し、その中から適切な解釈を著者が選択できるようにし 、著者の選択を示すタグを該当する文章に付けることによって行っている。 Ｂ．ファイル管理システム ファイル管理システム(FMS)110は、IEリリースライブラリ470及びSGMLテキスト エディタ140に対する、署者のインタフェースとして動作する。一般に、著者は 、IEを選択し、FMSインタフェース内のIEに該当するファイルを指定することに よって編集を行う。この結果、指定したIEに対するSGMLエディタセッションが、 FMS 110によって開始・管理される。完成した文書は、人間の編集者又はFMS制御 機能を通じて情報インテグレータヘ送られることになる。 Ｃ．制約ソース言語(CSL) 今日の技術文書の複雑性を考えると、制約のない自然言語テキストの上品質機械 翻訳は、実際的に見て不可能である。ここで大きな問題となっているのは、言語 の性質である。ソーステキスト翻訳で重要なプロセスは、元の意味をターゲット 言語に反映するということである。意味は、構造信号の表面下に隠されているた め、この明白な信号を分析することが必要になる。このような分析から得られた 意味は、ターゲット言語の信号生成プロセスに使用される。しかし、分析や生成 を妨げる言語本来の性質が、最も大きな翻訳の障害となるケースもある。 このような言語の性質としては、以下のものを挙げることができる。 １．曖昧な内容で１つ以上の意味を持つ語 例：Make it with light material. [材料は、″暗くない″のか、それとも″重くない″のか？］ ２．構成が曖味な語 例：ドイツ語″Arbeiterinformation″は、 ″information for workers″[Arbeiter + lnformation] 又は、 ″formation of female workers″[Arbeiterin + Formation]である。 ３．構文的に１つ以上の役割を果たす語 Roundは、以下に示すように、名詞(N)、動詞(V)、又は形容詞(A)として使用す ることができる。 (N) Liston was knocked out in the first round. (V) Round off the figures before tabulating tem. (A) Do not place the cube in a round box. ４．語の組み合わせで、それぞれの語が複数の構文的役割を持つ場合 例：British Left Waffles on Falklands. [Left Wafflesが、Ｎ＋Ｖの場合、これは、British Leftに関する見出しであ る。] [Left Wafflesが、Ｖ＋Ｎの場合、これは、Britishに関する見出しである。］ ５．曖昧な構造での語の組み合わせ 例：Visiting relatives can be boring. [″Visiting of relatives″がboringなのか、″relatives who visit″がbor ingなのか？] 例：Lift the head with the lifting eye. [″Lifting eye″は、計器なのか、それとも″head″の機能なのか？] ６．曖昧な代名詞の使用 例：The monkey ate the banana because it was... [″it″は、″monkey″を指すのか、それとも″banana″を指すのか？] さらに、生成の問題も加わり、機械翻訳の全体的な難しさを増している。 このような翻訳の問題は、言語が持つ言語的現象の範囲を減らすことによって、 大幅に解消することができる。二次言語の扱う範囲としては、限られたドメイン 内のオブジェクト、プロセス、及び関係がある。二次言語には、語彙の面での限 界はあるが、文法の面で限界があるとは限らない。制御された環境では、二次言 語の語葉及び文法両方を制約することが、機械翻訳の促進対策となる。 語葉の制約は、類義語を除くことによってサイズを限定するだけでなく、できる 限り単位１つに付き意味が１つとなるような、語彙単位の専用化を行うことによ って、語彙の曖昧さを制御することもできる。上記１、２、及び４の例で示した ような問題は、この制約によって回避できることは容易に推測できる。また、文 法規制を設ければ、代名詞化（上の例６）といったプロセスは容易に除外するこ とができ、語の追加、冗長的な語の繰返し、又は書き直しを行えば、意味をより 明確化することもできる。この条件の適用に関するパラメータを、以下の例で示 す。 制約のない曖味な英語（解釈としては、以下のA、B1、B2がある）： Clean the connecting rod and main bearings. 曖昧な英語A： Clean the connecting rod bearings and the main bearings. 曖味な英語B1： Clean the main bearings and the connecting rod. 曖昧な英語B2： Clean the main bearings and the connecting rods. 語彙及び文法規制の数と種類は、制約二次言語の開発目的によって大きく異なっ てくる。 以上のことから、本発明は、制約言語範囲内での文書オーサリングに限定される 。制約言語とは、特定のユーザアプリケーション用として開発されたソース言語 （たとえば、アメ リカ英語）に対する二次言語である。制約言語又は制御言語の説明については、 ここでも参考として含めてある、Adriaens et at，From COGRAM to ALCOGRAM： Toward acontrolled English Grammar Checker ，Proc．of Coling-92，Nantes ( Aug．23-28，1992) を参照のこと。機械翻訳という観点からすれば、制約言語の 目標は、以下のようになる。 １． ソース言語の一貫したオーサリングを促進するとともに、明確で率直な 執筆を奨励すること。 ２． ユーザ文書に対して迅速で正確な高品質の機械翻訳を可能とするような 、節操あるソーステキストのフレームワークを提供すること。 文書の文法をCSLに準拠させるために、著者が守らなければならない規則のこと を、CSL文法規約と呼ぶ。また、MTコンポーネント内のCSLテキストを分析するた めに適用する、CSL文法規約の演算的実施のことをCSL機能文法と呼び、これは、 Martin Kayが開発し、以降R. Kaplan及びJ. Bresnanによって改良された周知の 形式主義に基づくものである（参考として含めてある、Kay, M.,″Parsing in F unctional Unification Grammar,″in D. Dowty, L Karttunen and A. Zwicky ( eds.), Natural Language Parsing: Psychological, Computational, and Theor etical Perspectives , Cambridge, Mass.: Cambridge University Press, pgs. 251-278(1985)、及びKaplan R. and J. Bresnan,″Lexical Functional Grammar : A formal System for Grammatical Representation,″in J. Bresnan(ed.), T he Mental Representation of Grammatical Relations ，Cambridge, Mass.: MIT Press, pgs.172-281(1982)を参照のこと）。 本稿では、以降、″CSL内″又は″非CSL″という語又は句が、頻繁に出現する。 ここでは、CSLによって統制される用語規制の種類を説明するとともに、″CSL内 ″という表現の意味を明確化する。 英語では、同一の語や句が複数の異なる意味を持つ場合がある。たとえば、汎用 辞書には、″leak″という語に対して次のような定義がある。 (1)動詞：違反又は欠陥によって、物の脱出を許すこと。 (2)動詞：公式な承認又は認可なしに情報を公開すること。 (3) 名詞：容器や管から、物が漏れ出たり、入ったりできる割れ又は開口部。 これらの異なる意味は、それぞれ語又は句の″語義″と呼ぶ。与えられた文章内 で、語又は句がどの語義を意味するのかを理解するために、人間が用いる全知識 を備えていないMTシステムでは、このような単一の語又は句が持つ複数の語義が 問題となる。システムでは、特定の文章内で使用される語の品詞（名詞、動詞、 形容詞など）を見分けることによって、多数の語の曖昧さを、ある程度解消する ことができる。これが可能な理由は、上記の″leak″でも示した通り、品詞の違 いによって、語の定義も異なってくるからである。 しかし、CSL仕様では、MT 120で解消できないような曖昧さを回避するために、 それぞれの品詞に対して語又は句の語義が１つとなるような仕様の設定に努めて いる。従って、語又は句が″CSL内″の時は、最低１つの品詞としてその語又は 句が使用できることを意味する。たとえば、CSLで執筆作業を行っている著者は 、上記(1)及び(3)の品詞として″leak″という語を使用することはできるが、(2 )の品詞としては使用できない。ただし、語又は句が″CSL内″であるとは言って も、その語又は句のあらゆる用法が翻訳できるとは限らない。 ある語又は句が″CSL内″の場合、該当するCSL語義を表現できる語又は句の全語 形も、CSL内となる。上の例では、動詞″leak″を使用できるだけでなく、その 関連動詞語形″leaked″、″leaking″、及び″leaks″も使用できることになる 。名詞としての語又は句がCSL内の時は、その単数形及び複数形も使用すること ができる。ただし、１つ以上の品詞として機能する句は例外である。従って、こ の発見的方法は、曖昧な句の場合にはその妥当性が低下する。 用語とは、特定言語又は二次言語で使用される語及び句の集まりである。限定さ れたドメインは、限られた範囲内の経験に関する情報を、伝達又は表現するため に使用する限定用語で表現される。限定されたドメインの例として農業を考えて みると、農業機器や農業活動に関する用語が、この分野の限定用語となる。なお 、MTコンポーネントは、１種類以上の用語に対して作用する。機械翻訳用の語お よび句は、MT語彙に保存される。用語は、(1)機能項目、(2)一般内容項目、及び (3)専門技術語の３つのクラスに分類することができる。 英語での機能項目は、文章内で、主に考えをつなぎ合わせる働きをする単一の語 又は語の組み合わせである。このような項目は、英語のほぼあらゆる種類の書類 で必要になる。このクラスに含まれるものとしては、前置詞（to、 from、 with、 in front ofなど）、接続詞（and、 but、 or、 if、 when、 because、 since、 while など）、限定詞（the、 a、 your、 most of）、代名詞（it、 something、 anybody など）、一部の副詞（no、 never、 always、 not、 slowlyなど）、及び助動詞（sh oud、 may、 ought、 mustなど）がある。 一般内容語は、その大部分が、私達の回りの世界を表現するために使用され、共 通な一般の人間経験を表現することがその主な用途となる。 文書では、人間経験のかなり特定な部分（たとえば、機械やそれらの状態）が注 目されることが一般的である。従って、MTでは、比較的に一般用語が制限される ことになる。 専門技術語は、技術内容語や句及びユーザアプリケーション特有用語から構成さ れる。技術内容項目とは、特定分野の作業やドメインに特有の語や句のことであ る。ほとんどの技術語は、部品、コンポーネント、機械、材料などのように、項 目を命名するための名詞から成っている。ただし、動詞、形容詞、副詞などの他 の語のクラスを含む場合もある。これらの語は、当然、日常会話で頻繁に使用さ れることはないため、一般内容語に対立するものとなる。 技術内容句は、上記すべてのクラスから成る複数の語の列である。技術ドキュメ ンテーション用語としては、このような句が、最も典型的なものとなる。ユーザ アプリケーション特有用語は、ユーザアプリケーションが作り出した独特な語や 複合語を含む専門用語の一部であり、製品名、文書のタイトル、ユーザの使用す る略語、及びフォーム番号が、これに相当する。 便利で完全な用語の開発は、どのドキュメンテーション作業においても重要であ る。作成したドキュメンテーションを翻訳するとなれば、用語が、その翻訳作業 の重要な資源となる。MT 120は、人称（I、 me、 myなど）、性別（hers、 sheなど ）、及び代名詞（it、 themなど）の用法を除けば、英語で利用できるほとんど全 ての機能項目を、扱うことができるように設計されている。これには、英語の一 般語からの技術″借用語″（″truck″や″length″など）が多数含まれる。し たがって、制約言語に含まれる用語の大部分は、特別な分野の物やプロセスを表 現するための、１つ以上の語の″特別な″（たとえば、技術）用語から構成され ることになる。特別な分野に関する完全な概念を表現できるという点からすれば 、用語は、完全なものであると言うことができる。 簡素化されたものとはいえ、完全な用語の開発は、IATSシステム105の成功に大 きく貢献する。制約言語は、用語の正しい使い方と誤った使い方を指定すること によって、迅速且つ正確で高品質の機械翻訳を助成できるような文書作成の可能 性を、約束するものである。 用語項目は、明確な考えを伝えるとともに、読者層に対して適したものでなけれ ばならない。性差別的、口語的、慣用的、過度に複雑又は専門的、曖昧な、又は 通信を妨げるよう な用語は、避けるべきである。また、一般的に受け入れられている文体的な留意 点は、MT志向処理では必ずしも必要とは限らないが、通常、文書作成の重要なガ イドラインとなる。 なお、制約ソース言語及び（又は）一般の言語に関する本稿の説明は、その大部 分が、アメリカ英語を中心としているが、類似的な比較は、他の全ての言語に対 しても適用できることである。ここで説明するシステム100に関しては、アメリ カ英語がソース言語であるべき理由は、本質的に全くない。事実、システム100 は、アメリカ英語を唯一のソース言語として動作させるようには設計されていな い。ただし、LE 130及びMT 120と相互作用するデータベース（たとえば、ドメイ ンモデル）は、該当するソース言語の制約に基づいて変更することが必要である 。 また、標準アメリカ英語綴字法の規則は、厳守することが必要である。″throug h″に対する″thru″、″molding″に対する″moulding″、又は″odometer″に 対する″hodometer″などの、標準以外の綴りは避けるべきである。大文字で綴 る語（たとえば、On-Off、Value Planned Repairなど）は、用語の特別な意味を 示す場合にのみ使用すべきであり、このような用語は、ユーザアブリケーション 用語としてリストすることが必要である。標準以外の大文字化（BrakeSaverなど ）に関しても、同様のことが言える。また、略語（ROPS、API、PINなど）を使用 する場合も、ユーザアプリケーション特定用語としてリストすることが必要であ る。なお、数字形式、測定単位、及び日付に関しては、一貫性を守ることが重要 である。 さらに、制約言語回復用語は、該当する制約言語の意味に従って使用することが 必要である。これは、MTが、常に適切な制約言語の語義を使って、語の翻訳を行 うことを保証するためである。英語の中には、１つ以上の構文カテゴリーに属す るものがある。制約言語では、このような構文的に曖昧な語は、曖昧さを明確化 できるような構造内で使用することが必要である。 分野によっては、そのドメインの特殊な性質から、長い複合名詞の頻繁な使用と いう１つの大きな問題が発生する。複合名詞の修飾関係は、言語によってその表 現も異なってくる。このような修飾関係は、常にソーステキストから解明でき、 ターゲット言語で表現できるとは限らないため、以下のような性質を持つ複合名 詞は、MT語彙に含めることが考えられる。 ●ユーザアプリケーション特定用語内の技術用語 ●１語以上から成る複合用語 複雑な名詞一名詞の合成は、できる限り避けるべきである。しかし、語彙にリス トした用語の中には、このような重要なドキュメンテーションの性質をMTで取り 扱うことが可能な場合もある。ただし、名詞一名詞の合成は、英語では非常に一 般的な性質であるが、他の言語でもそうとは限らないため、制約言語の作成規定 は、対象となる特定のソース言語によって異なってくる。 英語では、動詞と前置詞、副詞、又はその他の品詞を組み合わせた、動詞−不変 化詞の形式が豊富である。この場合、不変化詞と動詞の間に目的語や句が挿入さ れるケースが多く、入力テキストのMT処理では、これが複雑さや曖昧さの原因に なる。従って、このような動詞・不変化詞の組み合わせは、できる限り書き直す ことが望ましい。これは、通常、単一の動詞に置き換えることによって行うこと ができる。たとえば、 ●″have to″の代わりに″must″又は″need″を使用する。 ●″refer to″の代わりに″consult″を使用する。 ●″turn the motor on″の代わりに″start the motor″を使用する。 また、できる限り完全な用語又は考えを適用することが必要である。これは、誤 解釈の可能性がある場合、特に重要である。たとえば、以下のような句では、 ″Use a monkey wrench to loosen the bolt...″ wrenchという語を、省略することはできない。技術的な知識を有する人間ならば 、この語がなくても、暗示されている意味を理解することはできるが、翻訳プロ セスでは、意味を明確に示すことが必要である。従って、CTEテキストで使用す る用語は、できる限り明示的に表現し、略語や短縮用語は、語彙的に完全な表現 となるよう書き直すことが必要である。 以下に、別の例を考えてみよう。 ″If the electrolyte density indicates that...″ これは、以下のように考えを正確に表現すれば、意味がより明確で完全になる。 ″If measurement of the etectrolyte density indicates that...″ また、以下の例で示すように、語や句が欠けている文章では、意味をより明確に するために、下線を引いた語を追加することが考えられる。 Turn the start switch key to OFF and remove the key. Pull the backrest(1)up, and move the backrest to the desired position. Jump Starting: make sure tha machines do no touch each other. このように、″ギャップ″を埋めると、考えがより完全になり、IATS 105による 正確な翻訳が、より確実となる。ギャップが原因となる翻訳ミスは、後編集が必 要となる一般的要因である。従って、ギャップは許されない。 口語又は会話英語では、非常に一般的な用語が頻繁に使用される。これは、曖昧 さの原因になるケースもあり、翻訳プロセスで解決することが必要である。たと えば、conditions、 remove、 faci1ities、 procedure、 go、 do、 is for、 make、 g etなどは、正しい語ではあるが、明確ではない。 以下のような文章では、 When the temperature reaches 32°F, you must take special precautions. ″reaches″という語は、温度が上昇しているのか、又は下降しているのかを伝 えることはできないため、いずれか（上昇又は下降）の語を使用した方が、テキ ストの読み易さを変えることなく、意味的により正確となる。 言語によっては、英語では常に区別するとは限らないものを、区別するケースも ある。たとえば、英語では、潤滑液や燃焼に使用する燃料のことをoilで総称し 、ディーゼルであるなしに関係なくfuelという語を使用する。同様に、doorとい う語は、孤立で使用し、どのような種類のdoorを指しているのか判断できないこ とがあり、この場合、car door、building door、又はcompartment doorなどが 考えられる。他の言語では、このような区別が必要となるケースも発生する。従 って、英語では、できる限り完全な用語を使用することが重要である。 Ｃ．ドメインモデル 知識系機械翻訳（KBMT）は、世界知識及び語彙単位やそれらの組み合わせに関す る言語的語義知識によって支援することが必要である。KBMTの知識ベースでは、 ″自動車は、車の一種である″、″ドアハンドルは、ドアの一部である″、加工 物は、（特性の中でも特に）″made-by″という特性によって特長付けられると いった、オブジェクトタイプの一般的な分類学的ドメインを表現できるだけでな く、オブジェクトタイプの特定なインスタンス（たとえば、″IBM″は、″corpo ration″というオブジェクトタイプのマーク付きインスタンスとして、ドメイン モデルに含める）や、（潜在的に複合となる）事象タイプのインスタンス（たと えば、米国大統領としてのジョージ・ブッシュの選挙当選は、複合動作″to-ele ct″のマーク付きインスタンスとなる）に関する知識を表現できることが重要で ある。知識ベースの存在学的な部分は、is-a、 part-ofなどの分類学構築リンク を通じて接続される多階層概念を形成する。概念は、同一リンクタイプ上で複数 の親を持つことができるため、このようにして得られた構造を、多階層と呼ぶ。 ドメインモデル又は概念語葉には、存在学モデルが含まれ、これは、特定ドメイ ンを記述するための積み木として利用される、基本分類（オブジェクト、事象タ イプ、関係、特性、場面など）の一様な定義を提供する。この″世界”モデルは 、比較的に静的であり、多様な相互関係を持つ存在学的概念のネットワークとし て構成される。アプリケーション（二次）世界の存在論の一般的展開は、この分 野でもよく知られている。関連文献としては、ここでも参考として含めてある、 Brackman and Schmolze, An Overview of the KL-ONE Knowledge representatio n System , Cognitive Science, vol.9, 1985、Lenat, et al, Cyc: Using Common Sense Knowledge to Overcome Brittleness and Knowledge Acquisition Bottl enecks , AI Magazine, VI:65-85，1985、 Hobbs, Overview of the Tacitus Proj ect , Computational Linguistics, 12:3, 1986、及びNirenburg et al, Acquisi tion of Very Large Knowledge Bases: Methodology, Tools and Applications , Center for Machine Translation, Carnegie Mellon University(1988)がある 。 存在学とは、重機器のトラブルシューティングや修理又はパーソナルコンピュー タとユーザ間の対話といった、特定の二次世界の言語独立型概念表現のことであ る。これは、ソーステキストをインターリングアテキストに解析し、得られたイ ンターリングアテキストからターゲットテキストを得るために、二次言語ドメイ ンで必要となる意味的情報を提供するものである。ドメインモデルでは、解析で の曖昧さを解消するのに十分な、意味上の制約を提供することが必要であり、ま た、存在学モデルでは、特定ドメイン記述用の積み木となる、基本存在分野に対 して一様な定義を提供することが必要である。 世界モデルでは、まず、存在学的概念が、オブジェクト(object)、事象(event) 、（無志向な行為者を説明するための）力(force)、及び特性(property)に分類 される。特性は、さらに、関係と属性に分類される。関係は、概念間のマッピン グ（写像）として定義される（たとえば、″belongs-to″は、あるオブジエクト を集合{*human*organization}にマッピングすることから、関係として分類され る）。また、属性は、特別に定義した値の集合への概念のマッピングとして定義 される（たとえば、″temperature″は、ケルビンスケールの程度の粒状性で、 物体を半オープンスケール[0,*]の値にマッピングする属性である）。概念は、 一般に、スロットがシステム内で完全に定義された特性となる、フレームとして 表現される。 ドメインモデルは、知識系機械翻訳だけでなく、あらゆる知識系システムで必要 となる。これは、翻訳分野で発生する概念の意味的階層を示すものであり、たと えば、オブジェクト*O-VEHICLEが、*O-WHEELED-VEHICLE及び*O-TRACKED-VEHICLE を含み、前者が、*O-TRACK、*O-WHEELED-TRACTORなどを含むといった定義になる 。この階層の底の部分は、CSLの用語に対応する特定概念であり、この部分を共 用K/DMと呼ぶ。正確な翻訳を行うためには、異なる概念が持つ役割に対して、意 味的制約を加えることが必要である。たとえば、*E-DRIVEという動作の行為者の 役割は、人間が果たさなければならないという事実は、*O-VEHICLEに対する意味 的制約となり、同様の制約が、あらゆる種類の車に対しても自動的に有効となる （この結果、それぞれのケースを、手動で個別にコーディングしなくても済む） 。ドメインモデルのオーサリング部分としては、非CSLの類義語に加え、著者が 各情報要素を組み立てる際に、便利なフィードバックとなるその他の情報をK/DM に追加する。 図５は、本発明が適用するドメインモデル(DM)の概念図である。DM 500は、TM 1 20及びLE 130が使用するCSL用語に関する、平叙文の知識を表現する。このDM 50 0は、主に、以下の３つの部分から構成されている。 １． ーネルドメインモデル(K/DM)510には、MTナライザ127及びLE 130の両方 で必要となる全部の語彙情報が含まれている。特に、カーネルには、関連する意 味上の概念、品詞、形態学的情報など、全てのCSL語葉用語（語及び句）が含ま れている。 ２． Tドメインモデル(MT/DM)520には、MTアナライザ127のみに必要となる情 報が含まれている。MTメインモデルは、翻訳での曖昧なマッピングや意味の確認 に利用する概念階層である。これには、概念の選択的制約及び概念の分類階層が 含まれる。 ３． Eメインモデル(LE/DM)530には、LE 130のみで必要となる情報が含まれ ている。これらの情報としては、CSL語彙用語に対する非CSLの類義語、CSL語彙 用語の辞書定義、及びCSL語彙用語の使用例がある。 カーネル/DM 510に含まれる語彙エントリは、各CSL語彙用語（語又は句）に対し て１つのみである。（″語彙エントリ″は、１つの語彙項目（つまり１つの語又 は１つの句）と、最低それに関連する意味的概念及び品詞から構成される。たと えば、″leak″という語が、名詞と動詞の両方としてCSLに含まれる場合、この 語に対しては、２つの語彙エントリが存在することになる。）各語彙項目は、定 義や不規則な語形変化といった、LE 130及び（又は）MT 120に必要な追加情報で 更新される。 共用K/DM 510は、CSLの洗練化と拡張を促進し、オーサリングや翻訳作業の繰返 しを不要とし、人間に読み易い構造を提供することによって、維持及び拡張を助 成する。 K/DM 510は、制約言語テキストの用語（語及び句）に関する、構文的情報と意味 的情報の両方を含んだ語彙集である。自動機械翻訳(MT)プロセスの分析過程では 、これが、中央語彙知識ソースとなる。K/DM 510は、また、LE/DMの基礎として も使用される。 K/DM 510に含まれるエントリは、各構文カテゴリーの用語１つに対して１つのエ ントリとなっている。（従って、名詞と動詞の両方で使用される″truck″のよ うな語には、２つのエントリが存在することになる。）K/DMエントリに含まれる 情報を、以下に示す。 ● 語根（例：″truck″） ● 品詞（例：Ｎ） ● 内容語の概念又は意味（例：O-TRUCK） ● 形態情報（例：不規則な語形変化） ● 構文情報（例：名詞が数えられるかどうかの区別） ● 定義情報：短い定義、異なる語義とその用途を示す文例、及び制約言語で 使用さるべき語義の指定 DM 500は、対象となるプロセスだけでなく、人間にも読める３セットの外部ファ イルに定義される。MT 120及びLE 130は、別のプロセスで稼動するため、このモ デルの情報は、MT 120に必要なDM部分とLE 130に必要な部分の、２つの異なるフォームで内部表現 されることになる。従って、K/DM 510は、両方のフォームで表現できるファイル セットに定義し、LE/DM 530は、LE 130が使用するフォームのみで表現し、MT/DM 520は、MT 120が使用するフォームのみで表現する。外部ファイルの形式、DMを 構成する各部の内容、及びLE 130が使用する情報の内部表現について、以下に説 明する。 上でも述べた通り、K/DMには、MT 120及びLE 130の両方で必要となる全情報が含 まれている。これらの情報としては、CSL語彙項目（基体語、句、又は引用用語 ）、及び意味的概念（″概念名″によって語彙エントリに表現される、語彙項目 の意味的概念）がある。さらに、品詞（決められた品詞の中の１つ（たとえば、 動詞、形容詞など）、定義（CSL語彙用語のどの語義かを明確化するための一般 用語の概略定義）、及び不規則な語形変化（不規則な語形のリスト及び各語形に 対する形態変形名）も、情報として含められる。動詞に対する形態変形名の例と しては、″past″（過去）、″third person singular present″（三人称単数 現在）、″past participle″（過去分詞）、″present participle″（現在分 詞）などがある。たとえば、″drive″という語では、このフィールドの値は、 （(past drove)(past-participle driven)）となり、これら２つの動詞変形が不 規則であり、その他の語形は規則的であることを意味する。最後に、語彙項目を すべて大文字にすべき時は、最初の文字を大文字にするといったような文字規制 も、K/DMに含まれる。 MT/DM 520には、MT 120のみが必要とする情報が含まれる。これらの情報として は、概念の選択規則、構成に対する概念の階層分類、及び選択規則の継承がある 。 著者が、適切なCSL語彙項目を選択できるようにするために、LE/DM 530には非CS L類義語を含める。また、カーネルとLE/DMには、（以降で説明する）LE用語チェ ッカーを支援するために、CSL語彙を特長付けるために必要な全ての情報及び規 制を含める。LE/DMには、LE用語チェッカーのみに必要となる追加情報も含めら れる。この追加情報としては、辞書定義（LEが著者に提供する語や句の定義）、 非CSL類義語（文書の作成で、著者が利用できるCSL語彙項目の類義語）、及び使 用例（LEが著者に提供する、CSL文内での語や句の使用例）がある。 この情報をLE/DMに含める理由は、執筆物が、適切なCSL語及び句で構成されてい るかどうかを、著者が確認できるようにするためである。CSLで許されている品 詞や意味の語や句を使っているかどうかの確認には、辞書定義と使用例が役立つ が、これらの情報は、すベてのCSL語彙項目に対して必要になるとは限らない。 辞書定義や使用例は、むしろ、CSLでの意味が一目瞭然でないような、不明確又 は曖昧な用語の一部にのみ必要となる。従って、 これらの情報が必要になるのは、DMに含まれる語彙項目の内の半分以下になるも のと思われる。たとえば、″for″や″the″といった機能語に対しては、定義や 使用例は不要である。また、技術用語、特に非常に特定的な意味を持つ技術用語 では、定義や使用例を提供する必要のない場合が多い。 LE/DMに含まれている非CSL類義語は、非CSL語や句を使っている場合に、それと 置き換えるべきCSL語やCSL句の類義語又は関連語を、著者が選択する時の助けと なる。用語チェッカーでは、該当する非CSL語と同じ品詞を持つ類義語だけでな く、文章の書き換えで役立つような、関連語に関する情報も提供することが望ま しい。後者を提供する場合は、必須の内容に加え、関連語に関する情報もLE/DM に含めることが必要である。 Ｄ．言語エディタ 図１(b)の制約言語エディタ(LE)130は、著者及び編集者が、CSLの制約内で文書 を作成する時の支援となる一連のツールから構成されている。これらのツールは 、著者がサービスドキュメンテーションを執筆する上で、適切なCSL用語及び文 法を使用するための助けとなる。このLE 130は、SGMLテキストエディタ140の″ 延長″として構築されるものである。LE 130とSGMLテキストエディタ140は、共 に同一の通信チャネルを使用してはいるが、両者の機能は、互いに排他的である 。ただし、LE 130との対話に使用するユーザインタフェースは、SGMLテキストエ ディタインタフェースの″一体的延長″となっている。 著者160は、SGMLテキストエディタ140で文書を作成し、LE 130を起動する。LE 1 30は、文書内のそれぞれの語が、非CSLであるかどうかを著者に知らせるととも に、ユーザアプリケーション情報ドメインに関連する語で、CSLに存在しないも のに対して、CSL類義語を提供することができる。さらに、LE 130は、ファイル 内のテキストが、CSL構文規約を満足しているかどうかの情報も著者に知らせる 。 LE 130のソフトウェアとしては、用語チェッカー、コア文法チェック機能を備え たMT構文アナライザへのインタフェースが含まれる文法チェッカー、及びユーザ インタフェース(UI)がある。さらに、CSL LEが利用するCSL用語情報も、K/DM及 びLE/DMで促供される。 任意の文書内の全用語及び文章構造が、CSL仕様に準拠するかどうかの承認は、L E 130によって行う。LE 130は、CSL承認を示すSGMLタグを使って、文書のマーク 付けを行う。 従って、文章、見出し、リスト項目、キャプション、図内の説明、表内の情報を 含め、文害内の全テキストに対してチェックを行うことが必要である。 本発明は、CSLチェック作業中、著者ができる限り効率よく作業し、一度に１文 書以上のオーサリングを行うことはないものと仮定しているため、文書を処理に 出し、その処理が完全に完了するまではフィードバックが得られないような、バ ッチモードでの作業は適していない。LE 130は、用語チェック、文法チェック、 及びインタラクティブ明瞭化プロセスに対して、対話モードを適用する。 図６は、LE 130の動作の高水準フローチャートである。この図では、制約のない 曖昧なテキスト605が、LE 130の入力になる。潜在的に曖昧で制約のないこの入 力テキスト605は、まず、（後述の）スペルチェッカー615を使ってその機能を果 たす用語チェッカー610でチェックされる。（この構成では、通常、ホストTE 14 0が有するスペルチェッカーによって、このスペルチェッカー機能が提供される 。）用語チェッカー610によるチェック及び（著者の介入を伴った）訂正が全て 完了すると、語彙制約済みテキスト617が、文法チェッカー620へ送られる。この 文法チェッカー620によって、構文の正しいCSLテキスト625が生成され、ブロッ ク630で示すように、構文の正しい制約済みテキスト625の明瞭化が行われる。こ の明瞭化プロセスからは、明瞭で翻訳可能な制約済みテキスト635が得られる。 この翻訳可能テキスト635は、前編集を行うことなく多言語へ翻訳することがで きる。ここで得られた翻訳の正確さによって、後編集も不要となる。 １．用語チェッカー 図７は、用語チェッカー610の動作フローチャートである。用語チェッカー610は 、CSLにない語を識別する。この用語チェッカー610は、著者のテキストに存在す る非CSL語の出現を識別し、著者が、それに代わる適切なCSL語を見つけられるよ う支援する。つまり、文書内の語境界を認識し、CSLにない語彙項目の全インス タンスを識別する。 ブロック706で示すように、単位の最初の用語が、チェック対象として選択され る。この用語は、ブロック710で示すように、全CSL語を含むCSL語彙データベー ス（つまり、辞書）と照合チェックされる。この用語が、CSL辞書に存在しない 時は、ブロック722に示す標準辞書で、用語のスペルがチェックされる。語のス ペルが誤っている場合は、ブロック726に示すように、スペルを訂正するための 手段が著者に提供される（つまり、用語チェッカー610が、代わりとなるスペル を表示する）。 次に、ブロック734に示すように、この用語がCSL用語であるかどうかがチェック される。CSL用語である時は、ブロック718へ処理が移る。CSL語でない時は、ブ ロック736に示すように、この用語に対する類義語がLE/DMに存在するかどうかが 、システムによってチェッ クされる。LE/DMに、少なくとも１個の類義語が見つかった時は、ブロック738に 示す通り、CSL用語であるその類義語を表示し、著者に選択を求める。LE/DMに、 該当する用語の類義語が全く存在しない場合は、ブロック740に示すように、著 者による再入力が行われる。ここで得られた入力は、ブロック710へ送られる。 著者によって妥当な選択が行われれば、手順700の制御はブロック718へ移る。 非CSL語が見つかった時の著者のオプションとしては、代わりの語を選択し、文 書内の非CSL語をその語で置き換えるか、又は文書内の語の置換えとなる新しい 語を入力するかである。通常、著者は、類義語の中から１つを選択し、それで非 CSL項目を置き換える。著者が、この処理をスキップした場合は、テキストが、C SLとしての承認で失格になる可能性もある。 ブロック718では、該当する単位に、別の用語が存在するかどうかをチェックす る。別の用語が存在しなければ、手順700は停止する。存在する場合は、ブロッ ク714に示すように、次の用語が選択され、手順700がブロック710から再開始と なる。 特に用語チェッカー610では、CSLに存在しない語彙項目の全インスタンスが識別 される。用語チェッカー610は、該当する語それぞれに対して、以下に記述する 説明の内どれが適切であるかを決定し、その情報をユーザインタフェースヘ報告 する。 ● 既知のCSL類義語を持つ非CSL語。この場合、用語チェッカー610は、類義 語を識別する。ここでは、例として、″let″という語が、非CSL語である場合を 考えてみよう。 チェック時の著者の入力：Open the valve and let more nitrogen go to the accumulator. VCメッセージ：この用語は非CSLですが、関連する別のCSL語があります。 関連CSL語：allow, allowed, enable, enabled, permit, permitted, leave, left 編集後のCSL文章：Open the valve and allow more nitrogen to go to the a ccumulator. ● 句の一部としてのみCSLに存在するが、該当する文脈では、CSL句として 使用されていない語。この場合、用語チェッカー610は、その語を含み、CSL句と して許される語を報告する。 チェック時の著者の入力：The first time the valve lash is checked, the injector timing should be checked. VCメッセージ：この用語は、非CSLの文脈で使用されています。 関連CSL語：advance signal timing, advance timing groove, timing gear, timing mechnism 編集後のCSL文章：The first time the valve lash is checked, the injecto r timing mechanism should be checked. ● 該当する文脈では引用符で囲まれていないが、CSLでは、引用符で囲むべ き語又は句。この場合、用語チェッカー610は、引用符で囲むべき由を報告する 。 チェック時の著者の入力：For more details, read the Testing and Adjusti ng article in the next section. VCメッセージ：この用語は、通常、引用符で囲みます。 関連CSL語：なし 編集後のCSL文章：For more details, read the ″Testing and Adjusting″a rticle in the next section. ● 該当する文脈では、大文字化されていないが、CSLでは必ず大文字化すべ き語又は句（たとえば、小文字で表現された略語）。この場合、用語チェッカー 610は、CSLでの正しい形式を報告する。 チェック時の著者の入力：Turn the screw until the pressure gauge reads Okpa（O psi）. VCメッセージ：この用語は、大文字化が正しくありません。 関連CSL語：kPa 編集後のCSL文章：Turn the screw until the pressure gauge reads O kPa（ O psi）. ● 正しい綴りの存在する非語（つまり、誤綴りの語を表現する文字の並び） 。この場合、用語チェッカー610は、CSLに存在するかどうかにかかわらず、綴り の正しい関連語を識別する（ユーザは、ここで選択した関連語を、チェック対象 語として入力する）。 チエツク時の著者の入力：When it is necesary to raise the boom, the boo m must have correct support. VCメッセージ：この用語は、非CSLです。 関連CSL語：necessary 編集後のCSL文章：When it is necessary to raise the boom, the boom must have correct support. ● システムに解明できない非CSL語。未知の語又は句に対するメッセージで は、場合に依り、表現の書き換え又は違法表現のチェック保護を、著者に依頼す る。下に示す例では、SGMLタグを利用し、該当する違法表現が、システムによっ て無視されるよう指定している。 チェック時の著者の入力：Put approximately 0.9 L（1 quart）of SAElOW hy draulic oil in the nitrogen end of the accumulator. VCメッセージ：この用語は、存在しません。 関連CSL語：なし 編集後のCSL文章：Put approximately 0.9L（1 quart）of〈sic〉SAElOW〈/si c〉hydraulic oil in the nitrogen end of the accumulator. ● 文脈に関係なく、システムでは絶対に許されない句読点又は特殊記号。 非CSL語に対する直接的CSL類義語（文書内で直接置き換えることのできる語）が 存在しない場合、意図する考えを表現するために使用できる関連CSL語又は句を 、システムは識別 することができる。この機能は、著者にとって、CSL用語のみを使って文章を書 き換える場合の支援となる。しかし、語を変更したために、文章構造まで変更し なければならなくなる場合もあり、同義語に対する自動置換機能だけでは、関連 語の採用に伴う変更が完全とはならないケースもある。たとえば、″can″はCSL 語、″capable″は非CSL語となっている場合に、以下のような文章を書いたとす ると、 The system is capable of being programmed for several customer-specifi ed parameters. ″capable″[[capable]]は、CSL語でない由のメッセージが出されることになる 。この場合、″can″[[can]]は、CSL語ではあるが、文章の他の部分を修正せず に、″capable″又は″is capable of″を、直接″can″で置き換えることはで きない。 ２．文法チェッカー 文法チェッカーの目的は、著者のテキストで、CSL文法規約に従っていない箇所 を見つけ、その箇所に対して著者の注意を促すことである。文法チェッカー620 の機能は、分析モジュール127及びMTシステム120によって提供し、構文及び文法 上の曖昧さに関するインスタンスを、システムで報告できるようにする。文法チ ェッカーのインタフェースは、曖昧さを明確化するための要求に対して、著者が 対話的に応答できるようにする。文章を制約言語で書いたとしても、その解釈が ２つ以上存在するケースもある。このような場合、文法チェッカーインタフェー スは、文章に該当する複数の解釈を指摘し、著者にその明確化を要求する。曖昧 な文章の例として、″check the cylinders on the inside″を考えてみると、 この場合、シリンダーが内側に存在するのか、シリンダーの内側をチェックする のか曖昧である。このような曖昧さとしては、以下に示す２種類がある。 語彙の曖昧さ。語彙の曖昧さは、１つの語が、制約言語で２つ以上の意味を持 つ場合に発生する。制約言語では、１つの語は、各品詞に付き１つの意味しか持 たないことが望ましいが、２つ以上の意味を持つ語も存在する。例として、″ga s″又は″gasoline″の意味に解釈できる語″gas″がある。 語彙レベルでは、CSL内で２つの異なる構文的役割を果たす語で、問題が発生す ることがある。この例としては、CSLで名詞としても、また動詞としても使用で きる″fuel″がある。著者が、構文的役割の不明確な文章を入力すると、文法チ ェッカー(GC)620は、以下のようなメッセージを出す。 チェック時の著者の入力：The sensor is attached to fuel rack. GCメッセージ：この用語は、名詞又は動詞として使用することができます。 この時点では、著者は、システムの支援なしに文章を編集することが可能である （この場合、文章の書き直しを行い、再度チェッカーに入力する）。著者が支援 を依頼した場合は、この種の問題を解決するための指示が、システムから提供さ れることになる。この時の支援は、以下のように明確である。 Help！ GCメッセージ：語が名詞の場合は、その語の前に限定詞を使用し、動詞の場合 は、その語の後に限定詞を使用します。 例：The ship sinks vs. Ship the sinks. この結果、著者は、文章を編集し、再度文法チェッカー620へ入力することにな る。 構文の曖昧さ。構文の曖昧さは、文章内の語が、２通り以上にグループ分けで きる場合に発生する。たとえば、″Remove the valve with the lever.″の例で は、″with the Iever″が、″the valve″という句を伴う１つの単位を形成す るのか、それとも″remove″という動詞を伴う単位を形成するのか曖昧である。 つまり、レバーの付いたバルブに関する文章なのか、それともバルブを取り外す ためにレバーを使うのか不明である。 IATS 105には、このような問題を解決できるように設計されたコンポーネントと して、ドメンモデル137があり、このドメインモデルは、このような曖昧さの出 現を最小限に抑えられるような構造となっている。 図５に示す通り、機械翻訳プロセス専用のDM/MT 520には、２種類の情報が含ま れている。その１つである語義情報(A)は、概念間の識別又は関係をサポートし 、他方の文脈情報(B)は、特定の動詞が取り得る、いわゆる深格又は引数を提供 する。まず、アナライザ127が、上の例″Remove the valve with the lever″の 構文を解析する上で、語義情報(A)と文脈情報(B)がどのように役立つのかを考え てみよう。 語義関係としては、たとえば、″hat（帽子）″が、″costume（服装）″の″is a part of（一部 である）″という点から、″hat″という概念と″costume″という概念の間には 、″is a part of″という関係が成立する。また、概念″sole″と概念″shoe″ 、又は″heel″と″shoe″の間にも、同様の関係が成り立つ。DM/MT 520に存在 する語義情報(A)は、これに加え、ドメイン内の概念間に存在する他の意味的関 係をも識別することができる。 概念″valve″と概念″lever″との間の語義情報を得るために、処理がMTアナラ イザ127からDM/MT 520へ移った時、MTアナライザ127は、″lever″が″valve″ の″is a part of″であるかどうかは、DM 137内の情報から判断することはでき ない。つまり、このような関係についての知識は、そこには存在しないのである 。従って、この段階では、句″with the lever″を語″valve″と接続すべきか どうかは、MTアナライザ127には不明である。 ここで、MTアナライザ127が、文脈情報(B)をチェックすると、（学校時代のラテ ン語文法よりも深いレベルの分析から）動詞″remove″には、主格（MON）、対 格（ACC）、及び助格（INS）の３つの格があることが分かる。つまり、″remove ″は、以下の格フレームに当てあまることになる。 この抽象パターンに基づいて、以下のような文章を構成することができる。 など DM/MTには、［+INSTRUMENT］という意味的機能を持つ名詞と前置詞″with″との 関係を示す情報があるため、このような組み合わせは、助格句を形成することが 分かる。このことから、アナライザによって、以下の結論が導かれることになる 。 a)″lever″は［+INSTRUMENT］であるため、″with the lever″はINSとなる 。 b)″remove″はINS格を取るため、句″with the lever″は、″remove″と接 続し、 ″remove″を修飾するものとして解釈する。 DM 137は、本発明者が構築した程度までしか高度化できない。従って、語義情報 が完全に開発されていない場合は、ドメインの語彙エントリだけで、MTアナライ ザ127の明瞭化プロセスをサポートすることは不可能な場合もある。 ″Peter has removed the box with the nail″の″nail″を考えてみよう。DM 137に、nailが木製フレームの一部であるという情報が存在したとしても、nail が［+INSTRUMENT］であるという情報が存在しなければ、″with″が″nail″と 組み合わさって助格句を構成することは、MTアナライザ137で判断することはで きない。このように、アナライザで構文の曖昧さを解決できない場合は、著者に 対してその解決が要求されることになる。著者の入力したテキストを文法チェッ クする時は、以下のような対話が発生する。 チェック時の著者の入力：Peter has removed the box with the nail. 文法チェッカー620のメッセージ：文章が曖昧です。 １．nailは、助格ですか？ ２．″nail″は、″box″に存在するのですか？ 著者が適切な解釈を選択すると、チェッカーは、不可視のSGMLタグを文章に付け 、この文章がどのように翻訳されるべきかをシステムに指示する。 上でも述べたように、入力テキスト又はIE（又はその一部）が、CSLの文法及び 語義規約に準拠しているかどうかをチェックするために、MTアナライザ127が文 法チェッカーから呼び出される。この点から、厳格な″緑ライト又は赤ライト″ メッセージを、各文章に対して返すのが好ましい。なお、赤ライトは、著者が、 オーサリング環境を通じてフラグ付き文章の構造を訂正しなければならないこと を意味する。入力テキスト全体又はIE全体が、CSL準拠として承認されれば、そ れを保管しておくことも、又は直ちに翻訳へ回すことも可能である。 図８は、文法チェッカー620（構文解析）及び明瞭化チェッカー630（語義解析） の高水準フローチャートである。以降使用する″文章″という言葉は、分析モジ ュール127のチェックで合格又は不合格となるテキストの単位を意味する。実際 にチェックされるテキストは、見出し、タイトル、リスト項目、キャプション、 又はその他の図のテキストといった、文 章以外のテキストコンポーネントである。文法チェッカー620は、文章境界に加 え、SGMLマーク付きテキストのSMGL要素境界を認識することができる。また、CS L仕様に準拠していない文章の識別も行う。MT分析モジュール127によって解析で きないような文章が、これに相当することになる。なお、解析処理は、以下に示 す原因に限らず失敗する可能性がある。 ●分析モジュール127による解析の対象とならない文法構造を、文章が含んで いる。たとえば、還元関係節が文章に含まれる場合がある。″Don't change the values that are programmed into the unit″という文章では、関係代名詞″t hat″と動詞″be″の削除によって、還元が発生することになる。 チェック時の著者の入力：Don't change the values programmed into the un it . 文法チェッカーのメッセージ：この文章は、複雑過ぎて解析できません。 以下の問題をチェックしてください。 ここで、文法チェッカー620は、CSLに含まれていない文法構造によって、解析が 不可能あるいは困難となる最も典型的なケースをリストする。 ●文章で使われている引用符が、CSL規約に準拠していない。上でも述べたよ うに、文脈にかかわらず、CSLで許されていない引用符や特殊符号は、用語チェ ッカー610によってフラグ付けされる。ただし、用語チェッカー610では、入力の 解析は行わないため、ＣＳＬには存在するが、間違った文脈で使用されるケース については報告しない。このような場合、文法チェッカー620の処理結果は、″ 失敗″となる。 ●CSL用語が、CSLでは認識できない構文形式で使用されている。この場合、用 語チェッカー610は、該当するケースの一部にフラグを付ける。たとえば、test という語が、動詞としてではなく、名詞としてのみCSLに含まれているとすれば 、用語チェッカーは、その過去形testedを非CSL語として報告することになる。 ただし、動詞の現在形testsは、CSL名詞の複数形と同一形式であるため、用語チ ェッカー610のチェックでは合格する。このような場合、文法チェッカー620の処 理結果は、″失敗″となる。 文法チェッカー620は、MT分析モジュール127（及びドメインモデル137）を使っ て、CSL文法規約に準拠していない文章を識別する。これは、構文解析として知 られるものであり、ブロック805に示す通りである。文法チェッカー620は、この ような文章のそれぞれに対し て、CSL外であることを報告する。ただし、文章は、CSL内ではあっても、曖昧な ものになっている場合もある。従って、本発明では、ブロック710に示すような 語義解析を提供している。チェックした文章が、語義的に曖昧でない時は、ブロ ック815及び825で示すように、明瞭化チェッカー630が、該当すると思われる２ つ以上の意味を著者に指摘し、その明確化を要求する。本発明の好ましい具体化 では、文章が、文法チェッカー620及び（又は）明瞭化チェッカー630で失格とな った場合、文書の編集、（読みが曖昧な場合は）文章の明確化、同一の入力の再 チェック、又は編集を伴わないチェックの続行が、著者のオプションとして考え られる。 なお、本発明は、単なる文体的警告や単純なエラーの検出（主語−動詞の一致） を行うのではなく、用語及び文法規約の厳格な準拠を実施するものである。 文章が語義的に曖昧な時は、ブロック820に示すように、インターリングアへの 翻訳を行う。文書が文法チェッカー620で合格すれば、CSL承認を示すSGMLタグを 文書に挿入することができる。 本発明の好ましい具体化では、合格・不合格のフィードバックが、文法チェッカ ー620から著者160に対して与えられる。しかし、合格・不合格以外のより詳細な フィードバックを提供することも可能である。 明瞭化を含む文法チェックの詳細な説明については、ここでも参考として含めて ある、Tomita, M., ″Sentence disambiguation by Asking,″ Computers and T ranslation , 1:39-51（1986）及びCarbonell, J. and M. Tomita, ″Knowledge- Based Machine Translation，the CMU Approach，″in S．Nirenburg（ed.），M achine Translation：Theoretical and Methodological Issues ，Cambridge：Ca mbridge University Press，pgs．68-89（1987）を参照のこと。 Ｅ．機械翻訳 MT 120は、インターリングア型機械翻訳システムである。このようなシステムで は、制約ソース言語（CSL）とターゲット言語が、互いに直接係わり合うことは ない。このようなシステムの処理は、通常２段階で行われる。第１段階では、CS Lテキストの意味を、インターリングアと呼ばれる言語独立型正式言語で表現し 、第２段階では、ターゲット言語の語葉単位及び構文構造を使って意味を表現す る。 他のタイプのMTシステムと同様に、インターリングアＭＴシステムは、この分野 でもよく知 られている。機械翻訳に対するこれら異なるアブローチの詳細については、その 全体をここでも参考として含めてある、Hutchins, Machine Translation: Past, Present ，Future, Ellis Horwood, Ltd., Chichester, UK, 1986及びZarechnak , The History of Machine Translation, in Henisz-Dostert, McDonaId, Zarec hnak, eds., Machine Translation. Trends in Linguistics: Studies and Mono graphs , Vol. ll, The Hague, Mouton, 1979を参照のこと。 CSLテキスト350の意味は、（この分野では周知の）インターリングアと呼ばれる 、特別に設計された知識表現計画に基づいて表現される。このインターリングア は、フレーム表記法で表現されているため、一種の語義ネットワークとして見る ことができる。インターリングアには、他の人工言語又は公式言語と同様に、独 自の語彙と構文が存在する。語彙は、翻訳済みテキストが対象とするドメイン（ たとえば、コンピュータ保守、宇宙探検など）に基づいている。従って、インタ ーリングアの″名詞″は、存在学の″物体概念″に相当し、インターリングアの 動詞は、存在学のいわゆる″事象″に対応し、そして、インターリングアの形容 詞及び副詞は、存在学で定義される様々な″特性″に相当する。存在学では、様 々な種類の概念を、ドメインモデルと呼ばれる緻密な結び付きを持ったネットワ ークで表現する。 図３及び図９を見ると、IATS 105の機械翻訳（MT）コンポーネント120が、主に ２つの部分から構成されているのが分かる。そのひとつは、CSLテキストをイン ターリングで表現するための処理の第１段階を実行するCSLアナライザ127であり 、もうひとつは、インターリングアで表現された″CSL承認″テキストをターゲ ット言語へ翻訳するためのターゲット言語ジェネレータ123である。これら２つ のタスクを実行するMTコンポーネント120は、独立した１個以上のサーバモジュ ールとして動作し、人間の翻訳コントローラ（図示省略）からの翻訳要求を受け 付ける。ターゲット言語の生成時には、後編集を必要としない高品質の出力テキ スト950を得るために、ターゲット言語ジェネレータ123は、インターリングアテ キスト260を適切なターゲット言語構文単位にマッピングする。 MT分析モジュール127による、承認済みCSL準拠IE用としてのインターリングアテ キスト260の生成が完了すれば、そのインターリングアは、保管することも、納 品することも、あるいはジェネレータ123（語義−構文マッパー及び、Center fo r Machine Translation, Carnegie Mellon University, Pittsburgh, Pa.から入 手可能なジェネレーションキットを含む（Tomita M. and E. Nyberg, The Gener ation Kit and Transformation Version3.2 User's Manual , Technical Memo(19 88)）によって、ターゲット言語IE又は各種ター ゲット言語のIEへ直ちに変換することもできる。MTアナライザ127とMTジェネレ ータ123間には２通りの対話形態があり、一方は、前者の出力が後者の入力とな る形態、他方は、同一の外部知識ソース（特にドメインモデル137）を共用する 形態である。 MTシステム120は、図９に示すように、さらに細かく分類することができる。分 析部分は、構文解析系910とインタプリタ920から構成されている。MT 120の他の 半分は、マッパー930とジェネレータ940に分類することができる。図９の楕円形 は、主なソフトウェアモジュール間で生成され、受け渡しされるデータを示す。 翻訳過程では、DM 137（及び特にMT/DM 520）が、３つの異なる目的で使用され ることになる。つまり、（１）構文解析系910は、（構文解析時、引数や修飾子 の厳格な小分類化を行って）付属物を制約するためにDM 137を使用し、（２）イ ンタプリタ920は、解釈時、適切なドメン概念を例示化するためにDM 137を使用 し、（３）マッパー930は、各インターリングア概念に適切なターゲット言語表 現を選択するためにDM 137を使用する。 MT 120は、１つ以上のサーバモジュールとして動作する。それぞれのMTプロセス は、FMS 110からの翻訳要求を受け付け、その結果を返す。この要求には、SGML タグ付きシステムテキストが含まれ、結果には、SGMLタグ付きターゲット言語翻 訳が含まれる。また、複数言語への翻訳が同時実行されることもあるため、該当 するターゲット言語も要求に含まれることになる。MTサーバプロセスは、ターゲ ット言語によって特殊化されることから、経路指示機能が必要になる。この経路 指示機能は、FMS 110で自動的に実行している。任意の時点で稼動すべきMTプロ セスのグループ及び複数機械間でのそれらのプロセスの分散は、MFS 110によっ て決定される。MFS 110は、要求中の翻訳ジョブのグループに従って、適時プロ セスグループの変更を行う。 図９のCSLアナライザ127は、２つの相互練結コンポーネントである、構文解析系 910と語義インタプリタ920から構成されている。語義インタプリタ920は、この 分野では、″マッピングルールインタプリタ″としても知られるものである。構 文解析系910は、CSLテキスト305を入力として、その構文構造を生成する。この 構文解析系910では、LFG型文法を適用している。語彙機能文法(FG)は、機械翻訳 の分野では周知の正式化文法のことであり、これから、LFG f-構造960が構文構 造として得られる。CSL文章960に対するf-構造が生成されると、ソース言語の語 彙単位及び構文構造をインターリングア翻訳で置き換えるために、語義インタプ リタ920によるマッピングルールの適用が直ちに開始される。語彙単位は、ドメ イン概念のインスタンスにマッピングされ（たとえば、″data″という語は、イ ンターリングアの″information″にマッピングされる）、一方、構文構造は、 概念関係 にマッピングされる（たとえば、文章の主語は、通常、インターリングアの″行 為者″にマッピングされる）。詳細については、ここでも参考として含めてある 、Mitamura, The Hierarchicat Organization of Predicate Frames for Interp retive Mapping in Natural Language Processing , Center for Machine Transl ation, Carnegie Mellon University(May 1990)を参照のこと。 MTアナライザ127は、分析知識（データファイル）を利用して、ソース言語のCSL テキスト305の入力文章を、文章の意味を現わす語義フレーム表現に翻訳する。 解析段階で利用される知識構造は、解析文法、マッピングルール、及び概念語彙 である。 解析の最初の部分は、入力文章の構文を解析する構文解析プロセスである。構文 解析系910は、入力文章の解析中に遭遇した構文の曖昧さを処理するために、概 念語彙（ドメインモデル）に具体化されている語義規約を適用する。マッピング ルールは、構文解析文法と概念語彙との間に介在する。 この解析からは、適用できる全ての語義情報を備えた構文f-構造が、その出力と して得られる。この構造は、意味的に組織化されたフレーム表現（つまり、文章 の構文解析過程で遭遇した概念語彙を、適切な概念に具体化した形式）を得るた めに、さらにMTアナライザ127の２番目の部分で処理することができる。MTアナ ライザ127では、（適切な全ての語義情報を含む）f-構造の語義的機能を検索す ることによって、この形式を得ている。 本発明で使用している構文解析系910は、この分野ではよく知られており、詳細 は、ここでも参考として含めてある、Tomita and Carbonell, The Universal Pa rser Architecture for Knowledge-Based Machine Translation , Technical Rep ort, Center for Machine Translation, Carnegie Mellon University（May 198 7）及びTomita（ed.）et al., The Generalized LR Parser/Compiler Version 8 .1: User's Guide , Technical Memo, Center for Machine Translation, Cargen ie Mellon University（April 1988）に説明されている。 インターリングア翻訳システムが、他の種類のMTシステムよりも有利となる理由 のひとつは、インターリングア260が、言語独立型であること、つまり、ソース 言語とターゲット言語に直接的な接触がないということである。この利点によっ て、任意のソース言語及びターゲット言語が選択される一方、演算構造の変更が 最小限に留められるような機械翻訳システムが、構築できることになる。このよ うなシステムでは、当然、多数のソース言語を構文解析できることが要求される 。従って、インタプリタ自体に文法を組込むのではな く、言語文法を入力とするような、万能構文解析系が必要である。これによって 、より優れた伸張性と汎用性を達成することができる。 換言すれば、多言語を扱う場合、言語構造は、（純粋な英語構文解析系のように ）あらゆる全てのアプリケーション間で互換性を持つような汎用不変式ではなく 、パラメータ化や伸張性の１次元でしかない。これに対し、語義情報は、（ドメ イン間での不変性は持たないが）あらゆる言語を通じ不変である。従って、語義 知識ソースは、構文知識ソースから分離させ、新しい言語情報を追加した時には 、その情報が全ての語義ドメインに適用でき、また、新しい語義情報を追加した 時には、それが全ての関連言語に適用できるようにすることが重要である。万能 構文解析系は、実行時の効率や語義精度に大譲歩することなく、これを達成でき るよう設計している。 構文解析系910は、３種類の知識ソースをその特長とする。その１つは、異なる 言語に関する構文文法、第２は、異なるドメインに関する語義知識ベース、第３ は、構文形式（語及び句）を語義知識構造にマッピングするための規則である。 それぞれの構文文法は、どのドメインからも完全に独立しており、同様に、それ ぞれの語義知識ベースは、どのドメインからも、また、どの言語からも独立して いる。 さらに、マッピングルールは、言語及びドメインから独立しており、それぞれの 言語・ドメインの組み合わせに対して、個別のマッピングルールが作成される。 これらの構文文法、ドメイン知識ベース、及びマッピングルールは、非常に抽象 的で、人間に読める形式で作成されているため、実行時の構文解析系では機械効 率が低くなる可能性もあるが、拡張や変更が容易である。 マッピングルールインタプリタ920の機能は、構文構造及び語義構造を生成及び 操作するとともに、これらの構造を同時生成することである。 万能構文解析系910は、解析した文章から得られるあらゆる全ての、つまり、有 効なf-構造を生成する。それぞれの構文f-構造は、語義機能を持ち、これらの機 能は、LFG理論に従って、残りの構文f-構造と同時に生成される。従って、語義 コンポーネントは、f-構造の追加機能として理解することができる。 このように、語義コンポーネントは、構文解析の″可視”部分にとなる。構文構 造及び語義構造を同時に生成するというこのアプローチによって、構文解析完了 前の″無意味な”部分的解析を省略できるシステムが構築されている。語義情報 は、語の定義を目的として 語彙をアクセスする時に、構文構造に追加されるようになっている。また、語の 定義の一部として、構造マッピングルールが含まれている。これらのマッピング ルールは、文法規則の構文式によって情報が構文構造に追加される時に適用され る。 ターゲット言語ジェネレータコンポーネント123は、インターリングアテキスト2 60を入力として、ターゲット言語テキスト950を生成する。このターゲット言語 ジェネレータ123は、語義モジュールと構文モジュールをそれぞれ１個づつとす る、２つの主要モジュールから構成されている。語義モジュールは、生成語彙及 び生成構造マッピングルールの支援によって、それぞれターゲット言語語彙の選 択及びターゲット言語構文構造の選択を行う。このモジュールの出力は、システ ムが出力するターゲット言語文章のf-構造である。 生成モジュールの目標は、CSLアナライザ127が生成したインターリングアテキス ト260のフレームから、ターゲット言語の文章を生成することである。生成処理 には、主に次の３つの段階がある。 １． 語彙の選択。 インターリングアの各概念に対して、最も適した語彙項目を選択するこ とが必要である。 ２． F-構造の生成。 インターリングアテキストフレームから、ターゲット言語の文法構造を 決定する構文機能構造を生成することが必要である。 ３． 構文の生成。 生成文法によって構文機能構造を処理し、ターゲット言語の文章を生成 する。 生成モジュール940の設計では、従来の翻訳CSLで利用されているマップ・アンド ・ジェネレート範例に、構文選択分野での最近の研究を組み込んでいる。 機械翻訳及び上で述べたモジュールの設計及び動作の詳細な説明については、こ こでも参考として含めてある、Nirenburg et al., Machine Translation: A Kno wledge-Based Approach , Morgan Kaufmann Publishers, Inc. (1992)、Sommers & Hutchins, Interlingua Translation System for Multi-lingual Document Pr oduction , Proceedings of Machine Translation Summit III, Washington D.C. (July 2-4 , 1991)、Nirenburg, S., ″World Knowledge and Text Meaning″, in K. Good man and S. Nirenburg(eds.), The KBMT Project: A Case Stud in Knowledge-B ased Machine Translation , San Mateo, Calif. (Center for Machine Translat ion, Carnegie Mellon University, Pittsburgh, PA（電話番号：(412)268-659 ）から入手可能なMorgan Kaufmann, KBMT-89 Project Report)(4th Printing: M arch 1990)、S. Nirenburg(ed.)，Machine Translation: Theoretical and Meth odological Issues , Cambridge: Cambridge University Press, pgs. 68-89(198 7)、及びCarbonell et al., Steps Toward Knowledge-Based Machine Translati on , IEEE Transaction on Pattern Analysis and Machine Intelligence, Vol. PAMI-3, No. 4(July 1981)を参照のこと。 以上、本発明を、好ましい具体化の例で示し、説明してきたが、本発明の真意及 び範囲から外れることなく、その形態や詳細に様々な変更を加え得ることは、こ の分野の特殊技能を有する者にとっては明白である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ハリス ティモシー ジェイ アメリカ合衆国 イリノイ州 61554 ペ キン サウス トゥエルヴス ストリート 625 (72)発明者 ヒグドン ジェームズ ダブリュー アメリカ合衆国 イリノイ州 61540 レ イコン ベイ ショア ドライヴ 55 (72)発明者 ヒル デニス エイ アメリカ合衆国 イリノイ州 61611 イ ースト ピオーリア アロウヘッド コー ト 121 (72)発明者 ハドソン ディヴィッド シー アメリカ合衆国 イリノイ州 61526 エ ーデルスタイン ノース センターヴィル 15914 (72)発明者 ナシレティ ディヴィッド アメリカ合衆国 イリノイ州 61550 モ ートン サウス ミシシッピー アベニュ ー 317 (72)発明者 レニッチ マーヴィン エル アメリカ合衆国 イリノイ州 61525 ダ ンラップ ノース ルート 91―11313 (72)発明者 アンダーソン ペギー エム アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ ピトック ストリ ート 2302 (72)発明者 バウアー マイケル エム アメリカ合衆国 ペンシルバニア州 15232 ピッツバーグ リーハイ アベニ ュー 245 (72)発明者 バスディッカー ロイ エフ ザ サード アメリカ合衆国 ペンシルバニア州 15232 ピッツバーグ サウス アベニュ ー 914 (72)発明者 ヘイズ フィリップ ジェイ アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ ノームリー プレ イス 5419 (72)発明者 ヒュットナー アリソン ケイ アメリカ合衆国 ペンシルバニア州 15206 ピッツバーグ ウォルナット ス トリート 6018 アパートメント ３ (72)発明者 マックラレン ブルース エム アメリカ合衆国 ペンシルバニア州 15206 ピッツバーグ ヒートス アベニ ュー 1018 (72)発明者 ニーレンバーグ アイリーン アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ ビーチウッド ブ ールヴァード 2550 (72)発明者 リーブリング エリック エイチ アメリカ合衆国 ペンシルバニア州 15237 ピッツバーグ クリアヴィュー ドライヴ 2294 (72)発明者 シュマンド リンダ エム アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ ビーチウッド ブ ールヴァード 1624 アパートメント １ (72)発明者 スウィート ジョン エフ アメリカ合衆国 ペンシルバニア州 15206 ピッツバーグ １ オーレリア ストリート 6362 (72)発明者 ベイカー キャサリン エル アメリカ合衆国 ペンシルバニア州 15206 ピッツバーグ ヘイスティングス ストリート 506 (72)発明者 ブラウンロウ ニコラス ディー アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ フィリップス ア ベニュー 5832 アパートメント ４ (72)発明者 フランツ アレクサンダー エム アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ 11 ワイトマン 2130 (72)発明者 ホーム スーザン イー アメリカ合衆国 ペンシルバニア州 15217 ピッツバーグ バートレット ス トリート 5858 (72)発明者 レーヴィット ジョン ロバート ラッセ ル アメリカ合衆国 ペンシルバニア州 15232 ピッツバーグ エルズワース ア ベニュー ディー２―5715 (72)発明者 ロンズデイレ ダリル ダブリュー アメリカ合衆国 ペンシルバニア州 15017 ブリッジヴィル スプリングハウ ス プレイス 6284 (72)発明者 ミタムラ テルコ アメリカ合衆国 ペンシルバニア州 15213 ピッツバーグ 204 ノース クレ イグ ストリート 233 (72)発明者 ニーバーグ エリック エイチ ザ サー ド アメリカ合衆国 ペンシルバニア州 15213 ピッツバーグ 36 ノース クレ イグ ストリート 147

Claims (1)

1. 【特許請求の範囲】 １． ソース言語で書かれた入力テキストを、著者(160)から対話的に受け付 けるように設計したテキストエディタ(140)と、 曖味さのない制約テキストを生成するために、上記入力テキストに対し てまず語彙制約の準拠を、次に文法規約の準拠を実施する上で、上記著者(160) を対話的に支援するようにし、上記入力テキストを作成するために上記著者(160 )が使用する自然言語サブセットに対してまず語彙制約の準拠を、次に文法規約 の準拠を対話的に実行する上記テキストエディタ(140)の延長である言語エディ タ(130) とから成る、一言語文書開発用コンピュータ系システム(105)。 ２．上記の語彙制約及び文法規約の実施において、上記言語エディタ(130)を支 援できるようにするために、語彙単位及びそれらの組み合わせに関する定義済み ドメイン知識及び言語語義知識を、ドメインモデル(137)から提供し、上記言語 エディタ(130)と通信する上記ドメインモデル(137)をその構成要素とした、特許 請求範囲１のシステム(105)。 ３．上記DM(137)が３体ドメインモデルであり、この３体ドメインモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタドメインモ デル(530)、 及び、上記機械翻訳システム(105)のみが必要とする情報を含む機械翻 訳ドメンモデル(520) から構成されるようにした、上記特許請求範囲２のシステム(105)。 ４．ソース言語で書かれた情報要素を、著者(160)から対話的に受け付けるよう に設計したテキストエディタ(140)と、 曖昧さのない制約情報要素を生成するために、上記情報要素に対してま ず語彙制 約の準拠を、次に文法規約の準拠を実施する上で、上記著者(160)を対話的に支 援するようにし、曖味さのない制約情報要素(410)を作成するために上記著者(16 0)が使用する自然言語サブセットに対してまず語彙制約の準拠を、次に文法規約 の準拠を対話的に実行する上記テキストエディタ(140)の延長である言語エディ タ(130)と、 曖昧さのない制約情報要素を、後の使用に備えて保存しておくためのメ モリ手段とから成る、一言語文書開発用コンピュータ系システム(105)。 ５．上記の語彙制約及び文法規約の実施において、上記言語エディタを支援でき るようにするために、語彙単位及びそれらの組み合わせに関する定義済みドメイ ン知識及び言語語義知識を、ドメインモデル(137)から提供し、上記言語エディ タ(130)と通信する上記ドメインモデル(137)をその構成要素とした、特許請求範 囲４のシステム(105)。 ６．上記DM(137)が３体ドメインモデルであり、この３体ドメインモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタドメインモ デル(530)、 及び、上記機械翻訳システム(105)のみが必要とする情報を含む機械翻 訳ドメンモデル(520) の３つから構成されるようにした、上記特許請求範囲５のシステム(105)。 ７． ソース言語で書かれた入力テキストを、著者(160)から対話的に受け付 けるように設計したテキストエディタ(140)と、 曖昧さのない制約テキストを生成するために、上記入力テキストに対し てまず語彙制約の準拠を、次に文法規約の準拠を実施する上で、上記著者(160) を対話的に支援するようにし、上記入力テキストを作成するために上記著者(160 )が使用する自然言語サブセットに対してまず語彙制約の準拠を、次に文法規約 の準拠を対話的に実行する上記テキストエディタ(140)の延長である言語エディ タ(130)、 及び、上記の語彙制約及び文法規約の実施において、上記言語エディタ を支援で きるようにするために、語彙単位及びそれらの組み合わせに関する定義済みドメ イン知識及び言語語義知識を、ドメインモデル(137)から提供し、上記言語エデ ィタと通信するドメインモデル(137) とから成る、一言語文書開発用コンピュータ系システム(105)。 ８．上記DM(137)が３体ドメインモデルであり、この３体ドメインモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタ(530)ドメ インモデル、 及び、上記機械翻訳システムのみが必要とする情報を含む機械翻訳ドメ ンモデル(520) の３つから構成されるようにした、上記特許請求範囲７のシステム(105)。 ９． (A) ソース言語で書かれた入力テキストを、著者(160)から対話的に受 け付けるように設計したテキストエディタ(140)と、 (i) 上記入力テキスト内で、語彙制約に準拠していない語の出 現を識別し、その語に代わる妥当な語葉を見つける上で、上記著者(160)を対話 的に支援する用語チェッカー(610)と、 (ii)上記入力テキストの構文的及び語義的な曖味さに関する対 話的フィードバックを、上記著者(160)に提供するとともに、曖味さのない制約 テキストを作成するための上記対話的フィードバックを、上記著者(160)に提供 する文法チェッカー(620)とから成る、 (B) 上記入力テキストを作成するために、上記著者(160)が使用する自 然言語サブセットに対し、語彙制約及び文法規約の準拠を対話的に実行する上記 テキストエディタ(140)の延長である言語エディタ(130)と、 (C) 曖昧さのない上記制約テキストの作成を支援するために、語彙単位 及びそれらの組み合わせに関する定義済みドメイン知識及び言語語義知識を提供 し、上記言語エ ディタと通信するドメインモデル(137) とから成る、一言語文書開発用コンピュータ系システム(105)。 １０．上記DM(137)が３体ドメインモデルであり、この３体ドメインモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタドメインモ デル(530)、 及び、上記機械翻訳システム(105)のみが必要とする情報を含む機械翻 訳ドメンモデル(520) の３つから構成されるようにした、上記特許請求範囲９のシステム(105)。 １１． (1) ソース言語の入力テキストをテキストエディタ(140)に入力し、 (2) 上記ドメインモデル(137)に存在し、用語及び文法に関するソース 二次言語規則を含む定義済み規約と照らし合わせながら、上記入力テキストをチ ェックし、 (3) 上記入力テキストに関する対話的フィードバックを著者(160)に提 供し、この対話的フィードバックで、上記の定義済み規約を満足しているかどう かを指摘し、さらにこの対話的フィードバックが、語彙単位及びそれらの組み合 わせに関し必要なドメイン知識及び言語語義知識に加え、自然言語サブセットの 文法を提供する上記ドメインモデル(137)を参照した後で行われるようにし、 (4) 上記ステップ(3)の完了後、曖味さのない制約テキストを生成する といった上記ステップから成る、一言語文書開発用コンピュータ系方法(105)。 １２．上記入力テキストを上記のソース二次言語規則に準拠させ、曖昧さを取り 除くために、上記の対話的フィードバックを実行するようにし、上記の定義済み 規約が、用語及び文法に関するソース二次言語規則を含むようにした、特許請求 範囲１１のコンピュータ系方法。 １３． (1)ソース言語の入力テキストをテキストエディタ(140)に入力し、 (2) 上記入力テキストを用語ソース言語規約と照合チェックし、 (3) 上記のソース入力テキストに無制約なソース言語が含まれている場 合、上記著者(160)が、上記入力テキストを制約ソーステキストに修正するまで 、上記ソース入力テキストに関する対話的フィードバックを上記著者(160)に提 供し、この対話的フィードバックが、語彙単位及びそれらの組み合わせに関し必 要なドメイン知識及び言語語義知識を提供する、上記ドメインモデル(137)を参 照した後で行われるようにし、 (4) 上記ドメインモデル(137)を参照することによって、上記制約ソー ステキストの構文誤りや語義の曖昧さをチェックし、 (5) 曖昧さのない制約テキストを生成するために、上記制約ソーステキ ストの上記構文誤りや上記語義の曖昧さを取り除くための対話的フィードバック を、上記著者(160)に提供する といった上記のステップから成る、一言語文書開発用コンピュータ系方法。 １４． (1) ソース言語で作成した最低１個の情報要素(410)を、テキストエデ ィタ(140)に入力し、 (2) 最低１個の上記情報要素を、用語ソース言語規約と照合チェックし 、 (3) 上記の最低１個の情報要素(410)に無制約なソース言語が含まれて いる場合、上記の最低１個の情報要素(410)が、制約ソーステキストに修正され るまで、上記の最低１個の情報要素(410)に関する対話的フィードバックを著者( 160)に提供し、この対話的フィードバックが、語彙単位及びそれらの組み合わせ についてのドメイン知識及び言語語義知識を提供する上記ドメインモデル(137) を参照した後で行われるようにし、 (4) 上記ドメインモデル(137)を参照することによって、上記制約ソー ステキストの構文誤りや語義の曖昧さをチェックし、 (5) 曖昧さのない最低１個の制約情報要素を生成するために、上記制約 ソーステキストの上記構文誤りや上記語義の曖味さを取り除くための対話的フィ ードバックを、上記著者(160)に提供し、 (6) 後の使用に備えて、上記最低１個の曖味さのない制約情報要素を保 存する といった上記のステップから成る、一言語文書開発用コンピュータ系方法。 １５． (1) ソース言語の入力テキストをテキストエディタ(140)に入力し、 (2) 上記入力テキストを用語ソース言語規約と照合チェックし、 (3) 上記のソース入力テキストに無制約なソース言語が含まれている場 合、上記入力テキストが制約ソーステキストに修正されるまで、上記ソース入力 テキストに関する対話的フィードバックを著者(160)に提供し、 (4) 上記制約ソーステキストの構文誤りや語義の曖味さをチェックし、 (5) 曖味さのない制約テキストを生成するために、上記制約ソーステキ ストの上記構文誤りや上記語義の曖昧さを取り除くための対話的フィードバック を、上記著者(160)に提供する といった上記のステップから成る、一言語文書開発用コンピュータ系方法。 １６． ソース言語で書かれた入力テキストを、著者(160)から対話的に受け付 けるように設計したテキストエディタ(140)と、 まず語彙制約の準拠を、次に文法規約の準拠を対話的に実施することに よって、上記入力テキストから曖昧さのない制約テキストを生成するために、上 記著者(160)と対話する上記テキストエディタ(140)の延長である言語エディタ(1 30)と、 曖昧さのない上記制約ソーステキストを、前編集及び後編集を必要とす ることなく外国語へ翻訳するように構成した、上記言語エディタ(130)に応答的 な機械翻訳システム(123)と、 曖昧さのない上記制約ソーステキストの作成並びに外国語への上記翻訳 を支援するために、語彙単位及びそれらの組み合わせに関する定義済みドメイン 知識及び言語語義知識を提供し、上記言語エディタ(130)及び上記機械翻訳シス テム(123)と通信するドメインモデル(137) から成る、前編集及び後編集を必要とすることなく、ソース言語入力テキストを 外国語へ翻訳するためのコンピュータ系システム(105)。 １７．上記ドメインモデル(137)が３体ドメインモデルであり、この３体ドメイ ンモデルが、 上記言語エディタ及び上記機械翻訳システム(123)が必要とする情報を 含むカーネル(510)、 上記言語エディタ(130)のみが必要とする情報を含む言語エディタドメ インモデル(530)、 及び、上記機械翻訳システム(123)のみが必要とする情報を含む機械翻 訳ドメンモデル(520) の３つのから構成されるようにした、上記特許請求範囲１６のシステム(105)。 １８．上記カーネル(510)が、それぞれの制約ソース言語語葉項目に対して１つ の語彙エントリを含むようにした、上記特許請求範囲１７のシステム(105)。 １９．選択の制限をサポートするために、上記機械翻訳ドメインモデル(510)が 、語彙概念を階層的に分類するための概念を含むようにした、上記特許請求範囲 １７のシステム(105)。 ２０．上記言語エディタドメインモデル(530)が、無制約ソース言語の類義語を 含むようにした、上記特許請求範囲１７のシステム(105)。 ２１．上記言語エディタ(130)の支援において、制約ソース言語語彙を特長づけ るために必要な全ての情報及び制限を、上記言語エディタドメインモデル(530) 及び上記カーネル(510)に含めるようにした、上記特許請求範囲１７のシステム( 105)。 ２２．上記の対話実施によって、曖味さのない制約テキストが得られる上記入力 テキストの一部を、翻訳可能性を示すタグでマーク付けするための手段を、さら にその構成要素として含むようにした、上記特許請求範囲１６のシステム(105) 。 ２３．複数の著者(160)がシステムを使用できるような翻訳サーバ環境で、上記 機械翻訳システム(23)が動作するようにした、上記特許請求範囲１６のシステム (105)。 ２４．上記著者(160)が、コンピュータネットワークの一部であるワークステー ションで作業を行うようにした、上記特許請求範囲１６のシステム(105)。 ２５．上記機械翻訳システム(123)が、曖昧さのない上記制約ソーステキストを インターリングアに翻訳するよう構成したインタプリタ(920)を含むようにした 、上記特許請求範囲１６のシステム(105)。 ２６．上記言語エディタ(130)が、上記著者(160)による上記対話操作を、バッチ モードで行えるようにした、上記特許請求範囲１６のシステム(105)。 ２７．図形エディタ(150)が、テキストラベルを生成するように設計し、上記著 者(160)が、上記言語エディタ(130)を使ってこのテキストラベルを編集し、その 後上記機械翻訳システム(123)で翻訳を行えるようにした、上記特許請求範囲１ ６のシステム（105)。 ２８．制約言語が、自然言語のサブセットとなり、語彙及び文法に関して指定さ れるようにした、上記特許請求範囲１６のシステム(105)。 ２９．上記言語エディタ(130)が、用語チェッカー(610)及び文法チェッカー(620 )から構成されるようにした、上記特許請求範囲１６のシステム(105)。 ３０．上記用語チェッカー(610)が、上記入力テキストを、使用の許された語彙 と照合チェックし、許されない語に対しては、その置換えとなるものを提案する ようにした、上記特許請求範囲２９のシステム(105)。 ３１．上記文法チェッカー(620)が、定義済み文法規則への準拠をチェックし、 未定義の文法構造に対しては、その置換えとなるものを提案するようにした、上 記特許請求範囲２９のシステム(105)。 ３２．上記文法チェッカー(620)が、語彙の曖昧さ及び構造の曖昧さに関して、 著者(160)にフィードバックを提供するようにした、上記特許請求範囲２９のシ ステム(105)。 ３３．上記文法チェッカー(620)が、対話的明瞭化の手段を提供するようにした 、上記特許請求範囲２９のシステム(105)。 ３４．上記用語チェッカー(610)が、スペルチェッカー(615)を含むようにした、 上記特許請求範囲２９のシステム(105)。 ３５．上記用語チェッカー(610)が、制約ソース言語に含まれていない語を識別 できるように構成した、上記特許請求範囲２９のシステム(105)。 ３６．上記入力テキストが、情報要素のかたまりとして提供されるようにした、 上記特許請求範囲１６のシステム(105) ３７．情報要素(410)の内容及び論理構造の記述を可能にするタグが、上記情報 要素に含まれるようにした、上記特許請求範囲３６のシステム(105)。 ３８． ソース言語で書かれた入力テキストを、著者(160)から対話的に受け付 けるように設計したテキストエディタ(140)と、 曖昧さのない制約テキストを生成するために、入力テキストに対して語 彙制約及び文法規約の準拠を実施する上で、上記著者(160)を対話的に支援する ようにし、上記入力テキストを作成するために上記著者(160)が使用する自然言 語サブセットに対して、上記の語彙制約及び文法規約の準拠を対話的に実行する 上記テキストエディタ(140)の延長である言語エディタ(130)と、 翻訳後テキストの後編集が不要となるように、曖昧さのない上記制約ソ ーステキストを翻訳する構成とした、上記言語エディタ(130)に応答的な機械翻 訳システム(123)から成る、一言語文書開発及び多言語翻訳用コンピュータ系シ ステム(105)。 ３９．曖昧さのない上記制約テキストを、後の使用に備えて保存しておくための 手段を、さらにその構成要素として含むようにした、上記特許請求範囲３８のシ ステム(105)。 ４０．上記の対話実施によって、曖昧さのない制約テキストが得られる上記入力 テキストの一部を、翻訳可能性を示すタグでマーク付けする手段を、さらにその 構成要素として含むようにした、上記特許請求範囲３８のシステム(105)。 ４１． ソース言語で書かれた情報要素を、著者(160)から対話的に受け付ける ように設計したテキストエディタ(140)と、 曖昧さのない制約情報要素を生成するために、上記情報要素に対して語 彙制約及び文法規約の準拠を実施する上で、上記著者(160)を対話的に支援する ようにし、上記入力テキストを作成するために上記著者(160)が使用する自然言 語サブセットに対して、上記の語彙制約及び文法規約の準拠を対話的に実行する 上記テキストエディタ(140)の延長である言語エディタ(130)と、 翻訳後テキストの後編集が不要となるように、曖味さのない上記制約情 報要素を 外国語へ翻訳する、上記言語エディタ(130)に応答的な機械翻訳システム(123)と 、 曖味さのない上記制約ソーステキストの作成並びに上記外国語への上記 翻訳を支援するために、語彙単位及びそれらの組み合わせに関する定義済みドメ イン知識及び言語語義知識を提供し、上記言語エディタ(130)及び上記機械翻訳 システム(123)と通信するドメインモデル(137) から成る、一言語文書開発及び多言語翻訳用コンピュータ系システム(105)。 ４２．上記ドメインモデル(137)が３体ドメインモデルであり、この３体ドメイ ンモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタドメインモ デル(530)、 及び、上記機械翻訳システムのみが必要とする情報を含む機械翻訳ドメ ンモデル(520) の３つから構成されるようにした、上記特許請求範囲４１のシステム(105)。 ４３． (A)ソース言語で書かれた入力テキストを、著者(160)から対話的に受け 付けるように設計したテキストエディタ(140)と、 (i) 上記語彙制約に準拠していない語の出現を識別し、その語 に代わる妥当な語彙を見つける上で、上記著者を対話的に支援する用語チェッカ ー(610)と、 (ii) 構文的及び語義的な曖味さに関する対話的フィードバッ クを、上記著者に提供するとともに、曖昧さのない制約テキストを作成するため の上記対話的フィードバックを提供する文法チェッカー(620)とから成る、 (B)上記入力テキストを作成するために、上記著者(160)が使用する自然 言語サブセットに対して、語彙制約及び文法規約の準拠を対話的に実行する上記 テキストエディタ(140)の延長である言語エディタ(130)と、 (C) 語彙単位及びそれらの組み合わせに関する定義済みドメイン知識及 び言語語義知識を提供し、上記言語エディタと通信するドメインモデル(137)と 、 (D) 翻訳後テキストの後編集が不要となるように、曖味さのない上記制 約テキストを任意の外国語へ翻訳する構成とした、上記言語エディタ(130)に応 答的な機械翻訳システム(123) とから成る、一言語文書開発及び多言語翻訳用コンピュータ系システム(105)。 ４４．上記ドメインモデル(137)が３体ドメインモデルであり、この３体ドメイ ンモデルが、 上記言語エディタ及び上記機械翻訳システムが必要とする情報を含むカ ーネル(510)、 上記言語エディタのみが必要とする情報を含む言語エディタドメインモ デル(530)、 及び、上記機械翻訳システムのみが必要とする情報を含む機械翻訳ドメ ンモデル(520) の３つから構成されるようにした、上記特許請求範囲４３のシステム(105)。 ４５． (1) ソース言語で作成した入力テキストを、テキストエディタ(140)に 入力し、 (2) 上記入力テキストを、用語ソース言語規約と照合チェックし、 (3) 上記のソース入力テキストに無制約なソース言語が含まれている場 合、上記著者が、このソース入力テキストを制約ソーステキストに修正するまで 、ソース入力テキストに関する対話的フィードバックを行い、最低１個の類義語 を含むリストから、この無制約ソース言語の置換えとなる語や句を上記著者が選 択できるようにし、 (4) 上記制約ソーステキストの構文誤りや語義の曖味さをチェックし、 (5) 曖昧さのない制約ソーステキストを生成するために、上記制約ソー ステキストの上記構文誤りや上記語義の曖昧さを取り除くための対話的フィード バックを、上記著者(160)に提供し、 (6) 曖味さのない上記制約ソーステキストを、ターゲット言語に翻訳す る といった上記のステップから成り、前編集及び後編集を必要とすることなく、ソ ース言語テキストを外国語へ翻訳するためのコンピュータ系(105)方法。 ４６．曖味さのない制約テキストが得られる上記入力テキストの一部を、翻訳可 能性を示すタグでマーク付けするためのステップを、さらにその構成要素として 含むようにした、上記特許請求範囲４５のシステム(105)。 ４７．ステップ(2)及び(4)が、さらに３体ドメインモデル(DM)(137)と通信する ためのステップを含み、この３体ドメインモデル(DM)(137)が、語彙単位及びそ れらの組み合わせに関する定義済みドメイン知識及び言語語義知識を提供するよ うにし、しかも上記３体ドメインモデルが、 上記言語エディタ(130)及び上記機械翻訳システム(123)が必要とする情 報を含むカーネル(510)、 上記言語エディタ(130)のみが必要とする情報を含む言語エディタドメ インモデル(530)、 及び、上記機械翻訳システム(123)のみが必要とする情報を含む機械翻 訳ドメンモデル(520) から構成されるようにした、上記特許請求範囲４５の方法。 ４８．翻訳を行うための上記ステップが、まず、曖昧さのない上記制約テキスト をインターリングアへ翻訳するためのステップを含むようにした、上記特許請求 範囲４５の方法。 ４９．チェックを行うための上記ステップ(2)が、 (a) 上記ソース入力テキスト内の用語を、制約ソース言語(CSL)語彙知 識ベースと照合チェックし、 (b) その用語が、上記CSL語彙知識ベースに存在しない場合は、 (i) 上記用語の綴りを標準辞書でチェックし、綴り間違いの時 は、上記著者がこの用語の綴りを訂正できるようにし、 (ii) 上記用語を、CSL語彙データベースでチェックし、 (iii) 上記用語が上記CSL語彙データベースに存在しない時は 、上記ドメインモデルに存在する最低１個のCSL類義語を提供し、著者がその中 から類義語を１個選択できるようにする といったステップから構成されるようにした、上記特許請求範囲４５の方法。 ５０．上記ソース入力テキスト内のあらゆる用語に対して、ステップ(a)及び(b) を繰り返すためのステップを、さらにその構成要素として含むようにした、上記 特許請求範囲４９の方法。 ５１．上記用語に対する直接的CSL類義語が存在しない場合は、関連するCSL語又 は句のリストを上記著者に提供するためのステップを、さらにその構成要素とし て含むようにした、上記特許請求範囲４９の方法。 ５２．上記著者が、非CSL用語を含む文章を書き換えることができるようにする ためのステップを、さらにその構成要素として含むようにした、上記特許請求範 囲４９の方法。 ５３．上記著者が、曖昧さの明瞭化に対する上記要求に応答した後で、上記ソー ス入力テキストにタグを挿入するためのステップを、さらにその構成要素として 含むようにした、上記特許請求範囲４５の方法。 ５４．上記ソース入力テキストが、情報要素のかたまりとして作成されるように した、上記特許請求範囲４５の方法。 ５５．図形では、上記ソース入力テキストが、テキストラベルとなるようにした 、上記特許請求範囲４５の方法。 ５６．上記著者に対して、上記ソース入力テキストに該当する２つ以上の意味の 指摘を提示するためのステップを、ステップ(3)に含めるようにした、上記特許 請求範囲４５の方法。 ５７． (1) ソース言語で作成した入力テキストを、テキストエディタ(140)に 入力し、 (2) 上記入力テキストを、ドメインモデル(137)に存在する定義済み規 約と照合チェックし、この定義済み規約が、用語及び文法に関するソース二次言 語規則を含むよう にし、さらに上記入力テキストを上記ソース二次言語規則に準拠させ、曖味さを 取り除くために、上記の対話的フィードバックを行うようにし、 (3) 上記の定義済み基準を満足していない場合は、上記入力テキストに 関する対話的フィードバックを著者(160)に提供し、この対話的フィードバック が、語彙単位及びそれらの組み合わせについてのドメイン知識及び言語語義知識 を提供するドメインモデルを参照した後で行われるようにし、さらにこの対話的 フィードバックを通じて、上記著者(160)が、曖昧さのない制約ソーステキスト を作成できるようにし、 (4) 曖昧さのない上記制約ソーステキストを、ターゲット言語へ翻訳す る といったステップから構成される、一言語文書開発及び多言語翻訳用コンピュー タ系方法。 ５８．曖昧さのない制約テキストが得られる上記入力テキストの一部を、翻訳可 能性を示すタグでマーク付けするためのステップを、さらにその構成要素として 含むようにした、上記特許請求範囲５７のシステム(105)。 ５９．コンピュータ系方法が、 (1) ソース言語で作成した入力テキストを、テキストエディタ(140)に 入力し、 (2) 上記入力テキストを、用語ソース言語規約と照合チェックし、 (3) 上記のソース入力テキストに無制約なソース言語が含まれている場 合、このソース入力テキストが制約ソーステキストに修正されるまで、ソース入 力テキストに関する対話的フィードバックを行い、この対話的フィードバックが 、語彙単位及びそれらの組み合わせについてのドメイン知識及び言語語義知識を 提供するドメインモデルを参照した後で行われるようにし、 (4) 上記ドメインモデル(137)を参照することによって、上記制約ソー ステキストの構文誤りや語義の曖昧さをチェックし、 (5) 曖昧さのない制約ソーステキストを生成するために、上記制約ソー ステキストの上記構文誤りや上記語義の曖味さを取り除くための対話的フィード バックを、上記著者(160)に提供し、 (6) 機械翻訳システム(123)を使って、上記ドメインモデルの支援を基 に、曖昧 さのない上記制約ソーステキストを外国語に翻訳する といったステップから構成される、一言語文書開発及び多言語翻訳用コンピュー タ系方法。 ６０． (1) ソース言語で作成した最低１個の情報要素(410)を、テキストエデ ィタ(140)に入力し、 (2) 最低１個の上記情報要素を、用語ソース言語規約と照合チェックし 、 (3) 上記の最低１個の情報要素に無制約なソース言語が含まれている場 合、上記の最低１個の情報要素が、制約ソーステキストに修正されるまで、上記 の最低１個の情報要素に関する対話的フィードバックを著者に提供し、この対話 的フィードバックが、語彙単位及びそれらの組み合わせについてのドメイン知識 及び言語語義知識を提供する上記ドメインモデル(137)を参照した後で行われる ようにし、 (4) 上記ドメインモデル(137)を参照することによって、上記制約ソー ステキストの構文誤りや語義の曖昧さをチェックし、 (5) 曖味さのない最低１個の制約情報要素を生成するために、上記制約 ソーステキストの上記構文誤りや上記語義の曖昧さを取り除くための対話的フィ ードバックを、上記著者に提供し、 (6) 後の使用に備えて、上記最低１個の曖昧さのない制約情報要素を保 存し、 (7) 機械翻訳システム(123)を使って、最低１個の曖昧さのない制約情 報要素を外国語に翻訳する といったステップから構成される、一言語文書開発及び多言語翻訳用コンピュー タ系方法。 ６１．上記情報要素が翻訳可能であることを承認するタグで、上記情報要素をマ ーク付けするためのステップを、さらにその構成要素として含むようにした、上 記特許請求範囲６０の方法。 ６２．上記著者(160)が、上記最低１個の情報要素に存在する無制約言語を置換 えるための語や句を、類義語リストから選択できるようにするステップが、対話 的フィードバックを提供するためのステップ(3)に含まれるようにした、上記特 許請求範囲６０の方法。