-
Technisches Gebiet
-
Die
vorliegende Erfindung bezieht sich auf eine Indexstruktur von Metadaten,
die für
das Suchen nach Informationen in Inhalten bereitgestellt wird, und
auf ein Verfahren für
das Bereitstellen von Indizes der Metadaten und auf eine Vorrichtung
für das
Suchen nach Metadaten unter der Verwendung der Indexstruktur der Metadaten.
Insbesondere bezieht sich die vorliegende Erfindung auf eine Indexstruktur
von Metadaten, die Informationen über einen Schlüssel enthalten,
von denen mindestens ein Teil so kodiert ist, dass es ermöglicht wird,
dass Informationen über
Inhalte wirksamer gesucht werden, sobald die XML-Metadaten für die digitalen Inhalte, die
in dem TV-Anytime-Forum (nachstehend als "TVA" bezeichnet)
(nachstehend als TVA-Metadaten" bezeichnet)
definiert sind, in einer unabhängigen
Einheit in Fragmente geteilt werden und auf einer Fragmentbasis übertragen
werden, auf ein Verfahren zur Bereitstellung von Indizes für Metadaten
sowie auf ein Verfahren und eine Vorrichtung für das Suchen der Metadaten
unter der Verwendung der Indizes von Metadaten.
-
Hintergrund der Erfindung
-
Das
TV-Anytime-Forum ist eine private Standardisierungsorganisation,
die im September 1999 mit dem Zweck der Entwicklung von Standards
für die
Bereitstellung audiovisueller Dienste in einer anwenderfreundlichen
Umgebung, wie einem personenbezogenen Digitalrekorder (PDR), der
einen personenbezogenen Massenspeicher aufweist, gegründet wurde.
Es ist insbesondere das Ziel der Dienste, allen Anwendern zu ermöglichen,
basierend auf dem personenbezogenen Speicher, verschiedene Typen
von Programmen (wie herkömmliche
Rundfunkdienste, interaktive Online-Dienste und Ähnliches) zu einer gewünschten
Zeit und in einer gewünschten
Weise zu sehen und zu hören.
-
Das
TV-Anytime-Forum hat Arbeitsgruppen für Geschäftsmodelle, System-/Übertragungs-Schnittsteilen-/Inhalte-Bezugnahme,
Beschreibungen, Metadaten, Rechtsmanagement und Schutz und Ähnliches
geschaffen, um eine Standardisierung aufzubauen. Mit Bezug auf die
Metadaten, die in der vorliegenden Erfindung betroffen sind, wurde
die „1st Draft of Metadata Specification SP003v1.3" („1. Ausarbeitung
einer Metadatenspezifikation SP003v1.3") bis zum Juni 2002 veröffentlicht.
-
Eine
Konfiguration des PDR wird mit Bezug auf 1 kurz beschrieben.
Der PDR 100 empfängt
Video-/Audio-Signale und Metadaten über eine Vielfalt von Netzwerken,
wie Raumwellen, Satellitenwellen, Intemetnetzwerke und Ähnliches
von einem Anbieter 200 für die Bereitstellung von Video-/Audio-Signalen,
sammelt, wenn notwendig, Seh- und Hörmuster und persönliche Geschmäcker der
Anwender und überträgt sie an den
Anbieter 200 für
die Bereitstellung von Video-/Audio-Signalen. Der PDR 100 umfasst
einen Massenspeicher, um darin die empfangenen Video-/Audio-Signale
und Metadaten zu speichern. Der PDR 100 umfasst ferner
Software für
die Speicherung und Wiedergabe der Video-/Audio-Signale und eine
elektronische Programmführer-Anwendung
(EPG), für
das Abfragen und Anzeigen von Metadaten und Video-/Audio-Signalen. Der
Anwender legt durch einen Rasterführungsbildschirm der EPG-Anwendung,
die in 2 gezeigt wird, die Metadaten für die Video-/Audio-Daten fest, d. h.,
die Titel der Programme, Programmwiedergabezeiten und Ähnliches,
wählt ein
gewünschtes
Programm aus und empfängt
es über
das Netzwerk in Echtzeit oder gibt die Video-/Audio-Daten wieder,
die zuvor in dem Massenspeichergerät gespeichert wurden.
-
Die
Metadaten beziehen sich auf Daten, die Inhalte wie Titel und Zusammenfassungen
von Programmen beschreiben, und werden als Daten über Daten" definiert. In den
TVA-Metadatenspezifikationen
des TV-Anytime-Forums wird deren Struktur durch Verwendung der XML-Schemasprache
(siehe XML 1.0 von W3C), der Standard durch das W3C (ein Konsortium
zur Förderung
der Standards für
das XML), definiert, und die Semantik und die Eigenschaften der
jeweiligen Metadatenelemente werden ebenfalls definiert. Die TVA-Metadaten, die sich
auf Rundfunkinhalte beziehen, werden mit einem XML-Dokument konfiguriert,
das einen Wurzelknoten „TVAMAIN
(300)",
wie in 3 gezeigt, aufweist Die TVA-Metadaten, die sich auf Programme beziehen,
werden gemäß dem Knoten
der „Programmbeschreibung" zum Beispiel mit
Knoten wie etwa einer Programlnformation-Tabelle, einer GroupInformation-Tabelle,
einer ProgramLocation-Tabelle, einer Serviceinformation-Tabelle
und Ähnlichem
konfiguriert.
-
In
dem TV-Anytime-Forum werden die TVA-Metadaten als eine unabhängige Einheit
auf einer Fragmentbasis übertragen,
um eine große
Menge von TVA-Metadaten in einem Stream-Format zu übertragen.
Das Fragment-Konzept wird mit Bezug auf 4 kurz beschrieben.
Die Fragmente werden erzielt, indem die TVA-Metadaten, die mit den
in 3 gezeigten XML-Dokumenten konfiguriert sind,
in vorbestimmte Baumstrukturen aufgeteilt werden. Wo die gesamten
TVA-Metadaten zum Beispiel in eine Baumstruktur (Fragment TVAMain)
aufgeteilt sind, die einen oberen Knoten von „TVAMain" und einen vorbestimmten Nachfolgerknoten unter
diesem oberen Knoten beinhaltet, eine Baumstruktur (Fragment-Programinformation),
die einen oberen Knoten der Programminformationstabelle und Nachfolgerknoten
unter diesem oberen Knoten beinhaltet, eine Baumstruktur (Fragment-BroadcastEvent),
die einen oberen Knoten der BroadcastEvent-Informationen und Nachfolgerknoten
unter diesem oberen Knoten beinhaltet, wird jede der aufgeteilten
Baumstrukturen ein Fragment. Die Fragmente können unabhängig von den anderen Fragmenten übertragen
werden, und auf die Fragmente kann individuell zugegriffen werden.
-
Für einen
individuellen Zugriff auf die Fragmente ist es notwendig, einen
Knoten zu kennen, auf den durch ein übertragenes TVA-Metadatenfragment
hingewiesen wird, d. h., ein Knoten, der in der gesamten Metadaten-Baumstruktur
dem oberen Knoten des TVA-Metadatenfragments
entspricht, und um die jeweiligen Pfade in dem TVA-Metadatenfragment
von Schlüsseln
zu beschreiben, die in dem übertragenen
TVA-Metadatenfragment
enthalten sind. Zu diesem Zweck wird XPath verwendet, der eine Syntax
für die
Beschreibung eines Pfades zu einem oder mehreren Knoten in einem
XML-Dokument ist,
das durch W3C definiert wird. Der Begriff ,Schlüssel' bezieht sich auf ein bestimmtes Feld
der Metadaten, die zur Indizierung verwendet werden, und bedeutet
außerdem
Nachfolgerknoten eines Knotens, auf den durch ein Fragment hingewiesen
wird. Felder (für
Suchbedingungen), die von dem Anwender eingegeben werden, wie etwa „Dienst-ID" und „Veröffentlichungszeit", entsprechen den
Schlüsseln.
-
Um
eine wirksame Suche nach und einen Zugriff auf die Fragmente bereitzustellen,
ist eine Indexstruktur für
die Schlüssel,
die in den Metadatenfragmenten beinhaltet sind, zusätzlich erforderlich,
und Informationen über
die Indexstruktur, d. h., Indexinformationen werden außerdem unabhängig von
den Metadatenfragmenten übertragen.
-
Wenn
ein Anwender wünscht,
Informationen über
ein Programm abzufragen, die eine vorbestimmte Veröffentlichungszeit-Bedingung
erfüllen,
werden in der Umgebung, die von dem TV-Anytime-Forum bereitgestellt
wird, die Indexinformationen, die dazu unabhängig von den Fragmenten übertragen
werden, genutzt, um die Position (Identifikator) eines Metadatenfragments
zu bestimmen, das eine gewünschte
Veröffentlichungszeit-Bedingung
erfüllt,
und ein Zugang zu dem relevanten Metadatenfragment wird dann basierend
auf der Position (Identifikator) hergestellt, um so die Metadaten
zu extrahieren, welche die Veröffentlichungszeit-Bedingung
erfüllen.
-
Die
TV-Anytime-Spezifikation TV145, J. P. Evain, „1st Draft
of Metadata Specification SP003v1.3" („1. Ausarbeitung
einer Metadatenspezifikation SP003v1.3"), 17. Meeting des TV-Anytime-Forums,
Montreal, Kanada, Juni 2002, nachstehend als „Schlüsselindex-Technikempfehlung" bezeichnet, schlägt einen Schlüsselindex-Datenstromstruktur
für einen
Metadaten-Fragmentindex vor.
-
Der
Begriff eines Containers, der durch das TV-Anytime-Forum definiert
wird, wird vor der Beschreibung der Indexstruktur beschrieben.
-
Das
TV-Anytime-Forum definiert einen Container als einen Speicher auf
höchster
Ebene, an den alle Daten, welche die zuvor erwähnten Indexinformationen und
die Metadatenfragmente abdecken, übertragen werden, was als ein
Typ von Übertragung
auf höchster
Ebene bezeichnet wird. Wir beschreiben den Container kurz; der Container
umfasst eine Vielzahl von Abschnitten, die jeweils darin die Indexinformationen
oder die Metadatenfragmente speichern. Der Container kann, gemäß den Daten,
die dadurch aufgenommen werden, in einen Index-Container und einen
Daten-Container klassifiziert werden: der Index-Container nimmt
Index-Informationsabschnitte auf, wie etwa einen Schlüssel-Indexlisten(key_index_list)-Abschnitt, einen
Schlüssel-Index(key_index)-Abschnitt,
einen Teil-Schlüssel-Index(subkey_index)-Abschnitt,
einen String-Datenarchiv(string_repository)-Abschnitt und einen
Fragmentdaten-Datenarchiv(fragment_data_repository)-Abschnitt, wobei
ein Daten-Container
Metadaten-Fragmentabschnitte aufnimmt, wie etwa einen Elemente-Tabellen(elements_table)-Abschnitt,
einen String-Datenarchiv(string_repository)-Abschnitt und einen
Fragmentdaten-Datenarchiv(fragment_data_repository)-Abschnitt. Die
obige Klassifizierung wird basierend auf den Inhalten der Informationen
vorgenommen, die in den Container enthalten sind. Sowohl der Index-Container
als auch der Daten-Container sind bezüglich der Konfiguration identisch.
-
Bezüglich des
Containers, der, wie in 5 dargestellt, durch das TV-Anytime-Forum
definiert wird, umfasst der Container einen Container-Identifikator
(container_id), ein (nicht gezeigtes) Datenfeld und eine große Anzahl
von Abschnitten. In jedem Abschnitt werden die Inhalte, die in dem
,section_body' gespeichert sind,
gemäß einem
Codierwert in dem ,section_id' identifiziert.
Zum Beispiel wird ein Abschnitt 10, dessen Codierwert in
,section_id' ,0 × 0004' ist, als ein Schlüssel-Index(key_index)-Abschnitt
identifiziert, ein Abschnitt 20, dessen Codierwert in ,section_id' ,0 × 0005' ist, wird als ein
Schlüssel-Index(key_index)-Abschnitt identifiziert,
ein Abschnitt 30, dessen Codierwert in ,section_id' ,0 × 0006' ist, wird als Teil-Schlüssel-Index(sub_key_index)-Abschnitt
identifiziert, ein Abschnitt 40, dessen Codierwert in ,section_id' ,0 × 0001' ist, wird als ein
Elemente-Tabellen(elements_table)-Abschnitt identifiziert, und ein Abschnitt 50,
dessen Codierwert in ,section_id' ,0 × 0003' ist, wird als Fragmentdaten-Datenarchiv(fragment_data_repository)-Abschnitt identifiziert.
-
Die
TVA-Metadatenfragmente werden in dem Fragmentdaten-Datenarchiv(fragment_data_repository)-Abschnitt 50 des
Daten-Containers gespeichert und dann übertragen. Die Identifikator-Informationen
(handle_value) für
die TVA-Metadatenfragmente
in dem Daten-Container sind in dem Elemente-Tabellen(elements_table)-Abschnitt 40 des
Daten-Containers beinhaltet.
-
Schließlich wird
das TVA-Metadatenfragment durch die Container-Identifikator-Informationen (container_id)
und die Metadatenfragment-Identifikator-Informationen (handle_value)
des Containers, der die TVA-Metadatenfragmente beinhaltet, eindeutig
identifiziert.
-
Die
oben beschriebene Schlüsselindex-Technikempfehlung
schlägt
die Schlüsselindex-Struktur für die Indizierung
der TVA-Metadatenfragmente vor, die in dem zuvor erwähnten Daten-Container
gespeichert werden, d. h., eine Struktur, die aus dem Schlüssel-Indexlisten(key_index_list)-Abschnitt 10,
dem Schlüssel-Index(key_index)-Abschnitt 20 und
dem Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30 besteht.
Da die Syntax der Struktur in der oben beschriebenen Schlüsselindex-Technikempfehlung
ausführlich
beschrieben wird, wird deren ausführliche Beschreibung weggelassen.
Nachstehend wird die Struktur mit Bezug auf 6 beschrieben,
welche die Struktur durch Segmente der Indexinformationen darstellt.
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt 10,
der in der Schlüsselindex-Struktur
definiert wird, stellt eine Liste aller übertragenen Schlüssel bereit.
Die Liste beinhaltet Schlüsselinformationen,
die jeden Schlüssel
definieren, sowie Identifizierungsinformationen über den Schlüssel-Index(key_index)-Abschnitt 20, die
später
beschrieben werden. Die Schlüsselinformationen
umfassen 1. Positionsinformationen des Metadatenfragments, das sich
auf den Schlüssel
bezieht, und 2. Positionsinformationen des Schlüssels innerhalb des Metadatenfragments.
Die Positionsinformationen des Metadatenfragments werden in XPath (fragment_xpath_ptr)
in dem TVA ausgedrückt.
Die Positionsinformationen des Schlüssels werden in XPath (key_xpath_ptr)
für den
jeweiligen Pfad innerhalb des relevanten Fragments der Knoten, die
als der Schlüssel in
dem TVA verwendet werden, ausgedrückt.
-
Der
XPath der Metadatenfragmente ist ein Pfad zu dem Wurzelknoten des
TVA-Metadaten-XML-Dokuments,
d. h., ein absoluter Pfad, und der XPath der Knoten, die als die
Schlüssel
verwendet werden, d. h., der XPath der Schlüssel, stellt einen relativen
Pfad der Schlüssel
für das
relevante Metadatenfragment dar. Der XPath für das Metadatenfragment und
der XPath für
den Schlüssel
werden jeweils in einem ,fragment_xpath_ptr'-Segment 11 und einem ,key_xpath_ptr'-Segment 12 gespeichert.
-
Ferner
beinhaltet der Schlüssel-Indexlisten(key_index_list)-Abschnitt 10 die
Identifizierungsinformationen über
den Schlüssel-Index(key_index)-Abschnitt 20 jedes
Schlüssels,
die später
beschrieben werden (d. h., die Container-Identifikator-Informationen
(container_id) des Containers, der darin den Schlüssel-Index(key_index)-Abschnitt 20 und
die Schlüsselindex-Identifikator-Informationen
speichert). Die Container-Identifikator-Informationen und die Schlüsselindex-Identifikator-Informationen
werden jeweils in einem ,index_container'-Segment
des Schlüssel-Indexlisten(key_index_list)-Abschnitts 10 und
in einem ,key_index_identifier'-Segment
gespeichert und dann übertragen.
-
Der
Schlüssel-Index(key_index)-Abschnitt 20,
der in der Schlüsselindex-Struktur
definiert wird, stellt eine Liste von Informationen bereit, welche
die Bereiche der Werte des Schlüssels
darstellen, die in dem jeweiligen Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30 beinhaltet
sind, d. h., der höchste
Wert des Schlüssels
unter den Werten des Schlüssels
in nerhalb des jeweiligen Bereichs (nachstehend als ,repräsentativer Schlüsselwert' bezeichnet), sowie
Identifizierungsinformationen über
den Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30,
der für
jeden repräsentativen
Schlüsselwert
(d.h., die Container-Identifikator-Informationen (container_id) des Containers,
der darin den Teil-Schlüssel-Index(subkey_index)-Abschnitt und
die Teil-Schlüssel-Index-Identifikator-Informationen
speichert) relevant ist.
-
Dementsprechend
beinhaltet der Schlüssel-Index(key_index)-Abschnitt 20 Folgendes:
ein ,key_index_identifier'-Segment,
um die Schlüssel-Index-Identifikator-Informationen
dann zu speichern, die in dem Schlüssel-Indexlisten(key_index_list)-Abschnitt 10 definiert
werden; ,high_key_value'-Segmente 13,
um die repräsentativen
Schlüsselwerte
der betreffenden Bereiche von Werten des Schlüssels dann zu speichern, der
in dem Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30 beinhaltet
ist; und ,sub_Index_container'-Segmente
und ,sub_index_identifier-Segmente für die Identifizierungsinformationen über den
Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30 (d.h.,
für die
Container-Identifikator-Informationen
(container_id) des Containers, in dem der Teil-Schlüssel-Index(subkey_index)-Abschnitt 30 gespeichert
ist, und für
betreffenden die Teil-Schlüssel-Index-Identifikator-Informationen).
Der Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30,
der in der Schlüssel-Indexstruktur
definiert wird, stellt eine Liste der Werte des Schlüssels bereit.
Die Liste beinhaltet ferner Identifizierungsinformationen über die
Metadatenfragmente, die den Werten des Schlüssels entsprechen (d.h., die
Container-Identifikator-Informationen (container_id) des Containers,
der die Metadatenfragmente und die Identifikator-Informationen (handle_value) der Metadatenfragment
speichert).
-
Dementsprechend
beinhaltet der Teil-Schlüssel-Index(sub_key_index)-Abschnitt 30 ein ,sub_key_index_identifier'-Segment, um die
Teil-Schlüssel-Index-Identifikator-Informationen
darin zu speichern, die in dem Schlüsselindex(key_index)-Abschnitt 20 definiert
werden, ,key_value'-Segmente 14,
um die betreffenden Bereiche von Werten des Schlüssels dann zu speichern, ,target_container'-Segmente, um die
betreffenden Container-Identifikator-Informationen (container_id) des Containers,
dann zu speichern, in dem die Metadatenfragmente gespeichert sind,
und ,target_handle'-Segmente,
um die betreffenden Fragmentdaten-Identifikator-Informationen (handle_value)
dann zu speichern. Die Schlüssel-Indexstruktur kann
durch Bezug auf 7 leichter verstanden werden,
welche die Indexinformationen darstellt.
-
7 zeigt
den Schlüssel-Indexlisten(key_index_list)-Abschnitt,
der die Schlüssel
beinhaltet, die für die
Dienst-ID, die Veröffentlichungszeit
und die Veröffentlichungsdauer
relevant sind. Der obere Knoten des Metadatenfragments, der die
Schlüssel
beinhaltet, die für
die Dienst-ID, die Veröffentlichungszeit
und die Veröffentlichungsdauer
relevant sind, ist, wie in 3 gezeigt
wird, ,BroadcastEvent' 310,
das durch einen schattierten Block identifiziert wird. Dementsprechend
wird das ,XPath/TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent' für das BroadcastEvent-Fragment
in dem ,Fagment_xpath_ptr'-Segment 11a gespeichert,
und die XPaths zu den Schlüsseln
der Dienst-ID, der Veröffentlichungszeit
und der Veröffentlichungsdauer
für das
,BroadcastEvent-Fragment, d. h. ,@Serviceld' (311a in 3),
,EventDescription/PublishedTime' (311b in 3)
und Event-Description/PublishedDuration
(311c in 3) werden in dem ,key_xpath_ptr'-Segment 12a gespeichert.
-
Die
Indexstruktur wird mit Bezug auf 7 verständlicher,
welche die Indexinformationen darstellt.
-
7 zeigt
den Schlüssel-Indexlisten(key_index_list)-Abschnitt,
der Schlüssel
für die
Dienst-ID, die Veröffentlichungszeit
und die Veröffentlichungsdauer
beinhaltet, worin ein oberer Knoten der Metadaten, die sich auf
die Dienst-ID, die Veröffentlichungszeit
und die Veröffentlichungsdauer
beziehen, ,BroadcastEvent' 310 ist,
was als ein schattierter Abschnitt in 3 angezeigt
wird. Dementsprechend wird der XPath für das ,BroadcastEvent'-Fragment/,TVAMain/ProgramDescription/ProgramLocation
Table/BroadcastEvent' in
dem ,fragment_xpath_ptr'-Segment
gespeichert, und die XPaths für
die Schlüssel
der Dienst-ID, der Veröffentlichungszeit
und der Veröffentlichungsdauer
für das
,BroadcastEvent'-Fragment, d. h. ,@Serviceld' (siehe 311a von 3),
,EventDescription/PublishedTime' (siehe 311b von 3)
und ,EventDescription/PublishedDuration' (siehe 311c von 3)
werden in dem ,key_xpath_ptr'-Segment
gespeichert.
-
7 zeigt
außerdem
den Schlüssel-Index(key_index)-Abschnitt 20 und
den Teil-Schlüssel-Index(sub-key_index)-Abschnitt 30 für die Dienst-ID
(der XPath des Schlüssels:
@ServiceID) des Schlüssel-Indexlisten(key_index_list)-Abschnitts 10.
-
Sobald
eine Suchbedingung für
das Suchen der Metadaten eingegeben wird, werden in einer solchen Indexstruktur
Positionsinformationen in einem Feld der Eingabebedingung der Metadaten
bestimmt, und die bestimmten Positionsinformationen werden mit den
Schlüsselinformationen
in der Schlüsselindexliste
verglichen, um so den Schlüssel
zu suchen, der die bestimmten Positionsinformationen innerhalb der
Schlüsselindexliste
aufweist, und ein Overhead wird verursacht, da ein Vergleich der
beiden XPaths notwendig ist Dasselbe Problem tritt auf sobald die
Schlüssel,
die relative Pfade von den Fragmenten unter den Schlüsselinformationen
anzeigen, bezüglich
der Positionsinformationen verglichen werden. Dieses Problem wird
insbesondere dann ernster, sobald Fragmente, die komplexer als die
Schlüssel
sind, bezüglich
der Positionsinformationen verglichen werden. Da der XPath des Fragments,
das die Positionsinformationen unter den Schlüsselinformationen darstellt,
einen Pfad von einem Wurzelknoten in dem XML-Dokument zu einem relevanten
Knoten beschreibt, sind die Übertragungskosten
ineffizient, und die Auswertungskosten des XPath in dem Endgerät sind hoch.
Der XPath des Rundfunkereignis-Fragments, das die Positionsinformationen
eines Programms unter den TV-Anytime-Fragmenten anzeigt, kann zum
Beispiel als /,TVAMain/ProgramDescription/ProgramLocation Table/BroadcastEvent' ausgedrückt werden.
Um einen Knoten in dem XML-Dokument darzustellen, kann der XPath
indessen in einer alternativen Weise ausgedrückt werden. In dem Fall eines
Rundfunkereignisses kann der XPath zusätzlich zu der zuvor erwähnten normalen
Darstellung alternativ ausgedrückt
werden, wie etwa ,TVAMain/BroadcastEvent' oder ,//BroadcastEvent' und so weiter. Hierbei
meint ,//' einen
Nachfolgerknoten in der Struktur des XML-Dokuments. Deshalb ist
ein Arbeitsablauf, um durch Verwendung des XPaths zu prüfen, ob
Fragmente dieselben sind, kein einfacher, der lediglich einfache
Zeichenfolgen miteinander abgleicht. Es wird insbesondere bei der
Analyse/dem Vergleich des relevanten Pfades ein Overhead verursacht, wenn
der XPath in einem verkürzten
Format ausgedrückt
wird.
-
Offenlegung der Erfindung
-
Nach
der vorliegenden Erfindung werden hier eine Vorrichtung und ein
Verfahren bereitgestellt, wie sie in den beiliegenden Ansprüchen dargelegt
werden. Bevorzugte Eigenschaften der Erfindung werden durch die Unteransprüche und
deren Beschreibung deutlich, die folgt Zusätzliche Gesichtspunkte und/oder
Vorteile der vorliegenden Erfindung werden zum Teil in der Beschreibung
dargelegt, die folgt, und werden zum Teil durch die Beschreibung
deutlich, oder sie können
in der Praxis der Erfindung erlernt werden.
-
Um
die obigen und/oder weitere Gesichtspunkte der vorliegenden Erfindung
zu erzielen, wird ein Verfahren des Suchens nach Metadaten bereitgestellt,
die in zwei Fragmente aufgeteilt sind, wobei ein Index verwendet
wird, der eine Liste von Schlüsseln
aufweist, die Feldern der Metadaten entsprechen, sowie Positionsinformationen
für das
Definieren der Schlüssel,
wobei das Verfahren umfasst das Suchen eines Schlüssels aus dem
Index der Metadaten, der einer Suchbedingung eines Felds der Metadaten
entspricht, worin mindestens ein Teil der Positionsinformationen,
die den Schlüssel
definieren, als ein vorbestimmter Code-Wert ausgedrückt wird,
und das Extrahieren eines Fragments der Metadaten unter Verwendung
des gesuchten Schlüssels.
-
Das
Suchen des Schlüssels
kann das Bestimmen der Positionsinformationen umfassen, die dem
Feld der Suchbedingung bezüglich
der Metadaten entsprechen, und das Suchen nach dem Schlüssel, der
den Positionsinformationen bezüglich
des Felds der Suchbedingung entspricht.
-
Das
Extrahieren des Fragments umfasst das Suchen nach einem Wert des
Schlüssels,
der die Suchbedingung unter den Werten des Schlüssels von dem Index erfüllt, sowie
Extrahierungs-Identifizierungsinformationen über das Fragment der Metadaten,
die dem Wert des Schlüssels
entsprechen.
-
In
Erwiderung auf eine Vielzahl von Werten des Schlüssels, welche die Suchbedingung
erfüllen,
kann das Extrahieren des Fragments das Extrahieren eines Fragments
der Metadaten umfassen, die den Werten des Schlüssels entsprechen, welche die
Suchbedingung erfüllen.
-
Das
Suchen des Wertes kann das Suchen eines repräsentativen Schlüsselwertes
unter repräsentativen
Schlüsselwerten
des Index, die den Bereichen der Werte des Schlüssels entsprechen, umfassen,
der die Suchbedingung erfüllt,
sowie das Suchen nach dem Wert unter einem Bereich von Werten, die
dem repräsentativen
Schlüsselwert
entsprechen.
-
Der
Index kann einen Schlüsselindex-Listenabschnitt
umfassen, der die Liste umfasst, einen Teil-Schlüsselindex-Abschnitt, der Bereiche
von Werten des Schlüssels
und Identifizierungsinformationen über diejenigen der Fragmente
der Metadaten umfasst, die den Werten des Schlüssels entsprechen, und einen Schlüsselindex-Abschnitt,
der repräsentative Schlüsselwerte
umfasst, welche die jeweiligen Bereiche von Werten des Schlüssels darstellen.
-
Die
Positionsinformationen können
Positionsinformationen eines Fragments der Metadaten umfassen, die
den Schlüssel
enthalten, sowie Positionsinformationen des Schlüssels innerhalb des Fragments.
-
Um
die obigen und/oder weitere Gesichtspunkte der vorliegenden Erfindung
zu erzielen, wird ein weiteres Verfahren des Suchens nach Metadaten
bereitgestellt, die in zwei Fragmente aufgeteilt sind, wobei das Verfahren
umfasst: das Zugreifen auf eine Liste, die eine Vielzahl von Kombinationen
von Positionsinformationen über
ein Fragment und Positionsinformationen umfasst, die wenigstens
einen Schlüssel
innerhalb des Fragmentes definieren, wobei eine der Positionsinformationen über das
Fragment und die Positionsinformationen, die den wenigstens einen
Schlüssel
definieren, als ein vorbestimmter Code ausgedrückt werden; und das Suchen
einer Kombination, die einer Eingabe-Suchbedingung wenigstens eines
Schlüssels
der Metadaten entspricht, aus der Liste.
-
Die
anderen Positionsinformationen können
als ein weitere vorbestimmter Code oder XPath ausgedrückt werden.
-
Das
Verfahren kann ferner das Extrahieren von einem oder mehreren Fragmenten
der Metadaten umfassen, die den Identifizierungsinformationen über die
Metadaten entsprechen, die durch die gewählte Kombination identifiziert
wird.
-
Um
die obigen und/oder weitere Gesichtspunkte der vorliegenden Erfindung
zu erzielen, wird eine Vorrichtung für das Suchen nach Metadaten
bereitgestellt, die in zwei Fragmente aufgeteilt sind, die einen
Index verwendet, der eine Liste von Schlüsseln aufweist, die Feldern
der Metadaten entsprechen, und Positionsinformationen, welche die
Schlüssel
definieren, wobei sie umfasst: eine Eingabeeinheit, die eine Suchbedingung empfängt, die
ein Feld der Metadaten als einen Suchparameter aufweist; und eine
Steuereinheit, die aus dem Index der Metadaten einen Schlüssel sucht,
welcher der Suchbedingung entspricht, wobei mindestens ein Teil der
Positionsinformationen, die den Schlüssel definieren, als ein vorbestimmter
Code-Wert ausgedruckt wird, und die ein Fragment der Metadaten und
Verwendung des gesuchten Schlüssels
extrahiert.
-
Der
vorbestimmte Code-Wert kann einen XPath als zusätzliche Information umfassen,
wobei das jeweilige Fragment/der jeweilige Schlüssel einem vom Anwender definierten
Typ entspricht.
-
Die
Positionsinformationen können
Positionsinformationen eines Fragments der Metadaten umfassen, das
den Schlüssel
enthält,
sowie Positionsinformationen des Schlüssels innerhalb des Fragments.
-
Die
Steuereinheit kann einen Wert des Schlüssels, der die Suchbedingung
erfüllt,
unter Werten des Schlüssels
aus dem Index suchen und Identifizierungsinformationen über das
Fragment der Metadaten extrahieren, die dem Wert des Schlüssels entsprechen.
-
Die
Vorrichtung kann ferner umfassen: eine Empfangseinheit, welche die
Metadaten empfängt;
eine Speichereinheit, welche die empfangenen Metadaten darin speichert;
und eine Ausgabeeinheit, die das Suchergebnis durch die Steuereinheit
ausgibt. In Erwiderung auf eine Vielzahl von Werten des Schlüssels, welche die
Suchbedingung erfüllen,
kann die Steuereinheit eines der Fragmente der Metadaten extrahieren,
die den Werten des Schlüssels
entsprechen, der die Suchbedingung erfüllt.
-
Die
Steuereinheit kann nach einem repräsentativen Schlüsselwert,
der die Suchbedingung erfüllt,
unter repräsentativen
Schlüsselwerten
des Index suchen, der Bereichen von Werten des Schlüssels entspricht, und
nach dem Wert in einem Bereich von Werten, der dem repräsentativen
Schlüsselwert
entspricht.
-
Um
die obigen und/oder weitere Gesichtspunkte der vorliegenden Erfindung
zu erzielen, wird eine weitere Vorrichtung für das Suchen nach Metadaten
bereitgestellt, die in zwei Fragmente aufgeteilt sind, die umfasst
eine Eingabeeinheit, die eine Suchbedingung wenigstens eines Schlüssels der
Metadaten empfängt;
und eine Steuereinheit, die aus einer Liste, die eine Vielzahl von
Kombinationen von Positionsinformationen über ein Fragment und Positionsinformationen
umfasst, die wenigstens einen Schlüssel innerhalb des Fragmentes definieren,
eine Kombination auswählt,
die der Suchbedingung entspricht, wobei eine der Positionsinformationen über das
Fragment und die Positionsinformationen, die wenigstens einen Schlüssel definieren,
als ein vorbestimmter Code ausgedruckt wird.
-
Die
anderen Positionsinformationen können
als ein anderer vorbestimmter Code oder XPath ausgedrückt werden.
Die Steuereinheit kann ein oder mehrere Fragmente der Metadaten
extrahieren, die Identifizierungsinformationen über die Metadaten entsprechen,
die durch die ausgewählte
Kombination identifiziert werden.
-
Um
die obigen und/oder weitere Gesichtspunkte der vorliegenden Erfindung
zu erzielen, wird für
jedes oben beschriebene Verfahren ein computerlesbares Medium bereitgestellt,
das computerausführbare
Befehle zum Durchführen
des Vorgangs/der Vorgänge
umfasst, die in dem Verfahren aufgezählt werden.
-
Kurze Beschreibung der Zeichnungen
-
Die
obigen und weitere Gesichtspunkte und Eigenschaften der vorliegenden
Erfindung werden deutlich durch die folgende Beschreibung der bevorzugten
Ausführungsformen,
die in Verbindung mit den beiliegenden Zeichnungen gegeben wird,
in denen Folgendes gilt:
-
1 ist
ein schematisches Diagramm, das ein Konzept eines allgemeinen PDR
darstellt;
-
2 zeigt
einen Rasterführungsbildschirm
in einer allgemeinen EPG Anwendung;
-
3 ist
ein Blockdiagramm, das eine Struktur allgemeiner Metadaten darstellt,
die durch das TV-Anytime-Forum definiert werden;
-
4 ist
ein schematisches Diagramm, das ein Konzept eines allgemeinen Fragments
darstellt, das durch das TV-Anytime-Forum definiert wird;
-
5 ist
ein schematisches Diagramm, das ein Konzept eines allgemeinen Containers
darstellt, der durch das TV-Anytime-Forum definiert wird;
-
6 ist
ein Blockdiagramm, das unter Verwendung des herkömmlichen Schlüsselschemas
eine Indexstruktur von Metadaten darstellt;
-
7 ist
ein Blockdiagramm, das unter Verwendung des herkömmlichen Schlüsselschemas
eine Indexstruktur von Metadaten und einen Suchvorgang darstellt;
-
8 ist
ein Blockdiagramm, das eine Indexstruktur von Metadaten nach einer
Ausführungsform
der vorliegenden Erfindung darstellt;
-
9 ist
ein schematisches Diagramm, das eine Indexstruktur von Metadaten
und einen Suchvorgang nach einer Ausführungsform der vorliegenden
Erfindung darstellt;
-
10 ist
ein Diagramm, das ein Verfahren der Bereitstellung von Indizes von
Metadaten nach einer Ausführungsform
der vorliegenden Erfindung darstellt;
-
11 ist
ein Diagramm, das ein Verfahren des Suchens nach den Metadaten nach
einer Ausführungsform
der vorliegenden Erfindung darstellt; und
-
12 ist
ein schematisches Diagramm, das eine Vorrichtung für das Suchen
nach den Metadaten nach einer Ausführungsform der vorliegenden
Erfindung darstellt.
-
Bester Modus für die Ausführung der
Erfindung
-
Nachstehend
werden eine Indexstruktur von Metadaten, die für das Suchen nach Informationen
in Inhalten bereitgestellt wird, und ein Verfahren zur Bereitstellung
von Indizes der Metadaten und eine Vorrichtung für das Suchen nach den Metadaten
unter Verwendung der Indexstruktur der Metadaten ausführlich mit
Bezug auf die beiliegenden Zeichnungen beschrieben.
-
Die
Ausführungsformen
werden in dieser Spezifikation aus Gründen der Beschreibung auf der
Basis von TVA-Metadaten beschrieben; das wird jedoch nicht als Begrenzung
des Anwendungsbereichs der Absicherung der vorliegenden Erfindung
interpretiert oder begriffen.
-
8 zeigt
eine Indexstruktur von Metadaten für das Suchen der Metadaten
nach einer Ausführungsform
der vorliegenden Erfindung, wobei die Indexstruktur Informationen
für das
Definieren eines Schlüssels beinhaltet,
um so TVA-Metadatenfragmente zu indizieren, die, wie oben beschrieben,
in dem Daten-Container gespeichert sind. Nachstehend werden ein
Schlüssel-Indexlisten(key_indexjist)-Abschnitt 110,
ein Schlüssel-Index(key_index)-Abschnitt 120 und
ein Teil-Schlüssel-Index(sub-key_index)-Abschnitt 130 beschrieben, und dann
wird die Indexstruktur, welche die codierten Schlüsselinformationen
beinhaltet, die durch die Syntax definiert werden, beschrieben.
-
Die
Syntax, welche die Indexstruktur der Metadaten nach einer Ausführungsform
der vorliegenden Erfindung definiert, insbesondere die, welche die
codierten Schlüsselinformationen
beinhaltet, unterscheidet sich dadurch im Konzept von der Syntax,
die in einer herkömmlichen
Schlüsselindex-Technikempfehlung
definiert wird, dass sie Strukturen umfasst, die für ein Codierungskonzept
der Schlüsselinformationen,
wie etwa ein fragment_deskriptor () und ein key_deskriptor (), neu
eingebracht werden, und sie reorganisiert Strukturen des Schlüssel-Indexlisten(key_index_list)-Abschnitts 110,
des Schlüssel-Index(key_index)-Abschnitts 120 und
des Teil-Schlüssel-Index(sub-key_index)-Abschnitts 130.
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt 110 umfasst
Schlüsselinformationen,
welche die jeweiligen Schlüssel
und Identifizierungsinformationen über den Schlüssel-Index(key_index)-Abschnitt 120, der
später
beschrieben wird, definieren.
-
Die
Schlüsselinformationen
dienen dazu, die Schlüssel
zu definieren, d. h., Positionsinformationen in den Metadaten, die
vorbestimmte Felder der Metadaten, welche die Schlüssel bilden,
aufweisen. Die Schlüsselinformationen
umfassen Positionsinformationen eines Metadatenfragments, zu dem
die Felder, welche die Schlüssel
bilden, innerhalb der Metadaten (nachstehend als „Positionsinformationen
eines Fragments" bezeichnet,
was als XPath des Fragments in TVA (fragment_xpath_ptr) ausgedrückt wird)
gehören,
sowie Positionsinformationen von Feldern, welche die Schlüssel bilden,
die innerhalb des jeweiligen Metadatenfragments liegen (nachstehend
zum Beispiel als „Positionsinformationen
eines Schlüssels" bezeichnet, d. h.
als ein XPath für
einen relativen Pfad des Knotens innerhalb des relevanten Fragments,
was als XPath des Schlüssels
in TVA (d. h. key_xpath_ptr) ausgedruckt wird).
-
1. Schlüssel-Indexlisten(key_index_list)-Abschnitt
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt
stellt eine Liste aller übertragenen
Schlüssel
bereit
-
In
einer Ausführungsform
der vorliegenden Erfindung wird ein fragment_xpath_ptr, der Positionsinformationen
des Fragments innerhalb des herkömmlichen
Schlüssel-Indexlisten(key_index_list)-Abschnitts
anzeigt, (als XPath des Fragments in der TVA ausgedrückt) durch
einen fragment_descriptor () ersetzt. Tabelle
1
key_index_account: spezifiziert die Anzahl aller übertragenen
Schlüssel,
d. h., die Anzahl von Indizes für
das gesamte XML-Dokument.
-
fragment_descriptor
(): entspricht der XPath-Position eines Zielfragments, das indiziert
werden soll. Nach einer Ausführungsform
der vorliegenden Erfindungwerden die Positionsinformationen des
Fragments für den
Standardfragmenttyp, wie nachstehend in Tabelle 3 gezeigt, als ein
vorbestimmter Code ausgedrückt.
Der Typ des Fragments ist nicht auf den Standardfragmenttyp von
Tabelle 3 beschränkt,
und das Fragment kann so beliebig wie möglich gebildet werden, solange
seine Form den XPath des Fragments anzeigen kann, um den Schlüssel zu
definieren.
-
key_descriptor
(): entspricht den XPaths der Schlüssel innerhalb der XPath-Position
des Zielfragments, das indiziert werden soll. Wo, ähnlich dem
oben beschriebenen Fragmenttyp, die Positionsinformationen des Schlüssels als
ein vorbestimmter Code ausgedrückt
werden, kann der Standardschlüsseltyp
beschrieben werden. Wie oben mit Bezug auf den fragment_descriptor
() beschrieben, ist der Typ des Schlüssels nicht auf den Standardschlüsseltyp
beschränkt.
-
index_container:
identifiziert den Container, in dem ein spezifizierter Schlüssel-Index(key_index)-Abschnitt
existiert.
-
key_index_identifler:
identifiziert den Schlüssel-Index(key_index)-Abschnitt
innerhalb des Containers, der durch den index_container spezifiziert
wird. Der Schlüssel-Index(key_index)-Abschnitt
kann in einer eindeutigen Weise als Kombination des index_container
und des key_index_identifier identifiziert werden.
-
2. Fragment-Deskriptor (fragment_descriptor)
-
Der
,fragment_descriptor ()' stellt
eine Struktur zur Codierung bezüglich
des Standardfragmenttyps, der häufig
verwendet wird, spezifischer Bits bereit (die zu beliebigen Bits,
wie etwa 8 Bits, 16 Bits und so weiter, codiert werden können), sowie
gleichzeitig eine Struktur, die den XPath als zusätzliche
Informationen bezüglich
des Metadatenfragmenttyps, der von dem Anwender definiert wird,
beschreiben kann. Das heißt,
wo der fragment_descriptor ,0 × FF' ist, zeigt er ein
vom Anwender definiertes Fragment an, und deshalb wird der XPath
für das
relevante vom Anwender definierte Fragment unmittelbar beschrieben. Tabelle
2
-
fragment_type:
stellt den Typ von Fragmenten dar, die indiziert werden sollen.
Codierte Werte werden den Standardfragmenttypen zugewiesen, die
häufig
verwendet werden. Wenn der fragment_type den codierten Wert 0 × FF aufweist,
wird der fragment_xpath_ptr als zusätzliche Information hinzugefügt.
-
Tabelle
3 stellt codierte Werte für
Positionsinformationen der häufig
verwendeten Fragmenttypen dar, sobald eine Suche in dem TV-Anytime
durchgeführt
wird. Die Standardfragmenttypen und die codierten Werte in dieser
Ausführungsform
sind jedoch nicht auf diejenigen beschränkt, die in Tabelle 3 dargestellt
werden, sondern können
gemäß den Anwendungen
erweitert werden. Tabelle 3
| Wert | Beschreibung |
| 0 × 00 | Nicht
bestimmt |
| 0 × 01 | Programinformation-Fragment |
| 0 × 02 | GroupInformation-Fragment |
| 0 × 03 | CreditsInformation-Fragment |
| 0 × 04 | ProgramReview-Fragment |
| 0 × 05 | SegmentInformation-Fragment |
| 0 × 06 | ServiceInformation-Fragment |
| 0 × 07 | BroadcastEvent-Fragment |
| 0 × FF | Vom
Anwender bestimmtes Fragment |
| 0 × 08 – 0 × 0E
0 × 10 – 0 × FF | Reserviert |
-
3. Schlüssel-Deskriptor (key_descriptor)
-
Der
,key_descriptor ()' stellt
eine Struktur für
die Codierung von Positionsinformationen der Schlüssel bereit,
die eine hohe Anwendungshäufigkeit
an spezifischen Bits aufweisen, sobald eine Suche durchgeführt wird,
sowie gleichzeitig eine Struktur der Beschreibung des Schlüsseltyps,
der vom Anwender bei dem XPath definiert wird. Wenn der key_descriptor
zum Beispiel ,0 × FF' ist, zeigt er einen
vom Anwender definierten Schlüssel
an. Deshalb wird der XPath als zusätzliche Information für den vom
Anwender definierten Schlüssel beschrieben.
-
-
key_type:
stellt den Typ des Schlüssels
dar, der indiziert werden soll. Codierte Werte werden den Positionsinformationen
der Standardschlüsseltypen
zugewiesen, die häufig
verwendet werden, sobald eine Suche durchgeführt wird. Wenn der key_type
den codierten Wert ,0 × FF' aufweist, wird der
key_xpath_ptr als zusätzliche
Informationen hinzugefügt.
-
key_xpath_ptr:
bezieht sich auf den relativen Pfad, der in den Fragment-XPath des
Knotens eingebunden ist, als der Schlüssel verwendet wird.
-
Während die
codierten Werte für
die Standardschlüssel
nicht spezifiziert wurden, versteht es sich, dass die codierten
Werte für
die Standardschlüsseltypen
eine Struktur aufweisen können,
die dem Codieren der Fragmenttypen von Tabelle 3 ähnlich ist.
-
Da
die Definitionen des Schlüssel-Index(key_index)-Abschnitts
und des Teil-Schlüssel-Index(sub_key_index)-Abschnitts
dieselben sind wie diejenigen, die in der Schlüsselindex-Technikempfehlung definiert werden,
wird deren ausführliche
Beschreibung weggelassen.
-
4. Schlüssel-Index(key_index)-Abschnitt
-
-
5. Teil-Schlüssel-Index(sub_key_index)-Abschnitt
-
-
Nachstehend
wird die Metadatenstruktur, die durch die oben beschriebene Syntax
definiert wird, mit Bezug auf 8 erläutert, in
der die Metadaten als Segmente der Indexinformationen ausgedrückt werden.
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt 110,
der in der Indexstruktur definiert wird, stellt eine Liste aller übertragenen
Schlüssel
bereit. Die Liste beinhaltet Schlüsselin formationen, die jeden
Schlüssel definieren
(d. h. Positionsinformationen des Fragments (fragment_descriptor)
und/oder Positionsinformationen des Schlüssels (key_descriptor); die
Positionsinformationen des Fragments oder die Positionsinformationen des
Schlüssels
können
selektiv codiert werden; oder sie können abhängig von den Ausführungsformen
der vorliegenden Erfindung gleichzeitig codiert werden) und Identifizierungsinformationen über den
Schlüssel-Index(key_index)-Abschnitt 120,
der später
beschrieben wird. Der XPath des Metadatenfragments ist ein Pfad für den Wurzelknoten
des TVA-Metadaten-XML-Dokuments, d. h. ein absoluter Pfad in derselben
Weise wie in der herkömmlichen
Indexstruktur, und der XPath des Knotens, der als der Schlüssel verwendet
wird, d. h. der XPath des Schlüssels,
stellt einen relativen Pfad des Schlüssels für das Metadatenfragment dar.
Der XPath des Metadatenfragments und der XPath des Schlüssels stellen
in Kombination Positionsinformationen des Schlüssels für das gesamte XML-Dokument
dar.
-
In
der vorliegenden Ausführungsform
werden der codierte Wert, der dem XPath des Metadatenfragments (d.
h. den Positionsinformationen der Fragmentgruppe) entspricht, und
der codierte Wert, der dem XPath des Schlüssels (d. h. den Positionsinformationen
des Schlüssels)
entspricht, jeweils in dem ,fragment_descriptor'-Segment 111 und dem ,key_descriptor'-Segment 112 gespeichert.
-
Wo
Positionsinformationen des Fragments unter den Schlüsselinformationen
vom Standardfragmenttyp sind, der häufig verwendet wird, wird,
wie oben beschrieben, ein codierter Wert (fragment_descriptor) bereitgestellt,
der den XPath für
das Metadatenfragment (fragment_xpath_ptr) mit einem vorbestimmten
Code ausdrückt.
Als Standardfragmenttypen, die häufig
verwendet werden, gibt es zum Beispiel Programminformationen (ProgramInformation),
Programmgruppeninformationen (GroupInformation), Kreditinformationen
(CreditInformation), Programmüberprüfung (ProgramReview),
Segmentinformationen (SegmentInformation), Rundfunkereignis (BroadcastEvent),
Dienstinformationen (ServiceInformation) und Ähnliches. Wenn der XPath des
Metadatenfragments für
diese Fragmenttypen einfach als ein codierter Wert ausgedrückt werden kann,
kann der Overhead bei der Suche nach den Metadaten reduziert werden.
-
Deshalb
wird in der Indexstruktur nach der vorliegenden Erfindung der XPath
des Standard-Metadatenfragments
mit einem vorbestimmten Wert codiert und dann gespeichert. Ferner
werden nicht alle codierten Werte den Fragmenten zugewiesen, und
einige codierte Wert (z. B. ,0 × FF') werden, wie es von dem Anwender definiert
wird, den Metadatenfragmenten zugewiesen, um dadurch dem Anwender
zu ermöglichen,
durch den XPath zusätzlich
Positionsinformationen über
das Metadatenfragment zu definieren. Diesbezüglich wird ein zusätzlicher
Bereich, zum Beispiel (,fragment_xpath_ptr'), durch den der XPath für das Metadatenfragment bestimmt
werden kann, bereitgestellt.
-
In
der Ausführungsform,
in der Fragmente gemäß Tabelle
3 codiert wenden, weisen die Positionsinformationen über das
Metadatenfragment solche codierten Werte wie ,0 × 01', ,0 × 02' und ,0 × 03' auf. Die Positionsinformation über das
Metadatenfragment, die mit ,0 × 01' codiert ist, zeigt
den XPath des ,Programminformations-(Programinformation)-Fragments' an. Wo ferner die
Positionsinformation über
das Metadatenfragment 0 × FF
ist, bedeutet das, dass das Metadatenfragment von dem Anwender definiert
wird, und deshalb wird ein zusätzlicher
Bereich bereitgestellt, um zu ermöglichen, dass der XPath des
Metadatenfragments bestimmt wird.
-
Obwohl
die obige Ausführungsform
nur bezüglich
des Metadatenfragments beschrieben wurde, kann dieselbe bezüglich des
Schlüssels/der
Schlüssel
für das
Metadatenfragment angewendet werden. Das heißt, codierte Werte können bestimmt
werden und anstelle des herkömmlichen
XPath für
die Schlüssel
für häufig verwendete
Schlüssel
angewendet werden. Wenn der codierte Wert einen vorbestimmten Wert
umfasst, kann der Anwender zusätzlich
den XPath für
den Schlüssel
bestimmen. Das Codieren des XPath des zuvor erwähnten Metadatenfragments und
das Codieren des Schlüssels
können
gleichzeitig oder unabhängig
angewendet werden.
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt 110 umfasst
ferner die Positionsinformationen über den Schlüssel-Index(key_index)-Abschnitt 120 jedes
Schlüssels,
der später
beschrieben wird (d. h. die Container-Identifikator-Informationen
(container_id) des Containers, in dem der Schlüssel-Index(key_index)-Abschnitt 120 und
die Schlüsselindex-Identifikator-Informationen
gespeichert sind). Die Container-Identifikator-Informationen und
die Schlüsselindex-Identifikator-Informationen
werden jeweils in einem ,index_container'-Segment
und einem ,key_index_identifier'-Segment
in dem Schlüssel-Indexlisten(key_index_list)-Abschnitt 110 gespeichert.
-
Da
der Schlüssel-Index(key_index)-Abschnitt 120 und
der Teil-Schlüssel-Index(subkey_index)-Abschnitt 130 dieselben
sind wie in der Schlüsselindex-Technikempfehlung,
wird deren Beschreibung weggelassen.
-
Die
Indexstruktur, welche die codierten Schlüsselinformationen beinhaltet,
wird ausführlich
mit Bezug auf 9 beschrieben, welche die Indexinformationen
nach einer Ausführungsform
der vorliegenden Erfindung darstellt
-
9 zeigt
den Schlüssel-Indexlisten(key_index_list)-Abschnitt 110,
in dem der XPath des ,BroadcastEvent'-Fragments für die Dienst-ID mit ,0 × 07' codiert ist. Hierbei
sind der Schlüssel-Index(key_index)-Abschnitt 120 und
der Teil-Schlüssel-Index(sub-key_index)-Abschnitt
130 dieselben wie die mit Bezug auf 7 beschriebenen.
-
Die
oben beschriebene Indexstruktur ist sehr effektiv, sobald die Schlüssel verwendet
werden, die zu den häufig
verwendeten Fragmenttypen, z. B. ProgramInformation, Groupinformation,
BroadcastEvent und so weiter, gehören, wodurch der gesamte Overhead
in der Vorrichtung für
das Suchen der Metadaten reduziert wird.
-
10 stellt
ein Verfahren der Bereitstellung eines Index von Metadaten dar,
welche eine Struktur nach einer Ausführungsform der vorliegenden
Erfindung aufweisen, wie sie oben beschrieben ist.
-
Indizes
der Metadaten nach einer Ausführungsform
der vorliegenden Erfindung können
durch den Anbieter 200 erzeugt werden, der zum Beispiel
Audio/Video-Signale bereitstellt.
-
Informationen über Inhalte,
d. h. Metadaten, werden zunächst,
wie oben beschrieben, auf einer Fragmentbasis verarbeitet (S100).
Wenigstens ein Teil von Informationen über die Felder (Positionsinformationen des
Fragments oder Positionsinformationen des Schlüssels), die in dem Metadatenindex
enthalten sein werden, das heißt
Informationen über
den Schlüssel
(zum Beispiel Positionsinformationen des Fragments und Positionsinformationen
des Schlüssels)
werden ediert (S200). Mit anderen Worten, wo Positionsinformationen des
Metadatenfragments, zu dem Felder, die Schlüssel bilden, gehören, oder
Positionsinformationen des Schlüssels
vom Standardfragmenttyp oder vom Standardschlüsseltyp sind, können beide,
die Positionsinformationen des Metadatenfragments oder Positionsinformationen des
Schlüssels
codiert werden, d. h., der XPath des Metadatenfragments oder der
XPath des Schlüssels
wird mit einem vorbestimmten Code-Wert codiert (das Rundfunkereignis(BroadcastEvent)-Fragment
wird zum Beispiel in 9 mit ,0 × 07' codiert). Wo die Positionsinformationen
des Metadatenfragments oder die Positionsinformationen des Schlüssels durch
den codierten Wert nicht identifiziert werden, können die Schlüsselinformation,
die mit XPath ausgedrückt
werden, wie in der herkömmlichen
Technik genutzt werden.
-
Durch
Verwendung von Informationen, die ein Fragment bilden, zum Beispiel
Informationen über
eine ,Dienst-ID',
wird ein Schlüssel
bereitgestellt (S300). Dann wird ein Teil-Schlüssel-Index(sub-key_index)-Abschnitt 130,
wie oben vorgesehen, für
den Schlüssel
bereitgestellt (S400). Der Teil-Schlüssel-Index(sub-key_index)-Abschnitt 130 beinhaltet
Segmente 114, die darin Bereich von Werten des Schlüssels aufweisen,
sowie Fragmentdaten-Identifizierungsinformationen,
die den Werten des Schlüssels
entsprechen (das heißt
die Container-Identifikator-Informationen (container_id) und die
Metadatenfragment-Identifikator-Informationen
(handle_value), die jeweils in dem ,target_container'-Segment und dem
,target_container'-Segment von 8 gespeichert
sind).
-
Ein
Schlüssel-Index(key_index)-Abschnitt 120,
der repräsentative
Schlüsselwerte
aufweist, welche die jeweiligen Bereiche von Werten des Schlüssels darstellen,
wird bereitgestellt (S500). Zum Beispiel ist ein repräsentativer
Schlüsselwert
(z. B 509), der einen vorbestimmten Bereich der Dienst-ID
anzeigt (z. B. 500–509),
enthalten. Der Schlüssel-Index(key_index)-Abschnitt 120 beinhaltet
darin Identifizierungsinformationen für den Teil-Schlüssel-Index(sub-key_index)-Abschnitt 130,
wobei die Identifizierungsinformationen die Container-Identifikator-Informationen
(container_id) des Containers umfassen, in dem der Teil-Schlüssel-Index(sub-key_index)-Abschnitt 130 gespeichert
ist, und die in 8 gezeigten Teil-Schlüssel-Index-Identifizierungsinformationen.
-
Ein
Schlüssel-Indexlisten(key_index_list)-Abschnitt 110,
der basierend auf dem Schlüssel
Schlüsselinformationen
wie oben vorgesehen anordnet, das heißt Positionsinformationen des
Fragments und Positionsinformationen des Schlüssels, wird bereitgestellt
(S600). Wenn zu diesem Zeitpunkt die codierten Positionsinformationen
des Fragments und die codierten Positionsinformationen des Schlüssels in
dem Schritt S200 existieren, werden die obigen Positionsinformationen
als ein codierter Code ausgedrückt,
sobald der SchlüsselIndexlisten(key_index_list)-Abschnitt 110 bereitgestellt
wird. Mit anderen Worten, das ,Rundfunkereignis (BroadcastEvent)'-Fragment in 9 wird
zum Beispiel als ,0 × 07' ausgedrückt. Wo
die Positionsinformationen des Fragments oder die codierten Positionsinformationen
des Schlüssels
nicht durch einen codierten Wert differenziert werden können, können die
Schlüsselinformationen,
die in dem XPath wie in der herkömmlichen
Technik ausgedrückt
werden, angewendet werden.
-
Der
Schlüssel-Indexlisten(key_index_list)-Abschnitt 110 umfasst,
zusätzlich
zu den Schlüsselinformationen,
ferner Identifizierungsinformationen über den Schlüssel-Index(key_index)-Abschnitt 120.
-
Die
oben beschriebenen Schritte können
in anderen Ausführungsformen
der vorliegenden Erfindung in umgekehrter Reihenfolge ablaufen,
und der Schritt S500 der Bereitstellung des Schlüssel-Index(key_index) Abschnitts 120,
der darin die repräsentativen
Schlüsselwerte
enthält,
kann abhängig
von der (den) Ausführungsform(en)
weggelassen werden.
-
Nachstehend
wird, unter Verwendung des Metadatenindex, der die Struktur nach
einer oben beschriebenen Ausführungsform
der vorliegenden Erfindung aufweist, mit Bezug auf 11 ein
Verfahren des Suchens nach Metadaten beschrieben.
-
Eine
Suchbedingung wird zum Beispiel durch einen Anwender eingegeben
(S1100) und Positionsinformationen von Metadaten, die sich auf ein
Feld der eingegebenen Suchbedingung beziehen, werden bestimmt (S1210).
Ein Schlüssel,
der den Positionsinformationen des Felds entspricht, wird in dem
Schlüssel-Indexlisten(key_index_list)Abschnitt 110 gesucht
(1300), wobei mindestens ein Teil der Positionsinformationen, z.
B. Positionsinformationen eines Fragments, die einen Schlüssel enthalten,
oder Positionsinformationen des Schlüssels innerhalb des Fragments,
mit einem vorbestimmten Code definiert werden, und die betreffenden Metadaten
werden unter Verwendung des gesuchten Schlüssels extrahiert (S1400).
-
Der
Schritt des Extrahierens der betreffenden Metadaten, S1400, umfasst
die folgenden Schritte: das Suchen nach einem repräsentativen
Schlüsselwert,
der die Suchbedingung erfüllt,
durch Vergleichen des repräsentativen
Schlüsselwerts
und des Bereichs von Werten des Schlüssels der Suchbedingung in
dem Schlüssel-Index(key_index)-Abschnitt 120;
und das Suchen des Teil-Schlüssel-Index(sub_key_index)-Abschnitts 130 für ein Segment 114, das
die Werte des Schlüssels
in dem Bereich beinhaltet, der durch den gesuchten repräsentativen
Schlüsselwert
dargestellt wird (S1410); das Suchen nach einem Wert des Schlüssels, der
die Suchbedingung in dem Segment 114 des gesuchten Teil-Schlüssel-Index(sub-key_index)-Abschnitts 130 erfüllt (S1420);
und das Extrahieren der betreffenden Metadaten unter Verwendung
der Identifizierungsinformationen des Metadatenfragments, die dem
Wert des gesuchten Schlüssels
entsprechen, wobei das Metadatenfragment, das die Suchbedingung
erfüllt,
extrahiert wird. Es versteht sich, dass zum Beispiel mit Bezug auf 2 und 9,
wo eine Suchbedingung, die einem Schlüssel der Dienst-ID in dem Bereich
von 507–514 entspricht, eingegeben
wird, repräsentative
Werte 509 und 519 gesucht werden, Werte aus den
repräsentativen
Bereichen von Werten des Schlüssels
gesucht werden, und Fragmente, die der Suchbedingung entsprechen,
unter Verwendung der identifizierungsinformationen über das
Fragment, das den Werten des Schlüssels entspricht, extrahiert
wenden.
-
Die
Positionsinformationen des Fragments beziehen sich auf einen absoluten
Pfad des Metadatenfragments dessen Schlüssel wie oben beschrieben indiziert
werden sollen, das heißt,
der XPath des Metadatenfragments (fragment_xpath_ptr), und die Positionsinformationen
des Schlüssels
beziehen sich auf einen relativen Pfad des Schlüssels für das Metadatenfragment (relativer
Pfad in der XPath-Position des Fragments), das heißt, auf
den XPath (key_descriptor) der Knoten, die als Schlüssel verwendet
werden.
-
In
den Schritten S1410, S1420 und S1430 laufen die Schritte des Suchens
des betreffenden Schlüssel-Index(key_index)-Abschnitts 120 und
des Teil-Schlüssel-Index(sub-key_index)-Abschnitts 130 sowie
das Extrahieren des betreffenden Fragments jeweils unter Verwendung
der Identifizierungsinformationen des Schlüssel-Index(key_index)-Abschnitts 120 und
des Teil-Schlüssel-Index(sub-key_index)
Abschnitts 130 sowie des Metadatenfragments ab.
-
12 beschreibt
eine Vorrichtung zum Suchen der Metadaten nach einer Ausführungsform
der vorliegenden Erfindung. Die Vorrichtung führt ein Verfahren des Suchens
der Metadaten nach der vorliegenden Erfindung, das mit Bezug auf 11 beschrieben
wird, durch.
-
Die
Vorrichtung 1000 umfasst: eine Eingabeeinheit 1100,
die einem Anwender ermöglicht,
eine Suchbedingung einzugeben; eine Empfangseinheit 1200,
die Inhalte, Metadaten in Inhalten oder einen Index der Metadaten
empfängt;
eine Speichereinheit 1300, welche die empfangenen Inhalte,
die Metadaten in den Inhalten oder den Index der Metadaten darin
speichert; und eine Steuereinheit 1400, welche die Positionsinformationen
der Metadaten bestimmt, die dem Feld der Suchbedingung entsprechen,
das von der Eingabeeinheit 1100 eingegeben wird; das Suchen
des Schlüssels,
der den Code enthält,
der als Positionsinformation vorbestimmt wird, wobei mindestens
ein Teil der Positionsinformationen als ein vorbestimmter Code definiert
wird; und das Extrahieren der betreffenden Metadaten unter Verwendung
des gesuchten Schlüssels;
und eine Ausgabeeinheit 1500, die das Ergebnis der Suche
durch die Steuereinheit 1400 ausgibt.
-
Die
Steuereinheit 1400 vergleicht die Suchbedingung, die von
der Eingabeeinheit 1100 eingegeben wird, mit dem Wert des
Schlüssels,
der in dem Metadatenindex enthalten ist, der in der Speichereinheit 1300 gespeichert
ist.
-
Unter
den Schritten des Suchens der Metadaten nach einer Ausführungsform
der vorliegenden Erfindung werden der Schritt des Bestimmens der
Positionsinformationen des Felds der eingegebenen Suchbedingung
innerhalb der Metadaten (S1210), der Schritt des Suchens des Schlüssels, der
den vorbestimmten Code als Positionsinformation enthält, wobei
mindestens ein Teil der Positionsinformationen als ein vorbestimmter Code
definiert wird (S1300), und der Schritt des Extrahierens der betreffenden
Metadaten unter Verwendung des gesuchten Schlüssels (S1400) in der Steuereinheit 1400 durchgeführt. Beschreibungen
dieser Schritte wurden mit Bezug auf 11 dargelegt.
-
Die
vorliegende Erfindung schlägt
eine Indexstruktur vor, die ein vereinfachtes Indizieren für Metadatenfragmente
bereitstellt, um die Metadatenfragmente in einer schnellen Weise
zu suchen, in einer Umgebung, in der die Metadaten auf einer Fragmentbasis
strukturiert sind, sowie ein Verfahren für das Suchen der Indexinformationen
und eine Vorrichtung für
das Suchen der Indexinformationen.
-
Industrielle Anwendbarkeit
-
Nach
der vorliegenden Erfindung ist eine schnelle Suche von Metadaten
verfügbar
und ein Overhead für
die Vorrichtung für
das Suchen der Metadaten wird reduziert, wodurch die Suchzeit verkürzt wird
und die Effizienz der Vorrichtung für das Suchen der Metadaten
erhöht
wird. Es versteht sich jedoch, dass während erläuternde, nicht einschränkende Ausfüh rungsformen
der vorliegenden Erfindung die oben beschriebenen Nachteile und
andere nicht beschriebene Nachteile überwinden, von der vorliegenden
Erfindung nicht verlangt wird, dass sie die oben beschriebenen Nachteile überwindet,
und erläuternde,
nicht einschränkende
Ausführungsformen
der vorliegenden Erfindung können
nicht jedes der oben beschriebenen Probleme überwinden. Es versteht sich
ebenfalls, dass ein System, welches die vorliegende Erfindung verwendet,
auch einen permanenten oder austauschbaren Speicher beinhaltet,
wie etwa magnetische und optische Platten, einen RAM, einen ROM,
ein Trägerwellen-Medium
etc., auf dem der Ablauf und die Datenstrukturen der vorliegenden
Erfindung gespeichert und vertrieben werden können. Die Verfahren können zum
Beispiel auch durch das Downloaden über ein Netzwerk wie das Internet
vertrieben werden.
-
Obwohl
ein paar bevorzugte Ausführungsformen
gezeigt und beschrieben wurden, wird es von Fachleuten geschätzt, dass
verschiedene Veränderungen
und Modifikationen durchgeführt
werden können,
was in den beigefügten
Ansprüchen
definiert wird.
