JP2004355440A - Data structure, and method and device for processing data - Google Patents

Data structure, and method and device for processing data Download PDF

Info

Publication number
JP2004355440A
JP2004355440A JP2003153845A JP2003153845A JP2004355440A JP 2004355440 A JP2004355440 A JP 2004355440A JP 2003153845 A JP2003153845 A JP 2003153845A JP 2003153845 A JP2003153845 A JP 2003153845A JP 2004355440 A JP2004355440 A JP 2004355440A
Authority
JP
Japan
Prior art keywords
data
metadata
link
identification information
classification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2003153845A
Other languages
Japanese (ja)
Inventor
Takao Komata
孝夫 小俣
Shigeki Ueno
滋樹 上野
Masayuki Tanazawa
昌幸 棚澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tokyo Electric Power Company Holdings Inc
Original Assignee
Tokyo Electric Power Co Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tokyo Electric Power Co Inc filed Critical Tokyo Electric Power Co Inc
Priority to JP2003153845A priority Critical patent/JP2004355440A/en
Publication of JP2004355440A publication Critical patent/JP2004355440A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

<P>PROBLEM TO BE SOLVED: To present data and the relationship among the data in a manner corresponding to a human sense. <P>SOLUTION: A data structure includes a first data structure which holds the linkage between meta data as a pair of data on the identification information of a page that provides a link and the link; a second structure which includes at least data on the link to a file related to the meta data; and a third structure which specifies the classification of the meta data. The data structure is capable of independently setting the classification of the meta data and the linkage between the meta data. Thus, the file is not directly linked but the meta data are linked to enable even data such as figures and graphs to be associated with one another, while facilitating searches. Use of the second data structure makes it possible to refer to the files of figures or the like from the meta data. Use of the first data structure enables the link to be traced in both directions and enables the meta data to be independently traced also from the third data structure. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【０００１】
【発明の属する技術分野】
本発明は、データの管理技術に関する。
【０００２】
【従来の技術】
ナレッジマネジメントシステム（以下、ＫＭ（Ｋｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎｔ）システム）では、一般的に文書・測定値などの形式知であるデータをデータベース（ＤＢ）に登録して、当該データを検索するようになっている。データを登録する際には、複数の文書を分類し、まとめた形で登録する。データ参照時には、参照すべきカテゴリの一覧表示中から目的のデータを探すか、検索キーを用いてデータ内における検索キーの有無による検索を行う。このようなＫＭシステムではデータという形式知を扱うに留まり、暗黙知を取り扱うものはほとんどない。
【０００３】
従来の暗黙知を扱うとされるＫＭシステムにおいても、データからデータへのリンクを例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のタグにて指定して暗黙知を形式知化するものに留まっている。この単純なタグを用いる方式では、指定した文書をタグを活用して表示することは可能であるが、特定のデータがどのデータから関連付けられているのかについての情報はない。そのため、通常人間が頭の中で行っているような情報関連付け（情報の連想とも呼ぶ）であるリンク元データの抽出や、データとデータのｎ対ｎの関連付け（１個のデータからｎ個のデータにリンクが張られるだけではなく、リンク元データへの関連付けもリンク先のｎ個のデータについて行われているいうこと）は不可能である。
【０００４】
例えば、ＡというＨＴＭＬファイルに、Ｂ及びＣというＨＴＭＬファイルへのリンクが含まれている場合、ＡからＢ又はＣへの移行は可能である。しかし、ユーザの参照履歴がなければ、Ｂ又はＣというＨＴＭＬファイルからはＡというＨＴＭＬファイルに戻ることは不可能である。よって、ＨＴＭＬファイルからは１対ｎという関係しか構築することはできない。また、遷移先のＨＴＭＬファイルが削除されても、遷移元のＨＴＭＬファイルにはリンクが残ってしまう。
【０００５】
なお、特開平８−２４９３４２号公報には、以下のような技術が開示されている。ハイパーメディア文書を構成する複数のカードの中から検索指示された語句を含むカードを検索するハイパー文書検索装置において、関連するカード間のリンク情報を管理するリンク管理部４と、検索用インデックスを管理するインデックス管理部５と、リンク管理部４により管理されるリンク情報に従ってインデックス管理部５により管理される検索用インデックスを参照し、上記検索指示された語句を含むカードを検索する検索部３とを具備え、検索指示された語句を含むカードをリンク先にもつリンク元カードを検索対象カードとして取り扱う、という技術が開示されている。
【０００６】
【特許文献１】
特開平８−２４９３４２号
【０００７】
【発明が解決しようとする課題】
しかし、上記のような技術では文書データであるカードを対象としているため、文書でないデータについては取り扱えない。また、文書データ毎にリンク情報を管理しているため、リンク情報だけを編集する場合であってもリンク元及びリンク先の文書データの両方のデータを修正しなければならない。さらに、文書データをリンクとは別の観点から分類することについては考慮していない。
【０００８】
従って、本発明の目的は、データ及びデータ間の関連性を人間の感覚に即した形で提示できるようにするための新規な技術を適用することである。
【０００９】
【課題を解決するための手段】
本発明の第１の態様に係るデータ構造は、メタデータ間のリンク関係をリンク元の識別情報及びリンク先の識別情報の対のデータとして保持する第１データ構造と、各メタデータについて、当該メタデータに関連するデータ（例えばファイル）へのリンク・データを少なくとも含む第２データ構造と、メタデータの分類を規定する第３データ構造とを含み、メタデータの分類とメタデータ間のリンク関係とが独立に設定可能なものである。
【００１０】
このようにデータ（例えばファイル）を直接リンク付けるのではなく、メタデータをリンク付けることにより、文書だけではなく図やグラフなどのデータについても関連付けることができ、且つ検索することも容易になる。また、第２データ構造を用いればメタデータから図やグラフなどのファイルをも参照することができる。さらに、メタデータ間のリンク関係はメタデータ自身のデータとは別個に第１データ構造として管理され、リンク関係の変更を行う場合であってもリンク先及びリンク元のメタデータを修正する必要ない。さらに、第１データ構造を用いればリンクを双方向に辿ることができ、さらにリンク関係とは独立に設定されるメタデータの分類（第３データ構造）からも別途メタデータを辿ることができる。なお、ファイルはメタデータと関連付けられ、メタデータが他のメタデータと関連付けられるため、ファイルから見ればｎ対ｎの関連付けがなされることになる。
【００１１】
なお、上で述べた第３データ構造が、メタデータの分類を木構造により規定するようにしてもよい。メタデータが、例えばファイル・システムにおいて提供されるディレクトリ構造に基づいて分類・管理されるようにしてもよい。
【００１２】
また、上で述べた第２データ構造が、各メタデータが属する分類における所定の主題についてのテキスト・データをさらに含むようにしてもよい。
【００１３】
本発明の第２の態様に係るデータ処理方法は、登録するメタデータの分類について指定がなされた場合、第１データ格納部に当該メタデータの分類を表すデータを登録するステップと、メタデータに関連するファイルの指定を受けた場合、当該メタデータから、指定されたファイルへのリンク・データを、第２データ格納部に登録するステップと、メタデータ間のリンク関係がリンク元の識別情報及びリンク先の識別情報の対のデータとして指定された場合、リンク元の識別情報及びリンク先の識別情報の対のデータを第１データ格納部から独立した第３データ格納部に登録するステップとを含む。
【００１４】
また、本発明の第２の態様において、特定のメタデータの削除要求を受信した場合、第１データ格納部及び第２データ格納部から特定のメタデータに関するデータを削除するステップと、第３データ格納部において、特定のメタデータの識別情報がリンク元の識別情報及びリンク先の識別情報のいずれかに登録されている上記対のデータを削除するステップとを含むようにすることも可能である。メタデータの削除に応じてリンク関係を解除するためである。
【００１５】
さらに、本発明の第２の態様において、特定のメタデータが特定のユーザにより参照され且つ当該特定のユーザから要求を受けた場合、特定のユーザの参照履歴のデータを参照することなく、第３データ格納部から、特定のメタデータの識別情報がリンク先の識別情報として登録されている上記対のデータを抽出し、当該特定のメタデータのリンク元のメタデータを特定するステップをさらに含むようにしてもよい。これにより、容易にリンク元を辿ることができるようになる。
【００１６】
さらに、本発明の第２の態様において、メタデータ間のリンク関係の変更が要求された場合、第３データ格納部において該当するリンク元の識別情報及びリンク先の識別情報の対のデータを変更して登録するステップをさらに含むようにしてもよい。リンク関係の変更では、第３データ格納部のみを変更すればよいので、処理が簡単になる。
【００１７】
また、本発明に係るデータ処理方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、データ構造についても上記のような記憶媒体又は記憶装置に格納される。プログラム等は、ネットワークを介してデジタル信号として配信される場合もある。また、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００１８】
【発明の実施の形態】
図１に、本発明をナレッジマネジメント（ＫＭ）・システムに適用した場合の一実施の形態におけるシステム概要図を示す。例えば、イントラネットなどのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であるネットワーク１には、情報の利用者であるユーザが操作し、例えばウェブ（Ｗｅｂ）ブラウザ機能を有する１又は複数のクライアント端末Ａと、情報の登録者であるユーザが操作し、例えばＷｅｂブラウザ機能を有する１又は複数のクライアント端末Ｂと、Ｗｅｂサーバ機能を有しており本実施の形態において主要な処理を実施するＫＭシステムサーバ５とが接続されている。クライアント端末Ａ及びＢは、例えばパーソナルコンピュータである。
【００１９】
ＫＭシステムサーバ５は、情報の登録・変更・削除やリンクの登録・変更・削除を実施するための処理を行う登録処理部５１と、情報の検索を行うための検索処理部５２とを含む。これらの処理内容については以下で詳しく述べる。また、ＫＭシステムサーバ５は、データベース（ＤＢ）５３を管理しており、ＤＢ５３は以下に述べるようなデータを保持している。
【００２０】
論理的なデータ構造の一例を図２に示す。本実施の形態では１又は複数のデータを管理するためのメタデータを採用している。図２の例では、メタデータＡと、メタデータＢと、メタデータＣとがメタデータ登録領域に保持されている。また、各メタデータは、自己が管理しているデータに対するリンクを含んでいる。図２の例では、メタデータＡは、データａ１乃至データａｎを管理しており、点線でリンクが示されている。メタデータＢは、データｂ１乃至ｂｍを管理しており、同じく点線でリンクが示されている。さらに、メタデータＣは、データｃ１乃至ｃｋ及びデータｂ１を管理しており、同じく点線でリンクが示されている。なお、データは、データ登録領域に保持されている。メタデータＣのように、他のメタデータと重複する形でデータを管理するようにしても良い。このようにメタデータは、データと１対ｎの関係を有しているが、個々のデータとは独立しているため、データを改変することなくその内容・構成を自由に変更することができる。
【００２１】
また、メタデータ間は双方向で関連付けられている。但し、ここで双方向とは、リンク元とリンク先とを合わせて抽出できるような形態にてリンク関係を保持していることを示している。図２の例では、メタデータＡは、メタデータＢ及びメタデータＣと関連付けられており、リンクＸとリンクＺとして示されている。メタデータＢは、メタデータＡ及びメタデータＣと関連付けられており、リンクＸ及びリンクＹで示されている。メタデータＣは、メタデータＡ及びメタデータＢと関連付けられており、リンクＺ及びリンクＹで示されている。このようなリンク付けをメタデータについて行うことにより、例えば技術者が保有する連想情報である暗黙知を形式知化することができるようになる。このようにメタデータ間のリンクはＨＴＭＬにおけるリンクとは異なり、メタデータを介したデータ間の双方向なリンクである。ＨＴＭＬでは１対ｎの関連付けしかできなかったが、図２に示すようにデータから他のデータに対してメタデータを介してｎ対ｎで関連付けることができるようになる。
【００２２】
また図３に示すように、メタデータはメタデータ間のリンク関係だけで関連付けられるわけではなく、リンク関係とは独立にメタデータには分類が規定される。メタデータが分類されれば、当該メタデータにより管理されるデータも分類されることになる。図３の例では、メタデータＡ及びメタデータＢがカテゴリ１に分類され、メタデータＣはカテゴリ２に分類されている。さらに、カテゴリ１及びカテゴリ２は、カテゴリ３に分類されている。
【００２３】
このようなデータ構造を実現することにより、検索を行うユーザは、メタデータに含まれる文字データによりキーワード検索を行うことができ、メタデータのリンクを双方向に辿ることにより目的のデータを探索することができ、さらに図３で示すようなメタデータの分類に従って目的のデータを探索することも可能となる。
【００２４】
次に、図２及び図３で説明したデータ構造を実現するためのデータの一例を図４乃至図６を用いて説明する。図４は、メタデータに含まれるデータ・テーブルの一例を示す図である。図４の例では、文書名（メタデータＡ）と、添付ファイル名１（画面例１．ｄｏｃ）と、作成者名（東電一郎）と、本メタデータの主題（例えば事故）に関するデータである概要、原因及び対策と、事故発生日時と、メタデータのサイズと、メタデータ更新日時とが含まれる。本データ・テーブルに含まれる添付ファイル名１に対応するファイル名が、本メタデータから管理されるデータへのリンクを表すデータである。添付ファイル名は、１つだけではなく複数指定される場合もある。また図４に示したデータ項目だけではなく、他のデータ項目を設けることも可能である。
【００２５】
図５は、メタデータ間のリンク関係を規定するテーブルの一例を示す図である。図５の例では、リンク元の列５０１と、リンク先の列５０２とが設けられている。このように本実施の形態では、メタデータに関するデータとは別にリンク関係を規定するテーブルを設けるようにしているため、リンク関係の追加・変更・削除が必要になった場合であっても、リンクテーブルのみを変更すればよいため、処理が簡略化される。
【００２６】
図６は、メタデータの分類関係を規定するディレクトリ構造の一例を示す図である。図６の例では、文書というディレクトリに事故情報及び指示文書というディレクトリが設けられ、指示文書というディレクトリにカテゴリ１というディレクトリが設けられ、カテゴリ１というディレクトリにメタデータＡ及びメタデータＢというメタデータが含まれる構造を示している。このようなディレクトリ構造によるファイルの管理は、従来からオペレーティング・システム（ＯＳ：Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）のファイル・システムにおいて実現されているが、ファイル・システムに類似のデータ構造を別途用意することにより、メタデータの分類を規定及び管理することができる。但し、例えば１つのメタデータを１つのファイルとして特定のディレクトリに保存することにより、メタデータの分類関係を規定及び管理するようにしても良い。また、このような管理は、図５に示したリンク・テーブルとは別個に設定・管理されており、柔軟なデータの関連付けを可能としている。
【００２７】
次に、ＫＭシステムサーバ５の処理について図７乃至図２７を用いて説明する。最初に、登録処理部５１の処理について説明する。図７は、メタデータの登録処理フローを示す。情報の登録を行うユーザは、クライアント端末Ｂを操作して、クライアント端末Ｂにメタデータ登録ページにアクセスさせる（ステップＳ１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂからのアクセスに応答して、分類指定ページ・データを送信する（ステップＳ３）。クライアント端末Ｂは、ＫＭシステムサーバ５から分類指定ページ・データを受信し、表示装置に表示する（ステップＳ５）。分類指定ページには、例えば今回登録するメタデータが登録されるべき分類（ディレクトリ）を入力するための入力欄が含まれている。
【００２８】
ユーザは、分類を入力欄に入力すると図示しない送信ボタンをクリックする。クライアント端末Ｂは、ユーザによる分類指定入力を受け付け、送信ボタンのクリックに応じて入力された分類データを送信する（ステップＳ７）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから分類データを受信し、一旦記憶装置に格納する（ステップＳ９）。そして、メタデータ登録ページ・データをクライアント端末Ｂに送信する（ステップＳ１１）。クライアント端末Ｂは、ＫＭシステムサーバ５からメタデータ登録ページ・データを受信し、表示装置に表示する（ステップＳ１３）。例えば、図８のような画面が表示される。
【００２９】
図８の例では、文書名の入力欄８０１と、メタデータが管理するデータである添付ファイルのファイル名（ここでは添付ファイル名２）の入力欄８１４と、参照ボタン８０６と、作成者名の指定欄８０７と、概要の入力欄８０８と、原因の入力欄８０９と、対策の入力欄８１０と、リンクボタン８１１と、登録ボタン８１２と、終了ボタン８１３とが設けられている。添付ファイル名の入力欄８１４には、本メタデータが管理するデータである添付ファイルのファイル名をパスを含めて指定してもよいが、参照ボタン８０６をクリックして、クライアント端末ＢのＯＳを介してファイルを指定するようにしても良い。作成者名の指定欄８０７には、予め登録されている作成者足り得るユーザの名前がコンボボックスで表示されるため選択することにより入力が完了するようになっている。概要の入力欄８０８と、原因の入力欄８０９と、対策の入力欄８１０とには、メタデータのキーワード検索で使用される文章が入力される。終了ボタン８１３については登録せずに処理を終了させるためのボタンである。なお、図８には示していないが、他の項目についての入力欄を設けるようにしても良い。例えば、事故発生日時の入力欄である。
【００３０】
なお、説明の都合上、添付ファイル名が既に登録済みの場合の表示例も合わせて示されており、図８の例では、画面例．ｄｏｃというファイルが既登録とされている。既登録の添付ファイルに対しては、削除のためのチェックボックス８０２と、表示ボタン８０３と、ダウンロードボタン８０４と、文書差し替えボタン８０５とが設けられている。
【００３１】
内容を確認する場合には表示ボタン８０３をクリックすれば、クライアント端末ＢはＫＭシステムサーバ５に表示指示を送信し、ＫＭシステムサーバ５は表示指示に応じてＤＢ５３から該当する添付ファイルのデータを読み出し、ＫＭシステムサーバ５から添付ファイルのデータがクライアント端末Ｂに送信される。そして、クライアント端末Ｂは、添付ファイルのデータを受信し、例えば別ウインドウにて添付ファイルの内容を表示する。
【００３２】
ダウンロードボタン８０４をクリックすれば、クライアント端末ＢはＫＭシステムサーバ５にダウンロード指示を送信し、ＫＭシステムサーバ５はダウンロード指示に応じてＤＢ５３から該当する添付ファイルを読み出し、ＫＭシステムサーバ５から添付ファイルのデータをクライアント端末Ｂに送信する。そして、当該添付ファイルは、クライアント端末Ｂの指定されたディレクトリに保存される。
【００３３】
残りの削除のためのチェックボックス８０２と文書差し替えボタン８０５については当該メタデータが管理するデータ（ファイル）の変更処理のためのボタンである。これらを用いた処理については後に詳述する。
【００３４】
図８で示したように、文書名（メタデータ名）、添付ファイル名、作成者名、概要、原因及び対策について選択又は入力を行うと、これらのデータをクライアント端末Ｂは受け付ける（ステップＳ１５）。
【００３５】
リンクについてはリンクボタン８１１を用いてリンクを指定することになるが、この段階で指定せずとも良い。このリンクボタン８１１をクリックした場合の処理（ステップＳ１６）については、図１０を用いて後に説明する。
【００３６】
その後図８における登録ボタン８１２がクリックされると、クライアント端末Ｂは、ユーザから登録指示がなされたものとして、入力されたメタデータの内容をＫＭシステムサーバ５に送信する（ステップＳ１７）。この際、図８のような入力画面で入力されたデータだけではなく、指定された添付ファイル名のファイルについても同時に送信する。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから、入力されたメタデータの内容を受信し、一旦記憶装置に格納する（ステップＳ１９）。そして、受信したメタデータの内容をＤＢ５３に登録する（ステップＳ２１）。例えばステップＳ９において受信した分類データに基づき、指定されたディレクトリにメタデータのファイルを登録する。又は、ステップＳ９において受信した分類データに基づき、今回登録されるメタデータの分類についてのデータをＤＢ５３に登録すると共に、受信したメタデータの内容を別途ＤＢ５３に登録するようにしても良い。なお、添付ファイルについては、別途ＤＢ５３の所定の領域に登録する。
【００３７】
以上のような処理を実施すれば、メタデータ及びメタデータが管理するデータ（ファイル）をＫＭシステムサーバ５のＤＢ５３に登録することができる。なお、上記のような登録を行った後に登録に係るメタデータを参照する際、すなわちクライアント端末Ａから特定のメタデータを指定して参照要求をＫＭシステムサーバ５に送信した場合には、クライアント端末ＡはＫＭシステムサーバ５から例えば図９に示すような内容を表示するためのページ・データを受信し、表示装置に表示を行う。
【００３８】
図９の例では、図８において入力された内容と同じ内容が表示されるメタデータ表示欄９０１と、リンクボタン９０２と、「閉じる」ボタン９０３とが含まれる。なお、メタデータ表示欄９０１に設けられた添付ファイル名の行における表示ボタン及びダウンロードボタンは、図８における表示ボタン８０３及びダウンロードボタン８０４と同じである。リンクボタン９０２については後に図２２乃至図２５を用いて説明する。「閉じる」ボタン９０３は、例えばメインメニューに戻るためのボタン若しくはウインドウをクローズするためのボタンである。
【００３９】
次に図１０乃至図１４を用いてメタデータのリンク関係を登録するための処理について説明する。図８においてリンクボタン８１１がクリックされると、クライアント端末Ｂは、リンク情報表示指示として受け付け（ステップＳ３１）、リンク情報表示要求データをＫＭシステムサーバ５に送信する（ステップＳ３３）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂからリンク情報表示要求データを受信すると（ステップＳ３５）、ＤＢ５３のリンク・テーブルを参照して、処理中のメタデータに関連するリンク・データを検索する。そして、検索結果を用いてリンク表示ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ３７）。クライアント端末Ｂは、ＫＭシステムサーバ５からリンク表示ページ・データを受信し、例えば表示装置に表示する（ステップＳ３９）。例えば図１１に示すような画面が表示される。
【００４０】
図１１の例では、追加ボタン１１０１と、削除ボタン１１０２と、終了ボタン１１０３と、リンク表示欄１１０４とが設けられている。但し、新規のメタデータ登録の場合には、リンク・データはまだ登録されていないので、リンク表示欄１１０４は空となっている。ここでは、メタデータ間のリンク関係を規定するため、ユーザは追加ボタン１１０１をクリックする。
【００４１】
クライアント端末Ｂは、ユーザからの追加指示を受け付け、追加要求をＫＭシステムサーバ５に送信する（ステップＳ４１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから追加要求を受信すると（ステップＳ４３）、ＤＢ５３において処理中のメタデータに対してロックをかける（ステップＳ４５）。不適切なリンク関係がリンクテーブルに登録されないようにするためである。なお、新規の場合にはメタデータはＤＢ５３に登録されていないのでスキップされる。そして、追加用ページ・データをクライアント端末Ｂに送信する（ステップＳ４７）。クライアント端末Ｂは、ＫＭシステムサーバ５から追加用ページ・データを受信し、表示装置に表示する（ステップＳ４９）。例えば図１２に示すような画面が表示される。
【００４２】
図１２の例では、リンク元メタデータ名の入力欄１２０１と、リンク先メタデータ名の入力欄１２０２と、リンク関係作成ボタン１２０３と、リンク関係を作成せずに処理を終了させるための終了ボタン１２０４と、メタデータを探すための参照ボタン１２０５とが設けられている。
【００４３】
参照ボタン１２０５をクリックすると、クライアント端末Ｂは、ＫＭシステムサーバ５にメタデータ参照要求を送信する。そして、ＫＭシステムサーバ５は、ＤＢ５３を参照して例えば図１３に示すような画面表示を行うためのメタデータ分類表示ページ・データを生成し、クライアント端末Ｂに送信する。クライアント端末Ｂは、ＫＭシステムサーバ５からメタデータ分類表示ページ・データを受信し、表示装置に表示する。図１３の例では、フォルダ形式の分類表示部１３０１と、特定の分類に含まれるメタデータを列挙するテーブル１３０２と、終了ボタン１３０３とが含まれる。ユーザは分類表示部１３０１から特定の分類を指定し、さらにその中のメタデータを指定することにより、図１２においてメタデータを指定することができる。但し、メタデータの名称を自ら入力しても良い。また、フォルダ形式にて分類表示を行っているが、他の形式にて表示を行ってメタデータを探索できるようにしてもよい。さらに、クライアント端末ＢとＫＭシステムサーバ５とが何回かやり取りをおこなって目的の分類のメタデータを探索するようにしても良い。なお、リンク元のメタデータ名については処理中のメタデータ名（ここではメタデータＡ）を埋め込んだ形で表示しても良いし、表示欄として入力できないようにする場合もある。
【００４４】
図１２で、リンク元のメタデータ名及びリンク先のメタデータ名を入力欄１２０１及び１２０２に入力し、作成ボタン１２０３をクリックすると、クライアント端末Ｂは、ユーザからのリンク・データ（リンク元とリンク先のメタデータの対）の入力を受け付け（ステップＳ５１）、入力されたリンク・データをＫＭシステムサーバ５に送信する（ステップＳ５３）。ＫＭシステムサーバ５は、クライアント端末Ｂからリンク・データを受信し、ＤＢ５３のリンク・テーブルに登録する（ステップＳ５５）。登録する際に登録可能か否か又は登録が妥当であるか否かを確認するようにしても良い。そして、ロック解除を行う（ステップＳ５７）。その後、今回登録したリンク関係を表示させるため、ＤＢ５３のリンク・テーブルからリンク表示ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ５９）。クライアント端末Ｂは、ＫＭシステムサーバ５からリンク表示ページ・データを受信し、表示装置に表示する（ステップＳ６１）。例えば図１４のような画面が表示される。
【００４５】
図１４の例では、追加ボタン１４０１と、削除ボタン１４０２と、終了ボタン１４０３と、リンク表示欄１４０４とが含まれる。ここでは、メタデータＡからメタデータＢへのリンクが登録されたことが表示されている。なお、リンク表示欄１４０４は、削除すべきリンク・データを特定するためのチェック・ボックスの列１４１１と、探索対象のメタデータ名（参照元文書名）の表示列１４１２と、リンクの方向表示列１４１３と、抽出されたメタデータ名（参照先文書名）の表示列１４１４と、参照先文書のリンク関係を表示させるためのリンク表示ボタンの列１４１５とが含まれる。なお、参照先文書名であるメタデータＢについてはハイパーリンクとなっており、メタデータＢの内容を表示させることができるようになっている。
【００４６】
次に、図１４において削除すべきリンク・データを特定するためのチェック・ボックスの列１４１１にチェックが付され、削除ボタン１４０２がクリックされた場合の処理について図１５を用いて説明する。
【００４７】
クライアント端末Ｂは、ユーザから削除対象のリンク・データの指定入力及び削除指示を受け付け（ステップＳ７１）、削除対象のリンク・データを特定する情報を含むリンク削除要求をＫＭシステムサーバ５に送信する（ステップＳ７３）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから削除対象のリンク・データを特定する情報を含むリンク削除要求を受信する（ステップＳ７５）。そして、登録処理部５１は、特定されたリンク・データに関連するメタデータ（例えばリンク元及びリンク先）をＤＢ５３においてロックする（ステップＳ７７）。そして、ＤＢ５３のリンク・テーブルから特定されたリンク・データを削除する（ステップＳ７９）。すなわち該当する１レコードを削除する。そして、ＤＢ５３においてロックを解除し（ステップＳ８１）、再度リンク・テーブルを参照して、処理中のメタデータに関連するリンク・データを抽出し、リンク表示ページ・データを生成して、クライアント端末Ｂに送信する（ステップＳ８３）。クライアント端末Ｂは、ＫＭシステムサーバ５からリンク表示ページ・データを受信し、表示装置に表示する（ステップＳ８５）。これにより、ユーザはリンク・データを削除した結果を確認することができる。
【００４８】
次に、メタデータの変更処理について図１６を用いて説明する。ユーザは、クライアント端末Ｂを操作して、クライアント端末Ｂにメタデータ変更ページにアクセスさせる（ステップＳ９１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂからメタデータ変更ページへのアクセスを受けると、ＤＢ５３を参照してメタデータの変更対象選択ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ９３）。クライアント端末Ｂは、メタデータの変更対象選択ページ・データを受信し、表示装置に表示する（ステップＳ９５）。メタデータの変更対象選択ページは、例えば図１３のように分類（フォルダ）を選択してその分類に含まれるメタデータを選択するようなページである。但し、クライアント端末ＢとＫＭシステムサーバ５の登録処理部５１で複数回やり取りを行って分類からメタデータを特定するようにしても良い。また、他の方法にてメタデータを特定できるようにしてもよい。
【００４９】
ユーザは、変更対象選択ページを参照して、変更対象メタデータを選択する。クライアント端末Ｂは、ユーザによる変更対象メタデータの選択入力を受け付け（ステップＳ９７）、選択されたメタデータを特定するデータをＫＭシステムサーバ５に送信する（ステップＳ９９）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから選択メタデータを特定するデータを受信する（ステップＳ１０１）。また、選択メタデータをＤＢ５３においてロックする（ステップＳ１０３）。そして、ＤＢ５３から選択メタデータの内容を読み出し、当該読み出した内容を用いて内容変更入力ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ１０５）。クライアント端末Ｂは、ＫＭシステムサーバ５から内容変更入力ページ・データを受信し、表示装置に表示する（ステップＳ１０７）。なお、例えば図８のような画面が表示される。但し、既に登録されている内容については、修正可能な態様で、入力欄に埋め込まれている。選択されたデータについても選択状態で表示される。この段階で、添付ファイルを変更・削除・追加することができるが、これについては後に説明する。
【００５０】
ユーザは、図８のような画面において入力欄に変更後の内容を入力する。クライアント端末Ｂは、ユーザから内容変更入力を受け付け（ステップＳ１０９）、登録ボタンによる指示に応じて内容変更入力データをＫＭシステムサーバ５に送信する（ステップＳ１１１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから内容変更入力データを受信すると一旦記憶装置に格納する（ステップＳ１１３）。そして、ＤＢ５３に対する内容変更反映処理を実施する（ステップＳ１１５）。すなわち、変更後の内容をＤＢ５３に登録する。また、ロックを解除する（ステップＳ１１７）。
【００５１】
このようにすれば、既に登録されたメタデータを変更することができる。なお、変更後のメタデータの内容をメタデータ表示ページとしてクライアント端末Ｂの表示装置に表示させるようにしても良い。
【００５２】
次に、メタデータの削除処理について図１７を用いて説明する。ユーザは、クライアント端末Ｂを操作して、クライアント端末Ｂにメタデータ削除ページにアクセスさせる（ステップＳ１２１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂからメタデータ削除ページへのアクセスを受けると、ＤＢ５３を参照してメタデータの削除対象選択ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ１２３）。クライアント端末Ｂは、メタデータの削除対象選択ページ・データを受信し、表示装置に表示する（ステップＳ１２５）。メタデータの削除対象選択ページは、例えば図１３のように分類（フォルダ）を選択してその分類に含まれるメタデータを選択するようなページである。但し、クライアント端末ＢとＫＭシステムサーバ５の登録処理部５１で複数回やり取りを行って分類からメタデータを特定するようにしても良い。また、他の方法にてメタデータを特定できるようにしてもよい。
【００５３】
ユーザは、削除対象選択ページを参照して、削除対象メタデータを選択する。クライアント端末Ｂは、ユーザによる削除対象メタデータの選択入力を受け付け（ステップＳ１２７）、選択されたメタデータを特定するデータをＫＭシステムサーバ５に送信する（ステップＳ１２９）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから選択メタデータを特定するデータを受信する（ステップＳ１３１）。また、選択メタデータをＤＢ５３においてロックする（ステップＳ１３３）。そして、例えば、ＤＢ５３から選択メタデータの内容を読み出し、当該読み出した内容を用いて削除確認ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ１３５）。クライアント端末Ｂは、ＫＭシステムサーバ５から削除確認入力ページ・データを受信し、表示装置に表示する（ステップＳ１３７）。なお、例えば図９に類似する画面が表示される。なお、添付ファイルの参照ボタンやダウンロードボタンは設けられておらず、「削除」ボタン又は「終了」ボタンのみが設けられている。
【００５４】
ユーザは、図９のような画面において削除するメタデータの内容を確認し、削除ボタンをクリックする。クライアント端末Ｂは、ユーザから削除確認入力を受け付け（ステップＳ１３９）、削除確認入力データをＫＭシステムサーバ５に送信する（ステップＳ１４１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから削除確認入力データを受信する（ステップＳ１４３）。この削除確認入力データの受信に応じて、削除対象メタデータの識別情報でリンク・テーブルを検索し、該当するレコードを削除する（ステップＳ１４５）。すなわち、リンク・テーブルにおいて、リンク先又はリンク元として、削除対象メタデータが登録されたリンク・データを削除する。これにより、存在しないメタデータへのリンク及び存在しないメタデータからのリンクを除去することができる。そして、ＤＢ５３から削除対象メタデータの内容を削除する（ステップＳ１４７）。なお、この際、削除対象のメタデータの分類についてのデータも削除する。すなわち、当該メタデータが属する分類（例えばディレクトリ）にもはやそれが存在しないという状態にする。その後、ロックを解除する（ステップＳ１４９）。
【００５５】
このようにすることにより、内容を確認した後に不要となったメタデータを削除することができる。なお、ステップＳ１４９の後に削除完了を表すデータをクライアント端末Ｂに送信するようにしてもよい。
【００５６】
次に、メタデータが管理するデータ（添付ファイル）の変更処理について図１８を用いて説明する。例えば図８において、文書差し替えボタン８０５がクリックされた場合には、クライアント端末Ｂは文書差し替え要求をＫＭシステムサーバ５に送信する（ステップＳ１５１）。ＫＭシステムサーバ５の登録処理部５１は、文書差し替え要求を受信すると（ステップＳ１５３）、添付ファイル名の表示欄の代わりに添付ファイルのファイル名指定欄が設けられた差し替え用登録（又は変更）ページ・データ（図８と同様）を生成し、クライアント端末Ｂに送信する（ステップＳ１５５）。また、ＫＭシステムサーバ５の登録処理部５１は、差し替えの対象となる添付ファイルを特定して記録しておく（ステップＳ１５６）。一方、クライアント端末Ｂは、ＫＭシステムサーバ５から差し替え用登録ページ・データを受信し、表示装置に表示する（ステップＳ１５７）。
【００５７】
ユーザは、差し替える添付ファイルの指定入力を行い、クライアント端末Ｂは当該添付ファイルの指定入力を受け付ける（ステップＳ１５９）。なお、ユーザは、この段階でメタデータの他の内容について変更・追加などを指示することも可能である。また、添付ファイル名の指定は上で述べたように新規添付ファイルの指定の場合と同様である。そして、登録ボタン８１２のクリックに応じて、クライアント端末Ｂは、指定された添付ファイルのデータ等（メタデータの他の内容も含む）をＫＭシステムサーバ５に送信する（ステップＳ１６１）。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから添付ファイル等のデータを受信し、一旦記憶装置に格納する（ステップＳ１６３）。そして、メタデータの内容において、添付ファイル名を指定の添付ファイルのファイル名で差し替え登録し、メタデータのその他の内容及び添付ファイルについてもＤＢ５３に登録する（ステップＳ１６５）。そして当該メタデータについてのロックを解除し（ステップＳ１６７）、当該メタデータの新たな内容でメタデータ表示ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ１６９）。クライアント端末Ｂは、ＫＭシステムサーバ５からメタデータ表示ページ・データを受信し、表示装置に表示する（ステップＳ１７１）。
【００５８】
このようにすれば、メタデータが管理するデータ（ファイル）を変更することができる。
【００５９】
次に、例えば図８において、削除のためのチェックボックス８０２にチェックが付され、登録ボタン８１２がクリックされた場合の処理を図１９を用いて説明する。クライアント端末Ｂは、添付ファイル削除指示を含む登録要求をＫＭシステムサーバ５に送信する（ステップＳ１８１）。なお、登録要求には、メタデータの他の内容について登録すべきデータを含む場合もある。ＫＭシステムサーバ５の登録処理部５１は、クライアント端末Ｂから添付ファイル削除指示を含む登録要求を受信すると（ステップＳ１８３）、ＤＢ５３において、指定された添付ファイル名の登録を処理中のメタデータから削除する（ステップＳ１８５）。また、ＤＢ５３において、登録要求に含まれる他の内容を処理中のメタデータに対して登録する（ステップＳ１８７）。その後ロック解除を行う（ステップＳ１８９）。そして、当該メタデータの新たな内容でメタデータ表示ページ・データを生成し、クライアント端末Ｂに送信する（ステップＳ１９１）。クライアント端末Ｂは、ＫＭシステムサーバ５からメタデータ表示ページ・データを受信し、表示装置に表示する（ステップＳ１９３）。
【００６０】
このようにすれば、メタデータが管理するデータ（ファイル）を削除することができる。
【００６１】
次に、検索処理部５２に関連する処理を説明する。メタデータの検索は、例えばキーワード検索や、分類からの検索、さらに特定のメタデータからリンクを辿っての検索がなされる。
【００６２】
キーワード検索の場合には、情報の検索者であるユーザが、例えば図２０に示すような画面においてキーワード等の検索条件を指定して、クライアント端末Ａから検索処理部５２に検索条件を送信する。図２０の例では、検索ボタン２００１と、検索条件をクリアするクリアボタン２００２と、検索キーワード入力欄２００３と、使用可能なキーワード一覧を表示するためのキーワード一覧ボタン２００４と、検索キーワードの適用対象を指定するためのチェックボックス群２００５と、検索対象の文書の種類を指定するためのラジオボタン２００６と、発生日、天候、店所及び所名を指定するための事故情報文書属性指定欄２００７と、全文検索のためのキーワード入力欄２００８と、キーワード一覧ボタン２００９と、カテゴリ（文献）入力欄２０１０と、カテゴリを指定するための参照ボタン２０１１と、日付指定のための入力指定欄２０１２と、ファイルタイプの指定欄２０１３と、表示件数、表示順及び作成者についての絞込み条件を入力するための欄２０１４とが含まれる。これらは一般的なキーワード検索において指定する条件と特に変わることはないので、これ以上説明しない。
【００６３】
以下、ＫＭシステムサーバ５の検索処理部５１は、図２１に示すような処理を実施する。すなわち、図２０のような検索条件入力欄に入力された検索条件のデータを受信し（ステップＳ２０１）、検索キーワード等による検索を実施し、該当するメタデータ及び当該メタデータが管理しているデータ（添付ファイル）をＤＢ５３から抽出し、一旦記憶装置に格納する（ステップＳ２０３）。また、抽出されたメタデータについてのリンク・データをリンク・テーブルを検索して確認する（ステップＳ２０５）。すなわち、リンク・テーブルに、抽出されたメタデータが、リンク元又はリンク先として登録されているか確認する。リンク・テーブルからリンク・データが抽出された場合には、リンクしているメタデータ及び当該メタデータにより管理されているデータ（添付ファイル）をＤＢ５３から抽出し、一旦記憶装置に格納する（ステップＳ２０７）。そして、抽出メタデータ及び抽出データ（抽出ファイル）のリストを生成し、要求元のクライアント端末Ａに送信する（ステップＳ２０９）。
【００６４】
例えば抽出されたメタデータ及び抽出されたデータ（抽出ファイル）は、ハイパーリンクとして列挙され、ユーザが参照するため、クリックした場合には、クライアント端末ＡからＫＭシステムサーバ５に参照要求を送信する。ＫＭシステムサーバ５の検索処理部５２は、参照要求に応じて該当するメタデータ又はデータ（添付ファイル）を、クライアント端末Ａに送信する。クライアント端末Ａは、表示装置に、選択したメタデータ又はデータ（添付ファイル）を表示する。例えば図９のような表示がなされる。
【００６５】
ここで図９のリンクボタン９０２がクリックされると、図２２に示すような処理が実施される。すなわち、メタデータＡというメタデータについて参照している状態で、リンクを参照する要求を入力するものである。クライアント端末Ａは、ユーザからリンク表示選択入力を受け付け（ステップＳ２１１）、ＫＭシステムサーバ５にキーとなるメタデータの識別情報を含む選択リンク情報を送信する（ステップＳ２１３）。ＫＭシステムサーバ５の検索処理部５２は、クライアント端末Ａから選択リンク情報を受信すると（ステップＳ２１５）、ＤＢ５３のリンク・テーブルをキーとなるメタデータの識別情報で検索して当該メタデータをリンク元又はリンク先とするメタデータを抽出し、当該抽出データに基づいてリンク・データを追加表示するページ・データを生成し、クライアント端末Ａに送信する（ステップＳ２１７）。クライアント端末Ａは、リンク・データを追加表示（追加する元がなければ単なる表示）するページ・データを受信し、表示装置に表示する（ステップＳ２１９）。例えば図２３に示すような画面が表示される。
【００６６】
図２３の例では、終了ボタン２３０１と、探索対象のメタデータ名の表示列２３０２と、リンクの方向の表示列２３０３と、抽出されたメタデータ名の表示列２３０４と、リンク表示ボタン２３０５と、リンク表示ボタン２３０６とが含まれる。このようにメタデータＡが、リンク元又はリンク先のいずれかに登録されたリンク・データが表示されるようになる。ここではメタデータＡには、メタデータＢに向けたリンクが設定されており、メタデータＤからリンクが張られていることが分かる。抽出されたメタデータの名称部分はハイパーリンクとなっており、クリックすればメタデータの内容を参照することができるようになっている。また、抽出されたメタデータに対応してリンク表示ボタンが設けられている。このリンク表示ボタンは、図９におけるリンクボタン９０２と同様の処理を実施させるためのボタンである。
【００６７】
リンク表示ボタン２３０５がクリックされると、図２２に示された処理が実施され、図２４に示すような画面が表示される。すなわち、メタデータＢが、リンク元又はリンク先のいずれかに登録されたリンク・データが表示されるようになる。ここではメタデータＢには、メタデータＡ及びメタデータＣからリンクが張られていることが分かる。ここでメタデータＣに対応するリンク表示ボタン２４０１がクリックされると、図２５に示すような画面が表示される。図２５では、メタデータＣが、リンク元又はリンク先のいずれかに登録されたリンク・データが表示される。ここではメタデータＣには、メタデータＢに向けたリンクが設定されており、メタデータＤからリンクが張られていることが分かる。
【００６８】
このような図２３乃至図２５から分かるように、一つのメタデータが特定されれば、当該メタデータからリンクが張られているメタデータだけではなく、当該メタデータがリンク先となっているメタデータに遷移することも可能となる。図２６に示すように、メタデータＡからメタデータＢにリンクＳが設定されており、メタデータＢからメタデータＣにリンクｔが設定されている場合、メタデータＡ、メタデータＢ、メタデータＣという順番に遷移することができるが、さらにメタデータＣ、メタデータＢ、メタデータＡという順番でも遷移することができる。ＨＴＭＬタグのリンクでも、メタデータＡ、メタデータＢ、メタデータＣという順番で遷移することができるが、参照履歴がなければ、メタデータＣ、メタデータＢ、メタデータＡの順番では遷移することができない。本実施の形態に従えば、参照履歴がなくとも、メタデータＢ又はＣを参照していれば、メタデータＡまで遡ることができる。これはリンク・テーブルを管理しているためである。
【００６９】
また、検索処理部５２における検索処理には図２１に示したような検索キーワードを主体とする検索条件に基づいて検索する処理だけではなく、特定のメタデータを指定することによる検索処理も含まれる。この処理を図２７を用いて説明する。ユーザが特定のメタデータを指定して検索指示をクライアント端末Ａに入力すると、クライアント端末Ａは、当該特定のメタデータの指定を含む検索要求をＫＭシステムサーバ５に送信する。ＫＭシステムサーバ５の検索処理部５２は、メタデータの指定を含む検索要求を受信する（ステップＳ２２１）。そして、当該メタデータが管理しているデータ（添付ファイル）をＤＢ５３から抽出し、一旦記憶装置に格納する（ステップＳ２２３）。また、指定されたメタデータでリンク・テーブルを検索し、当該メタデータがリンク元又はリンク先として登録されたリンク・データを抽出し、一旦記憶装置に格納する（ステップＳ２２５）。そして、リンク・データが抽出された場合には、リンクしているメタデータ及び当該メタデータが管理しているデータ（添付ファイル）を抽出し、一旦記憶装置に格納する（ステップＳ２２７）。そして、抽出されたメタデータ及び当該メタデータが管理するデータ（添付ファイル）のリストを生成し、クライアント端末Ａに送信する（ステップＳ２２９）。クライアント端末Ａは、抽出されたメタデータ及び当該メタデータが管理するデータ（添付ファイル）のリストを受信し、表示装置に表示する。
【００７０】
例えば抽出されたメタデータ及び抽出されたデータ（抽出ファイル）は、ハイパーリンクとして列挙され、ユーザが参照するため、クリックした場合には、クライアント端末ＡからＫＭシステムサーバ５に参照要求を送信する。ＫＭシステムサーバ５の検索処理部５２は、参照要求に応じて該当するメタデータ又はデータ（添付ファイル）を、クライアント端末Ａに送信する。クライアント端末Ａは、表示装置に選択したメタデータ又はデータ（添付ファイル）を表示する。
【００７１】
これにより特定のメタデータが関連するメタデータなどをユーザは一覧で参照することができ、メタデータの内容や添付ファイルの内容を参照することができる。
【００７２】
なお、図１３に示したように、メタデータの分類を一覧として示し、当該分類に従ってメタデータを探す方法もある。但し、これはＯＳにおいて通常提供されているディレクトリ構造の中からのファイルの探索と大きな差はないので、ここではこれ以上述べない。
【００７３】
以上述べた本発明の実施の形態によれば、リンク・テーブルなどのメタデータの関連付けにより暗黙知を形式知化してＫＭシステムにおいて取り扱うことができるようになる。また、リンク・テーブルに基づいて関連するメタデータ等を探索することができるため、データ検索時に漏れのない網羅的な検索を実施することができるようになる。
【００７４】
以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、画面例を示しているが、これは一例であって同様の内容を含む他の画面構成を採用しても良い。また、例えば複数の画面に分かれている内容を１つの画面にまとめることも可能であり、逆に１つの画面に表示されている内容を複数画面にて表示することも可能である。さらに、上で述べたデータ構造を用意できればそのデータ処理は上で述べた処理フローに限定されない。さらに、リンク・データの削除を１回につき１つ行う例を示したが、一度に複数のリンク・データを指定すれば、一度に複数のリンク・データを削除することも可能である。
【００７５】
【発明の効果】
以上述べたように、本発明によれば、データ及びデータ間の関連性を人間の感覚に即した形で提示できるようになる。
【図面の簡単な説明】
【図１】本発明の一実施の形態に係るシステム概要図である。
【図２】本発明の一実施の形態に係るデータ構造の概念図である。
【図３】本発明の一実施の形態に係るデータ構造の概念図である。
【図４】メタデータの内容を表すテーブルの一例を示す図である。
【図５】リンク・テーブルの一例を示す図である。
【図６】メタデータの分類を表すディレクトリ構造を示す図である。
【図７】メタデータ登録処理の処理フローを示す図である。
【図８】メタデータ登録時の画面例を示す図である。
【図９】メタデータ参照時の画面例を示す図である。
【図１０】リンク登録処理の処理フローを示す図である。
【図１１】リンク登録処理の第１ステップにおける画面例である。
【図１２】リンク登録処理の第２ステップにおける画面例である。
【図１３】メタデータの分類状態を表す画面例である。
【図１４】リンク登録処理の第３ステップにおける画面例である。
【図１５】リンク削除処理の処理フローを示す図である。
【図１６】メタデータ変更処理の処理フローを示す図である。
【図１７】メタデータ削除処理の処理フローを示す図である。
【図１８】データ変更処理の処理フローを示す図である。
【図１９】データ削除処理の処理フローを示す図である。
【図２０】検索条件入力画面の一例を示す図である。
【図２１】第１の検索処理フローを示す図である。
【図２２】リンク表示のための処理フローを示す図である。
【図２３】リンク情報一覧表示の第１ステップの画面例を示す図である。
【図２４】リンク情報一覧表示の第２ステップの画面例を示す図である。
【図２５】リンク情報一覧表示の第３ステップの画面例を示す図である。
【図２６】メタデータのリンクの一例を示す図である。
【図２７】第２の検索処理フローを示す図である。
【符号の説明】
１ ネットワーク
５ ＫＭシステムサーバ
５１ 登録処理部
５２ 検索処理部
５３ ＤＢ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to data management technology.
[0002]
[Prior art]
In a knowledge management system (hereinafter, referred to as a KM (Knowledge Management) system), data that is generally known as a format such as a document or a measured value is registered in a database (DB), and the data is searched. When registering data, a plurality of documents are classified and registered in a grouped form. At the time of data reference, target data is searched for from a list of categories to be referred to, or a search is performed based on the presence or absence of a search key in the data using a search key. In such a KM system, only the formal knowledge of data is dealt with, and there is almost no thing which deals with tacit knowledge.
[0003]
Even in the conventional KM system which treats tacit knowledge, data is linked from data to data by, for example, an HTML (Hyper Text Markup Language) tag, and the implicit knowledge is only formalized. In the method using the simple tag, it is possible to display the designated document by using the tag, but there is no information as to which data specific data is associated with. For this reason, extraction of link source data, which is information association (also referred to as information association) that is normally performed by humans in the head, and n-to-n association of data with data (n pieces of data from one piece of data) In addition to linking data, it is impossible to associate data with the link source data for the n destination data.
[0004]
For example, if the HTML file A contains links to the HTML files B and C, the transition from A to B or C is possible. However, if there is no reference history of the user, it is impossible to return from the HTML file B or C to the HTML file A. Therefore, only a one-to-n relationship can be constructed from an HTML file. Further, even if the transition destination HTML file is deleted, a link remains in the transition source HTML file.
[0005]
Note that Japanese Patent Application Laid-Open No. 8-249342 discloses the following technology. In a hyper document search device for searching for a card including a search-instructed word from a plurality of cards constituting a hypermedia document, a link management unit 4 for managing link information between related cards and a search index are managed. The index management unit 5 that performs the search and the search unit 3 that refers to the search index managed by the index management unit 5 in accordance with the link information managed by the link management unit 4 and searches for a card that includes the phrase specified by the search. A technology is disclosed in which a link source card having a link including a card including a word instructed to be searched is treated as a search target card.
[0006]
[Patent Document 1]
JP-A-8-249342
[0007]
[Problems to be solved by the invention]
However, in the above-described technology, a card that is document data is targeted, so that data that is not a document cannot be handled. Further, since the link information is managed for each document data, even when only the link information is edited, both the link source and the link destination document data must be corrected. Furthermore, no consideration is given to classifying document data from a viewpoint different from links.
[0008]
Accordingly, it is an object of the present invention to apply a novel technique for enabling data and relationships between data to be presented in a manner that matches human senses.
[0009]
[Means for Solving the Problems]
The data structure according to the first aspect of the present invention includes: a first data structure that holds a link relationship between metadata as data of a pair of identification information of a link source and identification information of a link destination; A second data structure including at least link data to data (for example, a file) related to the metadata; and a third data structure defining a classification of the metadata, and a link relationship between the metadata classification and the metadata. And can be set independently.
[0010]
By linking metadata instead of directly linking data (for example, files) in this way, not only documents but also data such as figures and graphs can be linked, and search can be easily performed. If the second data structure is used, a file such as a diagram or a graph can be referred to from the metadata. Further, the link relationship between the metadata is managed as a first data structure separately from the data of the metadata itself, and even when the link relationship is changed, it is not necessary to modify the metadata of the link destination and the link source. . Furthermore, if the first data structure is used, the link can be traced in both directions, and the metadata can be separately traced from the metadata classification (third data structure) set independently of the link relationship. Since a file is associated with metadata and the metadata is associated with other metadata, n-to-n association is made from the viewpoint of the file.
[0011]
Note that the above-described third data structure may define the classification of metadata by a tree structure. Metadata may be classified and managed based on a directory structure provided in a file system, for example.
[0012]
Further, the above-mentioned second data structure may further include text data on a predetermined subject in a classification to which each metadata belongs.
[0013]
In the data processing method according to the second aspect of the present invention, when a classification of metadata to be registered is designated, a step of registering data representing the classification of the metadata in the first data storage unit; When a related file is specified, a step of registering the link data to the specified file from the metadata in the second data storage unit; Registering the data of the pair of the identification information of the link source and the identification information of the link destination in the third data storage unit independent from the first data storage unit when the data is specified as the data of the pair of the identification information of the link destination. Including.
[0014]
Further, in the second aspect of the present invention, when a request for deleting specific metadata is received, a step of deleting data relating to the specific metadata from the first data storage unit and the second data storage unit; The storage unit may include the step of deleting the pair of data in which the identification information of the specific metadata is registered as one of the identification information of the link source and the identification information of the link destination. . This is because the link relationship is released in accordance with the deletion of the metadata.
[0015]
Further, in the second aspect of the present invention, when specific metadata is referred to by a specific user and a request is received from the specific user, the third metadata is referred to without referring to the reference history data of the specific user. Extracting, from the data storage unit, the pair of data in which the identification information of the specific metadata is registered as the identification information of the link destination, and further including a step of specifying the link source metadata of the specific metadata. Is also good. This makes it possible to easily follow the link source.
[0016]
Further, in the second aspect of the present invention, when a change in the link relationship between the metadata is requested, the data of the pair of the identification information of the corresponding link source and the identification information of the link destination is changed in the third data storage unit. May be further included. When the link relation is changed, only the third data storage section needs to be changed, so that the processing is simplified.
[0017]
Further, it is also possible to create a program for causing a computer to execute the data processing method according to the present invention, and the program includes, for example, a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, a hard disk, and the like. It is stored in a storage medium or a storage device. The data structure is also stored in the storage medium or storage device as described above. The program or the like may be distributed as a digital signal via a network. Data being processed is temporarily stored in a computer memory.
[0018]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 shows a system outline diagram in one embodiment when the present invention is applied to a knowledge management (KM) system. For example, in a network 1 that is a LAN (Local Area Network) such as an intranet, a user who is a user of information operates one or a plurality of client terminals A having a Web browser function, and registers information in the network 1. One or a plurality of client terminals B having a Web browser function, for example, and a KM system server 5 having a Web server function and performing main processing in the present embodiment are connected. ing. The client terminals A and B are, for example, personal computers.
[0019]
The KM system server 5 includes a registration processing unit 51 that performs processing for registering, changing, and deleting information and registering, changing, and deleting a link, and a search processing unit 52 for searching for information. Details of these processes will be described below. Further, the KM system server 5 manages a database (DB) 53, and the DB 53 holds data as described below.
[0020]
FIG. 2 shows an example of a logical data structure. In the present embodiment, metadata for managing one or a plurality of data is adopted. In the example of FIG. 2, metadata A, metadata B, and metadata C are held in the metadata registration area. Each metadata includes a link to data managed by itself. In the example of FIG. 2, the metadata A manages data a1 to data an, and links are indicated by dotted lines. The metadata B manages data b1 to bm, and is also indicated by a dotted line with a link. Further, the metadata C manages the data c1 to ck and the data b1, and the links are also indicated by dotted lines. Note that the data is held in the data registration area. Like metadata C, data may be managed in a form that overlaps with other metadata. As described above, the metadata has a one-to-n relationship with the data, but since the metadata is independent of the individual data, the content and structure of the metadata can be freely changed without altering the data. .
[0021]
Also, metadata is associated in both directions. Here, bidirectional means that the link relationship is maintained in such a form that the link source and the link destination can be extracted together. In the example of FIG. 2, the metadata A is associated with the metadata B and the metadata C, and is shown as a link X and a link Z. Metadata B is associated with metadata A and metadata C, and is indicated by link X and link Y. The metadata C is associated with the metadata A and the metadata B, and is indicated by a link Z and a link Y. By performing such linking on the metadata, for example, tacit knowledge that is the associative information held by the engineer can be formalized. Thus, the link between metadata is different from the link in HTML, and is a bidirectional link between data via metadata. In HTML, only one-to-n association was possible, but as shown in FIG. 2, it becomes possible to associate n-to-n from data to other data via metadata.
[0022]
Also, as shown in FIG. 3, the metadata is not associated only with the link relation between the metadata, and a classification is defined for the metadata independently of the link relation. If the metadata is classified, the data managed by the metadata is also classified. In the example of FIG. 3, metadata A and metadata B are classified into category 1, and metadata C is classified into category 2. Further, category 1 and category 2 are classified into category 3.
[0023]
By realizing such a data structure, a user performing a search can perform a keyword search based on character data included in metadata, and search for target data by bidirectionally following links of metadata. It is also possible to search for target data according to the classification of metadata as shown in FIG.
[0024]
Next, an example of data for realizing the data structure described with reference to FIGS. 2 and 3 will be described with reference to FIGS. FIG. 4 is a diagram illustrating an example of a data table included in metadata. In the example of FIG. 4, the data is the document name (metadata A), the attached file name 1 (screen example 1. doc), the creator name (Toden Ichiro), and the subject of the metadata (for example, accident). The information includes an outline, a cause and a countermeasure, an accident occurrence date and time, a metadata size, and a metadata update date and time. The file name corresponding to the attached file name 1 included in the present data table is data representing a link from the present metadata to data managed. Attached file names may be specified in plurals instead of just one. In addition to the data items shown in FIG. 4, other data items can be provided.
[0025]
FIG. 5 is a diagram illustrating an example of a table that defines a link relationship between metadata. In the example of FIG. 5, a link source column 501 and a link destination column 502 are provided. As described above, in the present embodiment, a table that defines the link relationship is provided separately from the data related to the metadata. Therefore, even when it is necessary to add, change, or delete the link relationship, Since only the table needs to be changed, the processing is simplified.
[0026]
FIG. 6 is a diagram illustrating an example of a directory structure that defines a classification relationship of metadata. In the example of FIG. 6, a directory of documents is provided with directories of accident information and instruction documents, a directory of instruction documents is provided with a directory of category 1, and a directory of category 1 is provided with metadata A and metadata B. The included structures are shown. Such file management using a directory structure has been conventionally realized in a file system of an operating system (OS), but by separately preparing a data structure similar to the file system, metadata Can be defined and managed. However, for example, by storing one piece of metadata as one file in a specific directory, the classification relation of metadata may be defined and managed. Further, such management is set and managed separately from the link table shown in FIG. 5, and enables flexible data association.
[0027]
Next, the processing of the KM system server 5 will be described with reference to FIGS. First, the processing of the registration processing unit 51 will be described. FIG. 7 shows a flow of processing for registering metadata. The user who registers information operates the client terminal B to allow the client terminal B to access the metadata registration page (step S1). The registration processing unit 51 of the KM system server 5 transmits the classification designation page data in response to the access from the client terminal B (Step S3). The client terminal B receives the classification designation page data from the KM system server 5 and displays it on the display device (step S5). The category designation page includes, for example, an input field for entering a category (directory) in which metadata to be registered this time is to be registered.
[0028]
When the user inputs the classification into the input field, the user clicks a transmission button (not shown). The client terminal B receives the classification designation input by the user, and transmits the input classification data in response to the click of the transmission button (step S7). The registration processing unit 51 of the KM system server 5 receives the classification data from the client terminal B and temporarily stores the classification data in the storage device (Step S9). Then, the metadata registration page data is transmitted to the client terminal B (step S11). The client terminal B receives the metadata registration page data from the KM system server 5 and displays it on the display device (step S13). For example, a screen as shown in FIG. 8 is displayed.
[0029]
In the example of FIG. 8, an input field 801 for a document name, an input field 814 for a file name of an attached file (here, attached file name 2) which is data managed by metadata, a reference button 806, and a creator name A designation field 807, a summary input field 808, a cause input field 809, a countermeasure input field 810, a link button 811, a registration button 812, and an end button 813 are provided. In the attached file name input field 814, the file name of the attached file, which is data managed by this metadata, may be specified including the path. However, by clicking the browse button 806, the OS of the client terminal B is displayed. The file may be specified via the command line. In the creator name specification field 807, the names of users who are registered in advance and are available are displayed in a combo box, so that input can be completed by selecting the creator name. A sentence used in a keyword search of metadata is input in an outline input field 808, a cause input field 809, and a countermeasure input field 810. The end button 813 is a button for terminating the process without registering. Although not shown in FIG. 8, input fields for other items may be provided. For example, an input column for the date and time when an accident occurred.
[0030]
For convenience of explanation, a display example when the attached file name is already registered is also shown. In the example of FIG. A file called doc has already been registered. For a registered attachment file, a check box 802 for deletion, a display button 803, a download button 804, and a document replacement button 805 are provided.
[0031]
When the display button 803 is clicked to check the contents, the client terminal B sends a display instruction to the KM system server 5, and the KM system server 5 reads the data of the attached file from the DB 53 according to the display instruction. , The attached file data is transmitted from the KM system server 5 to the client terminal B. Then, the client terminal B receives the data of the attached file, and displays the content of the attached file in another window, for example.
[0032]
When the download button 804 is clicked, the client terminal B transmits a download instruction to the KM system server 5, and the KM system server 5 reads the corresponding attached file from the DB 53 in response to the download instruction, and reads the attached file from the KM system server 5. The data is transmitted to the client terminal B. Then, the attached file is stored in the designated directory of the client terminal B.
[0033]
The check box 802 and the replace document button 805 for the remaining deletion are buttons for changing data (file) managed by the metadata. The processing using these will be described later in detail.
[0034]
As shown in FIG. 8, when the user selects or inputs a document name (metadata name), an attached file name, a creator name, an outline, a cause, and a countermeasure, the client terminal B receives these data (step S15). .
[0035]
The link is specified using the link button 811. However, the link need not be specified at this stage. The processing (step S16) when the link button 811 is clicked will be described later with reference to FIG.
[0036]
Thereafter, when registration button 812 in FIG. 8 is clicked, client terminal B transmits the content of the input metadata to KM system server 5 assuming that a registration instruction has been issued by the user (step S17). At this time, not only the data input on the input screen as shown in FIG. 8 but also the file having the specified attached file name is transmitted at the same time. The registration processing unit 51 of the KM system server 5 receives the content of the input metadata from the client terminal B, and temporarily stores the content in the storage device (Step S19). Then, the contents of the received metadata are registered in the DB 53 (step S21). For example, based on the classification data received in step S9, a metadata file is registered in a designated directory. Alternatively, based on the classification data received in step S9, data on the classification of the metadata to be registered this time may be registered in the DB 53, and the content of the received metadata may be separately registered in the DB 53. The attached file is separately registered in a predetermined area of the DB 53.
[0037]
By performing the above processing, metadata and data (files) managed by the metadata can be registered in the DB 53 of the KM system server 5. When referring to the metadata related to the registration after performing the above-mentioned registration, that is, when the client terminal A specifies the specific metadata and transmits the reference request to the KM system server 5, the client terminal A A receives, for example, page data for displaying the contents as shown in FIG. 9 from the KM system server 5 and displays the page data on the display device.
[0038]
The example in FIG. 9 includes a metadata display field 901 displaying the same content as the content input in FIG. 8, a link button 902, and a “close” button 903. The display button and the download button in the row of the attached file name provided in the metadata display column 901 are the same as the display button 803 and the download button 804 in FIG. The link button 902 will be described later with reference to FIGS. A “close” button 903 is, for example, a button for returning to the main menu or a button for closing a window.
[0039]
Next, a process for registering a metadata link relationship will be described with reference to FIGS. When the link button 811 is clicked in FIG. 8, the client terminal B receives a link information display instruction (step S31), and transmits link information display request data to the KM system server 5 (step S33). Upon receiving the link information display request data from the client terminal B (step S35), the registration processing unit 51 of the KM system server 5 refers to the link table of the DB 53 to check the link data related to the metadata being processed. Search for. Then, link display page data is generated using the search result, and transmitted to the client terminal B (step S37). The client terminal B receives the link display page data from the KM system server 5 and displays it on, for example, a display device (step S39). For example, a screen as shown in FIG. 11 is displayed.
[0040]
In the example of FIG. 11, an add button 1101, a delete button 1102, an end button 1103, and a link display column 1104 are provided. However, in the case of new metadata registration, the link display column 1104 is empty because link data has not been registered yet. Here, the user clicks an add button 1101 to define a link relationship between metadata.
[0041]
The client terminal B receives the addition instruction from the user, and transmits an addition request to the KM system server 5 (Step S41). Upon receiving the addition request from the client terminal B (step S43), the registration processing unit 51 of the KM system server 5 locks the metadata being processed in the DB 53 (step S45). This is to prevent an inappropriate link relationship from being registered in the link table. In the case of a new metadata, the metadata is not registered in the DB 53, so that the metadata is skipped. Then, the additional page data is transmitted to the client terminal B (step S47). The client terminal B receives the page data for addition from the KM system server 5 and displays it on the display device (step S49). For example, a screen as shown in FIG. 12 is displayed.
[0042]
In the example of FIG. 12, a link source metadata name input field 1201, a link destination metadata name input field 1202, a link relation creation button 1203, and an end button for terminating the process without creating a link relation 1204 and a reference button 1205 for searching for metadata are provided.
[0043]
When the user clicks the reference button 1205, the client terminal B transmits a metadata reference request to the KM system server 5. Then, the KM system server 5 refers to the DB 53 to generate, for example, metadata classification display page data for displaying a screen as shown in FIG. The client terminal B receives the metadata classification display page data from the KM system server 5 and displays it on the display device. In the example of FIG. 13, a classification display unit 1301 in a folder format, a table 1302 listing metadata included in a specific classification, and an end button 1303 are included. The user can specify the metadata in FIG. 12 by specifying a specific classification from the classification display unit 1301 and specifying the metadata therein. However, the name of the metadata may be input by itself. Further, although the classification display is performed in the folder format, the display may be performed in another format so that the metadata can be searched. Further, the client terminal B and the KM system server 5 may exchange data several times to search for metadata of a target classification. The metadata name of the link source may be displayed in a form in which the metadata name being processed (here, metadata A) is embedded, or may not be input as a display field.
[0044]
In FIG. 12, the link source metadata name and the link destination metadata name are entered in the input fields 1201 and 1202, and when a create button 1203 is clicked, the client terminal B receives link data (link source and link source) from the user. The input of the previous metadata pair is received (step S51), and the input link data is transmitted to the KM system server 5 (step S53). The KM system server 5 receives the link data from the client terminal B and registers it in the link table of the DB 53 (Step S55). At the time of registration, it may be confirmed whether registration is possible or whether registration is appropriate. Then, the lock is released (step S57). After that, in order to display the link relation registered this time, link display page data is generated from the link table of the DB 53 and transmitted to the client terminal B (step S59). The client terminal B receives the link display page data from the KM system server 5 and displays it on the display device (step S61). For example, a screen as shown in FIG. 14 is displayed.
[0045]
In the example of FIG. 14, an add button 1401, a delete button 1402, an end button 1403, and a link display field 1404 are included. Here, it is displayed that a link from metadata A to metadata B has been registered. Note that a link display column 1404 includes a check box column 1411 for specifying link data to be deleted, a display column 1412 of a metadata name (reference source document name) to be searched, and a link direction display column. 1413, a display column 1414 of the extracted metadata name (reference destination document name), and a link display button column 1415 for displaying the link relationship of the reference destination document. Note that the metadata B, which is the reference destination document name, is a hyperlink, so that the contents of the metadata B can be displayed.
[0046]
Next, a process in the case where the check box column 1411 for specifying link data to be deleted in FIG. 14 is checked and the delete button 1402 is clicked will be described with reference to FIG.
[0047]
The client terminal B receives the designation input and deletion instruction of the link data to be deleted from the user (step S71), and transmits a link deletion request including information for specifying the link data to be deleted to the KM system server 5 (step S71). Step S73). The registration processing unit 51 of the KM system server 5 receives a link deletion request including information for specifying link data to be deleted from the client terminal B (Step S75). Then, the registration processing unit 51 locks the metadata (for example, the link source and the link destination) related to the specified link data in the DB 53 (Step S77). Then, the specified link data is deleted from the link table of the DB 53 (step S79). That is, the corresponding one record is deleted. Then, the lock is released in the DB 53 (step S81), the link data related to the metadata being processed is extracted again by referring to the link table, the link display page data is generated, and the client terminal B (Step S83). The client terminal B receives the link display page data from the KM system server 5 and displays it on the display device (step S85). This allows the user to confirm the result of deleting the link data.
[0048]
Next, metadata change processing will be described with reference to FIG. The user operates the client terminal B to make the client terminal B access the metadata change page (step S91). When the registration processing unit 51 of the KM system server 5 receives access to the metadata change page from the client terminal B, the registration processing unit 51 refers to the DB 53, generates metadata change target selection page data, and transmits it to the client terminal B. (Step S93). The client terminal B receives the metadata change target selection page data and displays it on the display device (step S95). The metadata change target selection page is, for example, a page for selecting a category (folder) and selecting metadata included in the category as shown in FIG. However, the client terminal B and the registration processing unit 51 of the KM system server 5 may exchange information a plurality of times to specify the metadata from the classification. Further, the metadata may be specified by another method.
[0049]
The user selects the change target metadata with reference to the change target selection page. The client terminal B receives the selection input of the metadata to be changed by the user (step S97), and transmits data specifying the selected metadata to the KM system server 5 (step S99). The registration processing unit 51 of the KM system server 5 receives data specifying the selected metadata from the client terminal B (Step S101). Further, the selected metadata is locked in the DB 53 (step S103). Then, the content of the selected metadata is read from the DB 53, the content change input page data is generated using the read content, and transmitted to the client terminal B (step S105). The client terminal B receives the content change input page data from the KM system server 5 and displays it on the display device (step S107). Note that a screen as shown in FIG. 8 is displayed, for example. However, already registered contents are embedded in the input fields in a modifiable manner. The selected data is also displayed in a selected state. At this stage, the attached file can be changed, deleted, or added, which will be described later.
[0050]
The user inputs the contents after the change in the input field on the screen as shown in FIG. The client terminal B receives the content change input from the user (step S109), and transmits the content change input data to the KM system server 5 according to the instruction of the registration button (step S111). Upon receiving the content change input data from the client terminal B, the registration processing unit 51 of the KM system server 5 temporarily stores the data in the storage device (step S113). Then, a content change reflection process is performed on the DB 53 (step S115). That is, the changed contents are registered in the DB 53. The lock is released (step S117).
[0051]
In this way, the already registered metadata can be changed. The content of the metadata after the change may be displayed on the display device of the client terminal B as a metadata display page.
[0052]
Next, metadata deletion processing will be described with reference to FIG. The user operates the client terminal B to allow the client terminal B to access the metadata deletion page (step S121). When receiving the access to the metadata deletion page from the client terminal B, the registration processing unit 51 of the KM system server 5 generates the metadata deletion target selection page data with reference to the DB 53 and transmits it to the client terminal B. (Step S123). The client terminal B receives the deletion target selection page data of the metadata and displays it on the display device (step S125). The metadata deletion target selection page is a page for selecting a category (folder) and selecting metadata included in the category as shown in FIG. 13, for example. However, the client terminal B and the registration processing unit 51 of the KM system server 5 may exchange information a plurality of times to specify the metadata from the classification. Further, the metadata may be specified by another method.
[0053]
The user selects the deletion target metadata with reference to the deletion target selection page. The client terminal B receives the user's selection input of the metadata to be deleted (step S127), and transmits data specifying the selected metadata to the KM system server 5 (step S129). The registration processing unit 51 of the KM system server 5 receives the data specifying the selected metadata from the client terminal B (Step S131). Further, the selected metadata is locked in the DB 53 (step S133). Then, for example, the content of the selected metadata is read from the DB 53, the deletion confirmation page data is generated using the read content, and transmitted to the client terminal B (step S135). The client terminal B receives the deletion confirmation input page data from the KM system server 5 and displays it on the display device (step S137). For example, a screen similar to that of FIG. 9 is displayed. Note that no attached file reference button or download button is provided, and only a "delete" button or an "end" button is provided.
[0054]
The user checks the content of the metadata to be deleted on the screen as shown in FIG. 9 and clicks the delete button. The client terminal B receives a deletion confirmation input from the user (step S139), and transmits deletion confirmation input data to the KM system server 5 (step S141). The registration processing unit 51 of the KM system server 5 receives the deletion confirmation input data from the client terminal B (Step S143). In response to receiving the deletion confirmation input data, the link table is searched with the identification information of the deletion target metadata, and the corresponding record is deleted (step S145). That is, in the link table, link data in which metadata to be deleted is registered as a link destination or a link source is deleted. Thereby, it is possible to remove the link to the non-existent metadata and the link from the non-existent metadata. Then, the contents of the metadata to be deleted are deleted from the DB 53 (step S147). At this time, data on the classification of the metadata to be deleted is also deleted. That is, the state is such that the metadata no longer exists in the classification (eg, directory) to which the metadata belongs. Thereafter, the lock is released (step S149).
[0055]
This makes it possible to delete unnecessary metadata after confirming the content. After step S149, data indicating completion of deletion may be transmitted to the client terminal B.
[0056]
Next, a process of changing data (attached file) managed by metadata will be described with reference to FIG. For example, in FIG. 8, when the document replacement button 805 is clicked, the client terminal B transmits a document replacement request to the KM system server 5 (step S151). Upon receiving the document replacement request (step S153), the registration processing unit 51 of the KM system server 5 replaces the registration (or change) page with a file name designation field for the attached file instead of the attached file name display field. Generate data (similar to FIG. 8) and transmit it to client terminal B (step S155). Further, the registration processing unit 51 of the KM system server 5 specifies and records the attached file to be replaced (Step S156). On the other hand, the client terminal B receives the replacement registration page data from the KM system server 5 and displays it on the display device (step S157).
[0057]
The user performs designation input of the attached file to be replaced, and the client terminal B accepts the designation input of the attached file (step S159). At this stage, the user can also instruct change / addition of other contents of the metadata. The designation of the attached file name is the same as the designation of the new attached file as described above. Then, in response to the click of the registration button 812, the client terminal B transmits data of the specified attached file and the like (including other contents of the metadata) to the KM system server 5 (step S161). The registration processing unit 51 of the KM system server 5 receives the data such as the attached file from the client terminal B and temporarily stores the data in the storage device (Step S163). Then, in the contents of the metadata, the attached file name is replaced with the file name of the specified attached file, and the other contents and the attached file of the metadata are registered in the DB 53 (step S165). Then, the lock on the metadata is released (step S167), the metadata display page data is generated with the new content of the metadata, and transmitted to the client terminal B (step S169). The client terminal B receives the metadata display page data from the KM system server 5 and displays it on the display device (step S171).
[0058]
In this way, data (files) managed by the metadata can be changed.
[0059]
Next, for example, in FIG. 8, a process when the check box 802 for deletion is checked and the registration button 812 is clicked will be described with reference to FIG. The client terminal B transmits a registration request including the instruction to delete the attached file to the KM system server 5 (Step S181). The registration request may include data to be registered for other contents of the metadata. Upon receiving the registration request including the attached file deletion instruction from the client terminal B (step S183), the registration processing unit 51 of the KM system server 5 deletes the registration of the specified attached file name from the metadata being processed in the DB 53. (Step S185). In the DB 53, other contents included in the registration request are registered for the metadata being processed (step S187). Thereafter, the lock is released (step S189). Then, metadata display page data is generated with the new content of the metadata, and transmitted to the client terminal B (step S191). The client terminal B receives the metadata display page data from the KM system server 5 and displays it on the display device (step S193).
[0060]
In this way, data (files) managed by the metadata can be deleted.
[0061]
Next, processing related to the search processing unit 52 will be described. The metadata search includes, for example, a keyword search, a search based on classification, and a search following a link from specific metadata.
[0062]
In the case of a keyword search, a user who is a searcher of information specifies a search condition such as a keyword on a screen as shown in FIG. 20, for example, and transmits the search condition from the client terminal A to the search processing unit 52. In the example of FIG. 20, a search button 2001, a clear button 2002 for clearing search conditions, a search keyword input field 2003, a keyword list button 2004 for displaying a list of available keywords, and an application target of the search keyword are displayed. A checkbox group 2005 for specifying, a radio button 2006 for specifying the type of the document to be searched, an accident information document attribute specification column 2007 for specifying the date of occurrence, weather, store and place, A keyword input field 2008 for full-text search, a keyword list button 2009, a category (document) input field 2010, a browse button 2011 for specifying a category, an input specification field 2012 for date specification, a file type Field 2013 and the number of items to be displayed, display order, and narrowing conditions for the creator It includes a field 2014 for entering the. These are not particularly different from the conditions specified in a general keyword search, and will not be described further.
[0063]
Hereinafter, the search processing unit 51 of the KM system server 5 performs a process as shown in FIG. That is, the data of the search condition input in the search condition input field as shown in FIG. 20 is received (step S201), a search is performed using a search keyword or the like, and the corresponding metadata and data managed by the metadata are managed. (Attached file) is extracted from the DB 53 and temporarily stored in the storage device (step S203). In addition, the link data of the extracted metadata is checked by searching the link table (step S205). That is, it is confirmed whether or not the extracted metadata is registered as a link source or a link destination in the link table. When the link data is extracted from the link table, the linked metadata and the data (attached file) managed by the metadata are extracted from the DB 53 and temporarily stored in the storage device (step S207). ). Then, a list of extracted metadata and extracted data (extracted file) is generated and transmitted to the requesting client terminal A (step S209).
[0064]
For example, the extracted metadata and the extracted data (extracted file) are listed as hyperlinks and are referred by the user. Therefore, when the user clicks, a reference request is transmitted from the client terminal A to the KM system server 5. The search processing unit 52 of the KM system server 5 transmits the corresponding metadata or data (attached file) to the client terminal A according to the reference request. The client terminal A displays the selected metadata or data (attached file) on the display device. For example, a display as shown in FIG. 9 is made.
[0065]
Here, when the link button 902 in FIG. 9 is clicked, processing as shown in FIG. 22 is performed. That is, a request to refer to a link is input while referring to the metadata A. The client terminal A receives a link display selection input from the user (step S211), and transmits selected link information including identification information of metadata serving as a key to the KM system server 5 (step S213). Upon receiving the selected link information from the client terminal A (step S215), the search processing unit 52 of the KM system server 5 searches the link table of the DB 53 with the identification information of the metadata as a key, and searches the metadata for the link source. Alternatively, metadata as a link destination is extracted, page data for additionally displaying link data is generated based on the extracted data, and transmitted to the client terminal A (step S217). The client terminal A receives the page data for additionally displaying the link data (or simply displaying if there is no source to be added) and displaying it on the display device (step S219). For example, a screen as shown in FIG. 23 is displayed.
[0066]
In the example of FIG. 23, an end button 2301, a display column 2302 of the metadata name to be searched, a display column 2303 of the link direction, a display column 2304 of the extracted metadata name, a link display button 2305, A link display button 2306 is included. As described above, the link data registered as the metadata A at either the link source or the link destination is displayed. Here, a link to the metadata B is set in the metadata A, and it can be seen from the metadata D that the link is provided. The name portion of the extracted metadata is a hyperlink, and the content of the metadata can be referred to by clicking the hyperlink. Also, a link display button is provided corresponding to the extracted metadata. The link display button is a button for performing the same processing as the link button 902 in FIG.
[0067]
When the link display button 2305 is clicked, the processing shown in FIG. 22 is performed, and a screen as shown in FIG. 24 is displayed. That is, the link data in which the metadata B is registered at either the link source or the link destination is displayed. Here, it is understood that the metadata B is linked from the metadata A and the metadata C. Here, when the link display button 2401 corresponding to the metadata C is clicked, a screen as shown in FIG. 25 is displayed. In FIG. 25, the link data in which the metadata C is registered as either the link source or the link destination is displayed. Here, a link to the metadata B is set in the metadata C, and it is understood from the metadata D that the link is provided.
[0068]
As can be seen from FIGS. 23 to 25, if one piece of metadata is specified, not only the metadata linked from the metadata but also the metadata linked to the metadata. It is also possible to transition to data. As shown in FIG. 26, when a link S is set from metadata A to metadata B and a link t is set from metadata B to metadata C, metadata A, metadata B, and metadata Although the transition can be made in the order of C, the transition can be made in the order of metadata C, metadata B, and metadata A. Even with an HTML tag link, transitions can be made in the order of metadata A, metadata B, and metadata C. However, if there is no reference history, transitions are made in the order of metadata C, metadata B, and metadata A. Can not. According to the present embodiment, even if there is no reference history, if metadata B or C is referred to, metadata A can be traced back. This is because the link table is managed.
[0069]
The search processing in the search processing unit 52 includes not only a search processing based on a search condition mainly based on a search keyword as shown in FIG. 21 but also a search processing by designating specific metadata. . This processing will be described with reference to FIG. When the user specifies a specific metadata and inputs a search instruction to the client terminal A, the client terminal A transmits a search request including the specification of the specific metadata to the KM system server 5. The search processing unit 52 of the KM system server 5 receives the search request including the designation of the metadata (Step S221). Then, data (attached file) managed by the metadata is extracted from the DB 53 and temporarily stored in the storage device (step S223). Further, the link table is searched with the designated metadata, and the link data in which the metadata is registered as the link source or the link destination is extracted and temporarily stored in the storage device (step S225). Then, when the link data is extracted, the linked metadata and the data (attached file) managed by the metadata are extracted and temporarily stored in the storage device (step S227). Then, a list of the extracted metadata and data (attached file) managed by the metadata is generated and transmitted to the client terminal A (step S229). The client terminal A receives the extracted metadata and a list of data (attached file) managed by the metadata and displays the list on the display device.
[0070]
For example, the extracted metadata and the extracted data (extracted file) are listed as hyperlinks and are referred by the user. Therefore, when the user clicks, a reference request is transmitted from the client terminal A to the KM system server 5. The search processing unit 52 of the KM system server 5 transmits the corresponding metadata or data (attached file) to the client terminal A according to the reference request. The client terminal A displays the selected metadata or data (attached file) on the display device.
[0071]
As a result, the user can refer to metadata and the like associated with specific metadata in a list, and can refer to the contents of the metadata and the contents of the attached file.
[0072]
As shown in FIG. 13, there is a method of listing metadata classifications as a list and searching for metadata according to the classifications. However, this does not differ greatly from the search for a file from the directory structure normally provided in the OS, and will not be described further here.
[0073]
According to the above-described embodiment of the present invention, it is possible to formally understand tacit knowledge by associating metadata such as a link table, and handle it in the KM system. Further, since related metadata and the like can be searched based on the link table, an exhaustive search without omission at the time of data search can be performed.
[0074]
Although the embodiment of the present invention has been described above, the present invention is not limited to this. For example, although a screen example is shown, this is an example, and another screen configuration including similar contents may be adopted. Further, for example, the contents divided into a plurality of screens can be combined into one screen, and conversely, the contents displayed on one screen can be displayed on a plurality of screens. Further, as long as the data structure described above can be prepared, the data processing is not limited to the processing flow described above. Further, an example has been shown in which one link data is deleted at a time, but a plurality of link data can be deleted at a time by specifying a plurality of link data at a time.
[0075]
【The invention's effect】
As described above, according to the present invention, it is possible to present data and the relationship between the data in a manner that matches human senses.
[Brief description of the drawings]
FIG. 1 is a system schematic diagram according to an embodiment of the present invention.
FIG. 2 is a conceptual diagram of a data structure according to an embodiment of the present invention.
FIG. 3 is a conceptual diagram of a data structure according to an embodiment of the present invention.
FIG. 4 is a diagram showing an example of a table representing the contents of metadata.
FIG. 5 is a diagram illustrating an example of a link table.
FIG. 6 is a diagram showing a directory structure representing metadata classification.
FIG. 7 is a diagram showing a processing flow of metadata registration processing.
FIG. 8 is a diagram showing an example of a screen at the time of metadata registration.
FIG. 9 is a diagram showing an example of a screen when referring to metadata.
FIG. 10 is a diagram depicting a processing flow of a link registration processing;
FIG. 11 is an example of a screen in a first step of a link registration process.
FIG. 12 is an example of a screen in a second step of the link registration process.
FIG. 13 is an example of a screen showing a classification state of metadata.
FIG. 14 is an example of a screen in a third step of the link registration process.
FIG. 15 is a diagram depicting a processing flow of a link deletion processing;
FIG. 16 is a diagram showing a processing flow of metadata change processing.
FIG. 17 is a diagram illustrating a processing flow of metadata deletion processing.
FIG. 18 is a diagram depicting a processing flow of a data change processing;
FIG. 19 is a diagram depicting a processing flow of a data deletion processing;
FIG. 20 is a diagram showing an example of a search condition input screen.
FIG. 21 is a diagram showing a first search processing flow.
FIG. 22 is a diagram showing a processing flow for link display.
FIG. 23 is a diagram showing a screen example of a first step of link information list display.
FIG. 24 is a diagram illustrating a screen example of a second step of link information list display.
FIG. 25 is a diagram showing a screen example of a third step of link information list display.
FIG. 26 is a diagram illustrating an example of metadata links.
FIG. 27 is a diagram showing a second search processing flow.
[Explanation of symbols]
1 Network
5 KM system server
51 Registration processing unit
52 Search processing unit
53 DB

Claims (9)

メタデータ間のリンク関係をリンク元の識別情報及びリンク先の識別情報の対のデータとして保持する第１データ構造と、
各前記メタデータについて、当該メタデータに関連するデータへのリンク・データを含む第２データ構造と、
前記メタデータの分類を規定する第３データ構造と、
を含み、
前記メタデータの分類と前記メタデータ間のリンク関係とが独立に設定可能な
データ構造。A first data structure that holds a link relationship between metadata as a pair of identification information of a link source and identification information of a link destination;
For each said metadata, a second data structure including link data to data related to said metadata;
A third data structure defining a classification of the metadata;
Including
A data structure in which a classification of the metadata and a link relationship between the metadata can be set independently. 前記第３データ構造が、前記メタデータの分類を木構造により規定することを特徴とする請求項１記載のデータ構造。The data structure according to claim 1, wherein the third data structure defines the classification of the metadata by a tree structure. 前記第２データ構造が、各前記メタデータが属する分類における所定の主題についてのテキスト・データをさらに含むことを特徴とする請求項１記載のデータ構造。The data structure of claim 1, wherein said second data structure further comprises text data for a predetermined subject in a classification to which each said metadata belongs. 登録するメタデータの分類について指定がなされた場合、第１データ格納部に当該メタデータの分類を表すデータを登録するステップと、
メタデータに関連するファイルの指定を受けた場合、前記メタデータから、指定された前記ファイルへのリンク・データを、第２データ格納部に登録するステップと、
メタデータ間のリンク関係がリンク元の識別情報及びリンク先の識別情報の対のデータとして指定された場合、前記リンク元の識別情報及びリンク先の識別情報の対のデータを前記第１データ格納部から独立した第３データ格納部に登録するステップと、
を含み、コンピュータにより実行されるデータ処理方法。Registering data indicating the classification of the metadata in the first data storage when designation is made regarding the classification of the metadata to be registered;
When a file related to the metadata is specified, a step of registering, from the metadata, link data to the specified file in a second data storage unit;
When the link relationship between the metadata is specified as data of a pair of the identification information of the link source and the identification information of the link destination, the data of the pair of the identification information of the link source and the identification information of the link destination is stored in the first data. Registering in a third data storage unit independent of the unit;
And a computer-implemented data processing method. 特定のメタデータの削除要求を受信した場合、前記第１データ格納部及び前記第２データ格納部から前記特定のメタデータに関するデータを削除するステップと、
前記第３データ格納部において、前記特定のメタデータの識別情報が前記リンク元の識別情報及びリンク先の識別情報のいずれかに登録されている前記対のデータを削除するステップと、
を含む請求項４記載のデータ処理方法。When receiving a request to delete specific metadata, deleting data relating to the specific metadata from the first data storage unit and the second data storage unit;
In the third data storage unit, deleting the pair of data in which the identification information of the specific metadata is registered as one of the link source identification information and the link destination identification information;
The data processing method according to claim 4, comprising: 特定のメタデータが特定のユーザにより参照され且つ当該特定のユーザから要求を受けた場合、前記特定のユーザの参照履歴のデータを参照することなく、前記第３データ格納部から、前記特定のメタデータの識別情報が前記リンク先の識別情報として登録されている前記対のデータを抽出し、当該特定のメタデータのリンク元のメタデータを特定するステップ
をさらに含む請求項４記載のデータ処理方法。When the specific metadata is referred to by a specific user and a request is received from the specific user, the specific metadata is read from the third data storage unit without referring to the reference history data of the specific user. 5. The data processing method according to claim 4, further comprising the step of extracting the pair of data whose data identification information is registered as the link destination identification information, and specifying the link source metadata of the specific metadata. . メタデータ間のリンク関係の変更が要求された場合、前記第３データ格納部において該当するリンク元の識別情報及びリンク先の識別情報の対のデータを変更して登録するステップ
をさらに含む請求項４記載のデータ処理方法。10. The method according to claim 9, further comprising the step of: changing and registering data of a pair of the identification information of the link source and the identification information of the link destination in the third data storage unit when a change in the link relationship between the metadata is requested. 4. The data processing method according to 4. 請求項４乃至７のいずれか１つ記載のデータ処理方法をコンピュータにより実行させるためのプログラム。A program for causing a computer to execute the data processing method according to any one of claims 4 to 7. 登録するメタデータの分類について指定がなされた場合、第１データ格納部に当該メタデータの分類を表すデータを登録する手段と、
メタデータに関連するファイルの指定を受けた場合、前記メタデータから、指定された前記ファイルへのリンク・データを、第２データ格納部に登録する手段と、
メタデータ間のリンク関係がリンク元の識別情報及びリンク先の識別情報の対のデータとして指定された場合、前記リンク元の識別情報及びリンク先の識別情報の対のデータを前記第１データ格納部から独立した第３データ格納部に登録する手段と、
を有するデータ処理装置。Means for registering data representing the classification of the metadata in the first data storage unit when designation is made on the classification of the metadata to be registered;
Means for registering, in the second data storage unit, link data to the specified file from the metadata, when a specification of a file related to the metadata is received;
When the link relationship between the metadata is specified as data of a pair of the identification information of the link source and the identification information of the link destination, the data of the pair of the identification information of the link source and the identification information of the link destination is stored in the first data. Means for registering in a third data storage unit independent of the unit;
A data processing device having:
JP2003153845A 2003-05-30 2003-05-30 Data structure, and method and device for processing data Pending JP2004355440A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003153845A JP2004355440A (en) 2003-05-30 2003-05-30 Data structure, and method and device for processing data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003153845A JP2004355440A (en) 2003-05-30 2003-05-30 Data structure, and method and device for processing data

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2007276579A Division JP2008084336A (en) 2007-10-24 2007-10-24 Data structure, as well as apparatus and method for retrieval

Publications (1)

Publication Number Publication Date
JP2004355440A true JP2004355440A (en) 2004-12-16

Family

ID=34048661

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003153845A Pending JP2004355440A (en) 2003-05-30 2003-05-30 Data structure, and method and device for processing data

Country Status (1)

Country Link
JP (1) JP2004355440A (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007004779A (en) * 2005-05-26 2007-01-11 Tokyo Electric Power Co Inc:The Information processing method regarding link generation, link importance and similar document, and its device
JP2007310622A (en) * 2006-05-18 2007-11-29 Tokyo Electric Power Co Inc:The Method and apparatus for presenting guidance
JP2008525880A (en) * 2004-12-22 2008-07-17 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Apparatus and method for controlling personal data

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008525880A (en) * 2004-12-22 2008-07-17 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Apparatus and method for controlling personal data
JP4746053B2 (en) * 2004-12-22 2011-08-10 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Apparatus and method for controlling personal data
JP2007004779A (en) * 2005-05-26 2007-01-11 Tokyo Electric Power Co Inc:The Information processing method regarding link generation, link importance and similar document, and its device
JP2007310622A (en) * 2006-05-18 2007-11-29 Tokyo Electric Power Co Inc:The Method and apparatus for presenting guidance

Similar Documents

Publication Publication Date Title
JP5616491B2 (en) A system that inserts hyperlinks into documents
CA2410747C (en) System and method for saving browsed data
US9858255B1 (en) Computer-implemented method and system for automated claim construction charts with context associations
US7480669B2 (en) Crosslink data structure, crosslink database, and system and method of organizing and retrieving information
US8028231B2 (en) Document management system for searching scanned documents
US8626792B2 (en) Hierarchical structured abstract data organization system
US20060195461A1 (en) Method of operating crosslink data structure, crosslink database, and system and method of organizing and retrieving information
US9495376B2 (en) Content migration tool and method associated therewith
US20060095836A1 (en) Document editing system and method of preparing a tag information management table
JP3946934B2 (en) Web page component integration processing device, web page component integration processing method, and client device
US20070283288A1 (en) Document management system having bookmarking functionality
US20050216825A1 (en) Local storage of script-containing content
JP2008533544A (en) Method and system for operating a source code search engine
JPH11161686A (en) Successive index mechanism
US20070016552A1 (en) Method and apparatus for managing imported or exported data
US11086860B2 (en) Predefined semantic queries
US20060036609A1 (en) Method and apparatus for processing data acquired via internet
JP2000285134A (en) Method and device for managing document and storage medium
JP2004355440A (en) Data structure, and method and device for processing data
JP2008084336A (en) Data structure, as well as apparatus and method for retrieval
JPH117445A (en) Integrated document management device
JP2008541296A (en) Personalizable information network
JP3478070B2 (en) Document reference control method
JP3725835B2 (en) Knowledge information collecting system and knowledge information collecting method
Karayiannis et al. The MySQL Database Server

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070612

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070810

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070925

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071024

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20071213

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20080123

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20080328