JP2006309446A - 分類辞書更新装置、分類辞書更新プログラムおよび分類辞書更新方法 - Google Patents

Abstract

【課題】更新（編集・追加）提案に対する採用・拒否などの評価を容易に導き出すことができ、効率良く辞書構築を行うことができる分類辞書更新装置、分類辞書更新プログラムおよび分類辞書更新方法を提供する。
【解決手段】受け付けた階層型分類辞書２０に対する更新提案を提案履歴記憶部１９に格納するとともに、受け付けた更新提案と近似する近似提案を提案履歴記憶部１９に格納されている過去の更新提案を検索して抽出し、抽出された近似提案を提示する。これにより、階層型分類辞書２０に対する更新（編集・追加）提案の近似提案を既存の辞書編集履歴を利用して提示することで、更新（編集・追加）提案に対する採用・拒否などの評価を容易に導き出すことができるので、効率良く辞書構築を行うことができる。
【選択図】 図７

Description

本発明は、分類辞書更新装置、分類辞書更新プログラムおよび分類辞書更新方法に関する。

オブジェクト指向データベース（ＯＯＤＢ）やオブジェクト・リレーショナル型データベース（ＯＲＤＢ）を代表とする階層型データベースでは、下位が上位分類の属性（プロパティ）を継承する階層構造を持つ。この階層型データベースにおいては、継承に従って下位の分類では属性が累増する。この上位分類の属性を下位に継承することは、通常「インヘリタンス」と呼ばれており、このような技術は非特許文献１に記載されている。

また、オブジェクト指向データベースにおいては、階層中の分類は「クラス」と呼ばれることが多い。一方、オブジェクト・リレーショナル型データベース（ＯＲＤＢ）においては、継承を許したテーブルがこれに相当し、上下関係をもつテーブル間において、上位のテーブルから下位のテーブルへ属性、すなわち上位テーブルを構成するコラムのヘッダ情報が下位テーブルへ継承される。各階層の分類に属する同じ属性種を持つデータを「インスタンス」と呼び、その集合をデータの「ポピュレーション」と呼ぶ。データのポピュレーションは、関係データベース（ＲＤＢ）あるいはＯＲＤＢにおいては、テーブルと呼ばれる構造に格納されるのが普通である。テーブルにおいてそれを構成する属性の並びをテーブルのヘッダと呼ぶ。

階層型データベースの一つとしては、製品情報を電子的に提供する電子カタログシステムを実装するための国際規格であるISO13584 Parts Library規格（以下、「PLIB」規格という）がある。この「PLIB」規格は、複数の“Part"（通常、「分冊」と訳される）からなる製品あるいは部品ライブラリデータに関するオブジェクト指向的な記述の方法とその交換ファイル形式のセマンティックス、すなわち、どのような用語や記述方式およびデータ型を用いるかを定める国際規格である。「PLIB」規格のPart42（分冊第４２）はIEC61360-2（分冊第２）と内容が共通している。この規格は、オブジェクト指向的に製品を分類し、個々の分類を特徴付ける属性群を明らかにし、分類に対するコンテンツをファイル交換する仕組みであるので、勿論、属性の継承の概念はこの中に含まれている。また、この規格はISO6523"Structure for Identification of organizations and organization parts"を引用して作られており、特に、ISO6523の定めるICD（International Code Designator）を活用して属性に対して世界的に一意な識別子を割り振ることが可能である。

近年においては、「PLIB」規格に準拠したシステムがいくつか提案されている（特許文献１，２）。

Object-Oriented Concepts, Databases, and Applications, Edited by Won Kim, 1989, ACM Press 特開２００４−１７７９９６号公報 特開２００４−１７８０１５号公報

ところで、「PLIB」規格では、製品の技術情報を“辞書”と“コンテンツ”によって表現することを基本概念としたデータ変換形式を規定している。この“辞書”は、下位が上位分類の属性を継承する階層構造を有している階層型分類辞書である。このような階層型分類辞書は、階層構造を定義するクラスと、そのクラスに定義している属性と、クラス及び属性を表すフィールド（アトリビュートと称する）から構成される。

このような階層型分類辞書の構築には、様様なツールやシステムが提供されている。例えば、ＰＬＩＢ−ＥＤＩＴＯＲ（フランスのＬＩＳＩ−ＥＮＳＭＡが提供する辞書構築ツール：http://www.plib.ensma.fr/）は代表的なツールである。

ところが、ＰＬＩＢ−ＥＤＩＴＯＲツールは、辞書に対する編集・追加などの更新提案を受ける機能を設けておらず、階層型分類辞書への更新（編集・追加）提案は、辞書管理者及び辞書ドメン専門家（ＤＯＭＡＩＮ ＥＸＰＥＲＴ）の経験に基づいて別途で評価・審議（提案へのコメントと投票）を行い、提案を採用するか否かを決定するようにしている。そして、更新（編集・追加）提案の採用が決定した場合には、階層型分類辞書の修正を該ＰＬＩＢ−ＥＤＩＴＯＲから行うことが可能になっている。

また、辞書管理者及び辞書ドメン専門家は、階層型分類辞書に対する更新（編集・追加）提案に対して、採用・拒否などの評価をその更新（編集・追加）の度に与えており、非効率的であった。

本発明は、上記に鑑みてなされたものであって、更新（編集・追加）提案に対する採用・拒否などの評価を容易に導き出すことができ、効率良く辞書構築を行うことができる分類辞書更新装置、分類辞書更新プログラムおよび分類辞書更新方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の分類辞書更新装置は、階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付手段と、この更新提案受付手段により受け付けた前記更新提案を随時格納する提案履歴格納手段と、前記提案履歴格納手段により格納された過去の前記更新提案を検索することによって、前記更新提案受付手段により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出手段と、この近似提案抽出手段により抽出された前記近似提案を提示する近似提案提示手段と、を備える。

また、本発明の分類辞書更新プログラムは、階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付機能と、この更新提案受付機能により受け付けた前記更新提案を随時格納する提案履歴格納機能と、前記提案履歴格納機能により格納された過去の前記更新提案を検索することによって、前記更新提案受付機能により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出機能と、この近似提案抽出機能により抽出された前記近似提案を提示する近似提案提示機能と、をコンピュータに実行させる。

また、本発明の分類辞書更新方法は、階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付工程と、この更新提案受付工程により受け付けた前記更新提案を随時格納する提案履歴格納工程と、前記提案履歴格納工程により格納された過去の前記更新提案を検索することによって、前記更新提案受付工程により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出工程と、この近似提案抽出工程により抽出された前記近似提案を提示する近似提案提示工程と、を含む。

本発明によれば、受け付けた階層型分類辞書に対する更新提案を格納するとともに、受け付けた更新提案と近似する近似提案を過去の更新提案を検索して抽出し、抽出された近似提案を提示する。これにより、階層型分類辞書に対する更新（編集・追加）提案の近似提案を既存の辞書編集履歴を利用して提示することで、更新（編集・追加）提案に対する採用・拒否などの評価を容易に導き出すことができるので、効率良く辞書構築を行うことができるという効果を奏する。

以下に添付図面を参照して、この発明にかかる分類辞書更新装置、分類辞書更新プログラムおよび分類辞書更新方法の最良な実施の形態を詳細に説明する。

［第１の実施の形態］
［１．階層型分類辞書について］
最初に、本実施の形態の前提となる、製品情報を電子的に提供する電子カタログシステムに用いられる階層型分類辞書について説明する。

図１は、階層型分類辞書の構成の一例を示す説明図である。図１に示す階層型データベースである階層型分類辞書は、複数の階層に分かれている。そして、各階層は、１又は２以上の分類項目を有しており、下位が上位の属性（プロパティ）を継承する性質を持つ。したがって、下位の階層の分類項目の属性は、上位の階層の分類項目の属性を継承する。ここで、階層型の分類項目はクラスと呼ばれ、各クラスは属性を持つ。図１に示す階層型分類辞書は、多重継承を含む一般的なクラス間の属性継承関係を示している。クラスはＡ０、Ｂ０、Ｂ１、Ｃ０、Ｃ１、Ｃ２、Ｃ３、Ｄ１で示され、属性はＰ０〜Ｐ７で示される。クラスＣ３においては、その親クラスＢ１から属性Ｐ０とＰ４を継承し、別の親クラスＤ１から属性Ｐ７を継承する。属性Ｐ６は、クラスＣ３において独自に定義された属性である。クラスＡ０とクラスＤ１は、独立したクラスである。ユニバーサルルート（Universal Root）は、全てのルートクラスを仮想的に含む全体クラスである。これは通常数学で言う「全体集合」に相当するものと考えられる。すなわち、全体クラスでは、継承すべき属性を特に含んでおらず、属性を持たないため、全てのルートクラスの親クラスとして扱うことが可能になる。

製品情報を電子的に提供する電子カタログシステムを実装するための国際規格であるＰＬＩＢ規格（ISO13584 parts Library）は、製品分類やその属性に用いる階層構造は単純木構造である。したがって、上位クラス（親クラス）は１つしか存在しない。親クラス以外の属性を継承する場合には、Case Of（「ケースオブ」）という属性の輸入（引用）のための特別な構造が用いられる。この構造は、図１の多重継承を、例えば番号の一番若い親クラスを主系列とするなどにより主系列と副系列に適宜分け、副系列に対してCase Ofという別名を与えた例とみなすことができる。また、ＯＲＤＢや一般的なオブジェクト指向データベースにおいては、全てのテーブルやクラスに親テーブル及び親クラスがあるわけではない。しかし、独立に存在するテーブルやクラスについても、図１に示すように、仮想的な「ユニバーサルルート」を設定することにより、全てのクラスをただ一つのルートからたどることが可能になり、単純木と変わらなくなる。

図２は、単純木を用いたＰＬＩＢ規格の階層型分類辞書の構成の一例を示す説明図である。図２に示すＰＬＩＢ規格の階層型分類辞書は、ユニバーサルルートを持たない。図２において、Ａ０、Ｂ０、Ｂ１、Ｃ０、Ｃ１、Ｃ２の木構造の部分は、分類階層を含む情報を表現する。本実施形態では木は単純木であり、クラスには一つの上位クラスしかない。

図２において、クラスＡ０は下位クラスＢ０とＢ１を持つ。クラスＢ０は、下位クラスＣ０及びＣ１を持ち、クラスＢ１は下位クラスＣ２およびＣ３を持つ。それぞれの製品クラスは属性項目を持ち、上位クラスの属性は下位クラスに継承される。図２中、コンテンツ１２１、１２２、１２３及び１２４は実際の製品データである。例えば、コンテンツ１２１は、Ｃ０という種類の製品データである。このコンテンツ１２１は、３種類分のコンテンツデータである。すなわち、コンテンツ１２１は、属性項目Ｐ０の属性値としてｘ１、ｘ２と、属性項目Ｐ１の属性値としてｙ１、ｙ２と、属性項目Ｐ２の属性値としてｚ１、ｚ２とを持つ。

上述したような階層型分類辞書は、本実施形態の処理対象として後述する辞書ＤＢ２０（図７参照）に格納されるが、実際のコンテンツデータであるコンテンツ１２１〜１２４に対する操作は本発明の対象外である。なお、図１のコンテンツ１１１〜１１４は、図２のコンテンツ１２１〜１２４と同様の性質を持つ。

辞書のクラスと属性は、それぞれのアトリビュートによって定義されている。ここで、「アトリビュート」とは、クラスや属性に詳細情報を規定するための情報フィールドである。クラスに所属する「属性」との混同を避けるために、クラスや属性の詳細情報フィールドを「アトリビュート」と呼んで本明細書の記述では区別する。クラスには、図３に示すように、クラスタイプ（class type）、クラス名（code）、親クラス（superclass）、標準名称（preferred name)などのアトリビュートが定義されている。属性には、図４に示すように、属性コード（code）、定義クラス（definition class）、データ型（data type）、標準名称（preferred name)などのアトリビュートが定義されている。

クラス及び属性を定義するアトリビュートは、PLIB定義に従って、内容のフォーマット、内容に対して編集可・不可（図３、図４に示すAdd、Modify、Delete）、内容の必須・オプショナル（図３、図４に示すObligation）などを決める。

［２．システムの構成］
本発明の第１の実施の形態について詳細に説明する。図５は、第１の実施の形態に係る分類辞書更新装置を含むシステムのシステム構築例を示す模式図である。本システムは、図５に示すように、分類辞書更新装置であるサーバコンピュータ（以下、サーバという）１にＬＡＮ（Local Area Network）等のネットワーク２を介して端末装置であるクライアントコンピュータ（以下、クライアント端末という）３が複数台接続されたサーバクライアントシステムを想定する。

クライアント端末３は、一般的なパーソナルコンピュータ等であり、辞書ＷＥＢブラウザ３０と、表示装置３１と、入力装置３２とを備えている（図７参照）。このようなクライアント端末３は、辞書ＷＥＢブラウザ３０を用いることにより、ネットワーク２を介してサーバ１が備える現在の辞書ＤＢ２０（図７参照）に対する更新（編集・追加）提案ｐを作成・提示することが可能になっている。

図６は、サーバ１のモジュール構成図である。サーバ１は、情報処理を行うＣＰＵ（Central Processing Unit）１０１、ＢＩＯＳなどを記憶した読出し専用メモリであるＲＯＭ（Read Only Memory）１０２、各種データを書換え可能に記憶するＲＡＭ（Random Access Memory）１０３、各種データベースとして機能するとともに各種のプログラムを格納するＨＤＤ（Hard Disk Drive）１０４、記憶媒体１１０を用いて情報を保管したり外部に情報を配布したり外部から情報を入手するためのＣＤ−ＲＯＭドライブ等の媒体駆動装置１０５、ネットワーク２を介して外部の他のコンピュータと通信により情報を伝達するための通信制御装置１０６、処理経過や結果等を操作者に表示するＣＲＴ（Cathode Ray Tube）やＬＣＤ（Liquid Crystal Display）等の表示装置１０７、並びに操作者がＣＰＵ１０１に命令や情報等を入力するためのキーボードやマウス等の入力装置１０８等から構成されており、これらの各部間で送受信されるデータをバスコントローラ１０９が調停して動作する。

このようなサーバ１では、ユーザが電源を投入するとＣＰＵ１０１がＲＯＭ１０２内のローダーというプログラムを起動させ、ＨＤＤ１０４よりＯＳ（Operating System）というコンピュータのハードウェアとソフトウェアとを管理するプログラムをＲＡＭ１０３に読み込み、このＯＳを起動させる。このようなＯＳは、ユーザの操作に応じてプログラムを起動したり、情報を読み込んだり、保存を行ったりする。ＯＳのうち代表的なものとしては、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）等が知られている。これらのＯＳ上で走る動作プログラムをアプリケーションプログラムと呼んでいる。なお、アプリケーションプログラムは、所定のＯＳ上で動作するものに限らず、後述の各種処理の一部の実行をＯＳに肩代わりさせるものであってもよいし、所定のアプリケーションソフトやＯＳなどを構成する一群のプログラムファイルの一部として含まれているものであってもよい。

ここで、サーバ１は、アプリケーションプログラムとして、分類辞書更新プログラムをＨＤＤ１０４に記憶している。この意味で、ＨＤＤ１０４は、分類辞書更新プログラムを記憶する記憶媒体として機能する。

また、一般的には、サーバ１のＨＤＤ１０４にインストールされる動作プログラムは、ＣＤ−ＲＯＭやＤＶＤなどの各種の光ディスク、各種光磁気ディスク、フレキシブルディスクなどの各種磁気ディスク、半導体メモリ等の各種方式のメディア等の記憶媒体１１０に記録され、この記憶媒体１１０に記録された動作プログラムがＨＤＤ１０４にインストールされる。このため、ＣＤ−ＲＯＭ等の光情報記録メディアやＦＤ等の磁気メディア等の可搬性を有する記憶媒体１１０も、分類辞書更新プログラムを記憶する記憶媒体となり得る。さらには、分類辞書更新プログラムは、例えば通信制御装置１０６を介して外部から取り込まれ、ＨＤＤ１０４にインストールされても良い。

サーバ１は、ＯＳ上で動作する分類辞書更新プログラムが起動すると、この分類辞書更新プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。サーバ１のＣＰＵ１０１が実行する各種の演算処理のうち、本実施の形態の特長的な処理について以下に説明する。

図７は、サーバ１を含むシステムの概略構成を示すブロック図である。図７に示すように、サーバ１は、分類辞書更新プログラムに従うことにより、ネットワーク通信部１１と、提案作成提示部１２と、近似提案抽出手段である近似提案検索部１３と、追加先検索手段である追加先検索部１４と、近似提案提示手段である近似提案提示部１５と、提案アドバイス提示手段である提案アドバイス提示部１６と、評価・コメント手段である提案評価コメント部１７と、辞書構築部１８と、提案履歴記憶部である提案履歴データベース（ＤＢ）１９と、階層型分類辞書である辞書データベース（ＤＢ）２０と、履歴統計分析手段である履歴統計分析部２１と、再提案アドバイス提示部２２と、再利用提案提示手段である再利用提案抽出・通知・提示部２３と、注目度提示手段である辞書注目度提示部２４と、を備える。以下、この各機能について説明する。

ネットワーク通信部１１を介して更新（編集・追加）提案ｐを受け取ったサーバ１は、近似提案検索部１３により、提案履歴ＤＢ１９から近似提案を検索する。すなわち、ネットワーク通信部１１は、更新提案受付手段として機能する。検索結果の近似提案は、近似提案提示部１５で表示される。提案ｐが新しい項目を追加する提案である場合、追加先検索部１４は、提案ｐへアドバイスする追加先を検索する。提案アドバイス提示部１６は、近似提案提示部１５で表示されている近似提案と追加先検索部１４で検索した追加先結果とを参考にし、提案ｐに対するコメント、評価、追加先を、辞書管理者へのアドバイスとして提示する。提案ｐが現在の項目に対する編集提案である場合には、追加先検索部１４で追加先を検索する必要がなくなり、提案アドバイス提示部１６で追加先のアドバイスを提示する必要がない。提案評価コメント部１７では、実際に提案ｐに対する評価、コメントを行う。ここで、評価結果は“拒否”と“採用”の２種類がある。提案ｐへの評価結果が“拒否”であれば、提案ｐはそのまま提案履歴ＤＢ１９へ保存されるが（提案履歴格納手段）、評価結果が“採用”であれば、提案履歴ＤＢ１９へ保存されるとともに（提案履歴格納手段）、辞書構築部１８により提案ｐの辞書ＤＢ２０への構築を行う。履歴統計分析部２１は、提案履歴ＤＢ１９の履歴の統計、分析を行う。辞書注目度提示部２４では、履歴統計分析部２１の履歴統計、分析結果によって、辞書（提案履歴ＤＢ１９、辞書ＤＢ２０）の注目度を提示する。例えば、注目度の高い項目を別色にするなどして提示する。また、再利用提案抽出・通知・提示部２３は、履歴統計分析部２１からの履歴統計、分析結果によって、再利用する提案を抽出し、再利用する事を提案者へ通知し、再利用する提案を提示する。提案者は、再提案アドバイス提示部２２に提示された“再提案へのアドバイス”を参考にし、提案作成提示部１２で提案の再編集、または作成をする。

なお、提案の再編集または作成についてはクライアント端末３の辞書ＷＥＢブラウザ３０から行い、提案作成提示部１２は提案を提示するだけの構成としても良い。また、提案の作成はローカルで行い、作成した提案をネットワーク通信部１１によりサーバ１へ提出し、提案作成提示部１２で提案を提示するだけの構成としても良い。

［３．サーバ１が備える特徴的な機能について］
次に、サーバ１が備える各部が発揮する機能のうち特徴的な機能について詳述する。

［３−１．辞書ＤＢ２０に対する提案について］
階層型分類辞書である辞書ＤＢ２０に対して、辞書のクラス・属性への変更・追加する要求が、本発明では更新提案と呼ばれるものである。本実施の形態で呼ぶ提案履歴は、記録された提案及び提案に対するコメント、評価などの情報を含んで、提案履歴ＤＢ１９に保存されるものである。

辞書ＤＢ２０への提案は、クラス提案と属性提案と２つのグループに分けられる。クラス提案グループと属性提案グループには、それぞれ追加提案と編集提案との２種類がある。

追加提案について説明する。属性追加提案である場合には、図８の構造例に示すように、属性に必須なアトリビュート内容と、その他提案提出後に、提案に追加した“コメント参考”、“評価”の内容を含む。クラス追加提案である場合には、図９の構造例に示すように、クラスに必須なアトリビュート内容を含まなければならない。

編集提案について説明する。編集提案は、図１０に示すフォーマットを有している。すなわち、“提案番号”、“提案アトリビュート”、“提案内容”、“提案元参考”と、その他提案内容によって後で決められた“提案分類”、“提案レベル”、“コメント参考”、“評価”の情報から構成される。クラス編集提案は、各クラスで行える。属性編集提案は、属性を定義したクラスからしか編集操作できない。図２において属性Ｐ１は、クラスＢ０で定義されている。属性Ｐ１はクラスＢ０の下位クラスＣ０、Ｃ１で継承されている。属性Ｐ１への編集は、Ｃ０、Ｃ１で拒否され、Ｂ０だけで許可される。

［３−２．近似提案検索部１３及び近似提案提示部１５の説明］
近似提案検索部１３における提案履歴ＤＢ１９から提案の近似提案を検索する手順、及び近似提案提示部１５における近似提案の検索結果表示を図１１に示すフローチャートに基ついて説明する。

まず、ステップＳ１において、入力された提案についてフォーマットチェックを行う。フォーマットチェックは、アトリビュート毎に、許可される文字、記号、最大文字数などを、ＰＬＩＢの定義に従うかどうかをチェックする。

提案のフォーマットがＰＬＩＢの定義に従っていると判定された場合には（ステップＳ１のＹｅｓ）、ステップＳ２に進み、提案は“追加提案”であるか“編集提案”であるかを判定する。

編集提案であると判定した場合には、ステップＳ３に進み、“提案内容により、近似する提案を検索する方法”（「近似提案検索方法１」と称する）により、近似提案を検索する。

一方、追加提案であると判定した場合には、ステップＳ４に進み、“クラス提案”であるか“属性提案”であるかを判定する。

追加属性提案であると判定した場合には、ステップＳ５に進み、“各アトリビュートの近似度の加算により、近似する提案を検索する方法”（「近似提案検索方法２」と称する）によって、近似提案を検索する。

追加クラス提案であると判定した場合には、ステップＳ６に進み、近似提案検索方法２と近似提案検索方法３とのいずれかを選択する。近似提案検索方法３は、クラス提案が所有する属性情報による近似提案検索方法である。近似提案検索方法２が選択された場合には、ステップＳ５に進み、近似提案検索方法３が選択された場合には、ステップＳ７に進む。

検索結果の近似提案は、ステップＳ８で提示される。近似提案は、提案内容と、提案評価と、提案に対するコメント情報と、近似度計算結果である近似度情報を含む。図１２はクラス編集提案の近似提案リスト例、図１３は属性追加提案の近似提案リスト例である。

ここで、近似提案検索方法１、２、３について以下に詳述する。

（１）近似提案検索方法１の説明
近似提案検索方法１は、編集提案に対して行う検索方法である。提案内容は、図１０に示したように、“提案番号”、“提案アトリビュート名”、“提案内容”、“提案元参考”の構造を持つ。

近似提案の検索は、提案履歴ＤＢ１９から提案と同じ“提案元参考”と“提案アトリビュート名”と“提案内容”を持つ提案を検索する。

既存の履歴提案はｐｉとし、提案ｐｘの内容を、
ｐｘ．提案アトリビュート名＝definition
ｐｘ．提案元参考＝JEMIMA_C00012
ｐｘ．提案内容＝“definition2”
とすると、既存履歴提案ｐｉと提案ｐｘの近似度Ｓ（ｐｘ、ｐｉ）は、
Ｓ（ｐｉ、ｐｘ）＝（Ｗ₁Ｓ（提案元参考） ＋ Ｗ₂Ｓ （提案アトリビュート名）＋ Ｗ₃Ｓ （提案内容））／ΣＷ_i （ｉ＝１、２、３）
で計算される。以降、Ｓ（ｐｉ、ｐｘ）はＳ（ｐ）と略称する。なお、Ｗ₁〜Ｗ₃は、各近似度の重みであって、システムによって設定は異なる可能性がある。Ｓ（ｐ）は設定によって、計算される。一例として、Ｗ₁＝０．５、Ｗ₂＝０．５、Ｗ₃＝１０に設定すると、Ｓ（ｐ）の値は、｛0、0.02％、1%、50%、55%、91%、95%、100％｝のリストである。

Ｓ（提案元参考）は、ｐｘの提案元参考とｐｉの提案元参考の近似度を表す。条件“ｐｘ．提案元参考＝ｐｉ．提案元参考”が成立する場合は、提案元参考の近似度は“Ｓ（提案元参考）＝１”である。なお、提案元参考が編集提案に含まれていない場合には、提案元参考の近似度を求めなくても良い。

Ｓ（提案アトリビュート名）は、ｐｘの提案アトリビュート名とｐｉの提案アトリビュート名の近似度を表す。条件“ｐｘ．提案アトリビュート名＝ｐｉ．提案アトリビュート名”が成立する場合は、提案アトリビュートの近似度は“Ｓ（提案アトリビュート名）＝１”である。

Ｓ（提案内容）は、ｐｘの提案内容とｐｉの提案内容の近似度を表す。条件“ｐｘ.提案内容＝ｐｉ．提案内容”が成立する場合は、提案内容の近似度は“Ｓ（提案内容）＝１”である。提案内容の意味分析により、Ｓ（提案内容）の値を｛0、0.5、1｝から一つを指定する事も可能である。Ｓ（提案内容）の値を0．5に指定した場合には、ｐｘの提案内容とｐｉの提案内容は部分的に一致する場合である。システムによって、Ｓ（提案内容）を指定される値は異なる可能性がある。

Ｓ（ｐ）の値が最も高い時のｐｉは、ｐｘと最も近似する履歴提案とされる。本実施の形態において、ｐｘと近似する提案リストは、Ｓ（ｐ）は50％以上である履歴提案ｐｉから構成される。図１２はｐｘの近似提案リストの一例である。

（２）近似提案検索方法２の説明
近似提案検索方法２は、新しい項目を追加する追加提案への近似提案を検索方法である。提案内容は、図８に示すようなISO13584のPLIB規格に定義した必須のアトリビュートを全て含まなければならない。近似提案の近似度は、個別アトリビュートの近似度を、累計した結果である。但し、提案段階では、クラスと属性のcodeは正式になっていないため、近似度の計算には、Codeの近似度を含まない。

ここで、図８に示す属性追加提案ｐｙを例にして説明する。既存の属性提案履歴ｐｉと提案ｐｙとの近似度Ｓ（ｐｉ、ｐｙ）は、
Ｓ（ｐｉ、ｐｙ）＝（Ｗ₁Ｓ（definition class） ＋ Ｗ₂Ｓ（data type） ＋ Ｗ₃Ｓ（preferred name） ＋ Ｗ₄Ｓ（short name） ＋ Ｗ₅Ｓ（definition） ＋ Ｗ₆Ｓ（unit） ＋ Ｗ₇Ｓ（preferred letter symbol） ＋ Ｗ₈Ｓ（synonymous name） ＋ Ｗ₉Ｓ（property type classification） ＋ Ｗ₁₀Ｓ（source document of definition） ＋ Ｗ₁₁Ｓ（note） ＋ Ｗ₁₂Ｓ（remark） ＋ Ｗ₁₃Ｓ（condition） ＋ Ｗ₁₄Ｓ （formula） ＋ Ｗ₁₅Ｓ（format））／ΣＷ_i （ｉ＝１、２、…１５）
で計算される。Ｓ（definition class）は、履歴提案ｐｉと提案ｐｙのdefinition classの近似度であって、“ｐｉ．definition class＝ｐｙ．definition class”の場合、“Ｓ（definition class）＝１”である。その他のアトリビュートのＳについても、同様に計算される。

ところで、アトリビュートは、重要性によりメーンアトリビュートとサブアトリビュートに分類されている。メーンアトリビュートは、必須アトリビュートであるが、必須アトリビュートは、必ずメーンアトリビュートである事ではない。例えば、属性のメーンアトリビュートは、図４において網掛けで示すcode、definition class、data type、preferred name、short name、definition、unitであって、その他のアトリビュートはサブアトリビュートである。クラスのメーンアトリビュートは、図３において網掛けで示すcode、preferred name、short name、definitionであって、その他はサブアトリビュートである。辞書のクラスと属性のアトリビュートを変更、追加の可能性があり、メーンアトリビュートと、サブアトリビュートの分類も変更可能である。

近似度を累算する際には、メーンアトリビュートとサブアトリビュートとは、違う重みで計算する。上記例では、メーンアトリビュートに付ける重みＷ₁〜Ｗ₆は１０とし、サブアトリビュートに付ける重みＷ₇〜Ｗ₁₅は１とすると、Ｓ（ｐｉ、ｐｙ）は、
Ｓ（ｐｉ、ｐｙ）＝（１０＊Ｓ（definition class） ＋ １０＊Ｓ（data type） ＋ １０＊Ｓ（preferred name） ＋ １０＊Ｓ（short name） ＋ １０＊Ｓ（definition） ＋ １０＊Ｓ （unit） ＋ １＊Ｓ（preferred letter symbol） + １＊Ｓ（synonymous name） ＋ １＊Ｓ（property type classification） ＋ １＊Ｓ（source document of definition） ＋ １＊Ｓ（note） ＋ １＊Ｓ（remark） ＋ １＊Ｓ（condition） ＋ １＊Ｓ（formula） ＋ １＊Ｓ（format））／Σ（１０＊７＋１＊９）
になる。

Ｓ（ｐ）の値が最も高い時のｐｉは、ｐｙと最も近似する提案とされる。図１３は、属性追加提案の近似提案例である。

（３）近似提案検索方法３の説明
近似提案検索方法３は、追加クラス提案が所有する属性により近似提案を検索する方法である。図１４を用いて説明する。

図１４は、クラス追加提案Ｃｘに対してＣｘが含む属性により近似提案を探す手順を示すフローチャートである。図１４に示すように、ステップＳ１１では、既存辞書階層の上位から始め、Ｃｘ全ての属性を所有するクラス（仮にcls_ａとする）が存在するか否かを検索する。

Ｃｘ全ての属性を所有するクラスが存在する場合には（ステップＳ１１のＹｅｓ）、cls_aは、クラス追加提案Ｃｘの近似提案候補と決定される（ステップＳ１２）。

Ｃｘ全ての属性を所有するクラスが存在しない場合には（ステップＳ１１のＮｏ）、ステップＳ１３に進み、Ｃｘの属性を一番数多く含むクラスを検索し（検索結果は多数の可能性があり、仮にcls_listとする）、新規クラスＣｘの属性に新規属性があるか否かを判定する（ステップＳ１４）。

新規クラスＣｘの属性に新規属性がないと判定した場合（ステップＳ１４のＮｏ）、すなわち追加属性を定義していないと判定した場合には、ステップＳ１５に進み、cls_listを近似提案候補とする。

一方、新規クラスＣｘの属性に新規属性が存在していると判定した場合（ステップＳ１４のＹｅｓ）、すなわち追加属性を定義していると判定した場合には、ステップＳ１６に進み、新規属性との近似提案を前記近似提案検索方法２によって検索して決定し、その近似提案を定義するクラス（仮にcls_pとする）を検索して、ステップＳ１７に進む。

ステップＳ１７では、上記cls_pが、ステップＳ１３における検索結果のcls_listにあるクラス、またはその下位クラスで定義してあるかどうかのチェック行う。

cls_pが、cls_listにあるクラス１、または、クラス１の下位クラスで定義してあると判定した場合（ステップＳ１７のＹｅｓ）、クラス１は、追加クラスＣｘの近似提案と候補される（ステップＳ１８）。

一方、cls_pが、cls_listにあるクラス、またはその下位クラスで定義してないと判定した場合（ステップＳ１７のＮｏ）、cls_pとcls_listとを追加クラス提案Ｃｘの近似提案と候補する（ステップＳ１９）。

以上が、追加クラス提案が所有する属性により近似提案を検索する近似提案検索方法３である。

ここで、近似提案検索方法３による図１５に示す辞書に対する新規クラスＣｘ（ｐ１，ｐ２，ｐｙ）の近似提案の探索例について説明する。

辞書は、Ｃ１〜Ｃ６のクラスを有しており、各自が属性を定義してある。新規クラスＣｘは、自分が定義した新規属性ｐｙと親から継承した属性ｐ１，ｐ２とから構成されている。本実施の形態においては、新規クラスＣｘの属性は、自分が定義した新規属性及び継承した属性の全部、または一部であるとする。Ｃｘ属性のうち、ｐ１，ｐ２は既に定義している属性であり、ｐｙは新規追加属性とする。

図１４に示した手順によると、ステップＳ１１では、Ｃｘの全ての属性を含むクラスcls_aが存在しないので、ステップＳ１３へ進む。ステップＳ１３では、新規クラスＣｘの属性ｐ１，ｐ２を含むクラスリストcls_listが、Ｃ１及びその下位クラスＣ１〜Ｃ６であると判定される。

そして、Ｃｘに新規属性ｐｙが存在するため（ステップＳ１４のＹｅｓ）、ステップＳ１６に進み、近似提案検索方法２によって新規属性ｐｙとの近似提案を検索する。例えば、ｐｙの近似提案はｐ８であるとすると、ステップＳ１７では、ｐ８はＣ６で定義していると判定することができる。その結果、ステップＳ１８では、クラスＣ６及びその下位クラス（存在する場合）は、新規クラスＣｘの近似提案候補とされる。

続いて、近似提案検索方法３による図１５に示す辞書に対する新規クラスＣｘ'（ｐ１，ｐ７，ｐ８）の近似提案の探索例について説明する。

図１４に示した手順によると、ステップＳ１１では、Ｃｘ'の全ての属性を含むクラスcls_aが存在しないので、ステップＳ１３へ進む。ステップＳ１３では、新規クラスＣｘ'の属性を数多く含むクラスのリストは、Ｃ５（ｐ１，ｐ７）、Ｃ６（ｐ１，ｐ８）になる。

新規クラスＣｘ'には新規追加属性が存在していないため（ステップＳ１４のＮｏ）、クラスＣ５とクラスＣ６とが新規クラスＣｘ'の近似提案候補とされる（ステップＳ１５）。

以上により、提案履歴ＤＢ１９から提案の近似提案を検索することができる。

このようにして検索した近似提案は、近似提案提示部１５で表示される。また、提案ｐに対するコメント、評価が、提案アドバイス提示部１６により後述する追加先検索部１４で検索した追加先結果とともに、辞書管理者へのアドバイスとして提示される。図１６は、辞書管理者へのアドバイス例である。

［３−３．追加先検索部１４及び提案アドバイス提示部１６の説明］
新しいクラスを追加する際には、前述したように、近似提案検索方法２と近似提案検索方法３の方法とにより近似提案を探す。追加先検索部１４及び提案アドバイス提示部１６は、検索結果の近似提案のロケーションによって、新しいクラス提案の追加先をアドバイスする。

ここで、図１５に示す辞書に対する新規クラスＣｘ（ｐ１，ｐ２，ｐｙ）を例として、追加提案に対する追加するロケーションをアドバイスする機能を説明する。

追加するクラスＣｘに新しい属性を含む場合は、まず、新しい属性ｐｙの追加ロケーションを決める。ｐｙのロケーションを決めるため、近似提案検索方法２によりｐｙとの近似提案を探す必要がある。前述したように、例えばｐｙの近似提案はｐ８であるとすると、ｐｙはｐ８を定義したＣ６に追加するようとアドバイスする。

より詳細には、Ｃｘの属性は｛ｐ１，ｐ２，ｐｙ｝であり、すなわち｛ｐ１，ｐ２，ｐ８｝である事が分かる。Ｃｘの３つの属性を所有するクラスＣ６は、Ｃｘとの近似提案の候補とされている。但し、Ｃ６には、ｐ１，ｐ２，ｐ８の他に、Ｃｘに定義していない属性ｐ４とｐ９が存在する。ｐ４は親クラスＣ３から継承してあり、ｐ９はＣ６で定義している。この場合は、Ｃｘを追加するロケーションアドバイスは、
（１）図１５のＡルートに示すようになる。クラスＣ３の子供、クラスＣ６の親である。Ｃｘに含む属性は、｛ｐ１，ｐ２，ｐ４，ｐ８｝になる。
（２）図１５のＢルートに示すようになる。クラスＣ６の子供である。Ｃｘに含む属性は、｛ｐ１，ｐ２，ｐ４，ｐ８、ｐ９｝になる。Ｃ６には、その他の子供クラスが存在する場合に、Ｃ６及びＣ６の子供クラスは、全て追加先の候補クラスである。
のようになる。

この場合、Ｃｘの追加は、“クラスＣ１の子供”、或いは“クラスＣ３の子供”にするのが、不可である。Ｃｘが新たに定義する属性ｐ８は、既にクラスＣ６に定義してある。Ｃｘは“クラスＣ１の子供”、或いは“クラスＣ３の子供”にすると、属性ｐ８の定義重複になってしまう。本発明には、属性はユニークであり、重複定義を許されていないため、Ｃｘの追加先は、“クラスＣ１の子供”、“クラスＣ３の子供”、及びその他前記同じ現象を起こる追加先にするのが、不可である。

システムは、Ｃｘの追加ロケーション候補としてはＡとＢの両方をアドバイスし、各追加ケースにＣｘが含む属性も合わせて、辞書管理者へ提示する。辞書管理者は、アドバイスされた候補ロケーションに対して追加場所を選択する。

なお、クラスＣｘが定義するアトリビュートの内容によっては、近似提案検索方法２を用いて探した近似提案によって、Ｃｘの追加先をアドバイスする事もできる。まず、近似提案検索方法２により、Ｃｘが定義するアトリビュートの内容に基づいて、Ｃｘとの近似提案を検索する。例えば、Ｃｘと最も近似する提案はＣ６であるなら、Ｃｘが所有する属性と、近似提案Ｃ６が所有属性と比較する。上記記述により、Ｃｘへの追加先は、ＡとＢとの両方をアドバイスされる。

［３−４．提案評価コメント部１７の説明］
提案評価コメント部１７では、実際に提案ｐに対する評価、コメントを行う。評価結果は、“拒否”と“採用”の２種類がある。

ここで、図１７は提案評価プロセスを示すフローチャートである。前述した提案アドバイス提示部１６により近似提案の評価及びコメントが提示されると、図１７に示すように、提案評価コメント部１７は、辞書管理者に提案に対する評価を行わせる（ステップＳ２１）。

評価結果が“採用”になった提案に対しては、ステップＳ２２に進み、提案が編集提案であるか追加提案であるかを判定する。

編集提案である場合には（ステップＳ２２のＹｅｓ）、ステップＳ２３に進み、提案のレベル（高、普通）を自動的に決める。提案レベルの決める方法は、提案するアトリビュートがメーンアトリビュートであれば、提案レベルが“高”であって、提案アトリビュートがサブアトリビュートであれば、提案レベルは“普通”に設定される。さらに、ステップＳ２３では、提案分類が“Edit（提案編集）”であるか“Technical proposal（技術提案）”であるかを設定する。なお、提案分類が“Edit”であるか“Technical proposal”であるかの決定は、辞書管理者に行わせる。決められた結果は、図１０に示すように、各編集提案の、“提案分類”、“レベル”の列に記録される。

一方、編集提案でない場合には（ステップＳ２２のＮｏ）、すなわち追加提案である場合には、提案レベルと提案分類を決める必要はない。

［３−５．再提案アドバイス提示部２２及び再利用提案抽出・通知・提示部２３］
辞書管理者は、履歴統計分析部２１における提案履歴ＤＢ１９の履歴の統計、分析に基づき、再利用する提案を抽出し、再利用する事を提案者へ通知し、再利用する提案を提示する（再利用提案抽出・通知・提示部２３）。具体的には、辞書管理者は、提案ｐｘに対する近似提案を提案履歴から検索し、検索結果を近似度の順に並べて提示する。

また、辞書管理者は、“再提案へのアドバイス”を提案者に対して提示する（再提案アドバイス提示部２２）。すなわち、辞書管理者は、近似提案に対するコメントなどを参考し、提案ｐｘに対するコメントを行う。例えば、辞書管理者が、コメントを参考して出した評価結論は“拒否”であるが、ある内容を変更すれば評価は“採用”になれるとの編集アドバイスをコメントすることができる。このような提案ｐｘについて“再提案できる”事及び再提案に対する編集アドバイスは、電子メールで提案者に通知するか、または、ネットワーク２を介して提案者のクライアント端末３に通知し、提案者に明示する。明示する方法は、該当提案を、別色、別フォントなどの形で提示する。提案者は、その旨を受けて、再提案する作業を行う。

また、辞書管理者は、提案履歴ＤＢ１９の拒否された提案ｐｒに対しても、上記と同じ手法で、提案ｐｒとの近似提案の検索ができて、近似提案のコメントなどの参考によって、提案ｐｒの再提案する価値があるかどうかを判断できる。“再提案できる”との判断になったら、提案ｐｒについて“再提案できる”事及び再提案に対する編集アドバイスを、電子メールかネットワーク２を介して提案者のクライアント端末３に通知し、提案者へ明示することができる。

［３−６．辞書注目度提示部２４］
辞書注目度提示部２４では、履歴統計分析部２１の履歴統計、分析結果によって、辞書（提案履歴ＤＢ１９、辞書ＤＢ２０）の注目度を提示する。これにより、“提案元参考”の統計により、多く提案された“提案元”が分かるので、その“提案元”（クラス、または属性）は、辞書（提案履歴ＤＢ１９、辞書ＤＢ２０）において、注目度の高い項目として明示される。さらに、“提案アトリビュート”が多数存在するアトリビュートを、注目度が高い項目として明示する。明示する方法は、注目度の高い項目を、別色、フォントなどで提示する方法がある。システムによって明示する方法は異なる。

このように本実施の形態によれば、受け付けた階層型分類辞書に対する更新提案を提案履歴記憶部に格納するとともに、受け付けた更新提案と近似する近似提案を提案履歴記憶部に格納されている過去の更新提案を検索して抽出し、抽出された近似提案を提示する。これにより、階層型分類辞書に対する更新（編集・追加）提案の近似提案を既存の辞書編集履歴を利用して提示することで、更新（編集・追加）提案に対する採用・拒否などの評価を容易に導き出すことができるので、効率良く辞書構築を行うことができる。

［第２の実施の形態］
次に、本発明の第２の実施の形態を図１８に基づいて説明する。なお、前述した第１の実施の形態と同じ部分は同じ符号で示し説明も省略する。

本実施の形態は、より採用率の高い提案を提案者に提出させるために、提案者は正式に提案を提出する前に提案草案を提出させ、提案履歴から提案草案との近似提案を検索し、検索した近似提案の評価結果及びコメントによって、提案草案への事前シミュレーション評価・コメントをすることができるようにしたものである。

図１８は、提案草案に対する事前シミュレーション処理の流れを示すフローチャートである。提案草案は、図８ないし図１０で示したような正式な提案と同じ構造を有している。事前シミュレーション処理は、提案者が正式に提案を提出する前に、自分の提案草案に対して、事前シミュレーションすることができるものである。事前シミュレーション処理を実行するか否かは、事前にモード選択することができるものとする。

図１８に示すように、提案草案ｐが入力され（ステップＳ３１のＹｅｓ：提案草案受付手段）、提案草案ｐに対する事前シミュレーションが選択されている場合には（ステップＳ３２のＹｅｓ）、提案草案ｐの近似提案を、第１の実施の形態で説明した手法によって検索する（ステップＳ３３：模擬近似提案抽出手段）。

ステップＳ３３において最も近似する提案ｐｋが検索されると、当該近似提案ｐｋについての評価、コメント結果を提示する（ステップＳ３４：模擬近似提案提示手段）。評価は、近似提案ｐｋが採用されたか、拒否されたかという結果である。コメントは、各関係者から近似提案ｐｋに対してコメントした内容である。これにより、提案者は、自分の提案草案ｐを再編集する必要性や編集内容などを確認できる。

その後、提案者が、近似提案ｐｋの評価、コメント内容を参考して、再編集する必要があると判断し、近似提案ｐｋを再編集する事が選択された場合には（ステップＳ３５のＹｅｓ）、ステップＳ３１戻り、再編集した提案の入力に待機する。事前シミュレーションは、複数回行えるので、再編集した提案に対しても、再度、事前シミュレーションすることができる。

一方、ステップＳ３１〜Ｓ３４の処理を繰り返し、近似提案ｐｋを再編集しない事が選択された場合には（ステップＳ３５のＮｏ）、正式に提案草案ｐを提案する（ステップＳ３６）。

なお、提案草案ｐに対して、事前シミュレーションを行わない場合もありえる。その場合には、提案草案ｐに対する事前シミュレーションが選択されず（ステップＳ３２のＮｏ）、そのまま提案草案ｐを提案する（ステップＳ３６）。

このように本実施の形態によれば、提案者は、正式に提案を提出する前に提案草案を作成し、提案草案に対して事前シミュレーション処理を実行する。これにより、辞書提案者は、事前シミュレーションの結果である評価・コメントにより、提案草案に基づいてより採用され易い提案を再修正または作成し、正式な更新提案として提出することができるので、効率良く辞書を更新（編集・追加）することができる。

本実施の形態の前提となる階層型分類辞書の構成の一例を示す説明図である。 単純木を用いたＰＬＩＢ規格の階層型分類辞書の構成の一例を示す説明図である。 クラスに関係する辞書修正ルールの一例を示す説明図である。 属性に関係する辞書修正ルールの一例を示す説明図である。 第１の実施の形態に係る分類辞書更新装置を含むシステムのシステム構築例を示す模式図である。 サーバのモジュール構成図である。 サーバを含むシステムの概略構成を示すブロック図である。 属性追加提案の構造例を示す説明図である。 クラス追加提案の構造例を示す説明図である。 編集提案の構造例を示す説明図である。 近似提案の検索処理の流れを示すフローチャートである。 クラス編集提案の近似提案リスト例を示す説明図である。 属性追加提案の近似提案リスト例を示す説明図である。 クラス追加提案Ｃｘに対してＣｘが含む属性により近似提案を探す手順を示すフローチャートである。 近似提案検索方法３による近似提案の探索例を示す説明図である。 辞書管理者へのアドバイス例を示す正面図である。 提案評価プロセスを示すフローチャートである。 本発明の第２の実施の形態の提案草案に対する事前シミュレーション処理の流れを示すフローチャートである。

符号の説明

１ 分類辞書更新装置
１１ 更新提案受付手段
１３ 近似提案抽出手段
１４ 追加先検索手段
１５ 近似提案提示手段
１６ 提案アドバイス提示手段
１７ 評価・コメント手段
２０ 階層型分類辞書
２１ 履歴統計分析手段
２３ 再利用提案提示手段
２４ 注目度提示手段

Claims (17)

1. 階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付手段と、
   この更新提案受付手段により受け付けた前記更新提案を随時格納する提案履歴格納手段と、
   前記提案履歴格納手段により格納された過去の前記更新提案を検索することによって、前記更新提案受付手段により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出手段と、
   この近似提案抽出手段により抽出された前記近似提案を提示する近似提案提示手段と、
   を備えることを特徴とする分類辞書更新装置。
2. 前記近似提案提示手段により提示される前記近似提案には、前記更新提案受付手段により受け付けた更新提案内容と、前記更新提案受付手段により受け付けた更新提案に対する拒否・採用の評価結果と、前記更新提案受付手段により受け付けた更新提案に対するコメント内容と、近似度計算結果である近似度情報とが含まれる、
   ことを特徴とする請求項１記載の分類辞書更新装置。
3. 前記更新提案受付手段により受け付けた更新提案が既存のクラスまたはプロパティを編集する編集提案である場合、
   前記近似提案抽出手段は、前記編集提案の提案アトリビュート又は提案内容に基づく近似度の値が最も高いものを過去の前記更新提案から検索し、前記編集提案に近似する前記近似提案として抽出する、
   ことを特徴とする請求項１記載の分類辞書更新装置。
4. 前記更新提案受付手段により受け付けた更新提案が新しいクラスまたはプロパティを追加する追加提案である場合、
   前記近似提案抽出手段は、前記追加提案が所有する各アトリビュートに基づく近似度を累計した値が最も高いものを過去の前記更新提案から検索し、前記追加提案に近似する前記近似提案として抽出する、
   ことを特徴とする請求項１記載の分類辞書更新装置。
5. 前記更新提案受付手段により受け付けた更新提案が新しいクラスを追加する追加提案である場合、
   前記近似提案抽出手段は、前記追加提案が所有するプロパティの集合に対して同一性が最も高いものを過去の前記更新提案から検索し、前記追加提案に近似する前記近似提案として抽出する、
   ことを特徴とする請求項１記載の分類辞書更新装置。
6. 前記更新提案受付手段により受け付けた更新提案が新しいクラスまたはプロパティを追加する追加提案である場合、前記近似提案抽出手段により抽出された前記近似提案のロケーションに応じ、前記追加提案の追加先をアドバイスする追加先検索手段を備える、
   ことを特徴とする請求項４または５記載の分類辞書更新装置。
7. 前記追加先検索手段は、前記追加提案が新しいクラスを追加する提案である場合、当該追加提案が所有するプロパティの全部或いは部分により検索した前記近似提案の階層構造に応じ、追加先をアドバイスする、
   ことを特徴とする請求項６記載の分類辞書更新装置。
8. 前記追加先検索手段は、前記追加提案が新しいクラスを追加する提案である場合、当該追加提案が所有するアトリビュートの内容によって検索した前記近似提案が所有するプロパティと、前記追加提案が所有するプロパティとの比較結果に応じ、前記追加提案の追加先をアドバイスする、
   ことを特徴とする請求項６記載の分類辞書更新装置。
9. 前記追加先検索手段は、前記追加提案が新しいプロパティを追加する提案である場合、前記近似提案を定義したクラスを前記追加提案の追加先としてアドバイスする、
   ことを特徴とする請求項６記載の分類辞書更新装置。
10. 前記近似提案抽出手段により抽出された前記近似提案と前記更新提案受付手段により受け付けた更新提案とが同一である場合には、前記更新提案を拒否する評価結果をアドバイスする提案アドバイス提示手段を備える、
    ことを特徴とする請求項１記載の分類辞書更新装置。
11. 前記近似提案抽出手段により抽出された前記近似提案の評価結果を前記更新提案受付手段により受け付けた更新提案の評価結果としてアドバイスする提案アドバイス提示手段を備える、
    ことを特徴とする請求項１記載の分類辞書更新装置。
12. アドバイスされた評価結果に従って、前記更新提案に対する評価・コメントを辞書管理者に行わせる評価・コメント手段を備える、
    ことを特徴とする請求項１０または１１記載の分類辞書更新装置。
13. 前記提案履歴記憶部に格納されている前記更新提案の履歴の統計、分析を行う履歴統計分析手段と、
    この履歴統計分析手段からの履歴統計、分析結果に従って、再利用する提案を抽出し、再利用する事を提案者へ通知し、再利用する提案を提示する再利用提案提示手段と、
    を備えることを特徴とする請求項１記載の分類辞書更新装置。
14. 前記履歴統計分析手段からの履歴統計、分析結果に従い、注目度の高いクラス、プロパティ、アトリビュートを提示する注目度提示手段を備える、
    ことを特徴とする請求項１３記載の分類辞書更新装置。
15. 提案草案の近似提案を受け付ける提案草案受付手段と、
    この提案草案受付手段により受け付けた前記提案草案の近似提案を、前記近似提案抽出手段により検索する模擬近似提案抽出手段と、
    この模擬近似提案抽出手段により抽出された前記近似提案を提示する模擬近似提案提示手段と、
    ことを特徴とする請求項１記載の分類辞書更新装置。
16. 階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付機能と、
    この更新提案受付機能により受け付けた前記更新提案を随時格納する提案履歴格納機能と、
    前記提案履歴格納機能により格納された過去の前記更新提案を検索することによって、前記更新提案受付機能により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出機能と、
    この近似提案抽出機能により抽出された前記近似提案を提示する近似提案提示機能と、
    をコンピュータに実行させることを特徴とする分類辞書更新プログラム。
17. 階層構造を定義するクラスと、クラス階層構造を定義するプロパティと、クラス及びプロパティの詳細情報フィールドであるアトリビュートとを含み、下位の分類クラスが上位の分類クラスのプロパティを継承する階層構造を持つ階層型分類辞書に対する更新提案を受け付ける更新提案受付工程と、
    この更新提案受付工程により受け付けた前記更新提案を随時格納する提案履歴格納工程と、
    前記提案履歴格納工程により格納された過去の前記更新提案を検索することによって、前記更新提案受付工程により受け付けた前記更新提案と近似する近似提案を抽出する近似提案抽出工程と、
    この近似提案抽出工程により抽出された前記近似提案を提示する近似提案提示工程と、
    を含むことを特徴とする分類辞書更新方法。

Images