JP2007102814A

JP2007102814A - ファイルを定義し管理する方法

Info

Publication number: JP2007102814A
Application number: JP2006355059A
Authority: JP
Inventors: Franz-Josef Fritz; フリッツフランツ−ヨーゼフ; Norbert Schroeder; シュレーダーノルベルト
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 1997-10-07
Filing date: 2006-12-28
Publication date: 2007-04-19
Also published as: IL135378A0; EP1025516A1; US6430563B1; AU764026B2; JP2001519569A; AU1029699A; CA2303315C; WO1999018522A1; US6134552A; IL135378A; CA2303315A1; JP3939923B2

Abstract

【課題】マルチユーザ環境における文書の能率的な管理と保存のための方法であって、オブジェクトのダイナミックなバージョン化の最中に様々なオブジェクト間においてリンク及び参照を設定・管理する方法を提供する。
【解決手段】ファイルを表すコンポーネントを参照する少なくとも一つの物理オブジェクトを作成し、コンテンツリポジトリにおける絶対パスを定義し、複数のファイルをコンテンツカテゴリーにグループ化し、コンテンツコンポーネントレコードに基づき絶対パスに相対する相対パスを定義し、一意的なオブジェクトＩＤを作成し、そして、絶対パスと相対パスとに、オブジェクトＩＤを加えることによって検索可能となる。
【選択図】図１

Description

本発明は概してオブジェクト管理及び記憶システムに関し、より詳細には関連オブジェクトの大きな集まり内におけるオブジェクトの複数バージョン及びコンテキスト変化型の作成と管理に関する。また、本発明はオブジェクト間のリンクのダイナミックな解決、及び、特定の基準に基づく正確なバージョンの検索のための技術に関する。

オブジェクト管理システムは、マルチユーザ環境内でオブジェクトにアクセスしたり、表示したり、又は編集するためのシステムであると定義することができる。この文脈において、オブジェクトとは、ユーザにより作られ、編集され、又は見られるファイルであると定義できる。オブジェクトはテキスト、グラフィックス、バイナリ、音声等のファイルフォーマットを含む。最初のユーザが元のファイルを作り、その後、複数のユーザがそのファイルを表示したり編集したりする。これまでは、複数のユーザにより同時に編集されている多数の文書を管理したり、文書の最も正確で新しいバージョンを常に検索することは困難であった。仮に二人のユーザが同一の文書を編集する権利を有し、いずれもがその文書を各々のフロントエンド編集アプリケーションに転送し、作業を行い、各々その文書の異なるバージョンを記憶装置に戻したとすれば、一方のユーザの変更の上に他方のユーザの書き込みが行われる。このような可能性は本発明によれば、バージョン化処理及びチェックインないしチェックアウト手段により排除される。

さらに、これまで、文書の新しいバージョンにより、それらを参照するソースに問題が生ずるのが通例であった。ソース文書はターゲット文書に対する参照ないしリンクを含む。ソースが特定のターゲットを参照する際、ターゲットが該ターゲットの新しいバージョンとして変更されている場合、ソースはターゲットの最新バージョンを参照するのが理想である。何らかの方法により参照を変更して、新しいバージョンを指すようにしなければならない。文書の古いバージョンに対する参照が複数ある場合、全ての参照を変更する必要がある。リンクは必ずしも通常の意味におけるソース文書内に存在する必要は無く、どのような形式のオブジェクト内でも、特に業務オブジェクト内でも存在することができる。

この問題は、ワールドワイドウェブ上での文書出版におけるハイパーテキストで顕著である。ウェブ上の文書はハイパーテキストマークアップ言語（HTML）により記述される。ハイパーテキスト文書は通例、他のハイパーテキスト文書へのリンクであるハイパーリンクを有する。ソースとなるハイパーテキスト文書がターゲットハイパーテキスト文書へのハイパーリンクを有する場合、ターゲットハイパーテキスト文書の新しいバージョンが作られた時には、該ハイパーリンクを変更する必要がある。ターゲットハイパーテキスト文書が記憶システム内の別の場所に移動された場合、ハイパーリンクを再度変更する必要がある。

この問題はこれまで、単にターゲット文書の新規バージョンに元のターゲット文書との同一性を持たせて、参照の変更の必要性を無くすという方法により解決されてきた。しかし、この方法には問題がある。例えば、フランス語のソース文書が英語のターゲット文書を参照する場合、まだターゲット文書のフランス語バージョンが利用可能となっていないとする。この場合、実際にフランス語バージョンが利用可能となった時、該フランス語バージョンによりターゲット文書の英語バージョンを上書きすることは許されない。なぜなら、ターゲット文書の英語バージョンを参照している他の英語ソース文書が存在する可能性があるからである。

元のバージョンを維持しつつ、文書の新バージョンを作れることが望まれる。多くの場合、文書のある特定のバージョンの変更ないし編集は、必ずしも、元の文書の上書きを暗示する修正ではない。例えば、新バージョンはただ単にフォーマット、言語等における変化の場合もある。

本発明の課題は、同一のオブジェクトの異なるバージョンを作成、管理するためのオブジェクト管理方法を提供することである。

本発明の別の課題は、オブジェクトのバージョン化手段を提供することである。

本発明の別の課題は、システム内のオブジェクト間の関係を、様々な確立された基準及びユーザにより定義された基準に基づいて作ることである。

本発明の別の課題は、様々なフロントエンドエディタ／ブラウザアプリケーションと一体化できる管理及び記憶システムを提供することである。

本発明の別の課題は、オブジェクトのダイナミックなバージョン化の最中に様々なオブジェクト間においてリンク及び参照を設定・管理するための方法を提供することである。

本発明の別の課題は、フロントエンドクライアントアプリケーションからの呼出しに応じて、オブジェクトの特定のバージョンの正確な検索を可能とすることである。

本発明の別の課題は、複数のユーザに対して、オブジェクトの正確さを損なうことなく同一のオブジェクトへのアクセスを可能とすることである。

物理記憶場所に記憶されたファイルを定義し、管理する方法であって、
（ａ）前記ファイルを表すコンポーネントを参照する少なくとも一つの物理オブジェクトを作成するステップと、
ただし前記ファイルはコンテンツコンポーネントレコードを形成する、
（ｂ）コンテンツリポジトリにおける絶対パスを定義するステップと、
ただし、前記コンテンツリポジトリは前記物理ファイルの記憶場所の論理記述を提供し、前記コンテンツリポジトリを言及する少なくとも一つのコンテンツカテゴリーを含む、
（ｃ）前記複数のファイルを前記コンテンツカテゴリーにグループ化するステップと、
（ｄ）前記コンテンツコンポーネントレコードに基づき前記絶対パスに相対する相対パスを定義するステップと、
（ｅ）一意的なオブジェクトＩＤを作成するステップと、
（ｆ）前記コンテンツリポジトリのための前記絶対パスと前記コンテンツコンポーネントレコードのための前記相対パスとに、前記オブジェクトＩＤを加えるステップと、
を有する方法、
によって解決される。

本発明はオブジェクトを管理し記憶するためのコンピュータシステムに関する。このコンピュータシステムは、データベース、光学式アーカイブ、ウェブ上の文書サーバ、管理エージェント、事務管理用データ表、及びクライアントフロントエンドエディタ／ブラウザアプリケーション等の記憶手段を有する。オブジェクトとは、全てのフォーマットにおけるあらゆる形式のファイルないし文書である。オブジェクトは例えば、テキスト、バイナリファイル、グラフィックス等である。本発明は、３層コンテンツモデルを使用して様々なバージョンを有するオブジェクトを管理する。

モデルは、コンポーネント、物理オブジェクト、及び論理オブジェクトから構成される。複数の物理オブジェクトが１つの論理オブジェクトに属する一方、物理オブジェクト自体は個々の文書を表す。論理オブジェクトは最上層を構成し、オブジェクトをその最も一般的な用語で記述する。論理オブジェクトはコレクションとも呼ばれる。物理オブジェクト、すなわち、任意の時間に実際に存在する様々なバイナリオブジェクトのメタ記述であるオブジェクトは、何個でも、論理オブジェクトに属することができる。物理オブジェクトは一つだけの論理オブジェクトに属する特定のバージョンを記述し、該論理オブジェクトは記述される主題の一般的意味を表す。物理オブジェクトはコンポーネントへの参照を含み、該コンポーネントはファイル及び該ファイルへのポインタに関連する管理データを含む。

本発明のシステムは、複数ユーザによるオブジェクトの同時編集を防止するための制御手段を提供する。チェックイン／アウト手段により、オブジェクト管理システムは大規模なマルチユーザ環境におけるデータ精度を維持することができる。オブジェクトがチェックアウトされると、管理エージェントが、管理データ表内において元の物理オブジェクト用のロックを設定する。その結果、他のユーザは該オブジェクトを変更したり、知識プロバイダに新しいバージョンを転送しようとしても、オブジェクトにアクセスできなくなる。最初のユーザが文書からチェックアウトし、第２のユーザが同じ文書をチェックアウトしようとする場合、管理エージェントはチェックアウト情報を参照して、要求を拒絶する。

本発明のシステムはまた、コンテキスト解決手段を有する。コンテキスト解決手段は、論理オブジェクトへの要求があると、コンテキスト、ユーザの現在使用している言語との相関、フォーマット等に基づいて、その論理オブジェクトに関連した最も適切な物理オブジェクトの検索を可能にする。コンテキスト解決は、特定の論理オブジェクトによりカプセル化された物理オブジェクトの属性、並びにユーザのクライアントアプリケーションの属性に基づいて実行される。さらに、コンテキスト感知選択のプロセスを、アプリケーション特有のルール及び情報により補完することができる。特定のオブジェクトに関連付けられた物理オブジェクトはそれぞれ、異なる属性、すなわち言語、フォーマット等を有する。コンテキスト解決では、個々の物理オブジェクトの属性と、ユーザのフロントエンドクライアントアプリケーションの属性が比較される。

本発明のシステムはさらに、論理ハイパーリンク手段を有する。論理ハイパーリンク手段は、システム内の様々なオブジェクト間の参照を提供する。好適な実施例では、ウェブ上の文書サーバが記憶手段として使用され、様々なオブジェクトがハイパーリンクを介して参照される。この手段は“ソフト”な、すなわちランタイムにおけるターゲット文書の、コンテキストに応じた選択を可能とし、特定の場所の特定のオブジェクトを参照しない論理ハイパーリンクを使用する。論理ハイパーリンクは論理オブジェクトのグローバル・ユニーク・アイデンティファイア（GUID）及び実行可能プログラムの識別子を参照する。適切な物理オブジェクトを選択するために必要な属性はランタイムまで発生されない。このように、論理ハイパーリンクは実質上、実行中のバックエンド装置からクライアントアプリケーションを遮蔽する一種の“遅れバインディング”である。ソースオブジェクトがターゲットオブジェクトを参照する際、ターゲットオブジェクトの新しいバージョンが作成されていると、論理ハイパーリンク手段はターゲットオブジェクトの新規バージョンを動的に参照する。

記憶及び管理システムは、業務アプリケーションプログラミングインタフェース（ＢＡＰＩ）を介して、様々なクライアントアプリケーションと一体化される。クライアントアプリケーションは、システムから物理オブジェクトを検索する時には要求を送り、該要求はシステムからクライアントアプリケーションに返送される。

好適な実施例において、以下に説明するように、知識プロバイダないし情報リポジトリ（ＩＲ）を使用することにより、類似したアクセス特徴を有する大量の文書その他のコンテンツを、ダイナミック、多国籍、かつマルチ・ユーザ環境における管理を促進することができる。ＩＲは基本となる機能的文書管理モジュールであり、様々なクライアントアプリケーションによりアクセスできる。本発明は、一連のアプリケーションプログラミングインタフェースを介して、ほとんど全ての種類のフロントエンドクライアントアプリケーションを補助するために十分な能力と柔軟性を備える。ＩＲは統合されたＷＷＷパブリシング機能を有する。どのような種類のＨＴＴＰクライアントも、ＨＴＴＰを介してコンテンツを検索可能である。コンテンツは、通常のウェブブラウザをクライアントアプリケーションとして機能させるだけでアクセス及び閲覧可能である。ＩＲ管理システムにとって最も重要なことは、論理的ハイパーリンク手段である。これらハイパーリンクは、この場合ウェブサーバによる直接的解決でなく、ＩＲを介して間接的に解決される。論理的ハイパーリンクを辿る時、ＩＲはコンテキスト解決を実行する。ある論理デスティネーションを指し示すハイパーリンクは、現在の言語、フォーマット、コンテンツバージョン、その他のユーザにより定義された、クライアントアプリケーション毎に異なるパラメータに依存して、物理デスティネーションへと解決される。本実施例のＩＲはまた、ＩＲのコンテンツを編集し、物理オブジェクト間の関係を維持するために使用されるオーサリング環境を有する。チェックイン／アウト管理はロッキング手段を提供し、文書自体内の管理情報の維持を通して文書編集を支援する。ＩＲコンテンツはウェブサーバ上でＨＴＴＰアーカイブ内に保存される。ＩＲ内の文書はGUID(Globally Unique Identifiers)により識別される。GUIDは標準化されており、ＩＲとは独立してオフラインで発生される。クライアントアプリケーションは独立して、ＩＲにアクセスする前に、ＩＲ内に保存するためのオブジェクトのIDを発生でき、従ってコンテンツの移動が促進される。

好適な実施例の詳細な説明
図１には知識プロバイダの概念が大まかに示されている。ビューアアプリケーション及びエディタアプリケーション１０２は２つのユーザシナリオを例示している。ユーザはビューアクライアントアプリケーション１０４を介してコンテンツを見ることができ、又はエディタクライアントアプリケーション１０６を介してコンテンツを編集できる。ビューアアプリケーションは典型的にはウェブブラウザであるが、その他のビューアアプリケーションも使用できる。ＩＲ１０８自体がＩＲコンテンツアクセス・管理エージェント１１０を有する。ＩＲコンテンツアクセス・管理エージェント１１０は、ユーザの要求があった場合に管理データ１１４内の設定に従ってコンテンツ記憶手段１１２に対するコンテンツの書き込み及び読み出しを行う。図からわかるように、管理データはコンテンツから明確に分離されている。コンテンツは複数の記憶手段１１６内で分散することができる一方、管理データは一つの中央記憶手段内に置かれる。この方法により、集中的アクセス管理とスケーラビリティーが同時に得られる。

図１Aは実施構造をより詳細に示したもので、ＩＲを使用するクライアントアプリケーションを示す。ＩＲの主な構成要素は図１Aの右側に示してある。ＩＲコンテンツアクセスエージェント１１８とＩＲ管理エージェント１２０は共に図１のＩＲコンテンツアクセス及び管理エージェント１１０として機能する。ＩＲ管理データ１５２はＩＲシステム１２２上でＩＲ管理エージェント１２０と共に存在するが、複数コンテンツ記憶手段１２４，１２６はそれぞれのIRウェブサーバ１２８，１３０上に存在することができる。コンテンツ記憶手段はIRウェブサーバ１２８上に位置する必要はない。図１Aには示されてない別の実施例では、コンテンツ記憶手段１２４，１２６は文書コンテンツサーバの一部を構成することができる。

図１Aの左側には、ＩＲシステム（この場合、独国SAP AG社製のR/3システムとして図示されている）を使用する、アプリケーションを有したアプリケーションシステム１３２が図示されている。ユーザのフロントエンドPC134は、編集のために必要な付加的ＩＲ構成要素１３６を含む。図示の例では、ユーザはグラフィカルユーザインタフェース（GUI）１３８を介してアプリケーションシステム１３２と通信する。ＩＲ文書を表示するために、ウェブブラウザが必要である。編集のためには、通常の構成要素、例えばマイクロソフトワード（マイクロソフト社、ワシントン州）が使用される。さらに、フロントエンドユーザインタフェースとして機能し、ＩＲマネージャと通信するための、特定のIRフロントエンドコンポーネント１４０が必要である。アプリケーションシステム１３２とフロントエンドコンポーネント１３６はいずれも業務アプリケーションプログラミングインタフェース（BAPI；Business Application Programming Interface）１４２を介してＩＲ管理エージェント１２０と通信するが、どのような種類のアプリケーションプログラミングインタフェース（API）でも使用可能である。又は、ＩＲ管理エージェント１２０は、クライアントアプリケーションが置かれたシステム上に位置する必要はなく、BAPIコールはＩＲ管理プロキシ１４４を通して送られる。ＩＲウェブサーバ１２８は、見たり、付加したり、変更したりするためのコンテンツに対する主要なアクセスエージェントとして機能する。

クライアントは標準的なプロトコルHTTP及び／又はファイル転送プロトコル（FTP）を介して、ウェブサーバ上に置かれたHTTPサーバ１４６およびFTPサーバ１４８を介してＩＲウェブサーバにアクセスできる。さらに、ＩＲウェブサーバ１２８はＩＲゲートウェイ１５０を介してＩＲ管理エージェント１２０と通信できる。この実施例では、クライアントは論理コンテンツアクセス情報をＩＲウェブサーバ１２８に送る。ＩＲウェブサーバ１２８はこの情報を、ＩＲ管理エージェント１２０の補助の下で、ＩＲゲートウェイ１５０を介して解決し、コンテンツ記憶手段からファイル検索するために使用できる情報を物理的にアクセスする。管理性および制御性の観点から、データは全てＩＲ管理エージェント１２０を介される。この方法は以下により詳細に説明する。

ＩＲシステム１２２内にＩＲ管理データ１２２が置かれる。ＩＲ管理データは文書の場所、ステータス、アクセス権利、及びそれらの文書間の関係に関する情報を含む。

IR管理システムにおいて本質的な要素は図２に示すような３層構造IRコンテンツモデルである。論理オブジェクト２０２は最上層を構成し、最も一般的な用語で文書的な２進オブジェクトを記述する。実際のコンテンツ、すなわち文書又はオブジェクト自体は、言語、フォーマット、リリース等の付加的属性を有する。文書は特定の言語（英語等）で記述され、特定のフォーマット（ワード、ＰＤＦ、ＨＴＭＬ等）で作成される。これらの属性はユーザが自分の固有の必要に応じてカスタマイズすることができ、前記したものに限定されない。例えば、文書が論理的に何についてかに関するコレクションと呼ばれる属性がある。同一のコレクションに属するデータは全て、１つの論理オブジェクト２０２を介して管理される。論理オブジェクト２０２は不特定数の物理オブジェクト２０４、すなわち同一のコレクション内に同時に存在する全ての文書的２進オブジェクトのメタ記述であるオブジェクトを含む。フォーマットや言語２０６等のメタ情報は一般的に自動的に、該オブジェクトを作成したクライアントエディタアプリケーションから取り込まれるか、又は、ＩＲ自体により自由に定義可能な基準に従って作成することができる。物理オブジェクトは第３層であるコンポーネント２０８への参照を含み、この参照はユーザに対してはトランスペアレントである。コンポーネント２０８は１つの物理オブジェクトに属する個別ファイルを表す。

コンテンツモデルをよりよく理解するために、図３には今説明している概念が例示されている。論理オブジェクト“洗濯機ＸＹＺ”３０２は、物理識別子“ＰＨ＿１”３０４，“ＰＨ＿２”３０６，“ＰＨ＿３”３０８，“ＰＨ＿４”３１０を有する４つの物理オブジェクトを参照する。物理オブジェクト“ＰＨ＿１”，“ＰＨ＿２”，“ＰＨ＿３”が．ｄｏｃｆｉｌｅ（ＭＳＷＯＲＤ）に関連するコンポーネントを参照するのに対して、物理オブジェクト“ＰＨ＿４”は２つのコンポーネント、すなわちＨＴＭＬ(Hypertext Markup Language)ファイルとＧＩＦ(Graphic Image Format)ファイルから構成される。図示の物理オブジェクトは３つの属性３１２，すなわちＩＤ番号、言語及びバージョンを有する。物理オブジェクトの全ての異なる種類のバージョンは１つの物理オブジェクト内にカプセル化されている。

３層コンテンツモデルはＩＲ文書管理システムにおいて中核を成し、それによってユーザは、文書年齢、フォーマット、場所又は言語等の詳細を意識することなく必要な文書をアクセスすることが可能となる。

上述のように、同一ファイルの異なるバージョン及びコンテキスト変化型が同一のコレクション又は論理オブジェクト内に存在可能である。本発明によれば以下に説明するように、ＩＲ文書管理システム内におけるバージョン化方法が提供される。一般的に、作成した文書に変更を加えなければならない場合がある。コンテンツを変化することにより元の文書すなわちオリジナルから派生した新しい文書は、オリジナルの新バージョンと見なすことができる。オリジナルは新バージョンが出来ると古くなるか、又は新バージョンが独立した１つのコンテンツとして確立される。しかし、文書の新バージョンは、文書がドイツ語に翻訳された時にも作成される。この場合、オリジナルは古くならず、引き続いて有効な文書である。新バージョンはこの場合変化型と見なされる。さらに、マルチバージョン化と呼ばれるプロセスにおいてもオリジナル文書の複数のバージョンを作成することが可能である。原理的には、オリジナルからは不特定数のバージョンが作成可能である。バージョン化基準は新バージョンの作成方法を記述する。例えば翻訳によりオリジナルの言語バージョンが作成されたり、ＤＯＣファイルからＨＴＭＬファイルへの変換により、オリジナルのフォーマットバージョンが作成されたりする。

図４にこれらの概念が示されている。第１に、英語で記述されＰＤＦフォーマット４０２を有するオリジナル文書、ＩＲレポートｖ４．０がある。言語バージョンの作成４０４が行われ、ＰＤＦフォーマット４０６のＩＲレポートｖ４．０のフランス語バージョンが生じる。さらに別のフォーマットバージョンが作成され、ＨＴＴＰフォーマット４０８におけるフランス語バージョンのＩＲレポートｖ４．０が生じる。さらに、コンテンツバージョン４１０を作成することもできる。

バージョン化により、ユーザは文書作成及び管理における柔軟性が得られる。しかし、これらの新バージョンは通常、それらを参照するソースに対して問題を生ずる。ＩＲ管理システムの基本的な特徴は、そのコンテキスト解決システムである。上述のバージョン化の考え方は、ある時点において古くなっていないバージョンが複数ある可能性を示唆している。英語で１９９５年にリリースされたアプリケーションシステムにログオンし、ビューアとしてウェブブラウザインストールされているユーザは、典型的な例では英語ＨＴＭＬバージョンの文書を見たいと希望する。図５に示すコンテキスト属性はこの場合、ログオン言語５０２，ビューアアプリケーション５０４、及びアプリケーション５０６のリリースであり、該リリースはコンテキスト解決システム内での使用のためにマッピングされる。図６にはコンテキスト解決場面におけるコンテンツモデルが例示されている。図６の例における論理オブジェクト６０２は“顧客総合売り上げデータ”文書６０４の全てのバージョンのコレクションである。物理オブジェクト６０６はそれぞれ異なるフォーマットの３個のドイツ語ファイル６０８と、それぞれ異なるフォーマットの３個の英語ファイル６１０を有する。コンテキスト解決はユーザの属性に基づいて適切なファイルを呼出す。

これら新バージョンの作成プロセスはマルチユーザ環境において集中的に管理する必要がある。物理を同時に編集して変更を上書きすることのないようにするため、ＩＲシステムは全てのアクセスを図１Ａに示すようなＩＲコンテンツアクセスエージェント１１８を介して制御する。オリジナルに変更を加えようとする書き込み者は全て、このコンテンツアクセスエージェントを通過して自分を登録しなければならない。コンテンツアクセスエージェントはＩＲ管理データ１５２内においてオリジナルのロックを設定し、それによって他のユーザが文書にアクセスすることが防止される。第２のユーザがチェックアウトを実行しようとする時は、コンテンツアクセスエージェントはチェックアウト情報をチェックし、その要求を拒絶する。コンテンツアクセスエージェントにより管理される管理データの他に、ＩＲシステムはフロントエンドに関する管理データ、すなわちローカル管理データを維持する。場所とＩＲオブジェクトＩＤと共にフロントエンドにチェックアウトされる文書のリストは、文書のチェックイン及びチェックアウトの度に更新される。好適な実施例では２つのバージョン化の態様があり、すなわち厳密バージョン化と物理オブジェクトの更新の可能性を伴うバージョン化である。厳密バージョン化では、いったんＩＲ文書管理システムにチェックインされた文書は変更することができないが、新バージョンを明示的に派生するためには使用可能であり、その新バージョン上で作業を行うことができる。図７は厳密バージョン化プロセスのフローチャートである。ユーザはオリジナル文書に変更を加えて新バージョン７０２を作成しようとしている。ＩＲはオリジナル物理オリジナルのコンテンツを有する新物理オブジェクトを作成する７０４。この文書は、すでに別のユーザによりチェックアウト７０８されていない限り、ユーザに対するチェックアウト７０６が生じる。文書がチェックアウトされていなければ、ＩＲにおいてチェックアウトデータの書き込み７１０が行われ、文書のファイルがフロントエンドに転送され、そこでローカルチェックアウトデータと文書のカスタム属性の書き込み７１２が実行される。ユーザは文書に対する作業を終了した後、チェックイン７１４をトリガする。ＩＲは再びステータスをチェックするが、それは、ユーザは今フロントエンドで文書を作成したばかりの誰かであって今チェックインしようとしているのかも知れないからである。これにより、文書がまだチェックインされてないことと、文書が現在チェックアウトされてないことが確認される７１６。チェックが成功すると、文書はフロントエンドからＩＲにコピーされ、グローバル管理データの更新７１８が実行される。最後に、フロントエンドからローカルデータが削除される７２０。

厳密バージョン化においては、頻繁に文書変更が行われるアプリケーションの場合大量のオーバヘッドが生じるため、ＩＲシステムは“物理オブジェクトの更新可能性を有するバージョン化”と呼ばれる第２のバージョン化態様を有する。この態様のバージョン化においてチェックアウトされた物理オブジェクトは、厳密バージョン化において行われるような付加的変更からの永続的保護は行われない。物理オブジェクトをチェックアウト・インするプロセスは、ユーザが明示的に当該バージョンを“凍結”すると決定しない限り、何回でも繰り返すことができる。図８は、この態様のバージョン化を示す。オリジナル文書８０２のチェックアウト８０４，変更８０８，及びチェックイン８０８が可能である。しかし、凍結８１０を実行するときは、新バージョン８１２が作成されなければならない。

これら全ての物理オブジェクトがＩＲシステムに記憶されるに際して、図９に示すような、ＩＲから検索する必要のある（物理又は論理）情報オブジェクトをクライアントアプリケーションが参照する方法（“外部関係”）が必要である。１つの実施例では、クライアントアプリケーションはそれ自体が情報オブジェクトへの参照を管理する。クライアントアプリケーションはＩＲシステムへの要求に対する、情報オブジェクトのＩＤを直接提供する。好適な実施例では、ＩＲ情報オブジェクトを参照するクライアントアプリケーションオブジェクトとＩＲ情報オブジェクト自体との間でマッピングが行われる。この実施例では、Ｒ／３アプリケーション（ＳＡＰＡＧ社）内にある転送キーを使用してアプリケーションオブジェクトを明確に特定することができる。クライアントアプリケーション９０１内にはアプリケーションオブジェクト参照９０２が存在する。このオブジェクトは、ＩＲ管理データ９０６内のＩＲシステム上に置かれた情報オブジェクト参照９０４を参照する。情報オブジェクトは論理オブジェクト９０８か物理オブジェクト９１０のいずれかである。マッピング表９１２はＩＲ自体内に記憶されている。アプリケーションオブジェクト９１５用の転送キー９１４はＩＲシステム上の論理オブジェクト９１６をターゲットとして有する。クライアントアプリケーション９０１は単に、転送キーとコンテキスト（ログオン言語、フォーマット等）をＩＲに送る。ＩＲは適切なファイル９１８を呼出す。

図１と１Ａに示すように、ＩＲのコンテンツはＩＲシステムのデータベース内のみならず複数のコンテンツサーバＩＲ内に分散することができる。上述のように、ＨＴＴＰアーカイブのようなその他の文書サーバを使用することも可能である。ユーザは空間又は構成上の理由から、コンテンツを様々なサーバ間で再分配したいと考えるかもしれない。一般的に、論理的に同一のグループに属する文書グループを再配置する方が、単一の文書の再配置より便利である。また、論理グループを無視して、新しい文書サーバを導入したり、このサーバに全ての新しい文書をチェックインしたりすることによって論理的に同一の文書グループを乱すことは好ましくない。グループ全体を再配置することにより管理が簡略化され、性能が向上する。図１０はＩＲシステム内のファイル場所の管理方法を示す。コンポーネント（すなわちファイル）１００２は物理オブジェクト１００４に属し、該オブジェクトは、コンテンツリポジトリ１００８内に置かれるコンテンツカテゴリー（すなわち論理オブジェクト又はコレクション）１００６にグループ化される。コンテンツカテゴリーはクライアントアプリケーションにより定義される。コンテンツカテゴリーは論理オブジェクトと関連付けることはできないが、それは、物理オブジェクトのバージョンによって様々なコンテンツリポジトリが必要とされるかもしれないからである。コンテンツカテゴリーは文書記憶場所すなわち文書リポジトリの論理記述として機能し、その結果文書はいずれかの記憶場所にまとめて記憶ないし移動できる。コンテンツカテゴリーは物理記憶場所を記述するコンテンツリポジトリ１００８を参照する。ファイルシステムが記憶装置として使用される場合、コンテンツリポジトリ１０１０を含むルートディレクトリが生じる。物理オブジェクトはいずれも、実際のコンテンツ、すなわちファイルを表すコンポーネントを参照する。コンテンツコンポーネントレコード内の場所は、コンテンツリポジトリにより定義される場所に対して相対的である。コンテンツカテゴリーを再配置する時、コンテンツコンポーネントレコードを変化させる必要はない。図１０に示されたファイルパス１０１２は、それがコンテンツリポジトリ１０１０のためにどのように構成されているかを示す。コンテンツリポジトリ１０１０用の絶対的パスと、コンテンツコンポーネントレコード１００２からの相対的パスの他に、パスにはＩＲオブジェクトＩＤが付加される。ＩＲオブジェクトＩＤは一意的であるので、異なる物理オブジェクトのファイルに対して同一のファイルネームが選択された場合に起こり得る命名競合が防止される。

上述の“外部関係”に対して“内部関係”という用語はＩＲシステム内部のオブジェクト間の関係を指す。内部関係はＩＲシステムの中央ＩＲ管理データ内において管理・検索される（図１，１Ａ参照）。内部関係には異なるクラスがある。図１１は好適な実施例におけるＩＲ内部関係の所定のクラスの概要が示されている。バージョン関係１１０２、コレクション関係１１０４，テンプレート関係１１０６，ハイパーリンク関係１１０８、及び構造関係１１１０がある。これらの関係はそれぞれ以下により詳細に説明する。第１はバージョン関係である：上述のように、ある文書から別の文書をオリジナル文書の１バージョンとして派生させることができる。文書とそれに属する全てのファイル及びデータはＩＲ内で物理オブジェクトにより表されるため、物理オブジェクト間にはバージョン関係が存在する。バージョン関係は様々なサブタイプを有し、オリジナルから新バージョンを派生するために適応できる様々な機能に対応する。ユーザはａ）翻訳１１１２を通して新しい言語バージョンを派生する、ｂ）フォーマット変換を通して新しいフォーマットバージョンを派生する、又はｃ）コンテンツ１１１６の編集を通して新しいコンテンツバージョンを派生することができる。ＩＲでは、特定のクライアントアプリケーションの為に、バージョン関係の付加的サブタイプを定義することができる。次の関係クラスすなわちコレクションクラスはすでに定義した。コレクション関係は、文書のコレクションをモデル化した論理オブジェクトと、そのコレクションからの文書を表す物理オブジェクトとの関係である。コレクション関係はコンテキスト解決（以下に詳述）のために評価される。これらの関係を左右するいくつかの規則がある。文書は１つのコレクションにだけ“属する”ことができる（又はどのコレクションにも属さない）。コレクションを表す論理オブジェクトは従ってコレクション内の物理オブジェクトの“所有者”と見なすことができる。物理オブジェクトを所有しない論理オブジェクト（空コレクション）又は、いずれの論理オブジェクトにも所有されていない物理オブジェクト（コレクションに属さない文書）がある。

上述のように、ＩＲにおける文書の概念は書かれたコンテンツに限定されない。文書は例えばグラフィック、記録、ビデオ等でもよい。これらの種類の文書においては、メイン文書のコンテンツをテキストの形で記述した記述文書があると便利である。２つの物理オブジェクト間の記述関係は単に、１つの文書が他の文書の記述であることを意味する。物理オブジェクトにその記述オブジェクトである論理オブジェクトを持たせることも可能である。画像がテキストを含み、該画像が言語に依存している場合、論理オブジェクト間に直接、記述関係を設定すると便利である。そうすることにより、コンテキスト解決手段（以下に詳述）は、両方のコレクションからコンテキストに最も適合する文書を選び出すことができる。

ＩＲシステムはまた、テンプレート関係を有し、特定の種類の文書を頻繁に作成する複数のユーザは作成プロセスにおいて共通のスタート点から開始できる。その目的のため、物理オブジェクトのテンプレートとして物理オブジェクトを作成できる。クライアントが新しい物理オブジェクトを作成する時、クライアントはＩＲに対して、別の物理オブジェクトの１バージョンとして初期物理オブジェクトを作成するよう要求を出す。テンプレート物理オブジェクトが提供されると、ＩＲシステムは自動的に、新しい物理オブジェクトとテンプレートとして機能する物理オブジェクトとの間にテンプレート関係を作成する。

最後に、ハイパーリンク関係が提供される。ハイパーリンクは通常、１つの文書ファイル内の位置から別の文書ファイル内の位置にナビゲートするための汎用手段である。デスティネーション内の位置が特定されない場合は通常、デスティネーションはデスティネーションファイルの最初であることを意味する。ハイパーリンクを含むソースからそのデスティネーションへのナビゲーションは、単にソース内のハイパーリンク表示をクリックすることによりトリガされる。上述したように、文書のバージョン化をシナリオに導入する場合は、ハイパーリンク管理は一転して非常に複雑なプロセスとなる。従って、本発明の目的は論理ハイパーリンクを導入することである。すなわち、ハイパーリンク参照は物理デスティネーションではなく論理デスティネーションを指さなければならない。そうすることにより、ハイパーリンクを追跡する際のコンテキスト解決が可能となる。これにより、コレクションに新バージョンを付加した時にハイパーリンクを変更する必要が無くなるという利点が得られ、この場合、コンテキスト解決により自動的に適時新しいバージョンが選択される。

図１２にはＩＲハイパーリンクシステムの概略が示されている。この機能を可能にするために、ＩＲシステム内の文書内のハイパーリンク参照は直接にはＵＲＬ(Uniform Resource Locator)ファイルを含まない。その代わり、ハイパーリンク参照は論理オブジェクトへの参照を含む。ユーザがハイパーリンクを作動させると、この参照のＩＲウェブサーバ１２０２への、クライアントアプリケーションのコンテキストパラメータを伴う転送１２０４が実行される。しかし、通常のウェブサーバではこれらの参照を解決できないので、ＩＲハイパーリンクは、ＩＲシステムへのゲートウェイ１２０６として機能する拡張アプリケーションへ送られる。ＩＲシステムはコンテキスト解決を実行し、参照へのＩＲハイパーリンク１２０８を、最も適切な物理オブジェクトのファイルへ解決する。解決された論理オブジェクトがコンポーネント自体でなくコンポーネント内の位置を表す場合、リターン参照はさらにタグＩＤを含むことができる．ゲートウェイはＡＳＰ(Active Server Pages)を介して実現される。従って、ＩＲハイパーリンク参照はファイル参照でなくＡＳＰアプリケーションへの参照である。

図１３に示すように、コンテキストコンポーネントすなわち文書自体内のある位置に含まれるＩＲハイパーリンク参照は論理オブジェクト１３０２を参照する。タグ論理オブジェクト１３０４と呼ばれる論理オブジェクトには特定のサブクラスがある。これらオブジェクトは１つ又は複数のコンポーネント内の特定の位置を表す。ＩＲハイパーリンク参照が通常の論理オブジェクトを参照する場合、コンテキスト解決手段は単に適切な文書ファイルのＵＲＬを返送する。物理オブジェクト１３０６が複数のコンテンツコンポーネント１３０８から構成される場合、上位コンテンツコンポーネントのＵＲＬはウェブサーバ（ＧＩＦ画像への参照等）により直接解決される。ＩＲハイパーリンクがタグ論理オブジェクトを参照する場合、論理オブジェクトのＧＵＩＤ１３１０がタグ値として、リターンされるＵＲＬに付加される。従って、文書内の位置へのＩＲハイパーリンク参照を付加する場合は、対応するタグ論理オブジェクトをまず最初にＩＲ内に作成する必要があり、その後そのＧＵＩＤをタグ１３１２としてソース文書内に挿入することができる。

ハイパーリンク関係はまた、物理オブジェクトとＩＲシステム内の対応する論理オブジェクトとの間にも管理できる。このハイパーリンク関係はソースコンテンツコンポーネント内に含まれるハイパーリンクを表す。さらに、ＩＲシステムはフロントエンドにおいてＨＴＴＰファイルをスキャンしそこからＩＲハイパーリンクを抽出するサービスを提供する。ＩＲシステムは自動的にフロントエンドでのスキャンの結果を管理し、この情報を使用して、対応する文書がチェックインされた時にＩＲ管理データへのハイパーリンク参照を書く。

ＩＲシステムにおいて提供される最後の関係は構成関係である。特定の文書を検索する典型的な方法の１つは、ファイルシステムや図書館のような階層構造内をドリルダウンしていく方法である。ユーザはコレクションが存在するセクションに行き、そのコレクション内の全てのブックの場所を突き止めることができる。この種の関係がＩＲシステム内に設けられており、クライアントアプリケーションは文書を分類し後に検索することのできる上述のような階層構造を作ることができる。

図１４には構成関係概念が示されている。コレクション関係は物理オブジェクトとしてモデル化され、論理オブジェクト１４０２のコレクション内に含まれる。少なくとも１個のルート論理オブジェクトをクライアントアプリケーション１４０４により参照しなければならない。物理オブジェクトは論理オブジェクト１４０６に対して構成関係を有することができる。このようにして複数レベルの入れ子構造を作ることができる。１人のユーザは通常固定コンテキスト１４０８において作業する。図１４では、言語以外の全てのコンテキストは例示のため省略されている。第１英語物理オブジェクト１４１０は構造的に、下位論理オブジェクト内に入れ子構造として存在する第２と第３英語物理オブジェクト１４１２に関連付けられている。

上述した関係の種類は全てのユーザアプリケーションに対して常に十分であるとは限らない。例えば、文書を含むシェルフやフォルダの概念を導入したいとアプリケーションがあるかも知れない。シェルフはフォルダを含むことができるが、直接文書を含むことはできない。従って、アプリケーションがそれ自体の特定の関係クラスと、情報オブジェクトのクラスを定義するための手段が必要とされる。新しい関係クラス毎に、それは図１５に示すようにこの関係クラスに関係タイプを割り当てなければならない。関係クラスの関係タイプは転送特性と、関係パートナーに対する存在従属を定義する。さらに、アプリケーションが新しい関係クラスを使用できる前に、アプリケーションはどの情報クラスが図１６に示すような関係に参加できるかを定義しなければならない。この目的で、複数妥当性レコードが定義され、それら１つ１つが１つのソース情報クラス１６０２、１つのデスティネーション情報クラス１６０４，及び１つの関係クラス１６０６の組み合わせの妥当性を検査する。２つの情報オブジェクトと、関係を形成する１つの関係オブジェクトの個々の構成が、１個だけの妥当性検査レコード１６０８により検査される。関係クラスが許可されるかどうかは常に情報により定義される。

情報クラスとオブジェクト間の関係のために、付加的な関係タイプが導入され、それによって図１７に示すようにアプリケーションは柔軟に、情報クラスと情報オブジェクト間の関係のための関係クラスを導入することができる。クラス−オブジェクト関係は例えば、テンプレート関係クラスと協働して使用できる。クライアントアプリケーションは、“モデリング・リポート”と命名されたオブジェクト用に特定の情報クラス１７０２を導入できる。情報クラスは、共通の特定の態様で扱うべき全ての文書をグループ化する。この例では、共通の特性は、文書が当初、同一のテンプレートから作成されるということである。クライアントアプリケーションは次に、例えば“クラステンプレート関係”１７０４と呼ばれる関係タイプクラス−オブジェクトを有する関係クラスを導入する。対応する関係１７０８は、情報クラス１７０２“モデリングリポート”と、情報クラスのクラステンプレート１７０６として機能する情報オブジェクト間に設定される。

例として、情報クラスを有したデータモデルと関係クラスを使用する。ＩＲシステムにアクセスする必要のある新しいクライアントアプリケーションはいずれも、まず最初にその特定のデータモデルを設計する必要がある。図１８には、ＩＲシステム内の構造関係を通してモデル化された情報の構造を示す。ＩＲは“ルート”物理オブジェクト１８０２と“ブック”物理及び論理オブジェクト１８０４を含む。ブックとトピックス１８０６のために、物理及び論理オブジェクトの両方が導入されるが、それはいずれもバージョン化されるからである。図１９は通常のデータモデルを示す。トピックス用の物理オブジェクトの異なるフォーマットのために、個別の情報クラスが導入されている。このようにして、HTML文書が常にWORD文書から派生されるようにモデル化することができる。所定の関係クラス、コレクション、ハイパーリンク、構造、言語、フォーマット、及びコンテンツが使用される。所定の関係クラスに対しては、例示したデータモデルは、ソースとして又はデスティネーションとして、関連するクラスの関係内に参加できる情報クラスを定義する。例えば、情報クラスIWB_SRCTXT１９０２がフォーマットバージョン関係のソースとして生じる一方、情報クラスIWB_DSTTXT１９０４がデスティネーションとして生じる。例示のデータモデル内ではトピックスの特定のバージョンがある。これらバージョンはコンテンツバージョンとして設定されるため、アプリケーション個別関係クラスを導入する必要は無い。対応関係はその代わり、コンテンツ関係としてモデル化され、デスティネーションオブジェクトは、それがコンテンツバージョンであることを示す特定の属性を有する。

次に、別のシナリオを用いて本発明の動作をより詳細に説明する。以下の説明の目的は、コンポーネントが原理的に協働してどのように作用するかの概略を説明することであり、引き続いて、より内部の詳細とインタフェースの詳細を説明する。このシナリオでは、ＩＲシステムのユーザはウェブブラウザを介してコンテンツを見る。そのために、スタート点としてＩＲＵＲＬが必要である。コンテンツを表示するために、ＩＲは図２０に示すように、オブジェクトＩＤとコンテキスト２００２からＩＲＵＲＬを作るための特定のサービスを提供する。オブジェクトＩＤはＩＲオブジェクトにリンクされたアプリケーションオブジェクトのＩＤか、又はＩＲオブジェクトのＧＵＩＤである。ブラウザコーラーは、クライアントアプリケーションがフロントエンド２００４上でのＵＲＬのコンテンツを見ることを可能にするサービスを提供する。次に、ウェブブラウザはHTTP要求２００６をHTTPサーバ２００８に送る。IR URLは全て、以降の処理のためにIRゲートウェイ２０１０に送られる。アプリケーションシステムからトリガされた要求の場合には、コンテキストはIR URLに符号化され、IRゲートウェイはコンテキスト２０１２を抽出し、HTTPサーバに対して、該コンテキストをクライアント側２０１４のクッキー内に記憶するよう命令する。IRゲートウェイはまた、URL２０１６からオブジェクトIDを抽出する。その後、IRゲートウェイはIR管理エージェントにオブジェクトIDを解決するよう要求する。このステップではコンテキスト解決が行われる。また、アクセス権のチェックが行われる場合もある。ブラウザへのファイルの転送２０１８がHTTPサーバにより行われる。そして、ブラウザはファイルの表示２０２０を実行する。

チェックアウト／編集シナリオでは、フロントエンドで付加的なコンポーネントが必要とされる一方、先行のブラウジングシナリオでは、標準的なコンポーネントのみが必要とされる。図２１にはこのシナリオに要するコンポーネントが示されている。フロントエンド上のコンポーネントは、エンドユーザにより直接アクセスされるコンポーネントとその他のコンポーネントに分けられる。その他のコンポーネントのほとんどは、フロントエンドにおけるIR機能性を提供する。図の左側には編集アプリケーション、この場合ＭＳワード２１０２が示されている。IRコントローラ２１０４はフロントエンドにおいてIRシステムにインタフェースを提供し、フロントエンド上のIRオブジェクトのアクセス及び管理のためのサービス機能を提供する。IRコントローラは、クライアントアプリケーションとその個別のエディタアプリケーションがIRオブジェクトとオフラインで協働することを可能にする。IRコントローラはフロントエンド上で管理データをその他のIRフロントエンドコンポーネント、例えばIRCiCo２１０６とHTMLパーサ２１０８と共有する。管理データは“Ｒ３Ｌ−オブジェクト”と呼ばれるものの中に記憶される。１個のＲ３Ｌオブジェクトが、論理オブジェクト用の管理データとフロントエンド上の含まれた物理オブジェクトを含むファイルに対応する。Ｒ３Ｌオブジェクト内に含まれたデータはエディタアプリケーションにより、図２２に示すようなＩＲコントローラへのクライアントインタフェースにおいて表される、対応オブジェクトモデルを介してアクセス可能である。フロントエンド上の全ての管理データは、ＩＲコントローラにより実現されるＩＲインタフェースオブジェクト２２０２を介してアクセスされる。ＩＲインタフェースオブジェクトは１つ又は複数のパッケージ２２０４を参照する。パッケージは、共通の目的のためにフロントエンドにチェックアウト又はコピーされたオブジェクトの、クライアントアプリケーションにより定義されたグループである。パッケージ２２０４は複数の論理オブジェクト２２０６と物理オブジェクト２２０８ＩＲを含む。個々の論理オブジェクトに対して、ＩＲ管理データ内でクライアント関連２２１０であるとしてマークされた特性が記憶される。タスクネーム２２１２、及びタスクに関連した物理オブジェクトが記憶される。物理オブジェクトに対して管理されたデータは全て、物理オブジェクトがチェックアウトされた時に、中央ＩＲ管理データに書き込まれる。論理オブジェクト用のデータはフロントエンド上で変更することはできない。図２１では、エディタドライバ２１１０は、フロントエンドアプリケーションをＩＲコントローラにインタフェースするためのオプショナル接続ソフトウェアコンポーネントである。技術的理由でＩＲコントローラインタフェースを直接利用することができないアプリケーションに対しては、対応コンポーネントが必要である。ＨＴＭＬパーサ２１０８は文書をＨＴＭＬフォーマットにパースし、それらに埋め込まれたリンクとタグを抽出する。対応関係情報はＲ３Ｌオブジェクトと共に記憶され、チェックインの際に中央ＩＲ管理に書き込まれる。ＩＲＣｉＣｏ（チェックイン／チェックアウト）２１０６コンポーネントは要求によりＩＲシステムから文書を出し入れできる。ＩＲＣｉｃｏはまた、Ｒ３Ｌオブジェクト内に記憶された情報を中央ＩＲ管理データとの間で転送することができる。プロパティーＯＣＸ２１１２は構造形記憶を支援する文書内の情報を記憶するために使用される。情報は文書のカスタムプロパティーに書き込まれる。例えば、文書を特定する情報は外部トランスレータに送られる前にここに書かれる。これにより、正しい自己同一性に基づいて、後の文書の自動的チェックインを行うことができる。フロントエンド上には、特定のクライアントアプリケーションに特定の複数のコンバータ２１１８がある場合がある。それらは標準的ＩＲコンポーネントではない。それらは、対応する標準エディタのフォーマットと、クライアントアプリケーションにより定義された内部フォーマットとの間の変換を行う。

図２３は文書をチェックアウトする時に生ずるコンポーネント間の通信の概要を示す。ＩＲコントローラは以下のステップを実行する。選択２３０２は、どの１つ（又は複数）の論理オブジェクトをチェックアウトするかに関する。要求２３０４は、対応する物理オブジェクトのためにＩＲＢＡＰＩとＩＲマネージャプロキシ１４４を介してＩＲ管理エージェント１２０に送られる。チェックアウトする必要のある物理オブジェクトの選択２３０６が行われる。最後に、ＩＲＢＡＰＩを介してチェックアウトすべきオブジェクトのステータスに関するチェック２３０８が行われる。そして、チェックアウトすべき個々の物理オブジェクトに対して１個のフォルダの作成２３１０がＩＲＣｉＣｏによって実行される。その後、要求２３１２がＩＲ管理エージェント１２０に送られ、個別の物理オブジェクトに関してチェックアウトを実行するよう要求する。ＩＲマネージャはアクセス権を検査し、場所を検索し、アプリケーション上でＢＡＰＩをトリガしてファイルのフロントエンドへの転送２３１４を実行する。１つの物理オブジェクトに属するいずれかのファイルにエラーが生ずれば、ＩＲＣｉＣｏは、物理オブジェクト全体をチェックアウトすることができないことを示すリターンコード１４１４を受け取る。物理オブジェクトのチェックアウトが成功すると、ＩＲコントローラはオブジェクトＩＤ等の情報をプロパティーＯＣＸのカスタムプロパティーに書き込む。最後に、ＩＲコントローラは適切なエディタアプリケーション２３１８（この場合ＭＳワード）を呼出す。

チェックインシナリオに関しては、ファイルが逆の順番で転送され、ファイル転送の前にプロパティーＯＣＸが文書プロパティーを読み取り削除し、フロントエンド上のファイルがチェックアウトの成功の後削除されることを除けば、チェックアウトシナリオと同一である。

以上、本発明の実施例における基本的な新規な構成要件を説明したが、発明の要旨から外れることなく形式的又は詳細部分について様々な省略、置換ないし変更が可能であることは当業者に明らかである。実質的に同一の方法において同一の結果を得ることのできる要素及び／又はステップの全ての組み合わせは本発明の範囲内に含まれる。従って、本発明は以下の請求の範囲によってのみ制限されるものである。

知識プロバイダの全体を示す図である。知識プロバイダの詳細を示す図である。知識プロバイダの詳細を示す図である。３層構造ＩＲコンテンツモデルを示す図である。３層構造ＩＲコンテンツモデルの一例である。バージョン化の概略を示す。典型的なコンテキスト属性の例を示す。コンテキスト解決場面におけるコンテンツモデルを示す。図７．１と７．２の組み合わせを示す図である。厳正バージョン化を伴うチェックアウト／インのフローチャートである。厳正バージョン化を伴うチェックアウト／インのフローチャートである。物理オブジェクトのアップデートを伴うバージョン化のフローチャートである。ＩＲシステムの外部関係モデルを示す。図１０．１〜１０．４の組み合わせを示す図である。ＩＲシステムにおけるファイル位置の管理方法を示す。ＩＲシステムにおけるファイル位置の管理方法を示す。ＩＲシステムにおけるファイル位置の管理方法を示す。ＩＲシステムにおけるファイル位置の管理方法を示す。好適な実施例におけるＩＲ内部関係の所定のクラスの概略を示す。ＩＲハイパーリンク解決の概略を示す図である。ハイパーリンク手段のデータモデルを示す図である。構造関係概念を示す概略図である。関係型の表である。妥当性検査方法を示す図である。テンプレート関係における典型的な動作シーケンスのフローチャートである。構造関係のためにＩＲシステムにおいて使用されるモデルの一例である。３層構造コンテンツモデルに基づいたアプリケーション別コンテンツモデルを示す図である。図２０．１〜２０．４の組み合わせを示す図である。ブラウジングシナリオにおける各構成要素間の連絡を示す図である。ブラウジングシナリオにおける各構成要素間の連絡を示す図である。ブラウジングシナリオにおける各構成要素間の連絡を示す図である。ブラウジングシナリオにおける各構成要素間の連絡を示す図である。編集シナリオのために必要な構成要素を示す。編集シナリオのために必要な構成要素を示す。Ｒ３Ｌオブジェクト用のオブジェクトモデルを示す。チェックアウト／編集シナリオにおける各構成要素間の連絡を示すフローチャートである。チェックアウト／編集シナリオにおける各構成要素間の連絡を示すフローチャートである。チェックアウト／編集シナリオにおける各構成要素間の連絡を示すフローチャートである。チェックアウト／編集シナリオにおける各構成要素間の連絡を示すフローチャートである。

Claims

物理記憶場所に記憶されたファイルを定義し、管理する方法であって、
（ａ）前記ファイルを表すコンポーネントを参照する少なくとも一つの物理オブジェクトを作成するステップと、
ただし前記ファイルはコンテンツコンポーネントレコードを形成する、
（ｂ）コンテンツリポジトリにおける絶対パスを定義するステップと、
ただし、前記コンテンツリポジトリは前記物理ファイルの記憶場所の論理記述を提供し、前記コンテンツリポジトリを言及する少なくとも一つのコンテンツカテゴリーを含む、
（ｃ）前記複数のファイルを前記コンテンツカテゴリーにグループ化するステップと、
（ｄ）前記コンテンツコンポーネントレコードに基づき前記絶対パスに相対する相対パスを定義するステップと、
（ｅ）一意的なオブジェクトＩＤを作成するステップと、
（ｆ）前記コンテンツリポジトリのための前記絶対パスと前記コンテンツコンポーネントレコードのための前記相対パスとに、前記オブジェクトＩＤを加えるステップと、
を有することを特徴とする方法。