WO2007148304A2

WO2007148304A2 - Representing digital content metadata

Info

Publication number: WO2007148304A2
Application number: PCT/IB2007/052421
Authority: WO
Inventors: Igor W. F. Paulussen; Wilhelmus H. G. M. Van Den Boomen
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2006-06-23
Filing date: 2007-06-22
Publication date: 2007-12-27
Also published as: WO2007148304A3

Abstract

A method is presented for representing metadata associated with a digital content item according to a first standard, such as MPV, as metadata according to a second standard, such as UPnP CDS. The metadata according to the second standard is associated with the same digital content item. A digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files. A digital content item according to the second standard is associated with at maximum a single metadata block. The method includes determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item. Each of the first blocks is then represented as a respective corresponding metadata block according to the second standard (hereinafter referred to as second blocks). For each of the second blocks a respective associated copy of the digital content item is created according to the second standard.

Description

Representing digital content metadata

The invention relates to a method of representing first metadata according to a first standard and associated with a digital content item as second metadata according to a second standard and associated with a copy of the same digital content item.

The invention also relates to a system for performing the method.

The home environment is going through significant changes with respect to Audio, Video, Pictures (digital content) and their corresponding metadata. The PC and the CE worlds are integrating and form larger and larger home networks, shaping the Connected Home. Via these networks content and metadata from the PC, Digital Still Cameras,

Camcorders, the Internet and television broadcast channels all becomes available in the living room. Two standards are important to offer the abovementioned functionality: UPnP for networking and MPV for metadata.

For operations in a networked system the Content Directory Service (CDS) within the Universal Plug and Play (UPnP) architecture is known. The current publicly available version of UPnP and CDS can be obtained from www._.uprip,org. UPnP is a distributed, open networking architecture based on TCP/IP and Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and public spaces. In addition to being an extension of the plug and play peripheral model, UPnP is designed to support zero-configuration, "invisible" networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. A device can leave a network smoothly and automatically without leaving any unwanted state behind. IP internetworking spans different physical media, enables multiple-vendor interoperation, and achieves synergy with the Internet and many home and office intranets. Via bridging, UPnP accommodates media running non-IP protocols.

Many devices within a UPnP compliant network, such as a UPnP home network, contain various types of content that other devices in the network would like to access (e.g. music, videos, still images, etc). As an example, a "Media Server" device might contain audio, video, and still-image library. In order for the user to enjoy this content, the user must be able to browse the objects stored on the Media Server, select a specific one, and cause it to be "played" on an appropriate rendering device (e.g. an audio player for music objects, a TV for video content, an Electronic Picture Frame for still-images, etc). It is desired that user can access the content without having to interact directly with the device containing the content. In order to enable this capability, the service device needs to provide a uniform mechanism for UI devices to browse the content on the server and to obtain detailed information about individual content objects. To this end the UPnP architecture has defined the Content Directory Service (CDS). The Content Directory Service additionally provides a lookup/storage service that allows clients, e.g. user interface (UI) devices to locate (and possibly store) individual objects (e.g. songs, movies, pictures, etc) that the (server) device is capable of providing. A further definition within the AV architecture is given for AV media servers in the document MediaServer: 1 Device Template. The Media Server template defines a general-purpose device that can be used to instantiate any Consumer

Electronic (CE) device that provides AV content (e.g. media) to other UPnP devices on the home network. It exposes its content via the Content Directory service. As such, the Media Server can handle any specific type of media, any data format, and transfer protocol. Example instances of a Media Server include traditional devices such as VCRs, CD Players, DVD Players, audio-tape players, still-image cameras, camcorders, radios, TV Tuners, and set-top boxes.

CDS is hierarchically organised in a manner similar to a computer file system. A so-called container (analogous to a folder or directory) can include a plurality of items (analogous to a file) and containers that are hierarchically one level lower. The item includes an item description with an identifier and optionally meta-data. The meta-data may include properties such as item name, artist, composer, date created, size, etc. The item may also include the actual content or include a locator, such as a URL, for locating the content. The CDS hierarchy is indicated by each container including a reference to its parent container (a bottom-up hierarchy: lower in the hierarchy points to higher in the hierarchy). An item includes a reference to its parent container. An item and container can only refer to a single parent container. A CDS server can easily build/verify the entire tree based on the individual items/containers and their links.

The OSTA (Open Storage Technology Association) MPV (MusicPhoto Video) standard is a standard for exchanging and playing collections of digital music, photos, and videos among consumer electronics devices and PCs on CDs, DVDs, memory cards, hard disks, home networks and across the internet. MPV is a series of XML-based specifications developed by the participating members of OSTA' s MPV committee. MPV is comprised of a series of profiles and guidelines. The publicly available versions can be found at wwvv_^ost^org. The bases are the Core and Basic Profiles, which define all the assets and album or collection. On top of these, there are various types of profiles that address particular use cases, media types or product types. Finally, the Interoperability Specifications define strict or narrow uses of the profiles to ensure they can effectively be used in products with limited capabilities (limited processing power, memory, storage, etc.). In MPV, a digital content item (a file) is named an 'asset' or asset file. A collection of asset information (files and their presentation order) is referred to as an MPV album. An album can be seen as an index file. An MPV manifest is another form of an index file that includes location information (how to find the files/assets for rendering and/or manipulation) and all the metadata (subject, description, creator name, file format, etc.) associated with the digital media files/assets that belong to a certain manifestation. MPV defines a playlist or the order of playback for a series of digital media (music, photo or video) files. A playlist file is an example of an MPV manifest. Albums and manifests (e.g. playlists) are composed of the assets in it. As such, the albums and manifests point to the assets in it. The resulting hierarchy in MPV can thus be seen as top-down. In principle, an album may consists of albums, which consist of albums, etc. until finally an album consists of assets. The same holds for a manifest. A main manifest file is referred to as the index manifest file. It is located in the root directory file and identifies other manifests. An asset can be part of several albums and of several manifests. From the asset itself it can not be established if it is part of any or more albums or manifest. The hierarchy has to be followed top-down. Products such as DVD players or wireless networked media adapters simply have to locate, load and parse the information in the main album or manifest (depending on whether access is required to all assets = album or just to a certain manifestation of assets in the album = manifest) to know everything about the relevant content on a CD/DVD, memory card or remote home media server. MPV is a family of specifications or profiles each addressing either different media types or different product categories. MPV is XML based so it is easy to implement with "off-the-shelf tools and extensible to future product categories and data types.

The Picture Archive and Sharing Standard (PASS) is a digital imaging industry initiative aimed at optimizing the digital imaging experience for consumers. In much the same way that today's consumer can get nearly any brand of film processed at any location, the PASS group wants to ensure that digital images can be retrieved from any digital device or storage medium. The images can be preserved and transitioned to future media technologies for decades through PASS unique migration features and support from key members of the photographic industry. PASS uses MPV as a common "table of contents" for the discs but extends it further to ensure compatibility. PASS extends MPV in various ways to speed and enhance searches and by defining which file formats must be supported to be PASS compliant.

When a user loads an album with assets complying to MPV on a media server (e.g. PC) with the intention to use it in the UPnP environment, a conversion of the MPV content (assets) and metadata to the UPnP CDS equivalents of objects/containers and metadata takes place. Differences in the hierarchical structure cause conflicts.

It would be advantageous to provide a system and method of the kind set forth that is better capable of dealing with discrepancies in metadata hierarchy between standard sets of metadata.

To better address this concern, in a first aspect of the invention a method is presented of representing metadata associated with a digital content item according to a first standard as metadata according to a second standard and associated with the same digital content item, wherein a digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files, and wherein a digital content item according to the second standard is associated with at maximum a single metadata block; the method including: determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item; representing each of the first blocks as a respective corresponding metadata block according to the second standard (hereinafter referred to as second blocks); and creating for each of the second blocks a respective associated copy of the digital content item according to the second standard. By copying the content item N times, where N is the number of metadata blocks associated with the digital content item according to the first standard, a corresponding counterpart is created for each metadata block according to the second standard. Each of the counterparts is associated with its own copy of the digital content item. In an embodiment, the first standard is in conformance with the

MusicPhoto Video (MPV) standard; the digital content item being an MPV asset; the index file being an MPV manifest.

In an embodiment, the second standard is in conformance with the Content Directory Service (CDS) of the Universal Plug and Play (UPnP) standard.

According to an aspect of the invention, the method includes nominating one of the copies as a main copy and for each other copy inserting a reference to the main copy in a data field associated with the respective copy. In this way, it can be maintained which content items are actually copies of the same content. This information can, for example, be used when the content is copied back to an environment compatible with the first standard. At that moment redundant copies of the content can be removed and each of the different metadata blocks can be reproduced in respective index files. This gives an embodiment wherein the method includes copying or moving a digital content item from an environment according to the second standard (hereinafter referred to as second environment) into a third environment wherein digital content items are described according to the first standard; using the reference information to copy/move only a single copy of the content item to the third environment; and representing each metadata block associated with the digital content item or a copy of the digital content item in the second environment as respective metadata blocks in respective index files in the third environment.

According to an aspect of the invention, the first standard enables using a hierarchy of index files and the method includes checking the hierarchy of index files to determine all first blocks. In this way all relevant metadata blocks can be identified and reproduced. According to an embodiment, the second standard enables using a hierarchy of containers, where a digital content item is hierarchically below a single container, and the method includes representing a hierarchy of index files top-down by a corresponding hierarchy of containers. A top-down hierarchy of index files is represented by a 'same' top- down hierarchy of containers. According to an embodiment, the first standard enables an index file to be hierarchically below a plurality of parent index files and wherein the second standard enables a container to be hierarchically below a single parent container, and the method includes, for each index file (hereinafter referred to as child index file) that is hierarchically immediately below a plurality of parent index files: creating a same plurality of parent containers according to the second standard, each container corresponding to a respective one of the parent index files; and creating for each of the parent containers a respective child container according to the second standard that correspond to the same child index file. In this way, a not purely top-down hierarchy of the first standard is still reproduced according to the second standard by using child containers that are 'copies' of one another in the sense that they all correspond to the same single child index file.

According to an embodiment, the method includes nominating one of the child containers as a main container copy and for each other child container inserting a reference to the main container copy in a data field associated with the respective child container. In this way, it can be maintained which containers are actually 'copies' of the same child index file. This information can, for example, be used when the content and metadata is copied back to an environment compatible with the first standard. At that moment redundant copies of the containers can be removed.

These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.

In the drawings: Fig. 1 shows a block diagram of an exemplary system in which the invention may be used;

Fig.2 shows a structure for representing metadata according to a first standard;

Fig.3 provides more details where the first standard is MPV;

Fig. 4 shows a structure for representing metadata according to a second standard, such as UPnP CDS;

Fig.5 shows a hierarchical container structure according to the second standard;

Fig.6 illustrates representing a content associated with multiple metadata block according to the first standard in the structure according to the second standard; Fig.7 shows a further embodiment;

Fig.8 shows an embodiment with a hierarchy of index files according to the first standard;

Fig.9 shows representing the hierarchy according to the second standard;

Fig.10 shows a further embodiment; and Fig.11 shows an exemplary device implementing the method.

Fig.l shows a block diagram of an exemplary system 100 in which the invention may be used. The system couples metadata for the same digital content from two distinct environments. The digital content may take any multimedia form, such as audio, video, still images, etc. and in any format. In the first environment, the digital content is associated with first metadata according to conventions in the first environment. In an embodiment, the first environment is compliant with MPV. Other environments may also be used that meet the requirements as will be discussed in more detail with respect to Fig.2 below. In the second environment, the same digital content (typically in the form of a copy of the original content) is associated with second metadata according to conventions in the second environment. In an embodiment, the second environment is compliant with UPnP CDS. Other environments may also be used that meet the requirements as will be discussed in more detail with respect to Fig.4 below. Each of the environments includes a device. In principle, both environments may be executed in a single device, but in most practical situations each environment includes at least one own device with one or more device being able to participate in both environments and as such able to link both environments as described in the invention. For ease of discussion, in the remainder MPV will be used to represent the first environment and UPnP CDS to represent the second environment.

The exemplary system may include a network, such as a home network. In the figure a hierarchy of networks is shown. In this example, the main network 110 is a home network that may be based on the UPnP architecture. The description will focus on a UPnP network but it will be appreciated that the same concept can also be applied to non-UPnP system with a network and a CDS-like management of content in the system. UPnP is based on IP technology and supports many network media and higher level protocols. The media of the home network may be wired, e.g. from the Ethernet family of media, or wireless, such as based on IEEE 802.11 family of media. The system may, but need not, have links to an external network 130, such as the open Internet, for example through a gateway/router 120 coupled to the home network 110. The external network may also include devices, such as device 170 that may be an Internet server. The external network 130 could thus include or provide access to an MPV and/or UPnP device. A third network 140 may exist for the transfer of, in particular, streaming multimedia data, e.g. streaming AV data, in parallel to the home network 110. The third network may specially suited for isochronous transfer of digital content, for example using IEEE 1394, DVI, or HDMI. Portable devices, such as digital cameras, video cameras, PDAs, smartphones, etc. may also be connectable to the home network. Shown is a portable device 160 that is directly connected to the home network 110, for example though a bridge/router. A portable device may also be connected to a device that in turn is connected to the home network. For example, device 162 is connected to device 164 that is connected to the home network. For a link to a portable device any suitable wired or wireless technology may be used, for example using the USB network, IEEE 802.11, Bluetooth, or IEEE 1394.

In the description, a major role is given to the second environment (e.g. UPnP CDS) that may include a server device 150. The server device, such as a multimedia server may include a content directory service (hereinafter "CDS"), as will be describe in more detail later on. In principle, more devices may include a CDS. For simplicity only one device with a CDS is shown. The other devices, such as device 160, 162, 164, 166 are able to communicate with each other and/or with the server 150. In an exemplary scenario, device 160 represents an MPV source device, such as a digital camera. The MPV content (or part of it) of this device gets copied or moved to the UPnP CDS server 150. At a later stage, all or part of this content gets moved or copied (e.g. archived) to an MPV device, represented by device 162, e.g. for storage/archiving, rendering or manipulation Any of the devices may be implemented using conventional hardware and software. For example, the server 150 may be implemented on a personal computer platform, if so desired, with reliable background storage, such as a hard disk, a RAID system or rewritable DVD, for storing the CDS. The server 150 may also be implemented on a Consumer Electronics (CE) device, such as a receiver (e.g. set top box, multimedia server) with integrated hard disk. Rendering devices may be used, such as a TV, audio amplifier, etc. Source devices may be used, which may be any conventional CE source, but may also be a digital camera. User interface (UI) devices may be used, which may also be conventional CE devices, such as TVs, but may also be hand-held devices such as PDAs, or advanced programmable remote controls, etc. Each of the devices in the system includes the necessary hardware and/or software for communicating with at least one of the other devices through a suitable network connection.

Fig.2 shows more details of the first environment. In this example, five digital content items 210, 220, 230, 240 and 245 are shown, e.g. digital photos, or MP3 songs, etc.. Each content item is associated with a respective content item identifier (ID). Shown are the respective identifiers IDl, ID2, ID3, ID4, and ID5. The identifier may take any suitable form, such as a file name, but may also be more powerful, such as a URL, URI, or URN. In the first environment, the content item itself may include metadata, as for example is the case for MP3. Irrespective of that metadata, in the first environment index files 200, 205 are used that include metadata for content items covered by the index file. The part of the metadata in the index file that corresponds to a specific content item is identifiable in the index file through the content item identifier associated with of the content item. In the example of Fig.2, the index file 200 covers the four content items 210 to 240 and includes for each a respective portion of metadata 250 to 280, each identified by the respective content identifier. The index file 205 covers the two content items 230 and 245 and includes for each a respective portion of metadata 290 and 295, each identified by the respective content identifier. The content identifier may, for example, immediately precede the involved portion of metadata and thus identify the portion. Other forms of identifying the portion may also be used. For example, a mapping table may be used that maps each of the content identifiers to a respective pointer that points to the involved portion of metadata. As described above, in an embodiment the first environment is MPV compliant. An example, of an MPV XML manifest with album ALBOl and assets IDOl (a still picture) and ID02 (a audio track) is: <?xml version="1.0" encoding="UTF-8"?> <file:Manifest xmlns:file="http://ns.osta.org/manifest/l .0/" xmlns:mpv="http://ns.osta.org/mpv/1.0/" xmlns:mpvp="http://ns.osta.org/mpv/presentation/1.0/" xmlns :mpvm="http ://ns .osta.org/mpv/music/ 1.0/" xmlns:dc="http://purl.org/dc/elements/l Al" xmlns :dcterms="http://purl.org/dc/terms/" xmlns:nmf="http://ns.osta.org/nmf/1.0/" <nmf:Metadata> <ManifestProperties xmlns="http://ns.osta.org/manifest/l .0/">

<ProfileBag> <Profile>http://ns.osta.org/mpv/basic/l .0/</Profile>

<Profile>http://ns.osta.org/mpv/presentation/1.0/</Profile> <Profile>http://ns.osta.org/mpv/music/1.0/</Profile> </ProfileBag> </ManifestProperties> </nmf:Metadata>

<mpvp: Album mpv:id="ALB01">

<nmf:Metadata> <dc:Properties>

<dc:Title>Hawaii</dc:Title> <dc : Creator>Philips Research</dc : Creator> <dc:Description>Holiday to Hawaii, 2005</dc:Description> </dc:Properties> <dcterms:Properties>

<dcterms:Created>2005-03-03T12:05:00Z</dcterms:Created> </dcterms:Properties> </nmf:Metadata> <mpvp :Background> </mpvp:Background>

<mpv:AssetList> <mpv:Still mpv:id="ID01">

<nmf:Metadata> <dc:Properties>

<dc:Title>Holiday in Hawaii</dc:Title> <dc : Creator>Philips Research</dc : Creator> <dc:Description>2005: Hawaii Holiday</dc:Description> </dc:Properties> <dcterms:Properties>

<dcterms:Created>2005-02-03T15:07:00Z</dcterms:Created> </dcterms:Properties> </nmf:Metadata> <mp v : LastURL>Hawaii/Hawaii .jpg</mp v : LastURL> </mpv:Still>

<mpv:Audio mpv:id="ID02"> <nmf:Metadata> <dc:Properties> <dc:Title>Stir It Up</dc:Title>

</dc:Properties> <mpvm:MusicProperties>

<mpvm:PrincipalArtist>Bob Marley And The Wailers</mpvm:PrincipalArtist> <mpvm:AlbumTitle>One Love, The Best Of</mpvm:AlbumTitle> <mpvm:Recorded>2001 </mpvm:Recorded>

<mp vm : Genre> Alternative</mp vm : Genre> <mpvm:TrackNumber> 1 </mpvm:TrackNumber> <mpvm:PlayingTime>3 :41 </mpvm:PlayingTime>

<mpvm:EncodedBitrate>192 kbps / 44.1 kHz / Stereo</mpvm:EncodedBitrate> </mpvm:MusicProperties>

</nmf:Metadata>

<mpv:LastURL>Hawaii/StirItUp.mp3</mpv:LastURL> </mpv:Audio> </mpv:AssetList>

</file:Manifest>

For asset IDOl, the index file includes metadata, such as title, creator, and a description. For asset ID02, the index file includes metadata, such as principal artist, album title, when recorded, genre, track number, etc.

Fig.3 illustrates the structure of Fig.2 for MPV. In this example, the index files are albums, with respective album identifiers IDAO and IDAl. The first album covers three assets with respective identifiers IDl, ID2, and ID3. The second album covers two assets with respective identifiers ID3 and ID4. It is noted that an asset (in this case asset with identifier ID3) can be part of several index files (albums in this case). It is also noted that indeed the index file 'points' to its children assets, by including a reference to them.

Fig.4 shows more details of the second environment. Each content item (object) includes an item description. The description may include several fields, like an identifier, such as a name. In particular, the item description includes metadata describing the content. For example, for an audio title such metadata may include the name of a singer/artist, composer and producer, and recording data, such as a recording company, studio, etc. In addition to the content description, the item also includes actual content, such as an MP3 file or a JPEG file. This is shown in Fig.4A where the item includes a content description 410 and actual content 420. Fig.4B shows an alternative arrangement wherein, instead of containing the actual content, the item may in fact include a content locator 440, such as a URL, that enables locating the actual content 450. In principle, the content description may also refer to some of the fields to another location, e.g. a server on the Internet. Part 430 represents the same content description as 410 in Fig.4A. It is noted that for each item there is only one description. As described above, in an embodiment the second environment is UPnP CDS compliant.

Fig.5 shows for the UPnP CDS embodiment more details on the role of a server, also referred as media server. The server includes the Content Directory Service (CDS). The content is created or captured in a subsystem that may be located in another device. For example, a movie may be received by a tuner or supplied on disk into a DVD player. A photo may be supplied by a digital camera or scanned through a scanner. The actual content may be stored in the CDS, but may also be stored somewhere else, e.g. in a content storage database. The Content Directory Service, CDS, provides a set of actions that allow a device (Control Point in UPnP terminology) in the home network to enumerate the content that the Server can provide to the home network. For example, a device can obtain detailed information about each Content Item that the Server can provide. This information (i.e. metadata) includes properties such as its name, artist, date created, size, etc. The Content Directory Service includes a hierarchical structure of containers. Such container can be seen as equivalent to folders/directories in a file system. In principle a container may also be physically represented as a directory. It may also be represented differently, e.g. the entire CDS may be one file with an internal structure that makes identification of and access to containers/objects possible. Fig. 5 shows an example of a hierarchical structure with six containers Cont 1, Cont 2.1, Cont 2.2, Cont 2.3, Cont 3.1 and Cont 3.3.

The exemplary CDS at that moment contains three hierarchical layers, layer 1 with Cont 1, layer 2 with Cont 2.1, Cont 2.2, and Cont 2.3, layer 3 with Cont 3.1 and Cont 3.3. The top container (Cont 1) is also referred to as root. Preferably, each container can also include items, in particular but not limited to AV content, such as an audio title, movie, photographs, etc. The system can also work if, for example, only the lowest layer of containers can include items. In the example of Fig.5, Cont 1 includes two items It- 1.1 and It- 1.2; and container Cont 2.1 includes three items It-2.1.1, It-2.1.2, and It-2.1.3. In principle, the CDS is dynamic, in the sense that a user can determine the containers in the CDS and the hierarchy among the containers. It is noted that an object can be only in one parent container. Similarly, a container can be in only one parent container. Furthermore, in CDS the hierarchical structure is recorded by a child including the identifier of its parent. So, pointers run from the children (leaves/nodes in the tree) through the intermediate containers to the top container (root of the tree).

According to an aspect of the invention, metadata associated with a digital content item according to a first standard is represented as metadata according to a second standard and associated with the same digital content item. As illustrated before, a digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files. A digital content item according to the second standard is associated with at maximum a single metadata block. The method now includes determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item. Taking the example of Fig.3, and taking as the digital content item to be represented the Asset with identifier ID3, it is noted that this asset has two parent index files (Album IDAO and IDAl) which each have metadata for the content item. As a next step, the method includes representing each of the first blocks as a respective corresponding metadata block according to the second standard (hereinafter referred to as second blocks). In this example, two metadata blocks are created, each containing metadata mapped from the respective index files IDAO and IDAl. Mapping of the individual metadata fields may be done in any suitable form and is not the subject as such of this invention. Finally, for each of the second blocks a respective associated copy of the digital content item is created according to the second standard. This is illustrated in Fig. 6 that gives the outcome of this process for UPnP CDS, where the input was the MPV structure of Fig.3. Since asset ID3 had two metadata blocks, in the UPnP environment two copies are made of the content in the UPnP environment. The copies need to have different identifiers. In this example, identifiers ID3 and ID3ref are assigned (note: the identifiers are unique),. Now, each of the copies can be associated with a respective metadata block (not shown), along the lines of Fig.4. Fig.6 also illustrates that items lower in the hierarchy refer to items higher in the hierarchy by including the parented.

In an embodiment, the method includes nominating one of the copies as a main copy. In the example of Fig.7, item ID3 is selected as the main copy. The method further includes, for each other copy, inserting a reference to the main copy in a data field associated with the respective copy. In the example of Fig.7, the other copy of the same content is indicated with reference ID3ref. The association of this object with the main object is done by inserting the reference refID="ID3" in the object description of object ID3ref.

According to an aspect of the invention, the method includes copying or moving a digital content item from an environment according to the second standard (hereinafter referred to as second environment) into a third environment wherein digital content items are described according to the first standard. For example, a content item that has been imported from an MPV environment into the UPnP CDS environment is now exported to an MPV environment. According to the method, the reference information (e.g. reference refID="ID3") is used to copy/move only a single copy of the content item to the third environment. For example, by noticing that item IDreO refers to another item it can be decided not to copy the content of item IDreO. On the other hand, each metadata block associated with the digital content item or a copy of the digital content item is represented in the second environment as respective metadata blocks in respective index files in the third environment. So, the metadata blocks associated with both ID3 and ID3ref are represented in the third environment. For example, by using two index files, as was already shown in Fig. 3, that are associated with the same single content item.

In an embodiment, the first standard enables using a hierarchy of index files. This is shown in more detail for MPV in Fig.8. In that example, four index files (albums in this case) are shown. There are two hierarchically top albums (IDAO and IDAl). Album

IDAO has two children albums IDA2 and ID A3. Album IDAl has one child album ID A3. In this embodiment, the hierarchy of index files is checked to determine all first blocks, i.e. all metadata blocks in those index files for the same content item. For example, each of the albums IDAO, IDAl and ID A3 may have a metadata block for content item ID2. Similarly, albums IDAO and IDA2 may have a metadata block for content item IDl . Each of those blocks can then be represented in the second environment. A skilled person will have no problem checking the hierarchical structure for index files that covers a certain asset.

In an embodiment, the second standard enables using a hierarchy of containers, where a digital content item is hierarchically below a single container. This has already been described for the example of UPnP CDS, where an object (content item) can only be hierarchically below one container, by the fact that an object can only include one pointer to a parent. In this embodiment, the hierarchy of index files is represented top-down by a corresponding hierarchy of containers. For example, starting at a top-element in the hierarchy going down, all index files and asset that are found in this way can be directly mapped to corresponding elements in the second environment. For example, an MPV index file is mapped to a CDS container. An MPV asset is mapped to a CDS object. Referring to Fig.8, part of the structure that starts at the top album IDAO and including albums IDAO, IDA2, ID A3 and assets IDl and ID2 can be mapped in a straightforward way. Optionally, a similar independent mapping may occur starting at the top album IDAl and including albums IDAl, ID A3 and asset ID2. This would then give two unrelated CDS trees.

In an embodiment, the first standard enables an index file to be hierarchically below a plurality of parent index files, as already illustrated for MPV. The second standard enables a container to be hierarchically below a single parent container, as already described for UPnP CDS. In such a situation, the method includes, for each index file (hereinafter referred to as child index file) that is hierarchically immediately below a plurality of parent index files: creating a same plurality of parent containers according to the second standard, each container corresponding to a respective one of the parent index files; and creating for each of the parent containers a respective child container according to the second standard that correspond to the same child index file. This is illustrated with respect to the input MPV structure of Fig.8 and the resulting CDS output structure of Fig.9. In Fig.8, the index file (in that case album) ID A3 is hierarchically below two parent index files, albums IDAO and IDAl. Then two corresponding parent containers are created in the second environment: containers with identifiers IDAO and IDAl. Each of those created parent containers gets a child container, indicated with identifiers ID A3 and IDA3ref (note: the identifiers are unique), that correspond to the same child index file album IDA3 of Fig.8.

In an embodiment, similar as to has been described with respect to Fig. 7 for the content item, now one of the child containers is nominated as a main container copy. In the example of Fig.10, the child container with identifier IDA3 is chosen as the main copy. For each other child container (in that example: container IDA3ref) a reference is inserted to the main container copy in a data field associated with the respective child container. In this example, the reference is RefID="IDA3". Fig.11 shows a block diagram of an exemplary device 1100 capable of performing the metadata representation and structure translation according to the invention. The device 1100 has input means 1110 for retrieving information from the first environment, e.g. from an MPV environment. This includes being able to locate the index file (i.e. determine a locator for it) and to locate the relevant metadata part in this index file. A simply way of achieving this is establishing a form of communication with the first embodiment, for example by inserting a storage with the first memory into the device 1100, where device 1100 is equipped with a suitable slot for receiving the storage, or by communication to a device with the first environment through a network like USB, Bluetooth or WiFi. Device 1100 further includes means 1120 for accessing the second environment, e.g. for the CDS environment this may include creating/modifying object and/or containers in CDS. Device 1100 further includes means 1130 for representing metadata associated with a digital content item according to a first standard as metadata according to a second standard and associated with the same digital content item, wherein a digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files, and wherein a digital content item according to the second standard is associated with at maximum a single metadata block. The means 1130 may be subdivided into: means 1131 for importing the information retrieved from the first environment through the input means 1110; means 1132 for determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item; means 1134 for representing each of the first blocks as a respective corresponding metadata block according to the second standard (hereinafter referred to as second blocks); and means 1136 for creating for each the second blocks a respective associated copy of the digital content item according to the second standard; and means 1138 for exporting the new information to the second environment through means 1120. As such, block 1130 (and its sub-block) may be executed on a processor. In further embodiment, block 1130 may include respective sub-blocks (not shown in Fig.l 1): for nominating one of the copies as a main copy and for each other copy inserting a reference to the main copy in a data field associated with the respective copy; for copying or moving a digital content item from an environment according to the second standard (hereinafter referred to as second environment) into a third environment wherein digital content items are described according to the first standard; using the reference information to copy/move only a single copy of the content item to the third environment; and representing each metadata block associated with the digital content item or a copy of the digital content item in the second environment as respective metadata blocks in respective index files in the third environment; for checking the hierarchy of index files to determine all first blocks, wherein the first standard enables using a hierarchy of index files; the method including; for representing a hierarchy of index files top-down by a corresponding hierarchy of containers, where the second standard enables using a hierarchy of containers, where a digital content item is hierarchically below a single container; for, in a situation wherein the first standard enables an index file to be hierarchically below a plurality of parent index files and wherein the second standard enables a container to be hierarchically below a single parent container, for each index file

(hereinafter referred to as child index file) that is hierarchically immediately below a plurality of parent index files: creating a same plurality of parent containers according to the second standard, each container corresponding to a respective one of the parent index files; and creating for each of the parent containers a respective child container according to the second standard that correspond to the same child index file; for nominating one of the child containers as a main container copy and for each other child container inserting a reference to the main container copy in a data field associated with the respective child container. All of such sub-blocks may be implemented as separate hardware block or software function and/or software modules and/or software objects. A skilled person may also choose another suitable arrangement for performing the functionality described above. Device 1100 may include a memory or storage 1140 for storing the data relevant for performing the representation. The memory 1140 may be arranged in separate parts. For example, the memory/storage 1140 may include: a memory part 1141 may be used for storing the index file or data from the index file imported by sub-block 1131, a memory part 1142 for storing the data required for determining how many metadata blocks are associated with the digital content, as determined by sub-block 1132, a memory part 1144 for storing data required by or generated by sub-block

1134, such as the second blocks, a memory part 1146 for storing data required by or generated by sub-block 1136, such the respective associated copy of the digital content item according to the second standard; and a memory part 1148 for storing the data to be exported by sub-block 1138. For example, sub-block 1131 may store the retrieved information in block 1141 and additionally or alternatively supply it directly to block 1132. Sub-block 1132 may use this information, perform its described task and store the outcome and/or intermediate result in memory part 1142. Sub-block 1132 my also supply the outcome directly to sub- block 113. Sub-blocks 1134 and 1136 may operate in a same manner, performing their own respective tasks. Sub-block 1138 may export the information accumulated in memory part 1148 and/or directly obtained directly from sub-blocks 1134 and 1136. A skilled person will be able to define other memory/storage arrangements as well. It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as partially compiled form, or in any other form suitable for use in the implementation of the method according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may include a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further the carrier may be a transmissible carrier such as an electrical or optical signal, which may be conveyed via electrical or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant method.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. A method of representing metadata (260) associated with a digital content item (220; Fig.3 ID3) according to a first standard as metadata (330) according to a second standard and associated with the same digital content item (450), wherein a digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files (Fig.3, IDAO, IDAl), and wherein a digital content item according to the second standard is associated with at maximum a single metadata block; the method including: determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item; representing each of the first blocks as a respective corresponding metadata block (Fig.6 IDAO, IDAl) according to the second standard (hereinafter referred to as second blocks); and creating for each of the second blocks a respective associated copy (Fig.6 ID3, ID3ref) of the digital content item according to the second standard.

2. A method as claimed in claim 1, including nominating one of the copies as a main copy and for each other copy inserting a reference to the main copy in a data field associated with the respective copy.

3. A method as claimed in claim 2, including copying or moving a digital content item from an environment according to the second standard (hereinafter referred to as second environment) into a third environment wherein digital content items are described according to the first standard; using the reference information to copy/move only a single copy of the content item to the third environment; and representing each metadata block associated with the digital content item or a copy of the digital content item in the second environment as respective metadata blocks in respective index files in the third environment.

4. A method as claimed in claim 1, wherein the first standard enables using a hierarchy of index files; the method including checking the hierarchy of index files to determine all first blocks.

5. A method as claimed in claim 4, wherein the second standard enables using a hierarchy of containers, where a digital content item is hierarchically below a single container; the method including representing a hierarchy of index files top-down by a corresponding hierarchy of containers.

6. A method as claimed in claim 5, wherein the first standard enables an index file to be hierarchically below a plurality of parent index files and wherein the second standard enables a container to be hierarchically below a single parent container; the method including, for each index file (hereinafter referred to as child index file) that is hierarchically immediately below a plurality of parent index files: creating a same plurality of parent containers according to the second standard, each container corresponding to a respective one of the parent index files; and creating for each of the parent containers a respective child container according to the second standard that correspond to the same child index file.

7. A method as claimed in claim 6, including nominating one of the child containers as a main container copy and for each other child container inserting a reference to the main container copy in a data field associated with the respective child container.

8. A method as claimed in claim 1. wherein the first standard is in conformance with the MusicPhoto Video (MPV) standard; the digital content item being an MPV asset; the index file being an MPV manifest or an MPV Album.

9. A method as claimed in claim 1, wherein the second standard is in conformance with the Content Directory Service (CDS) of the Universal Plug and Play (UPnP) standard.

10. A computer program product for causing a processor to perform the method of claim 1.

11. A system for representing metadata associated with a digital content item according to a first standard as metadata according to a second standard and associated with the same digital content item, wherein a digital content item according to the first standard may be associated with a plurality of metadata blocks stored in respective index files, and wherein a digital content item according to the second standard is associated with at maximum a single metadata block; the system including: means for determining according to the first standard how many metadata blocks (hereinafter referred to as first blocks) are associated with the digital content item; means for representing each of the first blocks as a respective corresponding metadata block according to the second standard (hereinafter referred to as second blocks); and means for creating for each the second blocks a respective associated copy of the digital content item according to the second standard.