W3C

Ontology for Media Resource 1.0

W3C Working Draft 08 June 2010

This version:
http://www.w3.org/TR/2010/WD-mediaont-10-20100608
Latest version:
http://www.w3.org/TR/mediaont-10
Previous version:
http://www.w3.org/TR/2010/WD-mediaont-10-20100309
Editors:
이원석(WonSuk Lee), Electronics and Telecommunications Research Institute (ETRI)
Tobias Bürger, University of Innsbruck
Felix Sasaki, Potsdam University of Applied Sciences
Véronique Malaisé, VU University of Amsterdam
Florian Stegmaier, University of Passau
Joakim Söderberg, Ericsson

Abstract

This document defines the Ontology for Media Resource 1.0. We take the term of ontology in its loosest possible definition: a core vocabulary. The ontology for media resources is meant to bridge the different descriptions of media resources on the Web, as opposed to media resources in local archives or musea. It is defined based on a core set of properties which covers basic metadata to describe media resources. Further it defines syntactic and semantic level mappings between elements from existing formats. The ontology is supposed to foster the interoperability among various kinds of metadata formats currently used to describe media resources on the Web.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the a Last Call Working Draft of the Ontology for Media Resource 1.0 specification.

It has been produced by the Media Annotations Working Group, which is part of the W3C Video on the Web Activity. The Working Group expects to advance this specification to Recommendation Status.

The W3C Membership and other interested parties are invited to review the document and send comments through 11 July 2010. Comments must be sent to to public-media-annotation@w3.org mailing list (public archive). Use "[LC Comment ONT]" in the subject line of your email.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
    1.1 Formats in scope
    1.2 Formats out of scope
2 Terminology
3 Property value type definitions
    3.1 URI
    3.2 String
    3.3 Integer
    3.4 Float
    3.5 Date
4 Property definitions
    4.1 Core property definitions
        4.1.1 Namespace of core property definitions: http://www.w3.org/ns/ma-ont
        4.1.2 Description of the approach followed for the property definitions
        4.1.3 Core properties
    4.2 Property mapping table
        4.2.1 Rationale regarding the mapping table
            4.2.1.1 Semantic Level Mappings
            4.2.1.2 Syntactic Level Mappings
            4.2.1.3 Mapping expression
        4.2.2 The mapping table
            4.2.2.1 CableLabs 1.1
            4.2.2.2 DIG
            4.2.2.3 EBUCore
            4.2.2.4 EXIF
            4.2.2.5 ID3
            4.2.2.6 IPTC
            4.2.2.7 LOM
            4.2.2.8 MediaRDF
            4.2.2.9 MediaRSS
            4.2.2.10 METS
            4.2.2.11 MPEG7
            4.2.2.12 OGG
            4.2.2.13 SMTPD
            4.2.2.14 TVA
            4.2.2.15 TXFeed
            4.2.2.16 XMP
            4.2.2.17 YouTube
5 Conformance Requirements

Appendices

A References (Normative)
B References (Non-Normative)
C Acknowledgements (Non-Normative)


1 Introduction

This section is informative, except those parts that are explicitly defined as normative.

This document defines the Ontology for Media Resource, version 1.0. In this document, the term "ontology" is used in its broadest possible definition: a core vocabulary. The ontology for media resource describes a core vocabulary of properties and a set of mappings between different metadata formats of media resources hat describe media resources published on the Web (as opposed to local archives, museums, or other non-web related and non-shared collections of media resources). The purpose of these mappings is to provide metadata representations that describe the characteristics and behavior of media resources in an interoperable manner, thereby enabling different applications to share and reuse these metadata. The vocabulary is defined in this document is based on a core set of properties that defines basic metadata to describe media resources. For example creator is a common property that is supported in several existing metadata formats. Therefore, it is defined as one of the properties in the core vocabulary of this document. The set of mappings between this core property and other existing metadata formats can be used to facilitate application interoperability, where the mappings are used to equate the syntactical meaning between the same property that is expressed in different schemata. This builds a bridge between commonly used properties that are defined differently in various schemata. Ideally, the mappings defined in this document could be used to preserve the semantics of a vocabulary term defined in a particular schema. In reality, however, this cannot be easily achieved, due to the many and varied differences in the semantics that are associated with each property in the mapped vocabularies. The mappings defined in this document are syntactic only, and do not attempt to equate the different semantics that are associated with each property in a given mapping. For example, the property dc:creator from the Dublin Core and the property exif:Artist defined in the Exchangeable Image File Format, or EXIF are both mapped to the property creator in our ontology. Note, however, that the extension of the property in the EXIF vocabulary (i.e., the set of values that the property can have) is more specific than the corresponding set of values that this same property can have in the Dublin Core. Mapping back and forth between properties from different schemata, using our ontology as a reference, will hence induce a certain loss in semantics. This is inevitable if we want to improve application interoperability using a simple and lightweight mechanism. In order to avoid this loss of semantics, a more powerful implementation, such as one that uses a rule system that can associate and map different value ranges for a property, would have to be used. In contrast, this document defines a simple and lightweight system that usessyntacticmappings to identify equivalent properties in different schemata. In addition, for each mapping, the mapping is defined as an exact, broader, or narrower mapping between the two properties.

The ontology defines mappings between a set of vocabularies and a set of core properties in our own namespace, which is identified with the "ma" prefix in this document. Although some of these properties can appear to be redundant with the Dublin Core set of properties, the set of properties that make up our ontology are defined in a new namespace that is separate from the Dublin Core for several reasons, including:

The core set of properties and mappings (i.e., our ontology) provides the basic information needed by targeted applications (see Use Cases and Requirements for Ontology and API for Media Object 1.0) for supporting interoperability among the various kinds of metadata formats related to media resources that are available on the Web. In addition, the ontology is accompanied by an API (see API for Media Resource 1.0) that provides uniform access to all its elements.

The properties defined in this document are used to describe media resources that are available on the web. Media resources can denote both the abstract concept of a media resource (e.g., the movie "Notting Hill") as well as a specific instance (e.g., a certain file with an MPEG-4 encoding of the English version of "Notting Hill" with French subtitles). For the sake of simplicity, we do not make distinctions between these different levels of abstraction that exist in some formats (e.g., [FRBR])

This document contains normative, non-normative, and informative sections. The parts of this document that define the ontology, as well as the syntactic and semantic level mappings between elements from existing formats and the core properties defined in this document, are normative, and are marked as such. For normative sections only, the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC 2119]. To facilitate differentiation between the normative use of these terms as defined in RFC2119 and a non-normative use of these terms, the normative use of these terms MUST occur in all capital letters. All other sections, including examples, are not normative.

1.1 Formats in scope

This section is normative; however, examples contained in this section are informative.

The following table lists the formats that were selected by the working group as in-scope, along with the identifiers which are used as prefixes to identify them in this specification.

Identifier Format Example Reference
cl11 CableLabs 1.1 cl11:Writer_Display Cablelabs 1.1
dig35 DIG35 dig35:ipr_name/ipr_person@description='Image Creator' DIG35
dc Dublin Core dc:creator Dublin Core
ebucore EBUCore ebuc:creator EBUCore
exif EXIF 2.2 exif:Artist EXIF
id3 ID3 id3:TCOM ID3
iptc IPTC iptc:Creator IPTC
lom21 LOM 2.1 lom21:LifeCycle/Contribute/Entity LOM
ma Core properties of the MA WG ma:creator 4 Property definitions
media Media RDF media:Recording Media RDF
mrss Media RSS mrss:credit@role='author' Media RSS
mets METS mets:agency METS
mpeg7 MPEG-7 mpeg7:CreationInformation/Creation/Creator/Agent MPEG-7
dms DMS-1 dms:Participant/Person DMS-1
tva TV-Anytime tva:CredistsList/CredistItem TV-Anytime
txf TXFeed txf:author TXFeed
xmp XMP xmpDM:composer XMP
yt YouTube Data API Protocol yt:author YouTube Data API Protocol

1.2 Formats out of scope

The following formats have been decided to be out of scope for this specification.

  • MPEG-21: It is not a media description in the narrower sense.

2 Terminology

This section is normative.

[Definition: Ontology]

A formal definition of an ontology is as follows. "An ontology is a formal, explicit specification of a shared, machine-readable vocabulary and meanings, in the form of various entities and relationships between them, to describe knowledge about the contents of one or more related subject domains throughout the life cycle of its existence. These entities and relationships are used to represent knowledge in the set of related subject domains. Formal refers to the fact that the ontology should be representable in a formal grammar. Explicit means that the entities and relationships used, and the constraints on their use, are precisely and unambiguously defined in a declarative language suitable for knowledge representation. Shared means that all users of an ontology will represent a concept using the same or equivalent set of entities and relationships. Subject domain refers to the content of the universe of discourse being represented by the ontology" [KEUO]. In this specification, the broadest possible definition of an ontology is used: a shared vocabulary. The vocabulary in question is the list of core properties (relationships) defined in the ma namespace, and the machine-readable format is not specified here. This specification provides a simple text description and definition of the relationships. An implementation of the vocabulary in RDF [RDF] will be provided as an example in the appendix of this specification. However, implementations are not limited to using RDF. In particular, implementations MAY use different formats and still be considered to be conformant with this specification.

[Definition: Media Resource]

A media resource is any physical or logical Resource that can be identified using a Uniform Resource Identifier (URI), as defined by [RFC 3986]) , which has or is related to one or more media content types. Note that [RFC 3986] points out that a resource may be retrievable or not. Hence, this term encompasses the abstract notion of a movie (e.g., Notting Hill) as well as the binary encoding of this movie (e.g., the MPEG-4 encoding of Notting Hill on a DVD), or any intermediate levels of abstraction (e.g., the director's cut or the plain version of the Notting Hill movie). Although some ontologies (FRBR, BBC) define different concepts for different levels of abstraction, other ontologies do not. Therefore, in order to foster interoperability, our ontology does not provide such a classification of media resources.

[Definition: Property]

A property is an element from an existing metadata format for describing media resources, or an element from the core vocabulary as defined in this specification. For example, the Dublin Core dc:creator element and the Media Ontology ma:creator element are both properties. A property links a Media Resource with a value (or another resource). In the above example, the dc:creator property links a given resource with the value of its creator property. In this example, Dublin Core does this by defining the dc:creator property as follows: "Examples of a creator include a person, an organization, or a service".

Properties can have structured and/or unstructured values. The set of properties defined in the media ontology core vocabulary is listed in section 4 Property definitions.

[Definition: Mapping]

For the purposes of this document, a mapping is defined as a function that transforms information represented in one schema using one format to information in a different schema that uses a different format. In this document, a set of mappings are defined that equate a subset of the "in scope" Vocabularies with the properties of the core vocabulary of the media ontology that is defined in this document. These mappings are presented in section 4.2 Property mapping table.

[Definition: Property value types]

Property value types are the data types of values used in a property. For example, the property dc:creator can have either string or URI data types. Property value types are defined in section 3 Property value type definitions. They are dependent on XML Schema data types [XML Schema 2].

3 Property value type definitions

This section is normative.

Note:

Currently, the data types of property values that used in this document are defined in terms of XML Schema 1.1, part 2.

The Working Group MAY potentially modify these definitions, to ensure compatibility with the return data types defined in API for Media Resources 1.0 s well as the data types defined in the HTML5 W3C Working Draft. Applications that wish to be conformant with this specification MUST use the data types specified in this section for property values that are defined in this specification.

3.1 URI

"A Uniform Resource Identifier", or URI, is defined in [RFC 3986]. In this specification, the term URI is used, since it is well known. However, the use of this term is extended in this specification to also include "Internationalized Resource Identifiers" (IRIs), as defined in [RFC 3987]. An IRI is a URI that MAY contain non-escaped characters other than ASCII characters. The data type is anyURI. Hence, in this specification, the term "URI" MUST be interpreted to also include IRI.

3.2 String

A String value MUST be represented using the XML Schema string data type.

3.3 Integer

An Integer value MUST be represented using the XML Schema integer data type.

3.4 Float

A Float value MUST be represented using the XML Schema float data type.

3.5 Date

A Date value MUST be represented using the XML Schema dateTime data type.

4 Property definitions

This section is normative; however, examples contained within this section are informative.

4.1 Core property definitions

4.1.1 Namespace of core property definitions: http://www.w3.org/ns/ma-ont

The W3C Media Annotations Working Group has defined a namespace URI, ma-ont, for use with this specification. As specifications that use this namespace URI progress through the standardization process, it is important that each subsequent revision of specifications that use this namespace MUST use the same namespace URI. However, should one or more specifications that use this namespace URI revert to Working Draft status during the standardization process, and a subsequent revision, published as a Working Draft (WD), Candidate Recommendation (CR) or Proposed Recommendation (PR) draft, result in changes that are not backward compatible with the original specifications, the namespace URI (ma-ont) MAY be changed.

The ma abbreviation is a prefix for the namespace http://www.w3.org/ns/ma-ont, which identifies the namespace used by this specification. Applications that are compliant with this specification SHOULD use this namespace.

4.1.2 Description of the approach followed for the property definitions

This list of core properties has been defined by creating an initial set of mappings from the list of vocabularies in scope. This mapping table has been constructed by including properties that were supported by the majority of the vocabularies in scope.

The ranking of the core properties by expected importance, as determined by the use cases defined in this working group, has been used as an additional criterion for defining the set of core properties for this specification. The resulting set of properties has been validated by another ranking experiment [findtop10]. This ranking is nearly identical to that chosen by the [jpsearch] initiative.

The following information is available for each property:

Several properties in this specification are defined as complex types, consisting of a tuple of attributes. This is used to support qualifiers and optional attributes. Hence, a special syntax has been defined to accommodate this requirement, and is explained below.

All properties are defined in singular and MUST contain only a single value. However, multiple instances of a property MAY be used. In addition, each property MAY have an associated language attribute, which can be used to enable several instances of that property to be defined in different languages.

The following syntax is used for the type descriptions:

  • ( ) (parentheses) are used to group elements

  • | (vertical bar) is used to indicate a choice between different possible values

  • { } (curly brackets) are used to define a complex type

  • ? (question mark) is used to indicate an optional element

Example: { (identifier:URI), (type:String)? } is interpreted as a complex type that has two elements. The first serves the function of uniquely identifying a resource by using an associated URI. The second serves the function of specifying an optional category, which is defined by a string. To indicate this clearly, we enclose each element in parentheses, where the role is placed first, followed by a colon, which is then followed by the element data type; elements are separated by commas, and the final collection of elements that make up the complex type is enclosed in curly brackets.

4.1.3 Core properties

Name Type definition Description
Descriptive Properties (Core Set)
Identification
ma:identifier { (identifier:URI), (type:String)? } A tuple identifying a resource, which can be either an abstract concept (e.g., Hamlet) or a specific object (e.g., an MPEG-4 encoding of the English version of "Hamlet"), using a URI. The type can be used to optionally define the category of the identifier. See use case 4.4 of the Annotating Media Fragments Use Case document. An example of such a tuple would be {urn:uuid:36a87260-1102-11df-8a39-0800200c9a66, UUID}.
ma:title { (title:String), (type:String)? } A tuple that specifies the title or name given to the resource. The type can be used to optionally define the category of the title.
ma:language String The language used in the resource. A controlled vocabulary such as [BCP 47] SHOULD be used.
ma:locator URI The logical address at which the resource can be accessed (e.g. a URL, or a DVB URI).
Creation
ma:contributor { (identifier:(URI|String)), (role:String)? } A tuple identifying the agent, using either a URI or plain text. The role can be used to optionally define the nature of the contribution (e.g., actor, cameraman, director, singer, author, artist, or other role types). The identifier SHOULD be defined as a URI. An example of such a tuple is: {imdb:nm0000318, director}.
ma:creator { (identifier:(URI|String)), (role:String)? } A tuple identifying the author of the resource, using either a URI or plain text. The role can be used to optionally define the category of author (e.g., playwright or author). The identifier SHOULD be defined as a URI. The role is defined as plain text. An example of such a tuple is: {dbpedia:Shakespeare, playwright}.
ma:createDate { (date:Date), (type:String)? } A tuple defining the date and time that the resource was created. The type can be used to optionally define the category of creation date (e.g., release date, date recorded, or date edited).
ma:location { (name:(URI|String))?, ((longitude:Float), (latitude:Float), (altitude:Float), (coordinateSystem:String)?)?, } A tuple identifying an optional name and/or optional associated data that describe where the resource has been created, developed, recorded, or otherwise authored. The optional name can be defined using either a URI or plain text; however, the name SHOULD be defined as a URI. The optional location data MAY include longitude, latitude, and/or altitude information, and it MAY also define a coordinate system that can be used to interpret these measurements.
Content description
ma:description String Free-form text describing the content of the resource.
ma:keyword URI|String A concept, descriptive phrase or keyword that specifies the topic of the resource, using either a URI or plain text. The identifier SHOULD be defined as a URI. In addition, the concept, descriptive phrase, or keyword contained in this element SHOULD be taken from an ontology or a controlled vocabulary.
ma:genre URI|String The category of the content of the resource, using either a URI or plain text. The identifier SHOULD be defined as a URI. In addition, the genre contained in this element SHOULD be taken from an ontology or controlled vocabulary, such as the EBU vocabulary.
ma:rating { (value:Float), (identifier:(URI|String))?, ((min:Float), (max:Float))? } A tuple defining the rating value, an optional rating person or organization defined as either a URI or as plain text, and an optional voting range. The identifier SHOULD be defined as a URI. The voting range can optionally be used to define the minimum and maximum values that the rating can have.
Relational
ma:relation { (identifier:URI), (relation:String)? } A tuple that identifies a resource that the current resource is related with (using either a URI or plain text), and optionally, specifies the nature of the relationship. The identifier SHOULD be defined as a URI. An example is a listing of content that has a (possibly named) relationship to another content, such as the trailer of a movie, or the summary of a media resource.
ma:collection URI|String The name of the collection (using either a URI or plain text) from which the resource originates or to which it belongs. The collection SHOULD be defined as a URI.
Rights
ma:copyright { (copyright:String), (identifier:URI)? } A tuple containing the copyright statement associated with the resource and optionally, the identifier of the copyright holder. Other issues related to Digital Rights Management are out of scope for this specification.
ma:policy { (policy:URI|String), (type:String)? } A tuple that contains a description of the security policy that MUST be applied to the media resource, or a reference to the security policy (e.g., Creative Commons). This element is defined using either a URI or plain text. The policy SHOULD be defined as a URI. In addition, the type attribute can optionally be used to provide more information as to the nature of the security policy (e.g., permissions, access control, or ownership).
Distribution
ma:publisher URI|string The publisher of a resource, defined as either a URI or plain text. The publisher SHOULD be defined as a URI.
ma:targetAudience { (identifier:URI), (classification:String) } A tuple identifying the issuer of the classification (e.g., a parental guidance issuing agency, or a targeted geographical region) and the value given in this classification.
Fragment
ma:fragment { (identifier:URI), (role:String)? } A tuple containing a fragment identifier and optionally, its role. A fragment is a portion of the resource, as defined by the [MediaFragment] Working Group.
ma:namedFragment { (identifier:URI), (label:String) } A tuple containing a named fragment identifier and its label.
Technical Properties
ma:frameSize { (width:Float), (height:Float), (unit:String)? } A tuple defining the frame size of the resource (e.g., width and height of 720 and 480 units, respectively). The units can be optionally specified; if the units are not specified, then the units MUST be interpreted as pixels.
ma:compression String The compression type used. For container files (e.g., QuickTime, AVI), the compression is not defined by the format, as a container file can have several tracks that each use different encodings. In such a case, several ma:compression instances SHOULD be used. Thus, querying the ma:compression property of the track media fragments will return different values for each track fragment. Note: it is possible to use an extended MIME type as the value for this property, see [RFC 4281].
ma:duration Float The actual duration of the resource. The units are defined to be seconds.
ma:format String TheMIME type of the resource (e.g., wrapper or bucket media types).
ma:samplingrate Float The audio sampling rate. The units are defined to be samples/second.
ma:framerate Float The video frame rate. The units are defined to be frames/second.
ma:averageBitrate Float The average bit rate. The units are defined to be kbps.
ma:numTracks { (number:Integer), (type:String)? } A tuple defining the number of tracks of a resource, optionally followed by the type of track (e.g., video, audio, or subtitle).

A number of these properties use qualifiers to define subtypes and roles. In particular, these are the properties identifier, title, contributor, creator, createDate, relation, collection, policy, fragment and numTracks. In addition, the location, rating, copyright, and frameSize properties use optional elements to define how other element values are measured, or the ranges that the values of these elements can have, or other supplementary information. All subtype and role qualifiers for these properties are optional. The set of possible values for subtypes is not normative. However, whenever possible, values defined in an existing vocabulary or classification scheme SHOULD be used.

4.2 Property mapping table

4.2.1 Rationale regarding the mapping table

The mappings between the Media Ontology and a subset of the "in-scope" vocabularies of this specification are defined. These mappings specify both the semantic and some elements of the syntactic correspondences between the Media Ontology and the properties of a given vocabulary. The vocabularies selected were those that were deemed to be the most popular and useful, and which the Working Group had prior expertise concerning their usage. The purpose of these mappings is to provide a proof of concept, as a first step towards the creation of a global mapping list involving all of the vocabularies in scope.

4.2.1.1 Semantic Level Mappings

The presented mappings are uni-directional mappings. This is because the semantics of the property being mapped between the Media Ontology and another property may be very different. For example, ma:copyright is mapped to both xmpDM:copyright and dc:rights (as part of the XMP standard [XMP]); the same property is mapped to exif:Copyright (see [EXIF]). Unfortunately, no semantic relationship can be inferred between the properties defined in the XMP and EXIF standards. The mappings that have been taken into account have different semantics that have one of the following four characteristics:

  • Exact match: the semantics of the two properties are equivalent in all possible contexts. For example, the semantics of the property ma:title actly matches the semantics of the property vra:title.

  • More specific: the property of the vocabulary taken into account has associated semantics that contain a superset of the semantics expressed by the property defined in this specification. For example in DIG35, ipr_names@description and ipr_person@description are both more specific than the property ma:publisher to which they are mapped.

  • More generic: the inverse of the above, meaning that the property of the vocabulary taken into account has associated semantics that is broader than the property defined in this specification. For example, the DIG35 location is more general than the ma:location property.

  • Related: the two properties are related in a way that is relevant for some use cases, but this relation has no defined and/or commonly applied semantics. For example, in Media RSS, media:credit is related to ma:creator.

This list of relations between vocabularies (or informal mappings) and the "Core Media Properties list" is published as a table. Feedback from people or companies actually using the different vocabularies in communities that are currently using the different vocabularies is very welcome; if such feedback is received, then a future version of this specification will incorporate this feedback into the affected mappings.

4.2.1.2 Syntactic Level Mappings

Syntactic level mappings define the correspondence between two similar properties that have different syntactic expressions, but generally similar associated semantics. For example, one important use case is date formatting, where the format of the date and/or time used is different in two vocabularies, but the overall semantics (identifying a date and/or time) is the same.

4.2.1.3 Mapping expression

The mapping expression corresponds to the concrete implementation or representation of the mappings defined in the previous paragraph, both at a semantic level and at syntactic one.

SKOS is the acronym for the Simple Knowledge Organization System, which is currently a Recommendation of the W3C Semantic Web activity. It defines a vocabulary for representing Knowledge Organization Systems, such as vocabularies, and relationships amongst them. In SKOS the mapping properties that we take into account in the mapping table are expressed as: skos:exactMatch, skos:narrowMatch, skos:broadMatch and skos:relatedMatch. A future version of this specification MAY include additional information after interoperability and/or other feedback mechanisms have been completed. For example, it could be possible to further specify the characteristics and behavior of some properties (e.g., if they are symmetric) to enhance more efficient concrete mappings. If such changes are performed, then every effort will be made to produce a new and revised specification that is backwards-compatible with the current version of this specification.

4.2.2 The mapping table

The following mappings are established from the Media Ontology's core properties to various multimedia metadata formats. This list of formats is not closed, nor does it pretend to be exhaustive. A future version of this specification MAY include additional mappings if a need or use case is established for these new mappings.

4.2.2.1 CableLabs 1.1
4.2.2.2 DIG
4.2.2.3 EBUCore
4.2.2.4 EXIF
4.2.2.5 ID3
4.2.2.6 IPTC
4.2.2.7 LOM
4.2.2.8 MediaRDF
4.2.2.9 MediaRSS
4.2.2.10 METS
4.2.2.11 MPEG7
4.2.2.12 OGG
4.2.2.13 SMTPD
4.2.2.14 TVA
4.2.2.15 TXFeed
4.2.2.16 XMP
4.2.2.17 YouTube

5 Conformance Requirements

This section is normative.

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC 2119]

A "strictly conforming" application is one that satisfies all "MUST" and "SHALL" provisions in this document. In contrast, a "conditionally conforming" application is one that satisfies all "MUST" provisions in this document, but not all "SHALL" provisions. It should be noted that an application that does not specify all "MUST" provisions in this document is not conforming".

A References (Normative)

[Cablelabs 1.1]
CableLabs VOD Content Specification Version 1.1. Available for download at http://www.cablelabs.com/specifications/MD-SP-VOD-CONTENT1.1-I05-060831.pdf .
[DIG35]
DIG35 Specification - Metadata for Digital Image. April 2001. Available for download at http://www.bgbm.org/TDWG/acc/Documents/DIG35-v1.1WD-010416.pdf .
[DMS-1]
DMS-1 (SMPTE 380M-2004). April 2001. Available for download at http://www.smpte.org/standards .
[Dublin Core]
DCMI Metadata Terms. January 2008. Available for download at http://dublincore.org/documents/2008/01/14/dcmi-terms/ . The latest version of DCMI Metadata Terms is available at http://dublincore.org/documents/dcmi-terms/ .
[EBUCore]
EBUCore v.1.0. December 2008. Available for download at http://tech.ebu.ch/docs/tech/tech3293-2008.pdf .
[EXIF]
EXIF 2.2. Specification by JEITA, April 2002. Available for download at http://www.exif.org/Exif2-2.PDF .
[LOM]
Draft Standard for Learning Object Metadata. July 2002. Available for download at http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf .
[ID3]
ID3 tag version 2.4.0. February 1999. Available for download at http://www.id3.org/Developer_Information .
[IPTC]
IPTC Standard Photo Metadata 2008. IPTC Core Specification Version 1.1, IPTC Extension Specification Version 1.0, Document Revision 2, June 2008. Available for download at http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf
[IPTC NewsML]
IPTC NewsML-G2. Available for download at http://www.iptc.org/cms/site/ .
[METS]
Metadata Encoding & Transmission Standard 1.7. Available for download at http://www.loc.gov/standards/mets/ .
[Media RDF]
Media RDF. Available for download at http://digitalbazaar.com/media/video .
[Media RSS]
Yahoo! Media RSS Module - RSS 2.0 Module. March 2008. Available for download at http://video.search.yahoo.com/mrss .
[MPEG-7]
Information technology — Multimedia content description interface — Part 10: Schema definition. Available for download at http://www.chiariglione.org/mpeg/working_documents/mpeg-07/schema_def/cd.zip .
[SMPTE]
SMPTE Metadata. Available for download at http://www.smpte-ra.org/mdd/RP210v11-pub-20080415.2048.xls .
[TXFeed]
TXFeed standard 0.9. December 2007. Available for download at http://clearerchannel.org/docs/tx_metadata_standard_0_9.pdf .
[TV-Anytime]
ETSI 102 822-3-1 V1.4.1. November 2007. Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems("TV-Anytime"). Part 3: Metadata, Sub-part 1: Phase 1 - Metadata schemas .
[XMP]
XMP Specification Part 2 - Standard Schemas. Adobe, 2008. Available for download at http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf .
[YouTube Data API Protocol]
YouTube Data API Protocol. April 2008. Available for download at http://code.google.com/intl/en/apis/youtube/2.0/reference.html .

B References (Non-Normative)

[BCP 47]
BCP 47 (Tags for Identifying Languages), A. Phillips and M. Davis, Editors. Available for download at http://www.rfc-editor.org/rfc/bcp/bcp47.txt .
[findtop10]
Find the "top 10" of multimedia categories . Available for download at http://lists.w3.org/Archives/Public/public-media-annotation/2009Jun/0068.html .
[FRBR]
A URI space for vocabularies. October 2005. Available for download at http://vocab.org/frbr/core.html .
[HTML 5]
Hickson, I., and D. Hyatt. HTML 5. A vocabulary and associated APIs for HTML and XHTML. W3C Working Draft, June 2008. Available at http://www.w3.org/TR/2008/WD-html5-20080610/ . The latest version of HTML 5 is available for download at http://www.w3.org/TR/html5/ .
[jpsearch]
Mario Döller, Florian Stegmaier, Harald Kosch, Ruben Tous, and Jaime Delgado, "Standardized Interoperable Image Retrieval", ACM Symposium on Applied Computing (SAC), Track on Advances in Spatial and Image-based Information Systems (ASIIS), 2010 .
[KEUO]
J. Strassner, "Knowledge Engineering Using Ontologies", Handbook of Network and System Administration, edited by J. Bergstra and M. Burgess, Chapter 3, Section 4, pages 425-457, ISBN 9780444521989 .
[MediaFragment]
W3C Working Group on Media Fragments. Available for download at http://www.w3.org/2008/WebVideo/Fragments/ .
[MIME]
Freed, N., Borenstein, N. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. November 1996. Available for download at http://www.ietf.org/rfc/rfc2046.txt .
[MPEG-21]
ISO/IEC TR 21000-1:2001 - Information technology -- Multimedia framework (MPEG-21) -- Part 1: Vision, Technologies and Strategy. Available for download at http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=30819 .
[MWG Guidelines Image]
Guidelines for handling image metadata, version 1.0.. Metadata Working Group, September 2008. Available for download at http://www.metadataworkinggroup.com/pdf/mwg_guidance.pdf .
[PLING]
PLING W3C Open Forum The W3C Policy Languages Interest Group - PLING - is an open forum to discuss use cases, languages, and frameworks around information governance policies.
[RDF]
Resource Description Framework (RDF). W3C RDF Working Group. Available for download at http://www.w3.org/RDF/ .
[RFC 2119]
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Internet Engineering Task Force, 1997.
[RFC 3986]
Berners-Lee, T., R. Fielding, L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. RFC 3986, January 2005. Available for download at http://www.ietf.org/rfc/rfc3986.txt
[RFC 3987]
Dürst, M. and M. Suignard. Internationalized Resource Identifiers (IRIs). RFC 3987, January 2005. Available for download at http://www.ietf.org/rfc/rfc3987.txt.
[RFC 4281]
Gellens, R., Singer, D., and P. Frojdh. The Codecs Parameter for "Bucket" Media Types. RFC 4281, November 2005. Available for download at http://www.ietf.org/rfc/rfc4281.txt.
[RFC 4646]
Phillips, A., Ed. and M. Davis, Ed. Tags for Identifying Languages. RFC 4646, September 2006. Available for download at http://www.rfc-editor.org/rfc/rfc4646.txt.
[XML Schema 2]
Biron, P. V. and A. Malhotra. XML Schema Part 2: Datatypes Second Edition. W3C Recommendation, October 2004. Available for download at http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ . The latest version of XML Schema Part 2 is available for download at http://www.w3.org/TR/xmlschema-2/ .

C Acknowledgements (Non-Normative)

This document is the work of the W3C Media Annotations Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order): Werner Bailer (JOANNEUM RESEARCH), Tobias Bürger (University of Innsbruck), Eric Carlson (Apple, Inc.), Pierre-Antoine Champin ((public) Invited expert), Ashish Chawla ((public) Invited expert), Jaime Delgado (Universitat Politècnica de Catalunya), Jean-Pierre EVAIN ((public) Invited expert), Philip Jägenstedt (Opera Software), Ralf Klamma ((public) Invited expert), WonSuk Lee (Electronics and Telecommunications Research Institute (ETRI)), Véronique Malaisé (Vrije Universiteit), Erik Mannens (IBBT), Hui Miao (Samsung Electronics Co., Ltd.), Thierry Michel (W3C/ERCIM), Frank Nack (University of Amsterdam), Soohong Daniel Park (Samsung Electronics Co., Ltd.), Silvia Pfeiffer (W3C Invited Experts), Chris Poppe (IBBT), Víctor Rodríguez (Universitat Politècnica de Catalunya), Felix Sasaki (Potsdam University of Applied Sciences), David Singer (Apple, Inc.), Florian Stegmaier ((public) Invited expert), John Strassner ((public) Invited expert), Joakim Söderberg (ERICSSON), Thai Wey Then (Apple, Inc.), Ruben Tous (Universitat Politècnica de Catalunya), Raphaël Troncy (CWI), Vassilis Tzouvaras (K-Space), Davy Van Deursen (IBBT).

The people who have contributed to discussions on public-media-annotation@w3.org are also gratefully acknowledged.