Candidate Additional Elements

This page collects feedback on elements that are considered candidates for extending the first set of elements.

Open Issues

Descriptive metadata elements

Accessibility metadata

e.g. link to transcript, what 'axes' the media can be adapted -- such as closed captions, audio description of video, video contrast

• proposed in [1]
• comment from PFWG [2]: request elements for referencing alternate versions, including transcriptions, captions, ...) and resources required to play a reseource

Fictional character

Specify fictional character impersonated by a contributor with role "actor".

This is supported in the metadata set of the Timed Text WG, for comparison of metadata sets see [3]

Discovery of tracks

• raised in [4], partly related to accessibility metadata
• use metadata to get a list of tracks and their names
• required change is to use ma:fragments also for track fragments, one could then query name, type, etc. for each of the tracks
• could be used to implement the HTML5 Media MultiTrack API

Metadata available in Ogg but not in MAWG

• raised in [5]

Contact

contact information for the creators or distributors of the data; could be a URL, email address, or physical address

Encoder

information about the encoding software of the metadata

Technical metadata elements

general comments

• [6], [7], [8] warn from adding technical metadata elements, as this could make the ontology grow significantly
• [9] suggests that there needs to be a clear application scenario on the user agent side for each technical metadata property to be added
• [10] points out that the use cases Access via web client to metadata in heterogeneous formats and Multimedia adaptation require some technical metadata elements
• [11] proposes profiles for the ontology to support specific needs of some use cases
• work on annotative queries and format queries, in some of these the proposed technical elements are necessary [12]

Media types

At F2F 4, we have introduced media types for which certain technical properties are relevant. If necessary, this could evolve into media specific profiles.

The following media types have been considered:

• image
• video
• audio
• text (e.g. subtitles)

What about other media types? e.g. 3D scenes/models?

Requires

From [13]:

It would be important to have a property corresponding to DCMI Metadata Terms requires http://dublincore.org/documents/dcmi-terms/#terms-requires. This would be to indicate if the media requires something else to be played. If it requires something else known to be inaccessible on the user's system, then the media could be known to be unplayable from its metadata.

Metadata on metadata

Some metadata formats support the annotation of the metadata itself. Examples are the creation date, creator, and language of the metadata that describes a media resource. An open issue is whether we want to support this.

Resolved Issues

Descriptive metadata elements

Tag Line

Used as a kind of advertising claim for movies, a kind of subtitle

• proposed in [14]
• supported by [15] and [16]
• agreed in telco on 2009-05-12 that this could be represented by Title element with appropriate qualifier
• decided to define as specific title in F2F 4

Media resource representing content

Reference to media resource such as thumbnails, trailer, etc.

• proposed in [17]
• supported by [18]
• [19] suggests to use the Relation element
• agreed in telco on 2009-05-12 that this could be represented by Relation element with appropriate qualifier
• decided to define as specific relation in F2F 4

Rights

the group should not dig into the complexity of rights expressions but rights are a crucial aspect of any media consumption task and thus the property should be kept, so people are able to point to a (more complex) rights expression

• proposed in [20]
• ma:license has been added in F2F 4

List of fragments

list of spatial, temporal or named fragments indicating e.g. favourite/interesting scenes

• proposed in [21], clarified in [22]
• could be both user supplied or source supplied [23]
• ma:fragments has been added in F2F 4

Technical metadata elements

Number/type of tracks

in order to defining the range of possible values for the different types of fragments

• for spatial and temporal fragments, this is already defined by frame width/height and duration
• for track fragments this would require describing the list/type of channels

• proposed in [24]
• ma:numTracks has been added at F2F 4

Sample type/depth

could be useful at least in a limited way, e.g. to express black/white or color, in some application (e.g. medical imaging) a more precise specification could be helpful

• proposed in [25]
• decided at F2F 4 that it is not needed

File size/bit rate

could be useful for media to be downloaded/streamed

• proposed in [26]

• ma:bitrate has been added at F2F 4, if we have ma:duration and ma:bitrate (average bitrate of resource) we don't need ma:datasize, it can be computed if the other two makes sense

Temporal sampling rate

spatial sampling rate is included, so temporal sampling rate could be useful as well

• proposed in [27]
• ma:framerate and ma:samplingrate added at F2F 4