(57)【要約】【課題】  デジタルデータの保存、削除、更新または検索が効率よく行われるようにマークアップランゲージ基盤のデータを管理する方法とその装置及び記録媒体が提供される。【解決手段】  マークアップランゲージで表現されたデジタルデータを効率よく管理するためには、フラグメント化し、このフラグメントを関係テーブルで管理する。また、フラグメント化されたデジタルデータに効率よくアクセスするためにはフラグメントを基盤したインデックス構造を提供する。【選択図】  図５
2005174332.tif 000002
【特許請求の範囲】
【請求項１】
マークアップランゲージ基盤のデータが所定のノードグループ別に分割されたフラグメントを提供するデータ提供部と、
前記フラグメント、及び前記フラグメントを識別できる識別子を各フラグメント別に保存する保存部と、
データに対する検索要請時、前記要請されたデータを含むフラグメントを前記保存部で検索して提供するデータ処理部と、を含むことを特徴とするマークアップランゲージ基盤のデータ管理装置。
【請求項２】
前記データ提供部が提供したフラグメントを分析し、前記フラグメント及び前記フラグメントを識別できる識別子を各フラグメント別に前記保存部に保存するフラグメント管理部をさらに含むことを特徴とする請求項１に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項３】
前記フラグメント管理部は、前記分析されたフラグメントが前記保存部に保存されたフラグメントより最新である場合、該当フラグメントを更新することを特徴とする請求項２に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項４】
前記提供されたフラグメントを分析して前記フラグメントに対するインデックスを生成し、前記生成されたインデックスを前記保存部に保存するインデックス管理部をさらに含むことを特徴とする請求項１に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項５】
前記データ提供部は前記フラグメントに対するインデックスをさらに提供することを特徴とする請求項１に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項６】
前記データ提供部が提供したインデックスを分析し、前記インデックス及び前記インデックスを識別できる識別子を各インデックス別に前記保存部に保存するインデックス管理部をさらに含むことを特徴とする請求項５に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項７】
前記インデックス管理部は、前記分析されたインデックスが前記保存部に保存されたインデックスより最新である場合、該当インデックスを更新することを特徴とする請求項６に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項８】
前記データ提供部は、受信されたデジタル放送ストリームのうちフラグメント化されたデータを選別して提供することを特徴とする請求項７に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項９】
前記データ処理部が提供したフラグメントをパージングして出力するメタデータブラウザーをさらに含むことを特徴とする請求項８に記載のマークアップランゲージ基盤のデータ管理装置。
【請求項１０】
マークアップランゲージ基盤のデータが所定のノードグループ別に分割されたフラグメントを提供する段階と、
前記フラグメントを分析して、前記フラグメント及び前記フラグメントを識別できる識別子を各フラグメント別に保存する段階と、
データに対する検索要請時、前記要請されたデータを含むフラグメントを検索して提供する段階と、を含むことを特徴とするマークアップランゲージ基盤のデータ管理方法。
【請求項１１】
前記分析されたフラグメントが既に保存されたフラグメントより最新である場合、該当フラグメントを更新する段階をさらに含むことを特徴とする請求項１０に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１２】
前記提供されたフラグメントを分析して前記フラグメントに対するインデックスを生成し、前記生成されたインデックスを保存する段階をさらに含むことを特徴とする請求項１０に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１３】
前記フラグメントに対するインデックスを提供する段階をさらに含むことを特徴とする請求項１０に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１４】
前記提供されたインデックスを分析して、前記インデックス及び前記インデックスを識別できる識別子を各インデックス別に保存する段階をさらに含むことを特徴とする請求項１３に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１５】
前記分析されたインデックスが既に保存されたインデックスより最新である場合、該当インデックスを更新する段階をさらに含むことを特徴とする請求項１４に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１６】
前記提供されたフラグメントは、受信されたデジタル放送ストリームのうちフラグメント化されたデータを選別したものであることを特徴とする請求項１５に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１７】
前記検索して提供されたフラグメントをパージングして出力する段階をさらに含むことを特徴とする請求項１６に記載のマークアップランゲージ基盤のデータ管理方法。
【請求項１８】
請求項１０から請求項１７のいずれか１項に記載の方法をコンピュータに実行させるためのプログラムを記録したコンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はマークアップランゲージ基盤のデータを管理する方法とその装置及び記録媒体に係り、より詳細にはマークアップランゲージ基盤のデータをフラグメント化して生成、保存、削除または更新してフラグメント化されたデータに対するインデックスを生成、保存、削除または更新する方法及び記録媒体に関する。
【背景技術】
【０００２】
最近、デジタル装置が多く使用されているが、このようなデジタル装置はデジタルデータを処理するデジタル回路を有する装置であって、コンピュータ、プリンタ、スキャナー、ページャ、デジタルカメラ、ＦＡＸ、デジタル複写機、個人用デジタル端末機（ＰＤＡ）、携帯電話、デジタル家電機器、デジタル電話、デジタルプロジェクタ、ホームサーバ、デジタルビデオレコーダ、デジタルＴＶ放送受信機、デジタル衛星放送受信機、及びセットトップボックスなどが例として挙げられる。
【０００３】
一方、このようなデジタル装置が処理するデジタルデータはプログラミング可能に様々な形態のランゲージで構成されうるが、ＳＧＭＬ、ＨＴＭＬ、ＸＭＬのようなマークアップランゲージは構造的な情報伝達の便利さなどによってその使用が次第に増大している。マークアップランゲージに関する詳細な情報は、「ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ」または「ｈｔｔｐ：／／ｗｗｗ．ｘｍｌ．ｃｏｍ」等で探せる。現在最も普遍的に使われるマークアップランゲージは標準機構Ｗ３Ｃの標準であるＸＭＬであり、今後も多様なマークアップランゲージが開発されて使われると予想される。
【０００４】
図１に示されたようにマークアップランゲージで構成されたデジタルデータは一般的に構造とコンテンツとに分けられうる。マークアップランゲージで構成されたデジタルデータは、例えば、図２に示されたように“ＴＶＡＭａｉｎ”１０というルートノードと“ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｏｎ”、“ＰｒｏｇｒａｍＬｏｃａｔｏｎＴａｂｌｅ”、“ＢｒｏａｄｃａｓｔＥｖｅｎｔ”１１、“ＥｖｅｎｔＤｅｓｃｒｉｐｔｉｏｎ”、“ＳｅｒｖｉｃｅＩｄ”１２、“ＰｕｂｌｉｓｈｅｄＴｉｍｅ”１３、“ＰｕｂｌｉｓｈｅｄＤｕｒａｔｉｏｎ”１４のような子ノードで構成された階層構造を有しうる。参考に、図２は、ＴＶ−Ａｎｙｔｉｍｅフォーラムで放送プログラムに対するメタデータとして使用するデジタルデータの階層構造の一部を示したものである。ＴＶ−Ａｎｙｔｉｍｅフォーラムは個人用大容量保存装置を有するＰＤＲ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ｒｅｃｏｒｄｅｒ）のようなユーザ環境でオーディオ・ビジュアル関連サービス提供のための標準開発を目的として１９９９年９月に設立された民間標準機構である。
【０００５】
デジタル装置は、マークアップランゲージで表現されて所定規約による構造を有するデジタルデータの処理時、前記構造に関する情報に基づき、さらに迅速に所望のコンテンツにアクセスしうる。
【０００６】
したがって、マークアップランゲージで作成され、所定の規約により事前指定された構造を有するデジタルデータが一旦生成されれば、このデジタルデータは前記規約によるコンピュータ、ＰＤＡ、携帯電話などの多様なデジタル装置で効率よく処理されうる。
【０００７】
このような長所によって、マークアップランゲージで作成されたデジタルデータはコンピューティング能力に優れた大規模なシステムだけでなく、制限されたコンピューティング能力を有する小型デジタル装置でも多用されている。
【０００８】
現在マークアップランゲージで作成されるデジタルデータとしては、電話番号リストのような任意の個人情報を始めとして、マルチメディアデータを記述し、管理するためのメタデータまで多様な種類のデジタルデータがあり、使用目的によって多様なコンテンツ及び構造を有するデジタルデータが活用されている。
【０００９】
このようなマークアップランゲージで作成されるデジタルデータを管理するために多様な方法が使われてきたが、例えば、ＸＭＬデータを保存して検索する方法としては、図３に示されたようなノードナンバリング方法が代表的な方法である。ノードナンバリング方法については非特許文献１、２、３に開示されている。
【００１０】
ノードナンバリング方法は、ＸＭＬ文書上の各ノード（エレメントあるいはアトリビュート）を関係テーブルのタプル（ｔｕｐｌｅ）で自然にマッピングしうる。各タプルは＜ｄｏｃ＿ｉｄ、ｂｅｇｉｎ＿ｐｏｓ、ｅｎｄ＿ｐｏｓ、ｌｅｖｅｌ＞の構造で表現される。
【００１１】
ここで、ｄｏｃ＿ｉｄは文書のＩＤを、ｂｅｇｉｎ＿ｐｏｓとｅｎｄ＿ｐｏｓは文書内での該当ノードの位置情報を、ｌｅｖｅｌはルートノードからの深さを示す。例えば、図１のＸＭＬ文書でＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎノード内に存在するノードだけを考慮すれば、ノードナンバリング方法によって各ノードに該当するタプルは図３で表示したツリーのノードで表現される。
【００１２】
前記図面では、あらゆるノードが同じ文書に属するためにｄｏｃ＿ｉｄは１に設定され、端末ノードは親ノードのテキスト値を指定する特別なノードタイプとして使われた。
【００１３】
ノードナンバリング方法では、ＸＰａｔｈ及びＸＱｕｅｒｙ言語で各々‘／／’及び‘／’で表現されるノード間の先祖−子孫（ａｎｃｅｓｔｏｒ−ｄｅｓｃｅｎｄａｎｔ）関係及び親−子（ｐａｒｅｎｔ−ｃｈｉｌｄ）関係が各タプルのフィールド値を比較することによって判明される。すなわち、ノード‘Ａ’がノード‘Ｂ’の先祖ノード（ｉ．ｅ．，Ａ／／Ｂ）であれば、‘Ａ．ｄｏｃ＿ｉｄ＝＝Ｂ．ｄｏｃ＿ｉｄ、Ａ．ｂｅｇｉｎ＿ｐｏｓ＜Ｂ．ｂｅｇｉｎ＿ｐｏｓ、Ａ．ｅｎｄ＿ｐｏｓ＞Ｂ．ｅｎｄ＿ｐｏｓ’条件を満足する。ノード‘Ａ’がノード‘Ｂ’の親ノード（すなわち、Ａ／Ｂ）であれば、前の条件に‘Ａ．ｌｅｖｅｌ＝＝Ｂ．ｌｅｖｅｌ−１’が追加される。このような性質を用いて、ＸＰａｔｈあるいはＸＱｕｅｒｙ言語で‘Ａ／Ｂ’または‘Ａ／／Ｂ’で表現された質疑を満足するノード対は前記条件を用いた構造結合（ｓｔｒｕｃｔｕｒａｌ  ｊｏｉｎ）によって得られる。
【００１４】
ノードナンバリング方法は、入力データについてＤＴＤあるいはＸＭＬＳｃｈｅｍａなどの情報なしでも一般的なＸＭＬデータを保存して検索できるという長所を有する。しかし、この方法はコンピューティング能力が落ちる小型デジタル装置で幾つかの短所を有する。ＸＭＬ検索時、必須要素といえる経路式（ｐａｔｈｅｘｐｒｅｓｓｉｏｎ）を処理するのに経路式の長さほどの回数の結合が必要である。
【００１５】
小型デジタル装置でこのような演算はメモリ不足を引き起こして頻繁なＩ／Ｏ（書き込み／読み出し）を発生させるために性能低下が深刻になりうる。ＸＭＬデータの復元側面でも同様な結果を引き起こす。最後に、アップデートも子ノードのアップデートが親ノードのアップデートを引き起こさせるので、効率的でないという短所を有する。
【００１６】
ＸＭＬ文書を保存して検索する従来の他の方法として、アトリビュートインライニング方法がある。この方法は、１つ以上のＸＭＬノードを同じテーブル内に束ねて入れることによって、ノードナンバリング方法によって発生する過度なＸＭＬ文書の断片化現象を減らしたものであって、与えられたＤＴＤあるいはＸＭＬ  Ｓｃｈｅｍａを参照して自動で関係型データベースを構築しうる。
【００１７】
アトリビュートインライニング方法に関する詳細な内容は、非特許文献４に開示されている。
【００１８】
しかし、アトリビュートインライニング方法もＤＴＤ内にある多くのノードが複数のカージナリティを有する場合には、ノードナンバリング方法と同様に多くの演算が必要であり、ＸＭＬデータのスキーマ（ＤＴＤ）に非常に敏感なので、ノードの属性が変わればデータベースを再生成せねばならないという難点がある。
【００１９】
したがって、マークアップランゲージで作成されたデジタルデータを効率よく管理するための方法が必要となった。
【非特許文献１】Ｃｈｕｎ  Ｚｈａｎｇ，  Ｊｅｆｆｒｅｙ  Ｆ．Ｎａｕｇｈｔｏｎ，Ｑｉｏｎｇ  Ｌｕｏ，Ｄａｖｉｄ  Ｊ．ＤｅＷｉｔｔ，及びＧｕｙ  Ｍ．Ｌｏｈｍａｎの“Ｏｎ  ｓｕｐｐｏｒｔｉｎｇ  ｃｏｎｔａｉｎｍｅｎｔ  ｑｕｅｒｉｅｓ  ｉｎ  ｒｅｌａｔｉｏｎａｌ  ｄａｔａｂａｓｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍｓ，  ”Ｉｎ  Ｐｒｏｃ．ｏｆ  ｔｈｅ  ２００１  ＡＣＭ−ＳＩＧＭＯＤ  ｃｏｎｆｅｒｅｎｃｅ，Ｓａｎｔａ  Ｂａｒｂａｒａ，ＣＡ，ＵＳＡ，Ｍａｙ  ２００１
【非特許文献２】Ｑｕａｎｚｈｏｎｇ  Ｌｉ及びＢｏｎｇｋｉＭｏｏｎの“Ｉｎｄｅｘｉｎｇ  ａｎｄ  ｑｕｅｒｙｉｎｇ  ＸＭＬ  ｄａｔａ  ｆｏｒ  ｒｅｇｕｌａｒ  ｐａｔｈ  ｅｘｐｒｅｓｓｉｏｎｓ，”Ｉｎ  Ｐｒｏｃ．ｏｆ  ｔｈｅ  ２６ｔｈ  ＶＬＤＢ  ｃｏｎｆｅｒｅｎｃｅ，  Ｒｏｍｅ，  Ｉｔａｌｙ，  Ｓｅｐ．  ２００１
【非特許文献３】Ｔｏｒｓｔｅｎ  Ｇｒｕｓｔの“Ａｃｃｅｌｅｒａｔｉｎｇ  Ｘｐａｔｈ  Ｌｏｃａｔｉｏｎ  Ｓｔｅｐｓ，”Ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２００２  ＡＣＭ−ＳＩＧＭＯＤ  ｃｏｎｆｅｒｅｎｃｅ，ｐａｇｅｓ  １０９−１２０，  Ｍａｄｉｓｏｎ，  Ｗｉｓｃｏｎｓｉｎ，Ｊｕｎｅ  ２００２
【非特許文献４】Ｊａｖａｖｅｌ  Ｓｈａｎｍｕｇａｓｕｎｄａｒａｍ，  Ｋｒｉｓｔｉｎ  Ｔｕｆｔｅ，  Ｃｈｕｎ  Ｚｈａｎｇ，  Ｇａｎｇ  Ｈｅ，  ＤａｖｉｄＪ．Ｄｅｗｉｔｔ，及びＪｅｆｆｒｅｙ  Ｆ．Ｎａｕｇｈｔｏｎの“Ｒｅｌａｔｉｏｎａｌ  ｄａｔａ  ｂａｓｅｓ  ｆｏｒ  ｑｕｅｒｙｉｎｇ  ＸＭＬ  ｄｏｃｕｍｅｎｔｓ：Ｌｉｍｉｔａｔｉｏｎｓ  ａｎｄ  ｏｐｐｏｒｔｕｎｉｔｉｅｓ，”Ｉｎ  Ｐｒｏｃ．ｏｆ  ｔｈｅ  ２５ｔｈ  ＶＬＤＢ  ｃｏｎｆｅｒｅｎｃｅ，ｐａｇｅｓ  ３０２−３１４，Ｅｄｉｎｂｕｒｇｈ，Ｓｃｏｔｌａｎｄ，Ｓｅｐ．１９９９
【発明の開示】
【発明が解決しようとする課題】
【００２０】
本発明は前記問題点を鑑みてマークアップランゲージ基盤のデータを効率よく管理するための方法とその装置及びそのデータを記録した記録媒体を提供することを目的とする。
【００２１】
本発明はマークアップランゲージ基盤のデータに関する効率的なインデックス方法とその装置及びそのインデックスを記録した記録媒体を提供することを他の目的とする。
【課題を解決するための手段】
【００２２】
前記本発明の目的を達成するために本発明の実施例によるマークアップランゲージ基盤のデータ管理装置は、マークアップランゲージ基盤のデータが所定のノードグループ別に分割されたフラグメントを提供するデータ提供部と、前記フラグメント、及び前記フラグメントを識別できる識別子を各フラグメント別に保存する保存部と、データに対する検索要請時、前記要請されたデータを含むフラグメントを前記保存部で検索して提供するデータ処理部と、を含む。
【００２３】
前記実施例で、前記データ提供部が提供したフラグメントを分析し、前記フラグメント及び前記フラグメントを識別できる識別子を各フラグメント別に前記保存部に保存するフラグメント管理部をさらに含むことが望ましい。
【００２４】
また、前記フラグメント管理部は、分析されたフラグメントが前記保存部に保存されたフラグメントより最新である場合、該当フラグメントを更新することが望ましい。
【００２５】
一方、前記提供されたフラグメントを分析して前記フラグメントに対するインデックスを生成し、前記生成されたインデックスを前記保存部に保存するインデックス管理部をさらに含むことが望ましい。
【００２６】
また、前記データ提供部は前記フラグメントに対するインデックスをさらに提供することが望ましい。
【００２７】
また、前記データ提供部が提供したインデックスを分析し、前記インデックス及び前記インデックスを識別できる識別子を各インデックス別に前記保存部に保存するインデックス管理部をさらに含むことが望ましい。
【００２８】
また、前記インデックス管理部は、前記分析されたインデックスが前記保存部に保存されたインデックスより最新である場合、該当インデックスを更新することが望ましい。
【００２９】
また、前記データ提供部は、受信されたデジタル放送ストリームのうちフラグメント化されたデータを選別して提供することが望ましい。
【００３０】
また、前記データ処理部が提供したフラグメントをパージングして出力するメタデータブラウザーをさらに含むことが望ましい。
【００３１】
本発明の実施例によるマークアップランゲージ基盤のデータ管理方法は、マークアップランゲージ基盤のデータが所定のノードグループ別に分割されたフラグメントを提供する段階と、前記フラグメントを分析し、前記フラグメント及び前記フラグメントを識別できる識別子を各フラグメント別に保存する段階と、データに対する検索要請時、前記要請されたデータを含むフラグメントを検索して提供する段階と、を含む。
【００３２】
前記実施例で、前記分析されたフラグメントが既に保存されたフラグメントより最新である場合、該当フラグメントを更新する段階をさらに含むことが望ましい。
【００３３】
一方、前記提供されたフラグメントを分析して前記フラグメントに対するインデックスを生成し、前記生成されたインデックスを保存する段階をさらに含むことが望ましい。
【００３４】
また、前記フラグメントに対するインデックスを提供する段階をさらに含むことが望ましい
【００３５】
また、前記提供されたインデックスを分析し、前記インデックス及び前記インデックスを識別できる識別子を各インデックス別に保存する段階をさらに含むことが望ましい。
【００３６】
また、前記分析されたインデックスが既に保存されたインデックスより最新である場合、該当インデックスを更新する段階をさらに含むことが望ましい。
【００３７】
また、前記提供されたフラグメントは、受信されたデジタル放送ストリームのうちフラグメント化されたデータを選別したものであることが望ましい。
【００３８】
また、前記検索して提供されたフラグメントをパージングして出力する段階をさらに含むことが望ましい。
【００３９】
本発明の実施例によるマークアップランゲージ基盤のデータ管理方法をコンピュータに実行させるためのプログラムを記録したコンピュータ可読記録媒体は、前述した実施例による方法を実行すべく構成される。
【００４０】
その他の実施例の具体的な事項は詳細な説明及び図面に含まれている。
【発明の効果】
【００４１】
本発明によれば、マークアップランゲージ基盤のデータをフラグメント化し、各フラグメントを所定の関係テーブルを用いて管理することによって、デジタルデータの保存、削除、更新または検索が効率よく行われる。また、デジタルデータに対するインデックスをフラグメントに基づいて構成することによって、インデックスの構成が容易であり、インデックスを用いた検索も効率よく行われる。このような管理方法は軽量の保存能力を有するデジタル装置において効率的である。
【発明を実施するための最良の形態】
【００４２】
本発明の利点及び特徴、そしてこれを達成する方法は添付された図面に基づいて詳細に後述されている実施例を参照すれば明確になる。しかし、本発明は以下で開示される実施例に限定されるものではなく、この実施例から外れて多様な形に具現でき、本明細書で説明する実施例は本発明の開示を完全にし、本発明が属する技術分野で当業者に発明の範ちゅうを完全に報せるために提供されるものであり、本発明は請求項及び発明の詳細な説明により定義されるだけである。一方、明細書全体に亙って同一な参照符号は同一な構成要素を示す。
【００４３】
以下、添付された図面を参照して本発明の実施例によるマークアップランゲージ基盤のデータを管理する方法と装置及び記録媒体を具体的に説明する。
【００４４】
本発明の実施例を詳述する前に、マークアップランゲージで表現されたデジタルデータのフラグメント化に対する概念を先に説明する。フラグメント化はデジタルデータのブロック化を意味するが、本発明の実施例によるマークアップランゲージ基盤のデータを管理する方法と装置及び記録媒体は基本的にデジタルデータをフラグメント基盤で管理する。マークアップランゲージで表現されたデジタルデータのフラグメント政策は該当デジタル装置により決定され、所定のデジタルデータを送受信する多数のデジタル装置（以下‘ドメイン’と称する）間の規約によっても決定されうる。
【００４５】
図４を参照してフラグメントの概念を簡略に説明すれば、フラグメントとは、図１及び２に示されたマークアップランゲージで構成されたデジタルデータを所定のツリー構造別に分割したものである。
【００４６】
例えば、“ＴＶＡＭａｉｎ”を上位ノードとして所定の子ノードまで含むツリー構造（フラグメントＴＶＡＭａｉｎ）、プログラム情報（ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を上位ノードとし、以下子ノードまで含むツリー構造（フラグメントＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ）、ブロードキャストイベント情報（Ｂｒｏａｄｃａｓｔ  Ｅｖｅｎｔ）を上位ノードとし、以下子ノードまで含むツリー構造（フラグメントＢｒｏａｄｃａｓｔＥｖｅｎｔ）などに分割する場合、分割されたツリー構造それぞれは別途のフラグメントとなる。
【００４７】
このようなデジタルデータのフラグメント化はデータ量の多いデジタルデータを管理するか、このデジタルデータの転送時に有用である。例えば、デジタルデータがフラグメント化され、そのフラグメントが他のフラグメントと識別可能に構成されるならば、データ管理時に必要なフラグメントだけ個別的にアクセスでき、デジタルデータの転送時にも他のフラグメントと独立して転送できる利点が発生する。
【００４８】
１つのドメイン内でマークアップランゲージの階層構造は一連のフラグメント、すなわち一連のフラグメントタイプに分けられる。１つのフラグメントタイプは他のフラグメントタイプの子になりうる。図４では、ＴＶＡＭａｉｎ、ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ、ＢｒｏａｄｃａｓｔＥｖｅｎｔの３つのフラグメントタイプが存在する。図４では、３つのフラグメントに分割したが、分割方式及び分割されたフラグメントの数は該当ドメインのフラグメント政策によって任意に決定されうる。
【００４９】
一方、各フラグメントは独立して更新されうるために、相異なるフラグメントに属する両ノード間の親−子関係はこれ以上有効でないこともある。したがって、マークアップランゲージ基盤のデジタルデータをフラグメント化する時、特定の両ノード間の親−子関係を維持するためにはフラグメント政策が該当両ノードを同じフラグメントタイプに属するように設計されるか、あるいは１つのノードが他のノードを参照できるＩＤＲＥＦタイプノードの使用のような追加的な考慮が適用されうる。
【００５０】
デジタルデータのフラグメント化はマークアップランゲージ基盤のデジタルデータにアクセスする時、より詳細にはデジタルデータの所定ノードをアクセスさせる時にさらに有用である。
【００５１】
まず、フラグメント政策を参考にして、アクセスしようとするノードが該当するフラグメントを確認し、以後フラグメントで直ちに該当ノードをアクセスさせうる。したがって、あらゆるデジタルデータを処理せずとも該当フラグメントだけを処理して所望の情報を獲得できる。
【００５２】
一方、フラグメント化されたデジタルデータの所定ノードを表示する方法として、ＸＭＬの場合Ｗ３Ｃで定義したＸＰａｔｈ（ＸＰａｔｈはＷ３Ｃで定義したＸＭＬ文書内のノードに対する経路を記述するｓｙｎｔａｘである）を使用しうる。ＸＰａｔｈを使用し、ａ）  表示しようとするノードが含まれるフラグメントの上位ノードをデジタルデータの最上位ノードからの絶対経路として表示し、ｂ）  該当フラグメントの上位ノードで表示しようとするノードまでの相対経路を表示することによって任意のフラグメントに含まれたノードを表示しうる。
【００５３】
フラグメント化されたデジタルデータを識別するために、前述した表示方法が使われうる。例えば、各フラグメントを識別するために、各フラグメントのａ）  上位ノードの絶対経路を活用しうる。また、絶対経路をＸｐａｔｈとして表現する方法以外に、ある程度定形化された絶対経路が存在する場合、この定形化された絶対経路を所定のマッピングルールによってコードで表現する方法も可能である。例えば、前述した図２及び図４のＢｒｏａｄｃａｓｔＥｖｅｎｔフラグメントをＸｐａｔｈとして表現すれば‘／ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／  ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ／ＢｒｏａｄｃａｓｔＥｖｅｎｔ’となり、これを所定のマッピングルールによって‘ＦＦ０１’で表現することもできる。この場合、前記ＢｒｏａｄｃａｓｔＥｖｅｎｔフラグメントのタイプは‘ＦＦ０１’により識別されうる。
【００５４】
以下では本発明の望ましい実施例によるデータの管理構造を説明する。
この実施例ではフラグメント化されたデジタルデータを表１のような関係テーブルとして管理する。
【００５５】
【表１】
2005174332.tif 000003
【００５６】
表１の関係テーブルは、各フラグメントに対するフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄ、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅ、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎ、フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔで構成される。
【００５７】
ここで、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄは各フラグメントを識別する識別子であって転送ネットワークやデータベース内で該当フラグメントを識別するためのものであり、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅは該当フラグメントが如何なるフラグメントタイプであるかを示す。フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎは該当フラグメントのバージョンを示す。フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔはフラグメント化されたデジタルデータが保存される所であって、そのデジタルデータはテキスト形態のフラグメント自体または該当フラグメントをパージングした後の形で保存可能である。
【００５８】
このような関係テーブルを用いてフラグメント化されたデジタルデータを管理する場合、デジタル機器があらゆるデジタルデータを処理せずとも所望の情報に対して効率よくアクセスしうる。所望の情報にアクセスするために、まず所望の情報が含まれたフラグメントタイプを確認する。この際、フラグメントタイプは前述したフラグメント政策により容易に確認されうる。
【００５９】
次いで、同じフラグメントタイプを有する複数のフラグメントが存在する場合、フラグメントバージョンを確認して最も最新のフラグメントを選択する。選択されたフラグメントのフラグメントコンテンツを確認することによって所望の情報を得られる。もし、フラグメントコンテンツがパージングされていないテキスト形態のフラグメント内容そのものならば、該当内容をパージングする手続きを行って所望の情報を抽出する。
【００６０】
以下では本発明の望ましい実施例に係るデジタルデータに対するインデックス構造を説明する。
【００６１】
いずれの条件を満足するフラグメントを検索するために、関係テーブル内にあるあらゆるフラグメントの内容を見るより、検索条件として頻繁に参照されるノードをあらかじめインデクシングし、このインデックスを参照することがさらに望ましい。
【００６２】
インデックスは、フラグメントタイプに対してそのタイプに属する任意のノード値をキー値として作られる。例えば、図１のＸＭＬ文書でＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎフラグメントタイプに対してＧｅｎｒｅノード値をキー値としてインデックスを生成すれば、特定ジャンルに属するプログラムの情報を効率よく検索できるようになる。
【００６３】
したがって、デジタルデータに対する効率的な検索とアクセスとを許容するために、このデジタルデータに対するインデックス構造を提供することが望ましい。
【００６４】
マークアップランゲージで表現されたデジタルデータの所定のノードを、インデックスのためのキーとして使用しうる。例えば、図２では、‘放送時間’でインデクシングするために‘ＰｕｂｌｉｓｈｅｄＴｉｍｅ’がキーとして使われうる。
【００６５】
キーを表現するために、前述したように、キーに対応するノードを含むフラグメントの絶対経路と、該当フラグメント内での相対経路とを使用できる。
【００６６】
図２及び図４を参照して説明すれば、‘放送時間’がキーとして使われる場合、このキーに関する情報はａ）‘ＰｕｂｌｉｓｈｅｄＴｉｍｅ’が含まれたフラグメント（すなわち、フラグメント‘ＢｒｏａｄｃａｓｔＥｖｅｎｔ’）の絶対経路である‘／ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＬｏｃａｔｉｏｎ  Ｔａｂｌｅ／ＢｒｏａｄｃａｓｔＥｖｅｎｔ’と、ｂ）フラグメント‘ＢｒｏａｄｃａｓｔＥｖｅｎｔ’内で‘ＰｕｂｌｉｓｈｅｄＴｉｍｅ’の相対経路である‘ＥｖｅｎｔＤｅｓｃｒｉｐｔｉｏｎ／ＰｕｂｌｉｓｈｅｄＴｉｍｅ’となる。
【００６７】
結論的に、マークアップランゲージで表現されたデジタルデータを効率よく管理するためにはフラグメント化することが望ましく、このフラグメントは前述した形態の関係テーブルとして管理することが望ましい。一方、フラグメント化されたデジタルデータに効率よくアクセスするためにはインデックス構造を提供することがさらに望ましい。
【００６８】
インデックス構造で使われるキーは所定のフラグメントに含まれた所定のノードとなり得、インデックス構造を活用して所望のコンテンツであるフラグメントを直接アクセス可能である。一方、インデックス構造に使われるキーに関する情報として、キーに対応するノードを含むフラグメントの絶対経路と、該当フラグメント内での相対経路とを使用しうる。
【００６９】
インデックス構造に使われるキーに関する情報として、前述した絶対経路と相対経路とをＸＰａｔｈで表現する方法以外に、ある程度定形化された絶対経路と相対経路とが存在する場合、この定形化された絶対経路と相対経路とを所定のマッピングルールによってコードで表現する方法も可能である。例えば、前述した図２及び図３の‘／ＴＶＡＭａｉｎ／ＰｒｏｇｒａｍＤｅｓｃｒｉｐｔｉｏｎ／ＰｒｏｇｒａｍＬｏｃａｔｉｏｎＴａｂｌｅ／ＢｒｏａｄｃａｓｔＥｖｅｎｔ’を所定のマッピングルールによって‘ＦＦ０１’及び‘ＥｖｅｎｔＤｅｓｃｒｉｐｔｉｏｎ／ＰｕｂｌｉｓｈｅｄＴｉｍｅ’を各々‘ＡＡ０１’で表現することもできる。
【００７０】
本発明の望ましい実施例に係るインデックス構造は図５に図示されている。
【００７１】
本発明の望ましい実施例に係るマークアップランゲージ基盤データの全体構造は、大きくインデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００、インデックスキーフィールド部（ＩｎｄｅｘＫｅｙｆｉｅｌｄ）２００、インデックス部（Ｉｎｄｅｘ）３００ａ、３００ｂ、フラグメント部（フラグメント）４００の４つの部分で構成される。
【００７２】
前述したように、フラグメント部４００はフラグメント化されたデジタルデータが保存される関係テーブルであって、前述したように、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄ、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅ、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎ、フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔで構成される。
【００７３】
一方、インデックスのために、インデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００、インデックスキーフィールド部（ＩｎｄｅｘＫｅｙｆｉｅｌｄ）２００、及びインデックス部（Ｉｎｄｅｘ）３００ａ、３００ｂが提供される。
【００７４】
インデックス部３００を構成する各エントリーはキー値ｋｅｙ＿ｖａｌｕｅ、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄ、及びフラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎフィールドで構成される。キー値ｋｅｙ＿ｖａｌｕｅは１つ以上のフィールドで構成された多重値で構成されうる。フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄはフラグメント部４００のフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄと同一であり、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎはフラグメント部４００のフラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎと同一である。フラグメントのためのインデックスはＢ−ｔｒｅｅのような一般的に広く知られたインデックス技法で構築が可能である。
【００７５】
データベース内には１つ以上のインデックスが存在できるために、各インデックスを記述する２個の補助データ構造が提供されうる。
【００７６】
インデックス辞書部１００は各インデックスに関する情報を記述するが、インデックス識別子ｉｎｄｅｘ＿ｉｄ、インデックスバージョンｉｎｄｅｘ＿ｖｅｒｓｉｏｎ、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅ、キーフィールド数ｎｕｍ＿ｋｅｙ＿ｆｉｅｌｄ、及びキーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄの構造で構成される。
【００７７】
ここで、インデックス識別子ｉｎｄｅｘ＿ｉｄはインデックスを識別するＩＤであり、インデックスバージョンｉｎｄｅｘ＿ｖｅｒｓｉｏｎはインデックスのバージョンを表し、キーフィールド数ｎｕｍ＿ｋｅｙ＿ｆｉｅｌｄはキーを構成するフィールド（ノード）の数を表し、キーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄはキーフィールドを識別するＩＤである。インデックスキーフィールド部２００はインデックス部３００のキーフィールドに関する情報を記述するが、キーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄ、キーフィールド経路ｋｅｙ＿ｆｉｅｌｄ＿ｐａｔｈ、キーフィールドタイプｋｅｙ＿ｆｉｅｌｄ＿ｔｙｐｅで構成される。キーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄはキーフィールドのＩＤを表し、キーフィールド経路ｋｅｙ＿ｆｉｅｌｄ＿ｐａｔｈはキーフィールドのマークアップランゲージデータ構造上で該当フラグメントから該当キーフィールドまでの経路（相対経路）を表し、キーフィールドタイプｋｅｙ＿ｆｉｅｌｄ＿ｔｙｐｅはキーフィールドのデータベース内でのタイプを表す。他の実施例で、キーフィールド経路ｋｅｙ＿ｆｉｅｌｄ＿ｐａｔｈとしてキーフィールドのマークアップランゲージデータ構造上でルートノードから該当キーフィールドまでの経路（絶対経路）が使われうる。
【００７８】
このようなマークアップランゲージ基盤のデータ構造を用いたデジタルデータの管理方法については図８Ａ，Ｂ，Ｃを参照して後述する。
【００７９】
図６は、図５に示されたデータ管理構造を用いて図１のデジタルデータを管理する実施例を図示する。
【００８０】
この実施例では、図１のデジタルデータに対するインデックスの情報を記述するが、この実施例は、例示的に‘ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ’というフラグメント内に含まれた‘ジャンル’をキーとし、キー値として‘ニュース’を有するインデックスに関して説明する。
【００８１】
この実施例のインデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００は、フラグメントタイプが‘ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ’のフラグメントに対するインデックスであってインデックス識別子ｉｎｄｅｘ＿ｉｄが‘１’であり、インデックスバージョンｉｎｄｅｘ＿ｖｅｒｓｉｏｎが‘２’であるインデックス部３００に関する情報を含んでいる。また、このインデックス部３００のキーフィールドに関する情報を有するインデックスキーフィールド部２００に関する情報として、キーフィールド数ｎｕｍ＿ｋｅｙ＿ｆｉｅｌｄ及びキーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄをさらに含む。この実施例で‘ジャンル’に対する１つのキーフィールドだけ有するので、キーフィールド数ｎｕｍ＿ｋｅｙ＿ｆｉｅｌｄは‘１’であり、このキーフィールドに関する情報を有するインデックスキーフィールド部２００のキーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄは‘７’である。
【００８２】
インデックスキーフィールド部２００は‘ジャンル’キーフィールドに関する情報を記述するが、キーフィールド識別子ｋｅｙ＿ｆｉｅｌｄ＿ｉｄは‘７’、キーフィールド経路ｋｅｙ＿ｆｉｅｌｄ＿ｐａｔｈは‘ＢａｓｉｃＤｅｓｃｒｉｐｔｉｏｎ／Ｇｅｎｒｅ’、キーフィールドタイプｋｅｙ＿ｆｉｅｌｄ＿ｔｙｐｅは‘ｓｔｒｉｎｇ’である。
【００８３】
図６のインデックス部３００のエントリーは、‘ジャンル’キーフィールドに対してキー値ｋｅｙ＿ｖａｌｕｅが‘ニュース’のエントリーである。キー値ｋｅｙ＿ｖａｌｕｅが‘ニュース’である、すなわちジャンルがニュースのデジタルデータを含むフラグメントのフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄは‘１２３’であり、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎは‘１’である。したがって、ユーザはキーフィールドが‘ジャンル’のインデックス部３００をインデックス辞書部１００及びインデックスキーフィールド部２００を参照して検索し、インデックス部３００内でキー値が‘ニュース’のエントリーを検索し、このエントリーでフラグメントのフラグメント識別子とフラグメントバージョンとを抽出する。最終的に、これを用いてフラグメント部４００で‘ジャンル’が‘ニュース’のデジタルデータを含むフラグメントを検索できる。
【００８４】
図７は、本発明の一実施例に係るマークアップランゲージ基盤のデータを管理するデジタル装置を示すブロック図である。
【００８５】
本発明の一実施例に係るマークアップランゲージ基盤のデータを管理するデジタル装置５００は、フラグメント化されたデジタルデータを提供するデータ提供部５１０、提供されたフラグメントを本発明に係るデータ構造で変更するフラグメント管理部５２０、フラグメントに対するインデックスを生成または更新するインデックス管理部５３０、提供されたフラグメント及びインデックスを保存部５７０に保存し、保存されたデジタルデータに対する検索を行うデータ処理部５４０、及び検索を要請して必要なデジタルデータをデータ処理部５４０から受信して活用するアプリケーション５６０より構成されうる。
【００８６】
データ提供部５１０は所定のフラグメント政策によってフラグメント化されたデジタルデータを提供する機能を行う。データ提供部５１０はフラグメント化されたデジタルデータを自ら生成するか、他のデジタル装置より受信して提供する。
【００８７】
他のデジタル装置よりフラグメント化されたデジタルデータを受信する時、デジタルデータだけでなく、このデジタルデータに対するインデックスまで受信することもできる。この場合、受信されたインデックスはインデックス管理部５３０に提供されて管理される。
【００８８】
フラグメント管理部５２０はデータ提供部５１０が提供したフラグメント化されたデジタルデータを分析して表１に係る関係テーブルに該当フラグメントを保存させる。
【００８９】
所定のフラグメントを分析し、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄ、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅ、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎ、フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔの情報を抽出し、これをデータ処理部５４０に伝達する。既に保存されたフラグメントに対して更新されたフラグメントが受信される場合、保存されている該当フラグメントを更新する役割も行う。
【００９０】
インデックス管理部５３０は、データ処理部５４０が提供したフラグメント化されたデジタルデータを分析して図５のインデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００、インデックスキーフィールド部（ＩｎｄｅｘＫｅｙｆｉｅｌｄ）２００及びインデックス部（Ｉｎｄｅｘ）３００ａ、３００ｂを生成する。
【００９１】
もし、データ提供部５１０からインデックスが受信される場合、インデックス管理部５３０は上の情報を自ら生成する役割以外に、これを分析する役割も行える。また、インデックス管理部は保存されたフラグメントに対して更新されたフラグメントが受信される場合、これにより該当インデックスを更新する役割も行える。
【００９２】
データ処理部５４０はフラグメント管理部５４０及びインデックス管理部５３０から処理結果を受信し、これを保存部５７０に保存し、アプリケーション５６０の要請によって該当フラグメントを保存部５７０で検索し、必要なデジタルデータを抽出し、これをアプリケーション５６０に伝達する。もし、保存部５７０に保存された関係テーブルのフラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔがテキスト形態のフラグメント自体である場合には、これをパージングして必要なデジタルデータをアプリケーション５６０に伝達しうる。
【００９３】
またデータ処理部５４０は新たなフラグメントが受付けられた場合、これをインデックス管理部５３０に通知し、インデックス管理部５３０をして該当インデックスを更新させる。
【００９４】
データ処理部５４０は保存部５７０を管理する役割も行うが、ユーザの要請または所定のアルゴリズムによって保存部５７０に保存されたフラグメントまたはインデックスを選択的に削除するようにフラグメント管理部５２０及びインデックス管理部５３０に要請する。一方、フラグメントだけ削除要請を受けた場合でも、該当インデックスもこれ以上必要がないので共に削除されることが望ましい。したがって、データ処理部５４０は所定のフラグメントの削除をインデックス管理部５３０に通知し、保存されたインデックスを修正するように要請することもできる。
【００９５】
図７に示されたデジタル装置５００の動作をまとめれば次の通りである。
【００９６】
本発明の実施例に係るデジタル装置は下記の動作を全て行えるが、デジタル装置の性能または機能によって１つ以上の動作を選択的に行える。
【００９７】
１．フラグメント化されたデジタルデータの生成
２．フラグメント化されたデジタルデータの保存
３．フラグメント化されたデジタルデータの更新
４．フラグメント化されたデジタルデータの削除
５．フラグメント化されたデジタルデータに対するインデックスの生成
６．フラグメント化されたデジタルデータに対するインデックスの保存
７．フラグメント化されたデジタルデータに対するインデックスの更新
８．フラグメント化されたデジタルデータに対するインデックスの削除
９．デジタルデータの検索
１０．検索されたデジタルデータの出力
【００９８】
前記機能に関する詳細な説明は図８Ａ，Ｂ，Ｃに説明されている。
【００９９】
図８Ａ，Ｂ，Ｃは、フラグメント化されたデジタルデータの管理方法を示す。
【０１００】
１．フラグメント化されたデジタルデータの生成
デジタルデータは所定のフラグメント政策によってフラグメント化される。データ提供部５１０は所定のフラグメント政策によってデジタルデータをフラグメント化させる（Ｓ１１０）。他の実施例として、データ提供部５１０は他のデジタル装置から受信されたフラグメントを提供するか、受信されたデジタル放送ストリームのうちフラグメント化されたデータを選別して提供するか、受信された放送ストリームのうちフラグメント化されたデータを選別して提供することもできる。
【０１０１】
２．フラグメント化されたデジタルデータの保存
データ提供部５１０が提供したフラグメントはフラグメント管理部５２０により分析される（Ｓ１２０）。フラグメント管理部５２０はフラグメント分析後、表１のフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄ、フラグメントタイプｆｒａｇｍｅｎｔ＿ｔｙｐｅ、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎ、フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔのような情報を抽出する。抽出された情報はデータ処理部５４０に伝達されて保存部５７０のフラグメント部４００に保存される。
【０１０２】
一方、重複保存を防止するために、データ提供部５１０が提供したフラグメントと既に保存されたフラグメントとのフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄを比較する段階（Ｓ１３０）をさらに含みうる。
【０１０３】
この場合、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄが同じフラグメントは捨てられ（Ｓ１５０）、他のフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄを有するフラグメントのみ保存される（Ｓ１７０）。さらに他の実施例で、フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄの比較以後、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎをさらに比較することもできる（Ｓ１４０）。フラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄが同一であり、フラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎがより高いフラグメントが提供されたならば、これは該当フラグメントの更新を意味し、下記の３過程が行われる。
【０１０４】
一方、保存部５７０のフラグメント部４００に新たなフラグメントが追加されるか、既存のフラグメントが更新される場合、該当フラグメントに対するインデックスも追加されるか、更新される必要がある。インデックスの追加または更新に関する過程は下記５〜７過程を参照すれば良い。
【０１０５】
３．フラグメント化されたデジタルデータの更新
保存部５７０に既に保存されたフラグメントと所定情報が同一であるフラグメントがデータ提供部５１０から提供される場合、データ処理部５４０は該当フラグメントを更新する（Ｓ１６０）。同一性判断のためには多様なフィールドが使われ、前述したようにフラグメントバージョンｆｒａｇｍｅｎｔ＿ｖｅｒｓｉｏｎを同一性判断に使用して該当フラグメントが更新されたことを判断することもできる。
【０１０６】
４．フラグメント化されたデジタルデータの削除
保存部５７０に保存されたデジタルデータはフラグメント単位で削除可能である。関係テーブルで保存されたフラグメントはアプリケーション５６０を通じたユーザの要請、または所定のアルゴリズムにより自動的に削除されうる。この場合、該当フラグメントに関する情報は関係テーブルより削除される。
【０１０７】
５．フラグメント化されたデジタルデータに対するインデックスの生成
所定のデジタルデータを検索するために保存部５７０に保存されたあらゆるフラグメントの内容を説明するより、フラグメントに対するインデックスを提供し、このインデックスを検索することがさらに効率的であり得る。
【０１０８】
本発明の望ましい実施例では、所定のフラグメントタイプに対してそのタイプに属する任意のノードをキーとして選定し、該当ノードの値をキー値として作られる。インデックス管理部５３０はフラグメントを分析し、図５のようなインデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００、インデックスキーフィールド部（ＩｎｄｅｘＫｅｙｆｉｅｌｄ）２００、インデックス部（Ｉｎｄｅｘ）３００ａ、３００ｂを生成することによってインデックスを提供する（Ｓ２１０）。
【０１０９】
一方、インデックス提供部５３０はデジタル装置の性能及び機能によって他のデジタル装置より受信されたインデックスを提供することもできる。
【０１１０】
６．フラグメント化されたデジタルデータに対するインデックスの保存
インデックス提供部５３０が提供したインデックスはデータ処理部５４０に伝達されて保存部５７０に保存される。フラグメントの管理方法と同様に、インデックスを分析し（Ｓ２２０）、重複如何を判断し（Ｓ２３０）、更新可否を判断し（Ｓ２４０）、これによりインデックスを捨てるか（Ｓ２５０）、インデックスを更新するか（Ｓ２６０）、インデックスを保存しうる（Ｓ２７０）。
【０１１１】
７．フラグメント化されたデジタルデータに対するインデックスの更新
保存部５７０に既に保存されたインデックスと所定情報が同一であるインデックスとがデータ提供部５１０から提供される場合、データ処理部５４０は該当インデックスを更新する（Ｓ２６０）。同一性判断のためには多様なフィールドが使われ、例えば、インデックスバージョンｉｎｄｅｘ＿ｖｅｒｓｉｏｎを同一性判断に使用して該当フラグメントが更新されたことを判断できる（Ｓ２４０）。
【０１１２】
一方、インデクシングされるフラグメントが更新される場合、インデックスも共に更新されることが望ましい。この際、フラグメントの更新如何はデータ処理部５４０からインデックス管理部５３０に伝達されうる。
【０１１３】
８．フラグメント化されたデジタルデータに対するインデックスの削除
保存部５７０に保存されたインデックスは削除可能である。インデックス辞書部（ＩｎｄｅｘＤｉｃｔｉｏｎａｒｙ）１００、インデックスキーフィールド部（ＩｎｄｅｘＫｅｙｆｉｅｌｄ）２００及びインデックス部（Ｉｎｄｅｘ）３００ａ、３００ｂはアプリケーション５６０を通じたユーザの要請、または所定のアルゴリズムにより自動的に削除されうる。
【０１１４】
９．所定デジタルデータの検索
本発明でデジタルデータの検索はフラグメント単位よりなる。
【０１１５】
簡単な検索方法として、検索しようとするデジタルデータが含まれたフラグメントタイプだけを指定し、指定されたフラグメントタイプをフラグメント部４００で検索し、検索されたフラグメントを抽出する方法が可能である。
【０１１６】
一方、より効率的な検索方法としてインデックスを活用する方法が可能である。以下ではインデックスを活用して検索する方法を基準として説明する。
【０１１７】
デジタルデータに対する検索を試みる時、まず検索対象はフラグメントタイプにより指定され、検索条件は該当フラグメントタイプ内での特定ノード（キー）値及び特定ノード値に対する比較演算子により指定される（Ｓ３１０）。
【０１１８】
例えば、図６に示されたように‘ジャンル’が‘ニュース’に対するデジタルデータを検索しようとする時、まずインデックスを通じて‘ジャンル’が‘ニュース’のデジタルデータを含むフラグメントを検索する。この際、‘ジャンル’というキーは‘ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ’というフラグメントタイプを検索対象とし、‘ＰｒｏｇｒａｍＩｎｆｏｒｍａｔｉｏｎ’というフラグメントタイプに属するフラグメントのうちジャンルが‘ニュース’である値を有するフラグメントをフィルタリングできる。ジャンルが‘ニュース’である値を有するフラグメントのフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄをインデックスで確認し、このフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄを有するフラグメントをフラグメント部４００から持ってくる。以後、該当フラグメントを応用プログラムが要求する形態にパージングする。前述した検索過程は次の４つの段階に区分されうる。
【０１１９】
１）  インデックスの選択：インデックス辞書部１００とインデックスキーフィールド部２００とを参照してユーザ質疑を処理するインデックス部３００を選択する（Ｓ３２０）。
２）  フラグメントＩＤフィルタリング：該当インデックス部３００を参照して質疑条件に合うフラグメントのフラグメント識別子ｆｒａｇｍｅｎｔ＿ｉｄを抽出する（Ｓ３３０）。
３）  フラグメント内容検索：フラグメント部４００を参照して該当フラグメント識別子を有するフラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔを抽出する（Ｓ３４０）。
４）  検索結果出力：フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔを出力する（Ｓ３５０）。もし、フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔがテキスト形態のフラグメントである場合、別途のパージング過程を通じてパージングしてから出力する。
【０１２０】
１０．検索されたデジタルデータの出力
フラグメントコンテンツｆｒａｇｍｅｎｔ＿ｃｏｎｔｅｎｔを所定アプリケーションに伝達し、そのアプリケーションは該当内容を活用して所定のデータ処理を行う。
【０１２１】
以下では本発明のデジタルデータ管理方法が適用されたデジタル放送受信装置を本発明の望ましい実施例として説明する。
【０１２２】
デジタル放送受信装置は、放送信号以外に、ＸＭＬのようなマークアップランゲージで構成されたメタデータを受信し、これをユーザにディスプレイする。メタデータはプログラムタイトルと概要のようなコンテンツに対する説明的なデータを意味し、“データに関するデータ”に定義される。
【０１２３】
このようなメタデータは、例えば、図９に示されたＥＰＧアプリケーションのグリッドガイド画面を通じてユーザにディスプレイされる。したがって、デジタル放送受信装置は、受信される放送プログラムに対する多様な検索機能を提供するために、このメタデータを効率よく管理する必要がある。
【０１２４】
受信側４０のデジタル放送受信装置は、図１０に示されたように送信側２０からフラグメント化されたメタデータを転送ネットワーク３０を通じて受信する。場合によって、デジタル放送受信装置はフラグメント化されたメタデータだけでなく、これらに対してインデックスも受信する。
【０１２５】
本発明はデジタル放送分野で特に有用に使われうる。
【０１２６】
デジタル放送環境ではオーディオとビデオとで構成された放送内容物だけでなく、それを説明するメタデータも共に、放送ネットワークを通じて転送される。このようなメタデータは主に受信装置で放送内容物を検索するか、ブラウジングする目的として使われる。放送内容物を記述するこのようなメタデータの標準としてＸＭＬが益益広く採択されている。ＴＶ−ＡｎｙｔｉｍｅのＭｅｔａｄａｔａ規格あるいはＭＰＥＧ−７のＭｕｌｔｉｍｅｄｉａ  ｄｅｓｃｒｉｐｔｉｏｎ  ｓｃｈｅｍｅｓが代表的な例である。放送プログラムに関するメタデータは、プログラム、プログラムグループ、プログラムレビュー、クレジット、プログラムスケジュール、放送局などの多様な種類の情報を含みうる。
【０１２７】
デジタル放送に関するメタデータ文書は前述したような多様な情報を含む多数の部分で構成されており、一定期間（通常２週間内外）の放送プログラムに対するかなり多くの量の情報を含んでいるために、制限された帯域幅のネットワークを通じて転送するためにはメタデータをフラグメント化することが望ましい。
【０１２８】
全体ＸＭＬ文書が転送のために小さい単位で分解される時の利点は以下の２種類に要約しうる。第１に、転送エラーの頻繁なネットワーク上で該当文書を１つの大きなパケットよりは多量の小さな単位のパケットで転送することがさらに安全であるという点である。第２に、文書のアップデートが文書の一部に対して行なわれうるという長所がある。全体文書が一度に転送されるならば、文書の何れか一部が変わる度に全体文書が再転送されねばならない。一方、フラグメントに基盤した転送では単に変わったフラグメントだけを再転送すれば良い。
【０１２９】
放送環境ではフラグメントをカルーゼル（ｃａｒｏｕｓｅｌ）ネットワークを通じて反復的に転送することによって、受信装置が如何なる瞬間に作動しても必要な放送情報を受信可能にすることが望ましい。
【０１３０】
図１０においてメタデータはフラグメント化され、各フラグメントが識別子、バージョン情報と共にカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）されて転送される。
【０１３１】
一方、受信装置ではこのようなフラグメント化されたデジタルデータを処理しなければならず、これにより下記のような要求事項を支援することが望ましい。
【０１３２】
１）  本来のＸＭＬ文書を効率よく再構成せねばならない。
２）  ＸＭＬ文書の部分単位で動的なアップデートとバージョン技法とを提供しなければならない。
３）  ＸＭＬ文書の部分単位に対する効率的な検索が可能であるべきである。
【０１３３】
本発明に係るマークアップランゲージ基盤のデジタル管理方法は前述したような要求事項を全て満足させうるので、デジタル放送送信装置及びデジタル放送受信装置に何れも適合した解決策になりうる。
【０１３４】
図１１は、本発明の望ましい実施例に係るデジタル放送受信装置７００のブロック図を示した図面である。
【０１３５】
このデジタル放送受信装置７００は放送受信のために、図６の一般的なデジタル装置とは違って、逆多重化部７１０及びメタデータブラウザー７５０をさらに含む。逆多重化部７１０は転送レイヤ６００でデジタル放送ストリームを受信し、オーディオ信号及びビデオ信号は該当処理モジュールに伝達し、本発明と関連したフラグメント化されたメタデータまたはメタデータに対するインデックスは各々フラグメント管理部７２０及びインデックス管理部７３０に伝達する役割をする。メタデータブラウザー７５０は図７のデータ処理部５４０の機能のうちパージング機能だけを専門に担当するモジュールであって本図面では別途表示した。
【０１３６】
以上、添付図を参照して本発明の実施例を説明したが、 本発明が属する技術分野における当業者ならば、本発明がその技術的思想や必須特徴を変更せずとも他の具体的な形に実施されうるということが理解できるであろう。したがって、前述した実施例は全ての面で例示的なものであって、限定的なものではないと理解せねばならない。
【０１３７】
この実施例に係るデジタル放送受信装置７００は、図７で説明したデジタル装置と基本的に同じ構成であり、但し、フラグメントを自ら生成するものではなく、転送レイヤ６００から受信するという点が異なるだけである。したがって、その動作も図７で説明したデジタル装置の動作とほぼ同一なので、その詳細な説明は省略する。
【産業上の利用可能性】
【０１３８】
本発明は、コンピュータ、プリンタ、スキャナー、ページャ、デジタルカメラ、ＦＡＸ、デジタル複写機、個人用デジタル端末機（ＰＤＡ）、携帯電話、デジタル家電機器、デジタル電話、デジタルプロジェクタ、ホームサーバ、デジタルビデオレコーダ、デジタルＴＶ放送受信機、デジタル衛星放送受信機、及びセットトップボックスなどのデジタル装置に好適に適用されうる。
【図面の簡単な説明】
【０１３９】
【図１】マークアップランゲージ基盤の一般的なデータを示す例示図である。
【図２】マークアップランゲージ基盤のデータの一般的な構造を示す図面である。
【図３】従来のノードナンバリング方法によるマークアップランゲージ基盤のデータ保存方法を示す図面である。
【図４】マークアップランゲージ基盤のデータフラグメント化を説明する概念図である。
【図５】本発明の一実施例に係るマークアップランゲージ基盤のデータを管理する概念を示す図面である。
【図６】図５のデータ管理概念を用いて図１のデジタルデータを管理する実施例を示す図面である。
【図７】本発明の一実施例に係るマークアップランゲージ基盤のデータを管理するデジタル装置のブロック図である。
【図８Ａ】本発明の一実施例に係るデータ管理方法及び検索方法を示す図面である。
【図８Ｂ】本発明の一実施例に係るデータ管理方法及び検索方法を示す図面である。
【図８Ｃ】本発明の一実施例に係るデータ管理方法及び検索方法を示す図面である。
【図９】一般的なＥＰＧアプリケーションでのグリッドガイド画面である。
【図１０】フラグメント化されたメタデータの転送を示す概念図である。
【図１１】本発明の他の実施例に係るマークアップランゲージ基盤のメタデータを処理するデジタル放送受信装置のブロック図である。
【符号の説明】
【０１４０】
１００        インデックス辞書部
２００        インデックスキーフィールド部
３００ａ、３００ｂ        インデックス部
４００        フラグメント部
【図１】
2005174332.tif 000004
【図２】
2005174332.tif 000005
【図３】
2005174332.tif 000006
【図４】
2005174332.tif 000007
【図５】
2005174332.tif 000008
【図６】
2005174332.tif 000009
【図７】
2005174332.tif 000010
【図８Ａ】
2005174332.tif 000011
【図８Ｂ】
2005174332.tif 000012
【図８Ｃ】
2005174332.tif 000013
【図９】
2005174332.tif 000014
【図１０】
2005174332.tif 000015
【図１１】
2005174332.tif 000016