WO2006010107A1 - Service de metadonnees - Google Patents

Service de metadonnees Download PDF

Info

Publication number
WO2006010107A1
WO2006010107A1 PCT/US2005/024503 US2005024503W WO2006010107A1 WO 2006010107 A1 WO2006010107 A1 WO 2006010107A1 US 2005024503 W US2005024503 W US 2005024503W WO 2006010107 A1 WO2006010107 A1 WO 2006010107A1
Authority
WO
WIPO (PCT)
Prior art keywords
metadata
mapping
control point
tva
module
Prior art date
Application number
PCT/US2005/024503
Other languages
English (en)
Inventor
Dennis Bushmitch
Hong Heather Yu
Rajesh Khandelwal
Original Assignee
Matsushita Electric Industrial Co. Ltd.
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 Matsushita Electric Industrial Co. Ltd. filed Critical Matsushita Electric Industrial Co. Ltd.
Publication of WO2006010107A1 publication Critical patent/WO2006010107A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H04N21/8405—Generation or processing of descriptive data, e.g. content descriptors represented by keywords

Definitions

  • the present invention generally relates to a general architecture of an XML-based metadata service and its extensions.
  • TV-Anytime has specified a set of tools that allow establishment of richer relationships between content producers, service providers, and consumers.
  • the TV-Anytime metadata (MD) system allows the consumer to find, navigate and manage content from a variety of internal and external sources including, for example, enhanced broadcast, interactive TV, Internet and local storage. It allows consumption of this content at the time and location that users want in respect to access and usage rules associated to this content. It also defines a standard way to describe consumer profiles including search preferences to facilitate automatic filtering and acquisition of content by agents on behalf of the consumer.
  • TV-Anytime metadata contains a much richer set of structured metadata information than currently defined in UPnP AV specifications (e.g., UPnP CDS, SRS, etc.).
  • UPnP CDS provides metadata listing strongly related with program information MD, program location MD, and other content item specific MD.
  • existing provisions for consumer metadata support, segmentation metadata, DRM-related metadata, or group information-related MD e.g., UPnP
  • existing XML-based home control frameworks e.g., UPnP
  • TVA TV Anytime
  • a metadata service system includes a datastore of metadata objects.
  • a search and search and browsing module is adapted to receive a search request from a control point and return at least part of one or more metadata objects to the control point based on a content reference identifier specified by the search request.
  • the metadata service system is adapted to inform the control point of its existence and capabilities by participating as a service in a service discovery protocol.
  • Figure 1A is a block diagram illustrating a metadata service architecture in accordance with the present invention.
  • FIG. 1B is a block diagram illustrating inheritance of TVA document metadata structure in accordance with the present invention.
  • Figure 1C is a block diagram illustrating MDS fragment (MDObject) hierarchy in accordance with the present invention
  • Figure 2 is a block diagram illustrating a metadata bridging service and metadata translation service in accordance with the present invention
  • Figure 3 is a block diagram illustrating generation of a mapping between metadata sets in accordance with the present invention
  • Figure 4 is a block diagram illustrating an example translation service scenario in accordance with the present invention
  • Figure 5 is a block diagram illustrating a multi-pass, multi- iteration metadata mapping process in accordance with the present invention
  • Figure 6 is a block diagram illustrating mapping of a multi- metadata set to a single metadata set, with subsequent unidirectional metadata translation in accordance with the present invention.
  • Figure 7 is a block diagram illustrating mapping of a multi- metadata set to a single metadata set, with subsequent bidirectional metadata translation in accordance with the present invention.
  • the metadata service (MDS) can be implemented to facilitate the TV-Anytime metadata system to provide interoperability between UPnP and other services and broadcasting standards that implement TV-Anytime, such as ARIB, DVB, and ATSC.
  • the MDS can provide an extensible and flexible framework for TVA metadata discovery, distribution, and update (DDU) in a UPnP-compliant manner. It can also offer the capability for both consumer and content metadata DDU, with better granularity and easy management ability. It can further allow customers to initiate and perform MDS operations from any networked control point with a variety of Ul devices and personalized metadata to be delivered to any networked render devices. It can still further provide a standard way to describe consumer profiles, including search preferences to facilitate automatic filtering, and acquisition of content by agents on behalf of the consumer. These capabilities improve both user convenience and user entertainment experience.
  • the MDS provides a query service that allows clients (e.g. Ul devices) to locate various content (such as TV program, movies, music, and etc) or a segment of the content (such as a portion of a video) that the (server) device is capable of retrieving; and to retrieve metadata associated and related to a piece of content that maybe provided by multiple services. For example, it can be used to retrieve multiple 'reviews' of a TV series or a specific episode available at multiple websites; to enumerate a list of TV drama shows currently being broadcast and the associated metadata
  • the present invention is an XML Device Control Framework (e.g., UPnP)-discoverable and controllable TVA metadata service.
  • XML Device Control Framework e.g., UPnP
  • the novel middleware service architecture allows the user to bridge the home networking and TVA worlds by introducing a TVA metadata distribution service for home LAN networks.
  • This service is discoverable and controllable from XML-based home control frameworks (e.g., UPnP)-based AVC devices.
  • Additional service components can also allow semantic metadata translation and bridging between TVA metadata classes and other data types.
  • the present invention treats content referencing identifier (CRID) sources in UPnP AV as follows: (1 ) a GRID issuing authority in UPnP AV scenario comes from a Content Directory Services (CDS) listing, as obtained from the following entities: (a) content creator; (b) content service provider (e.g., broadcaster); and (c) 3rd party; (2) this functionality requires a "CSV list" structure in UPnP, as multiple GRID can be returned by the GRID issuing authority service, and can include: (a) GRID': type: any URI; use: optional; (b) the 'GRID' attribute that identifies the content reference ID; (c) the Syntax of a CRID attribute; and (d) CRID:// ⁇ DNS name>; ⁇ name_extension>/ ⁇ data>, where ⁇ DNS name>; ⁇ name_extension> is the syntax of an authority name.
  • CDS Content Directory Services
  • the present invention can accomplish CRID location resolution as follows: (1) it is not important how the location resolution occurs in the device, as long as the results are exposed by the MDS, based on the following assumptions: (a) that UPnP protocols are not used for CRID resolution; and (b) that the UPnP specification avoids complex interaction scenarios between devices as a result of UPnP actions; (2) whichever UPnP device (server, STB, PDR) provide location resolution services, it will determine the target device for the MDS service, and will need to define the UPnP device (i.e., which UPnP MDS services are included).
  • Metadata discovery the metadata service is discoverable and self-describing, with types of supported metadata, service interfaces (actions), and state variables being provided in the service description documents.
  • actions can return complex object types comprised from a metadata listing for a specific CRID (e.g., Metadata Listing with advanced search criteria (akin Content Directory Service Browser()action)).
  • CRID e.g., Metadata Listing with advanced search criteria (akin Content Directory Service Browser()action)
  • subscribers can be notified about changes in metadata state, with these events also capable of being moderated.
  • the metadata service architecture can include a control point 10 interacting with a content directory service (CDS) 12 and the metadata service system 14.
  • CDS content directory service
  • the control point 10 obtains an item listing and CRID property specifying a CSV list, including a program CRID and group CRID from the CDS 12.
  • the control point 10 employs published methods to interact with the system 14, including a create method 16, a browse method 18, an update method 20, and a delete method 22.
  • the control point 10 sends a create metadata objects request having arguments such as ID, type, and objects; the control point 10 receives a success or error message in reply from the service system 14.
  • control point 10 sends a GRID, an instance ID, and search criteria, such as a program CRID and group ID to the system 14; in reply from the service system 14, the control point 10 receives metadata objects including DlDL-MDS schema, such as location metadata, segmentation metadata, CRIDs, etc..
  • the control point 10 sends updated metadata objects with arguments such as type and TLVs to the system 14; in reply from the service system 14, the control point 10 receives a message indicating success or error.
  • the control point 10 sends a delete metadata objects command specifying an ID to the system 14; in reply, the control point 10 receives from the system 14 a message indicating success or error.
  • Location resolution occurs internally in the system 14.
  • the present invention employs a MDS internal reference ID (MDObjectJD) as a reference type for MDS objects, with the MDObjectJD being created by the MDS.
  • MDObjectJD MDS internal reference ID
  • This reference type is employed because CRID does not have sufficient granularity to properly reference all metadata objects. Instead, GRID only provides "per-content item" granularity.
  • MDObjectJD references specific MDS metadata objects.
  • the MDObjectJD created by MDS is unique per each existing MDS object.
  • the MDObjectJD can use a GRID + ⁇ D# ⁇ association to insure uniqueness.
  • the MDS has a simple referencing model, ⁇ int ⁇ .
  • FIG. 1 B some embodiments of the MDS inherit TV-anytime metadata structure, where fragmentation is the generic decomposition mechanism of the metadata description into self-consistent units of data. More details related to TVA Anytime specification information can be obtained from the following TVA Specification documents: SP002V1.3, TV- Anytime Specification - System Description, February 2003; SP003V1.3, TV- Anytime Specification - Metadata, December 2002; and SP004V1.2, TV-Anytime Specification - Content Referencing, June 2002.
  • the aforementioned TVA Specification documents are available at: http://www.tv-anvtime.org.
  • TVAMain There are four basic kinds of metadata that a "TVAMain" element 100 groups: (1 ) Content description metadata 102; (2) Instance description metadata 104; (3) Consumer metadata 106; and (4) Segmentation metadata 108.
  • Content description metadata 102 is general information about a piece of content that does not change regardless of how the content is published or broadcast. It includes information such as the content's title, textual description, and genre. Various components of the content description metadata 102 can be stored in program information table 102A, group information table 102B, credits information table 102C, and program review table 102D. Typically, the content creator assigns content description metadata before publication.
  • Instance description metadata 104 describes a particular instance of a piece of content, including information such as the content location, usage rules (pay-per-view, etc.), and delivery parameters (e.g., video format).
  • instance description metadata 104 can be stored in service information table 104A and program location table 104B.
  • Instance description metadata 104 is assigned by the content provider as a part of the publication of content. During the search and selection process, a consumer may use both general content and instance descriptions.
  • a third category of metadata called consumer metadata 106 includes usage history 106B data (logging data), annotation metadata, and user preferences 106A.
  • Segmentation information stored, for example, in segmentation information table 108A can be used to enhance the users viewing experience by providing the ability to view content in a non-linear way. Segmentation refers to the ability to define, access and manipulate temporal intervals (i.e., segments) within an AV stream.
  • Segmentation metadata 108 By associating metadata with segments and segment groups - segmentation metadata 108, it is possible to restructure and re-purpose an input AV stream to generate alternative consumption and navigation modes. Such modes can include, for example, a summary of the content with highlights, or a set of bookmarks that point to "topic headings" within the stream.
  • Such metadata can be provided by service providers or broadcasters as a value- added feature, and/or generated by viewers themselves. Applications include, for example, repurposing of content for educational purposes.
  • the segmentation metadata 108 may be acquired at the same time as the content or it may be intermittently broadcast from the carousel and acquisition may occur at a later time.
  • MDObject is defined as a reference to any metadata segment that can be returned by Metadata services.
  • MDS inherits TVA metadata structure, where fragmentation is the generic decomposition mechanism of a TVA metadata description into self-consistent units of data, called TVA fragments. A fragment is the ultimate atomic part of a TV-Anytime metadata description that can be transmitted independently to a terminal.
  • a fragment shall be self consistent in the sense that: (1 ) It shall be capable of being updated independently from other fragments; (2) The way it is decoded, processed and accessed shall be independent from the order in which it is transmitted relative to other fragments; (3) The decoding of a fragment and its addition to the partial description shall give a TV-Anytime schema valid description. Note that a partial description must have at least the fragment delivering the root element (TVAMain).
  • the self-consistency capability of a TVA fragment means that: (1 ) Fragments can be obtained in a random order; (2) Each fragment can be transmitted and updated independently; and (3) After a fragment has been received and decoded, the resulting partial description is valid with respect to the TVA schema.
  • Root fragment contains the TVAMain root element plus a limited range of child nodes, wherein CopyrightNotice, ClassificationSchemeTable, ClassificationSchemeTable, ProgramlnformationTable, GrouplnformationTable, ProgramLocationTable, ServicelnformationTable, CreditslnformationTable, ProgramReviewTable, and SegmentlnformationTable with SegmentList, SegmentGroupList and TimeBaseReference are example members of the TVAMain fragment; and (b) CSAIias fragment and ClassificationScheme fragment are children elements of ClassificationSchemes - a member of TVAMain fragment; and (2) Fragments that are child elements of TVAMain fragment: (a) Programlnformation fragment containing metadata for a given content, such that Programlnformation is a direct child element of ProgramlnformationTable element; (b) Grouplnformation fragment containing metadata are used for a given group of contents.
  • Grouplnformation is a direct child element of GrouplnformationTable element;
  • OnDemandProgram and OnDemandService fragment are used for the description of on-demand instances of contents;
  • BroadcastEvent fragment and Schedule fragment are used for the description of broadcast instances of contents and of the services where they are available;
  • OnDemandProgram, OnDemandService, BroadcastEvent, and Schedule are children elements of ProgramLocationTable element;
  • Servicelnformation fragment contains details about a single Service within a broadcast system.
  • Servicelnformation is a direct child element of ServicelnformationTable;
  • PersonName and OrganisationName fragments are for the Creditlnformation metadata, and are children of CreditlnformationTable element;
  • Review fragment is to contain review of a given content, and is a direct child element of ProgramReviewTable;
  • Segmentlnformation fragment and SegmentGrouplnformation fragment are used for the Segmentation metadata, wherein Segmentlnformation element is a child of the SegmentList element and SegmentGrouplnformation element is a child of the SegmentGroupList element.
  • a MDObject hierarchy has the following characteristics: (1 ) An MDObject is the atomic part of MDS that can be independently obtained, stored, transmitted, updated, and returned in random order, and each MDObject can be accessed, decoded, and processed independent from the order it is stored or received; (2) there is a root object called Root MDObject 110, for example TVAMain fragment; (3) each MDObject can have zero to multiple children MDObjects 114A-114E which can be represented in a tree structure; (4) MDObjectJD is the key representation of MDObject.
  • the Root MDObject 110 has a root element 112, and with child elements 116A-116C corresponding to child MDObjects, such as child MDObjects 114A-114E, which can be TVA child fragments.
  • the child MDObjects 114A-114E each comprise a subtree.
  • child MD Object 114A has root element 118 that is the root of the subtree comprising that child MD object 114A.
  • Child fragments 120A and 120B of that subtree can therefore correspond to tables storing appropriate metadata for the TVA child fragment.
  • Table 2 lists fragment_type ID defined in TVA, to identify the type of TVA fragments. MDS inherits these ID values for interoperability.
  • MDS adopts XML Schema as the common representation format for documentation of metadata.
  • MDS can use the MPEG-7 Description Definition Language (DDL) to describe metadata structure as well as the XML encoding of metadata.
  • DDL is based on XML schema as recommended by W3C. It should be readily understood that DDL is used in TVA, but the MDS should not be limited to use of DDL when extended to other metadata types.
  • MDS is fully interoperable with TV- anytime schema which is based on DDL.
  • MDS can come from one of three metadata namespaces: TV-anytime, MPEG-7 DDL, Dublin Core (dc), or UPnP (upnp).
  • the TV-Anytime metadata namespace: xmlns:tva "urn:tva:metadata:2002”.
  • MPEG-7 metadata namespace: xmlns:mpeg7 "urm:mpeg:mpeg7:schema:2001".
  • datatypes MDS data typing facilities are based on
  • XML Schema Datatypes, the MPEG-7 datatypes, and TV-anytime datatypes.
  • Some embodiments of the MDS provide a standard way of describing common data structures required within an UPnP environment. However there may be instances where third parties may wish to extend it to provide enhancements to existing data types, or to introduce completely new data types, providing additional functionality. This extension can be achieved in a backward compatible way using standard XML Schema methods. Note that the declaration of new data types must occur in a separate schema document and have their own unique namespace. [0042] In terms of basic types, the simple and complex utility types defined below are used throughout this specification in order to describe some embodiments of the present invention.
  • MDObjectJD A simple type used to indicate uniqueness of a metadata fragment within a metadata description
  • MDObjectJDs are used in MDS.
  • MDObjectJD is provided to enable identification of MDObject for referencing, which assists in various functionalities of MDS, such as metadata browsing and searching. It also enables MDObjects (such as fragments) to reference other MDObjects within the same MDS framework.
  • the guideline rules for use of MDObjectJD include: (1 ) The value assigned to MDObjectJD must be unique within a MDS; (2) in case of an update to an MDObject, it maybe appropriate to create a totally new MDObjectJD corresponding to the updated MDObject.
  • state variables the service's state variables exist primarily to support argument passing of the service's actions. Information is not exposed directly through explicit state variables. Rather, a client retrieves metadata information via the return parameters of actions further defined below in relation to Table 6. The majority of state variables defined below in Table 4 exist simply to enable the various actions of this service. Table 4. State Variables
  • A_ARG_TYPE_Count This variable is used in conjunction with those actions that include a Count parameter. Count parameters specify an ordinal number of arbitrary objects.
  • A_ARG_TYPE_Crid This variable is used in conjunction with those actions that include a Crid parameter.
  • A_ARG_TYPE_Crid variables must use proper syntax as described in [TVA SP004] SP004V1.2, TV-Anytime Specification - Content Referencing, June 2002. Available at: http://www.tv- anytime.org.
  • A_ARG_TYPE_Filter This variable is used in conjunction with those actions that include a Filter parameter. The comma-separated list of property specifiers (including namespaces) indicates which metadata properties are to be returned in the results from browsing.
  • Both properties represented in MDS query results as XML elements, as well as properties represented as element attributes, may be included in the comma-separated list. If the Filter parameter is equal to " * ", all properties are returned. As a rule, all required properties are returned, but no optional properties will be returned unless explicitly requested in the filter.
  • a MDS must always respond to Browse() requests with valid metadata, such as TVA metadata in the current version of the specification, in the Result parameter. Individual properties specified in the comma-separated filter list that would result in an invalid MDS Result are selectively ignored by the MDS. In the current version of the specification, if the result is an invalid TVA Result, it is selectively ignored by MDS. By the same token, individual properties NOT specified in the comma-separated Filter list that are required for a valid MDS Result are automatically included.
  • A_ARG_TYPE_Result This variable is used in conjunction with those actions that include a Result parameter.
  • the structure of the result is a valid MDObject.
  • the structure of the result is a valid TVA XML fragment: (1 ) ⁇ TVAMain> is the root element; (2)
  • the TV-Anytime XML Schema contains many elements that are optional and some that are mandatory as detailed in [TVA SP003] SP003V1.3, TV-Anytime Specification - Metadata, December 2002. Available at: http://www.tv-anvtime.org. The following two examples illustrate sample valid Result in some embodiments.
  • A_ARG_TYPE_SearchCriteria is the related state variable for the SearchCriteria parameter used in search actions.
  • the SearchCriteria parameter gives one or more search criteria to be used for querying the metadata in MDS.
  • SearchCriteria string syntax is described here formally using EBNF as described in [CDS] UPnP Specification, UPnP Content Directory Service, Version 1.
  • searchCrit :: searchExp
  • asterisk searchExp :: relExp
  • 's1 and s2 or s3 or s4 and s5' is equivalent to: ' ((s1 and s2) or s3) or (s4 and s5)"
  • 's1 and s2 or (s3 or s4) and s5' is equivalent to: ' (s1 and s2) or ((s3 or s4) and s5)'; (2) Return all:
  • the special value '*' means "find everything", or "return all objects that exist beneath the selected starting container";
  • Property existence testing Property existence is queried for by using the 'exists' operator. Strictly speaking, 'exists' can be a unary operator. This searchCriteria syntax makes it a binary operator to simplify search string parsing — there are no unary operators.
  • the string "actor exists true” is true for every object that has at least one occurrence of the actor property. It is false for any object that has no actor property. Similarly, the string "actor exists false” is false for every object that has at least one occurrence of the actor property. It is true for any object that has no actor property;
  • Property omission Any property value query (as distinct from an existence query) applied to an object that does not have that property, evaluates to false.
  • A_ARG_TYPE_SortCriteria This variable is used in conjunction with those actions that include a SortCriteria parameter.
  • A_ARG_TYPE_SortCriteria is CSV list of signed property names, where signed means preceded by '+' or '-' sign. The '+' and '-' indicate the sort is in ascending or descending order, respectively, with regard to the value of its associated property. Properties appear in the list in order of descending sort priority. For example, a value of "+upnp:artist,-dc:date,+dc:title" would sort first on artist in ascending order, then within each artist by date in descending order (most recent first) and finally by title in ascending order. An empty string indicates no sorting requested.
  • A_ARG_TYPE_URI This variable is used in conjunction with any action that includes a URI parameter.
  • A_ARG_TYPE_URI variables must be properly escaped URIs as described in [RFC 2396] Tim Berners-Lee, et. al. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. 1998.
  • A_ARG_TYPE_XQuery This variable is used in conjunction with the XQuery and XUdate arguments used in ExecXQuery and ExecXUpdate actions.
  • A_ARG_TYPE_XQuery variables must be properly formatted using XQuery or XUpdate script.
  • the XQuery script is described inJXQuery].
  • the Xupdate script is available atJXUpdate] XUpdate Working Draft, XML: DB, XUpdate Working Group Working Draft, September 14, 2000. Available at http://xmldb- orq.sourceforqe.net/xupdate/xupdate-wd.html.
  • XQuery Engine must support: (1) XQuery 1.0 and XPath 2.0 Functions and Operators; (2) Full-text search;and (3) Restriction of output size.
  • LastUpdates This optional state variable is an ordered list of events. Each event consists of an MDObjectJD and an event type. The initial value of LastUpdates is the empty string.
  • the MDObjectJD is xml attribute which has a unique value. This attribute unambiguously refers to one xml-node.
  • LastUpdates is incremented with pair of the MDObjectJD and an event type.
  • LastUpdates is an evented state variable and is only used for eventing. There is no action that returns the value of LastUpdates.
  • LastUpdates is a history list of changes. When the LastUpdates has been evented, the value of LastUpdates is cleared (set to the empty string) before the newly changed 'MDObject_ID:eventType' is added to the list.
  • Table 5 shows a time-ordered sequence of activities on a Metadata Service for modifications.
  • Browse This action allows incremental browsing of the native hierarchy of the MDObject exposed by the MDS. For instance, in the current version of the specification, Browse() action enables incremental browsing of the TVA fragments, from TVAMain fragment, to Grouplnformation fragment,to Programlnformation fragment, and so on; and from TVA fragments to each individual elements of the specific TVA fragment.
  • the results of the Browse() action include the list of metadata returned in XML format, the total number of matches found in the database, and the total number of MDObjects returned.
  • CreateMDObject This action allows creation of a new MDS object in the container identified by CRID. Programlnformation is
  • ElementTagName, ElementPath, and ElementTagValue of each element to be created shall be enumerated in the order of 1 st ElementTagName, ElementPath, and ElementTagValue;
  • CreateElement allows creation of one or multiple new element within an MDObject. It provides finer granularity metadata creation compares to CreateMDObject.
  • DeleteMDObject This action destroys the specified metadata object when permitted.
  • DeleteElement Although this action may not be used frequently, for completeness we define this action here as well. It enables deletion of one or multimedia elements within an MDObject.
  • UpdateMDObject This action modifies MDS object.
  • the object to be updated is specified by MDObjectJD, ElementPath and ElementName. Multiple elements within an MDObject can be updated using a single UpdateMDObject action.
  • ExecXQuery This action takes a string of XQuery script, executes it, and returns result of the script. Similar to the Browse() action specified specified above, this action allows incremental browsing as well as query and retrieval of metadata through MDS. The difference lies in the tools used for the two actions. ExecXQuery() takes advantage of XQuery script to facilitate browsing and searching, while BrowseQ uses more generic browse and search tools much like the one used in CDS.
  • ExecXUpdate This action takes a string of XUpdate script, executes it, and returns old values of modified nodes.
  • Non-Standard Actions Implemented by a UPnP Vendor To facilitate certification, non-standard actions implemented by a UPnP vendor must be included in the device's service template.
  • the UPnP Device Architecture lists naming requirements for non-standard actions (cf. section on Description).
  • Table 7 lists error codes common to actions for this service type. If a given action results in multiple errors, the most specific error must be returned.
  • the Browse() action is designed to allow the control point to navigate the "native" metadata repository exposed by the MDS. This hierarchy could map onto an explicit physical hierarchy or a logical one. It also is designed to allow a control point to search for metadata and a fragment in the metadata repository that match a given search criteria.
  • the Browse() action enables the following features: (1) metadata only browsing and searching based search criteria; (2) root element browsing; (3) children object browsing; (4) fragment specific browsing (e.g., browse GrouplnformationTable); (5) incremental navigation (i.e., the full hierarchy is never returned in one call since this is likely to flood the resources available to the control point, including memory, network bandwidth, etc.); also, within a particular hierarchy level, the control point can restrict the number (and the starting offset) of elements returned in the result; (6) sorting: the result can be requested in a particular sort order; and (7) filtering, the result data can be filtered to only include a subset of the metadata available.
  • CreateMDObject The CreateMDObject() action is designed to allow a control point to create a fragment in the metadata repository.
  • the following example illustrates a typical CreateMDObject() request-response interaction between a control point and a MDS in some embodiments.
  • CreateEIement allows creation of one or multiple new element within an MDObject by a control point.
  • the following example illustrates a typical CreateElement() request-response interaction between a control point and a MDS.
  • DeleteMDObject The DeleteMDObject() action is designed to allow a control point to delete a fragment in the metadata repository.
  • the following example illustrates a typical DeleteMDObject() request-response interaction between a control point and a MDS.
  • UpdateMDObject The UpdateMDObject() action is designed to allow a control point to update a fragment or part of a fragment in the metadata repository.
  • the following example illustrates a typical UpdateMDObject() request-response interaction between a control point and a MDS.
  • ExecXQuery This action takes a string of XQuery script, executes it, and returns result of the script.
  • the following example illustrates a typical ExecXQuery() request-response interaction between a control point and a MDS.
  • ExecXUpdate This action takes a string of XUpdate script, executes it, and returns old values of modified nodes.
  • the following example illustrates a typical ExecXUpdate() request-response interaction between a control point and a MDS.
  • MDS implementation will always reside on an UPnP device.
  • various CRIDs and URIs present as metadata inside MDS may point to locations, e.g., web servers that are outside the UPnP network.
  • MDS system includes a common core set of metadata as defined in this specification to ensure a minimum level of interoperability. Backward and possibly forward compatibility shall be maintained.
  • the MPEG-7 Definition Description Language (DDL) that is used as the MDS representation language is the main instrument for extensibility - to allow vendor extend MDS metadata for vendor specific application for added functionality. The main principle is to use the namespace of the schema.
  • MDS extensions can include one or more metadata translation services.
  • Such services can support interoperability between different metadata standards, such as MPEG21 , TVA, etc.. They can also support access and exchange of different metadata between different sources and/or services; for example, given a non-TVA standard metadata, the service can translate it into TVA standard metadata.
  • a semantic translation service can be thesaurus-based and/or learning based, with examples being neural network- based and HMM-based. However, before turning attention to the metadata
  • a sample translation service architecture accomplishes a metadata bridging service system 30 between a first type of metadata in datastore 32 and a second type of metadata in datastore 34.
  • System 30 can include a metadata comparison module 36 providing comparison results to a metadata mapping module 38, which can employ a semantic analysis module 40 to produce or inform a metadata translation module 42.
  • system 30 can employ a pluggable metadata mapping heuristics database 43 provided and/or periodically informed by third party service providers 45.
  • Database 43 can provide rules for translating metadata between schemas.
  • database 43 can provide mapping principles defining metadata element to metadata element correspondence for two or more specified metadata schema and/or schema categories.
  • Bridging service 30 can therefore obtain a predefined mapping from database 43 based on two or more metadata schema to be bridged, and replace the database 43 as needed and as updates become available.
  • a metadata translation service 44 can function to provide schema translation and XML translation services. Once the mapping is obtained and/or established by metadata bridging service 30, metadata translation module 44 can apply the mapping template. Accordingly, the metadata translation module 44 takes input from the mapping module 38 in the form of a mapping template. The mapping module takes inputs from databases or other data sources providing sample metadata of different types in a comparative fashion. The automatic mapping is performed by the semantic analysis module 40. Semantic analysis module provides intelligent learning based mapping services with multiple paths (parallel) mapping and multiple iteration mapping.
  • the metadata type "genre type" 46 of one metadata schema can be mapped to the metadata type "genre” 48 of another metadata schema (e.g., UPnP properties: DIDL-Lite, DIDL- SRS, etc.) based on comparative semantic analyses of the metadata schema.
  • TVA metadata TVA schema
  • MPEG7 DDL MPEG7 DDL
  • the metadata mapping module can employ semantic analysis module 40 to generate a mapping between metadata of datastore 32 and metadata of datastore 34 that can identify one to one correspondences and many to one correspondences between metadata types of the metadata schema.
  • Mapping module 38 can alternatively or additionally employ database 43 to obtain part or all of a mapping provided by the third party service providers 45.
  • TVA metadata types 50 present in datastore 32 can be mapped to relatively fewer UPnP metadata types 52 present in datastore 34 as follows: (a) "genre type” of metadata types 50 can be mapped to "genre” of metadata types 52; (b) "title”, “media title”, and “short title” of metadata types 50 can all be mapped to "title” of metadata types 52; and (c) “synopsis", “promotional information", and "key word” of metadata types 50 can all be mapped to "description” of metadata types 52. If a predefined mapping template from datastore 43 is being used, it is still possible for mapping module 38 to employ the semantic analysis to supplement or correct the predefined mapping template when errors are encountered.
  • semantic analysis module 40 includes both an identification of similarity between tagged content, and an identification of similarity between tags.
  • tags For example, "title”, “media title”, and “short title” of metadata type 50 all contain the word “title”, which is identical to "title” of metadata type 52; thus, there is similarity between metadata tags.
  • semantic analysis engine can note that each of these metadata tags is used to tag the phrase “Gone with the Wind” in similar instances; thus, there is similarity between tagged content. Accordingly, the many to one correspondence mapping between the metadata types can be generated with a degree of accuracy.
  • mapping of "synopsis", “promotional information”, and "keyword" of metadata type 50 and "description" of metadata type 52 can be based on similarity between tagged content, and also based on process of elimination that includes an analysis of dissimilarity between tagged content of other metadata types.
  • some metadata types such as “description” of metadata type 52, can be identified as a “catch all", “miscellaneous", or “default” category based on its tendency to tag large amounts of varying types of content. Accordingly, metadata of type 50 that does not confidently map to any other metadata of type 52 can be mapped by default to the "description" metadata type.
  • an example translation service scenario translates at 54 an instance of TVA metadata 56 of datastore 32 to an instance of UPnP metadata 58 of datastore 34.
  • Semantic analysis module 40 generates a mapping 59 between TVA metadata type 59A and UPnP metadata type 59B.
  • the instance of TVA metadata 56 is then translated to the instance of UPnP metadata based on the mapping 59.
  • the metadata mapping module 38 employs semantic analysis module 40 in a multi-pass, multi-iteration mapping process to map TVA metadata property "x" 60 to UPnP base property 62 and UPnP associated property 64.
  • module 38 employs module 40 to search for equivalence by semantic analysis in a first level of metadata (e.g., base property) at R1-1 and returns "no mapping found" at R1-2.
  • a first level of metadata e.g., base property
  • second pass equivalence is searched for in a second level of metadata (e.g., associated property) at R1-3, with "no mapping found" being returned at R1-4.
  • multi-metadata set 70 can be mapped to single metadata set 72 by metadata mapping module 38 employing semantic analysis module 40.
  • TVA metadata 7OA and DV metadata 7OB of set 70 are mapped with UPnP metadata of set 72 at S1 and S2.
  • metadata translation module 44 translates metadata 7OA and 7OB to metadata of set 72 at S3, S4, and S5.
  • metadata mapping module 38 can employ semantic analysis engine 40 to provide a mapping to metadata translation module 44 and provide bidirectional metadata translation services.
  • TVA metadata 7OA and DV metadata 7OB are mapped with UPnP metadata of set 72 at T1 and T1 '.
  • TVA metadata 7OA is translated to UPnP metadata of set 72 at T2 and T3
  • UPnP metadata of set 72 is translated to DV metadata 7OB at T4 and T5.
  • some embodiments of the present invention can perform bidirectional metadata translation.
  • the description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. Such variations are not to be regarded as a departure from the spirit and scope of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système de service de métadonnées (14) qui comporte un magasin d'objets sous forme de métadonnées. Un module de recherche et de navigation est adapté pour recevoir une demande de recherche provenant d'un point de commande (10) et renvoie au moins une partie d'un ou plusieurs objets sous forme de métadonnées au point de commande sur la base d'un identificateur de référence de contenu spécifié par la demande de recherche. Ledit système de service de métadonnées (14) est adapté pour informer le point de commande de son existence et de ses capacités en participant en tant que service à un protocole de découverte de service. Dans d'autres modes de réalisation, des modules de mise à jour (20), de création (16) et d'effacement (22) fournissent des fonctions complémentaires.
PCT/US2005/024503 2004-07-09 2005-07-08 Service de metadonnees WO2006010107A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US58730504P 2004-07-09 2004-07-09
US60/587,305 2004-07-09

Publications (1)

Publication Number Publication Date
WO2006010107A1 true WO2006010107A1 (fr) 2006-01-26

Family

ID=35785577

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/024503 WO2006010107A1 (fr) 2004-07-09 2005-07-08 Service de metadonnees

Country Status (1)

Country Link
WO (1) WO2006010107A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2044771A2 (fr) * 2006-07-24 2009-04-08 NDS Limited Système de décodeur poste à poste
EP2057574A1 (fr) * 2006-08-25 2009-05-13 Samsung Electronics Co., Ltd. Procédé, dispositif av dépendant d'un pc et système de réseau de rattachement destiné à exécuter un contenu av en unités de segmentation
US10853356B1 (en) 2014-06-20 2020-12-01 Amazon Technologies, Inc. Persistent metadata catalog
CN112817764A (zh) * 2021-02-08 2021-05-18 网易（杭州）网络有限公司 虚拟资源处理的方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040031058A1 (en) * 2002-05-10 2004-02-12 Richard Reisman Method and apparatus for browsing using alternative linkbases
US6862594B1 (en) * 2000-05-09 2005-03-01 Sun Microsystems, Inc. Method and apparatus to discover services using flexible search criteria

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6862594B1 (en) * 2000-05-09 2005-03-01 Sun Microsystems, Inc. Method and apparatus to discover services using flexible search criteria
US20040031058A1 (en) * 2002-05-10 2004-02-12 Richard Reisman Method and apparatus for browsing using alternative linkbases

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2044771A2 (fr) * 2006-07-24 2009-04-08 NDS Limited Système de décodeur poste à poste
EP2057574A1 (fr) * 2006-08-25 2009-05-13 Samsung Electronics Co., Ltd. Procédé, dispositif av dépendant d'un pc et système de réseau de rattachement destiné à exécuter un contenu av en unités de segmentation
EP2057574A4 (fr) * 2006-08-25 2014-02-19 Samsung Electronics Co Ltd Procédé, dispositif av dépendant d'un pc et système de réseau de rattachement destiné à exécuter un contenu av en unités de segmentation
US10853356B1 (en) 2014-06-20 2020-12-01 Amazon Technologies, Inc. Persistent metadata catalog
US11886429B2 (en) 2014-06-20 2024-01-30 Amazon Technologies, Inc. Persistent metadata catalog
CN112817764A (zh) * 2021-02-08 2021-05-18 网易（杭州）网络有限公司 虚拟资源处理的方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
US8055676B2 (en) Method for providing requested fields by get—Data operation in TV-anytime metadata service
US7844644B2 (en) Method and apparatus for managing data written in markup language and computer-readable recording medium for recording a program
CN100444635C (zh) TV-Anytime元数据服务中的利用了get_Data操作的请求域提供方法
US20090187837A1 (en) Declaratively composable dynamic interface framework
KR100534604B1 (ko) 티브이-애니타임 표준을 지원하는 멀티미디어 검색 및지능화 서비스 시스템
WO2006010107A1 (fr) Service de metadonnees
JP2004537775A (ja) 拡張可能な命令システム
KR100679314B1 (ko) ＳＯＡＰ　오퍼레이션을　이용한　ＴＶ－Ａｎｙｔｉｍｅ　메타데이터　배포　방법
JP5114547B2 (ja) Ｓｏａｐオペレーションを用いた問合せコンテンツサービス方法
US20030005128A1 (en) Service access system
KR100696949B1 (ko) ＴＶ－Ａｎｙｔｉｍｅ　서비스에서　ｇｅｔ＿Ｄａｔａ　오퍼레이션을　이용한　필드단위　검색 방법
EP3726845A1 (fr) Système et procédé de recherche de données de guide de programme électronique
Shin A storage and retrieval method of XML-based metadata in PVR environment
KR100590028B1 (ko) 포터블 미디어 플레이어를 위한 컨텐츠 리스트의 생성 및관리 방법
Timmerer et al. Digital item adaptation–coding format independence
Miao et al. A semantic metadata infrastructure for UPnP AV to maximize quality of user experience
Carvalho et al. A unified data model and system support for the context-aware access to multimedia content.
Sony et al. ContentDirectory: 1 Service Template Version 1.01
Echostar et al. ScheduledRecording: 2 Service
Evain et al. TV‐anytime phase 1 and MPEG‐7
GB2479925A (en) System for providing metadata relating to media content
Allegrosoft et al. ContentDirectory: 2 Service Template Version 1.01
Castro et al. A unified data model and system support for the context-aware access to multimedia content
Petersen Personalized DVB-H service discovery beyond 3G
Allegrosoft et al. ScheduledRecording: 1 Service Template Version

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase