JPH0727487B2 - 探索項構築の制御テーブルの導入方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、共用文書のライブラリに対するユーザ・アク
セスの拡張に関するものである、とりわけ、文書へのア
クセスに関する企業に固有の探索項を発生するために用
いられるテーブルの動的変更に関するものである。

B.従来の技術 電子オフィス・システムは、しばしば、情報の共用を可
能にする。この要求を満たす技法の１つは、電子ライブ
ラリと呼ばれるデータ収納所を用いたものである。これ
らの電子または共用ライブラリは、共通ネット・ワーク
のユーザだけでなく、機器及びプログラムの相互接続部
分からなるネットワークの他のユーザによってもアクセ
スすることができる。ユーザ（エンド・ユーザ）として
は、データ処理及び情報交換のために該システムを利用
する任意の装置、プログラム、または、コンピュータ・
システムが考えられる。該ライブラリについて情報の検
索及び格納を行なうことができるユーザの数が増すにつ
れて、いったん納められた情報の検索に関する問題も増
してきた。これらの共用ライブラリについて情報の格納
及び検索を行なう企業は、急速で、迅速なアクセスを必
要とする。企業には、任意の経済組織が考えられる。企
業には、例えば、コングロマリット、会社、会社内にお
ける１組の部門、または、会社内における単一部門があ
る。企業と共用ライブラリとの間における情報交換のた
めの電子オフイス・システムとしてはDISOSSがある。SN
Aネツトワークを介して接続されているDISOSS端末間
で、メモ、書簡、フオーム、その他の種類の通信文書な
どの文書を同期的に交換するための交換方式を定義する
代表的なアーキテクチヤとして文書交換アーキテクチヤ
（DIA）がある。

DIAは、プログラマがそれに従い、あるいは、用いる場
合、一貫した、予測可能なやり方で文書及びメッセージ
といった情報の交換をプログラムが行なえるようにな
る、プロトコル及びデータ構造を定義するプログラム間
通信アーキテクチャである。DIAは、共用ライブラリに
納められた情報のタイプとは関係がなく、情報のファイ
ル名、著名、情報の件名、情報がファイルされた日付、
及び、キー・ワードといった、送信される情報の内容を
表わした規定の組をなすパラメータを設定する。これら
のDIAの構成による記述子は、企業または他のエンド・
ユーザによるライブラリにおける文書の探索を可能にす
る。

しかしながら、DIAの現在の定義は、企業またはエンド
・ユーザが、DIAの構成による記述子以外に、共用ライ
ブラリに納められた情報に対し独特な記述子を加えるこ
とを可能にするものではない。結果として、銀行のよう
な企業は、著者、件名、または、ファイルされた日付と
いったDIA構成による記述子を用いた共用ライブラリの
探索に限定される。該企業は、“銀行口座ID"または
“ローン識別子”の意味を有する探索項を用いて探索を
行なうことはできない。同様に、製造業の企業は、“パ
ーツ”または“在庫”の意味を有する探索項を用いてラ
イブラリにアクセスすることはできない。

C.発明が解決しようとする課題 本発明の主な目的は、共用ライブラリに格納される文書
へのアクセスに当り動的に変更する探索項を構築するた
めの制御テーブルを導入する方法を提供することであ
る。

本発明の他の目的は、ラン中のプログラム／システムで
定義しなかつた私的／企業固有の探索項の構築を制御す
るパーザ・テーブル及びビルダ・テーブルを、プログラ
ムのラン後で文書の共用ライブラリへのフアイル前に、
共用ライブラリに導入する方法を提供することである。

D.課題を解決するための手段 本発明の構成は次の通りである。

文書の共用ライブラリへの格納に当りプログラム／シス
テムで定義されている探索項が構築されて探索インデツ
クス・オブジエクト48に格納される文書交換システムに
対して、交換文書プロフイル50中にサブプロフイルの形
で格納される私的／企業固有の属性情報に基づき前記探
索インデツクス・オブジエクトへ格納されるべき私的／
企業固有の、プログラム／システムで予め定義しなかつ
た探索項を構築するためのパーザ・テーブル及びビルダ
・テーブルの一方または両方を付加的に導入する方法に
おいて、 前記両テーブルの一方または両方を指定するオペラン
ド、前記属性情報に連関した企業を指定するオペランド
及び指定テーブルが新規導入かまたは既存テーブルにマ
ージするのを指定するオペランドを含む特別な導入指令
を準備するステツプと、 ユーザから伝送された前記導入指令に応答して前記共用
ライブラリのサーバが前記指定テーブルを前記共用ライ
ブラリに導入するステツプと、 導入完了に応答して前記ライブラリ・サーバから前記ユ
ーザへ向けて導入完了信号を返送するステツプと、 より成る、プログラム／システムで予め定義しなかつた
探索項の構築を制御するテーブルの導入方法。

本発明により導入された制御テーブルは、ユーザが文書
を作成して共用ライブラリにフアイルする時点で、シス
テムで定義しなかつた企業固有の、すなわちユーザ特有
の、探索項を構築する。この探索項は、文書データ・ス
トリームがパージングにより文書コンポネントを判別す
るときに、その文書の一部分になる。この事は、ユーザ
が文書を共用ライブラリ中にフアイルすることを要求す
ると、そのデータ・ストリームがシステム定義の探索項
及びユーザ特有の探索項の両方についてパージングされ
て探索インデツクス・オブジエクトへ格納されることを
意味する。

E.実施例 第１図には、共用ライブラリとエンド・ユーザの間で、
共用ライブラリに納められた文書を交換する文書管理シ
ステムが示されている。ユーザ20は、共用ライブラリ28
に文書を納めたり、共用ライブラリから文書を検索する
ことができる。ユーザ（エンド・ユーザ）としては、デ
ータ処理または情報交換用のシステムを利用する人、装
置、プログラム、または、コンピュータ・システムが考
えらる。ライブラリ28は、他のユーザによる同時アクセ
スが可能であり、従って、共通の収納所すなわち共用資
源に相当するものである。共用ライブラリ28とは違っ
て、ユーザの個人的すなわち私用文書は、局所資源24に
納められる。この局所収納資源24は、通常、他のユーザ
と共用されない。ユーザ20は、マネージャ／リクエスタ
22を介して局所収納資源24にアクセスする。マネージャ
／リクエスタ22は、また、共用ライブラリ28に対するユ
ーザのアクセスに制御を加えるライブラリ・サーバ26と
のインターフェイスも行なう。ユーザが文書ライブラリ
28に文書をファイルする場合、ライブラリ・サーバ26
は、ライブラリに納められる情報の内容を表わすパラメ
ータまたは記述子を作成する。

第２図を参照すると、第１図に示されたライブラリ28に
納められた情報に関する基本文書モデルが示されてい
る。この文書モデルは、ライブラリ・サーバ26によって
生成され、各文書毎に納められる。DIAライブラリ・サ
ービス・アーキテクチャを支援するために、基本文書モ
デルを明確に実現する必要はないが、これらのモデルま
たはそのサブセットに対し設計を写図する必要がある。

ユーザ・プロフィル・オブジェクト36（UPO）は、DIA文
書モデルの一部ではなく、DIA文書モデルが参照するオ
ブジェクトである。表示のユーザがオフィス・システム
・ネットワークの登録メンバの場合、ユーザ・プロフィ
ル・オブジェクト36が生成される。該オブジェクトは、
ユーザを識別するものであり、別名、ユーザに許可され
るサービス、省略時会計情報、及び、その他のユーザに
固有の情報といった、ユーザに関する情報を含んでい
る。

文書モデル・オブジェクト30は、DIA文書モデルの中心
であり、文書が初めて文書ライブラリにファイルされる
場合に生成され、論理的に最初のオブジェクトである。
該オブジェクトには、特定の文書の所有権及び属性に関
する情報が含まれている。さらに詳述すると、それに
は、文書の編集が可能か、あるいは、編集が不可能かと
いうこと、最大バージョン数、及び、ユーザが編集でき
ない文書の編集を試みた場合にとるべきアクションとい
った文書例の属性が含まれている。さらに、文書モデル
・オブジェクト30には、下記情報のうち任意のものを含
むことができる： １）更新のため、ライブラリから文書を取り出したユー
ザを表わす文書レベル・ロック情報 ２）ある文書内容がライブラリ・サーバの直接制御から
除去された旨の表示。

３）ある文書の一部をライブラリ・サービス制御から除
去したり、あるいは、ライブラリ・サービス制御に戻す
ように命じるライブラリ・アドミニストレータに対する
指令、 ４）ライブラリ・サーバの直接制御から除去される時間
及び日付情報、 ５）ライブラリ・サーバの直接制御から除去される情報
の位置、 ６）永久記録を目的とする任意選択情報。

アクセス制御モデル・オブジェクト32（ACMO）は、文書
が初めてDIAライブラリにファイルされる場合に生成さ
れる。アクセス制御モデル・オブジェクト32の主たる目
的は、非所有者による文書へのアクセスについて判定す
るのに用いられる情報を整理統合することにある。該オ
ブジェクトには、文書に誰でもアクセスできるか（公
開）、明確に指定された限定数のユーザにしかアクセス
できない（私用）、あるいは、他のユーザと情報の共用
が行なえるかといったアクセス制御情報が含まれてい
る。アクセス制御モデル・オブジェクト32には、文書の
保存及び廃棄を管理する情報が含まれている。

文書活動ログ・オブジェクト34（DHLO）は、文書がライ
ブラリにファイルされており、ユーザが文書にさまざま
な活動を記録したいという場合に、任意に生成される。
例えば、ユーザは、文書の読取り回数及び誰が読み取っ
たかを記録したいと考えることもある。

文書関係オブジェクト42（DRO）は、文書が最初にライ
ブラリにファイルされる場合に生成される。その目的
は、ある文書と、他の関係する文書またはグループ化さ
れる文書との間における論理関係を表わすことにある。
例えば、DIAアーキテクチャは、他の文書を含んでいる
フォルダ文書の生成を可能にする。こうした関係が存在
する場合、フォルダに含まれる各文書は、ライブラリ割
当て文書名（LADN）と呼ばれるポインタ項目を文書関係
オブジェクト42を備えている。

バージョン制御オブジェクト40（VCO）は、文書が最初
にライブラリにファイルされる場合に生成され、単一名
のついたバージョンの文書を構成することが可能ないく
つかのオブジェクトに関する情報を含んでいる。該オブ
ジェクトは、バージョンのネーミング、バージョンのレ
ベル・ロック、及び、他のバージョンに関係したレベル
処理制御のための空間を提供する。

プロフィル内容オブジェクト44（PCO）は、文書が最初
にライブラリにファイルされ、ユーザが性能またはその
他の理由からサブオブジェクトの生成を望む場合に生成
される。プロフィル内容オブジェクト44は、サブオブジ
ェクトに関連したプロフィル情報のための収納所であ
る。

文書内容オブジェクト46（DCO）は、文書が最初にライ
ブラリにファイルされる場合に生成され、文書内容に関
する記録域を提供する。さらに、文書内容オブジェクト
46は、さまざまな測定単位による文書の実際のサイズに
関する情報を保管するための記憶域を提供する。

探索インデックス・オブジェクト48（SIO）には、文書
内における探索に用いられる項目が含まれている。該項
目は、他のオブジェクトに関する下記シーケンスによる
アクションの結果として、SIO48に納められる。基本の
文書モデル・オブジェクト30が、最初に、FILE指定の処
理の一部として生成される。ライブラリ・サーバは、次
に、プロフィル内容オブジェクト44、文書関係オブジェ
クト42、及び、アクセス制御モデル・オブジェクト32を
走査して、パラメトリックSEARCHの支援に用いられる項
を見つけ出す。各探索項が識別される毎に、探索インデ
ックス・オブジェクト48において、その名前にパラメト
リック探索項値と意味を含む項目が作成される。ライブ
ラリ・サーバによる前述のオブジェクトの走査時に、SI
O48が存在しなければ、１つ生成して、探索インデック
ス・オブジェクト48が常に存在したかのように項目が納
められる。

逆探索インデックス・オブジェクト38（RSIO）は、DELE
TE指令によってライブラリから文書が除去される際、探
索インデックス・オブジェクト48の項目の除去を支援す
るために存在する。パラメトリック探索項に関する項目
は、探索インデックス・オブジェクト48において作成さ
れると同時に、RSIO38に納められる。

第３図を参照すると、共用ライブラリに格納された各文
書に対して、DIAで定義の探索項（すなわち、プログラ
ムにより定義された探索項を指称し、本明細書ではDIA
定義またはシステム定義の探索項と略称する）に加え
て、プログラムのラン後にアドミニストレータ／ユーザ
により企業固有の探索項を追加する本発明の方法が開示
されている。交換文書プロフイル50においては、システ
ム定義探索項及び企業固有／私的の各探索項が、各々、
ブロツク56及びブロツク52/54内に格納されている。こ
のシステム定義探索項が従来の基本的DISOSSシステムで
元来使用されていた探索項である。DIA構成の一部とし
てサブプロフイルが記述されているときは、DIA定義の
基本サブプロフイルの存在により、それらのサブプロフ
イルに対応したブロツク52及び54がチエツクされる。

交換文書プロフイル50（IDP）、並びに企業固有の探索
項パーザ・テーブル58及びビルダ・テーブル60が探索イ
ンデツクス62を構築（ビルド）するのに必要な文書のコ
ンポネントであり、これらは各文書と共に共用ライブラ
リに格納される。これらのテーブルは、DIA探索データ
ストリームのパージングまたはビルデイングに必要な書
式情報を記述している。従つて、これらのテーブルは探
索インデツクスが作成される前に共用ライブラリ中に存
在しなければならない。前述のように、IDP50には、シ
ステム定義の属性56、企業固有の属性52及び私用属性54
がサブプロフイルの形で含まれており、これらの属性
は、探索インデツクスの構築（ビルド）に使用される。
システム定義の属性56は、情報のフアイル名、著者名、
主題名、及び情報が文書活動ログにフアイルされた日付
などのシステム定義探索項の作成に使用される。企業固
有の属性52はIDP50内の企業固有のサブプロフイルに格
納される。この属性は、例えば、企業が銀行の場合、
“銀行口座ID"、“ローン識別子”などの企業固有の探
索項の作成のためにバーザ・テーブル58及びビルダ・テ
ーブル60と共に使用される。使用属性は、私用サブ・プ
ロフイル54に格納される。

次に企業固有の探索インデツクスの作成について説明す
る。システム・アドミニストレーシヨン・プログラム
（アドミニストレータと呼ぶ）は、先ず、フイールド
（すなわち、銀行口座ID）が企業固有の探索項であるこ
とを判別する。アドミニストレータは、交換文書プロフ
イル50（IDP）を評価して銀行口座IDをサブプロフイル
として追加する。次に、この銀行口座IDを含むパーザ・
テーブル及びビルダ・テーブルを、各々、作成する（日
付、著者名などのシステム定義探索項を作成するための
パーザ・テーブル及びビルダ・テーブルはプログラマに
より供給されることに留意されたい）。アドミニストレ
ータは、前記システム定義の両テーブルをロードすると
共に、後述するINSTALL指令を使用して企業固有の探索
項（すなわち銀行口座ID）のためのパーザ・テーブル及
びビルダ・テーブルをロードする。システム定義探索項
をビルドするためのプロセス・ルーチンが呼び込まれ、
ブロツク52内にサブプロフイルの存在が判定され、企業
固有の探索項のためのパーザ・テーブル及びビルダ・テ
ーブルをチエツクする。このようにして、システム定義
探索項及び企業固有の探索項、すなわち銀行口座ID、を
含むフイールドが探索インデツクスの一部を構成するこ
とを指示する探索インデツクスが作成される。この事
は、文書を企業固有の探索フイールド（すなわち銀行口
座ID）と共に共用ライブラリにフアイルしようとするユ
ーザがその探索項（銀行口座ID）を構築して探索インデ
ツクス・オブジエクト48（第２図）に格納することを意
味する。

このようにして、DISOSSシステムに対して、新規な指令
語INSTALLの導入及びそれに付随する若干のフアームウ
エアの修正により、アドミニストレータは、アプリケー
シヨン・プログラムのラン後でもシステム定義探索項と
は別に企業固定の探索項（ESST）を追加することができ
る。これらの探索項（ESST）は、パーザ・テーブル及び
ビルダ・テーブルをDIA定義の書式に従つて処理し、動
的に更新することにより、容易に作成できる。これは、
両テーブル用にコード化する既存の書式データ・オブジ
エクト内容アーキテクチヤ（FDOCA）を使用することに
より達成される。FDOCAは、ユーザに対して、データ構
造及びデータの意味に関する情報提供を許可するIBM社
規定のオブジエクト内容アーキテクチヤである。FDOCA
は、１個のフアイル中に、データ処理タイプのデータ及
びその記述子を含めることができる。

第７図を参照すると、企業固有探索項のパーザ・テーブ
ルの一例が図示されている。図中、データは、下段のブ
ロツクに図示されており、またその記述子は中段のブロ
ツクに図示されている。具体的には、データは、各々３
桁の数字から成る４行×11列のアレイの形で表現されて
いる。データのための記述子は、例えば４行から成り、
第１行はデータ・タイプ行であり、予め定めた数字によ
りテキスト・データまたはグラフイツク・データの区別
を表わす。第２行はデータ・タイプ・パラメータ行であ
り、本例では３バイト長である。第３行及び第４行は、
各々、行方向及び列方向の範囲を規定しており、本例で
は、各々、４及び11である。前述及び本例のように、FD
OCAは、データ処理タイプのデータとその記述子を同一
のパーザまたはビルダ・テーブルに格納してもよい。

企業固有探索項のためのパーザ・テーブル及びビルダ・
テーブル（ESSTテーブルと略称する）は、システム定義
探索項による標準のライブラリ・サービスに加えて、追
加のライブラリ・サービスを希望していることを指示し
なければならない。これらのテーブルが追加のサービス
を指示しなければ、その追加サービスが提供されない。
ESSTテーブルが存在しないと、第３図の企業固有の探索
項のサブプロフイル52がスキツプされる一方、完成した
バイト・データとして格納され処理されるので、探索イ
ンデツクス62の一部を構成しなくなる。

第１図のライブラリ・サーバ26は、第３図に示す探索イ
ンデックス62を構築する前に、企業に固有の探索項（ES
ST）テーブルの存在をチェックする。該テーブルが適当
に導入されていなければ、探索インデックスは作成され
ない。該テーブルの導入が適正である場合、ライブラリ
・サーバは、パーザ・テーブル58及びビルダ・テーブル
60に見られる妥当性検査ルール，シノニム規定、及び、
標準化情報に基づきESSTに関する探索インデックスを作
成する。本発明は、企業のエンドユーザに固有の要件に
基づく妥当性検査済テーブルを企業のエンド・ユーザが
ロードできるようにするものである。従って、企業のエ
ンド・ユーザには、企業の要件毎に妥当性検査ルールを
変えるが、交換可能なDIA規定による構文及び書式は維
持する能力が与えられる。

第４図乃至第６図を参照して詳細に後述されるように、
本発明では、ESSTパーザ・テーブル及びESSTビルダ・テ
ーブルを、文書を作成して共用ライブラリに格納する時
点において、変更する（すなわち、ライブラリに導入し
たり、そこから削除したりする）ために、基本的DISOSS
システムにとつては新規な文書交換管理指令を準備す
る。これらの新規の指令体系の導入に伴い、フアームウ
エアの変更を必要とするが、この変更は、各指令の明細
から当業者が容易に実施しうる範疇に属するものであろ
う。新規な指令には、INSTALL、FETCH、UNINSTALLが含
まれる。

第４図を参照すると、本発明は、パーザ・テーブル及び
ビルダ・テーブルを導入するための新しい文書交換管理
指令を提供する。INSTALL指令を用いて、ライブラリ制
御オブジェクトがDIAライブラリに導入される。本発明
に用いられているように、ライブラリ制御オブジェクト
は、企業に固有の探索項の生成に用いられるパーザ／ビ
ルダ・テーブルと同義である。ライブラリ制御オブジェ
クトは、許可されたライブラリ・アドミニストレータだ
けしか導入することができない。この指令を用いて、ラ
イブラリ・アドミニストレータは、下記の全ての機能を
実施することができる： １）制御オブジェクトのタイプを識別する、２）該オブ
ジェクトとの関連を確立する、３）該オブジェクトを導
入すべきライブラリを識別する、４）該オブジェクトが
新たに導入されるのか否かを指示する、５）該オブジェ
クトを既存のオブジェクトと組み合わせられることにな
るのか否かを指示する、６）該オブジェクトが既存のオ
ブジェクトと取り替えられることになるか否かを決定す
る。

再び第４図を参照すると、INSTALL指令のオペランド・
フィールドが、システム・アドミニストレータに利用可
能な各種オプションを指示する。IDENTIFIED−DATA（ID
D）オペランドは、導入すべきオブジエクトのテーブル
・タイプがパーザ・テーブルかビルダ・テーブルかを指
定する。OBJECT−KEYオペランドは、IDDオペランドで指
定のオブジエクトと連関した企業を指定する。OBJECT−
TYPEオペランドは、オブジエクトの文書タイプがテキス
トかグラフイツクかを指定する。パーザ・テーブルかビ
ルダ・テーブルかを区別する必要がなく両テーブルを共
に導入するときは、OBJECT−KEY及びOBJECT−TYPEの両
オペランドによりライブラリに導入すべきオブジエクト
が特定される。OBJECT−TYPEオペランドのみがライブラ
リ・アドミニストレータによつて供給されてもよい。

２個のオプシヨナル・オペランド、すなわち、TARGET−
SERVICE及びINSTALL−OPTION、がINSTALL指令と共に使
用される。TARGET−SERVICEオペランドは、オブジエク
トを導入すべきライブラリを指定する。

INSTALL−OPTIONオペランドは、既存のオブジェクトと
組み合わせるために、あるいは、既存のオブジェクトに
取って代るために、新たに導入されることになるのか否
かを指定する。このオペランドの省略時の状態は、オブ
ジェクトが新たに導入されることになる。

INSTALL指令を利用して、ライブラリにライブラリ制御
オブジェクト（パーザ／ヒルダ・テーブル）が導入され
ると、該指令が首尾よく完了したことが示され、第4A図
に示すACKNOWLEDE指令が戻される。首尾よく完了した状
況が、DIA ACKNOWLEDGE指令のEXCEPTION−CODEオペラ
ンドで戻される。

オブジェクトがDIAライブラリに導入されると、エンド
・ユーザは、検分または更新のため、コピーを検索する
ことが可能になる。これは、第５図に示すFETCH指令を
用いて行なわれる。オブジェクトを検索するエンド・ユ
ーザは、少なくとも、オブジェクトに対する“読取り”
の権限を有していなければならない。エンド・ユーザ
は、もとのオブジェクトのコピーを検索し、検分するこ
とができるが、もとのオブジェクトを検索し、更新する
ことができるのは、許可されたライブラリ・アドミニス
トレータだけである。

再び第５図を参照すると、FETCH指令に利用可能なオペ
ランドが、調べられる。OBJECT−KEY及びOBJECT−TYPE
が、必要とされるオペランドである。OBJECT−TYPEオペ
ランドは、オブジェクトの文書タイプを識別する。これ
らの必要とされるオペランドを共に用いることによっ
て、ライブラリに導入されるオブジェクトが一意的に識
別される。TARGET−SERVICEオペランド及びCHECK−OUT
オペランドは、任意選択である。TARGET−SERVICEオペ
ランドは、オブジェクトを見つけるべきライブラリ名、
及び、ライブラリ・サーバに対する省略時解釈を指定す
る。CHECKOUT−OPTIONオペランドは、オブジェクトが検
分のためのものか、あるいは、更新のためのものかを指
定する。CHECKOUT−OPTIONの省略時解釈は、検分だけの
ためのものである。

テーブルがターゲット・ライブラリからうまく検索され
ると、DELIVER指令が、ライブラリ・サーバによる処理
の終了時に送り出される。第5A図には、FETCH指令の送
信、及び、最終的には、DELIVER指令によって示される
ようなその上首尾の終了が示されている。DIAアーキテ
クチャの規定によって要求されるように、DELIVER文書
交換単位（DIU）には要求される情報が含まれる。

ライブラリ制御オブジェクトが特定の企業によってもは
や必要とされなくなると、それらは、UNINSTALL指令を
用いてDIAライブラリから除去することが可能になる。
ライブラリ制御オブジェクトは、許可されたライブラリ
・アドミニストレータによってしか削除することができ
ず、正規のDIAライブラリのエンド・ユーザによって削
除することはできない。UNINSTALL指令は、その利用可
能なオペランドと共に第６図に示されている。OBJECT−
KEY及びOBJECT−TYPEは、必要とされるオペランドであ
る。OBJECT−KEYオペランドは、企業を識別するが、１
つだけしか供給することができない。OBJECT−TYPEオペ
ランドは、オブジェクトの文書タイプを識別し、さら
に、OBJECT−KEYオペランドと共に、ライブラリに導入
されたオブジェクトを一意的に識別する。１つのOBJECT
−TYPEオペランドしか供給することができない。

あるテーブルがターゲット・ライブラリからうまく削除
されると、ライブラリ・サーバは、ACKNOWLEDGE指令で
応答する。第6A図には、UNINSTALL指令及びACKNOWLEDGE
指令のシーケンスが示されている。

要するに、本発明は、各企業要件毎にパーザ・テーブル
及びビルダ・テーブルを動的に変更できるようにする方
法を提供することにある。テーブルは、ライブラリに導
入され、必要がなくなると、除去することができる。現
在導入されているテーブルのコピーは、適正な読取り権
限を有していれば、どのエンド・ユーザにでも提供する
ことができる。これは、INSTALL、FETCH、及び、UNINST
ALL指令の生成によって行なわれる。INSTALL指令は、テ
ーブルのタイプを識別し、企業との連関を規定するオペ
ランドを送り、既存のテーブルと取り替えるため、また
は、既存のテーブルと組合わせるため、テーブルが新た
に導入されるのか否かを指示することによって、テーブ
ルのライブラリへの導入を可能ならしめる。FETCH指令
は、検分または更新のため、ライブラリからのテーブル
のコピーを検索できるようにする。最後に、UNINSTALL
指令は、もはや必要がなくなると、ライブラリからテー
ブルを削除できるようにする。新しい指令に加え、本発
明は、ライブラリ制御に関する２つの新しいオペランド
・フィールドを提供する。これらのオペランドは、テー
ブルと連関した企業を一意的に識別するために用いられ
る。OBJECT−KEYオペランドを利用して、テーブルに連
関した企業が識別され、OBJECR−TYPEオペランドを利用
して、テーブルのタイプが識別される。該指令と、利用
可能なオペランドが相俟って、文書交換システムのため
に、企業に固有の項を生成するのに必要なテーブルの生
成を容易にする。

F.発明の効果 本発明は、企業に固有の探索項のインデックスを作成す
るのに用いられる探索項のテーブルを動的に変更する方
法を提供するものである。

【図面の簡単な説明】

第１図は、本発明を実施することができる文書管理シス
テムのブロック図である。 第２図は、第１図に示すシステムのライブラリにファイ
ルされる各文書毎に生成される基本文書モデルである。 第３図は、プロフィル内容オブジェクトに納められる交
換文書プロフィルのブロック図である。 第４図は、第３図に示すパーザ・テーブル及びビルダ・
テーブルを導入するための、利用可能なオペランドを備
えた文書交換INSTALL指令である。 第4A図は、INSTALL指令の実行がうまくいった場合の望
ましい応答である。 第５図は、検分または更新のため、パーザ・テーブル及
びビルダ・テーブルの検索を行なう手段をエンド・ユー
ザに与える、利用可能なオペランドを備えた文書交換FE
TCH指令である。 第5A図は、FETCH指令の実行がうまくいった場合の望ま
しい応答である。 第６図は、パーザ・テーブル及びビルダ・テーブルを削
除するための、利用可能なオペランドを備えた文書交換
UNINSTALL指令である。 第6A図は、UNINSTALL指令の実行がうまくいった場合の
望ましい応答である。 第７図は、定様式データ・オブジェクト内容アーキテク
チャを用いてコード化されるパーザ・テーブルを示して
いる。 20……ユーザ、22……マネージャ／リクエスタ 24……局所収納資源、26……ライブラリ・サーバ 28……共用ライブラリ 30……文書モデル・オブジェクト 32……アクセス制御モデル・オブジェクト 34……文書活動ログ・オブジェクト 36……ユーザ・プロフィル・オブジェクト 38……逆探索インデックス・オブジェクト 40……バージョン制御オブジェクト 42……文書関係オブジェクト 44……プロフィル内容オブジェクト 46……文書内容オブジェクト 48……探索インデックス・オブジェクト 50……交換文書プロフィル 52……企業に固有の属性 54……利用サブ・プロフィル 56……DIAで規定の属性 58……パーザ・テーブル 60……ビルダ・テーブル。

Claims (1)

【特許請求の範囲】
1. 【請求項１】文書の共用ライブラリへの格納に当りプロ
   グラム／システムで定義されている探索項が構築されて
   探索インデツクス・オブジエクト48に格納される文書交
   換システムに対して、交換文書プロフイル50中にサブプ
   ロフイルの形で格納される私的／企業固有の属性情報に
   基づき前記探索インデツクス・オブジエクトへ格納され
   るべき私的／企業固有の、プログラム／システムで予め
   定義しなかつた探索項を構築するためのパーザ・テーブ
   ル及びビルダ・テーブルの一方または両方を付加的に導
   入する方法において、 前記両テーブルの一方または両方を指定するオペラン
   ド、前記属性情報に連関した企業を指定するオペランド
   及び指定テーブルが新規導入かまたは既存テーブルにマ
   ージするのを指定するオペランドを含む特別な導入指令
   を準備するステツプと、 ユーザから伝送された前記導入指令に応答して前記共用
   ライブラリのサーバが前記指定テーブルを前記共用ライ
   ブラリに導入するステツプと、 導入完了に応答して前記ライブラリ・サーバから前記ユ
   ーザへ向けて導入完了信号を返送するステツプと、 より成る、プログラム／システムで予め定義しなかつた
   探索項の構築を制御するテーブルの導入方法。