JP2011503734A - 記述論理ファイル・システムを用いて情報を格納する方法、システムおよびコンピュータ・プログラム - Google Patents

Abstract

【課題】データ処理システムにおいて情報を格納するための解決策を提案する。
【解決手段】関連する方法は、ファイル・システム・マネージャ（データ処理システムの大容量メモリ上の複数の実ファイルを編成するようになっている）の知識ベースを提供するステップ（Ａ１〜Ａ２）から始まる。知識ベースは（所定のオントロジに従って）、概念のセットと、概念間の関係のセットと、各実ファイルを少なくとも１つの概念のインスタンスとして記述する包含の関係のセットとを含む知識の集合を定義する。選択されたインスタンスのセットにアクセスするために、ファイル・システム・マネージャにコマンドが出される（Ａ５〜Ａ６）（例えば、対応する仮想フォルダおよびファイルのグラフィック表現を介して）。本方法は、選択されたインスタンスによって記述されている選択された実ファイルのセットを（知識に従って）特定すること（Ａ７〜Ａ１１）によって続く。次に、選択された実ファイルが、大容量メモリ上でアクセスされる（Ａ１３）。
【選択図】図１１

Description

本発明は、情報技術の分野に関する。特に本発明は、データ処理システムにおける情報の格納に関する。

データ処理システム（コンピュータなど）は、大量の情報を格納するために広く使用されている。典型的には、情報は複数のファイルに配置され、ファイルはそれぞれ、コンピュータの大容量メモリに格納された情報のブロックから成り、情報のブロックはそのユーザによって個別にアクセス可能である。

ファイルは、コンピュータのオペレーティング・システムによって制御されるファイル・システムにおいて編成される。当技術分野において既知であるファイル・システムは、ほぼすべて階層構造を有する。詳細には、ファイルがコンテナ（一般にフォルダまたはディレクトリと呼ばれる）に含まれ、さらにフォルダが、コンピュータの（物理的または論理的）デバイスを定義するルート・フォルダから始まるツリーにおいて関係付けられる。

ファイル・システムは、コンピュータ上のファイルの論理的管理を促進する。実際に、まず各ファイルの名前が、その特徴について何らかの情報を提供する。さらに、同じフォルダ内のファイルはすべて、対応するカテゴリを定義する共通の特徴を共有する傾向にあり、これはフォルダの名前によって何らかの形で特定される。さらに、ファイルのカテゴリの異なるレベルが、フォルダの階層によって定義されることもある。例えば、全顧客に関するフォルダがあり、それに、特定の顧客に関するさらなるフォルダが従属し、このフォルダそれぞれが、対応する顧客に関するすべてのファイルを（その顧客との具体的な通信を格納する各ファイルと共に）含むことが可能である。

しかし、この方法では、ファイルの特徴は完全に変則的な形でしか定義できない（ファイルおよびフォルダの名前によって）。したがって、この情報は一般に、ソフトウェア・アプリケーションによる利用が不可能である。

さらに、フォルダ内のファイルの編成は（特定の階層が選択されてからは）、事実上固定され、変更するのが難しい。詳細には、各ファイルが単一のフォルダに属する。他のフォルダの中に同じファイルへのリンクを作成することも可能である。しかしこれは、（その、他のフォルダの名前により）ファイルにさらなる特徴を追加することを可能にするのみであるとはいえ、ファイルの一意性という概念を乱し、ファイルの編成が非常に管理しにくくなる。いずれにせよ、フォルダが、ファイル間の関係を（フォルダ内へのその包含によって定義される基本的な関係のほかに）表せるようにすることはない。

別の手法が、米国特許第７，１４９，７２９（Ｂ）号明細書にて開示されている（その開示全体を参照によって本願明細書に引用したものとする）。この文献は、ファイルに関連するメタデータ（ファイルを記述することを目的としている）を利用して、そのアクセスを促進する。このために、（物理的）フォルダにおけるファイルの実際の編成ではなく、そのメタデータに基づくファイルの種々のビューを公開する、仮想フォルダが提供される。さらに具体的には、すべてのファイルのメタデータがデータベースに格納され、フィルタリング基準（ファイルの対応するカテゴリを定義する）に一致するファイルを読み出すためにデータベースに問い合わせるべく使用されるフィルタリング基準により、各仮想フォルダが定義される。仮想フォルダ内のファイルは、標準のコマンド（コピー、移動、削除および同様のものなど）を用いて操作することができ、これは、それに応じて関連のあるメタデータに作用することによって実行される。例えば、ファイルが仮想フォルダに付属させられると、そのメタデータが自動的に更新される。反対に、ファイルを削除するときは、ユーザは、大容量メモリからそれを物理的に消すこと、または仮想フォルダからそれを論理的にのみ除去すること（単に、対応するメタデータの更新を伴う）を選択することができる。

しかし、上述の解決策は、全く問題がないものではない。詳細には、ファイルは（仮想フォルダにおいて）メタデータで明白に定義されている明確な特徴によってしかフィルタリングすることができない。

さらに、種々の仮想フォルダにあるファイルの特徴の、論理的一貫性を強制することはできない。例えば、ロックの歌を格納するファイルのメタデータにおいて、その作者は（正確に）ロック・バンドであるがそのジャンルが（誤って）クラシック音楽であると指定することを防ぐものはない。この場合、ファイルは誤ってクラシック音楽の仮想フォルダに含まれることになるであろう（対応するフィルタリング基準に基づくクエリの結果として）。

本提案は、全般的に、オントロジをファイル・システムに適用するという発想に基づく。

特に、本発明の種々の側面は、独立請求項に記載されている解決策を提供する。本発明の有利な実施形態は、従属請求項に記載されている。

さらに具体的には、本発明の側面は、データ処理システムにおいて情報を格納する方法を提案する。本方法は、ファイル・システム・マネージャ（データ処理システムの大容量メモリ上の複数の実ファイルを編成するようになっている）の知識ベースを提供するステップから始まり、知識ベースは（所定のオントロジに従って）、概念のセットと、概念間の関係のセットと、各実ファイルを少なくとも１つの概念のインスタンスとして記述する包含の関係のセットとを含む知識の集合を定義する。選択されたインスタンスのセットにアクセスするために、ファイル・システム・マネージャにコマンドが出される（例えば、対応する仮想フォルダおよびファイルのグラフィック表現を介して）。本方法は、選択されたインスタンスによって記述されている、選択された実ファイルのセットを（知識に従って）特定することによって続く。次に、選択された実ファイルが、大容量メモリ上でアクセスされる。

実ファイルは、所定の論理的推論規則（ｌｏｇｉｃａｌ ｉｎｆｅｒｅｎｃｅ ｒｕｌｅ）を適用することによって知識から推論される、さらなる知識にも従ってアクセスされることが好ましい。

さらに、選択されたインスタンスを操作する（知識の対応する更新を伴う）さらなるコマンドを出すことも可能である。

例えば、選択されたインスタンスがターゲット概念に追加されると、選択された各インスタンスの、ターゲット概念への包含の関係が表明される。

選択されたインスタンスの、さらなるターゲット概念からの弱い削除（ｗｅａｋ ｄｅｌｅｔｉｏｎ）もサポートされる（対応する関係それぞれの除去のみを伴う）。

該さらなるコマンドは、選択された実ファイル（上記で、選択されたインスタンスにより記述されたものとして知識に従って特定された）の変更も伴うとよい。

例えば、選択されたインスタンスを、別のターゲット概念から強く削除する（ｓｔｒｏｎｇｌｙ ｄｅｌｅｔｅ）ことが可能であり、これは選択された各インスタンスおよびそれを含む各関係を除去すること、ならびに対応する実ファイルそれぞれを大容量メモリから消すことを伴う。

さらなる改善として、提案されるこの解決策は、知識に対し要求される任意の更新の論理的一貫性の検証も行う。

それに応じて（要求される更新の強制を可能にするよう）知識を訂正することもできることが好ましい。

提案される実装では、ファイル・システムの表現を表示するために、仮想フォルダおよび仮想ファイルは、それぞれ概念およびインスタンスに関連付けられる。

典型的には、ファイル・システム・マネージャに出されるコマンドが傍受され（例えば、フッキング技術を用いて）、続いて推論エンジンへ転送される。

特定の実装では、概念は階層的タクソノミに準拠する。

知識は、記述論理言語を用いて表されると有利である。

提案される実装では、知識ベースは実ファイルから独立して格納される。

本発明の別の側面は、上記の方法を実行するコンピュータ・プログラムを提案する。

詳細には、コンピュータ・プログラムは、仮想ファイル・システム・マネージャに含まれるとよい。

さらに、仮想ファイル・システム・マネージャは、オペレーティング・システムに組み込まれるとよい。

本発明の別の側面は、対応するシステムを提案する。

単に非限定的な指示として与えられ、添付の図面と併せて読むべきである以下の詳細な説明を参照することで、本発明自体、ならびにそのさらなる機能および利点が最もよく理解される。

本発明の実施形態による解決策を実践するために使用することができるコンピュータの概略ブロック図である。 本発明の実施形態による解決策の適用例である。 本発明の実施形態による解決策の適用例である。 本発明の実施形態による解決策のさらなる適用例である。 本発明の実施形態による解決策のさらなる適用例である。 本発明の実施形態による解決策のさらなる適用例である。 本発明の実施形態による解決策のさらなる適用例である。 本発明の実施形態による解決策のさらなる適用例である。 本発明の実施形態による解決策の別の適用例である。 本発明の実施形態による解決策の別の適用例である。 本発明の実施形態による解決策を実装するために使用されるとよい種々のソフトウェア・コンポーネントの役割を表現するコラボレーション図である。

図１を詳しく参照すると、コンピュータ１００（例えばＰＣ）の概略ブロック図が示されている。コンピュータ１００は、システム・バス１０５に並列接続されているいくつかのユニットによって構成されている。詳しくは、１つ以上のマイクロプロセッサ（μＰ：ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）１１０が、コンピュータ１００の動作を制御し、ＲＡＭ１１５が、マイクロプロセッサ１１０によってワーキング・メモリとして直接使用され、ＲＯＭ１２０が、コンピュータ１００のブートストラップ用の基本コードを格納する。いくつかの周辺ユニットが、ローカル・バス１２５の周りに集合している（それぞれのインターフェースを介して）。詳細には、大容量メモリが、１つ以上のハード・ディスク１３０、およびＣＤ−ＲＯＭ１４０を読み取るドライブ１３５から成る。さらに、コンピュータ１００は、入力ユニット１４５（例えば、キーボードおよびマウス）ならびに出力ユニット１５０（例えば、モニタおよびプリンタ）を含む。コンピュータ１００をネットワーク（図示せず）に接続するためにアダプタ１５５が使用される。ブリッジ・ユニット１６０は、システム・バス１０５と、ローカル・バス１２５とをインターフェースで接続する。各マイクロプロセッサ１１０およびブリッジ・ユニット１６０は、情報を送信するためにシステム・バス１０５へのアクセスをリクエストするマスタ・エージェントとして動作することができる。アービタ１６５は、相互排除を伴うシステム・バス１０５へのアクセスの許可を管理する。

コンピュータ１００は、その大容量メモリ１３０、１４０に格納されているファイルを編成するため（コンピュータ１００のユーザがそれにアクセスするよう）に使用される、ファイル・システムを実装する。以下で詳しく記載する、本発明の実施形態による解決策では、このファイル・システムはオントロジに基づく。

オントロジは、対象のドメインの包括的なエンティティのセマンティックを記述するための形式仕様である（すなわち、その意味を曖昧でない形で）。オントロジに従って記述することができるエンティティが、ドメインの論議領域を定義する。一般に、オントロジはエンティティの抽象ビュー（それらの間の同じ種類の共通性をとらえるように、その細部を無視することで簡素化される）を提供する、ある種の概念化に基づき、その結果、このエンティティを、オントロジに準拠する具体的なデータ構造を用いて記述することができる。

多くのオントロジは、インスタンス、概念、属性および関係を定義する。インスタンスは、具体的な物（有形または無形）から成り、これは、あらゆるオントロジの最終的な目標として記述される（例えば、特定の乗用車のインスタンス「ＭｙＣａｒ」）。概念は、インスタンスの抽象的集合である（例えば、すべての乗用車の概念「Ｃａｒ」）。属性は、情報片であり（一般に、名前／値のペアの形である）、属性が適用されるインスタンスまたは概念を規定するために使用される（例えば、インスタンス「ＭｙＣａｒ」の属性「Ｃｏｌｏｒ＝Ｒｅｄ」、または概念「Ｃａｒ」の属性「ＮｕｍｂｅｒＯｆＷｅｅｌｓ＝４」）。最後に、関係は、１つ以上のソース・タームを１つ以上のターゲット・タームに関連付ける。最も重要なタイプの関係は、関係「ｉｓ−ａ」であり、これは、ソース・インスタンス／概念が、ターゲット概念に含まれることを規定する。関係「ｉｓ−ａ」は、特定のオントロジを定義できるようにし（タクソノミとして既知である）、対応する概念によって定義されるカテゴリへとインスタンスを分類するために使用される。典型的には、タクソノミは階層構造を有し、概念は、関係「ｉｓ−ａ」によってツリー構造に編成され、ツリーのルート概念に至るまで親概念に含まれる（例えば、概念「Ｂｉｋｅ」および「Ｃａｒ」を含む概念「Ｖｅｈｉｃｌｅ」）子概念（対応するインスタンスを含む）を備える。

特定の概念の定義から、または特定の関係（オントロジに従って実際のエンティティを記述する）の表明から成る事実（すなわち、常に真である節）は、ドメイン上の知識を定義し、これは知識ベースに集められる。この場合、論理的推論に基づく推理（ｒｅａｓｏｎｉｎｇ）により既存の知識からさらなる知識が得られることもあるため、知識ベースは標準のデータベースとは異なる。論理的推論は、論理的推論規則（新たな事実を取得するために利用可能な事実がどのように組み合わされるべきかを定義する）を適用することによって、利用可能な事実から新たな事実を取得するプロセスである。

知識ベースは、種々の形式言語によって表され得る（オントロジに従って）。典型的な例は記述論理（ＤＬ：Ｄｅｓｃｒｉｐｔｉｏｎ Ｌｏｇｉｃ）言語であり、その名前は、論理に基づくセマンティックの適用に由来している。各ＤＬ言語の構文は、インスタンス名、概念名、役割名、属性名、コンストラクタ、内包表明（ｉｎｔｅｎｓｉｏｎａｌ ａｓｓｅｒｔｉｏｎ）および外延表明（ｅｘｔｅｎｓｉｏｎａｌ ａｓｓｅｒｔｉｏｎ）を含むタームにより定義される。インスタンス名はインスタンスを表現し、概念名は概念を表現し（すべてのインスタンスにより構成される標準の概念「Ｔｏｐ」、およびインスタンスがない標準の概念「Ｂｏｔｔｏｍ」がある）、役割名は関係を表現し、属性名は属性を表現する。コンストラクタ（共通部分、和集合、否定、逆数、および同様のものなど）は、より単純なターム（概念名または役割名）を、より複雑なタームへと組み合わせるために使用される。例えば、コンストラクタ「Ｃａｒ∩∃ｈａｓＦｏｌｄｉｎｇＲｏｏｆ」は、「ＣｏｎｖｅｒｔｉｂｌｅＣａｒ」の概念を、折りたたみ式ルーフを有する（属性「ｈａｓＦｏｌｄｉｎｇＲｏｏｆ」が表明されている）乗用車（概念「Ｃａｒ」に含まれている）として定義する。内包表明は、概念間の関係を表す。例えば、内包表明「Ｃａｒ⊆Ｖｅｈｉｃｌｅ」は、概念「Ｃａｒ」が概念「Ｖｅｈｉｃｌｅ」に含まれることを規定する。最後に、外延表明は、インスタンスおよび他のインスタンス、概念または役割の間の関係を表す。例えば、外延表明「ＭｙＣａｒ ｂｅｌｏｎｇｓＴｏ ＭｙＰｅｒｓｏｎ」は、インスタンス「ＭｙＣａｒ」がインスタンス「ＭｙＰｅｒｓｏｎ」によって使用されることを規定し、外延表明「ＭｙＣａｒ ｉｓ−ａ Ｃａｒ」は、インスタンス「ＭｙＣａｒ」が概念「Ｃａｒ」に含まれることを規定する。従来、ＤＬ言語は、用語ボックス（ＴＢｏｘ：Ｔｅｒｍｉｎｏｌｏｇｉｃａｌ Ｂｏｘ）と表明ボックス（ＡＢｏｘ：Ａｓｓｅｒｔｉｏｎａｌ Ｂｏｘ）とを区別する。ＴＢｏｘは、実質的に、所望のエンティティの概念化を表現する（すなわち、一種のデータのスキーマ）。このために、ＴＢｏｘは、概念、役割、属性および内包表明を含む。一方、ＡＢｏｘは、実質的に、この概念化を実際に明示するエンティティを表現する（すなわち、データそのもの）。このために、ＡＢｏｘは、インスタンスおよび外延表明を含む。この識別は重大ではないが、ＤＬ言語で表される知識ベースの定義および管理を促進する。

本発明の実施形態による解決策では、所定のオントロジに準拠して知識の集合を定義する知識ベースを用いてファイル・システムが記述される。さらに具体的には、知識は概念、概念間の関係、および各ファイルを１つ以上の概念のインスタンスとして記述する包含の関係を含む。選択されたインスタンスのセットにアクセスするためにファイル・システム・マネージャに出される各コマンドについて、選択されたインスタンスによって記述されている対応する選択されたファイルが、知識に従って特定され、その結果、この選択されたファイルが大容量メモリ上でアクセス可能である。

提案される解決策は、正式な方法で、さらに曖昧さなしで、ファイルのセマンティックを定義できるようにする（オントロジに従って）。さらに、これによって、ファイル・システム上で高度なセマンティック推理（ｓｅｍａｎｔｉｃ ｒｅａｓｏｎｉｎｇ）を実装できるようになる。

なお、所望の解決策はファイル・システム自体に組み込まれ、その結果ファイル・システムが直接、知的行動を示す。

ファイル・システムのこの能力は、ユーザによって利用されるとよい（対応するインスタンスが含まれている概念に従ったファイルの自動分類の利点がある）。さらに、同じ能力が、追加設定なしのソフトウェア・アプリケーションによって活用されることも可能である。

ここで図２に移る。本発明の好適な実施形態では、知識ベースはＤＬ言語を用いて表される。特定のＤＬ言語を選択することで、記述的能力と推理の複雑さとの、対立する要件間の望ましいトレードオフを可能にすることができる（提案される解決策はいかなる特定のＤＬ言語にもまったく制約されないが）。

詳細には、ＴＢｏｘは、標準の概念「Ｔｏｐ」および「Ｂｏｔｔｏｍ」、ならびにすべてのファイルの概念「ＳｔａｎｄａｒｄＦｉｌｅ」を含む。その結果、ユーザは、さらなるカスタム概念（概念「ＳｔａｎｄａｒｄＦｉｌｅ」に含まれる）、役割、属性および内包表明を定義することができる。その結果、ユーザは、コンピュータの大容量メモリに格納されている各ファイルを１つ以上の概念（すべてのファイルは常に少なくとも概念「ＳｔａｎｄａｒｄＦｉｌｅ」のインスタンスとして記述される）のインスタンスとして記述する外延表明を、任意の所望の対応する関係と共に用いて、ＡＢｏｘを定義することができる。

例えば、図示されているように、知識ベースは階層的タクソノミを定義するとよく、これがツリー２００を用いて図で表現されている。さらに具体的には、各概念が、仮想フォルダ２０５で表現されており、各インスタンスが、仮想ファイル２１０で表現されている。以下、簡単にするために、各仮想フォルダ２０５および各仮想ファイル２１０は、それぞれ同じ名前の対応する概念およびインスタンスで示される。上記で指摘したように、各仮想ファイル２１０は、コンピュータの大容量メモリ上に格納されている（実）ファイルを記述する。実ファイルは、曖昧でない形で、例えば汎用一意識別子（ＵＵＩＤ：Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）から成る対応する識別子によって、特定される。仮想フォルダ２０５はそうではなく、コンピュータの大容量メモリ上で実ファイルを編成するために場合によって使用されることがあるいかなる実フォルダからも完全に独立している（知識ベースに追加される各実ファイルの第１のインスタンスに、対応する実フォルダを使用することを妨げるものはないが）。

ツリー２００は、（ルート）仮想フォルダ「ＳｔａｎｄａｒｄＦｉｌｅ」（すべての実ファイルに関する）から始まる。次に、ユーザが、「Ｖｅｈｉｃｌｅ⊆ＳｔａｎｄａｒｄＦｉｌｅ」と表明してすべての車両の概念「Ｖｅｈｉｃｌｅ」を、「Ｂｉｋｅ⊆Ｖｅｈｉｃｌｅ」と表明してすべてのバイクの概念「Ｂｉｋｅ」を、「Ｃａｒ⊆Ｖｅｈｉｃｌｅ」と表明してすべての乗用車の概念「Ｃａｒ」を、「Ｐｒｏｊｅｃｔ⊆ＳｔａｎｄａｒｄＦｉｌｅ」と表明してすべてのプロジェクトの概念「Ｐｒｏｊｅｃｔ」を、および「Ｐｅｒｓｏｎ⊆ＳｔａｎｄａｒｄＦｉｌｅ」と表明してすべての人の概念「Ｐｅｒｓｏｎ」を備える企業アーカイブの編成を定義した。ユーザはさらに、「Ｃａｒ∩Ｂｉｋｅ＝Ｂｏｔｔｏｍ」と表明する（すなわち、どの乗用車もバイクとすることはできず、どのバイクも乗用車とすることはできない）。

この時点で、ユーザは、概念「Ｂｉｋｅ」のインスタンス「ＭｙＢｉｋｅ１」（表明「ＭｙＢｉｋｅ１ ｉｓ−ａ Ｂｉｋｅ」）、概念「Ｃａｒ」の２つのインスタンス「ＭｙＣａｒ１」および「ＭｙＣａｒ２」（表明「ＭｙＣａｒ１ ｉｓ−ａ Ｃａｒ」および「ＭｙＣａｒ２ ｉｓ−ａ Ｃａｒ」）、概念「Ｐｒｏｊｅｃｔ」の２つのインスタンス「ＭｙＰｒｏｊｅｃｔ１」および「ＭｙＰｒｏｊｅｃｔ２」（表明「ＭｙＰｒｏｊｅｃｔ１ ｉｓ−ａ Ｐｒｏｊｅｃｔ」および「ＭｙＰｒｏｊｅｃｔ２ ｉｓ−ａ Ｐｒｏｊｅｃｔ」）、ならびに概念「Ｐｅｒｓｏｎ」の３つのインスタンス「ＭｙＰｅｒｓｏｎ１」、「ＭｙＰｅｒｓｏｎ２」および「ＭｙＰｅｒｓｏｎ３」（表明「ＭｙＰｅｒｓｏｎ１ ｉｓ−ａ Ｐｅｒｓｏｎ」、「ＭｙＰｅｒｓｏｎ２ ｉｓ−ａ Ｐｅｒｓｏｎ」、および「ＭｙＰｅｒｓｏｎ３ ｉｓ−ａ Ｐｅｒｓｏｎ」）を定義した。インスタンス「ＭｙＢｉｋｅ１」、「ＭｙＣａｒ１」および「ＭｙＣａｒ２」は、対応するバイクおよび乗用車についての情報（そのプレート番号、機械特性、経年数および同様のものなど）を格納する実ファイルを記述するとよい。インスタンス「ＭｙＰｒｏｊｅｃｔ１」および「ＭｙＰｒｏｊｅｃｔ２」は、対応するプロジェクトについての情報（そのスケジューリング、状況および同様のものなど）を格納する実ファイルを記述するとよく、インスタンス「ＭｙＰｅｒｓｏｎ１」、ＭｙＰｅｒｓｏｎ２」および「ＭｙＰｅｒｓｏｎ３」は、対応する人についての情報（その名前、電話番号および同様のものなど）を格納する実ファイルを記述するとよい。ユーザは、インスタンス間の任意の所望の関係を表明することもできる。例えば、「ＭｙＢｉｋｅ１ ｂｅｌｏｎｇｓＴｏ ＭｙＰｅｒｓｏｎ１」、「ＭｙＣａｒ２ ｂｅｌｏｎｇｓＴｏ ＭｙＰｅｒｓｏｎ３」、「ＭｙＰｒｏｊｅｃｔ１ ｂｅｌｏｎｇｓＴｏ ＭｙＰｅｒｓｏｎ２」、および「ＭｙＰｒｏｊｅｃｔ２ ｂｅｌｏｎｇｓＴｏ ＭｙＰｅｒｓｏｎ３」と表明することができる。

結果として生じる知識ベースが、仮想フォルダ「ＳｔａｎｄａｒｄＦｉｌｅ」をそのルートとして備えるツリー２００で表現されている。仮想フォルダ「Ｖｅｈｉｃｌｅ」、「Ｐｒｏｊｅｃｔ」および「Ｐｅｒｓｏｎ」は、仮想フォルダ「ＳｔａｎｄａｒｄＦｉｌｅ」に付属し、仮想フォルダ「Ｂｉｋｅ」および「Ｃａｒ」は、仮想フォルダ「Ｖｅｈｉｃｌｅ」に付属している。仮想ファイル「ＭｙＢｉｋｅ１」、仮想ファイル「ＭｙＣａｒ１」および「ＭｙＣａｒ２」、仮想ファイル「ＭｙＰｒｏｊｅｃｔ１」および「ＭｙＰｒｏｊｅｃｔ２」、ならびに仮想ファイル「ＭｙＰｅｒｓｏｎ１」、「ＭｙＰｅｒｓｏｎ２」および「ＭｙＰｅｒｓｏｎ３」は、それぞれ仮想フォルダ「Ｂｉｋｅ」、「Ｃａｒ」、「Ｐｒｏｊｅｃｔ」、および「Ｐｅｒｓｏｎ」に付属している。

提案されるファイル・システムにおける仮想フォルダ２０５および仮想ファイル２１０の管理は、標準のファイル・システムによって典型的にサポートされるコマンドにできる限り似たコマンドを用いて行われる。このように、考案された解決策は、それを活用しないユーザおよびソフトウェア・アプリケーションには、完全に隠れたものとなる。なお、知識ベースに基づく、提案されるファイル・システムの編成に特に合わせてあるさらなる動作を実装するために、さらなるコマンドが利用可能である。

詳細には、ユーザは、仮想ファイル２１０が付属している一般仮想フォルダ２０５から仮想ファイル２１０に達する任意のパスによって、従来通り各仮想ファイル２１０（さらに続いて、コンピュータの大容量メモリ上の対応する実ファイル）にアクセスすることができる。例えば、
「ＳｔａｎｄａｒｄＦｉｌｅ／Ｖｅｈｉｃｌｅ／Ｃａｒ／ＭｙＣａｒ１」、
「Ｖｅｈｉｃｌｅ／Ｃａｒ／ＭｙＣａｒ１」、
「Ｃａｒ／ＭｙＣａｒ１」、および
「ＭｙＣａｒ１」
はすべて、仮想ファイル「ＭｙＣａｒ１」（そのＵＵＩＤによって特定される）の有効なパスである。

なお、ユーザはここで、知識ベースから推論される（論理的推論規則を適用することによる）さらなる知識に従って仮想ファイル２１０にアクセスすることもできる。例えば、図３に示されているように、ユーザが、人から使用されている車両の新たな概念「Ｂｅｎｅｆｉｔ」を追加する（「Ｂｅｎｅｆｉｔ⊆Ｖｅｈｉｃｌｅ ＡＮＤ Ｖｅｈｉｃｌｅ ｂｅｌｏｎｇｓＴｏ Ｐｅｒｓｏｎ」）。この場合、インスタンス「ＭｙＢｉｋｅ１」（インスタンス「ＭｙＰｅｒｓｏｎ１」によって使用される）およびインスタンス「ＭｙＣａｒ２」（インスタンス「ＭｙＰｅｒｓｏｎ３」によって使用される）が、概念「Ｂｅｎｅｆｉｔ」に含まれると推論することができる。これは、ツリー２００で、仮想フォルダ「ＳｔａｎｄａｒｄＦｉｌｅ」に付属する仮想フォルダ「Ｂｅｎｅｆｉｔ」によって、仮想フォルダ「Ｂｅｎｅｆｉｔ」に付属する仮想ファイル「ＭｙＢｉｋｅ１」および「ＭｙＣａｒ２」と共に表現されている。なお、この結果は、推理を知識ベースに適用することで、インスタンス「ＭｙＢｉｋｅ１」および「ＭｙＣａｒ２」が概念「Ｂｅｎｅｆｉｔ」に含まれると明示的に表明する必要なく自動的に得られる。

このようにして、インスタンス（および対応する実ファイル）間の潜在する関係を発見することができる。さらにこれによって、ファイル・システムに対しセマンティック・クエリを実行できるようになる。

仮想フォルダ２０５および仮想ファイル２１０は、標準のコマンド（コピー、移動、削除、および同様のものなど）を用いて操作することも可能であり、これは、知識ベースおよび実ファイル（必要であれば）の対応する更新へと自動的に変換される。

例えば、図４は、図２と同じツリー２００の一部を示す（対応する仮想ファイル「ＭｙＢｉｋｅ１」、「ＭｙＣａｒ１」および「ＭｙＣａｒ２」を備えた仮想フォルダ「ＳｔａｎｄａｒｄＦｉｌｅ」、「Ｖｅｈｉｃｌｅ」、「Ｂｉｋｅ」および「Ｃａｒ」に限られている）。この事例では、ユーザは、概念「ＲｅｎｔｅｄＧｏｏｄ」（企業によって賃借されているすべての物品に関する）の新たな仮想フォルダ２０５を作成する。次にユーザは、仮想ファイル「ＭｙＣａｒ２」を、仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」へコピーし（例えば、図面で矢印によって表現されているように、マウスを用いたドラッグ・アンド・ドロップによって）、対応する乗用車が賃借されていることを示す。

図５に移る。結果として、新たな表明「ＭｙＣａｒ２ ｉｓ−ａ ＲｅｎｔｅｄＧｏｏｄ」が自動的に知識ベースに追加される。これは、ツリー２００で、仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」に付属するさらなる仮想ファイル「ＭｙＣａｒ２」を用いて表現されている。次にユーザは、企業によって賃借されているＰＣについての情報を格納する新たな実ファイルを作成し、それを、同じ仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」に付属する新たな仮想ファイル「ＭｙＰＣ１」を用いて表現する。上記のように、表明「ＭｙＰＣ１ ｉｓ−ａ ＲｅｎｔｅｄＧｏｏｄ」に対応する新たなインスタンス「ＭｙＰＣ１」が、知識ベースに自動的に追加される。

以下、図６を参照する。ユーザが、仮想ファイル「ＭｙＣａｒ２」を仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」から削除することを決定する（図面において、ばつ印で示されているように）。削除の動作は、弱モード（ｗｅａｋ ｍｏｄｅ）または強モード（ｓｔｒｏｎｇ ｍｏｄｅ）で実行されるとよい（例えば、ユーザが任意の仮想ファイル２１０をマウスの右ボタンでクリックすると開くポップアップ・メニュー内の、対応するコマンドを選択することによる）。

弱い削除の場合、図７に示されているように、対応する表明「ＭｙＣａｒ２ ｉｓ−ａ ＲｅｎｔｅｄＧｏｏｄ」のみが知識ベースから除去される。これは、ツリー２００において、仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」からの仮想ファイル「ＭｙＣａｒ２」の削除によって表現されている。なお、この動作は、知識ベース内の、インスタンス「ＭｙＣａｒ２」を含む他のタームには影響を及ぼさない。したがって、問題の例では、図面において仮想フォルダ「Ｃａｒ」に依然として付属する仮想ファイル「ＭｙＣａｒ２」によって示されているように、概念「Ｃａｒ」のインスタンス「ＭｙＣａｒ２」（表明「ＭｙＣａｒ２ ｉｓ−ａ Ｃａｒ」）は残る。例えば、この動作は、対応する乗用車はもう賃借されてはいないが、企業によって購入された場合に実行され得る。

一方、強い削除の場合は、図８に示されているように、インスタンス「ＭｙＣａｒ２」が、対応する表明すべてと共に知識ベースから完全に除去される。問題となっている特定の場合には、これは、インスタンス「ＭｙＣａｒ２」、表明「ＭｙＣａｒ２ ｉｓ−ａ ＲｅｎｔｅｄＧｏｏｄ」、および表明「ＭｙＣａｒ２ ｉｓ−ａ Ｃａｒ」を除去することを伴う。知識ベースからのインスタンス「ＭｙＣａｒ２」の除去は、コンピュータの大容量メモリから対応する実ファイルを実際に消すことも伴う。これは、ツリー２００において、仮想フォルダ「ＲｅｎｔｅｄＧｏｏｄ」および仮想フォルダ「Ｃａｒ」からの仮想ファイル「ＭｙＣａｒ２」の削除によって表現されている。例えばこの動作は、企業が対応する乗用車をもう有していない場合に実行され得る。

さらに、仮想フォルダまたはファイル、あるいはその両方に対して、ユーザによって出される任意のコマンドの論理的一貫性を強制することも可能である。このために、図９において、図２に示されたのと同じツリー２００を参照する。ユーザが、仮想ファイル「ＭｙＣａｒ２」を、仮想フォルダ「Ｂｉｋｅ」にコピーしようとすると仮定する（この場合もやはり、図面において矢印で表現されているように、マウスでのドラッグ・アンド・ドロップによる）。しかしこの場合、この動作は、概念「Ｃａｒ」のインスタンスが概念「Ｂｉｋｅ」のインスタンスにもなることはできない（逆の場合も同じ）ということを示す表明「Ｃａｒ∩Ｂｉｋｅ＝Ｂｏｔｔｏｍ」と矛盾する。したがって、ユーザは、この動作は許可されないと警告される。それに応答して、ユーザは動作を中止することができる（例えば、ユーザがその動作を誤ってリクエストしたと納得するため）。

図１０に移る。もう１つの方法として、ユーザは代わりに、この動作の強制を決定することができる。例えばこれは、ユーザが以前、仮想ファイル「ＭｙＣａｒ２」が誤って仮想フォルダ「Ｃａｒ」に付属させられたときに間違いがあったことを知っている場合に生じ得る。この場合、インスタンス「ＭｙＣａｒ２」が概念「Ｃａｒ」に含まれ、知識ベースに新たな表明「ＭｙＣａｒ２ ｉｓ−ａ Ｂｉｋｅ」が追加される。同時に、この新たな表明と矛盾していた知識ベース内のすべての表明が除去される。問題となっている特定の場合には、これは、表明「ＭｙＣａｒ２ ｉｓ−ａ Ｃａｒ」を除去することを伴う。これはツリー２００において、仮想フォルダ「Ｃａｒ」から仮想フォルダ「Ｂｉｋｅ」へ移動される仮想ファイル「ＭｙＣａｒ２」によって表現されている。

このように、知識ベースは確実に、常に論理的に一貫性のある状態となる。特に、提案される機能によって、ユーザが間違った動作をファイル・システムに対して実行することが防がれる。

図１１に移る。本発明の実施形態による解決策を実装するために使用することができる主要なソフトウェア・コンポーネントが、全体として参照番号５００で示されている。情報（プログラムおよびデータ）は、典型的には、ハード・ディスク上に格納され、プログラムの実行中にコンピュータのワーキング・メモリへ（少なくとも部分的に）ロードされる。プログラムは最初に、例えばＣＤ−ＲＯＭから、ハード・ディスクにインストールされる。特に、図面は、システムの静的構造（対応するコンポーネントによって）と、その動的な動作（符号「Ａ」が先頭につく連続番号で示されている、対応するアクションをそれぞれのメッセージが表現する、やり取りされる一連のメッセージによって）とを表している。

さらに詳しくは、オペレーティング・システム５０５（例えばＬｉｎｕｘ（Ｒ））が、コンピュータの基本機能を実装するソフトウェア・プラットフォームを、対応するコンポーネントを介して提供する。詳細には、この説明に関連するオペレーティング・システム５０５のコンポーネントには、ネイティブ・ファイル・システム・マネージャ５１０（コンピュータの大容量メモリ上の実ファイルの編成を制御する）およびグラフィカル・ユーザ・インターフェース、すなわちＧＵＩ５１５（グラフィック構成要素を操作することによるユーザのコンピュータとの対話を制御する）がある。ソフトウェア・アプリケーション５２０（図面には１つのみ示す）は、オペレーティング・システム５０５の上で実行される。アプリケーション５２０は、特定のサービスを実装するソフトウェア・プログラム、またはユーザによるオペレーティング・システム５０５へのアクセス用の単純なコンソールから成るとよい。

本発明の実施形態による解決策では、仮想ファイル・システム・マネージャ５２５が、ネイティブ・ファイル・システム・マネージャ５１０をラップする。詳細には、仮想ファイル・システム・マネージャ５２５は、所定のオントロジに基づいてファイル・システムを記述する知識ベース５３０（図面に示されていない、そのＴＢｏｘおよびＡＢｏｘを備える）を含む。知識ベースは、（例えばデータベース内の）実ファイルから独立した構造でコンピュータの大容量メモリ上に格納されることが好ましい。このように、知識ベース５３０は、ネイティブ・ファイル・システム・マネージャ５１０から切り離されており、その結果、任意の利用可能なネイティブ・ファイル・システム・マネージャ５１０の拡張に使用することができる。

インターフェース５３５は、知識ベース５３０のＴＢｏｘを編集するために使用される。このために、インターフェース５３５は、ＡＰＩのセットを、対応するライブラリ内に公開する。このＡＰＩは、知識ベース５３０内の概念、役割、属性および内包表明を追加、除去、または更新するコマンドを出すことを可能にする（アクション「Ａ１．編集」）。それに応答して、知識ベース５３０は、その論理的一貫性に関して状況に応じ更新される（アクション「Ａ２．更新」）。

レンダリング・モジュール５４０は、知識ベース５３０にアクセスする。レンダリング・モジュール５４０は、知識ベース５３０の概念およびインスタンスを、対応する仮想フォルダおよびファイルに関連付け、これらが続いて、対応する表明に従って関係付けられる（アクション「Ａ３．関連付け」）。次に、レンダリング・モジュール５４０は、ＧＵＩ５１５に、結果として生じる構造のグラフィック表現を表示させる（アクション「Ａ４．表示」）。

ＡＰＩ層５４５は、仮想フォルダおよびファイルを管理するためのＡＰＩのセットを公開する（例えば、Ｊａｖａ（Ｒ）エクステンションを用いて実装される）。ＡＰＩ層５４５は、ネイティブ・ファイル・システム５１０のすべてのコマンドをサポートし、仮想ファイル・システム５２５に特有の機能に関するさらなるコマンドを備える。その結果、アプリケーション５２０は、ＡＰＩ層５４５によって公開されている対応するＡＰＩを呼び出すことで、任意の所望のコマンドを仮想ファイル・システム５２５に出すことができる（アクション「Ａ５．送出」）。例えば、コマンドは、仮想フォルダおよびファイルのグラフィック表現に影響を与えることによって出されてもよい。あるいは、コマンドは、対応する命令を用いて出されてもよい。

いずれの場合も、各コマンドは、フッカー５５０によって傍受される（例えば、オペレーティング・システム５０５のカーネル拡張を利用することによる）。それに応答して、フッカー５５０は、知識ベース５３０の推論エンジン（または推理器（ｒｅａｓｏｎｅｒ））５５５へコマンドを転送する（アクション「Ａ６．転送」）。当技術分野で既知の利用可能な推論エンジン（ＤＬ言語で表された知識ベース５３０の）の例は、Ｆａｃｔ＋＋、ＫＡＯＮおよびＰｅｌｌｅｔである。それに応答して、推論エンジン５５５はまず、そのコマンドによって知識ベース５３０に対しリクエストされた動作に、そのコンテンツとの論理的な一貫性があるかどうかを検証する（アクション「Ａ７．検証」）。この検証の結果が否定的であれば、推論エンジン５５５は、例えばポップアップ・ウィンドウを用いて、ＧＵＩ５１５を介しユーザに警告メッセージを提供する（アクション「Ａ８．警告」）。それでもやはりユーザがこの動作を強制することを決定すると、推論エンジン５５５は、知識ベース５３０を訂正して、矛盾を除去する（アクション「Ａ９．訂正」）。いずれの場合も、次に知識ベース５３０が、必要な動作に従って更新される（アクション「Ａ１０．実行」）。この動作の実行が、選択された仮想ファイル（直接、または選択された仮想フォルダを介して）によって記述される選択された実ファイルに対する任意のアクセスまたは変更あるいはその両方を伴う場合、当該の実ファイルが、そのＵＵＩＤに従い変換器５６０によって特定される（アクション「Ａ１１．特定」）。この動作が、選択された実ファイルに対する任意の変更（それを消すことなど）から成る場合、変換器５６０は、その動作を、ネイティブ・ファイル・システム・マネージャ５１０に対し強制する（アクション「Ａ１２．強制」）。反対に、この動作が、選択された実ファイルに対するアクセス（それを開くためなど）から成る場合、変換器５６０は、選択された実ファイルを、ネイティブ・ファイル・システム・マネージャ５１０を介してアプリケーション５２０へ返す（アクション「Ａ１３．アクセス」）。

当然、ローカルの要件および特有の要件を満たすために、当業者は、上述の解決策に対して多数の論理的または物理的あるいはその両方の変更および改変を適用することができる。さらに具体的には、本発明は、その好適な実施形態（単数または複数）を参照して、ある程度の詳細事項と共に記載されたが、当然のことながら、形態および細部における様々な省略、置換ならびに変更、ならびに他の実施形態が可能である。詳細には、提案された解決策は、それをさらに深く理解できるよう上記の説明において記載された特定の細部（数値の例など）を用いずに実践されることさえも可能である。逆に、周知の機能は、不必要な詳細で説明を曖昧にしないために、省略または簡略化されている場合もある。さらに、一般的な設計上の問題として、本発明の任意の開示された実施形態に関連して記載された特定の構成要素または方法ステップあるいはその両方が、他の任意の実施形態に組み入れられてもよいということが明白に意図されている。

詳細には、提案された解決策は、等価な方法を用いて（同様のステップを使用すること、絶対不可欠ではない一部のステップを除去すること、またはさらなる任意選択のステップを追加することによって）実装されるのに適している。さらに、各ステップは、異なる順序で実行されても、同時に実行されても、または交互の形で実行されてもよい（少なくとも部分的に）。

いずれの場合も、同じ解決策が、任意の他のタイプのファイル（例えば、電子メール、マルチメディア・データ、および同様のものを格納する）を編成するために使用され得る。

さらに、知識ベースは、どのようなオントロジでもそれに準拠する別の方法で定義され得る。いずれの場合も、上述の概念、インスタンスおよび関係は、単に説明に役立つのみであり、制限的な形で解釈されてはならない。

あるいは、その他任意の推論規則、または推理が、利用可能な知識からさらなる知識を得るために使用され得る（例えば、高階論理に基づく）。

ファイル・システムの表現に対して出すことができるコマンドの上記の例は、網羅的なものではない。例えば、同様の考慮事項が、移動コマンド（すなわち、コピー・コマンドおよび削除コマンド）ならびに同様のものに当てはまる。さらに、同じコマンド（すなわち、アクセス、コピー、移動、削除など）が、変更すべき点を変更して複数の仮想ファイルに、または１つ以上の仮想フォルダに（それに直鉄的または間接的に付属するすべての仮想ファイルにコマンドを適用するよう）適用されることもあり得る。

いずれの場合も、基本的な実装は、弱いコマンド（ｗｅａｋ ｃｏｍｍａｎｄ）のみ、または強いコマンド（ｓｔｒｏｎｇ ｃｏｍｍａｎｄ）のみのサポートの可能性を排除するものではない。

知識ベースの一貫性が任意の他の方法で検証されても、同様の考慮事項が当てはまる（例えば、重大でない環境または動作、あるいはその両方に関してはその要件を緩和する可能性がある）。

さらに、矛盾した動作を常に中止すること（ユーザがそれを強制する可能性なしで）を妨げるものはない。この場合、ユーザは、矛盾を手動で除去して、次に同じコマンドを再び出す必要があるであろう。

提案されたファイル・システムのグラフィック表現は、制限を意図したものではない。いずれの場合も、同じコマンドが、任意の他の方法で出されてもよく、コマンド・ライン・インターフェース（ＣＬＩ：Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）を介すことさえも可能である。

あるいは、ファイル・システム・マネージャに対する各コマンドの送出を、他の技術で傍受することができる（例えば、ファイル・システム・マネージャをスタブ・ライブラリでラップすることによって）。いずれの場合も、提案された解決策を、ネイティブ・ファイル・システム・マネージャによって直接実装することを妨げるものはない。

当然、概念は、無閉路有向グラフ（ＤＡＧ：ｄｉｒｅｃｔｅｄ ａｃｙｃｌｉｃ ｇｒａｐｈ）などの任意の他の構造で編成されても（ツリーに基づかなくても）よい。

ＤＬ言語への言及が制限的な形で解釈されてはならず、提案される解決策は、他の言語（Ｐｒｏｌｏｇなど）で知識ベースが表されても、実現に適している。

知識ベースを任意の他の形態で格納することを妨げるものはない。例えば、本発明の別の実施形態（基礎をなすネイティブ・ファイル・システム・マネージャに依存する）では、対応する情報が、実フォルダおよびファイルのメタデータに保存されてもよい。

プログラム（本発明の各実施形態を実装するために使用されるとよい）が別の方法で構築されても、またはさらなるモジュールもしくは機能が提供されても、同様の考慮事項が当てはまる。同じように、メモリ構造は、他のタイプのものであってもよく、または等価なエンティティ（必ずしも物理的なストレージ媒体から成るとは限らない）に置き換えられてもよい。いずれの場合も、プログラムは、外部もしくは常駐ソフトウェア、ファームウェア、またはマイクロコード（例えばコンパイルまたは解釈実行されるべき、オブジェクト・コードまたはソース・コードで）など、任意のデータ処理システムによって、または任意の処理システムと関連して使用されるのに適した任意の形態をとればよい。さらに、任意のコンピュータ使用可能媒体上にプログラムを提供することが可能である。媒体は、プログラムを含むこと、格納すること、伝達すること、伝播させることまたは転送することに適した任意の構成要素であればよい。例えば、媒体は、電子、磁気、光学、電磁気、赤外線または半導体タイプのものであればよい。このような媒体の例は、固定ディスク（プログラムがプレインストールされている場合もある）、取り外し可能ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波および同様のものである。いずれの場合も、本発明の実施形態による解決策は、ハードウェア構造を用いての実装（例えば半導体材料のチップに統合されて）、またはソフトウェアとハードウェアとの組み合わせを用いての実装に適している。同じ解決策を、ネットワークを介して（インターネットにおいてなど）アクセスされるサービスとして展開することも可能であるということがすぐに分かるであろう。

本発明の実施形態では、仮想ファイル・システムが、オペレーティング・システムのレベルで直接実装されるとよい。しかし、同じ解決策をプラグインとして、または任意の他の形態で提供することを妨げるものはない。

さらに、提案される解決策が、スタンドアロンのファイル・システムのみを参照して上記で記載されていても、その、分散ファイル・システムへの適用は除外されない。種々のファイル・システム（リモート・コンピュータ上）をセマンティック・レベルで統合し、そのすべてが遵守する共通のオントロジに基づく調整プロセスを用いることも可能である。

提案された方法は、異なるアーキテクチャを有するシステム、または等価なユニットを含むシステム上で実行されてもよい（例えば、ローカル・ネットワークに基づく）。さらに、各コンピュータは、同様の構成要素を含んでもよい（プログラムまたはその一部を一時的に格納するキャッシュ・メモリなど）。どのような場合も、コンピュータを、任意のコード実行エンティティ（ＰＤＡ、移動電話、および同様のものなど）、またはその組み合わせ（多層サーバ・アーキテクチャ、グリッド・コンピューティング・インフラストラクチャ、および同様のものなど）に置き換えることが可能である。

Claims (18)

1. データ処理システムにおいて情報を格納する方法（Ａ１〜Ａ１３）であって、
   前記データ処理システムの大容量メモリ上の複数の実ファイルを編成するようになっているファイル・システム・マネージャの知識ベースであって、概念のセットと、前記概念間の関係のセットと、各実ファイルを少なくとも１つの概念のインスタンスとして記述する包含の関係のセットとを含む知識の集合を、所定のオントロジに従って定義する、前記知識ベースを提供するステップ（Ａ１〜Ａ２）と、
   選択されたインスタンスのセットにアクセスするために、前記ファイル・システム・マネージャにコマンドを出すステップ（Ａ５〜Ａ６）と、
   前記選択されたインスタンスにより記述されている選択された実ファイルのセットを、前記知識に従って特定するステップ（Ａ７〜Ａ１１）と、
   前記大容量メモリ上の前記選択された実ファイルにアクセスするステップ（Ａ１３）と、
   を含む方法。
2. 所定の論理的推論規則を適用することによって、前記知識からさらなる知識を推論するステップ（Ａ１０）であって、前記選択されたファイルは、前記さらなる知識にさらに従って特定される、前記ステップ
   をさらに含む、請求項１に記載の方法（Ａ１〜Ａ１３）。
3. さらなる選択されたインスタンスのセットを操作するために、前記ファイル・システム・マネージャにさらなるコマンドを出すステップ（Ａ５〜Ａ６）と、
   前記さらなるコマンドに従って、前記知識を更新するステップ（Ａ７〜Ａ１０）と、
   をさらに含む、請求項１または２に記載の方法（Ａ１〜Ａ１３）。
4. 前記さらなるコマンドを出す前記ステップ（Ａ５〜Ａ６）は、
   前記選択されたインスタンスをターゲット概念に加えること（Ａ５〜Ａ６）
   を含み、前記さらなるコマンドに従って前記知識を更新する前記ステップ（Ａ７〜Ａ１０）は、
   選択された各インスタンスの前記ターゲット概念への包含の関係を表明すること（Ａ７〜Ａ１０）
   を含む、請求項３に記載の方法（Ａ１〜Ａ１３）。
5. 前記さらなるコマンドを出す前記ステップ（Ａ５〜Ａ６）は、
   前記選択されたインスタンスをさらなるターゲット概念から弱く削除すること（Ａ５）
   を含み、前記さらなるコマンドに従って前記知識を更新する前記ステップ（Ａ７〜Ａ１０）は、
   選択された各インスタンスの包含の関係を、前記さらなるターゲット概念から除去すること（Ａ７〜Ａ１０）
   を含む、請求項３または４に記載の方法（Ａ１〜Ａ１３）。
6. 前記さらなる選択されたインスタンスによって記述されているさらなる選択された実ファイルのセットを、前記知識に従って特定するステップ（Ａ７〜Ａ１１）と、
   前記さらなるコマンドに従って、前記さらなる選択された実ファイルを変更するステップ（Ａ１２）と、
   をさらに含む、請求項３〜５いずれかに記載の方法（Ａ１〜Ａ１３）。
7. 前記さらなるコマンドを出す前記ステップ（Ａ５〜Ａ６）は、
   前記選択されたインスタンスを、またさらなるターゲット概念から強く削除すること（Ａ５）
   を含み、前記さらなるコマンドに従って前記知識を更新する前記ステップ（Ａ７〜Ａ１０）は、
   選択された各インスタンスと、選択された各インスタンスを含む各関係とを除去すること（Ａ７〜Ａ１０）
   を含み、前記方法は、
   選択された各インスタンスによって記述されている前記実ファイルを、前記大容量メモリから消すステップ（Ａ１２）
   をさらに含む、請求項６に記載の方法（Ａ１〜Ａ１３）。
8. 前記知識の前記更新の論理的一貫性を検証するステップ（Ａ７）と、
   前記論理的一貫性の前記検証の否定的な結果に応答して、警告を提供するステップ（Ａ８）と、
   をさらに含む、請求項３〜７いずれかに記載の方法（Ａ１〜Ａ１３）。
9. 前記論理的一貫性の前記検証の前記否定的な結果に応答して、
   論理的矛盾を除去するよう前記知識を更新するステップ（Ａ９）
   をさらに含む、請求項８に記載の方法（Ａ１〜Ａ１３）。
10. 仮想フォルダと各概念とを、さらに仮想ファイルと各インスタンスとを、関連付けるステップ（Ａ３）と、
    前記関係に従って編成された前記仮想フォルダおよび前記仮想ファイルを含む、前記ファイル・システム・マネージャの表現を表示するステップ（Ａ４）であって、前記コマンドまたは前記さらなるコマンドあるいはその両方は、前記ファイル・システム・マネージャの前記表現に対して出される（Ａ５〜Ａ６）、前記ステップと、
    をさらに含む、請求項１〜９いずれかに記載の方法（Ａ１〜Ａ１３）。
11. 前記コマンドまたは前記さらなるコマンドあるいはその両方を出す前記ステップ（Ａ５〜Ａ６）は、
    前記コマンドまたは前記さらなるコマンドあるいはその両方を傍受すること（Ａ５）と、
    前記コマンドまたは前記さらなるコマンドあるいはその両方を、前記知識ベースの推論エンジンへ転送すること（Ａ６）と、
    を含む、請求項１〜１０いずれかに記載の方法（Ａ１〜Ａ１３）。
12. 前記概念は、階層的タクソノミに準拠し、前記概念は、前記概念のうちの、すべての前記実ファイルに関するルート概念から始まるツリーにおける前記関係によって編成される、請求項１〜１１いずれかに記載の方法（Ａ１〜Ａ１３）。
13. 前記知識は、記述論理言語を用いて表される、請求項１〜１２いずれかに記載の方法（Ａ１〜Ａ１３）。
14. 前記知識ベースは、前記実ファイルから独立して、大容量メモリ構造内に格納される、請求項１〜１３いずれかに記載の方法（Ａ１〜Ａ１３）。
15. コンピュータ・プログラム（５２５）がデータ処理システム（１００）上で実行されると、請求項１〜１４いずれかに記載の方法（Ａ１〜Ａ１３）を実行する、前記コンピュータ・プログラム。
16. データ処理システム（１００）の仮想ファイル・システム・マネージャ（５２５）であって、請求項１５に記載のコンピュータ・プログラム（５２５）を含む、前記仮想ファイル・システム・マネージャ。
17. データ処理システム（１００）のオペレーティング・システム（５０５）であって、請求項１６に記載の仮想ファイル・システム・マネージャ（５２５）を含む、前記オペレーティング・システム。
18. 請求項１〜１４いずれかに記載の方法（Ａ１〜Ａ１３）のステップを実行する手段（５２５）を含む、システム（１００）。

Images