JP4192082B2 - 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム - Google Patents

分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム Download PDF

Info

Publication number
JP4192082B2
JP4192082B2 JP2003415361A JP2003415361A JP4192082B2 JP 4192082 B2 JP4192082 B2 JP 4192082B2 JP 2003415361 A JP2003415361 A JP 2003415361A JP 2003415361 A JP2003415361 A JP 2003415361A JP 4192082 B2 JP4192082 B2 JP 4192082B2
Authority
JP
Japan
Prior art keywords
proposal
classification
voting
dictionary
attribute
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.)
Expired - Fee Related
Application number
JP2003415361A
Other languages
English (en)
Other versions
JP2005174116A (ja
Inventor
蘭 王
廣 村山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2003415361A priority Critical patent/JP4192082B2/ja
Publication of JP2005174116A publication Critical patent/JP2005174116A/ja
Application granted granted Critical
Publication of JP4192082B2 publication Critical patent/JP4192082B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明はデジタル・ネットワークを用いて製品分類等の分類辞書を作成、修正、決定等編集する分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラムに関する。
コンピュータの基本ソフトウェアとして、マイクロソフト社のオペレーティング・システム（ＯＳ）のＷｉｎｄｏｗｓ（登録商標）や、その他ＵＮＩＸ（登録商標）、ＬＩＮＵＸ（登録商標）といった汎用ＯＳが用いられている。これらＯＳにおいては、ツリー表示のグラフィック・ユーザ・インタフェース（ＧＵＩ）が採用されている。このＧＵＩは、例えばツリー状のディレクトリ構造やファイル構造をユーザに視覚的に表示し、ユーザを特定のディレクトリやファイルへ誘導・移動（ナビゲート）することができる。
しかしながら、このツリー表示の各ノード間においては、上位のノードに含まれる情報（ファイル等）と下位のノードに含まれる情報の間には属性の継承関係、あるいは包含しない部分集合関係等の関係はない。ルート・ノードから始まるツリー上のノードは、ファイルなどの情報を納めるフォルダを表しているにすぎない。つまり、情報のコンテナが単にツリー状に相互接続されていることを表わしているにすぎない。この種の構造のことを、本明細書では階層型ディレクトリ構造と呼ぶ。この階層型ディレクトリ構造は、階層型データベースとは別の概念である。階層型データベースを管理するシステムをここでは階層型データベース管理システム（ＨＤＢＭＳ）と呼ぶ。
一方、オブジェクト指向データベース（ＯＯＤＢ）やオブジェクト・リレーショナル型データベース（ＯＲＤＢ）を代表とするデータベースでは、下位が上位分類の属性を継承する階層構造を持つ。この階層構造では、継承に従って下位の分類では属性が累増する。このように、上位の属性を下位に継承することを通常「インヘリタンス」と呼ぶ。このような技術はたとえば“Object-Oriented Concepts, Databases, and Applications, Edited by Won Kim, 1989, ACM Press ”他多くの文献に記載されている。
オブジェクト指向データベースの文献においては、階層中の分類は「クラス」と呼ばれることが多い。一方、オブジェクト・リレーショナル型データベース（ＯＲＤＢ）においては、継承を許したテーブルがこのクラスに相当する。上下関係をもつテーブル間において、上位のテーブルから下位のテーブルへ属性、すなわち上位テーブルを構成するコラムのヘッダ情報が下位テーブルへ継承される。本明細書においては、その両者を含めて「階層型データベース」と称す。
デジタル・ネットワーク上（本明細書では以下単に「ネットワーク」と呼ぶ）に分散したコンテンツ情報を収集し、コンテンツの属性構造情報を抽出して、その属性構造について正規化する方法については特願平11−328218号公報（特許文献１）がある。この特許文献１では、ＷＥＢ上に存在するコンテンツ、特にＸＭＬドキュメントについてそれを自動収集したのち整理して、ある形式に正規化する方法を述べている。
又、従来の投票を含むコンテンツの共同編集システムとしては、特開2000-298635公報（特許文献２）がある。この特許文献２は、コンテンツのみについての共同編集と結果の投票による合意形成を目指すものである。
特願平11−328218号公報 特開2000-298635公報
しかしながら、上記特許文献１では、ＷＥＢを使って収集する対象として上位から下位へ属性の継承構造を持ち、それがコンテンツ記述の言わば「型枠」となる、「辞書」を扱うものではなく、また、辞書をネットワークを介した複数の辞書編集者の共同作業により、改訂していく方法について述べたものではない。
また、上記特許文献２では、コンテンツと辞書とを明確に分け、その辞書についての共同編集の方法を扱い、かつその辞書に上位から下位への属性の継承構造を持ち投票による合意を形成するためのシステムを提案しているものではない。
一般に、ネットワーク上に散在する階層構造を持つデータベースで共通に用いられる辞書の編集を行おうと思うと、まずその辞書の内容を紙で記録する。そして、辞書管理者は、登録された投票権を持つ多数の評議員グループにその紙を回す。そして、各評議員からのコメントおよび投票結果を辞書管理者が手動で集計して辞書の改訂を行っていた。あるいは、辞書管理者は、その辞書の内容を登録された投票権を持つ多数の評議員達に電子メールで送信し、コメントおよび投票結果を電子メールで返事してもらって、手動で集計していた。しかしながら、これらの方法は時間が掛かり、現実に起きている辞書に対する頻繁な修正・追加などに対して即時に対応することができない。また、辞書の公開性にも問題があった。すなわち、提案者は、自分が提案した内容に対して、時間の経過に従って変化する提案に対する承認状態を調べるのは困難であった。さらに、コメントや投票結果などを人手により集計する操作は大変困難であった。集計操作にはエラーも起こりやすく、辞書の正確性や公平性を保つには問題があった。また、辞書項目毎に対してバージョン管理及び履歴を管理することも困難であった。
階層型構造を持つデータベースシステムにおいて、その階層構造の仕様をデータ化した「辞書」の仕様案をネットワーク上で収集し、それに対するコメントを集め、審議を行う場合、対象とする辞書の情報構造に合致した改訂のメカニズムとプロセスを用意する必要がある。しかしながら、従来から存在する「提案に対する一般的な電子投票の仕組み」では、階層型データベースに使用する辞書を合理的かつ効率の良く改定していくことが困難である。
例えば、後述の図２に示すように、あるクラスＣ３に存在する属性には、上位クラスから継承されている属性と、そのクラスＣ３で定義された属性、他の分類体系のクラスから輸入された属性等が存在する。しかしながら、上位クラスから継承されている属性や、他の分類体系のクラスから輸入された属性等に対する変更をクラスＣ３で行うと、その変更が他のクラスへ及ぶ。したがって、その変更された属性を継承している全てのクラスについて逐一、変更の妥当性を検証し、変更の結果を波及させる必要があり、非効率的である。そのような場合は、定義されているクラスにおいてのみ変更を可能にし、継承しているクラスや輸入しているクラスでは変更を禁止するのが望ましい。
このように、従来の分類辞書の構築手法では、高い公開性で正確に構築する手法は存在しなかった。
本発明は上記課題を解決するためになされたもので、その目的とするところは、データベースの分類辞書を高い公開性で正確に構築する分類辞書構築サーバ及び分類辞書構築システムを提供することにある。
本発明のある観点によれば、分類項目及び属性により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築サーバであって、前記分類辞書の編集内容を分類項目又は属性で指定した提案の整合性を判定する提案整合化手段と、前記整合性の判定結果が整合性ありの場合に、投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行する投票管理手段と、閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信する閲覧管理手段と、可決条件を満たす前記提案に基づき前記分類辞書を更新する更新手段とを具備してなることを特徴とする分類辞書構築サーバが提供される。
また、本発明の別の観点によれば、分類項目及び属性により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築方法であって、前記分類辞書を編集するための提案の対象となった分類項目又は属性の定義の整合性を判定し、前記整合性の判定結果が整合性ありの場合に、投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行し、閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信し、可決条件を満たす前記提案に基づき前記分類辞書を更新することを特徴とする分類辞書構築方法が提供される。
また、本発明の別の観点によれば、分類項目及び属性により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築プログラムであって、この分類辞書構築プログラムはコンピュータに、前記分類辞書を編集するための提案の対象となった分類項目又は属性の定義の整合性を判定する処理と、前記整合性の判定結果が整合性ありの場合に、投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行する処理と、閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信する処理と、可決条件を満たす前記提案に基づき前記分類辞書を更新する処理とを実行させることを特徴とする分類辞書構築プログラムが提供される。
本発明によれば、データベースのスキーマとして用いられる分類辞書を高い公開性で正確に構築することができる。
以下、本発明の実施の形態を図面に基づいて説明する。
（第１実施形態）
図１は本実施形態に係る分類辞書構築システム１０００の基本構成を示す図である。また、図２は分類辞書構築システム１０００による操作対象である階層型データベースの構成の一例を示す図である。この図２に示す階層型データベースは、複数の階層に分かれている。そして、各階層は、１又は２以上の分類項目を有する。下位が上位属性を継承する性質を持つ。したがって、下位の階層の分類項目の属性は、上位の階層の分類項目の属性を継承する。ここで、階層型の分類項目はクラスと呼ばれる。各クラスは属性を持つ。図２は多重継承を含む一般的なクラス間の属性継承関係を示している。クラスはＡ０、Ｂ０、Ｂ１、Ｃ０、Ｃ１、Ｃ２、Ｃ３、Ｄ１で示され、属性はＰ０〜Ｐ７で示される。クラスＣ３においては、その親クラスＢ１から属性Ｐ０とＰ４を継承し、別の親クラスＤ１から属性Ｐ７を継承する。属性Ｐ６はクラスＣ３において独自に定義された属性である。クラスＡ０とクラスＤ１は独立したクラスである。ユニバーサルルート（Universal Root）は、全てのルートクラスを仮想的に含む全体クラスである。これは通常数学で言う「全体集合」に相当するものと考えられる。すなわち、全体クラスでは、継承すべき属性を特に含んでおらず、属性を持たないため、全てのルートクラスの親クラスとして扱うことが可能になる。
ＰＬＩＢ規格（ISO13584 Parts Library）の場合は、製品分類やその属性に用いる階層構造は単純木構造である。したがって、上位クラス（親クラス）は１つしか存在しない。親クラス以外の属性を継承する場合には、後述するCaseOf（「ケースオブ」）という属性の輸入（引用）のための特別な構造が用いられる。この構造は、図２の多重継承を、例えば番号の一番若い親クラスを主系列とするなどにより主系列と副系列に適宜分け、副系列に対してCaseOfという別名を与えた例とみなすことができる。また、ＯＲＤＢや一般的なオブジェクト指向データベースにおいては、全てのテーブルやクラスに親テーブル及び親クラスがあるわけではない。しかし独立に存在するテーブルやクラスについても、図２に示すように、仮想的な「ユニバーサルルート」を設定することにより、全てのクラスをただ一つのルートから全てのテーブルやクラスたどることが可能となり、単純木と変らなくなる。
図３は、単純木を用いたデータベースの構成の一例を示す図である。このデータベースはユニバーサルルートを持たない。この図３を用いて本実施形態を説明しても、一般性を損なうことはない。図３において、Ａ０、Ｂ０、Ｂ１、Ｃ０、Ｃ１、Ｃ２の木構造の部分は、分類階層を含む情報を表現する。本実施形態では木は単純木であり、クラスには一つの上位クラスしかない。
図２において、クラスＡ０は下位クラスＢ０とＢ１を持つ。クラスＢ０は、下位クラスＣ０及びＣ１を持ち、クラスＢ１は下位クラスＣ２およびＣ３を持つ。それぞれの製品クラスは属性項目を持ち、上位クラスの属性は下位クラスに継承される。図２中コンテンツ１１，１２，１３及び１４は実際の製品データである。例えば、コンテンツ１１は、Ｃ０という種類の製品データである。このコンテンツ１１は、３種類分のコンテンツデータである。すなわち、コンテンツ１１は、属性項目Ｐ０の属性値としてｘ１，ｘ２と、属性項目Ｐ１の属性値としてｙ１，ｙ２と、属性項目Ｐ２の属性値としてｚ１，ｚ２とを持つ。階層型データベース構造は分類辞書と呼ばれており、本実施形態の処理対象として図１の辞書ＤＢ１０３に格納されるが、実際のコンテンツデータであるコンテンツ１１〜１４に対する操作は本発明の対象外である。なお、図３のコンテンツ２１〜２４は、図２のコンテンツ１１〜１４と同様の性質を持つ。
辞書のクラスと属性はモデリングにより表される。したがって、クラスおよび属性エンティティ（オブジェクト）にそのアトリビュートが定義されている。ここで、「アトリビュート」とは、クラスや属性に詳細情報を規定するための情報フィールドである。クラスに所属する「属性」との混同を避けるために、クラスや属性の詳細情報フィールドを「アトリビュート」と呼んで本明細書の記述では区別する。クラスには、クラスタイプ、クラス名、親クラス、標準名称などのアトリビュートが定義されている。属性エンティティには、属性タイプ、定義クラス、データ型、標準名称などのアトリビュートが定義されている。各クラス及び属性はそれぞれ定義されたアドリビュートを持ち、モデリングされる。
図４はＷＥＢブラウザ１４２を利用してクラス及びアトリビュートを閲覧した表示画面例である。図３に示す辞書構造において、フレーム２６は、その辞書クラスをツリー構造で提示した階層型分類体系図である。フレーム２６で選択されたクラスにおいて、処理フレーム２８で、属性あるいはクラスのどちら一つをユーザが選択する。フレーム２７はフレーム２６かつ処理フレーム２８で選択された内容の詳細内容を提示する図である。例えば、フレーム２６ではクラスＣ０が選択され、処理フレーム２８でクラスが選択された場合、ＷＥＢブラウザ１４２は、フレーム２７に、選択されたクラスＣ０のアトリビュート内容を表として表示する。この後、フレーム２６の辞書ツリーで異なるクラスが新たに選択されると、ＷＥＢブラウザ１４２は、選択前のクラスのアトリビュート内容に代えて、新たに選択されたクラスのアトリビュート内容を表として表示する。例えば、クラスＣ１が選択された場合、ＷＥＢブラウザ１４２はフレーム２７にクラスＣ１のクラスアトリビュート内容をクラスＣ０のクラスアトリビュート内容に代えて表示するようになる。さらに、ＷＥＢブラウザ１４２はフレーム２６の処理でクラスＣ０を選択し、処理フレーム２８では属性が選択された場合に、図５に示すように、クラスＣ０の属性アトリビュートおよび属性リストをフレーム３１のように表示できる。また、この後、フレーム３０で、ユーザによりクラスツリーで異なるクラスが選択されると、ＷＥＢブラウザ１４２はフレーム３１に選択されたクラスの属性を表示する。符号３２は属性が選択された場合の処理フレームの例である。
本実施形態における辞書に対する編集・追加操作は、クラス及び属性のアトリビュート内容に対する操作である。
次に、図１を用いて分類辞書構築システム１０００の詳細を説明する。
分類辞書構築システム１０００は、大別して分類辞書構築サーバ１と、ネットワーク１４０と、複数の端末１４１ａ〜１４１ｎからなる（以下では単に端末１４１と称する）。分類辞書構築サーバ１及び端末１４１ａ〜１４１ｎはネットワーク１４０に接続されている。
分類辞書構築サーバ１は、辞書データベース（ＤＢ）１０３と、表示用データ読み込み部１０４と、データ表示部１０５と、辞書データ編集部１０６と、提案データ整合化・評価部１０７と、提案データコメント・投票部１０８と、投票結果集計部１０９と、提案ステータス決定部１１０と、提案データ書き込み部１１１と、提案データベース（ＤＢ）１１２と、辞書更新部１１３と、辞書改訂ルールデータベース（ＤＢ）１１４と、ネットワーク通信部１２０と、ユーザ管理部１３０と、ユーザデータベース（ＤＢ）１３１から構成されている。
端末１４１ａ〜１４１ｎは、辞書ＷＥＢブラウザ１４２ａ〜１４２ｎ（以下、単にＷＥＢブラウザ１４２と称する）と、表示装置１４３ａ〜１４３ｎ（以下、単に表示装置１４３と称する）と、入力装置１４４ａ〜１４４ｎ（以下、単に入力装置１４４と称する）を備える。
表示用データ読み込み部１０４が辞書ＤＢ１０３から辞書データを読み込む。この辞書データに基づきデータ表示部１０５が表示データを生成して端末１４１に送信する。表示データは、使用目的に応じて生成される。例えば、辞書データ編集部１０６における処理のための表示データとしては、編集表示データが生成される。提案データ整合化・評価部１０７における処理のための表示データとしては、整合化・評価表示データが生成される。
端末１４１側では、辞書ＷＥＢブラウザ１４２が分類辞書構築サーバ１からの表示データを表示装置１４３に表示する。図６はクラス及びそのアトリビュートの表示画面例である。この図６の画面例は、ＷＥＢブラウザ１４２からネットワーク通信部１２０を介して分類辞書構築サーバ１にアクセスすることにより端末１４１側で受信され表示された画面である。
提案者、評議員などのユーザは端末１４１からネットワーク１４０を介して分類辞書構築サーバ１にアクセスし、ユーザ管理部１３０でユーザの管理を受け、権限を付与される。評議員なら投票権を持つグループにも登録される。付与された権限またはグループによって、各ユーザは辞書に対してその権限またはグループに相当な操作を行うことがユーザ管理部１３０により許可される。
まず、辞書編集動作について説明する。
辞書データ編集部１０６は辞書に対する編集を行う。図７は辞書データ編集部１０６の編集処理のフローチャート示す図である。まず、ステップＳ１では、登録された権限を持つユーザが端末１４１の辞書ＷＥＢブラウザ１４２を用いて辞書をレビューする。この辞書編集では、まず辞書ＷＥＢブラウザ１４２はネットワーク１４０を介して辞書の閲覧要求を分類辞書構築サーバ１に送信する。分類辞書構築サーバ１のユーザ管理部１３０は、ネットワーク通信部１２０を介して受信したこの辞書の閲覧要求に基づき、ユーザＤＢ１３１を参照して権限の有無を判定する。権限がある場合には、表示用データ読み込み部１０４に辞書ＤＢ１０３を読み込ませて辞書データを読み出し、データ表示部１０５で表示データを生成し、ユーザ管理部１３０を介して端末１４１に送信する。端末１４１の辞書ＷＥＢブラウザ１４２は、受信した辞書データを表示装置１４３に表示する。端末１４１側では、ステップＳ２で、クラスあるいは属性をいずれか一つ入力装置１４４を用いて選択する。
このステップＳ２でクラスを選択した場合は、ユーザはさらにステップＳ７で操作の種類を選択する。新しいクラスを追加するクラス追加操作ステップＳ９と、現在クラスの項目を修正するクラス修正操作ステップＳ８と、テクニカルノートを記述するテクニカルノード記述ステップＳ１０のうち、いずれか１つを入力装置１４４を用いて選択する。
ステップＳ２で属性を選択した場合、ステップＳ３で操作種類を選択する。属性を追加する属性追加操作ステップＳ６と、属性を修正する属性修正操作ステップＳ５と、テクニカルノートを記述するテクニカルノート記述ステップＳ４のうち、いずれか１つを入力装置１４４を用いて選択する。
これらクラス及び属性の修正・追加・テクニカルノート記述の別を示す入力データは、ステップＳ１１でＷＥＢブラウザ１４２により端末１４１の表示装置１４３に表示される。ユーザは、ステップＳ１２で自分が入力した内容を表示画面で確認する。ステップＳ１２で、入力されたデータを確認すると、入力したデータが端末１４１から分類辞書構築サーバ１に送信される。分類辞書構築サーバ１では、入力データは、提案データとして提案ＤＢ１１２に提案データ書き込み部１１１により登録される（ステップＳ１３）。同時に、提案ステータス決定部１１０により提案内容に初期ステータスが付与される。ステータスは、提案が現時点で属する状態、あるいは投票されている段階などの進捗状況を表す。一方、ステップＳ１２の処理では入力した内容を廃棄する旨を端末１４１が要求すると、分類辞書構築サーバ１の辞書データ編集部１０６は、システムを終了するか、あるいは入力内容の入れ直しのため、辞書レビューのステップＳ１の状態に戻る。ステップＳ１３で、提案ＤＢ１１２に提案が書き込まれると、表示用データ読み込み部１０４は提案ＤＢ１１２に書き込まれた内容に基づき、提案の整合化と評価を要求するための整合化・評価要求電子メールを辞書管理者の端末１４１に自動で送信する（ステップＳ１４）。送信されたメールは端末１４１側でＷＥＢブラウザ１４２を用いて表示装置１４３に表示される。以下、他のメールを受信した場合も同様である。
次に、提案の整合化及び評価について説明する。
整合化・評価要求電子メールの通知を受信した辞書管理者は、端末１４１を用いて提案の整合化及び評価を行う。図８は整合化及び評価のフローチャートを示す図である。
辞書管理者は、辞書ＷＥＢブラウザ１４２で提案の一覧表を閲覧する。すなわち、辞書ＷＥＢブラウザ１４２は、分類辞書構築サーバ１から表示用データ読み込み部１０４及びデータ表示部１０５を介して提案の一覧表を受信して表示装置１４３に表示する。端末１４１と分類辞書構築サーバ１との間の情報のやりとりは、端末１４１側への情報の提供は表示用データ読み込み部１０４及びデータ表示部１０５の動作によるもので、辞書編集の場合と同様であり、さらには後述の提案データコメント・投票処理でも同様である。
そして、提案データ整合化・評価部１０７は、自動で提案毎にステップＳ１０２で提案内容の整合化チェックを行う。具体的には、提案内容が項目毎に決められた形式、単位などに違反しているか否かを判定する。例えば、クラスのcodeの英文及び数字は必ず半角であること、使う単位は必ずＳＩ単位（SI units:International System of Units）であることなどである。問題ない提案、すなわち整合性を有する提案に対して、次のステップＳ１０３に進み、辞書管理者は端末１４１側で表示された表示画面を参照して提案内容を評価する。例えば、提案内容は既に辞書に存在していると辞書管理者が判断した場合に、辞書管理者は、入力装置１４４を用いて廃棄要求を選択する。この廃棄要求はネットワーク１４０を介して分類辞書構築サーバ１に送信される。提案データ整合化・評価部１０７は、受信した破棄要求に基づきステップＳ１０４で該提案を廃棄処理する。
一方、許可を取れた提案に対しては、ステップＳ１０５では、辞書管理者の端末１４１からは、整合性有りで、評価に問題無しであることを示す判定結果が分類辞書構築サーバ１に送信される。分類辞書構築サーバ１の提案データ整合化・評価部１０７は、受信した判定結果が整合性有りで、評価に問題無しである旨のデータを端末１４１から受信した場合に、提案ステータス決定部１１０に提案ＤＢ１２のステータスを更新させて、提案が投票できるように設定する。次のステップＳ１０６で、提案データ書き込み部１１１により提案が提案ＤＢ１１２で更新される。提案データコメント・投票部１０８は、提案が発生し投票状態にあることを示す提案発生電子メールを生成する。生成された提案発生電子メールは、ユーザ管理部１３０により予めユーザＤＢ１３１に登録された評議員グループ１の端末１４１を選択し、選択した端末１４１に自動送信される。以上によりデータ整合化及び評価の処理が終了する。
次に、コメント、投票及び他の操作について説明する。
図９は、提案発生電子メールを受信した評議員グループ１（図１１に示すものと同様）が提案に対して行うコメント、投票及び他の操作のフローチャートを示す図である。
提案発生電子メールの通知を受けた投票権のある評議員グループ１に属するユーザは、端末１４１を用いて制限時間内の提案内容をレビューできる。具体的には、端末１４１から閲覧要求が分類辞書構築サーバ１に対して送信される。ユーザ管理部１３０は、受信した閲覧要求に基づき要求元の端末利用者が閲覧権限を持つか否かをユーザＤＢ１３１を読み出し判定する。閲覧権限を持っていると判定された場合、提示用データ読み込み部１０４により読み出された表示用データに基づきデータ表示部１０５で生成された表示データが端末１４１に送信される。
なお、閲覧の制限時間は、提案データコメント・投票部１０８が予め設定した提案の投票有効時間である。提案の投票の有効期間は、投票可能になった時刻から投票制限時間（すなわち、投票有効時間）（例えば１４日間）までである。
ステップＳ３０２に示すように、提案全体またはその一部の項目に対して投票権を持つユーザはコメントすることができ、さらに、提案に対して賛成・反対・棄権の投票が行える。コメント及び投票内容は、端末１４１から分類辞書構築サーバ１に送信され、提案データコメント・投票部１０８で処理される。提案に投票するかの判断（ステップＳ３０３）において、投票を希望する場合には投票がなされ（ステップＳ３０４）、投票しない場合には投票はなされず制限時間が経過する（ステップＳ３０１）。
評議員グループに所属しているユーザは、ひとつの提案に対して一人あたり一回しか投票をすることができない。一旦ステップＳ３０５で提案の制限時間になるとステップＳ３０６に進む。ステップＳ３０６では、提案データコメント・投票部１０８は各端末１４１から受信した投票内容に基づき自動的に投票結果を集計する。ステップＳ３０７で、その集計結果の賛成数は可決条件に満たした場合、ステップＳ３０８へ進み、提案データコメント・投票部１０８は最終審議段階であるか否かをチェックする。可決条件は、例えば参加者は評議員グループ１の８０％、賛成数は参加者の５０％などに設定される。最終段階ではない場合には、提案ステータス決定部１１０は自動的に提案のステータスを更新する。これにより、提案が次の投票段階に進む。そして、提案データコメント・投票部１０８は、提案が発生した旨を設定された評議員グループに提案発生電子メールで通知し、ステップＳ３０１〜Ｓ３０７と同様なコメント及び投票操作を繰り返し行う。すなわち、予めユーザＤＢ１３１に複数のメンバーからなる評議員グループを複数登録しておく。そして、提案データコメント・投票部１０８は、ある提案に対して、その提案で指定されたクラス及び／又は属性と、評議員グループについて登録されている投票クラス及び／又は得票属性と比較し、投票権を持つ評議員グループを複数抽出する。このように、ある提案に対して複数の評議員グループが投票権を持つとして抽出される場合、各評議員グループについて上記投票処理が繰り返しなされる。
上記ステップＳ３０８の判断が最終段階である場合、ステップＳ３１１に進む。最終段階であるか否かは、例えば最終決済者である評議員グループについて可決条件を満たす場合や、最終決済者は存在しないが、提案に対して投票権を有するすべての評議員グループについて可決条件を満たす場合などが該当する。したがって、提案データコメント・投票部１０８が最終段階に進んだか否かを自動で判定することができる。
ステップＳ３１１では、提案データコメント・投票部１０８は提案を辞書へ更新できるように設定する。この設定の後、提案データ書き込み部１１１により提案内容が図１の提案ＤＢ１１２に登録される。さらに、設定された辞書ＤＢ１０３への更新時間になると、図１の辞書更新部１１３は提案ＤＢ１１２に登録された提案内容に基づき辞書ＤＢ１０３の更新を行う。ステップＳ３１３では、提案ステータス決定部１１０は、ステップＳ３１１での提案により辞書ＤＢ１０３が更新されたことを示す辞書更新電子メールを全ての関係者の端末１４１に通知する。
一方、ステップＳ３０７において、集計結果が可決条件を満たさなかった場合、ステップＳ３０９の処理で提案が廃棄され、設定されたユーザの端末１４１に提案廃棄電子メールで通知する。
図１０は本実施形態における提案ＤＢ１１２に登録される提案データの構造例を示す図である。提案データは、提案者から入力した内容と、ステータスによって分けた審議段階１から審議段階Ｎにおける各段階の評議員のコメント情報および投票情報から構成される。提案者から入力した内容は、提案内容そのものを指し、分類辞書に対する改訂をクラス及び属性で指定し、あるいはクラス又は属性のいずれかで指定したデータである。
このように、ネットワーク１４０を利用して、下位が上位分類属性を継承する階層型辞書の修正・追加・テクニカル記述などの編集を行うことができる。また、その編集された内容に対して、ネットワーク１４０を介して、登録された投票権を持つ不特定多数の評議員が端末１４１を用いてコメント及び電子投票を行う。予め設定された投票制限時間になると、分類辞書構築サーバ１は自動的に投票結果を集計し、最終的に辞書を決定する。
これにより、ネットワークを利用した辞書の分類体系構築が可能となる。この方法により、辞書に対する頻繁な修正・追加操作が簡単に即時に出来て、コメント・投票結果も自動的に行えるようになる。
また、複数段階に渡って異なるグループに投票を繰り返せるようにしている。このように、投票管理及び投票結果の集計を自動化することにより、次の段階へ進むか否かを自動に判定でき、辞書改訂の即時性、正確性及び公平性を保つことをできる。すなわち、辞書に対する評議員の多段階の投票の処理が自動的に行える。
（第２実施形態）
本実施形態は、第１実施形態の構成に別の機能を追加した実施形態に関わる。したがって、特に言及のない限りは第１実施形態と構成が共通し、共通する部分の説明は省略する。
図１１及び図１２は本実施形態を説明するための図である。
本実施形態では、下位が上位属性を継承する階層型データベースの辞書に対して、評議員グループは自分の分野に応じて、その分類体系上のクラスに対してユーザＤＢ１３１に登録する。登録したクラスおよび下位クラスを、その評議員グループの閲覧スコープ、あるいは投票スコープと称する。評議員は、登録された投票スコープにあるクラス及び属性に対して、提案があった場合にコメントおよび投票を行う。図１１に示すように、評議員グループ１はクラス１に対して登録する。登録された投票スコープは３０１である。
投票スコープ３０１にあるクラス１あるいは、クラス１で定義した属性１１に対して改訂の提案等があった場合に、評議員グループ１にその提案等を知らせる電子メールが通知される。電子メールを受信した評議員グループ１は、その提案等に対して設定された操作、すなわち投票やコメントなどを端末１４１を用いて行う。
一方、クラス１に対して上位クラスである「ＲＯＯＴ」から継承した属性１、または輸入属性に変更があった場合には、評議員グループ１は投票およびコメントが出来ないため、電子メールにより提案の発生等を知らされる必要がない。
評議員グループ２はクラス２に対して登録しており、投票スコープは３０２である。投票スコープ３０２にあるクラス２と、クラス２に属する全ての属性１，２１及びそのサブクラスであるクラス２１と、クラス２１に属する全ての属性１，２１，２１に対して編集があった場合に、評議員グループ２に電子メールで通知される。電子メールを受信した評議員グループ２は、その提案等に対して予め設定された操作を端末１４１を用いて行う。
評議員グループ３は「ＲＯＯＴ」に対して登録しており、辞書中の全てのクラス及び属性が投票スコープである。
投票スコープの登録は、例えば次のように行われる。まず、ユーザ管理部１３０は、表示用データ読み込み部１０４で読み込まれた提案ＤＢ１１２を用いて端末１４１の表示装置１４３に図１１に示すような階層型データベースの辞書の分類体系をツリー図等で表示する。ユーザは、表示装置１４３を見ながらクラスを入力装置１４４を用いて選択する。選択されたクラスは、ネットワーク１４０を介してユーザ管理部１３０に送信される。ユーザ管理部１３０は、受信した選択クラス（投票クラス）と、さらにその選択されたクラスの属性を継承し下位に位置するクラスと、これら選択クラスと下位クラスの属性をスコープ、すなわち投票範囲としてユーザＤＢ１３１にユーザに関連づけて登録する。投票権を与えるための登録であれば投票スコープ、すなわち投票可能な範囲として、閲覧権を与えるための登録であれば閲覧スコープ、すなわち閲覧可能な範囲として登録する。なお、投票クラスや閲覧クラスのみを登録しておき、投票や閲覧の要求が端末１４１からある都度投票スコープや閲覧スコープを解析して設定してもよい。
図１２は、提案があった場合に通知する必要な評議員グループを探す操作のユーザ管理部１３０の処理のフローチャートである。
ユーザ管理部１３０は、提案者の端末１４１から提案を受信すると（Ｓ３００１）、クラス提案か属性提案かを判定する（Ｓ３００２）。クラス提案とは、クラスの修正・追加・テクニカルノートの記述に関する提案であり、属性提案とは、属性の修正・追加・テクニカルノートの記述に関する提案である。クラス提案である場合は、提案データ中の”classcode”項目にあるクラスのコード（code）を抽出する（ステップＳ３００３）。属性提案であれば、提案の“definition class”（定義クラス）項目にあるクラスのコード情報（code）を抽出する（ステップＳ３００４）。
ユーザ管理部１３０は、取得したクラスのcode情報を例えばユーザＤＢ１３１に保存する（ステップＳ３００５）。次に、ユーザ管理部１３０は、Ｓ３００５で保存されたクラスの上位クラスがあるかどうかを探す（Ｓ３００６）。上位クラスがある場合には、ユーザ管理部１３０は、上位クラスコード（code）を取得し（Ｓ３００７）、ステップＳ３００５に戻りコードを保存する。このステップＳ３００５〜Ｓ３００７の処理は繰り返し行われる。ステップＳ３００６で、上位クラスが他に存在しない場合、既に保存したクラスのコード（code）を利用して、保存したクラスに対して登録した評議員グループ情報を取得する（Ｓ３００８）。
例えば、ステップＳ３００５で保存されたクラスはcls1であって、そのcls1の上位クラスはcls2、cls2の上位クラスはcls3である場合、ステップＳ３００８における処理は、
select 評議員グループ from 評議員グループテーブル where 評議員グループ登録クラス=cls1 or cls2 or cls3
である。
上記ステップＳ３００８で取得した評議員グループの端末１４１に対して、提案の発生を提案発生電子メールにより通知する（Ｓ３００９）。
このように、多数の評議員を、階層構造を持つ辞書のクラスに従って、編集する辞書のクラス構造に結びつけて、階層クラス化された専門分野に分けて登録し、その評議員に対して当該専門分野についての提案の発生等を知らせ投票させ、あるいはその分野以外の提案の発生等は知らせない。これにより、評議員による辞書提案に対する審査やコメントの正確性、正当性が向上する。
また、評議員がその専門分野に応じて正確なコメントを行えるようになり、さらには評議員の専門分野外の提案に対して時間を割くことがなくなるため、効率よく辞書提案に対するコメントや投票を行うことが可能になる。
（第３実施形態）
本実施形態は第１及び第２実施形態に別の機能を追加した実施形態に関わる。したがって、特に言及のない限りは第１及び第２実施形態と構成が共通し、共通する部分の説明は省略する。
図１３は本実施形態を説明するための図である。
本実施形態では、辞書のユーザや辞書の変更に関心を持つ人々の集団（以下「ＳＩＧ」:Special Interest Groupと呼ぶ）が辞書の変更に関する通知を、自己の専門領域の内部か否かで区別して受信する形態に係る。本実施形態では、自分の専門領域の上位クラスで起こった変更と下位クラス、つまり専門領域内で起こったクラスを区別して受けるために、自己の関心のある範囲を登録する。自己の関心のある範囲は、個々のＳＩＧの属する人の専門性において最も汎概念的なクラスＣｓｉｇ（つまり上位のクラス、図中ではクラスＣ４）を１つまたは複数指定することで設定される。
ここで、図１３では、個々のＳＩＧの属する人の専門性として、クラスＣ７、Ｃ８に対して専門知識を持つ場合を示している。また、最も汎概念的なクラスＣｓｉｇは、これらクラスＣ７及びＣ８の上位クラスＣ４で示される。クラスの登録手法は第２実施形態と共通するので詳細な説明は省略する。
ケース１は、例えば、クラスＣ１において実際に提案者より提案が行われた場合、もしくは、提案が採用されて辞書の改訂が決定した場合である。このケース１の場合には、その提案あるいは決定をユーザ管理部１３０が解析することにより対象クラス（提案指定クラス）を特定し、この提案指定クラス、あるいはこの提案指定クラスより下位のクラス（すなわちＣ１のサブクラス）に付随するＳＩＧに登録された全てのメンバーに辞書の改訂がされた旨を電子メールで通知する。従って、クラスＣ４に付随するＳＩＧ４にはこの通知がなされる。より具体的には、最も汎概念的なクラスＣｓｉｇであるクラスＣ４と、このクラスＣ４の上位クラスである「ＲＯＯＴ」、クラスＣ１、Ｃ２にかかわる提案や決定の場合に通知される。
ケース２は、自分の登録したクラスより下位のクラスにおいて提案者より実際の提案が行われた場合、もしくは、提案が採用されて辞書の改訂が決定した場合である。このケース２の場合には、そのクラスより上位の全てのクラスに付随するＳＩＧにその旨を、前述の通知とは区別して報告する。一例として、クラスＣ７で辞書の変更が行われた場合には、クラスＣ７の上位クラスであるＳＩＧ４のメンバーにも、ケース１とは別種の電子メールによる通知が成される。より具体的には、最も汎概念的なクラスＣｓｉｇであるクラスＣ４と、このクラスＣ４の下位クラスであるクラスＣ７、Ｃ８にかかわる提案や決定の場合に通知される。
このように本実施形態は、多数の辞書のユーザおよび辞書の改訂に関心や利害をもつ人々、すなわち辞書ＳＩＧのユーザを、階層構造を持つ辞書のクラスに従って（階層クラス化された）専門分野に分けて登録することにより、各ユーザの辞書上の関心の範囲に応じて、辞書の改訂に関する通知や情報を受信する。このようなＳＩＧユーザとは例えば辞書を用いてある分野のコンテンツを作成しているユーザである。例えば、３つのクラス、ノートＰＣ、デスクトップＰＣ、ワークステーションが存在し、その共通の親クラスとして計算機クラスが存在するとする。ノートＰＣ、デスクトップＰＣ、ワークステーションにいずれも関心や利害を持つ専門家であれば、投票権を持つか持たないかに関わらず、関心を持つ分野あるいは専門分野としての最上位概念である計算機クラスにおいて、それに付随するＳＩＧに自分自身を登録すると考えられる。従ってあるＳＩＧの付随するクラスに対して、その下位クラスの一つで起こった改訂はそれより上位のクラスに付随するＳＩＧに通知しなければならない。これは、上記ケース１の場合に対応する。
一方、計算機クラスには、その上位クラスから継承して来た属性が存在し、上位クラスに付随する属性の仕様は専門分野の範囲には入らないが、上位クラスの属性の改訂は、その下位クラスのＳＩＧに属する人々の辞書の使用に影響を与える。これは、上記ケース２の場合に対応する。従って、このケース１とケース２に相当する改訂を区別してＳＩＧに通知する必要がある。従来は、上記のように編集する辞書のクラス構造に結びつけて、ユーザの関心のスコープを決定する方法は知られていなかったが、この実施形態により、上記ケース１とケース２の場合を区別して通知することが可能となる。
（第４実施形態）
本実施形態は第１乃至第３実施形態の変形例に関わる。本実施形態は、第１乃至第３実施形態に示した構成を用いてＰＬＩＢ規格（ISO13584 Parts Library）に完全に準拠し、あるいは部分的に準拠した辞書ＤＢ１０３を構築する実施形態に関わる。したがって、特に言及のない限りは第１乃至第３実施形態と構成が共通し、共通する部分の説明は省略する。
図１に示すように、本実施形態では、辞書データ読み込み部１０１が入力データとして初期辞書データ２０１を読み込み辞書ＤＢ１０３に格納する。初期辞書データ２０１は、例えばＣＳＶ、ＥＸＣＥＬ（登録商標）、ISO13584 Part21などの形式である。辞書ＤＢ１０３はクラスと属性により構成され、図２に示すような辞書データ構造を有する。
ＪＩＥＴＡ辞書（日本電子情報産業協会， http://www.e-parts.org）はＩＳＯ １３５８４規格に部分的に準拠した辞書の例であって、ＪＥＭＩＭＡ辞書（日本電気計測器工業会，http://www.toplib.com/en/TrialVersion.html），ＪＥＭＡ辞書（日本電機工業会,http://www.jemarche.com/），ＩＳＯ １３５８４ Ｐ５１１辞書なども完全に、または部分的にＩＳＯ １３５８４規格に準拠している辞書の例である。
次に図１４及び図１５においてＰＬＩＢに従った辞書改定ルールについて説明する。
ＰＬＩＢ規格により、辞書に関する制約と辞書改定ルールに準拠しなければならない。例えば、クラスおよび属性のアトリビュート項目はＰＬＩＢで決められており、アトリビュートの形式、内容などについても制約されてある。例えば、図１４に示すように、クラスに対して、Code, Date of Original Definition等のアトリビュートを変更する操作は、CodeおよびDate of Original Definitionに対してそれぞれ表中で、−、X、X と記されていることから不可能であることが分かり、全く新しいクラスを追加する時しかできないが、ＰＬＩＢ規格より他の修正可能なアトリビュート、例えばPreferred name, short nameなどに対しては、アトリビュートの内容を修正することが可能である。また、属性に対して、ＰＬＩＢにより、code, Definition class, Unitなどのアトリビュートでは新しい追加操作しかできないが、ＰＬＩＢ規格より他の修正可能なアトリビュート、例えば Data type, Definitionなどのアトリビュートに対して、内容の修正操作が可能である。さらに、アトリビュートの内容形式、内容選択子などが決められている。例えば、辞書のクラスタイプは、ＰＬＩＢ規格に決められたタイプ：component_class, item_class，material_class, feature class, item_class_case_of, component_class_case_of, material_class_case_of 及びfeature_class_case_of の中から一つ選ばなければならない。全ての辞書データがＰＬＩＢ規格に準拠したフォーマットで処理される。このようなＰＬＩＢ規格に決められている改訂ルールを図１の辞書改訂ルールＤＢ１１４に示すようにデータベース化して備えておく。これにより、辞書データ編集部１０６と提案データ整合化・評価部１０７より参照し、辞書の編集や提案のＰＬＩＢとの整合化や評価においてＰＬＩＢに合致して提案や辞書の改訂が行われるように誘導することが可能となる。このような改訂のルールについては、例えば、図１４及び図１５に示す、ＰＬＩＢ規格の第４２分冊（ISO13584-42）に掲載され
ているクラスと属性の改訂の可否ルール・テーブルがある。
更新された辞書ＤＢ１０３は、ＰＬＩＢ規格に基準して構築されている。この辞書ＤＢ１０３は辞書データ書き出し部１０２により、他の辞書およびシステムで利用できるように、ＩＳＯ １３５８４ Ｐａｒｔ２１の形式が、ＣＳＶ，ＥＸＣＥＬ（登録商標）などの形式で、辞書データを設定された形式で更新後辞書データ２０２として書き出すことができる。
例えば、辞書データ編集部１０６における編集処理で、辞書改訂ルールＤＢ１１４の辞書改訂ルールを読み出し編集内容と比較し、編集内容が辞書改訂ルールに従わない場合にはエラー表示をする。あるいは、提案データ整合化・評価部１０７は、図８に示す提案データ整合化における整合化チェック（ステップＳ１０２）などにおいて、提案内容が辞書改訂ルールに従っているか否かをチェックし、提案内容が辞書改訂ルールに従わない場合にはエラー表示をする等の処理を付加することもできる。
このように本実施形態によれば、ＰＬＩＢ規格に部分的に、または完全に基準した、下位が上位分類の属性を継承する階層型データベースの辞書に対して、ＰＬＩＢ規格の定めるところに従って、ネットワークを介した辞書の改定・提案・審査が可能になる。
（第５実施形態）
本実施形態は第１乃至第４実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、提案等のあったクラスや属性を他のクラスや属性と視覚的に区別して表示する実施形態に関わる。したがって、特に言及のない限りは第１乃至第４実施形態と構成が共通し、共通する部分の説明は省略する。
図１６は本実施形態を説明するための図である。
辞書はツリー構造を利用して端末１４１の表示装置１４３上でＷＥＢブラウザ１４２により表示される。ＷＥＢブラウザ１４２は、修正、追加、あるいはテクニカルノート記述の操作（以下、編集と略称する）があったクラスおよび属性に対して、編集がないクラスと属性とを区別して表示する。例えば、両者を違う色で表示する。分類辞書構築サーバ１の表示用データ読み込み部１０４は、提案の対象となったクラス及び属性と、対象とならなかったクラス及び属性とに別個の識別子を関連づけて表示用データを生成する。この表示用データは、ネットワーク１４０を介して端末１４１に送信される。端末１４１のＷＥＢブラウザ１４２は、受信した表示用データの識別子を参照し、対象となったクラス又は属性と、対象とならなかったクラス又は属性とを視覚的に区別できるよう表示する。
例えば、図１６に示すように、ＷＥＢブラウザ１４２は、編集があったクラスS3_001は薄青色で表示するが、編集がなかったクラスS3_002などは黄色で表示装置１４３に表示する。同様に、ＷＥＢブラウザ１４２は、同じクラスに属する編集があった属性S3_003は薄青色で表示するが、編集がない属性S3_004などは黄色で表示する。なお、マーキングに使う色や方法は、本実施形態で示す薄灰色以外の色や、シェーディング、枠の色や模様を代えるなどの方法でも勿論構わない。
このように本実施形態によれば、提案の改定箇所を明示すべくＧＵＩを工夫することにより、評議員や提案者が新規に提案した辞書の改訂の内容を確認する際に、提案内容の把握やコメント及び投票操作が容易になる。
（第６実施形態）
本実施形態は第１乃至第５実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、他の分類体系から輸入されたクラスや属性を、他のクラスや属性と視覚的に区別して表示する実施形態に関わる。したがって、特に言及のない限りは第１乃至第５実施形態と構成が共通し、共通する部分の説明は省略する。
図１７は本実施形態で用いられる辞書データの一例を示す図である。図１７に示すように、辞書データは、ＩＳＯ１３５８４規格（以降：ＰＬＩＢと称する）で定義された単純木型の辞書及びＩＳＯ１３５８４−２４で定義されたクラス間で部分継承できる辞書の組み合わせである。
ＩＳＯ１３５８４規格で定義できる辞書は単純木である。すなわち、クラスは一つの上位クラスしか持たない。しかしながら、ＩＳＯ１３５８４−２４には、複数のクラスから、それぞれが利用できる属性を複数インポートすることができるＣａｓｅＯｆという概念がある。このＣａｓｅＯｆという概念を利用することにより、クラス間で部分継承が可能となる。
図１７は部分継承を含む辞書構造例を示している。クラス１、クラス２及びクラス３は単純木であり、階層関係で結ばれており、クラス１１及びクラス１２も単純木であり、階層関係で結ばれており、それぞれ上位クラスの属性を継承している。
図中、ドットが付された属性は、上位から継承されたものをあらわしている。例えばクラス２では、クラス１から継承された属性１と属性２を属性として持つ。
クラス２は、ＣａｓｅＯｆクラスで定義されており、クラス１１から属性１１をインポートしている（以降、輸入属性と呼ぶ）。属性をインポートすることにより、クラス２では、それ以降、属性１１を自身の属性として利用することが可能となる。
以上のような辞書構造に対する本実施形態の構成を図１６及び図１７を用いて説明する。
クラスに属する全部の属性を図１６のS3_006のようなテーブル形式で端末１４１側でＷＥＢブラウザ１４２を用いてレビューできる。その中で、ＷＥＢブラウザ１４２は、クラスP501_C0003で定義した属性、例えば、S3_004, S3_003を黄色あるいは薄青色（編集あり）で表示し、上位から継承した属性S3_005などを薄灰色で表示する。
また、ＷＥＢブラウザ１４２は、CaseOfクラスおよび輸入属性を他のクラスおよび属性と視覚的区別して表示装置１４３に緑色で表示する。この視覚的に区別した表示は、例えば図５のクラス２及び属性１１のように表示すればよい。
また、図１６中、クラスP501_C0003は定義した属性S3_003，S3_004などは、設定された評議員グループに属するユーザに選択されて修正・追加を行うことが可能である。一方、上位クラスから継承した属性S3_005および他のクラスからの輸入属性に対しては、非定義クラスでは、修正・追加することが不可能である。このような属性への操作制限により、下位クラスで継承した属性を編集することができないため、上位クラス及び上位クラスの他のサブクラスへの影響がない。また、輸入属性への編集に制限をかけるため、インポートされたクラスへの影響がない。
一方、クラスにあるすべての属性に対するテクニカルノートの記述は制限されない。これにより、クラスにあるすべての属性に対し、テクニカルノートを記述することを可能である。なお、マーキングに使う色や方法は、本実施形態で示す薄灰色、緑色以外の色や、シェーディング、枠の色や模様を代えるなどの方法でも勿論構わない。
このように本実施形態によれば、他の分類体系から輸入されたクラスや属性を、他のクラスや属性と視覚的に区別して表示すべくＧＵＩを工夫することにより、評議員や提案者が新規に提案した辞書の改訂の内容を確認する際に、提案内容の把握やコメント及び投票操作が容易になる。
また、上位クラスにおいて定義されている属性において下位クラスにおける辞書属性の編集の影響が及ばないようにし、またその上位クラスを親クラスとしてその属性を継承する他の兄弟クラス、すなわち同一階層の異なるクラスへ辞書改定の影響が及ぶのを抑える効果を持つ。さらに、インポートされた属性への編集も不可能に設定し、インポートした属性を定義しているクラスや、その属性をインポートしている他のクラスへの影響も抑えることができる。
（第７実施形態）
本実施形態は第１乃至第６実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、提案を表により閲覧し、かつコメント済みか否かで視覚的に区別して表示する実施形態に関わる。したがって、特に言及のない限りは第１乃至第６実施形態と構成が共通し、共通する部分の説明は省略する。
図１８は本実施形態に係る提案表の表示例を示す図である。
設定された評議員グループユーザは、ＷＥＢブラウザ１４２を用いて提案の一覧を表示させる。この場合、例えば表示用データ読み込み部１０４やデータ表示部１０５が、表示用データを生成し、ユーザ管理部１３０がユーザ毎に提案一覧表を生成して端末１４１に送信する。提案一覧表の生成では、ユーザ管理部１３０が各ユーザに関する提案を第２実施形態で説明した閲覧権スコープなどを参照して抽出すればよい。
図１８に示すように、ユーザ毎に閲覧する提案一覧テーブルができる。ＷＥＢブラウザ１４２は、そのユーザがコメントした提案５０２を薄灰色で表示し、そのユーザがコメントしていない提案５０１を薄青色で表示する。また、そのユーザが閲覧できる提案に対して、一旦投票を行ったら、投票が行った提案を、ＷＥＢブラウザ１４２あるいは分類辞書構築サーバ１側のユーザ管理部１３０や表示用データ読み込み部１０４が提案一覧表から削除する。これにより、そのユーザの提案閲覧テーブルには表示されなくなる。例えば、図１８の提案５０２に対してユーザＡが投票をした場合、提案５０２はユーザＡの提案一覧テーブルから抹消される。なお、マーキングに使う色や方法は、本実施形態で示す薄灰色以外の色や、シェーディング、枠の色や模様を代えるなどの方法でも勿論構わない。
このように本実施形態によれば、提案が複数ある場合にその提案一覧表を表示し、コメント済みか否かで視覚的に区別して表示する。また既に投票等行った提案は削除される。これにより、評議員や提案者が新規に提案した辞書の改訂の内容を確認する際に、提案内容の把握やコメント及び投票操作が容易になる。また、提案に対する即時なコメントおよび投票ができるようになる。
（第８実施形態）
本実施形態は第１乃至第７実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、投票の集計結果を表示する実施形態に関わる。したがって、特に言及のない限りは第１乃至第７実施形態と構成が共通し、共通する部分の説明は省略する。
図１９は投票結果の集計結果をまとめて表示したテーブルを示す図である。
進捗状況の各段階において、設定された評議員グループに属するユーザは投票有効時間内の提案に対して、コメントは何回でも行えるが、投票は一回しかできない。投票は、賛成・反対・棄権と３種類が設定されて、ユーザはその１つ選択して投票を行う。
上記集計、投票結果の生成は、データ表示部１０５で行われる。データ表示部１０５は、投票結果集計部１０９で得られた集計結果に基づきテーブルを生成し、あるいはグラフを生成する。なお、集計結果が提案ＤＢ１１２に書き込まれている場合には、表示用データ読み込み部１０４が提案ＤＢ１１２が集計結果を読み出しデータ表示部１０５でテーブルやグラフを生成してもよい。
この投票結果は、ネットワーク１４０を介して端末１４１に送信され、図１９に示すように、テーブル形式で表示装置１４３に表示され得る。具体的には、提案番号、投票終了時間、設定された評議員グループ総人数、投票した人数及び参加者比率、参加者うちの賛成者人数及び賛成者比率の詳細情報が表示される。
また、図２０に示すように、上記テーブルはグラフの形式で表示することも可能である。図２０（ａ）の７２０は、設定された評議員グループに投票参加者対不参加のグラフであり、参加者は全体の８０％で、８０人である。図２０（ｂ）の７２１は、グラフ７２０に示される参加者のうち、賛成者、反対者および棄権したメンバーの比率である。各段階に設定された可決条件はおのおのの参加者比率かつ賛成者比率で決定される。例えば、参加者比率は８０％以上、かつ、賛成者が６０％以上はその可決条件の一例である。
このように本実施形態によれば、改訂提案に対して、各段階の投票の集計結果および各投票詳細情報と、提案に対する個々の可決条件に対する投票の充足状態を提示することができ、辞書の改訂の公開性が向上する。
（第９実施形態）
本実施形態は第１乃至第８実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、ＧＵＩの改良に関わる実施形態である。したがって、特に言及のない限りは第１乃至第８実施形態と構成が共通し、共通する部分の説明は省略する。
図２１は、ステップＳ８１０を除いて提案者による端末１４１を用いたＷＥＢブラウザ１４２による操作のフローチャートを示す図である。８１１で示された部分の処理は、辞書管理者および各段階評議員グループの操作フローチャートである。
まず、提案者の操作を説明する。
各提案者は、端末１４１を用いてＷＥＢブラウザ１４２により、自分が提案した内容について、例えば図２２に示すような提案一覧テーブルを表示装置１４３に表示させる（ステップＳ８０１）。この提案一覧テーブルは、提案番号、提案した時間、提案内容へのリンク、提案の今の状態、各段階に提案に対するコメントへのリンク、および各段階投票集計結果へのリンクなどである。提案一覧テーブルは、表示用データ読み込み部１０４で読み出された提案データに基づきデータ表示部１０５で生成され端末１４１に送信されるものである。
提案内容の詳細を検索して確認する場合に（ステップＳ８０２）、ステップＳ８０７で選択されたクラス提案、あるいは属性提案を単独に表として表示装置１４３上にＷＥＢブラウザ１４２により表示できる（ステップＳ８０３）。
図２３はクラス提案の一つの表示例である。例えば“user1_提案２”の提案を選択した場合、ＷＥＢブラウザ１４２は、この提案の詳細内容として、CODE, CLASS_TYPEなどを一覧表として表示装置１４３に表示できる。さらに、選択された提案は実際の辞書においてどの階層に存在するかについて調べたい際、図１６に示すようなＷＥＢブラウザ画面で、提案の対象がクラスであれば、クラスツリーで別のクラスと区別して他の色（例えば赤色）で表示する。提案の対象が属性であれば、属性テーブルにおいて別の属性と区別して他の色（例えば赤色）で表示する。
提案のコメントに対して、各段階のコメント詳細情報を調べるときには（ステップＳ８０４）、図２４に示すように、該提案のコメント履歴詳細一覧表を表示装置１４３上にＷＥＢブラウザ１４２で表示できる。コメントした評議員、所属評議員グループ、コメントした時間、コメントした際提案のステータス状態、およびコメントの詳細内容などを表として表示できる（ステップＳ８０５）。
また、提案の現在の状態については、図２２のように表示されるが、さらにユーザが入力装置１４４を用いて提案段階プロセスフローで段階を示す要求を行う場合、ＷＥＢブラウザ１４２は、図２６に示すような提案段階プロセスフロー図を表示させ、かつ提案の現在の進捗状況を他の色と別の色で表示する。提案段階プロセスフロー図は、２６１〜２６８からなるプロセスからなり、そのうちの現在の進捗状況を示すプロセス２６４が別の色で表示される。
例えば、図２２中提案番号“User1_提案１”の提案の今の状態は“評議員グループ２投票中”であって、図２６では、“評議員グループ２投票段階状態”のプロセス２６４は薄青色で表示される。さらに、今までに各段階において、投票集計結果を調べる際、図２５に示すような提案番号、投票終了時間など、提案者に許可された範囲に限って各段階の集計結果詳細情報を閲覧できる。
なお、上記各処理において、提案者側の端末１４１に提供される情報は、提案者に許可された範囲で送信されるが、この「提案者に許可された範囲」は、予めユーザＤＢ１３１に登録された提案者への公開条件に基づきユーザ管理部１３０が判定し、公開条件で認められていない情報については端末１４１への情報の送信及び表示装置１４３への表示が制限される。
次に、辞書管理者または各段階の評議員グループメンバーの操作について説明する。
辞書管理者、または評議員グループは端末１４１を用いてＷＥＢブラウザ１４２により、自分の提案閲覧リストを表示装置１４３に表示させる。そして、表示されている提案閲覧リストから、詳細な閲覧を希望する提案を入力装置１４４を用いて選択する（ステップＳ８０７）。そして、選択された提案について、その提案の各段階において、提案へのコメント情報、投票情報、および今現在提案の状態を許可された範囲に限って調べることが可能である。なお、辞書管理者または各段階の評議員グループのメンバーに許可された範囲は、予めユーザＤＢ１３１に登録された辞書管理者または各段階の評議員グループのメンバーへの公開条件に基づきユーザ管理部１３０が判定し、公開条件で認められていない情報については端末１４１への情報の送信及び表示装置１４３への表示が制限される。
図２１の８１１の部分で示すように、選択された提案に対して、ユーザがステップＳ８０９の要求すなわち「現在段階を提案段階プロセスフローで提示する」を入力装置１４４を用いて要求する場合、ＷＥＢブラウザ１４２は、図２６に示すような提案段階プロセスフローを生成して表示装置１４３に表示させる。この表示の際に、提案の今の状態を他の状態と区別して薄青色で提示する。
提案各段階の投票情報を調べる場合には、図２５に示すように、投票情報の要求の入力に応答して、ＷＥＢブラウザ１４２は、選択された提案の各段階での投票詳細情報を表として表示装置１４３に表示する。この表示画面により、ユーザは投票詳細情報を閲覧できる。同様に、選択された提案の各段階でのコメント詳細情報を図２４に示すような表として閲覧できる。
さらに、選択されたいずれか一つの段階において、選択された提案に対して辞書管理者および設定された評議員グループは、その提案に対する投票情報（提案はその段階の投票終了ものである場合）、または投票中情報（提案はその段階の投票中ものである場合）を調べることが可能である。
図２７は投票の詳細情報を示すテーブルの図である。図２７に示すように、提案番号“User1_提案2”に対して、選択された段階“評議員グループ３の投票中”の詳細情報及び投票全体情報をＷＥＢブラウザ１４２により表示画面で閲覧できる。投票した人、投票時間、投票結果およびそのときのコメントを一覧できる。図２８は投票全体情報の表示例を示すテーブルの図である。投票全体情報は、例えば、評議員グループのメンバー数、投票参加者数、賛成者数、投票の終わり時間などである。この投票全体情報は、図２７に示す投票詳細情報と合わせて表示される。
このように本実施形態によれば、提案者は自分が提案した内容を検索確認することができる。そして、その提案の現時点の審議状態を表示させて各段階のコメントおよび投票情報を制限範囲内において閲覧することが可能になる。また、提案者は、自分の提案に対する審査の進捗状況を正確に把握できるようになる。また、辞書管理者及び各段階の評議員は提案に対して、今現在の審議状態、各段階のコメントおよび投票情報を決められた制限内において閲覧可能である。その結果、辞書管理者および評議員が提案の進捗状況を正確に把握できるようになり、提案に対するコメント、審査、および投票の公開性を向上できる。
（第１０実施形態）
本実施形態は第１乃至第９実施形態等の構成に別の機能を付加した実施形態に関わる。本実施形態は、辞書の編集内容の履歴を閲覧し、また履歴に対する条件付け検索を行う実施形態に関わる。したがって、特に言及のない限りは第１乃至第９実施形態と構成が共通し、共通する部分の説明は省略する。
図２９は本実施形態に示す履歴表示のフローチャートを示す図である。設定されたアクセス制限を持つユーザは、端末１４１を用いてＷＥＢブラウザ１４２により表示装置１４３上に辞書データを表示させ閲覧することができる（ステップＳ９００１）。この状態で、辞書データのうちいずれかのクラス又は属性をユーザが選択すると、ＷＥＢブラウザ１４２は選択されたクラスや属性の編集履歴を表示装置１４３に表示する（ステップＳ９００２）。図３０は編集履歴の表示例を示す図である。選択されたクラスのCodeクラスＡ、提案があった時間、その提案内容へのリンク、提案者、その提案が最終的に採用されたか、または拒否されたかなどの情報をユーザは一覧できる。また、ユーザは入力装置１４４を用いて履歴の検索条件を入力することができる。この検索条件の入力に応答して、ＷＥＢブラウザ１４２は、検索条件に合致する履歴を履歴検索結果として表示装置１４３に表示させることができる（ステップＳ９００３）。例えば、クラスＡに対して、提案された時間は2000年3月〜2002年5月までの提案期間指定、具体的な提案時間、提案者などの条件をユーザは入力することができ、これに対してＷＥＢブラウザ１４２は与えられた検索条件に合致する履歴を表示装置１４３に表示させる。
このように本実施形態によれば、辞書各クラス及び各属性に対して、その改訂の履歴およびバージョン管理が可能になる。具体的には、辞書の各クラスおよび各属性に対して、修正・追加・テクニカルノートの履歴を表に纏めＷＥＢブラウザを利用して閲覧可能になる。また、実際の提案や採択内容へのリンクを用意してその詳細な内容を確認できるようにすることで、履歴の表についての条件付き検索が可能になる。
以上説明したように上記実施形態によれば、下位が上位属性を継承する階層型辞書に対して、デジタル・ネットワークを介して、辞書データへの修正・追加・テクニカルノート記述などを行って、ＷＥＢ上で提案できる。また、この提案に対して、多数評議員からのコメント、投票をＷＥＢ上で実現できる。さらに、投票の自動集計結果により、提案が次の段階へ自動的に進む。また、最終的には、提案の採用、拒否を自動的に決定できる。
また、従来の課題であった階層型辞書に対する頻繁な編集・追加操作に対応できて、その修正内容への多数評議員がコメント、投票なども即時に行える。各提案者は、自分で提案した内容の進捗状況を正確に把握できる。また、辞書各データの履歴、バージョン管理を電子化でき、辞書の公開性を保つことができる。さらに、投票結果集計のシステム自動化により、辞書の公平性、正確性および即時性を保持できるようになる。
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
以上説明したようにこの発明は、デジタル・ネットワークを用いて製品分類等の分類辞書を作成、修正、決定等編集する分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラムの技術分野に有効である。
本発明の第１実施形態に係る分類辞書構築システムを示す全体構成図。 同実施形態に係る階層型データベースに記述されるデータ構造を示す図。 同実施形態に係るＩＳＯ１３５８４に準拠した電子カタログに記述されるデータ構造を示す図。 同実施形態に係るＷＥＢ上辞書ツリー及びクラスレビューの一例を示す図。 同実施形態に係るＷＥＢ上辞書ツリー及び属性レビューの一例を示す図。 同実施形態に係るＷＥＢ上辞書編集処理の表示画面の一例を示す図。 同実施形態に係る辞書編集処理のフローチャートを示す図。 同実施形態に係る提案データの整合化及び評価処理のフローチャートを示す図。 同実施形態に係るコメント、投票及び投票結果集計処理のフローチャートを示す図。 同実施形態に係る提案データ構造の一例を示す図。 本発明の第２実施形態に係る評議員グループの分野別登録を説明するためのクラスツリー図。 同実施形態に係る提案に対して投票権を持つ評議員グループの検出処理のフローチャートを示す図。 本発明の第３実施形態に係る辞書提案に関心や利害を持つユーザの分類図。 本発明の第４実施形態に係る属性に関係する辞書改訂ルールの一例を示す図。 同実施形態に係るクラスに関係する辞書改訂ルールの一例を示す図。 本発明の第５実施形態に係る提案データ、編集があるデータ、継承属性を視覚的に区別して表示した画面例を示す図。 本発明の第６実施形態に係るCaseofクラス及び輸入属性を説明するためのクラスツリー図。 本発明の第７実施形態に係るコメント済みの提案とコメント済みでない提案と区別して表示される画面例を示す図。 本発明の第８実施形態に係る投票詳細情報の表形式の表示例を示す図。 同実施形態に係る投票詳細情報のグラフ形式の表示例を示す図。 本発明の第９実施形態に係る各ユーザによる提案の今の状態、各段階のコメント、投票詳細等を調べる処理のフローチャートを示す図。 同実施形態に係る提案者に提示される提案一覧表の表示例を示す図。 同実施形態に係る提案者、評議員グループ及び辞書管理者に提示される提案の詳細情報の表示例を示す図。 同実施形態に係る提案者、評議員グループ及び辞書管理者に提示される提案のコメント履歴の表示例を示す図。 同実施形態に係る提案者、評議員グループ及び辞書管理者に提示される提案への投票履歴の詳細の表示例を示す図。 同実施形態に係る提案段階プロセスフロー図。 同実施形態に係る提案の投票詳細情報の表示例を示す図。 同実施形態に係る提案の投票詳細情報の表示例を示す図。 本発明の第１０実施形態に係る辞書クラス及び属性の履歴の閲覧処理のフローチャートを示す図。 同実施形態に係る履歴詳細の表示例を示す図。
符号の説明
１…分類辞書構築サーバ、１０１…辞書データ読み込み部、１０２…辞書データ書き出し部、１０３…辞書ＤＢ、１０４…表示用データ読み込み部、１０５…データ表示部、１０６…辞書データ編集部、１０７…提案データ整合化・評価部、１０８…提案データコメント・投票部、１０９…投票結果集計部、１１０…提案ステータス決定部、１１１…提案データ書き込み部、１１２…提案ＤＢ、１１３…辞書更新部、１１４…辞書改訂ルールＤＢ、１２０…ネットワーク通信部、１３０…ユーザ管理部、１３１…ユーザＤＢ、１４１…端末、１４２…ＷＥＢブラウザ、２０１…初期辞書データ、２０２…更新後辞書データ

Claims (11)

  1. 第１の属性を持つ第１の分類項目を有する第１の階層と、前記第１の属性を継承する第２の属性を持つ第２の分類項目を有し前記第１の階層よりも下位の第２の階層とを少なくとも含む複数の階層を有する階層構造により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築サーバであって、
    前記分類辞書の編集内容を分類項目又は属性で指定した提案の整合性を判定する提案整合化手段と、
    投票権を持つグループが投票可能な投票分類項目にユーザを関連づけて記憶する投票範囲記憶手段と、
    閲覧権を持つグループが閲覧可能な閲覧分類項目にユーザを関連づけて記憶する閲覧範囲記憶手段と、
    前記提案で指定された分類項目が、前記投票範囲記憶手段に記憶された前記投票分類項目あるいは該投票分類項目の属性を継承し該投票分類項目よりも下位の階層の分類項目に該当する場合に、該投票分類項目に関連づけられたユーザを投票権を持つグループに決定する投票者決定手段と、
    前記提案で指定された分類項目が、前記閲覧範囲記憶手段に記憶された前記閲覧分類項目あるいは該閲覧分類項目の属性を継承し該閲覧分類項目よりも下位の階層の分類項目に該当する場合に、該閲覧分類項目に関連づけられたユーザを閲覧権を持つグループに決定する閲覧者決定手段と、
    前記整合性の判定結果が整合性ありの場合に、前記投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行する投票管理手段と、
    前記閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信する閲覧管理手段と、
    可決条件を満たす前記提案に基づき前記分類辞書を更新する更新手段と
    を具備してなることを特徴とする分類辞書構築サーバ。
  2. 前記投票管理手段は、
    集計結果が可決条件を満たす場合には、前記審議処理を繰り返し実行し、
    前記集計結果が可決条件を満たさない場合には、前記提案を廃棄する旨を前記第１の端末に送信し、
    前記更新手段は、可決条件を満たし、かつ最終決裁が与えられた場合に前記提案を登録する旨を前記端末に送信し、前記提案に基づき前記分類辞書を更新する
    ことを特徴とする請求項１に記載の分類辞書構築サーバ。
  3. 前記提案整合化手段は、前記分類辞書が準拠する規格に定められた制約及びルールに基づき整合性を判定し、前記制約及びルールに対して前記提案に違反がある場合に違反がある旨を提案者の端末に送信し、違反が無い場合には整合性ありと判定する
    ことを特徴とする請求項１に記載の分類辞書構築サーバ。
  4. 前記請求項１に記載の分類辞書構築サーバと、前記分類辞書構築サーバと通信可能な端末とを備え、該端末は、
    表示装置と、
    前記提案で指定された分類項目又は属性を、指定されなかった分類項目又は属性と区別して前記表示装置に表示させる閲覧手段と
    を具備してなることを特徴とする分類辞書構築システム。
  5. 前記閲覧手段は、他の分類辞書からインポートした分類項目又は属性とそれ以外の分類項目又は属性とを視覚的に区別して前記表示装置に表示させ、ユーザにより選択された１つの分類項目に対して、該分類項目で利用できるすべての属性を前記表示装置に表示させ、前記選択された分類項目で定義された分類固有属性と上位階層から継承された継承属性とを視覚的に区別して前記表示装置に表示させるものであり、
    さらに、前記分類辞書構築サーバは、前記継承属性に対する編集を制限する編集制限手段
    を備えることを特徴とする請求項４に記載の分類辞書構築システム。
  6. 前記分類辞書構築サーバはさらに、前記提案に対して前記端末から送信されたコメントを前記提案に付加するコメント付加手段を備え、
    前記閲覧手段は、前記提案が複数ある場合に、ユーザ毎に提案リストを前記表示装置に表示し、かつ前記ユーザに前記コメントが付加された提案と前記コメントが付加されていない提案とを視覚的に区別した提案リストを前記表示装置に表示し、かつ前記ユーザが既に投票を送信した提案を前記提案リストから外して表示する
    ことを特徴とする請求項４に記載の分類辞書構築システム。
  7. 前記閲覧手段は、１つの提案に対して複数の可決条件が設定された場合には、前記投票の集計結果を可決条件毎に表又はグラフを生成して前記表示装置に表示する
    ことを特徴とする請求項４に記載の分類辞書構築システム。
  8. 前記閲覧手段は、提案の進捗状況を示すプロセスフロー図を前記表示装置に表示させる手段と、前記提案で指定された分類項目又は属性を、他の分類項目又は属性と視覚的に区別した前記分類辞書のクラスツリー図又は表を前記表示装置に表示させる手段とを備え、
    前記閲覧管理手段は、審議段階の提案に対するコメント情報及び投票情報を、提案者に許可された範囲で提案者の端末に送信し、前記第１の端末には、審議段階上の進捗状況を示すプロセスフロー図又は表と、審議段階のコメント情報及び投票情報とを投票権を持つグループに許可された範囲で表示させる
    ことを特徴とする請求項４に記載の分類辞書構築システム。
  9. 前記閲覧手段は、前記編集の履歴を前記表示装置に表示させる手段と、履歴の検索条件の入力に対して該検索条件に合致する履歴検索結果を前記表示装置に表示させる手段と
    を備えることを特徴とする請求項４に記載の分類辞書構築システム。
  10. 第１の属性を持つ第１の分類項目を有する第１の階層と、前記第１の属性を継承する第２の属性を持つ第２の分類項目を有し前記第１の階層よりも下位の第２の階層とを少なくとも含む複数の階層を有する階層構造により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築方法であって、コンピュータが、
    前記分類辞書を編集するための提案の対象となった分類項目又は属性の定義の整合性を判定し、
    前記提案で指定された分類項目が、投票権を持つグループが投票可能な投票分類項目にユーザを関連づけて記憶する投票範囲記憶手段に記憶された前記投票分類項目あるいは該投票分類項目の属性を継承し該投票分類項目よりも下位の階層の分類項目に該当する場合に、該投票分類項目に関連づけられたユーザを投票権を持つグループに決定し、
    前記提案で指定された分類項目が、閲覧権を持つグループが閲覧可能な閲覧分類項目にユーザを関連づけて記憶する閲覧範囲記憶手段に記憶された前記閲覧分類項目あるいは該閲覧分類項目の属性を継承し該閲覧分類項目よりも下位の階層の分類項目に該当する場合に、該閲覧分類項目に関連づけられたユーザを閲覧権を持つグループに決定し、
    前記整合性の判定結果が整合性ありの場合に、前記投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行し、
    前記閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信し、
    可決条件を満たす前記提案に基づき前記分類辞書を更新する
    ことを特徴とする分類辞書構築方法。
  11. 第１の属性を持つ第１の分類項目を有する第１の階層と、前記第１の属性を継承する第２の属性を持つ第２の分類項目を有し前記第１の階層よりも下位の第２の階層とを少なくとも含む複数の階層を有する階層構造により定義され、データベースのスキーマとして用いられる分類辞書を構築する分類辞書構築プログラムであって、この分類辞書構築プログラムはコンピュータに、
    前記分類辞書を編集するための提案の対象となった分類項目又は属性の定義の整合性を判定する処理と、
    前記提案で指定された分類項目が、投票権を持つグループが投票可能な投票分類項目にユーザを関連づけて記憶する投票範囲記憶手段に記憶された前記投票分類項目あるいは該投票分類項目の属性を継承し該投票分類項目よりも下位の階層の分類項目に該当する場合に、該投票分類項目に関連づけられたユーザを投票権を持つグループに決定する処理と、
    前記提案で指定された分類項目が、閲覧権を持つグループが閲覧可能な閲覧分類項目にユーザを関連づけて記憶する閲覧範囲記憶手段に記憶された前記閲覧分類項目あるいは該閲覧分類項目の属性を継承し該閲覧分類項目よりも下位の階層の分類項目に該当する場合に、該閲覧分類項目に関連づけられたユーザを閲覧権を持つグループに決定する処理と、
    前記整合性の判定結果が整合性ありの場合に、前記投票権を持つグループに属する第１の端末に前記提案の発生を送信する処理と、前記生成された提案に対する賛成又は反対を含む投票を前記第１の端末から受信する処理と、前記投票を集計し、該集計結果が可決条件を満たすか否かを判定する処理とを有する審議処理を異なるグループに対して繰り返し実行する処理と、
    前記閲覧権を持つグループに属する第２の端末からの閲覧要求に応答して前記提案を前記端末に送信する処理と、
    可決条件を満たす前記提案に基づき前記分類辞書を更新する処理と
    を実行させることを特徴とする分類辞書構築プログラム。
JP2003415361A 2003-12-12 2003-12-12 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム Expired - Fee Related JP4192082B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003415361A JP4192082B2 (ja) 2003-12-12 2003-12-12 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003415361A JP4192082B2 (ja) 2003-12-12 2003-12-12 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム

Publications (2)

Publication Number Publication Date
JP2005174116A JP2005174116A (ja) 2005-06-30
JP4192082B2 true JP4192082B2 (ja) 2008-12-03

Family

ID=34734881

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003415361A Expired - Fee Related JP4192082B2 (ja) 2003-12-12 2003-12-12 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム

Country Status (1)

Country Link
JP (1) JP4192082B2 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090138500A1 (en) * 2007-10-12 2009-05-28 Yuan Zhiqiang Method of compact display combined with property-table-view for a complex relational data structure
WO2015022336A1 (en) * 2013-08-12 2015-02-19 Philip Morris Products S.A. Systems and methods for crowd-verification of biological networks
CN109902104A (zh) * 2019-02-11 2019-06-18 北京百度网讯科技有限公司 用于管理知识库的方法、装置、设备和介质
JP7255219B2 (ja) * 2019-02-13 2023-04-11 日本電気株式会社 アクセス権自動設定装置、アクセス権自動設定方法及びプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03252763A (ja) * 1990-03-02 1991-11-12 Hitachi Ltd 文書分担作成管理システム
JP2961791B2 (ja) * 1990-03-09 1999-10-12 松下電器産業株式会社 共同作業支援装置
JP3412241B2 (ja) * 1994-03-03 2003-06-03 富士ゼロックス株式会社 共同作業支援システム及び方法
JPH07311764A (ja) * 1994-05-18 1995-11-28 Mitsubishi Electric Corp 文書査読支援システム
JPH09167158A (ja) * 1995-12-18 1997-06-24 Nec Corp 討議支援システム
JP3771744B2 (ja) * 1999-04-14 2006-04-26 日本電信電話株式会社 グループ作業におけるコンピュータ内に蓄積された共有情報の共同編集方法，およびグループ作業におけるコンピュータ内に蓄積された共有情報の共同編集のためのプログラム記録媒体

Also Published As

Publication number Publication date
JP2005174116A (ja) 2005-06-30

Similar Documents

Publication Publication Date Title
Benson et al. Principles of health interoperability: SNOMED CT, HL7 and FHIR
CN1992728B (zh) 用于便利分组合作的系统和方法
US8661059B1 (en) Compliance framework database schema
US20060271519A1 (en) Analyzing externally generated documents in document management system
US20080250331A1 (en) Method and System of a Voting Based Wiki and Its Application to Internet Topic Directories
US20100179818A1 (en) Utilizing Conditional Logic in Medical Documentation
US20070127597A1 (en) System and method for facilitating visual comparison of incoming data with existing data
US20060282291A1 (en) Method and means for analysis of incident data
WO2006036991A2 (en) A method and system for building audit rule sets for electronic auditing of documents
US20070061425A1 (en) Bulletin board system, server for bulletin board system, thread display method for client of bulletin board system, and program
US20030128243A1 (en) Tree-structured diagram output method and program
US20130103420A1 (en) System and method facilitating patient registration across multiple practice groups
EP2648116A2 (en) Automated system and method of data scrubbing
WO2005013162A1 (en) Systematic review system
JP4192082B2 (ja) 分類辞書構築サーバ、分類辞書構築システム、分類辞書構築方法及び分類辞書構築プログラム
Jiang et al. Effect of data environment and cognitive ability on participants’ attitude towards data governance
US20050210040A1 (en) Document organization and formatting for display
JP2007527058A (ja) データおよびメタ・データをリンクさせるためのフォームの構成メカニズムおよびその方法
US20100131544A1 (en) Interactive database
JP5222604B2 (ja) 文書管理システム及び方法
Klusmann et al. BIM based information delivery controlling system
US8799326B2 (en) System for managing electronically stored information
Kemp et al. A taxonomy of design guidance for hypermedia design
Olszowski et al. Organisational Structure and Created Values. Review of Methods of Studying Collective Intelligence in Policymaking
JP2010152694A (ja) 情報交換支援管理システム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080212

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080414

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080916

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080919

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110926

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees