WO2006010107A1 - Metadata service - Google Patents

Abstract

A metadata service system (14) includes a datastore of metadata objects. A search and search and browsing module is adapted to receive a search request from a control point (10) 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 (14) is adapted to inform the control point of its existence and capabilities by participating as a service in a service discovery protocol. In other aspects, update (20), create (16) , and delete (22) modules provide complimentary functions.

Description

METADATA SERVICE

FIELD OF THE INVENTION

[0001] The present invention generally relates to a general architecture of an XML-based metadata service and its extensions.

BACKGROUND OF THE INVENTION

[0002] 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.

[0003] 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.). Existing UPnP CDS service provides metadata listing strongly related with program information MD, program location MD, and other content item specific MD. However, there are no existing provisions for consumer metadata support, segmentation metadata, DRM-related metadata, or group information-related MD. Moreover, existing XML-based home control frameworks (e.g., UPnP) have no support for a TV Anytime (TVA) metadata distribution model within a home network. Though some TVA metadata overlaps semantically with the UPnP AV metadata, the majority of the TVA metadata types are missing from the UPnP AV architecture.

[0004] There remains a need for a way to bridge this gap between UPnP metadata types and the distribution model for TVA metadata and other metadata. The present invention fulfills this need. SUMMARY OF THE INVENTION

[0005] 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.

[0006] Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:

[0008] Figure 1A is a block diagram illustrating a metadata service architecture in accordance with the present invention;

[0009] Figure 1B is a block diagram illustrating inheritance of TVA document metadata structure in accordance with the present invention;

[0010] Figure 1C is a block diagram illustrating MDS fragment (MDObject) hierarchy in accordance with the present invention; [0011] Figure 2 is a block diagram illustrating a metadata bridging service and metadata translation service in accordance with the present invention;

[0012] Figure 3 is a block diagram illustrating generation of a mapping between metadata sets in accordance with the present invention; [0013] Figure 4 is a block diagram illustrating an example translation service scenario in accordance with the present invention; [0014] Figure 5 is a block diagram illustrating a multi-pass, multi- iteration metadata mapping process in accordance with the present invention;

[0015] 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; and

[0016] 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.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] The following description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.

[0018] The metadata service (MDS) according to the present invention 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. For example, 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.

[0019] 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

[0020] In some embodiments, the present invention is an XML Device Control Framework (e.g., UPnP)-discoverable and controllable TVA metadata service. 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.

[0021] In some embodiments, 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.

[0022] 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). [0023] The following features are gained from UPnP-based TVA metadata deployment: (1 ) metadata discovery; (2) metadata distribution control within a home; and (3) metadata state change eventing. With respect to 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. With respect to metadata distribution control within a home, 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)). In relation to metadata state change eventing, subscribers can be notified about changes in metadata state, with these events also capable of being moderated.

[0024] Referring to Figure 1 , the metadata service architecture according to some embodiments of the present invention can include a control point 10 interacting with a content directory service (CDS) 12 and the metadata service system 14. First, 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. Second, 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. According to the create method 16, 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. According to the browse method 18, 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.. According to the update method 20, 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. According to the delete method 22, 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.

[0025] 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. 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. In contrast, MDObjectJD references specific MDS metadata objects. The MDObjectJD created by MDS is unique per each existing MDS object. In some embodiments, the MDObjectJD can use a GRID + {D#} association to insure uniqueness. In a preferred embodiment, the MDS has a simple referencing model, {int}.

[0026] Table 1 summarizes currently available set of terms utilized herein.

Table 1. Terms

[0027] Turning now to Figure 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.

[0028] 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.

[0029] 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. [0030] 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).

Various components of the 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.

[0031] A third category of metadata called consumer metadata 106 includes usage history 106B data (logging data), annotation metadata, and user preferences 106A.

[0032] 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. 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.

[0033] There is also the possibility that the segmentation metadata 108 could be updated over time. If the metadata 108 changes between selection and playback, it may be necessary to use version or timestamp information to present useful information to the user. For example the highlights may be changed if one of the players in the match is later named as the best player of the tournament. [0034] MDObject is defined as a reference to any metadata segment that can be returned by Metadata services. In some embodiments, 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).

[0035] 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. [0036] A number of normative TVA fragment types have been defined as follows: (1 ) Root fragment: (a) TVAMain 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; (c) OnDemandProgram and OnDemandService fragment are used for the description of on-demand instances of contents; (d) BroadcastEvent fragment and Schedule fragment are used for the description of broadcast instances of contents and of the services where they are available; (e) OnDemandProgram, OnDemandService, BroadcastEvent, and Schedule are children elements of ProgramLocationTable element; (f) Servicelnformation fragment contains details about a single Service within a broadcast system. Servicelnformation is a direct child element of ServicelnformationTable; (g) PersonName and OrganisationName fragments are for the Creditlnformation metadata, and are children of CreditlnformationTable element; (h) Review fragment is to contain review of a given content, and is a direct child element of ProgramReviewTable; (i) 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.

[0037] Turning now to Figure 1 C, a MDObject hierarchy according to some embodiments 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. In turn, the child MDObjects 114A-114E, each comprise a subtree. For example, 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. [0038] The introduction of MDObject enables flexibility for future metadata extension and interoperability. Table 2 lists fragment_type ID defined in TVA, to identify the type of TVA fragments. MDS inherits these ID values for interoperability.

Table 2. fragmentjype assignments

Value Description

[0039] In terms of schema, MDS adopts XML Schema as the common representation format for documentation of metadata. In some embodiments, 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.

[0040] In terms of namespaces, MDS is fully interoperable with TV- anytime schema which is based on DDL. In some embodiments, 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". [0041] In terms of 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.

<simpleType name="MDObject_ID"> <restriction base="string"> </restriction> </simpleType>

<simpleType name="CRIDType"> <restriction base="anyURI">

<pattern value="(c|C)(r|R)(i|l)(d|D)://.*/.^*7> </restriction> </simpIeType>

Table 3. MDS basic types

Name Definition

MDObjectJD A simple type used to indicate uniqueness of a metadata fragment within a metadata description

CRIDType A type to represent a GRID as a URI reference

[0043] In a number of instances, 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. [0044] In terms of 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

Vaπab e Name Req. Data Allowed Default Eng. or Opt. Type Value Value Units

R = Required, O = Optional, X = Non-standard.

[0045] 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.

[0046] 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. [0047] 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.

[0048] 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.

[0049] 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. In some embodiments, 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.

<TVAMain xmlns="um:tva:metadata:2002" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="um:tva:metadata:2002 schemas/tvajnetadata_v13.xsd" version="03" xml:lang="en" publisher="..." publicationTime="2001-04-05T21 :00:00.00+01 :00"> <CopyrightNotice>...</CopyrightNotice> <ProgramDescription>

<ProgramlnformationTable>...</ProgramlnfornnationTablθ>

</ProgramDescription>

<UserDescription>

<UserPreferences>...</UserPreferences> <UsageHistory>...</UsageHistory>

</UserDescription> </TVAMain>

<TVAMain version="03" xml:lang="en" publisher=".." publicationTime=".."> <ProgramDescription>

<ProgramlnformationTable>...</ProgramlnformationTablθ> </ProgramDescription> </TVAMain>

[0050] A_ARG_TYPE_SearchCriteria: 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.

[0051] SearchCriteria String Syntax: 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 | searchExp wChar÷ logOp wChar+ searchExp |

'C wChar* searchExp wChar* ')' logOp ::= 'and' | Or' relExp property wChar+ binOp wChar+ quotedVal property wChar+ existsOp wChar+ boolVal binOp relOp I stringOp relOp ^■=' i M=¹ J ^■<^■ J ^■<=^■ J ^■>^■ i ^■>=^• stringOp ::= 'contains' | 'doesNotContain' | 'derivedfrom' existsOp ::= 'exists' boolVal ::= 'true' | 'false' quotedVal ::= dQuote escapedQuote dQuote wChar ::= space | hTab | lineFeed | vTab I formFeed | return property ::= (* property name as defined in section 2.4 in

[[0051] ]*) escapedQuote ::= (* double-quote escaped string as defined in section 2.3.1 in [[0051] ] *) hTab ::= (* UTF-8 code 0x09, horizontal tab character *) lineFeed ::= (* UTF-8 code OxOA, line feed character *) vTab ::= (* UTF-8 code OxOB, vertical tab character *) formFeed ::= (* UTF-8 code OxOC, form feed character *) return ::= (* UTF-8 code OxOD, carriage return character *) space ::= ' ' (* UTF-8 code 0x20, space character *) dQuote ::= "" (* UTF-8 code 0x22, double quote character *) asterisk ::= '*' (* UTF-8 code 0x2A, asterisk character *)

[0052] SearchCriteria String Semantics and Examples:

(1 ) Operator precedence:

Precedence, highest to lowest, is: dQuote

( ) binOp, existsOp and or

Examples: '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";

(3) 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; (4) 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.

(5) Numeric comparisons: When the operator in a relExp is a relOp, and both the escapedQuote value and the actual property value are sequences of decimal digits or sequences of decimal digits preceded by either a '+' or '-' sign (i.e., integers), the comparison is done numerically. For all other combinations of operators and property values, the comparison is done by treating both values as strings, converting a numeric value to its string representation in decimal if necessary. It should be noted that, in some embodiments, the MDS is not expected to recognize any kind of numeric data other than decimal integers, composed only of decimal digits with the optional leading sign;

(6) String comparisons: All operators when applied to strings use case- insensitive comparisons.

[0053] 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.

[0054] 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.

Available at: http://www.ietf.org/rfc/rfc2396.txt.

[0055] 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.

[0056] 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.

[0057] 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.

Each time a node with the MDObjectJD attribute is modified, its 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.

[0058] As an example, Table 5 shows a time-ordered sequence of activities on a Metadata Service for modifications.

Table 5. LastUpdates Example

[0059] In terms of actions, the following tables and subsections define the various MDS actions. Except where noted, if an invoked action returns an error, the state of the device will be unaffected.

Table 6. Actions

[0060] 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 Browse() action also enables query and retrieval of metadata based on search criteria, such as "GRID = crid://tvaroot/movies/title1". It enables browsing of metadata associated with a particular MDObject, a specific GRID, or a special search criterion, such as 'browsing a group of objects.' It also facilitates searching of specific metadata based on known information such as content title, GRID, creator, E-flyer information, and etc. Query and search results shall be limited by the 'Filter' argument.

[0061] 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.

[0062] All input arguments are designed to be optional. When zero input argument is given, depending on the resource, such as memory and network bandwidth, availability, incremental browsing of the native hierarchy maybe returned portion by portion.

[0063] CreateMDObject: This action allows creation of a new MDS object in the container identified by CRID.

Programlnformation is

/tva:TVAMain/tva:Pr ogramDescription

/tva: Programl nforma tionTable/ tva:Programlnformat ion

NumOfElements IN ui4 R Number of elements to be created within the MDObject (fragment.) The ElementTagName, ElementPath, and ElementTagValue of each element to be created shall be enumerated in the order of 1^st ElementTagName, ElementPath, and ElementTagValue;

ElementTagName, ElementPath, and ElementTagValue; and so on so forth. The elements on a specific level needs not to be inputted in any particular order since the

[0064] CreateElement: CreateElement allows creation of one or multiple new element within an MDObject. It provides finer granularity metadata creation compares to CreateMDObject.

[0065] DeleteMDObject: This action destroys the specified metadata object when permitted.

[0066] 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.

[0067] 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.

argument type data Req description Com¬ type or ments

[0068] 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.

[0069] ExecXUpdate: This action takes a string of XUpdate script, executes it, and returns old values of modified nodes.

[0070] 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).

[0071] Common Error Codes: 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.

Table 7. Common error codes

Error Error Description Code Description

Error Error Description

[0072] In order to demonstrate the theory of operation of some embodiments of the MDS, several scenarios are presented below to illustrate the various actions supported by the MDS. These include browsing, searching, creation, update, and deletion.

[0073] Attention is first given to content setup for browsing and searching. In terms of browsing, 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.

[0074] The following examples illustrate a typical Browse() request- response interaction between a control point and a MDS in some embodiments. They assume a particular content setup.

[0075] Browse purchased to play forever content and purchase info:

Request: Browse(" ", "0", "1", "PurchaseType=PlayForever", "Programlnformation; Purchaselnformation", " ") Response: Browse( "<?xml version="1.0"?> <TVAMain xml:lang="en" xmlns="um:tva:metadata:2002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="um:tva:metadata:2002 tva_metadata_v13_am1.xsd"> <ProgramDescription>

<ProgramlnformationTable>

<Programlnformation programld^'crid^/www.vituralMDS.com/TVA /content-i¹^

<Purchaselnformation purchaseld="p1 " start="2004-09-07T00:00:00" end="2004-09-07T00:00:00">

<PriceType href="urn:tva:metadata:cs:PriceTypeCS"> <Name>standard</Name> </PriceType>

<Price currency="USD">20.00</Price> <Purchase> <PurchaseType href="um:tva:metadata:cs:PurchaseTypeCS"> <Name>PlayForever</Name> </PurchaseType> </Purchase> </Purchaselnformation> ...

</Programlnformation>

<Programlnformation programld="crid://www.vituralMDS.com/TVA /content-9">

<Purchasel information purchaseld="p9" start="2004-09-17T00:00:00" end="2004-09-17T00:00:00">

<PriceType href^'urnitvaimetadataicsPriceTypeCS'^

<Name>discount</Name>

</PriceType> <Price currency="USD">12.00</Price>

<Purchase>

<PurchaseType href="urn:tva:metadata:cs:PurchaseTypeCS">

<Name>PlayForever</Name>

</PurchaseType> </Purchase>

</Purchasθlnformation>

</Programlnformation> </ProgramlnformationTable> </ProgramDescription> «/TVAMain>", 2, 2) [0076] Browse Title with group GRID:

Request: Browse(" ", "4", "1", "CRID://tvaroot/movies", "title", " " )

Response: Browse(

"<?xml version="1.0"?> <TVAMain xml:lang="en" xmlns="urn:tva:metadata:2002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2002 tva_metadata_v13_am1.xsd">

<ProgramDescription> <ProgramlnformationTable>

<Programlnformation>

<BasicDescription>

<Title type="main">Fight club</Title> </BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title type="main">Dogma</Title> </BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title type="main">Ella Enchanted</Title> </BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title type="main">Batman</Title> </BasicDescription> </Programlnformation>

</ProgramlnformationTable> </ProgramDescription> </TVAMain> ", 1 , 1 )

[0077] Browse CRID of movie "Sleepless in Seattle":

Request: Browse(" ", "4", "1", "title="Sleepless in Seattle"", "CRID, title, genre ", a » \

Response: Browse( "<?xml version="1.0"?>

<TVAMain xml:lang="en" xmlns="um:tva:metadata:2002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="um:tva:metadata:2002 tva_metadata_v13_am1.xsd"> <ProgramDescription> <ProgramlnformationTable>

<Programlnformation programld="CRID://www.vituralMDS.com/TVA/movie/SleeplessinSeattle"> <BasicDescription>

<Title type="main">Sleepless in Seattle</Title> <Genre type="main">

<Name>drama</Name> </Genre>

</BasicDescription> </Programlnformation> </ProgramlnformationTable> </ProgramDescription> </TVAMain> ", 1 , 1 )

[0078] Browse only required metadata of program information with

GRID: Request: Browsef ", "1", "0",

"CRlD://www.vituralMDS.com/TVA/movie/SleeplessinSeattle ", "Programlnformation", " " ) Response: Browse( "<?xml version="1.0"?>

<TVAMain xml:lang="en" xmlns="urn:tva:metadata:2002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2002 tva_metadata_v13_am1.xsd"> <ProgramDescription> <ProgramlnformationTable> <Programlnformation programld='^lCRID://www.vituralMDS.com/TVA/movie/SleeplessinSeattle^II> <BasicDescription>

</BasicDescription>

</Programlnformation>

</ProgramlnformationTable>

</ProgramDescription>

</TVAMain> ", 1 , 1)

[0079] Browse all available metadata of program information with

CRID:

Request: Browse(" ", "1", "1", "CRID://www.vituralMDS.com/TVA/movie/SleeplessinSeattle",

"Programlnformation", " " )

Response: Browse(

"<?xml version="1.0"?>

<TVAMain xml:lang="en" xmlns="urn:tva:metadata:2002" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="um:tva:metadata:2002 tva_metadata_v13_am1.xsd">

<ProgramDescription> <ProgramlnformationTable> <Programlnformation> <BasicDescription>

<Title type="main">Sleepless in Seattle</Title> <Promotionallnformation>

</Promotionallnformation> <keyword>love</keyword> <Genre type="main"> <Name>drame</Name>

</Genre>

<Language>English</Language> <CaptionLanguage>French< CaptionLanguage>

</BasicDescription> <AVAttributes>

</AVAttributes> <MemberOf>

</MemberOf> <AggregationOf>

</AggregationOf> </Programlnformation>

</ProgramlnformationTable>

</ProgramDθscription>

</TVAMain>

", 1 , 1)

[0080] Browse purchase information along with program information and group information with CRID: Request: Browse(" ", "1", "1", "crid://shop.jp/terminator/episode3", "Programlnformation, Grouplnformation, Purchaselnformation", " " ) Response: Browse( "<?xml version="1.0"?> <TVAMain xml:lang="ja" xmlns="um:tva:metadata:2004" xmlns:mpeg7="um:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2004 ./tva_metadata_y13_am2+eflyer.xsd"> <ProgramDescription>

<ProgramlnformationTable> <Programlnformation programld="crid://shop.jp/ternninator/episode3"> <BasicDescription> <Title type="main">Terminator 3</Title>

<Synopsis>Fox goes to Washington and jumps in the

Potomac</Synopsis> <Keyword>Fox</Keyword>

<Genre href="um:tva:metadata:cs:FormatCS:3.2.1.7" type="main"/> <MDObject_ID> shop.jp/terminator/episode3/Programlnformation</MDObject_ID >

</BasicDescription>

<MemberOf crid="crid://shop.jp/terminator_all" xsi:type="MemberOfType" />

</Programlnformation> </ProgramlnformationTable> <GrouplnformationTable>

<Grouplnformation groupld="crid://shop.jp/terminator_all"> <GroupType xsi:type="ProgramGroupTypeType" value="series" /> <BasicDescription> <Title type="main">Terminator(1 -3)</Title>

<Genre href="um:tva:metadata:cs:FormatCS:3.2.1.7" type="main"

/>

<MDObject_ID> shop.jp/terminator/episode3/Groupinformation</MDObject_ID>

<ReIatedMaterial> <HowRelated href="urn:tva:metadata:cs:HowRelatedCS" > <Name>Supplier</Name>

</HowRelated> <MediaLocator>

<mpeg7:MediaUri>http://shop.jp/</mpe g7:MediaUri>

</Medial_ocator> </RelatedMaterial> <PurchaseList>

<Purchaseltem start="2001-04- 07T19:00:00.00+01 :00" end="2001-04-

10T19:00:00.00+01 :00"> <PriceType href="urn:tva:metadata:cs:PriceTypeC S"> <Name>Standard</Name>

</PriceType> <Price currency="JPY" unit="Yen">2000</Price> <Purchase> <PurchaseType href="urn:tva:metadata:cs:Purcha seTypeCS"> <Name>PlayForPeriod</Name> </PurchaseType> <QuantityUnit href="urn:tva:metadata:cs:UnitTyp eCS">

<Name>Month</Name> </QuantityUnit> <QuantityRange max="1" /> </Purchase> </Purchaseltem>

</PurchaseList> </BasicDescription> </Grouplnformation> </GrouplnformationTable> </ProgramDescription>

</TVAMain>", 1 ,1 )

[0081] 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.

[0082] Create MDObject with GRID:

Request: CreateMDObject("", "crid=crid://shop.jp/terminator/episode2",

"Programlnformation", /tvaiTVAMain/tvaProgramDescription/tvaProgramlnformationTable/tvaProgram

Information", "4", "Programlnformation",

'VtvaiTVAMain/tvaProgramDescription/tvaProgramlnformationTable/tvaProgra mlnformation", "programld="crid://shop.jp/terminator/episode2", "0",

"BasicDescription", 'VtvaiTVAMain/tvaProgramDescription/tvaProgramlnformationTable/tvaProgra mlnformation/tvaiBasicDescription", "0", "0", "Title",

'VtvaiTVAMain/tvaProgramDescription/tvaProgramlnformationTable/tvaiProgra mlnformation/tvaiBasicDescription/Title", "type="main"", "Terminator 2", "MembθrOf",

"/tvaiTVAMain/tvaProgramDescription/tvaProgramlnformationTable/tvaiProgra mlnformation/tva:MemberOf , "crid="crid://shop.jp/terminator_all¹¹", "0", "1") Response: CreateMDObject(

" "shop.jp/terminator/episode2/Programlnformation",

"<?xml version="1.0"?>

<TVAMain xml:lang="ja" xmlns="um:tva:metadata:2004" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2004 ./tva_metadata_v13_am2+eflyer.xsd"> <ProgramDescription>

<ProgramlnformationTable> <Programlnformation programld="crid://shop.jp/terminator/episode2"> <BasicDescription>

<Title type="main">Terminator 2</Title> </BasicDescription> <MemberOf crid="crid://shop.jp/terminator_all"/>

</Programlnformation> <Programlnformation programld="crid://shop.jp/terminator/episode3"> <BasicDescription> <Title type="main">Terminator 3</Title>

<Synopsis>Fox goes to Washington and jumps in the

Potomac</Synopsis> <Keyword>Fox</Keyword>

<Genre href="urn:tva:metadata:cs:FormatCS:3.2.1.7" type="main"/> <MDObject_ID> shop.jp/terminator/episode3/Programlnformation</MDObject_ID </BasicDescription>

<MemberOf crid="crid://shop.jp/terminator_aH" xsi:type="MemberOfType" /> </Programlnformation> </ProgramlnformationTable>

</ProgramDescription> </TVAMain>"

[0083] CreateEIement: CreateElement() action 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.

[0084] Create new element with MDObjectJD:

Request: CreateElement("shop.jp/terminator/episode3/Programlnformation", "Language", "0",

'VtvaiTVAMain/tvaiProgramDescription/tvaProgramlnformationTable/tvaProgra mlnformation ", "En", "0") Response: CreateElement( "<?xml version="1.0"?> <TVAMain xml:lang="ja" xmlns="urn:tva:metadata:2004" xmlns:mpeg7="um:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2004 ./tva_metadata_v13_am2+eflyer.xsd"> <ProgramDescription>

<ProgramlnformationTable> <Programlnformation programld="crid://shop.jp/terminator/episode3"> <BasicDescription> <Title type="main">Terminator 3</Title> <Synopsis>Fox goes to Washington and jumps in the

Potomac</Synopsis> <Keyword>Fox</Keyword>

<Genre href="urn:tva:metadata:cs:FormatCS:3.2.1.7" type="main"/> <Language>En</Language>

<MDObject_iD> shop.jp/terminator/episode3/Programlnformation</MDObject_ID

>

</BasicDescription> <MemberOf crid="crid://shop.jp/terminator_all" xsi:type="MemberOfType" /> </Programlnformation> </ProgramlnformationTable> </ProgramDescription> </TVAMain>"

[0085] 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.

[0086] Delete an MDObject with MDObjectJD:

Request: DeleteMDObject("shop.jp/terminator/episode2/Programlnformation", "Programlnformation",

'VtvaTVAMain/tvaiProgramDescription/tvaProgramlnformationTable/tvaProgra mlnformation ", "0")

Response: DeleteMDObject(O)

The metadata will change from: <?xml version="1.0"?> <TVAMain xml:lang="ja" xmlns="urn:tva:metadata:2004" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2004 ./tva_metadata_v13_am2+eflyer.xsd"> <ProgramDθscription> <ProgramlnformationTable>

<Programlnformation programld="crid://shop.jp/terminator/episode2"> <BasicDescription>

<Title type="main">Terminator 2</Title> <MDObject_ID> shop.jp/terminator/episode2/Programlnformatio n

</MDObject_ID> </BasicDescription> <MemberOf crid="crid://shop.jp/terminator_all"/>

</Programlnformation> <Programlnformation programld="crid://shop.jp/terminator/episode3"> <BasicDescription> <Title type="main">Terminator 3</Title>

<Synopsis>Fox goes to Washington and jumps in the

Potomac</Synopsis> <Keyword>Fox</Keyword>

<Genre href="urn:tva:metadata:cs:FormatCS:3.2.1.7" type="main"/> <MDObject_ID> shop.jp/terminator/episode3/Programlnformation</MDObject_ID >

</BasicDescription>

<MemberOf crid="crid://shop.jp/terminator_aH" xsi:type="MemberOfType" />

</Programlnformation> </ProgramlnformationTable> </ProgramDescription> </TVAMain> to:

<?xml version="1.0"?> <TVAMain xml:lang="ja" xmlns="urn:tva:metadata:2004" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:tva:metadata:2004 ./tva_metadata_v13_am2+eflyer.xsd"> <ProgramDθscription>

<ProgramlnformationTable> <Programlnformation programld="crid://shop.jp/terminator/episode3"> <BasicDescription> <Title type="main">Terminator 3</Title>

<Synopsis>Fox goes to Washington and jumps in the

Potomac</Synopsis> <Keyword>Fox</Keyword>

<Genre href="urn:tva:metadata:cs:FormatCS:3.2.1.7" type="main"/> <MDObject_ID> shop.jp/terminator/episode3/Programlnformation</MDObject_ID >

</BasicDescription>

<MemberOf crid="crid://shop.jp/terminator_all" xsi:type="MemberOfType" />

</Programlnformation> </ProgramlnformationTable> </ProgramDescription> </TVAMain>

[0087] 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.

[0088] Update an element (the price of a content) with CRID:

Request: UpdateMDObjectf", "crid://shop.jp/terminator/episode2", "Price",

'VtvaTVAMain/tva-ProgramDescription/tvaProgramlnformationTable/tvaProgra mlnformation/tva:BasicDescription/tva:PurchaseList/tva:Purchaseltem/tva:Price",

"0", "8.00", "6.00")

Response: UpdateMDObject(O) Before update:

<TVAMain xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001 ">

<ProgramDescription>

<ProgramlnformationTable>

<Programlnformation> <BasicDescription>

<Title type="main">Fight club</Title>

<PurchaseList>

<Purchaseltem start="2001-04-07T19:00:00.00+01 :00" end="2001-04-

10T19:00:00.00+01 :00"> <Price currency="US" unit="USD">8</Price>

<Purchase>

<PurchaseType href="urn:tva:metadata:cs:PurchaseTypeCS">

<Name>PlayForPeriod</Name>

</PurchaseType> </Purchase>

</Purchaseltem>

</PurchaseList>

</BasicDescription>

</Programlnformation> </ProgramlnformationTable>

</Program Description>

</TVAMain> After update:

<TVAMain xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001 ">

<ProgramDescription> <ProgramlnformationTabIe>

<Programlnformation>

<BasicDescription>

<Title type="main">Fight club</Title>

<PurchaseList> <Purchaseltem start="2001-04-07T19:00:00.00+01 :00" end="2001-04-

10T19:00:00.00+01 :00">

<Price currency="US" unit="USD">6</Price>

<Purchase>

<PurchaseType href="urn:tva:metadata:cs:PurchaseTypeCS"> <Name>PlayForPeriod</Name>

</PurchaseType>

</Purchase>

</Purchaseltem>

</PurchaseList> </BasicDescription>

</Programlnformation>

</ProgramlnformationTable>

</Program Description>

</TVAMain>

[0089] 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.

[0090] Browse a program group:

Request: ExecXQuery( "For $p ln

/TVAMain/ProgramDescription/ProgramlnformationTable/Programlnformation [./MemberOf/@crid = 'crid://tvaroot/movies'] Where $p/Genre/Name/text() = 'Fantasy' Return $p//Title"

)

Response:

"<TVAMain>

<Program Description> <ProgramlnformationTable>

<Programlnformation>

<BasicDescription>

<Title> Batman </Title>

</BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title> Lord of Rings </Title>

</BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title> Spiderman </Title>

</BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription>

<Title> Avalon </Title>

</BasicDescription> </Programlnformation>

<Programlnformation>

<BasicDescription> </BasicDescription> </Programlnformation> </ProgramlnformationTable> </Program Description> </TVAMain>"

[0091] 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.

[0092] Modify a program title:

Request: ExecXUpdate(

"UPDATE REPLACE

/TVAMain/ProgramDescription/ProgramlnformationTable/Programlnformationt© programld = 'crid://tvaroot/movies/Batman']//Title/text()

WITH

'New Title of Batman' " )

Response:

"<TVAMain>

<Program Description>

<ProgramlnformationTable> <Programlnformation>

<BasicDescription>

<Title> Batman Il </Title>

</BasicDescription>

</Programlnformation> </ProgramlnformationTable>

</Program Description> </TVAMain>"

[0093] Internet Content Representation: In some embodiments, a

MDS implementation will always reside on an UPnP device. However, various CRIDs and URIs present as metadata inside MDS may point to locations, e.g., web servers that are outside the UPnP network.

[0094] Vendor Metadata Extensions: In some embodiments, 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.

[0095] XML Service Description:

<?xml version="1.0"?>

<scpd xmlns="um:schemas-upnp-org:service-1-0"> <specVersion> <maior>1</major> <minor>0</minor> </specVersion> <actionList> <action>

<name> B rowse</name> <arqumentList>

<arqument>

</arqument>

<argurnent> < name> Res u lt</name> <direction>out</direction>

</arqument> </arqumentList>

</action> <action> <name>Search</name>

<arqumeπtList>

</arqumentList> </action> <action> <name>Create</name>

<arqumentList>

</arqumentList> </action> <action> <name>Delete</name>

<arqumentList>

</arqumentList>

</action> <action> <name> U pd ate</name>

<arqumentList>

</arqumentList> </action> </actionlist> </scpd>

[0096] Now that some presently preferred embodiments of the MDS have been described, attention is now given to some embodiments of a metadata translation service architecture according to the present invention.

[0097] 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. Further, 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

[0098] Turning now to Figure 2, 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. Alternatively or additionally, 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. For example, 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.

[0099] 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. In an example, the metadata type "genre type" 46 of one metadata schema (e.g., TVA metadata: TVA schema, MPEG7 DDL) 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.

[00100] Turning now to Figure 3, 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. For example, 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.

[00101] One type of semantic analysis that can be employed by semantic analysis module 40 includes both an identification of similarity between tagged content, and an identification of similarity between 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. Also, 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. Similarly, the mapping of "synopsis", "promotional information", and "keyword" of metadata type 50 and "description" of metadata type 52, even where there is no similarity between metadata tags, 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. For this purpose, 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.

[00102] Turning now to Figure 4, 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.

[00103] Turning now to Figure 5, 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. For example, in a first iteration, first pass, 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. Then, in a first iteration, 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. Next, in a second iteration, a comparison for similarity is made at R2-1 , with the mapping result being returned at R2-2. [00104] Turning now to Figure 6, multi-metadata set 70 can be mapped to single metadata set 72 by metadata mapping module 38 employing semantic analysis module 40. For example, TVA metadata 7OA and DV metadata 7OB of set 70 are mapped with UPnP metadata of set 72 at S1 and S2. Then, metadata translation module 44 translates metadata 7OA and 7OB to metadata of set 72 at S3, S4, and S5.

[00105] Turning finally to Figure 7, 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. For example, TVA metadata 7OA and DV metadata 7OB are mapped with UPnP metadata of set 72 at T1 and T1 '. Then, TVA metadata 7OA is translated to UPnP metadata of set 72 at T2 and T3, while UPnP metadata of set 72 is translated to DV metadata 7OB at T4 and T5. Accordingly, some embodiments of the present invention can perform bidirectional metadata translation. [00106] 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.

Claims

CLAIMS What is claimed is:

1. A metadata service system, the system comprising: a datastore of metadata objects; and a search and browsing module 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, wherein said metadata service system is adapted to inform the control point of the existence and capabilities of said metadata service system by participating as a service in a service discovery protocol.

2. The system of claim 1 , wherein said search and browsing module is adapted to return one or more metadata objects based at least in part on an instance identifier specified by the search request.

3. The system of claim 1 , wherein said search and browsing module is adapted to return one or more metadata objects based at least in part on search criteria specified by the search request.

4. The system of claim 1 , further comprising a metadata managing module adapted to receive a create metadata object request from the control point and create a metadata object having a unique internal reference ID based on arguments of the request specifying object characteristics and properties.

5. The system of claim 1 , wherein the create metadata object request has arguments including identifier, type, and object to be created.

6. The system of claim 1 , further comprising a metadata managing module adapted to receive a delete metadata objects command from the control point and delete a metadata object based on a unique internal reference ID specified by the command.

7. The system of claim 1 , further comprising an updating module adapted to receive an updated metadata object from the control point and update said datastore based on the updated metadata object characteristics and properties.

8. The system of claim 7, wherein said updating module is adapted to receive updated metadata objects with arguments including object type and TLVs.

9. The system of claim 1 , wherein said search and browsing module is adapted to receive search criteria including a program GRID and group GRID.

10. The system of claim 1 , wherein said search and browsing module is adapted to return DIDL-MDS schema to the control point, including at least one of location metadata, segmentation metadata, or CRIDs.

11. The system of claim 1 , further comprising a metadata translation module translating metadata of one metadata set to metadata of another metadata set based on a mapping between the sets.

12. The system of claim 11 , further comprising a metadata mapping module employing a semantic analysis of the metadata sets to generate the mapping between the metadata sets.

13. The system of claim 12, wherein said metadata mapping module is operable to create a mapping between multiple metadata sets and another metadata set, and said metadata translation module is operable to perform bidirectional translation between the sets and the set.

14. The system of claim 12, wherein said metadata mapping module employs a multi-pass, multi-iteration process to initially seek equivalence between a property of TVA metadata and firstly base and secondly associated properties of UPnP metadata, and subsequently seeks similarity between TVA and UPnP metadata properties.

15. The system of claim 11 , wherein said translation module is adapted to at least one of obtain or perform the mapping based on content of a pluggable metadata mapping heuristics database supplying rules for mapping metadata between sets.

16. The system of claim 15, wherein said database is at least one of informed or provided by one or more third party service providers.

17. The system of claim 1 , wherein said datastore uniquely indexes said metadata objects using unique internal reference identifiers providing a greater amount of granularity than is available using content reference identifiers.

18. The system of claim 1 , wherein a service discovery framework used by said service system is UPnP.

19. A metadata service method, comprising: providing metadata object creation actions, including receiving a create metadata object request from a control point and creating a metadata object having a unique internal reference ID based on arguments of the request specifying object characteristics; providing metadata object browsing actions, including receiving a search request from the control point and returning metadata objects to the control point based on a CRID, an Instance ID, and search criteria specified by the search request; and providing metadata objects deleting actions, including receiving a delete metadata objects command from the control point specifying the unique internal reference ID and deleting the metadata object based on the unique internal reference ID.

20. The method of claim 19, further comprising providing metadata object updating actions, including receiving an updated metadata object from the control point and updating the metadata object based on the updated metadata object.

21. The method of claim 20, wherein providing metadata object updating actions includes receiving updated metadata objects with arguments including object type and TLVs.

22. The method of claim 19, wherein providing metadata object creation actions includes receiving a create metadata object request having arguments including ID, type, and object to be created.

23. The method of claim 19, wherein providing metadata object browsing actions includes receiving search criteria including a program CRID and group ID.

24. The method of claim 19, providing metadata object browsing actions includes returning DIDL-MDS schema to the control point, including at least one of location metadata, segmentation metadata, or CRIDs.

25. The method of claim 19, further comprising translating metadata of one metadata set to metadata of another metadata set based on a mapping between the metadata sets.

26. The method of claim 25, further comprising employing a semantic analysis of the metadata sets to generate the mapping.

27. The method of claim 26, further comprising: creating a mapping between multiple metadata sets and another metadata set; and performing bidirectional translation between the sets and the set.

28. The method of claim 26, further comprising employing a multi-pass, multi-iteration process to initially seek equivalence between a property of TVA metadata and firstly base and secondly associated properties of UPnP metadata, and subsequently seek similarity between TVA and UPnP metadata properties.

29. The method of claim 25, further comprising at least one of obtaining the mapping or generating the mapping based on contents of a pluggable metadata mapping heuristics database storing rules for mapping metadata, said rules provided by third party service providers.

30. A metadata service system, the system comprising: a datastore of metadata objects, wherein said datastore uniquely indexes said metadata objects using unique internal reference identifiers providing a greater amount of granularity than is available using content reference identifiers; a search and browsing module 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 one or more of a content reference identifier, an instance identifier, or search criteria including a program GRID and group ID specified by the search request, wherein return of one or more metadata objects includes return of DIDL-MDS schema to the control point, including at least one of location metadata, segmentation metadata, or CRIDs, and wherein said metadata service system is adapted to inform the control point of the existence and capabilities of said metadata service system by participating as a service in a service discovery protocol.

31. The system of claim 30, further comprising a metadata management module adapted to receive a create metadata object request from the control point and create a metadata object having a unique internal reference ID based on arguments of the request specifying object characteristics, wherein the create metadata object request has arguments including identifier, type, and object to be created.

32. The system of claim 30, further comprising a metadata management module adapted to receive a delete metadata objects command from the control point and delete the metadata object based on a unique internal reference ID specified by the command.

33. The system of claim 30, further comprising an updating module adapted to receive an updated metadata object from the control point and update said datastore based on the updated metadata object properties and characteristics, wherein said updating module is adapted to receive updated metadata objects with arguments including object type and TLVs.

34. The system of claim 30, further comprising a metadata translation module translating metadata of one metadata set to metadata of another metadata set based on a mapping between the sets.

35. The system of claim 34, further comprising a metadata mapping module employing a semantic analysis of the metadata sets to generate the mapping.

36. The system of claim 34, further comprising a pluggable metadata mapping heuristics database employed by said metadata translation module, said database supplying rules for mapping metadata between sets, said rules provided by third party service providers.