video-metadata-model

Getting Started On A Harmonized Video Metadata Model

Lisa Rein - Bloqx, lisa@lisarein.com

The Problem Space

Currently, video objects are very hard to search for on the web. There a lack of a simple taxonomy for users to implement, and most of the technology used to derive meaning is basically dependent on what text is available from a corresponding web page.

With the emergence of video tools that both allow for some information to be embedded within the files themselves and/or prompt a user to enter such metadata before the file is generated, it is more important than ever to attempt to construct a core set of elements to facilitate metadata interoperability.

Perhaps a vocabulary based on the information that can be derived from the object itself, while also providing a framework for users to include additional data about a media object, if so desired, would be most useful.

This number one goal of this vocabulary would be to enable metadata compatibility between both existing and new types of services and applications. An element set that could be used by many different variations of metadata-based applications and services.

The idea is to create a practical, easy-to-use element set that can both be implemented quickly by software developers and archivists, while also being intuitive to artists, photographers, film makers etc. A metadata system that makes sense to artists will encourage them to become more involved and add more information about their works.

One starting point could be to begin with a dc-compatible subset that is already in use by numerous applications (and that, by definition, ensures compatibility with all W3C Metadata Formats), and build from there a larger framework capable of encompassing all media objects.

Every attempt should be made to be compatible with the following vocabularies, and, most likely, several others: Dublin Core Metadata Element Set, SMIL (Synchronized Multimedia Integration Language), Media RSS, and the Internet Archive's metadata format.

Existing Video Metadata Archive Vocabularies

DCMI Dublin Core Metadata Element Set http://dublincore.org/documents/dces/

The Dublin Core metadata element set is a standard for cross-domain information resource description. Here an information resource is defined to be "anything that has identity". This is the definition used in Internet RFC 2396, "Uniform Resource Identifiers (URI): Generic Syntax", by Tim Berners-Lee et al. There are no fundamental restrictions to the types of resources to which Dublin Core metadata can be assigned.

Media RSS http://search.yahoo.com/mrss

Media RSS is a vocabulary for use with RSS 2.0s "enclosure" element to enable more detailed metadata to be included with media object syndication. (Note: You will need an enclosure-aware RSS reader to take advantage of the content within RSS 2.0 Enclosures. FireANT http://www.antisnottv.net/?q=download is one such RSS reader.

SMIL (Synchronized Multimedia Integration Language) http://www.w3.org/TR/SMIL/ http://www.w3.org/TR/2005/REC-SMIL2-20050107/metadata.html#q6

SMIL is a W3C Recommendation for an XML-based language for expressing the properties of largely web-based multimedia presentations. SMIL includes temporal behavior, methods for associating hyperlinks with a media object, and describing layout presentation on a screen. (Scalable Vector Graphics SVG - note that it can be used to draw video boxes http://www.w3.org/TR/SVG/metadata.html#MetadataElement)

OurMedia http://www.ourmedia.org/tools OurMedia provides hosting for user generated media. OurMedia's metadata format conforms to the Internet Archive's metadata format.

Internet Archive - Movie Database Metadata Format http://www.archive.org/details/movies The Internet Archive is an attempt at archiving everything on the web, and really, all text and documentation, whether or not it was ever meant to be on the web. The Moving Images archive provides users with the ability to upload their own films and associate some very simple metadata with the files to provide for better search.

Creative Commons http://www.creativecommons.org Creative Commons provides a set of alternative copyright licenses and a metadata format for expressing the terms of those licenses.

Compatibility Table

It is important that any newly-emerging video metadata format be compatible with the metadata formats already in extensive use within existing media archives.

Some of these, such as the Internet Archive's format, were designed to be compatible with the Dublin Core Metadata Element Set, so compatibility is easy. Others use different names, but the models are similar, and so it is simple to do a one-to-one mapping between the varying elements.

.html

Bloqx Element	Description	Dublin Core	Media RSS	SMIL	Internet Archive
identifier	The URL of the movie (video object).	identifier	the "url" attribute of the "content" element	resource	link
title	The name of the movie.	title	title	title	title
creator	The creator of the movie.	creator	tbd	creator	creator
date	Date that the movie was created -- could also be date the movie was uploaded and made available via a URL. DCMI Best Practice to use the ISO 8601 profile for date format: YYYY-MM-DD.	date	tbd	date	date (contains year eg: "2004"), also "publicdate" in the correct format. Our "date" seems that it is more compatible with "publicdate."
format	The format of the video file: Quicktime, Windows Media, MPEG, etc. (Mime type)	format	"type" attribute of the "content" element	format	format
rights	A URL for a text-based explanation of the movie's licensing terms.	rights	tbd	rights (contains text description rather than a url)	licenseurl
subject	A set of keywords describing the topic of the movie.	subject	tbd	subject	subject
description	Provides a text-based description of the movie.	description	description	description	description

.html

Other Compatibility Considerations

It would be a good idea to consider designing our model to be compatible with most audio and still picture metadata formats, since it is likely that these types of objects would be generated and associated with the video objects we are describing. Also, one might want to compare the soundtrack information of a .mov file with that of an .mp3, etc.. For these reasons, it will be important to maintain one to one element relationships between the semantics of the different vocabularies whenever possible. Some of these formats include the Flickr, itunes, the Internet Archive's audio archive format.

The following is a list of the various elements that could be contained in a video metadata file.

At minimum, a metadata entry would contain the URL of the movie file (identifier), the date the URL was submitted (date), and the name of the person who submitted the metadata (uploader or creator).

The date and name can be added automatically, because, theoretically, a user would have to be logged in to enter metadata.

The below list represents one possible "core" subset of elements for more simple implementations. A more detailed description of elements is also provided after the list itself.

Suggested Core Elements:

1. identifier (dc)

The URL of the movie file.

2. title (dc)

The title of the movie.

3. creator (dc)

The creator of the movie.

4. date (dc)

Date that the movie was uploaded (made available via a URL).

This value is automatically added when the metadata is initially entered into the service.

DCMI Recommended Best Practice is to use the ISO 8601 profile for date format: YYYY-MM-DD.

5. subject (dc)

A list of keywords describing the content of the movie. (This is where subject words of a formal classification scheme would be used.)

6. format (dc)

Format of the video file: Quicktime, Windows Media, etc. DCMI Recommended Best Practice is to use MIME type information.

7. rights (dc)

A URL to a text-based description of the movie's licensing terms.

8. description - used as a container for "abstract"

9. comment

10. latitude

11. longitude

12. contributor (dc)

A person or organization who has contributed to the content of the resource.

13. rightsholder (dc)

A person or organization owning or managing rights over the resource. Recommended best practice is to use the URI or name of the Rights Holder to indicate the entity.

14. filesize

15. filename

16. duration

17. hash

A SHA-1 Hash value for the file.

Other optional elements could include:

- codec (Sorensen, etc.) - person - image (for that person) - director - producer - aspectradio - framerate - number of audio channels - sample rate