JP4343669B2 - ファイル管理装置，動的名前空間生成方法および動的名前空間生成プログラム - Google Patents

Description

本発明は，コンピュータシステムに格納されたファイルへのアクセス技術に関し，特に，利用者の利用状況に応じて動的にディレクトリとファイルの階層構造を構成するファイル管理装置および動的名前空間生成方法に関する。

ファイルシステムとは，コンピュータシステムにおける記憶装置に記録されているデータファイルを管理するソフトウェアであり，その管理対象には，ファイルの他，記憶媒体に設けられた管理領域，管理情報も含まれる。現在広く利用されているMicrosoft Windows のファイルシステムであるＮＴＦＳ（NT File System）に代表される多くの既存ファイルシステムでは，ファイルは木構造で管理される。

木構造のファイルシステムでは，ルートと呼ばれる“根”をはじまりとして，ディレクトリと呼ばれる“節”と，ファイルである“葉”による階層構造が構成される。ルートには，ディレクトリとファイルが一つ，または複数配置される。ディレクトリは，ファイルや別のディレクトリを含むことができる箱のような役割を持ち，ディレクトリには，ディレクトリとファイルが一つ，または複数配置される。あるディレクトリから見て，自身を含むディレクトリ，つまり，ルートに近い側のディレクトリを以降では“上位ディレクトリ”と表現する。あるディレクトリから見て，自身が含んでいるディレクトリを以降では“下位ディレクトリ”と表現する。

ファイルは，ファイル名という個別の名称を持ち，そのファイルを含むディレクトリ内では一意の名称となる。ディレクトリも同様に，ディレクトリ名という個別の名称を持ち，そのディレクトリを含む上位ディレクトリ内では一意の名称となる。一般にディレクトリ名は，“時間”，“場所”，“分野”など，自身が含んでいるディレクトリやファイルの意味や説明にあたる語が用いられる。

あるファイルの，ルートから順に木構造を辿ったディレクトリの列をパスと呼び，パスを構成するディレクトリ名の列をパス名と呼ぶ。各ファイルは，パス名とファイル名とを組み合わせることで，ファイルシステムの中で一意の名称となる。

なお，下記のＲＦＣ１８１３で規定される特許文献１に記述されているＮＦＴＳは，利用者自身の計算機から通信路経由で異なる計算機のファイルシステムを利用することができるものであるが，静的な木構造のファイルシステムである。
ＮＦＳ Version 3 Protocol Specification (RFC1813)

既存のファイルシステムでは，以下に挙げる課題がある。第一の課題は，“時間”，“場所”，“分野”などのディレクトリの名称として用いるものの上下間係が，利用者が木構造を構成する時点で静的に決定されることにある。利用者は，複数のディレクトリの上下関係を自由に決定することができるが，このことは，木構造を構成する方針をあらかじめ決めておかなければ不統一な階層構造になってしまう可能性があることを意味する。一方，目的のファイルを取得するためにファイル名とパス名が必要になるため，利用者は，そのファイル名やパスに含まれるディレクトリ名だけでなく，ディレクトリ名の木構造における順序を正確に知っていなければならない。

第二の課題は，ファイル名が単独では意味をなさない可能性である。ディレクトリ名は前述の通り，自身が含んでいるディレクトリやファイルの意味や説明にあたる語が用いられる。例えば，“旅行”という名称のディレクトリ内に１０個の画像ファイルが含まれる場合，一般に１０個の画像ファイルにとって“旅行”という説明は共通である。

この際，利用者は１０個の画像ファイルのファイル名を“１”から“１０”までの連番にすることが可能である。この連番からなるファイル名は，“旅行”というディレクトリに含まれる限り，順番という意味をなしているといえる。しかし，この中の“５”という名称のファイルを，別の“写真”というディレクトリに複製した場合，“５”という名称は順番という意味を失うとともに，ディレクトリ名によって与えられていた“旅行”という意味も失うことになる。

第三の課題は，パス名やファイル名における意味の重複である。第二の課題で例に挙げた，ファイルの複製によって意味が喪失する問題を解決する一つの手段としては，ファイル名に“旅行”という語を含ませ，“旅行５”をファイル名とすることが考えられる。しかし，この場合，“旅行”というディレクトリの中に“旅行５”というファイルが含まれることになり，パス名とファイル名とで意味が重複してしまう。同様の問題は，パスに含まれる複数のディレクトリの間でも起こり得る。このような冗長な名称による管理は，意味の一貫性を失う可能性が高くなる。

第四の課題は，木構造の再構成の必要性である。ファイルシステムは，特殊な目的の利用でない限り，管理するディレクトリとファイルとが計算機の使用とともに増加する。この際，事前に厳密な設計を行った木構造でない限り，ディレクトリの統合や分割，ディレクトリ名の変更が発生する。例として，“旅行”というディレクトリを，“国内旅行”と“海外旅行”の二つのディレクトリに分割することが挙げられる。第一の課題と同様，利用者は，目的のファイルを取得するために，新しい木構造を正確に知っていなければならない。

第五の課題は，ファイル名の重複の問題である。“風景”というディレクトリに含まれていた“５”というファイルを，第二の課題の例で挙げた“５”という名称のファイルが既に複製されている“写真”というディレクトリに複製することは，複製先の“写真”というディレクトリに“５”というファイル名が重複することになり，同一ディレクトリ内でのファイル名の一意性が保てないため，行うことができない。これは，第二の課題と同様，本来パスを含めて異なる意味を与えられていた二つのファイルが，別のディレクトリへの複製によってファイル名以外の意味が失われたためである。

本発明の目的は，利用者が木構造の正確な構成や，その変更に関する知識を有していなくても目的のファイルを取得できるようにして，前述の第一，第四の課題を解決し，ファイルの移動や複製による，意味や説明の欠落を回避することで前述の第二，第五の課題を解決し，ファイルの意味や説明の冗長性の排除によって一貫性を向上することで前述の第三の課題を解決するファイルシステムを実現することにある。

上記課題を解決するため，本発明は，従来の静的な木構造のファイルシステムではなく，利用者がファイルシステムを利用する際に動的に木構造が構成されるファイルシステムを実現するものである。ファイルの意味について記述したデータのことを，以降では“メタデータ”と表現する。メタデータは，具体的にはファイルの意味を表す「値」または「属性と値の組」からなる１または複数のメタデータ要素のデータ列である。本発明では，ディレクトリやファイルは固定的な名称を持たず，利用者の操作によってファイルに関連するメタデータを，ディレクトリ名またはファイル名として用いる。

すなわち，本発明は，コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するファイル管理装置において，各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，前記メタデータ定義情報記憶手段へのファイルＩＤとメタデータの登録，前記メタデータ定義情報記憶手段に登録されたファイルＩＤとメタデータの変更および削除を行う登録手段と，ファイルの検索要求における前記ディレクトリの名称の指定が，前記メタデータ要素のいくつかの指定により行われた場合に，前記メタデータ定義情報記憶手段に記憶されたメタデータの中で，前記ディレクトリの名称として指定されたメタデータ要素をすべて含むメタデータを検索し，検索された各メタデータ中から前記ディレクトリの名称として指定されたメタデータ要素を除いたメタデータ要素の組を検索結果のファイルの名称として定義し，前記ディレクトリの名称と前記検索結果のファイルの名称の一覧を利用者に提示する手段とを備えることを特徴とする。

また，前記ファイル管理装置において，前記メタデータ定義情報記憶手段に登録されるメタデータを構成するメタデータ要素は，ファイルの意味を表す値または属性と値の組であることを特徴とする。

また，前記検索手段は，前記メタデータ定義情報記憶手段を検索した結果のメタデータとそのメタデータに対応するファイルを識別するファイルＩＤのリストとの組の情報を記憶する検索結果キャッシュ機構を持ち，指定されたメタデータに該当するファイルを前記検索結果キャッシュ機構により特定し，前記検索結果キャッシュ機構により特定できなかった場合に前記メタデータ定義情報記憶手段を検索することを特徴とする。

また，本発明は，コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するとともに，各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，前記ファイルシステムへのファイルの登録手段と，ファイルを操作するファイル操作手段とを備えるコンピュータが，ファイルシステムにおけるディレクトリとファイルとの階層構造を，利用者の利用状況に応じて動的に構成する動的名前空間生成方法であって，前記ファイルの登録手段が，登録対象のファイルのファイルＩＤと，そのファイルに対して定義される１または複数のメタデータ要素の集合であるメタデータとの組を，前記メタデータ定義情報記憶手段に登録するステップと，前記ファイル操作手段が，前記メタデータ定義情報記憶手段に登録された各ファイルごとのメタデータの中の，利用者から指定されたメタデータ要素の組をディレクトリの名称とし，該メタデータから前記ディレクトリの名称として用いられたメタデータ要素を除いた残りのメタデータ要素の組をファイルの名称として利用者に提示し，前記メタデータ要素の組から構成される，前記ディレクトリの名称と前記ファイルの名称との組によってファイルを特定する処理を行うステップとを有することを特徴とする。

また，本発明は，コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するとともに，各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，前記ファイルシステムへのファイルの登録手段と，ファイルを操作するファイル操作手段とを備えるコンピュータが，ファイルシステムにおけるディレクトリとファイルとの階層構造を，利用者の利用状況に応じて動的に構成する動的名前空間生成方法であって，前記ファイルの登録手段が，登録対象のファイルのファイルＩＤと，そのファイルに対して定義される１または複数のメタデータ要素の集合であるメタデータとの組を，前記メタデータ定義情報記憶手段に登録するステップと，前記ファイル操作手段が，前記ファイルシステムにおけるファイル操作インタフェースから受け付けたファイル操作要求の種類に応じたファイル操作を行うステップとを有し，前記ファイル操作手段が前記ファイル操作を行うステップでは，前記ファイル操作インタフェースから受け付けたファイル操作要求の種類がディレクトリ内容の取得である場合に，前記ファイル操作要求に含まれるメタデータをメタデータ要素に分割し，分割したメタデータ要素をすべて含むメタデータに対応するファイルＩＤを前記メタデータ定義情報記憶手段から検索し，検索したファイルＩＤのリスト，または検索したファイルＩＤに対応するメタデータ，または検索したファイルＩＤに対応するメタデータから前記ファイル操作要求に含まれるメタデータ中のメタデータ要素を除いた残りのメタデータを，前記ファイル操作要求の要求元へ返却することを特徴とする。

また，前記ファイル操作インタフェースとして，固定的なディレクトリと固定的なファイル名とを扱う既存のインタフェースを用い，該ファイル操作インタフェースを用いたファイル操作を，ディレクトリとファイル名とが利用者の利用状況に応じて動的に変化するメタデータ操作に変換するステップを有することを特徴とする。

本発明の作用は以下のとおりである。本発明の動的名前空間生成方法は，ファイルシステムにおける木構造を利用者の利用状況に応じて動的に構成する。この動的名前空間生成方法を用いるファイルシステムでは，利用者が，木構造の構成に関する知識を持つ必要がない。また，このファイルシステムは，固定的なデイレクトリ名とファイル名を持たないことを特徴としている。また，このファイルシステムは，ファイルに対するメタデータを利用して，名前空間を生成することを特徴としている。また，このファイルシステムは，単独でも意味を持った名称によって，ディレクトリ内のファイルを識別することを特徴としている。

さらに，本発明を用いたファイルシステムは，同一のファイルに対する重複したメタデータ定義の必要性をなくしたことによる，意味の一貫性確保が容易であることを特徴としている。また，本発明を用いたファイルシステムは，利用者による，従来のインタフェースを用いたファイル操作を，ファイルに対するメタデータ操作へ変換することを特徴としている。

本発明では，利用者が自身の利用目的に合わせて，メタデータ要素を指定する，すなわちディレクトリ内容の取得操作を行うことで，従来のファイルシステムにおける木構造を動的に構成する。これにより，利用者は木構造の正確な構成や，その変更に関する知識を持っていなくてもファイルシステムを利用すること，および，メタデータの更新を行うことが可能であり，前述の第一，第四の課題を解決することができる。

また，本発明では，ファイルの名前は，ディレクトリの名前として利用されていないメタデータ，すなわち利用者によってまだ指定されていないメタデータを用いて決定される。これにより，ファイルは常にディレクトリ内で識別するための適切なファイル名を持つことができ，前述の第二，第五の課題を解決することが可能となる。

本発明では，あるファイルに対する一つのメタデータを，ディレクトリ名としても，ファイル名としても利用することが可能であり，メタデータを重複して定義する必要がない。これにより，意味の一貫性を保つことが容易になり，前述の第三の課題を解決することが可能となる。

下記の実施の形態でも示すように，利用者は従来のファイルシステムと同一のインタフェースを利用して，本発明のファイルサーバからファイルを取得することが可能である。さらに，利用者は，従来のインタフェースによる，従来のファイル操作で，本発明のシステムのメタデータ操作を行うことが可能である。

これらにより，本発明は，利用者に負担をかけることなく，意味や説明の欠落，冗長性を排除した，一貫性の高いファイルシステムを提供することが可能である。

以下，本発明の実施の形態について図面を参照して説明する。図１は，本発明の概要を説明する図である。図１において，ファイル実体管理部１０は，ディスク装置１１１等に格納されたデータの集合であるファイルに対するアクセス機能を提供する手段であり，既存の一般的なオペレーティング・システム（ＯＳ）が持つファイル管理機能と同様な機能を持つものである。各ファイルには，ファイルを一意に識別するファイルＩＤ（ｆ１，ｆ２，…）が付与され，管理される。

メタデータ定義情報記憶部１２０は，各ファイルに対して定義された１または複数のメタデータ要素からなるメタデータを，各ファイルを識別するファイルＩＤとともに記憶する手段である。登録部１２は，メタデータ定義情報記憶部１２０にファイルＩＤと対応するメタデータの組を登録する処理を行う。

検索部１３は，ファイルの操作要求においてメタデータ要素のいくつかが指定されると，その指定されたメタデータ要素を含むメタデータに対応するファイルを，メタデータ定義情報記憶部１２０から検索し，検索結果のファイルを操作対象として決定する手段である。検索部１３は，メタデータ定義情報記憶部１２０を検索した結果のメタデータとそのメタデータに対応するファイルを識別するファイルＩＤのリストとの組の情報を記憶する検索結果キャッシュ機構１３３を持ち，指定されたメタデータに該当するファイルを検索する場合に，まず検索結果キャッシュ機構１３３を検索することにより，メタデータ検索の高速化を可能としている。

登録部１２および検索部１３によって，このファイルシステムにおけるディレクトリとファイルとの階層構造が，利用者の利用状況に応じて動的に構成されるようになっている。具体的には，以下のとおりである。

この例では，メタデータ定義情報記憶部１２０には，ファイルＩＤがｆ１のファイルに対して，ａ１，ａ２，ａ３，ａ４の値を持つ４個のメタデータ要素からなるメタデータが登録されている。ファイルＩＤがｆ２のファイルには，ａ１，ａ５，ａ３，ａ４の値を持つ４個のメタデータ要素からなるメタデータが登録されている。メタデータ要素の内容および個数は，ファイルの登録者がファイルごとに任意に定義することができる。ここでは，メタデータ要素の並びの順番は意味を持たず，利用者は必要に応じてメタデータ要素を並べ替えることができる。

また，メタデータ要素は，属性と値の組として定義することができる。ファイルＩＤがｆ３のファイルのメタデータ要素３，４およびｆ４のファイルのメタデータ要素４が，属性と値の組の例である。ここでは，“属性→値”として表記されており，ファイルＩＤがｆ３のファイルのメタデータ要素３の場合，“ｘ１”が属性，“ａ６”がその属性の値である。

本システムでは，ディレクトリ名とファイル名とがあらかじめ固定的に決まっているのではなく，利用者の利用状況に応じてメタデータ中のメタデータ要素の組から動的に生成される。例えば，ディレクトリとして“ａ１”のメタデータ要素が指定されると，“ａ１”のメタデータ要素を含むファイルが，ａ１のディレクトリ配下にあるファイルとしてすべて抽出される。

図１（Ｂ）は，その例を示している。図１（Ｂ）においてディレクトリ名として示している“Ｚ：￥ａ１”における“Ｚ：”は，ディスク装置１１１の装置名を指定するものであるが，本発明にとっては本質的なものではないため，以下の説明では省略する。検索部１３が，“￥ａ１”のディレクトリ名によってメタデータ定義情報記憶部１２０を検索すると，“ａ１”のメタデータ要素を含むｆ１，ｆ２，ｆ４のファイルが検索結果として得られる。これらの各ファイルをファイル操作インタフェースを介して利用者に提示する場合には，各ファイルのメタデータから“ａ１”のメタデータ要素を除いたメタデータ要素を“＿”で連結したものを，ファイル名とする。すなわち，ｆ１のファイルのファイル名は“ａ２＿ａ３＿ａ４”となる。また，ｆ２のファイルのファイル名は“ａ５＿ａ３＿ａ４”となる。また，ｆ４のファイルのファイル名は“ａ２＿ａ４＿ａ８（ｘ１）”となる。ここでは，メタデータ要素が属性と値の組である場合には，そのメタデータ要素は，“値（属性）”の形式で表示される。

また，例えばディレクトリとして“￥ａ１￥ａ２”というように，“ａ１”と“ａ２”のメタデータ要素が指定されると，“ａ１”と“ａ２”のメタデータ要素を含むメタデータに対応するファイルＩＤが，“￥ａ１￥ａ２”のディレクトリ配下にあるファイルとしてすべて抽出される。この例では，ｆ１とｆ４のファイルが該当し，これらのファイルの一覧が，それぞれ図１（Ｃ）のように“ａ３＿ａ４”および“ａ４＿ａ８（ｘ１）”のファイル名で表示されることになる。

同様に，図１（Ｄ）のように，ディレクトリとして“￥ａ３￥ａ４￥ａ５”という指定が行われると，ｆ２のファイルのメタデータだけが，“ａ３，ａ４，ａ５”のメタデータ要素を含むので，検索結果はｆ２のファイルとなり，ｆ３のファイルのメタデータから，ディレクトリで指定された“ａ３，ａ４，ａ５”のメタデータ要素を除いた“ａ１”のメタデータ要素がファイル名として表示される。

図２は，本発明のシステム構成例を示す図である。図２において，１は利用者が利用するファイルを管理するファイルサーバ，２は利用者が操作を行う利用者端末，３００はファイルサーバ１と利用者端末２を結ぶ通信路である。ファイルサーバ１は，ディスク管理部１１，登録部１２，検索部１３を有する。１００は後述するファイルサーバにファイルを登録する登録者，２００は本発明によるシステムを利用する利用者である。

ディスク管理部１１は，図１に示すファイル実体管理部１０に相当し，これには，ディスク装置１１１，ディスクアクセス機構１１２が含まれる。ディスク装置１１１は，ファイルを格納し，各ファイルにはディスク装置１１１上で一意な識別子（以下，ファイルＩＤという）が付与されている。

登録部１２には，メタデータ定義表１２１，メタデータ登録受付機構１２２，メタデータ生成機構１２３が含まれる。メタデータ定義表１２１は，図１に示すメタデータ定義情報記憶部１２０に相当し，ファイルＩＤごとのエントリからなる表（テーブル）である。一つのエントリは，ファイルＩＤとメタデータで構成される。ファイルＩＤは，前述のディスク装置１１１のファイルＩＤと対応しており，メタデータ定義表１２１内においても一意な識別子となる。

メタデータは，一つ以上のメタデータ要素からなるデータの列であり，メタデータ要素は「値」または「属性と値の組」のいずれかである。値は，任意の文字列や数値であり，例として“鈴木太郎”や“２００３／１／１”などが挙げられる。属性は，値の意味する内容を説明する任意の文字列であり，例として“作成者”や“更新日”などが挙げられる。

検索部１３には，メタデータ検索機構１３１，ファイル操作要求受付機構１３２，検索結果キャッシュ機構１３３が含まれる。検索結果キャッシュ機構１３３には，複数のキャッシュ内容が保持される。一つのキャッシュ内容は，ある“メタデータ”と，そのメタデータがメタデータ定義表１２１に含まれているファイルの“ファイルＩＤリスト”の組で構成される。前記“ファイルＩＤリスト”を，以降では“検索結果列”と表記する。

利用者端末２は，利用者２００との間のファイル操作情報に関する入出力を行うファイル操作インタフェース２１と，通信路３００を介してファイル操作情報に関するファイルサーバ１との通信を行うファイル操作要求部２２とを有する。

次に，本システムの動作について説明する。図３は，登録部１２の処理フローの一例を示す図である。登録者１００は，ファイルサーバ１へ登録するファイルを，登録部１２のメタデータ登録受付機構１２２から登録する。メタデータ登録受付機構１２２はその命令を受け付ける（ステップＳ１）。登録者１００からの命令を受け付けた登録部１２は，命令（登録者の要求）の種類を判定する（ステップＳ２）。

登録者１００からの命令が「登録」の場合には，ステップＳ３へ進む。ステップＳ３では，登録を要求されたファイル（実体）のコピーを作成して，そのコピーをディスク管理部１１へ渡す（ステップＳ３）。ディスク管理部１１は，ファイルをディスク装置１１１へ格納し，ディスク装置１１１上で一意なファイルＩＤを登録部１２へ返す。登録部１２は，そのファイルＩＤを取得する（ステップＳ４）。

登録部１２は，メタデータ登録受付機構１２２から登録されたファイル情報をメタデータ生成機構１２３へ移し，メタデータの生成を行う（ステップＳ５）。登録部１２は，ディスク管理部１１から渡されたファイルＩＤと，生成したメタデータの組でメタデータ定義表１２１のエントリを新規作成し（ステップＳ６），作成したエントリをメタデータ定義表１２１に登録する（ステップＳ７）。

登録者１００は，登録部１２のメタデータ登録受付機構１２２から，メタデータ定義表１２１に登録したメタデータの変更，削除を行うことができる。登録者１００が，メタデータ定義表１２１に登録したメタデータを変更する命令を出した場合，メタデータ登録受付機構１２２はその命令を受け付ける（ステップＳ１）。登録部１２は，登録者１００から受け付けた命令が「変更」であると判断すると（ステップＳ２），メタデータ定義表１２１のメタデータを変更し（ステップＳ８），検索部１３へ検索結果キャッシュのクリアを要求する（ステップＳ９）。これによって，検索部１３は，検索結果キャッシュ機構１３３のキャッシュ内容をクリアする。

また，登録部１２は，登録者１００から受け付けた命令が「削除」であると判断すると（ステップＳ２），メタデータ定義表１２１の指定されたメタデータ（要素）を削除し（ステップＳ１０），該当ファイルＩＤのメタデータ要素が一つもなくなったかどうかを判定する（ステップＳ１１）。該当ファイルＩＤのメタデータ要素が１以上残っている場合には，ステップＳ１４へ進み，検索部１３へ検索結果キャッシュのクリアを要求する。これによって，検索結果キャッシュ機構１３３のキャッシュ内容が削除される。

該当ファイルＩＤに対するメタデータ要素がすべてなくなった場合，登録部１２は，そのファイルＩＤで識別されるファイルの削除要求をディスク管理部１１へ送る（ステップＳ１２）。ディスク管理部１１は，ディスクアクセス機構１１２を用いて，ディスク装置１１１からファイルを削除する。次に，登録部１２は，メタデータ定義表１２１からそのファイルＩＤのエントリを削除する（ステップＳ１３）。登録部１２は，検索部１３へ検索結果キャッシュの削除を要求する（ステップＳ１４）。これによって，検索結果キャッシュ機構１３３のキャッシュ内容が削除される。

図４および図５は，検索部１３の処理フローの一例を示す図である。利用者２００は，利用者端末２のファイル操作インタフェース２１から，従来の階層構造のファイルシステムに対する操作と同様の，ディレクトリ内容の取得，ファイルの取得，ファイルのコピー，ファイルの削除，ファイルの移動，ファイルの新規作成の操作を行うことができる。

前記の各操作の要求には，要求の種別のほか，現在のディレクトリを表すメタデータも含まれる。ファイルの取得，ファイルの削除については，対象となるファイルＩＤも操作要求に含まれる。

ファイルのコピーについては，対象となるファイルＩＤに加え，ファイルのコピー先ディレクトリを表すメタデータ，コピー先のファイル名も操作要求に含まれる。ファイルの移動については，対象となるファイルＩＤに加え，ファイルの移動先ディレクトリを表すメタデータ，移動先のファイル名も操作要求に含まれる。ファイルの新規作成については，作成するファイル名も操作要求に含まれる。

前記の操作は，ファイル操作要求部２２から，通信路３００を介してファイルサーバ１の検索部１３へ渡され，ファイルサーバ１内部で処理が行われる。操作の処理結果は，検索部１３から通信路３００を介してファイル操作要求部２２に返され，ファイル操作インタフェース２１に表示される。

利用者端末２のファイル操作要求部２２から，ファイルサーバ１へ渡されたファイル操作要求は，検索部１３のファイル操作要求受付機構１３２で受け付けられ（ステップＳ２１），メタデータ検索機構１３１へ渡される。メタデータ検索機構１３１では，ファイル操作要求の種類が判断され（ステップＳ２２），ファイル操作要求の種類に応じて，それぞれ以下に説明する処理が行われる。

〔ディレクトリ内容の取得〕
ファイル操作要求が「ディレクトリ内容の取得」のとき（ステップＳ２２），メタデータ検索機構１３１は，ファイル操作要求に含まれるメタデータを先頭からメタデータ要素単位に分割し，検索メタデータ列を生成する（ステップＳ２３）。次に，メタデータ検索機構１３１は，検索処理を行う（ステップＳ２４）。この検索処理の詳細ついては図５に従って後述する。

メタデータ検索機構１３１は，ステップＳ２４の検索処理の後，検索結果が空であるかどうかを調べる（ステップＳ２５）。検索結果が空でなければ，メタデータ検索機構１３１は，検索結果のファイルＩＤのリスト，および，各ファイルＩＤのメタデータ定義表１２１で定義されているメタデータのうち，ファイル操作要求に含まれるメタデータを除いたものを，検索結果としてファイル操作要求受付機構１３２へ返す。ファイル操作要求受付機構１３２は，検索結果を利用者端末２のファイル操作要求部２２へ返す（ステップＳ２６）。検索結果が空であるとき，メタデータ検索機構１３１は，空の検索結果をファイル操作要求受付機構１３２へ返す。ファイル操作要求受付機構１３２は，空の検索結果を利用者端末２のファイル操作要求部２２へ返す（ステップＳ２７）。

図５を用いて上記ステップＳ２４に示した検索部１３の検索処理の詳細を説明する前に，その説明に用いるメタデータ定義表１２１の例と，検索結果キャッシュ機構１３３に保持されるキャッシュの例を説明する。図６は，メタデータ定義表の一例を示す図であり，図７は，検索結果キャッシュ機構１３３のキャッシュの一例を示す図である。

メタデータ定義表１２１には，例えば図６に示すように，各ファイルＩＤごとにメタデータ要素のデータ列からなるメタデータが登録されているものとする。図中のＡ，Ｂ，Ｃ，…，Ｅは，各ファイルに対して定義された「値」（「属性と値の組」でもよい）からなるメタデータ要素である。

検索結果キャッシュ機構１３３は，例えば図７に示すようなメタデータと検索結果列とを記憶する。検索結果キャッシュ機構１３３は，メタデータ定義表１２１の検索処理を高速化するために設けられており，一度，メタデータでメタデータ定義表１２１を検索した結果を記憶している。メタデータ定義表１２１が更新された場合には，メタデータ定義表１２１の内容とキャッシュ内容との一貫性維持のために，検索結果キャッシュ機構１３３におけるキャッシュ内容がクリアされる。

図７の例では，キャッシュａは，メタデータ“Ａ，Ｂ，Ｃ，Ｄ”の検索結果であり，メタデータ“Ａ，Ｂ，Ｃ，Ｄ”と，図６のメタデータ定義表１２１のメタデータに“Ａ，Ｂ，Ｃ，Ｄ”を含むファイルのファイルＩＤリストである「２」という検索結果列の対応情報が記憶されている。また，キャッシュｂは，メタデータ“Ａ，Ｅ”の検索結果であり，メタデータ“Ａ，Ｅ”と，図６のメタデータ定義表１２１のメタデータに“Ａ，Ｅ”を含むファイルのファイルＩＤリストである「１，３，４」という検索結果列の対応情報が記憶されている。また，キャッシュｃは，メタデータ“Ａ，Ｃ”の検索結果であり，メタデータ“Ａ，Ｃ”と，図６のメタデータ定義表１２１のメタデータに“Ａ，Ｃ”を含むファイルのファイルＩＤリストである「１，２」という検索結果列の対応情報が記憶されている。

図４に示すステップＳ２４の検索処理は，図５に示すように行われる。以下，メタデータ定義表１２１が図６に示す状態，検索結果キャッシュ機構１３３のキャッシュが図７に示す状態の場合を例に挙げて，検索部１３による処理内容を説明する。

メタデータ検索機構１３１は，検索結果キャッシュ機構１３３に，検索メタデータ列の一部，または全部がキャッシュのメタデータと一致するキャッシュ内容があるかを調べる（ステップＳ２４１）。

検索メタデータ列の全部がキャッシュのメタデータと一致するキャッシュ内容がある場合，メタデータ検索機構１３１は，キャッシュに含まれる検索結果列を，検索結果とする（ステップＳ２５６）。図８は，検索処理の例を説明するための図である。図８に示す検索メタデータ列が“Ｃ，Ａ”の例では，検索メタデータ列と図７に示すキャッシュｃのメタデータが一致するため，キャッシュａの検索結果列“１，２”が検索結果となる。

検索メタデータ列の一部だけがキャッシュのメタデータと一致するキャッシュ内容がある場合，メタデータ検索機構１３１は，キャッシュに含まれる検索結果列（ファイルＩＤリスト）を，現在の仮検索結果列とする。複数のキャッシュが該当する場合には，検索結果列の要素数が最も小さいキャッシュ内容を採用する。検索結果列の要素数が最も小さいキャッシュ内容も複数存在する場合には，先に検索されたものを採用する。

メタデータ検索機構１３１は，キャッシュのメタデータを，仮ディレクトリ列とする。さらにメタデータ検索機構１３１は，検索メタデータ列から，キャッシュのメタデータ（仮ディレクトリ列）と一致したメタデータ要素を取り除き（ステップＳ２４２），検索メタデータ列が空になるか，仮検索結果列が空になるまで，後述するキャッシュ確認後の処理を繰り返す（ステップＳ２４４〜Ｓ２５４）。

例えば，図８に示す初期の検索メタデータ列が“Ｃ，Ａ，Ｅ”の例では，検索メタデータ列の一部が，図７に示すキャッシュｂおよびキャッシュｃと一致する。メタデータ検索機構１３１は，この二つのキャッシュ内容のうち，検索結果列の要素数が最も小さいキャッシュｃのメタデータ“Ａ，Ｃ”を仮ディレクトリ列，同じくキャッシュｃの検索結果列“１，２”を現在の仮検索結果列とする。次に，検索メタデータ列“Ｃ，Ａ，Ｅ”から“Ａ，Ｃ”を取り除いた“Ｅ”を新しい検索メタデータ列（キャッシュ確認後の検索メタデータ列）とする。

検索メタデータ列の一部とも，キャッシュのメタデータと一致するキャッシュ内容がない場合，メタデータ検索機構１３１は，新規の要求として処理を行う。メタデータ検索機構１３１は，空の仮ディレクトリ列と，メタデータ定義表１２１のファイルＩＤのリストからなる仮検索結果列を生成し（ステップＳ２４３），検索メタデータ列が空になるか，仮検索結果列が空になるまで，後述するキャッシュ確認後の処理を繰り返す（ステップＳ２４４〜Ｓ２５４）。

例えば，図８に示す初期の検索メタデータ列が“Ｃ，Ａ，Ｂ”の例では，検索メタデータ列の一部に，キャッシュのメタデータが含まれるキャッシュ内容が図７に示すキャッシュに存在しない。メタデータ検索機構１３１は，空の仮ディレクトリ列と，図６に示すメタデータ定義表１２１のファイルＩＤのリスト“１，２，３，４，５”を仮検索結果列とする。

次に，キャッシュ確認後の処理動作（ステップＳ２４４〜Ｓ２５４）を説明する。まず，検索メタデータ列の先頭を検索メタデータ要素とし（ステップＳ２４５），その検索メタデータ要素の種類を判定する（ステップＳ２４６）。前述の通り，メタデータ定義表１２１のメタデータ要素には「属性と値の組」，「値」の二通りがある。これに対し，検索メタデータ要素は「属性」，「属性と値の組」，「値」の三通りとする。ここでは，「属性と値の組」を“属性→値”の書式で表記して説明する。

検索メタデータ要素が「属性」の場合，仮検索結果列にファイルＩＤが含まれ，かつ，そのファイルＩＤに対応するメタデータ定義表１２１のメタデータに，検索メタデータ要素で指定された「属性」と同じ属性を用いたメタデータ要素が含まれるファイルＩＤを抽出する（ステップＳ２４７）。例えば，検索メタデータ要素が“作成者→”の場合，“作成者→鈴木太郎”や“作成者→佐藤次郎”などのメタデータ要素が含まれたファイルＩＤが抽出される。

検索メタデータ要素が「属性と値の組」の場合，仮検索結果列にファイルＩＤが含まれ，かつ，そのファイルＩＤに対応するメタデータ定義表１２１のメタデータに，検索メタデータ要素で指定された「属性と値の組」と同じ組のメタデータ要素が含まれるファイルＩＤを抽出する（ステップＳ２４８）。例えば，検索メタデータ要素が“作成者→鈴木太郎”の場合，“作成者→鈴木太郎”のメタデータ要素が含まれたファイルＩＤが抽出される。

検索メタデータ要素が「値」の場合，仮検索結果列にファイルＩＤが含まれ，かつ，そのファイルＩＤに対応するメタデータ定義表１２１のメタデータに，検索メタデータ要素で指定された「値」と同じ値を用いたメタデータ要素が含まれるファイルＩＤを抽出する（ステップＳ２４９）。例えば，検索メタデータ要素が“鈴木太郎”の場合，“鈴木太郎”のほか，“作成者→鈴木太郎”や“管理者→鈴木太郎”などの属性が定義されたメタデータ要素が含まれたファイルＩＤも抽出される。

前記の検索結果によって得られたファイルＩＤのリストを，新しい仮検索結果列として置き換える（ステップＳ２５０）。検索メタデータ要素を，仮ディレクトリ列の最後尾に加え，新しい仮ディレクトリ列として置き換える（ステップＳ２５１）。

新しい仮ディレクトリ列と，新しい仮検索結果列の組を，検索結果キャッシュ機構１３３に登録する（ステップＳ２５２）。前記の処理で用いた先頭のメタデータ要素を取り除いたリストを，新しい検索メタデータ列として置き換え（ステップＳ２５３），メタデータ検索機構１３１は，ステップＳ２４４からＳ２５４までの処理を，検索メタデータ列か仮検索結果列が空になるまで繰り返す。検索メタデータ列が空になった時点の仮検索結果列を，検索結果とする（ステップＳ２５５）。仮検索結果列が空であれば，検索結果を空とする。

〔ファイルの取得〕
図４のステップＳ２２において，ファイル操作要求が「ファイルの取得」のとき，メタデータ検索機構１３１は，ファイル操作要求に含まれるファイルＩＤのファイル取得要求をディスク管理部１１へ送る。ディスク管理部１１は，ディスクアクセス機構１１２を用いて，ディスク装置１１１からファイルを取得し（ステップＳ２８），検索部１３へ返す。検索部１３は，取得したファイルの内容を，ファイル操作要求受付機構１３２から利用者端末２のファイル操作要求部２２へ返す（ステップＳ２９）。

〔ファイルのコピー〕
図４のステップＳ２２において，ファイル操作要求が「ファイルのコピー」のとき，メタデータ検索機構１３１は，ファイル操作要求に含まれるコピー先ディレクトリを表すメタデータを，先頭からメタデータ要素単位に分割する（ステップＳ３０）。次に，メタデータ検索機構１３１は，ファイル操作要求に含まれるファイルＩＤのメタデータ定義表１２１で定義されているメタデータに，前記の分割したコピー先のメタデータ要素，および，ファイル操作要求に含まれるコピー先ファイル名を加える（ステップＳ３１）。そして，検索部１３は，検索結果キャッシュ機構１３３のキャッシュ内容を削除する（ステップＳ３２）。

〔ファイルの削除〕
図４のステップＳ２２において，ファイル操作要求が「ファイルの削除」のとき，メタデータ検索機構１３１は，ファイル操作要求に含まれる現在のディレクトリを表すメタデータを，先頭からメタデータ要素単位に分割する。次に，メタデータ検索機構１３１は，ファイル操作要求に含まれるファイルＩＤのメタデータ定義表１２１で定義されているメタデータから，前記の分割したメタデータ要素と同一のメタデータ要素を削除する（ステップＳ３４）。

該当ファイルＩＤのメタデータ要素が一つもなくなった場合には，ステップＳ３５へ進み，一つ以上残っている場合には，ステップＳ３７へ進む（ステップＳ３４）。該当ファイルＩＤに対するメタデータ要素が０になったならば，検索部１３は，そのファイルＩＤで識別されるファイルの削除要求をディスク管理部１１へ送り（ステップＳ３５），ディスク管理部１１は，ディスクアクセス機構１１２を用いて，ディスク装置１１１からファイルを削除する。検索部１３は，メタデータ定義表１２１から，そのファイルＩＤのエントリを削除する（ステップＳ３６）。最後に検索部１３は，検索結果キャッシュ機構１３３のキャッシュ内容を削除する（ステップＳ３７）。

〔ファイルの移動〕
図４のステップＳ２２において，ファイル操作要求が「ファイルの移動」のとき，メタデータ検索機構１３１は，ファイル操作要求に含まれる現在のディレクトリを表すメタデータ，および，ファイル操作要求に含まれる移動先のディレクトリを表すメタデータを，各々先頭からメタデータ要素単位に分割する（ステップＳ３８）。

次に，メタデータ検索機構１３１は，ファイル操作要求に含まれるファイルＩＤのメタデータ定義表１２１で定義されているメタデータから，前記の現在のディレクトリを表すメタデータを分割したメタデータ要素と同一のメタデータ要素を削除する（ステップＳ３９）。また，メタデータ検索機構１３１は，同じくメタデータ定義表１２１で定義されているメタデータに，前記の移動先のディレクトリを表すメタデータを分割したメタデータ要素と同一のメタデータ要素，および，ファイル操作要求に含まれる移動先ファイル名を加える（ステップＳ４０）。その後，検索結果キャッシュ機構１３３のキャッシュ内容を削除する（ステップＳ４１）。

〔ファイルの新規作成〕
図４のステップＳ２２において，ファイル操作要求が「ファイルの新規作成」のとき，メタデータ検索機構１３１は，ファイル操作要求に含まれる現在のディレクトリを表すメタデータを，先頭からメタデータ要素単位に分割する（ステップＳ４２）。次に，メタデータ検索機構１３１は，ディスク管理部１１へファイルＩＤの作成を要求し，登録部１２へディスク管理部１１から取得したファイルＩＤと，前記のメタデータ要素にファイル操作要求に含まれる新規ファイル名を加えたものを渡し，メタデータ定義表１２１への登録を要求する（ステップＳ４３，Ｓ４４）。その後，検索結果キャッシュ機構１３３のキャッシュ内容を削除する（ステップＳ４５）。

〔本発明の実施例の構成の説明〕
図２に示したファイルサーバ１として，Ｗｉｎｄｏｗｓ（登録商標）ＯＳがインストールされたパソコン，また，利用者端末２としてＷｉｎｄｏｗｓ ＯＳがインストールされたパソコンとする。ディスクアクセス機構１１２としてＷｉｎｄｏｗｓ ＯＳのＮＴＦＳ（NT File System），また，登録部１２と検索部１３として，本発明を実現するためのアプリケーションソフトウェア，メタデータ定義表１２１におけるファイルＩＤとしてＮＴＦＳのファイルパス名およびファイル名の組を用いるものとする。

ファイル操作要求受付機構１３２の外部インタフェースは，ＷｅｂＤＡＶ（ＲＦＣ２５１８）に準拠するものとする。前記インタフェースにＷｅｂＤＡＶを利用するため，本実施例では，検索部１３にＷｅｂＤＡＶで渡されるパス名を，ディレクトリを表すメタデータとみなし，ファイル名をファイルＩＤを特定するための情報として用いる。検索結果キャッシュ機構１３３としてファイルサーバ１のメモリを用いるものとする。検索結果キャッシュ機構１３３の容量は有限であるため，ＬＲＵ（Last Recently Used）方式で領域を管理するものとする。

ファイル操作インタフェース２１としてＷｉｎｄｏｗｓ ＯＳ付属ソフトウェアのエクスプローラ，ファイル操作要求部２２としてＷｉｎｄｏｗｓ ＯＳ付属のＷｅｂＤＡＶ（Web Distributed Authoring and Versioning）クライアント機能のＷｅｂフォルダ・ソフトウェア，通信路３００はＩＰ（Internet Protocol ）による通信網とする。

利用者２００がファイル操作インタフェース２１（エクスプローラ）を用いて，フォルダを開く，ファイルをダブルクリックする，ファイルのコピーを行う，ファイルの削除を行う，ファイルの移動を行う，の各動作を実行した際，本発明におけるファイル操作要求，すなわちディレクトリ内容の取得，ファイルの取得，ファイルのコピー，ファイルの削除，ファイルの移動の各要求が発生したとみなす。

〔本発明の実施例の動作の説明〕
ここでは，登録者１００がファイルの登録を行った際の動作，および，利用者２００がファイル操作インタフェース２１（エクスプローラ）からファイル操作要求を行った際の動作を説明する。

登録者１００がディスクアクセス機構１１２（ＮＴＦＳ）上の“＃１”〜“＃１０”というファイルを登録部１２へ渡す。登録部１２は，この１０個のファイルをメタデータ定義表１２１へ登録する。本実施例では，ファイルＩＤはディスクアクセス機構１１２上のパス名とファイル名の組とする。登録者１００は，各ファイルに対して，例えば図９に示す内容でメタデータ定義を行う。図９のメタデータ定義表１２１では，最大４個のメタデータ要素（１〜４）を持つ例を示しているが，メタデータ要素の個数はファイルごとに任意に定義することができる。各ファイルに対して定義されるメタデータ要素の順番は階層構造的な意味はなく，必要に応じて並べ換えることができる。

また，図９のメタデータ定義表１２１では，各メタデータ要素は“写真”，“旅行”，“河口湖”，…というような「値」で定義されているが，例えば“旅行先→河口湖”というような属性（旅行先）と値（河口湖）の組で定義することもできる。

メタデータ要素は，ファイルの形式や他の属性などから自動的に定義することもでき，例えば，ファイルがＥｘｉｆ（Exchangeable Image File Format；JEIDA-49）形式の画像ファイルであれば，Ｅｘｉｆのタグである画素数，圧縮モード，カメラの機種名，絞り値，シャッター速度，撮影日時などをメタデータの「属性」，その値をメタデータの「値」として，メタデータ要素を追加するような実施も可能である。同様に，ファイルがＭＰ３（MPEG Audio Layer-3）形式の音楽ファイルであれば，ＩＤ３ｖ２（RFC3003 ）タグである曲名，アルバム名，演奏者名などをメタデータの「属性」，その値をメタデータの「値」として，メタデータ要素を追加することも可能である。

利用者２００がファイル操作インタフェース２１（エクスプローラ）でフォルダを開くと，ＷｅｂＤＡＶクライアントは，ディレクトリを引数としたＧＥＴコマンドを，ファイル操作要求受付機構１３２へ送信する。検索部１３のメタデータ検索機構１３１は，ＧＥＴコマンドの引数であるディレクトリをファイル操作要求に含まれるメタデータとして前述の処理を行う。

検索部１３のファイル操作要求受付機構１３２は，検索結果に含まれる全てのファイルＩＤについて，ファイルＩＤに対応する各メタデータ要素を“＿”文字で連結したものを，そのファイルＩＤに対応するファイルのファイル名とし，一覧をＷｅｂＤＡＶクライアントへＧＥＴコマンドの応答として返す。

例えば，「湖畔の写真を探したい」という目的で，“／湖畔／写真／”というディレクトリに対するＧＥＴコマンドが送信された場合，検索部１３の検索結果は，「＃１」と「＃５」の二つのファイルＩＤとなり，ＧＥＴコマンドの応答として返されるファイル名は，“旅行＿河口湖”と“旅行＿十和田湖”の二つとなる。

利用者２００がファイル操作インタフェース２１でファイルをダブルクリックすると，ＷｅｂＤＡＶクライアントは，ファイル名を引数としたＧＥＴコマンドを，ファイル操作要求受付機構１３２へ送信する。検索部１３のメタデータ検索機構１３１は，ＧＥＴコマンドの引数であるファイル名をファイル操作要求に含まれるメタデータとして前述の処理を行う。この際，ファイル名に“＿”文字が含まれている場合には，“＿”文字を区切り文字としてさらにメタデータ要素へ分割する。

検索部１３のファイル操作要求受付機構１３２は，検索結果のファイルＩＤに対応するファイルの内容を，ディスクアクセス機構１１２から読み出し，ＷｅｂＤＡＶクライアントへＧＥＴコマンドの応答として返す。また，検索結果のファイルＩＤが複数になった場合には，最も値の小さいファイルＩＤに対して前述の処理を行うものとする。

例えば，「湖畔の写真を探して出てきた一つを見たい」という目的で，“／湖畔／写真／旅行＿河口湖”というファイルに対するＧＥＴコマンドが送信された場合，検索部１３の検索結果は「＃１」のファイルＩＤとなり，このファイルの内容がＧＥＴコマンドの応答として返される。

利用者２００がファイル操作インタフェース２１でファイルをコピーすると，ＷｅｂＤＡＶクライアントは，コピー元とコピー先を引数としたＣＯＰＹコマンドを，ファイル操作要求受付機構１３２へ送信する。検索部１３のメタデータ検索機構１３１は，ＣＯＰＹコマンドの引数であるコピー先を，コピー先ディレクトリを表すメタデータ，およびコピー先ファイル名を表すメタデータの組として前述の処理を行う。

例えば「河口湖へ旅行に行ったときの愛車の写真に，車とドライブというメタデータを追加したい」という目的で，“／河口湖／旅行／愛車／写真”というファイルを“／車／ドライブ”というファイルとしてコピーするＣＯＰＹコマンドが送信された場合，検索部１３の検索結果は，「＃３」のファイルＩＤとなり，メタデータ定義表１２１における前述のファイルＩＤが示すエントリに対して，“車”，“ドライブ”のメタデータ要素が追加される。

利用者２００がファイル操作インタフェース２１でファイルを削除すると，ＷｅｂＤＡＶクライアントは，ファイル名を引数としたＤＥＬＥＴＥコマンドを，ファイル操作要求受付機構１３２へ送信する。検索部１３のメタデータ検索機構１３１は，ＤＥＬＥＴＥコマンドの引数であるファイル名をファイル操作要求に含まれるメタデータとして前述の処理を行う。当該ファイルＩＤに対するメタデータ要素が一つもなくなった場合，検索部１３は，そのファイルＩＤで識別されるファイルの削除要求をディスクアクセス機構１１２へ送り，ディスク装置１１１からファイルを削除する。

例えば，“／旅行／河口湖／湖上祭／写真”というファイルを削除するＤＥＬＥＴＥコマンドが送信された場合，検索部１３の検索結果は「＃２」というファイルＩＤとなり，メタデータ定義表１２１における前述のファイルＩＤが示すエントリから，“写真”，“旅行”，“河口湖”，“湖上祭”のメタデータ要素が削除される。この際，前述のファイルＩＤが示すエントリのメタデータ要素がなくなり，該当のファイル，および，メタデータ定義表１２１におけるエントリも削除される。

利用者２００がファイル操作インタフェース２１でファイルを移動すると，ＷｅｂＤＡＶクライアントは，移動元と移動先を引数としたＭＯＶＥコマンドを，ファイル操作要求受付機構１３２へ送信する。検索部１３のメタデータ検索機構１３１は，ＭＯＶＥコマンドの引数である移動先を，移動先ディレクトリを表すメタデータ，および移動先ファイル名を表すメタデータの組として前述の処理を行う。

例えば，“／写真／旅行／河口湖／愛車”というファイルを“／写真／車／ドライブ”というファイルへ移動するＭＯＶＥコマンドが送信された場合，検索部１３の検索結果は「＃３」のファイルＩＤとなり，メタデータ定義表１２１における前述のファイルＩＤが示すエントリから，“写真”，“旅行”，“河口湖”，“愛車”のメタデータ要素が削除される。次に，同じエントリへ“写真”，“車”，“ドライブ”のメタデータ要素が追加される。

図１０および図１１は，ファイル操作インタフェース２１の表示画面の例を示す図である。利用者端末２においてエクスプローラを起動し，Ｗｅｂフォルダを開くと，図１０（Ａ）に示すような，あらかじめ定義されたファイルサーバ１を示すアイコンが表示される。“ＦＳ１０００”は，ファイルサーバ１のホスト名である。ここで，利用者２００が“ＦＳ１０００”のアイコンをマウスなどによりダブルクリックすると，ファイルサーバ１から，図９に示すメタデータ定義表１２１の検索結果をもとに，ファイルごとに全てのメタデータ要素を“＿”で連結したファイル名の一覧が返却され，ファイル操作インタフェース２１の表示画面には，図１０（Ｂ）に示すようなファイル名一覧が表示される。

ここで，利用者２００が，例えばエクスプローラの表示画面のアドレス欄に，“／湖畔／写真”というディレクトリを指定する文字列を追加し，ディレクトリ内容の取得要求を行うと，図１１（Ａ）に示すような“旅行＿河口湖”と“旅行＿十和田湖”の２つのファイル名の一覧が表示画面に表示されることになる。

同様に，図１０（Ｂ）に示す表示画面のアドレス欄に，“／河口湖”というディレクトリを指定する文字列を追加し，ディレクトリ内容の取得要求を行うと，図１１（Ｂ）に示すような“写真＿旅行＿愛車”と“写真＿旅行＿湖上祭”と“写真＿旅行＿湖畔”と“写真＿旅行＿富士山”の４つのファイル名の一覧が表示画面に表示されることになる。

利用者２００は，これらの表示画面において，ファイルを選択しダブルクリックすることにより，そのファイルを取得することができる。また，ファイルを選択した後，「コピー」ボタン，「削除」ボタン，「移動」ボタン等をクリックすることにより，ファイルのコピー操作，ファイルの削除操作，ファイルの移動操作等を実行することができる。

上記本発明の実施例で挙げたネットワークファイルシステムとしての構成のほか，登録部１２と検索部１３をＵＮＩＸ（登録商標）ＯＳのローカルファイルシステムとして実現し，ファイル操作要求部２２にＵＮＩＸ ＯＳのファイルシステム・マウント機能，ファイル操作インタフェース２１としてＵＮＩＸ ＯＳのシェル，メタデータ定義表１２１におけるファイルＩＤとしてローカルファイルシステムのｖｎｏｄｅを利用することも可能である。

実施例によっては，ファイル操作要求部２２の機能をファイルサーバ１側に備える構成，検索部１３の機能を利用者端末２側に備える構成，ファイルサーバ１と利用者端末２の機能を同一の装置に備える構成も可能である。また，一つのファイル操作要求部２２から複数ファイルサーバの検索部１３を利用する構成，一つの検索部１３が複数のファイル操作要求部２２から要求を受け付ける構成をとることも可能である。

以上の登録部１２，検索部１３等が行う処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。

本発明の概要を説明する図である。 本発明のシステム構成例を示す図である。 登録部の処理フローの一例を示す図である。 検索部の処理フローの一例を示す図である。 検索部の処理フローの一例を示す図である。 メタデータ定義表の一例を示す図である。 キャッシュの一例を示す図である。 検索処理の例を説明するための図である。 メタデータ定義表の具体例を示す図である。 ファイル操作インタフェースの表示画面の例を示す図である。 ファイル操作インタフェースの表示画面の例を示す図である。

符号の説明

１ ファイルサーバ
２ 利用者端末
１１ ディスク管理部
１２ 登録部
１３ 検索部
２１ ファイル操作インタフェース
２２ ファイル操作要求部
１００ 登録者
１１１ ディスク装置
１１２ ディスクアクセス機構
１２１ メタデータ定義表
１２２ メタデータ登録受付機構
１２３ メタデータ生成機構
１３１ メタデータ検索機構
１３２ ファイル操作要求受付機構
１３３ 検索結果キャッシュ機構
２００ 利用者

Claims (7)

1. コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するファイル管理装置において，
   各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，
   前記メタデータ定義情報記憶手段へのファイルＩＤとメタデータの登録，前記メタデータ定義情報記憶手段に登録されたファイルＩＤとメタデータの変更および削除を行う登録手段と，
   ファイルの検索要求における前記ディレクトリの名称の指定が，前記メタデータ要素のいくつかの指定により行われた場合に，前記メタデータ定義情報記憶手段に記憶されたメタデータの中で，前記ディレクトリの名称として指定されたメタデータ要素をすべて含むメタデータを検索し，検索された各メタデータ中から前記ディレクトリの名称として指定されたメタデータ要素を除いたメタデータ要素の組を検索結果のファイルの名称として定義し，前記ディレクトリの名称と前記検索結果のファイルの名称の一覧を利用者に提示する手段とを備える
   ことを特徴とするファイル管理装置。
2. 請求項１記載のファイル管理装置において，
   前記メタデータ定義情報記憶手段に登録されるメタデータを構成するメタデータ要素は，ファイルの意味を表す値または属性と値の組である
   ことを特徴とするファイル管理装置。
3. 請求項１または請求項２記載のファイル管理装置において，
   前記検索手段は，前記メタデータ定義情報記憶手段を検索した結果のメタデータとそのメタデータに対応するファイルを識別するファイルＩＤのリストとの組の情報を記憶する検索結果キャッシュ機構を持ち，指定されたメタデータに該当するファイルを前記検索結果キャッシュ機構により特定し，前記検索結果キャッシュ機構により特定できなかった場合に前記メタデータ定義情報記憶手段を検索する
   ことを特徴とするファイル管理装置。
4. コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するとともに，各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，前記ファイルシステムへのファイルの登録手段と，ファイルを操作するファイル操作手段とを備えるコンピュータが，ファイルシステムにおけるディレクトリとファイルとの階層構造を，利用者の利用状況に応じて動的に構成する動的名前空間生成方法であって，
   前記ファイルの登録手段が，登録対象のファイルのファイルＩＤと，そのファイルに対して定義される１または複数のメタデータ要素の集合であるメタデータとの組を，前記メタデータ定義情報記憶手段に登録するステップと，
   前記ファイル操作手段が，前記メタデータ定義情報記憶手段に登録された各ファイルごとのメタデータの中の，利用者から指定されたメタデータ要素の組をディレクトリの名称とし，該メタデータから前記ディレクトリの名称として用いられたメタデータ要素を除いた残りのメタデータ要素の組をファイルの名称として利用者に提示し，前記メタデータ要素の組から構成される，前記ディレクトリの名称と前記ファイルの名称との組によってファイルを特定する処理を行うステップとを有する
   ことを特徴とする動的名前空間生成方法。
5. コンピュータで扱うデータの集合であるファイルを，ディレクトリとファイルとの階層構造により管理し，ディレクトリの名称とファイルの名称との組み合わせから各ファイルを識別するファイルＩＤを特定するファイルシステムを有するとともに，各ファイルに対して定義された１または複数のメタデータ要素の集合であるメタデータを，前記ファイルＩＤに対応づけて記憶するメタデータ定義情報記憶手段と，前記ファイルシステムへのファイルの登録手段と，ファイルを操作するファイル操作手段とを備えるコンピュータが，ファイルシステムにおけるディレクトリとファイルとの階層構造を，利用者の利用状況に応じて動的に構成する動的名前空間生成方法であって，
   前記ファイルの登録手段が，登録対象のファイルのファイルＩＤと，そのファイルに対して定義される１または複数のメタデータ要素の集合であるメタデータとの組を，前記メタデータ定義情報記憶手段に登録するステップと，
   前記ファイル操作手段が，前記ファイルシステムにおけるファイル操作インタフェースから受け付けたファイル操作要求の種類に応じたファイル操作を行うステップとを有し，
   前記ファイル操作手段が前記ファイル操作を行うステップでは，前記ファイル操作インタフェースから受け付けたファイル操作要求の種類がディレクトリ内容の取得である場合に，前記ファイル操作要求に含まれるメタデータをメタデータ要素に分割し，分割したメタデータ要素をすべて含むメタデータに対応するファイルＩＤを前記メタデータ定義情報記憶手段から検索し，検索したファイルＩＤのリスト，または検索したファイルＩＤに対応するメタデータ，または検索したファイルＩＤに対応するメタデータから前記ファイル操作要求に含まれるメタデータ中のメタデータ要素を除いた残りのメタデータを，前記ファイル操作要求の要求元へ返却する
   ことを特徴とする動的名前空間生成方法。
6. 請求項５記載の動的名前空間生成方法において，
   前記ファイル操作インタフェースとして，固定的なディレクトリと固定的なファイル名とを扱う既存のインタフェースを用い，該ファイル操作インタフェースを用いたファイル操作を，ディレクトリとファイル名とが利用者の利用状況に応じて動的に変化するメタデータ操作に変換するステップを有する
   ことを特徴とする動的名前空間生成方法。
7. 請求項４から請求項６までのいずれか１項に記載の動的名前空間生成方法を，コンピュータに実行させるための動的名前空間生成プログラム。

Images