(57)【要約】【課題】管理対象データに付随するメタデータやログ情報を参照し、事前に設定されたポリシーに従って、システムの振舞いを変更するデータ管理システムにおいて、必要なメタデータやログ情報のデータ量の増大を抑えながら、管理対象データの粒度を縮小すると共に定義可能なポリシーの表現力を増して、効率的な情報ライフサイクル管理を行う。【解決手段】業務レベルで参照される用語間の関係を定義するオントロジを導入し、ポリシーと合わせて解析することで、情報取得が必要な範囲を明確に決定できるようにして、設定変更に要する手間を削減し、運用管理コストを削減すると共に必要リソースの最適化を図る。【選択図】図１
2006318146.tif 000002
【特許請求の範囲】
【請求項１】
業務データやメールなどのデータリソース集合のそれぞれのデータリソースに対して適用されるデータ管理方式を、データリソースに付随するメタデータあるいはアクセスログ情報を参照して決定する情報ライフサイクル管理システムにおいて、
前記各データリソースのメタデータあるいはログ情報の管理方法に関する設定を変更するメタデータ/ログ情報設定変更手段を有することを特徴とする情報管理システム。
【請求項２】
請求項１に記載の情報ライフサイクル管理システムにおいて、事前に登録された各データリソースに付随するメタデータあるいはアクセスログ情報と前記データリソースに対して適用されるデータ管理方式との対応付けを行なうポリシーの定義内容を解析した結果に基づき、前記メタデータ/ログ情報設定変更手段への指示を決定するポリシー解析手段を有することを特徴とする情報管理システム。
【請求項３】
請求項２に記載の情報ライフサイクル管理システムにおいて、前記ポリシー解析手段がポリシーの定義内容の解析を行なう際に、ポリシー記述に利用される用語間の関係を定義するオントロジを参照して、前記メタデータ/ログ情報設定変更手段への指示を決定することを特徴とする情報管理システム。
【請求項４】
請求項３に記載の情報ライフサイクル管理システムにおいて、前記ポリシー解析手段は、定義済みポリシーにおいて参照されるメタデータ/ログ情報の項目を特定し、特定された項目に対してのみメタデータ/ログ情報の取得を行なうように前記メタデータ/ログ情報設定変更手段へ指示を行なうことを特徴とする情報管理システム。
【請求項５】
請求項３に記載の情報ライフサイクル管理システムにおいて、前記ポリシー解析手段は、定義済みポリシーにおいて参照されるメタデータ/ログ情報の範囲を特定し、メタデータ/ログ情報の取得を特定された範囲に対して行なうよう前記メタデータ/ログ情報設定変更手段へ指示を行なうことを特徴とする情報管理システム。
【請求項６】
請求項３に記載の情報ライフサイクル管理システムにおいて、前記ポリシー解析手段は、定義済みポリシーにおいて参照されるメタデータ/ログ情報の範囲を特定し、特定された範囲を外れるメタデータ/ログ情報を削除するよう前記メタデータ/ログ情報設定変更手段へ指示を行なうことを特徴とする情報管理システム。
【請求項７】
請求項３に記載の情報ライフサイクル管理システムにおいて、前記オントロジに当該情報管理システムで参照可能なメタデータ/ログ情報の範囲が定義されており、前記ポリシー解析手段は、定義済みポリシーにおいて参照されるメタデータ/ログ情報の内容が前記オントロジに登録された範囲を逸脱する場合は、当該ポリシーの判定を行なえないことを検知することを特徴とする情報管理システム。
【請求項８】
請求項３に記載の情報ライフサイクル管理システムにおいて、前記オントロジに当該情報管理システムにて適用可能なデータ管理に関するコマンドの範囲が定義されており、前記ポリシー解析手段は、定義済みポリシーにおいて指定されるデータ管理に関するコマンドの内容が前記オントロジに登録された範囲を逸脱する場合は、当該ポリシーの適用を行なえないことを検知することを特徴とする情報管理システム。
【請求項９】
請求項７あるいは８のいずれかに記載の情報ライフサイクル管理システムにおいて、前記ポリシーに当該ポリシーが評価あるいは適用されない場合に実行されるエラーコマンドに関する記述を含み、前記ポリシー解析手段は、ポリシーの判定あるいは適用を行なえないことを検知した場合に、ポリシーに記述されたエラーコマンドを実行するよう指示を出すことを特徴とする情報管理システム。
【請求項１０】
請求項７あるいは８のいずれかに記載の情報ライフサイクル管理システムにおいて、事前定義されたポリシーと管理対象であるデータリソースを参照するサービス群との間の依存関係を保持し、前記ポリシー解析手段において、ポリシーの判定あるいは適用を行なえないことを検知した場合に、当該ポリシーに依存するサービスの停止を行なうサービス実行制御手段を有することを特徴とする情報管理システム。
【請求項１１】
オフィス文書やメールなどのデータリソース集合の管理及び前記リソース集合に関する１つあるいは複数のメタデータ及びログ情報の取得を行い情報ライフサイクル管理エンジン内のメタデータ/ログ情報レジストリに対する登録を行なうリソース管理システム、
前記リソース集合の個々のリソースと当該リソースの業務区分との対応関係を定義する１つあるいは複数のオントロジを情報ライフサイクル管理エンジン内のオントロジ定義レジストリに対して登録を行なうオントロジ定義モジュール、
前記リソース管理システムが管理する前記リソース集合の管理方針である１つあるいは複数のポリシーを前記オントロジレジストリに登録されたオントロジの業務区分を参照して定義し、情報ライフサイクル管理エンジン内のポリシー定義レジストリに対して登録を行なうポリシー定義モジュール、及び
前記オントロジ定義手段によって定義された１つあるいは複数のオントロジと前記ポリシー定義手段によって定義された１つあるいは複数のポリシーを参照して、前記リソース管理システムにおける前記リソース集合に対する管理操作を決定する情報ライフサイクル管理エンジン、を備えた情報ライフサイクル管理システムにおいて
前記リソース管理システムは、前記リソース集合に対する管理を行なうためのリソース集合管理手段、及び前記リソース集合に関するメタデータ及びログ情報を取得するメタデータ/ログ情報取得手段を備え、
前記オントロジ定義モジュールは、前記情報ライフサイクル管理エンジン内のオントロジ定義レジストリに対して登録を行なうオントロジ定義手段を備え、
前記ポリシー定義モジュールは、前記情報ライフサイクル管理エンジン内のポリシー定義レジストリに対して登録を行なうポリシー定義手段を備え、
前記情報ライフサイクル管理エンジンは、前記オントロジ定義プログラムによって登録された前記オントロジを格納するオントロジ定義レジストリ、
前記ポリシー定義プログラムによって登録された前記ポリシーを格納するポリシー定義レジストリ、前記リソース管理システムによって登録された前記メタデータ及びログ情報を格納するメタデータ/ログ情報レジストリ、
前記ポリシー定義レジストリに格納されたポリシーを、前記オントロジで定義された業務区分を利用してリソースの絞り込みを行なうポリシー条件部と前記絞り込まれたリソースに対して適用する操作内容を指示するポリシーコマンド部に分離し、前記ポリシー条件部を対象リソース決定手段へ受け渡し、前記ポリシーコマンド部をコマンド実行手段に受け渡すポリシー解析手段、
前記ポリシー解析手段から受け渡された前記ポリシー条件部から、前記オントロジレジストリに登録されたオントロジ、さらに前記メタデータ/ログ情報レジストリに登録されたメタデータ及びログ情報を参照して、前記コマンド部で支持されたコマンドの適用対象リソースを決定する対象リソース決定手段、及び
前記対象リソース決定手段から受け渡された対象リソースに対して、前記ポリシー解析手段から受け渡されたポリシーコマンド部で指示された操作を適用するコマンド実行手段を備え、
前記情報ライフサイクル管理エンジンは、前記ポリシー定義レジストリに登録された各ポリシーに関して、当該ポリシーのポリシー条件部で参照されている業務区分に関して、前記オントロジ定義レジストリに登録されたオントロジを参照し、対応するリソース集合を特定し、対応する前記リソース集合に関するメタデータ及びログ情報の取得方法を変更するように前記メタデータ/ログ情報取得手段における設定変更を行なうためのメタデータ/ログ情報収録設定変更手段を有することを特徴とする情報管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータの業務上の価値に応じてデータ管理方法を決定する情報ライフサイクル管理システムに係わり、特に “管理対象データの分類基準と分類されたデータに対して適用するデータ管理方法との対応付け“を行なうポリシー群を事前に定義しておき、定義されたポリシーの内容に従い、管理対象データの管理方法の決定を行なうシステムに関する。
【背景技術】
【０００２】
一般にＩＬＭ(Information Lifecycle Management)と呼ばれる情報ライフサイクル管理を実現する情報管理システムでは、データの生成から廃棄に至る一連のライフサイクルにおいて、管理対象データの業務的価値が時間的に変化することに着目し、予め指定されたポリシーに従って、その時々の業務的価値に応じて適切なデータ管理方法を選択/適用することで、システム全体におけるデータ管理コスト削減を目指す。
【０００３】
例えば、「直近一ヶ月における利用頻度の高い有望顧客に関しては、関連する取引データを信頼性の高いディスク装置に配置する」などのポリシーを定義した場合、個々の顧客に関する利用ログなどを参照した上で、ポリシーに照らしてその重要度を判断し、対応する取引データを信頼性やバイト単価の異なるディスク装置に自動的に移動することで、システムのトータルコスト（機器コスト、運用コスト含む）を低減する。管理対象データに付随するメタデータや蓄積されるログ情報の内容を参照して、時間経過と共に変化する管理対称データの業務価値を判断し、実施コストの異なる様々なデータ管理方法を自動的に使い分けることで、システム全体で必要となるデータ管理コストを低減させることとなる。
【０００４】
管理対象データに対するデータ管理方法の適用方針を定義するポリシーは、データ管理方法の変更操作における操作対象データを絞り込むための条件部と操作内容を指示するコマンド部からなる。情報ライフサイクル管理を実用システムに対して適用する場合、ポリシーの条件部の記述においては、ファイルシステムなどから得られるデータ作成日時や最終アクセス日時情報などの単純なメタデータだけでは不十分で、顧客区分や文書の業務分類など業務レベルの概念を用いて条件設定を行ないたいとのニーズが強い。
【０００５】
また一般に、管理対象データの粒度がより細かく、またより複雑な条件のポリシー記述が可能な程、木目の細かい効率の良いデータ管理を実現することが出来る。しかし、データの管理単位を細かくし、ポリシーの記述範囲を拡大すると共に、個々の管理対象データについて取得が必要となるメタデータやログ情報の範囲が拡大し、情報ライフサイクル管理の実施コスト増大につながる。
【０００６】
情報ライフサイクル管理の実現において、業務レベルでのポリシー定義を可能にしたり、メタデータやログ情報の収録管理コストを削減したりするために利用可能と思われる従来の技術を列挙すると、以下の通りである。
“Query Processing, Resource Management, and Approximation in a Data Stream Management System“,CIDR2003（非特許文献１）には検索処理対象となる各データリソースに対して、ウインドウ条件（件数やデータ生成時刻等に関する制限）が設定され、検索処理対象となるデータの範囲を問合せ毎に明示的に指定して、限定する技術が開示される。この技術を「ストリームＤＢ方式」と呼ぶ。
【０００７】
“Implementing Data Cubes Efficiently“,SIGMOD96（非特許文献２）は、データベースシステムでの検索処理において、予め頻繁に投入されることが予想される検索処理の共通部分について、事前にその一部を実行し結果を保持することで、検索処理効率の向上を図る技術を開示する。この技術を「マテリアライズドビュー方式」と呼ぶ。
【０００８】
Hector Garcia-Molina, Jeffery D. Ullman, Jennifer Widom著、“Ｄａｔａbase System Implementation“、p.605-p.612（非特許文献３）には、「ラッパー」と呼ばれるデータ形式変換プログラムと「メディエータ」と呼ばれる個別データからより上位の概念に相当するデータを生成するプログラムとを予め定義し、個別データを業務レベルの概念と対応させ、業務レベルの用語を用いて検索処理の定義を行なえるようにする技術が開示される。この技術を「ラッパーアンドメディエータ方式」と呼ぶ。
上記三つのいずれの方式においても、システムに投入された問合せの内容に応じて、検索対象となるデータ本体に対して適用される問合せ処理の内容を変更することを行なっているが、データ本体そのものに対しては影響を及ぼさない。
【０００９】
【非特許文献１】Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Singh Manku, Chris Olston, Justin Rosenstein, Rohit Varma: “Query Processing, Approximation, and Resource Management in a Data Stream Management System“ CIDR 2003
【００１０】
【非特許文献２】Venky Harinarayan, Anand Rajaraman, Jeffrey D. Ullman: “Implementing Data Cubes Efficiently“ SIGMOD Conference 1996: pp.205-216
【非特許文献３】Hector Garcia-Molina, Jeffery D. Ullman, Jennifer Widom, “Ｄａｔａbase System Implementation“ pp.605-612
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記「ストリームＤＢ方式」「マテリアライズドビュー方式」および「ラッパーアンドメディエータ方式」では、システムに投入された問合せの内容に応じて、対象となるデータ本体に対して適用される問合せ処理の内容を変更することを行なっている。しかし、上記従来のいずれの方法も、例えば情報ライフサイクル管理の実現に適用した場合にデータリソースに付随するメタデータ/ログ情報の管理方法に対して変更を加えるものとはならない。
【００１２】
事前に設定されたポリシーに従って、管理対象データに付随するメタデータやログ情報を参照し、システムの振舞いを変更するデータ管理システムにおいて、より柔軟で実務的な管理を実現するためには、ポリシー定義で利用できる用語を拡大したり、管理対象データの粒度を縮小したりするなどしてポリシーの表現力を増すことが望まれる。しかし、そのためにポリシー記述の複雑化や保持が必要なメタデータやログ情報のデータ量が増大したのでは管理コストがかえって増大する。したがって本発明ではポリシー定義を容易にし、管理コスト増大を抑えながら、効率的で柔軟な情報ライフサイクル管理を実現することを課題とする。
【課題を解決するための手段】
【００１３】
ポリシーの定義内容に応じて取得が必要なメタデータやログ情報の範囲が変化するが、本発明では、ポリシー記述で使用される業務レベルの用語とメタデータやログ情報との間の対応関係を定義するオントロジを導入し、ポリシーと合わせて解析することで、情報取得が必要な範囲を明確に決定できるようにして、ポリシー定義容易化と運用管理コスト削減を図る。
【００１４】
本発明では、設定されたポリシーの内容に応じて、データリソースに付随するメタデータログ情報に対してその管理に関する設定変更を行なう場合があり、例えばログ情報に対する参照が過去１ヶ月に限定される場合は、１ヶ月より古いログ情報を自動的に削除することを行なう。このように、本発明方式では、情報ライフサイクル管理実現のためにデータリソースに付随するメタデータ/ログ情報の管理方法の変更を行なう点が上述の従来技術と大きく異なる。
【発明の効果】
【００１５】
事前定義されたポリシーに基づき、リソース管理の最適化を図る情報ライフサイクル管理システムでは、複雑なポリシーを定義しようとしたり、管理対象となるリソースの数を増大させようとしたりすると、取得が必要なメタデータやログ情報の種別も膨大となり、その取得に要するコストが増大する。
【００１６】
本発明では、ポリシー定義を行なう際に利用される業務レベルの用語と管理対象データに付随するメタデータやログ情報との間の対応関係を定義するオントロジを導入し、個別システムにおけるメタデータ/ログ情報の取得可能性やコマンドの実行可能性を考慮しながら、メタデータ/ログ情報の取得範囲を決定することで、
１．定義されたポリシーの実施に対して必要となる最小限となるメタデータ/ログ情報取得条件が決定されるため、効率的な情報ライフサイクル管理の実現を図れるとともに、
２．業務レベルの用語を用いてポリシー定義を行なえるようになり、ポリシーで参照される条件の定義が変更された場合も、対応関係を差し替えることで、自動的にメタデータやログ情報の取得条件が変更されるため、ポリシー定義の容易化と管理コスト低減を図ることが出来る。
【実施例１】
【００１７】
図１に、本発明におけるデータ管理方式を備える情報ライフサイクル管理システムの実施形態の一例を示す。
本実施例における情報ライフサイクル管理システムでは、管理対象となる文書ファイルやメールなどの業務データは、プロジェクトや業務の状況に応じてその価値が変動すると考え、その時々の価値に応じたデータ管理手法を適用することで、費用対効果の高い情報管理を実現することを目指す。
【００１８】
本システムは、大きく、ポリシー記述で使用される用語とメタデータやログ情報との間の対応関係を表すオントロジを定義するためのオントロジ定義モジュール（１）、
上記定義済みのオントロジで出現する用語を用いて定義される、データリソースのグループ分けとそれらに適用する情報管理手法方針を対応付けるポリシーを定義するためのポリシー定義モジュール（２）、上記定義済みポリシーを参照して、具体的なデータリソースのグループ分けと情報管理手法の対応付けの決定を行なう情報ライフサイクル管理モジュール（３）、上記情報ライフサイクル管理モジュールが決定したグループ分けと情報管理手法の指定に基づき、各データリソースの管理手法を変更するデータリソース管理モジュール（４）、及び、前記定義済みポリシーとそれらポリシーの成立を前提として稼動する業務サービスの対応関係を管理し、ポリシーが成立しなくなった場合に対応業務サービスの停止を行なうサービス実行制御モジュール（５）から成る。
【００１９】
まず上記オントロジ定義モジュール（１）が備えるオントロジ定義手段（１１）では、管理対象となる各データリソースとそれらを参照する業務の対応関係を表す用語（オントロジ）を定義し、これらを上記情報ライフサイクル管理モジュール（３）が備えるオントロジ定義レジストリ（３１）に登録する。さらに上記ポリシー定義モジュール（２）が備えるポリシー定義手段（２１）では、データリソースのグループ分けを行なうための「条件部」とグループ分けされたデータリソースに対する適用する「コマンド部」を組とするポリシーを定義し、これらを上記情報ライフサイクル管理モジュール（３）が備えるポリシー定義レジストリ（３４）に登録する。このとき上記オントロジ定義レジストリ（３１）には、条件変換オントロジとコマンド変換オントロジの二種類のオントロジが登録されており、ポリシー定義の際、条件部を定義する際には、上記オントロジ定義レジストリに登録された条件変換用オントロジを参照して定義し、コマンド部を定義する際には、上記オントロジ定義レジストリに登録されたコマンド変換用オントロジを参照して定義する。
【００２０】
また、データリソース管理モジュール（４）が備えるリソース集合管理手段（４２）は、データリソースに対して適用可能な操作一覧を備え、メタデータ/ログ情報取得手段（４１）は、上記情報ライフサイクル管理モジュール（３）が備えるメタデータ/ログ情報設定変更手段（３８）からの指示に従って、前記リソース集合管理手段（４２）が管理するデータリソースからのメタデータやログ情報の取得を行ない、これを上記情報ライフサイクル管理モジュール（３）が備えるメタデータ/ログ情報レジストリ（３３）に登録する。
【００２１】
引き続いて前記情報ライフサイクル管理モジュール（３）が備えるポリシー解析手段（３５）は、前記ポリシー定義レジストリ（３４）から登録済みのポリシーを取り出し、前記オントロジ定義レジストリ（３１）に定義されたオントロジを参照して、前記ポリシーをポリシー実行プランに変換し、ポリシー実行プランレジストリ（３６）に登録する。前記ポリシー実行プランは、実際に操作対象となるデータリソース集合を決定するとともに、それらに適用すべき操作を決定する。このとき、もし取り出されたポリシーがログ情報出力用領域の不足などで実行できないことが判明した場合は、サービス実行制御モジュール（５）が備えるサービス実行制御手段（５１）に対して、どのポリシーが実行できなかったかを通知し、そのポリシーの成立を前提として稼動する業務サービスの停止を行なう。
【００２２】
前記情報ライフサイクル管理モジュール（３）が備える前記ポリシー実行プランレジストリ（３６）は、前記ポリシー実行プランを実施する場合には、まずポリシー実行プランの条件部を対象リソース決定手段（３２）に、またコマンド部をコマンド実行手段（３７）に送付する。前記対象リソース決定手段（３２）では、送付された条件部に指示されたデータリソースの絞込み条件に従って、オントロジ定義レジストリ（３１）に登録された条件変換オントロジとメタデータ/ログ情報レジストリ（３３）に登録されたメタデータ/ログ情報を参照しながら、操作対象データリソース集合を決定する。決定されたデータリソース集合は、前記コマンド実行手段（３７）に送付され、既に送付済みのコマンド部の指示に従って、適切なデータ管理操作が適用される。
【００２３】
図２において、情報ライフサイクル管理モジュール（３）が備えるポリシー解析手段（３５）の概略フローを示す。
ポリシー解析手段（３５）は、まず３種類のポリシー集合PS,QS,ESの初期化を行なった後（２０２）、ポリシー定義レジストリに登録されたポリシーのうち、未実行のポリシーを取り出し（２０３）、候補ポリシー集合PSの要素として登録する（２０４）。もし、未実行のポリシーがない場合は終了する（２０７）。続いてポリシー集合PSからポリシーP１を取り出し（２０５）、ポリシーP１の条件部の評価可能性を判定する。もし評価可能である場合は、そのポリシーP１を評価可能ポリシー集合QSに登録し、評価可能でない場合は、図３に示す処理フローにしたがって、ポリシーP１を変換して再びポリシー集合PSに登録する（２０６）。もし、ポリシー集合PSが空となり取り出すべきポリシーが存在しない場合は、評価可能ポリシー集合QSからポリシーP２を取り出し（２０８）、ポリシーP２のコマンド部の実行可能性を判定する。
【００２４】
もし実行可能である場合は、そのポリシーP２を実行可能ポリシー集合ESに登録し、評価可能でない場合は、図４に示す処理フローにしたがって、ポリシーP２を変換して再びポリシー集合QSに登録する（２０９）。もし、ポリシー集合QSが空となり取り出すべきポリシーが存在しない場合は、実行可能ポリシー集合ESから、評価値が最良となるポリシーPPを選び、ポリシー実行プランに送付する。さらにこのとき、ポリシー解析手段では、適用可能なポリシーPPからメタデータ/ログ情報に対する参照範囲情報を生成し、これをデータリソース管理モジュールモジュールが備えるメタデータ/ログ情報取得手段に送付する（２１１）。さらに実行可能ポリシー集合ＥＳが空となり取り出すべきポリシーが存在しない場合は、前記サービス実行制御手段に対して不成立となったポリシーＰの情報を送付する（２１２）。
【００２５】
図３に、ポリシー集合PSから取り出されたポリシーに対する処理フローを示す。
候補ポリシー集合PSから取り出した候補ポリシーP１については、まずポリシーの条件部SPに関する評価可能性を図５に示すフローにしたがって判定する（３０１）。もし条件部SPが評価可能状態にある場合は、ポリシーPを評価可能ポリシー集合QSに登録し（３０２）、もし評価可能でない場合は、条件変換オントロジを参照し、条件部SPに出現する述語パターンが一致する変換規則集合TRを決定する（３０３）。もし、集合TRが空の場合は、その候補ポリシーは評価可能とはならないため、候補ポリシーＰ１を破棄し（３０４）、新たな候補ポリシーの検討を行う（２０５）。変換規則集合TRが空でない場合は、それぞれの変換規則を候補ポリシーに適用し、条件節を書き換えた新しい候補ポリシー群をPSに登録する（３０６）。このとき、さらに他の実施例として、TRに含まれる適用可能な変換規則をすべて適用するのではなく、各変換規則に対して評価関数を適用して得られる評価値に基づいて適用する変換規則を絞り込む（３０５）ことも考えられる。
【００２６】
図４に、ポリシー集合QSから取り出されたポリシーに対する処理フローを示す。
評価可能ポリシー集合QSから取り出した評価可能ポリシーP２については、まずポリシーのコマンド部CPに関する適用可能性を図６に示すフローにしたがって判定する（４０１）。もしコマンド部CPが実行可能状態にある場合は、ポリシーPを適用可能ポリシー集合ESに登録し（４０２）、もし評価可能でない場合は、コマンド変換オントロジを参照し、コマンド部CPに出現するコマンドパターンが一致する変換規則集合DRを決定する（４０３）。もし、集合DRが空の場合は、その候補パリシーは適用可能とはならないため、評価可能ポリシーＰ２を破棄し（４０４）、新たな候補ポリシーの検討を行う（２０８）。変換規則集合DRが空でない場合は、それぞれの変換規則を候補ポリシーに適用し、コマンド節を書き換えた新しい候補ポリシーをQSに登録する（４０６）。このとき、他の実施例として、DRに含まれる適用可能な変換規則をすべて適用するのではなく、各変換規則に対して評価関数を適用して得られる評価値に基づいて適用する変換規則を絞り込む（４０５）ことが考えられる。
【００２７】
図５に、ポリシーの評価可能性を判定する処理フローを示す。ポリシーの評価可能性判定処理では、ポリシーの条件部ＳＰを構成する最初の条件節SPCについて（５０２）、条件節SPCを構成する述語が条件変換オントロジにおいて、評価可能フラグが付与されているかどうかを判定する（５０３）。もし評価可能フラグが付与されていない場合は、そのポリシーはまだ評価可能な状態ではないとして判定結果を返し（５０６）、評価可能フラグが付与されている場合は、次の条件節（５０４）について同様の判定を行なう（５０３）。条件部ＳＰを構成する全ての条件節の述語について、評価可能状態である場合は、そのポリシー全体を評価可能として判定結果を返す（５０５）。
【００２８】
図６に、ポリシーの適用可能性を判定する処理フローを示す。ポリシーの適用評価可能性判定処理では、ポリシーのコマンド部CＰを構成する最初の条件節CPCについて（６０２）、コマンド節ＣPCに含まれるコマンドがコマンド変換オントロジにおいて、適用可能フラグが付与されているかどうかを判定する（６０３）。もし適用可能フラグが付与されていない場合は、そのポリシーはまだ適用可能な状態ではないとして判定結果を返し（６０６）、適用可能フラグが付与されている場合は、次の条件節（６０４）について同様の判定を行なう（６０３）。コマンド部ＣＰを構成する全てのコマンド節のコマンドについて、適用可能状態である場合は、そのポリシー全体を適用可能として判定結果を返す（６０５）。
【００２９】
以下では、本実施例における情報ライフサイクル管理方法を、架空のオフィス情報システムにおける業務データの機密管理に関する具体例に対して適用した場合について述べる。
本具体例では、業務データはいくつかのファイルシステムに分けて格納され、それぞれの業務データにはその所有者が設定される。また所有者はそれぞれいずれかの業務プロジェクトに属し、業務プロジェクトに対してはそのプロジェクトの機密レベルが予め設定されるとする。
【００３０】
図７に、本具体例におけるファイル配置情報や組織情報をＲＤＦ(Resource Description Framework)のグラフ表現で示す。
ＲＤＦは、複雑な相互関係を持つデータを、主語(Subject)、述語(Predicate)、目的語(Object)の三つの単語を順番に組み合わせた三つ組（RDF Triple）の集まりで表現するものである。例えば図１３-(a)に示す架空の家系図は、Gomez, Morticia, Wednesday, Pugsleyの４名から成り立つ家族を表す。この家系図の内容をＲＤＦで表現した場合、次の３個の三つ組で表現される。
【００３１】
（Gomez, spouseOf, Morticia）
（Gomez, parentOf, Wednesday）
（Gomez, parentOf, Pugsley）
そのグラフ表現においては、矢印に述語、矢印の根元に主語、矢印の先に目的語を対応させて示す。上記の家系図をグラフ表現した場合、図１３-(b)のようになる。
【００３２】
本具体例ではプロジェクト名がそれぞれＡ及びＢである２つのプロジェクトが存在し、プロジェクトAにメンバーa1が、プロジェクトBにメンバーb1及びb2が所属している。このときメンバーa1はファイルx1を、メンバーb1はファイルy1及びy2を所有し、ファイルx1はファイルシステムＸの配下にあり、ファイルy1及びy2はファイルシステムＹの配下にあるとする。またプロジェクトＢはその機密レベルとして“confidentail“が指定されている。
これをＲＤＦで表現すると以下のようになる。
（Ａ, rdf:type, プロジェクト), （B, rdf:type, プロジェクト),
（a1, rdf:type, メンバ), （b1, rdf:type, メンバ), （b2, rdf:type, メンバ),
（x1, rdf:type, ファイル), （y1, rdf:type, ファイル), （ｙ2, rdf:type, ファイル),
(X, rdf:type, ファイルシステム), （Ｙ, rdf:type, ファイルシステム),
(a1, ilm:belongsTo, A), (b1, ilm:belongsTo, B), (b2, ilm:belongsTo, B),
(x1, ilm:owns, a1), (y1, ilm:owns, b1), (y2, ilm:owns, b1),
(x1, ilm:belongsTo, X), (y1, ilm:belongsTo, Y), (y2, ilm:belongsTo, Y)
(B, ilm:securityLevel, “confidential“)
図８に本具体例におけるポリシーの記述の例を示す。本例では、ポリシーの条件部をＲＤＦデータに対する検索言語であるＲＤＱＬで記述し、ポリシーのコマンド部に起動すべきコマンドスクリプト名を引数付きで記述する。
【００３３】
ＲＤＱＬ (A Data Oriented Query Language for RDF Models)は、蓄積されているRDFデータモデルから条件にあったものを取り出す機能を提供する検索言語である。RDFに対する検索は、RDFモデルとクエリパターンとのパターンマッチングによって実現される。例えば、先の家系図の例に対して配偶者の関係にある人物の組を得たい場合は、次のようなクエリによって?person1及び?person2にパターンマッチするリソースを取得することが出来る。
【００３４】
RDQLクエリ：SELECT ?person1, ?person2 WHERE (?person1, spouseOf, ?person2)
検索結果：{person1= Gomez, person2=Morticia}
図８に示すポリシーの条件部は、プロジェクトの機密レベルが“confidentail“で、かつそのプロジェクトの管轄内にあるデータリソースの内、種別がファイルで、そのデータアイテムに過去一週間以内のアクセス履歴が存在するデータリソースを絞り込むことを指示する。また図８に示すポリシーのコマンド部は、上記条件部で絞り込まれたデータリソースに対して、アクセスログを取得するように設定変更することを指示する。
【００３５】
図９に本具体例で登録されているオントロジの内容を示す。オントロジは、条件変化用のオントロジとコマンド変換用のオントロジの２種類がある。本具体例では、条件変換用オントロジが３個、コマンド変換用オントロジが１個定義されている。
図９に示す条件変換用オントロジの一つ目のオントロジは、ポリシーの条件部に現れる「プロジェクトの管轄内(ilm:belongsTo)にあるデータリソース」は「プロジェクトに所属(ilm:belongsTo)するメンバーが所有(ilm:owns)するデータリソース」と変換できることを示す。
【００３６】
二つ目のオントロジは、「プロジェクトに所属(ilm:belongsTo)するメンバー」は、「プロジェクトを構成(meta:memberOf)するメンバー」と変換できることを示す。
三つ目のオントロジは、「メンバーが所有(ilm:owns)するデータリソース」は、「メンバーが所有者(meta:owner)であるデータリソース」と変換できることを示す。
さらに図９に示すコマンド変換用オントロジの一つ目のオントロジは、「データ種別がファイルであるデータリソースに対するアクセスログの取得を指示するコマンド」は、「そのデータリソースが属する(meta:decendantOf)ファイルシステムに対しするアクセスログの取得を指示するコマンド」に変換できることを示す。
【００３７】
図１０に、本実施例において評価可能な述語の一覧及び適用可能なコマンドの一覧を示す。ファイル情報に関しては、データリソースの所有者情報(meta:owner),ファイルシステムに対するデータリソースの所属関係(meta:decendantOf)及びファイルに対するアクセス履歴情報(meta:accesshistory,meta:accesstime)が評価可能なメタデータとして登録されており、プロジェクト組織情報に関しては、プロジェクトの機密レベル(meta:securityLevel)とプロジェクトに対するメンバーの所属関係(meta:memberOf)が評価可能なメタデータとして登録されている。また、本実施例において適用可能なコマンドとしては、ファイルシステムに対するアクセスログの取得コマンドが実行可能として登録されているとする。ただし、リソースの種別を表す述語rdf:typeは常に評価可能な述語と見做す。
【００３８】
また本具体例におけるファイル情報に関するメタデータ及び組織情報に関するメタデータは、それぞれ図１１,図１２に示す通りとする。
このとき、まずポリシー解析手段は、ポリシー定義レジストリに登録された図８に示すポリシーを候補ポリシー集合ＰＳに登録する。引き続き候補ポリシー集合ＰＳからポリシーＰ１として前記登録したポリシーを取り出す。
【００３９】
「ポリシーＰ１」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?dataitem, ilm:belognsTo, ?project),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY  1WEEK
USING ilm FOR &lt;http://ilm/ontology.rdf#&gt;
<コマンド部>
Set accesslog On dataitem
本ポリシーの評価可能性を判定すると、本ポリシーの２番目の条件節（?dataitem, ilm:belongsTo, ?project）を参照すると、本条件節を構成する述語ilm:belongsToは評価可能な述語として登録されていないので、条件変換オントロジーを参照し、条件部に対して適用可能な変換規則の集合ＴＲとして、条件変換オントロジ#1を得る。ポリシーＰ１に対して条件変換オントロジ#1を適用すると、以下のポリシーＰ１１を得る。
【００４０】
「ポリシーＰ１１」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, ilm:belognsTo, ?project),
(?dataitem, ilm:owns, ?member),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY  1WEEK
USING ilm FOR &lt;http://ilm/ontology.rdf#&gt;
<コマンド部>
Set accesslog On dataitem
本ポリシーの評価可能性を判定すると、本ポリシーの２番目及び３番目の条件節を構成する述語が評価可能な述語として登録されていないので、さらにポリシーＰ１１に対して適用可能な変換規則として条件変換オントロジ＃２、＃３を得る。ポリシーＰ１１に対してこれらのオントロジを順次適用することで、以下のポリシーＰ１２を得る。
【００４１】
「ポリシーＰ１２」
<条件部>
SELECT ?dataitem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?dataitem, rdf:type, “file“),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY  1WEEK
USING ilm FOR &lt;http://ilm/ontology.rdf#&gt;
<コマンド部>
Set accesslog On dataitem
ポリシーＰ1２に関しては、ポリシーを構成する全ての条件節の述語が評価可能となるので、このポリシーを評価可能ポリシー集合ＱＳに登録する。
【００４２】
引き続き、評価可能ポリシー集合QSに登録された前記ポリシーP12をポリシーＰ２として取り出す。ポリシーＰ２の適用可能性を判定すると、ポリシーＰ２のコマンド部に記述されるファイルに対するアクセスログの取得コマンドは実行可能として登録されていないので、コマンド変換オントロジを参照し、コマンド部に対して適用可能な変換規則の集合ＤＲとして、コマンド変換オントロジ#1を得る。ポリシーP2に対してコマンド変換オントロジ#1を適用すると、以下のポリシーP21を得る。
【００４３】
「ポリシーＰ21」
<条件部>
SELECT ?filesystem
WHERE
(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?filesystem, rdf:type, “filesystem“),
(?dataitem, meta:decendantOf, ?filesystem),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)
AND
?acctime > TODAY  1WEEK
USING ilm FOR &lt;http://ilm/ontology.rdf#&gt;
<コマンド部>
Set accesslog On filesystem
変換の結果得られたポリシーＰ21は、コマンド部が本実施例において適用可能となるため、このポリシーを適用可能ポリシー集合ESに登録する。
【００４４】
以上の操作の結果、評価可能ポリシー集合にはポリシーＰ21のみが登録されている状態になるので、このポリシーをポリシー実行プランレジストリに送付する。
さらにこのとき、ポリシー解析手段では、適用可能となったポリシーP21で参照されるメタデータ/ログ情報の参照範囲情報として、以下のような一覧リストを作成し、データリソース管理モジュールモジュールが備えるメタデータ/ログ情報取得手段に対して送付する。
【００４５】
(?project, meta:securityLevel, “confidential“),
(?member, meta:memberOf, ?project),
(?dataitem, meta:owner, ?member),
(?filesystem, rdf:type, “filesystem“),
(?dataitem, meta:decendantOf, ?filesystem),
(?dataitem, meta:accesshistory, ?acclog),
(?acclog, meta:accesstime, ?acctime)   ?acctime > TODAY  1WEEK
前記メタデータ/ログ情報取得手段では、受け取ったメタデータ/ログ情報一覧リストを参照し、リソース集合管理手段に対し、一覧リストにあるメタデータ/ログ情報（meta:securityLevel,meta:memberOf,meta:owner,meta:decendantOf,meta:accesshistory,meta:accesstime）を収集するように設定の変更を指示する。このときさらにアクセス履歴に関するログ情報(ilm:accesstime)に関しては、参照されるアクセス履歴の範囲が過去１週間以内であるので、ログの保持期間が過去１週間となるように設定することとなる。
【００４６】
このときもし、適用可能ポリシー集合が空であり、ポリシーレジストリから取り出されたポリシーに対して、適用可能なポリシーが生成されなかった場合は、サービス実行制御モジュールが備えるサービス実行制御手段に対して、適用不可となったポリシーとして送付を行なう。サービス実行制御手段では、適用不可となったポリシーを動作前提とするサービスが登録されていた場合は、当該サービスを停止するようにする。
【００４７】
ポリシー実行プランレジストリに送付されたポリシーは、その条件部が対象リソース決定手段に送付され、そのコマンド部がコマンド実行手段に送付される。対象リソース決定手段では送付された条件部に含まれるＲＤＱＬを解釈し、操作対象となるデータリソースを絞り込む。今回の実施例の場合は、ファイルシステムＹが対象リソースとして選択される。選択されたデータリソースはコマンド実行手段に送られ、先に送付されたコマンド部に記述されたコマンドが選択されたデータリソースに対して適用され、ファイルシステムＹに対して、アクセスログを取得するように設定変更が行なわれる。
【産業上の利用可能性】
【００４８】
本発明によれば、データの生成から廃棄に至る一連のライフサイクルにおいて、ビジネス戦略やビジネスモデルの変化により管理対象データの業務的価値が時間的に変化することに対応して、情報の取得、保持、廃棄の条件の変更を容易に行える情報管理システムが得られるので、この分野で利用可能性が高い。
【図面の簡単な説明】
【００４９】
【図１】本発明による情報ライフサイクル管理システムを示すブロック図である。
【図２】本発明の実施例におけるポリシー解析手段の全体処理を示すフローチャートである。
【図３】ポリシー条件部変換及びポリシー集合QSへの登録処理を示すフローチャートである。
【図４】コマンド変換及びポリシー集合ESへの登録処理を示すフローチャートである。
【図５】ポリシー条件部の評価可能性判定処理を示すフローチャートである。
【図６】ポリシーコマンド部の適用可能性判定処理フローチャートである。
【図７】本実施例の適用例におけるファイル配置や組織情報に関するＲＤＦグラフである。
【図８】適用例におけるポリシー定義を示す図である。
【図９】適用例におけるオントロジ定義を示す図である。
【図１０】適用例における評価可能メタデータ/ログ情報あるいは適用可能コマンド定義を示す図である。
【図１１】適用例におけるファイル情報メタデータを示す図である。
【図１２】適用例における組織情報メタデータを示す図である。
【図１３】架空の家系図とそのRDFグラフ表現である。
【符号の説明】
【００５０】
１：オントロジ定義モジュール
２：ポリシー定義モジュール
３：情報ライフサイクル管理モジュール
４：データリソース管理モジュール
５：サービス実行制御モジュール
１１：オントロジ定義手段
２１：ポリシー定義手段
３１：オントロジ定義レジストリ
３２：対象リソース決定手段
３３：メタデータ/ログ情報レジストリ
３４：ポリシー定義レジストリ
３５：ポリシー解析手段
３６：ポリシー実行プランレジストリ
３７：コマンド実行手段
３８：メタデータ/ログ情報設定変更手段
４１：メタデータ/ログ情報取得手段
４２：リソース集合管理手段
５１：サービス実行制御手段。
【図１】
2006318146.tif 000003
【図２】
2006318146.tif 000004
【図３】
2006318146.tif 000005
【図４】
2006318146.tif 000006
【図５】
2006318146.tif 000007
【図６】
2006318146.tif 000008
【図７】
2006318146.tif 000009
【図８】
2006318146.tif 000010
【図９】
2006318146.tif 000011
【図１０】
2006318146.tif 000012
【図１１】
2006318146.tif 000013
【図１２】
2006318146.tif 000014
【図１３】
2006318146.tif 000015