WD-media-annot-reqs-20100121 53.5 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
  <title>Use Cases and Requirements for Ontology and API for Media Resource
  1.0</title>
  <style type="text/css">
 /**/
code           { font-family: monospace; }
div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }
ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }
dt.label       { display: run-in; }
li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }
 .diff-chg       { background-color: yellow; }
 .diff-del       { background-color: red; text-decoration: line-through;}
 .diff-add       { background-color: lime; }
table          { empty-cells: show; }
table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}
div.issue {
  color: red;
}
 .rfc2119 {
  font-variant: small-caps;
}
div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
div.boxedtext {
   border: solid #bebebe 1px;
   margin: 2em 1em 1em 2em;
 }
span.practicelab {
   margin: 1.5em 0.5em 1em 1em;
   font-weight: bold;
   font-style: italic;
 }
span.practicelab   { background: #dfffff; }
 span.practicelab {
   position: relative;
   padding: 0 0.5em;
   top: -1.5em;
 }
p.practice
{
   margin: 1.5em 0.5em 1em 1em;
 }
@media screen {
 p.practice {
   position: relative;
   top: -2em;
   padding: 0;
   margin: 1.5em 0.5em -1em 1em;
}
}
/**/ </style>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/base.css" />
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
</head>

<body>

<div class="head">
<p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72" /></a></p>

<h1><a name="title" id="title"></a>Use Cases and Requirements for Ontology and
API for Media Resource 1.0</h1>

<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 21 January
2010</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121">http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/media-annot-reqs">http://www.w3.org/TR/media-annot-reqs</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604">http://www.w3.org/TR/2009/WD-media-annot-reqs-20090604</a></dd>
  <dt>Editors:</dt>
    <dd>WonSuk Lee, Electronics and Telecommunications Research Institute
    (ETRI)</dd>
    <dd>Tobias Bürger, University of Innsbruck</dd>
    <dd>Felix Sasaki, Potsdam University of Applied Sciences</dd>
    <dd>Véronique Malaisé, VU University of Amsterdam</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
2010 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.eu/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr />

<div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2>

<p>This document specifies use cases and requirements as an input for the
development of the "Ontology for Media Resource 1.0" and the "API for Media
Resource 1.0". The ontology will be a simple ontology to support
cross-community data integration of information related to media resources on
the Web. The API will provide read access and potentially write access to media
resources, relying on the definitions from the ontology. </p>

<p>The main scope of this document are videos. Metadata for other media
resources like audio or images will be taken into account if it is applicable
for videos as well.</p>
</div>

<div>
<h2><a name="status" id="status"></a>Status of this Document</h2>

<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>

<p>This is an updated Working Draft of the Use Cases and Requirements for
Ontology and API for Media Object 1.0 specification. It has been produced by
the <a href="http://www.w3.org/2008/WebVideo/Annotations/">Media Annotations
Working Group</a>, which is part of the <a
href="http://www.w3.org/2008/WebVideo/">W3C Video on the Web Activity</a>. The
purpose of this publication is to reflect the progress of the Working Group.
There are still topics e.g. in the area of terminology about which the Working
Group has not reached consensus.</p>

<p>A <a href="#change-log">list of changes</a> to the previous version of this
document is available.</p>

<p>Please send comments about this document to <a
href="mailto:public-media-annotation@w3.org">public-media-annotation@w3.org</a>
mailing list (<a
href="http://lists.w3.org/Archives/Public/public-media-annotation/">public
archive</a>).</p>

<p>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. </p>

<p>This document was produced by a group operating under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C
Patent Policy</a>. W3C maintains a <a
href="http://www.w3.org/2004/01/pp-impl/42786/status">public list of any patent
disclosures</a> 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 <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>.</p>

<p>The group does not expect this document to become a W3C Recommendation.</p>
</div>

<div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2>

<p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#purpose-of-this-draft">Purpose of this draft publication</a><br />
3 <a href="#scope">Purpose of the Ontology and the API</a><br />
4 <a href="#terminology">Terminology</a><br />
5 <a href="#UseCases">Use Cases</a><br />
    5.1 <a href="#uc-cultural-heritage-institutions">Interoperability
between media resources across Cultural Heritage Institutions</a><br />
    5.2 <a href="#uc-recommendations-across-media-types">Recommendation
across different media types</a><br />
    5.3 <a href="#uc-life-log">Life Log</a><br />
    5.4 <a href="#uc-access-via-web-client">Access via web client to
metadata in heterogeneous formats</a><br />
    5.5 <a href="#uc-user-generated-metadata">User generated
Metadata</a><br />
    5.6 <a href="#uc-tbd">Use cases: to be done</a><br />
6 <a href="#requirements">Requirements</a><br />
    6.1 <a href="#req-r01">Requirement r01: Providing methods for getting
metadata information stored in different formats</a><br />
    6.2 <a href="#req-r02">Requirement r02: Providing methods for setting
metadata information stored in different formats</a><br />
    6.3 <a href="#req-r03">Requirement r03: Providing in the API a means
for supporting structured annotations</a><br />
    6.4 <a href="#req-r04">Requirement r04: Providing a means to access
user-defined metadata</a><br />
    6.5 <a href="#req-r05">Requirement r05: Providing the ontology as a
simple set of properties</a><br />
    6.6 <a href="#req-r06">Requirement r06: Specifying an internal or
external format for the ontology</a><br />
    6.7 <a href="#req-r07">Requirement r07: Introducing several abstraction
levels in the ontology</a><br />
    6.8 <a href="#req-r08">Requirement r08: Being able to apply the
ontology / API for collections of metadata</a><br />
    6.9 <a href="#req-r09">Requirement r09: Supporting the provenance
information of metadata properties</a><br />
    6.10 <a href="#req-r10">Requirement r10: Being able to describe
fragments of media resources</a><br />
    6.11 <a href="#req-r11">Requirement r11: Providing the ontology in
slices of conformance</a><br />
    6.12 <a href="#req-r12">Requirement r12: Providing support for
controlled vocabularies for the values of different properties</a><br />
    6.13 <a href="#req-r13">Requirement r13: Allowing for different return
types for the same property</a><br />
    6.14 <a href="#req-r14">Requirement r14: Providing support for policy
information</a><br />
    6.15 <a href="#req-r15">Requirement r15: Providing support for
discovery of named and track fragments</a><br />
</p>

<h3><a name="appendices" id="appendices"></a>Appendices</h3>

<p class="toc">A <a href="#references-normative">References</a><br />
B <a href="#references-non-normative">References</a> (Non-Normative)<br />
C <a href="#change-log">Change Log</a> (Non-Normative)<br />
D <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
</p>
</div>
<hr />

<div class="body">

<div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2>

<p>Anticipating the increase in online video and audio in the upcoming years,
we can foresee that it will become progressively more difficult for viewers to
find the content using current search tools. In addition, video services on the
web that allow for upload of video, need to display selected information about
the media documents which could be facilitated by a uniform access to selected
metadata across a variety of file formats. </p>

<p>Unlike hypertext documents, it is more complex and sometimes impossible to
deduce meta information about a medium, such as its title, author, or creation
date from its content. There has been a proliferation of media metadata formats
for the document's authors to express this metadata information. For example,
an image could potentially contain <cite><a href="#exif">EXIF</a></cite>,
<cite><a href="#iptc">IPTC</a></cite> and <cite><a href="#xmp">XMP</a></cite>
information. There are also several metadata solutions for media related
content, including <cite><a href="#mpeg-7">MPEG-7</a></cite>, Yahoo! <cite><a
href="#mediarss">MEDIA RSS</a></cite>, Google <cite><a
href="#videositemaps">Videositemaps</a></cite>, <cite><a
href="#vodcsv">VODCSV</a></cite>, <cite><a
href="#tvanytime">TVAnytime</a></cite> and <cite><a href="#ebu-p-metadata">EBU
P-Meta</a></cite>. Many of these formats have been extensively discussed in the
deliverables <cite><a href="#xgr-vocabularies">XGR Vocabularies</a></cite> and
<cite><a href="#xgr-image-annotation">XGR Image Annotation</a></cite> of the <a
href="http://www.w3.org/2005/Incubator/mmsem/ ">W3C Multimedia Semantics
Incubator Group </a>, which provide a major input to this Working Group.</p>

<p>The "Ontology for Media Resource 1.0" will address the intercompatiblity
problem by providing a common set of properties to define the basic metadata
needed for media resources and the semantic links between their values in
different existing vocabularies. It will help circumventing the current
proliferation of video metadata formats by providing full or partial
translation and mapping from properties in formats to a common set of
properties in the ontology. The ontology will be accompanied by an API that
provides uniform access to all elements defined by the ontology. </p>

<p>This document specifies the use cases and requirements that are motivating
the development of the "Ontology for Media Resource 1.0". The scope is mainly
video media resources, but we take also other media resources into account if
their metadata information is related to video.</p>

<p>The development of the requirements has three major inputs: Use cases,
analysis of existing standards, and a description of canonical media
processes.</p>
</div>

<div class="div1">
<h2><a name="purpose-of-this-draft" id="purpose-of-this-draft"></a>2 Purpose of
this draft publication</h2>

<p>This initial version of this document contains only a small set of use cases
and requirements. Nevertheless it is being published to gather wide feedback on
the general direction of the Working Group. Hence, we would like to encourage
especially feedback on <a href="#requirements"><b>6 Requirements</b></a>, the
requirements which we are planning to implement, or others which we are
planning not to take into account.</p>

<p>Currently, there is an additional section under development, describing a
top-down modeling approach to describe the media annotation problem. The
Working Group is considering to publish that section in an updated version of
this document.</p>
</div>

<div class="div1">
<h2><a name="scope" id="scope"></a>3 Purpose of the Ontology and the API</h2>

<p>The following figure visualizes the purpose of the ontology, the purpose of
the API and their relation to applications.</p>
<img
src="http://www.w3.org/2008/WebVideo/Annotations/drafts/media-req/MediannScope.png"
alt="Purpose of the ontology and the API" />

<p>The ontology will define mappings from properties in formats to a common set
of properties. The API then will define methods to access heterogeneous
metadata, using such mappings. An example: the property <code>createDate</code>
from XMP <cite><a href="#xmp">XMP</a></cite> can be mapped to the property
<code>DateCreated</code> from IPTC <cite><a href="#iptc">IPTC</a></cite>.</p>

<p>An important aspect of the above figure is that everything visualized above
the API is left to applications. For example.</p>
<ul>
  <li><p>languages for simple or complex queries</p>
  </li>
  <li><p>analysis of user preferences (like "preferring movies with actor X and
    suitable for children")</p>
  </li>
  <li><p>other mechanisms for accessing metadata</p>
  </li>
</ul>

<p>The ontology and the API provide merely a basic, simple means of
interoperability for such applications.</p>
</div>

<div class="div1">
<h2><a name="terminology" id="terminology"></a>4 Terminology</h2>

<p>The keywords <strong>MUST</strong>, <strong>MUST NOT</strong>,
<strong>SHOULD</strong> and <strong>SHOULD NOT</strong> are to be interpreted
as defined in <cite><a href="#rfc2119">RFC 2119</a></cite>.</p>
</div>

<div class="div1">
<h2><a name="UseCases" id="UseCases"></a>5 Use Cases</h2>

<div class="div2">
<h3><a name="uc-cultural-heritage-institutions"
id="uc-cultural-heritage-institutions"></a>5.1 Interoperability between media
resources across Cultural Heritage Institutions</h3>

<p>Summary: Accessing media collections of different cultural heritage
institutions (libraries, museums, archives, etc.) on the Web.</p>

<p>Related requirements:</p>
<ul>
  <li><p><a href="#req-r01">Requirement r01: Providing methods for getting
    metadata information stored in different formats (querying the
    collections)</a></p>
  </li>
  <li><p><a href="#req-r02">Requirement r02: Providing methods for setting
    metadata information stored in different formats (annotating the
    collections, or adding metadata to the agregated result, for
    example)</a></p>
  </li>
  <li><p><a href="#req-r03">Requirement r03: Providing in the API a means for
    supporting structured annotations</a></p>
  </li>
  <li><p><a href="#req-r04">Requirement r04: Providing a means to access
    user-defined metadata </a></p>
  </li>
  <li><p><a href="#req-r07">Requirement r07: Introducing several abstraction
    levels in the ontology</a></p>
  </li>
  <li><p><a href="#req-r08">Requirement r08: Being able to apply the ontology /
    API for collections of metadata</a></p>
  </li>
  <li><p><a href="#req-r09">Requirement r09: Supporting the provenance
    information of metadata properties</a></p>
  </li>
  <li><p><a href="#req-r10">Requirement r10: Being able to describe fragments
    of media resources</a></p>
  </li>
  <li><p><a href="#req-r12">Requirement r12: Providing support for controlled
    vocabularies for the values of different properties</a></p>
  </li>
  <li><p><a href="#req-r14">Requirement r14: Providing support for policy
    information</a></p>
  </li>
</ul>

<p>Description / Example:</p>

<p>The collections of cultural heritage institutions (libraries, museums,
archives, etc.) are increasingly digitised and made available on the Web. These
collections range from text to image, video and audio (music and radio
collections, for example). A comprehensive, professionally created
documentation is usually available, however, often using domain specific or
even proprietary metadata models. This hinders accessing these collections in
an homogeneous or centralized way and linking them across collections. </p>

<p>For example, Jane is a TV journalist searching for material about some event
in contemporary history. She is interested in television and radio broadcasts
from this event, along with photos and newspaper articles. All these resources
come from different collections, and some are in different languages. A
homogeneous way of accessing them across the Web would improve her work.</p>
</div>

<div class="div2">
<h3><a name="uc-recommendations-across-media-types"
id="uc-recommendations-across-media-types"></a>5.2 Recommendation across
different media types</h3>

<p>Summary: Accessing heterogeneous media resources metadata as the input to
the creation of recommendations which is based on user preferences.</p>

<p>Related requirements:</p>
<ul>
  <li><p><a href="#req-r01">Requirement r01: Providing methods for getting
    metadata information stored in different formats</a></p>
  </li>
  <li><p><a href="#req-r03">Requirement r03: Providing in the API a means for
    supporting structured annotations</a></p>
  </li>
  <li><p><a href="#req-r05">Requirement r05: Providing the ontology as a simple
    set of properties</a></p>
  </li>
  <li><p><a href="#req-r15">Requirement r15: Providing support for discovery of
    named and track fragments</a></p>
  </li>
</ul>

<p>Description / Example:</p>

<p>People nowadays are able to enjoy large number of programs from different
content providers (broadcasting companies, Internet video website, etc.). To
achieve better user experience, reduce the user's experience of being
overloaded, and hence retain users, some systems provide recommendations based
on the user's history, ratings, or stated preferences. However, different
content providers usually have their specific or proprietary metadata models,
which is one of the key problems faced by recommendation service providers. A
common ontology spanning different metadata sets can allow recommendation
systems to return a better, larger, and more relevant selection than when the
metadata systems are unrelated. </p>

<p>Company A is an IPTV add-value service provider. One of their services is to
recommend programs that users might like, based on their watching history or
explicit rating of programs. In this system, users are able to watch regular TV
programs with electronic program guide (EPG) format metadata, videos such as
from YouTube, with website-specific metadata, etc. In order to perform uniform
and effective recommendation in the absence of a common set of vocabularies,
they would need to design own integrated media annotation model.</p>
</div>

<div class="div2">
<h3><a name="uc-life-log" id="uc-life-log"></a>5.3 Life Log</h3>

<p>Use case summary: combining heterogeneous metadata from life logs, to allow
searching personal life log information, potentially enriched with geolocation
information.</p>

<p>Related requirements:</p>
<ul>
  <li><p><a href="#req-r01">Requirement r01: Providing methods for getting
    metadata information stored in different formats</a></p>
  </li>
  <li><p><a href="#req-r05">Requirement r05: Providing the ontology as a simple
    set of properties</a></p>
  </li>
  <li><p><a href="#req-r14">Requirement r14: Providing support for policy
    information</a></p>
  </li>
  <li><p><a href="#req-r15">Requirement r15: Providing support for discovery of
    named and track fragments</a></p>
  </li>
</ul>

<p>Description / Example:</p>

<p>With modern devices, a person can capture his or her experience, including
all sorts of daily events, by creating images, audios and videos files, and
publish them on the Web. These are called "Life Logs". These Life Logs contain
various information such as time, location, creator's profile, relations
between different people, and even emotion. If accessed via an ontology
providing links between the different metadata used to describe these various
information, a user could easily and efficiently search for his or her personal
Life Log information, including emotional information ( this type of
information can be described using a vocabulary like <cite><a
href="#emotionsml10">Emotions ML 1.0</a></cite>), or geolocation information on
the Web (which can be described using the <cite><a
href="#geolocationapi">Geolocation API</a></cite> specification). Other
people's Life Logs contents could also be searched and accessed via this
ontology.</p>
</div>

<div class="div2">
<h3><a name="uc-access-via-web-client" id="uc-access-via-web-client"></a>5.4
Access via web client to metadata in heterogeneous formats</h3>

<p>Use case summary: Accessing metadata in heterogeneous formats for web
developers</p>

<p>Related requirements:</p>
<ul>
  <li><p><a href="#req-r01">Requirement r01: Providing methods for getting
    metadata information stored in different formats</a></p>
  </li>
  <li><p><a href="#req-r05">Requirement r05: Providing the ontology as a simple
    set of properties</a></p>
  </li>
  <li><p><a href="#req-r15">Requirement r15: Providing support for discovery of
    named and track fragments</a></p>
  </li>
</ul>

<p>Description / Example:</p>

<p>John is developing a JavaScript library for accessing metadata of media
resources (e.g. video) in various formats. These resources are available within
a database, such as that of a search engine indexing the internet or other
web-accessible content (e.g. a corporate repository, library, etc.). His
library can be used to make queries of the media resources like: </p>
<ul>
  <li><p>"Find me all media resources which have been created by a specified
    person"</p>
  </li>
  <li><p>"Find me all media resources which have been created this year" </p>
  </li>
  <li><p>"Find me all videos which are not longer than a specified time"</p>
  </li>
  <li><p>"Extract all user added tags from all media resources available"</p>
  </li>
</ul>

<p>This use case is related to many other use cases. Nevertheless it is
mentioned separately since, at the difference from other requirements, its
implementation requires only a small set of requirements. The difference from
this use case to the Cultural Heritage use case is that the former is very
strongly tied to the requirement of a read-only client side API.</p>
</div>

<div class="div2">
<h3><a name="uc-user-generated-metadata"
id="uc-user-generated-metadata"></a>5.5 User generated Metadata</h3>

<p>Use case summary: Adding or linking to external metadata by different
users.</p>

<p>Related requirements:</p>
<ul>
  <li><p><a href="#req-r01">Requirement r01: Providing methods for getting
    metadata information stored in different formats</a></p>
  </li>
  <li><p><a href="#req-r02">Requirement r02: Providing methods for setting
    metadata information stored in different formats</a></p>
  </li>
  <li><p><a href="#req-r04">Requirement r04: Providing a means to access
    user-defined metadata</a></p>
  </li>
</ul>

<p>Description / Example:</p>

<p>John wants to publish comments on the last movies he has seen on
http://example.cheap-vod.com/ . For each movie, he uses the description
metadata field to provide a personal summary of the movie (with incentive to
see or avoid the movie according to his own opinions), and the ranking
metadata. John is also not satisfied with the genre classification of the
website, so he uses the genre metadata field to provide his appreciation of the
genre with regard to a better scheme. He then publishes these metadata on his
blog (may be in the form of a podcast), but only links to the videos
themselves.</p>

<p>Jane, a friend of John's and another cheap-vod customer, can now configure
her cheap-vod account or her browser, to have John's metadata added to or
replacing the original metadata embedded in each file. </p>

<p>Now Jane wants to study more particularly the characters of the movie. For
making this easier, she defines one custom metadata field for each of the main
characters, and sets these fields to "yes" or "no" for each sequence, to
indicate if they contain that character or not. For example:</p>

<div class="exampleInner">
<pre>&lt;http://example.library.myschool.edu/rose.ogv#some_fragment_identifier&gt;
dc:title "Meeting Tom Baxter" ;
dc:description "Cecilia sees the movie several times when...." ;
custom:cecilia "yes" ;
custom:tom "yes" ;
custom:gil "no" ;
custom:monk "no".</pre>
</div>

<p>In this context, the ontology would enhance the interoperability between
different users.</p>
</div>

<div class="div2">
<h3><a name="uc-tbd" id="uc-tbd"></a>5.6 Use cases: to be done</h3>

<table border="1" summary="Editorial note">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top">In a future draft of this
        document, the following use cases will be spelled out separately,
        integrated into existing use cases or dropped.</td>
    </tr>
  </tbody>
</table>
<ul>
  <li><p>Multimedia adaptation</p>
  </li>
  <li><p>Multimedia presentation</p>
  </li>
  <li><p>Digital imaging lifecycle</p>
  </li>
  <li><p>Accessibility</p>
  </li>
</ul>
</div>
</div>

<div class="div1">
<h2><a name="requirements" id="requirements"></a>6 Requirements</h2>

<p>This sections describes requirements for the ontology and the API. The
Working Group has agreed to implement the following requirements. For the other
requirements, there is no agreement yet, and the Working Group is asking
reviewers of this document for feedback about their implementation.</p>
<ul>
  <li><p><a href="#req-r01"><b>6.1 Requirement r01: Providing methods for
    getting metadata information stored in different formats</b></a></p>
  </li>
  <li><p><a href="#req-r03"><b>6.3 Requirement r03: Providing in the API a
    means for supporting structured annotations</b></a></p>
  </li>
  <li><p><a href="#req-r05"><b>6.5 Requirement r05: Providing the ontology as a
    simple set of properties</b></a></p>
  </li>
  <li><p><a href="#req-r10"><b>6.10 Requirement r10: Being able to describe
    fragments of media resources</b></a></p>
  </li>
  <li><p><a href="#req-r11"><b>6.11 Requirement r11: Providing the ontology in
    slices of conformance</b></a></p>
  </li>
</ul>

<p>The requirements which the Working Group currently does not have agreement
to take into account are the following:</p>
<ul>
  <li><p><a href="#req-r02"><b>6.2 Requirement r02: Providing methods for
    setting metadata information stored in different formats</b></a></p>
  </li>
  <li><p><a href="#req-r04"><b>6.4 Requirement r04: Providing a means to access
    user-defined metadata</b></a></p>
  </li>
  <li><p><a href="#req-r06"><b>6.6 Requirement r06: Specifying an internal or
    external format for the ontology</b></a></p>
  </li>
  <li><p><a href="#req-r07"><b>6.7 Requirement r07: Introducing several
    abstraction levels in the ontology</b></a></p>
  </li>
  <li><p><a href="#req-r08"><b>6.8 Requirement r08: Being able to apply the
    ontology / API for collections of metadata</b></a></p>
  </li>
  <li><p><a href="#req-r09"><b>6.9 Requirement r09: Supporting the provenance
    information of metadata properties</b></a></p>
  </li>
  <li><p><a href="#req-r12"><b>6.12 Requirement r12: Providing support for
    controlled vocabularies for the values of different properties</b></a></p>
  </li>
  <li><p><a href="#req-r13"><b>6.13 Requirement r13: Allowing for different
    return types for the same property</b></a></p>
  </li>
  <li><p><a href="#req-r14"><b>6.14 Requirement r14: Providing support for
    policy information</b></a></p>
  </li>
  <li><p><a href="#req-r15"><b>6.15 Requirement r15: Providing support for
    discovery of named and track fragments</b></a></p>
  </li>
</ul>

<div class="div2">
<h3><a name="req-r01" id="req-r01"></a>6.1 Requirement r01: Providing methods
for <em>getting</em> metadata information stored in different formats</h3>

<p>Description: The API <strong>MUST</strong> provide methods for getting
metadata stored in different formats related to media resources. Metadata can
be in one of different formats, either as separate document or embedded in
media resources.</p>

<p>Rationale: This is a core requirements. Its implementation is necessary for
nearly all use cases.</p>

<p>Target (API and / or ontology): API</p>
</div>

<div class="div2">
<h3><a name="req-r02" id="req-r02"></a>6.2 Requirement r02: Providing methods
for <em>setting</em> metadata information stored in different formats</h3>

<p>Description: The API <strong>MUST</strong> provide methods for setting
metadata stored in different formats related to media resources. Metadata can
be in one of different formats, either as separate document or embedded in
media resources.</p>

<p>Rationale: The implementation of this requirement is mainly necessary for
use cases which involve change of media resources by users. </p>

<p>Target (API and / or ontology): API</p>

<div class="note">
<p class="prefix"><b>Note:</b></p>

<p>The implementation of this requirement may impose several problems, like:
how to set information in formats which have more detailed information than our
ontology, or how to implement the setting process in the API (e.g. what
protocol to use). Due to such problems and since there seem to be no
implementations achieving this functionality, we might not take this
requirement into account.</p>
</div>
</div>

<div class="div2">
<h3><a name="req-r03" id="req-r03"></a>6.3 Requirement r03: Providing in the
API a means for supporting structured annotations</h3>

<p>Description: The API <strong>MUST</strong> provide a means to support
structured metadata to media resources, like the name of the creator being
structured in "first name" and "last name".</p>

<p>Rationale: There are existing, widely used formats like <cite><a
href="#xmp">XMP</a></cite> which are defined in a structured manner. To be able
to support meta information for media resources, including such formats, the
API needs to have a means to achieve this.</p>

<p>Target (API and / or ontology): API</p>
</div>

<div class="div2">
<h3><a name="req-r04" id="req-r04"></a>6.4 Requirement r04: Providing a means
to access user-defined metadata</h3>

<p>Description: It <strong>MUST</strong> be possible to access user-defined
metadata to media resources. "user-defined metadata" means metadata that is not
defined in a standardized format, but which is being created entirely by the
user.</p>

<p>Rationale: The ability to access user-defined metadata is necessary for the
use case <a href="#uc-user-generated-metadata">user generated metadata</a>.</p>

<p>Target (API and / or ontology): API which needs to provide a method to add
user-defined metadata, and the ontology which needs to provide an extensibility
mechanism.</p>

<div class="note">
<p class="prefix"><b>Note:</b></p>

<p>"Accessing user-defined metadata" may mean setting or getting such metadata.
We have not decided whether we will be able to support the process of setting
metadata, see issues mentioned at <a href="#req-r02">Requirement r02: Providing
methods for setting metadata in media resources in different formats</a>.</p>
</div>
</div>

<div class="div2">
<h3><a name="req-r05" id="req-r05"></a>6.5 Requirement r05: Providing the
ontology as a simple set of properties</h3>

<p>Description: the ontology <strong>MUST</strong> be available as a simple set
of properties, to hide complexity for whose who do not need it.</p>

<p>Rationale: In use cases like <a href="#uc-access-via-web-client">access via
web client to metadata in heterogeneous formats</a> it is important to hide the
potentially complex ontology from the web developer. This will foster ease of
use and wide spread adoption.</p>

<p>Target (API and / or ontology): API and ontology</p>
</div>

<div class="div2">
<h3><a name="req-r06" id="req-r06"></a>6.6 Requirement r06: Specifying an
internal or external format for the ontology</h3>

<p>Description: The ontology <strong>MUST</strong> be provided not only in
prose description but also as an internal or external format.</p>

<p>Rationale: to be able foster interoperability between applications, a common
format for the ontology will be helpful. To avoid the need to process this
format for all implementations, the specification(s) will provide separate
slices of conformance, see <a href="#req-r11">Requirement r11: providing the
ontology in slices of conformance</a>.</p>

<p>Target (API and / or ontology): Mainly the ontology, but possibly also the
API, if we require it to process this format.</p>
</div>

<div class="div2">
<h3><a name="req-r07" id="req-r07"></a>6.7 Requirement r07: Introducing several
abstraction levels in the ontology</h3>

<p>Description: The ontology <strong>MUST</strong> provide several abstraction
levels.</p>

<p>Rationale: Several metadata standards like <cite><a
href="#frbr">FRBR</a></cite> or <cite><a href="#cidoc">CIDOC</a></cite> allow
referring to multimedia resources on several abstraction levels, in order to
separate e.g. a movie, a DVD which contains the movie and a specific copy of
the DVD. Especially for collections of multimedia resources, knowledge about
such abstraction levels is helpful, as a means for accessing the resources on
each level.</p>

<p>Target (API and / or ontology): ontology and potentially API, if we want to
provide access to metadata and multimedia resources on several abstraction
levels.</p>
</div>

<div class="div2">
<h3><a name="req-r08" id="req-r08"></a>6.8 Requirement r08: Being able to apply
the ontology / API for collections of metadata</h3>

<p>Description: It <strong>MUST</strong> be possible to access collections of
metadata.</p>

<p>Rationale: For processing collections of multimedia resources, access to
collections of metadata referring potentially to more than one resource is
necessary. As an example for the need for this requirement and a related
requirement see <a href="#req-r07">Requirement r07: Introducing several
abstraction levels in the ontology</a>.</p>

<p>Target (API and / or ontology): API and ontology</p>
</div>

<div class="div2">
<h3><a name="req-r09" id="req-r09"></a>6.9 Requirement r09: Supporting the
provenance information of metadata properties</h3>

<p>Description: The ontology <strong>MUST</strong> support provenance
information of metadata properties.</p>

<p>Rationale: Metadata is being dealt with by for example producers of metadata
(e.g. a video camera), changers (e.g. a person which modifies initially created
metadata) and consumers (e.g. an application which processes metadata to make
it accessible for search). If several pieces of metadata, created by machines
or people in different roles, are in conflict (e.g. contradictory creation
dates), a description of provenance (i.e. roles of the metadata creators) can
be useful for conflict resolution (e.g. "metadata produced by the changer has
precedence over metadata produced by the creator").</p>

<p>Target (API and / or ontology): ontology</p>
</div>

<div class="div2">
<h3><a name="req-r10" id="req-r10"></a>6.10 Requirement r10: Being able to
describe fragments of media resources</h3>

<p>Description: It <strong>MUST</strong> be possible to relate metadata to
fragments of media resources. </p>

<p>Rationale: Processes like search may be specific to fragments of media
resources, e.g. a search for all kiss scenes in a movie. The implementation of
this requirement provides the means to implement such processes.</p>

<div class="note">
<p class="prefix"><b>Note:</b></p>

<p>This requirement will be implemented by the <a
href="http://www.w3.org/2008/WebVideo/Fragments/">Media Fragments Working
Group</a>.</p>
</div>

<p>Target (API and / or ontology): none of these</p>
</div>

<div class="div2">
<h3><a name="req-r11" id="req-r11"></a>6.11 Requirement r11: Providing the
ontology in slices of conformance</h3>

<p>Description: The ontology <strong>MUST</strong> be provided in a prose
description and <strong>MAY</strong> be provided in different serializations
(RDF, XML). The yet to be produced general conformance description
<strong>MUST</strong> require implementations to take the prose description
into account. Additional conformance descriptions, being specific to a
serialization, <strong>MAY</strong> be provided.</p>

<p>Rationale: Existing metadata formats use a wide range of serializations like
RDF and XML. To foster a widespread adoption of the ontology, we do not want to
be specific to one serialization, but rather state that following the prose
description is sufficient for an implementation. If there is a interest in the
Working Group to create one or more serializations, we may provide additional
types of conformance for them.</p>

<p>Target (API and / or ontology): ontology</p>
</div>

<div class="div2">
<h3><a name="req-r12" id="req-r12"></a>6.12 Requirement r12: Providing support
for controlled vocabularies for the values of different properties</h3>

<p>Description: It <strong>MUST</strong> be possible to take information from
controlled vocabularies for certain properties into account.</p>

<p>Rationale: Media archives often make use of controlled vocabularies (e.g.
classifications, thesauri, ontologies) for certain properties. Providing access
to knowledge about which vocabulary is actually being in use for a media
resource, is an important requirement for such archives.</p>

<p>Target (API and / or ontology): ontology (for describing properties which
need a slot for specifying a controlled vocabulary) and the API ( for getting
information about which vocabulary is being used for a media resource)</p>
</div>

<div class="div2">
<h3><a name="req-r13" id="req-r13"></a>6.13 Requirement r13: Allowing for
different return types for the same property</h3>

<p>Description: It <strong>MUST</strong> be possible to provide different
return types for the same property.</p>

<p>Rationale: Some properties are defined with the same name and functionality
(e.g. conveying information about the creator of a media resource), but use
different value types (e.g. <code>string</code> versus <code>URI</code>). This
raises the question whether the API should be specific to only one return type,
or allow for undefined/unformatted return values for the same property. </p>

<p>Target (API and / or ontology): API</p>
</div>

<div class="div2">
<h3><a name="req-r14" id="req-r14"></a>6.14 Requirement r14: Providing support
for policy information</h3>

<p>Description: The ontology <strong>MUST</strong> provide support for linking
policy information related to the media resource. </p>

<p>Rationale: Specific types of policy information are license, rights and
access. If an implementation supports policy information, the set of properties
must include a link to policy description, represented using e.g. <cite><a
href="#odrl">ODRL</a></cite> or <cite><a href="#p3p">P3P</a></cite>, in order
to express the binding of the policy information to the media resource being
described. Ideally, the link to the policy information should be embedded in
the media resource.</p>

<p>Source: Input from <a
href="http://www.w3.org/Policy/pling/wiki/Main_Page">PLING IG</a></p>

<p>Target (API and / or ontology): Ontology and API</p>
</div>

<div class="div2">
<h3><a name="req-r15" id="req-r15"></a>6.15 Requirement r15: Providing support
for discovery of named and track fragments</h3>

<p>Description: The ontology <strong>MUST</strong> provide properties to query
the list tracks that exist in a media resource as well as the list of named
fragments.</p>

<p>Rationale: The <a href="http://www.w3.org/2008/WebVideo/Fragments/">Media
Fragments WG</a> is interested in technologies that enable track and named
fragments discovery, i.e., the UA needs a way to know for which tracks are
available in a particular media resource, and which named fragments have been
annotated. </p>

<p>Source: Input from <a
href="http://www.w3.org/2008/WebVideo/Fragments/">Media Fragments WG</a></p>

<p>Target (API and / or ontology): Ontology and API</p>
</div>
</div>
</div>

<div class="back">

<div class="div1">
<h2><a name="references-normative" id="references-normative"></a>A
References</h2>
<dl>
  <dt class="label"><a name="rfc2119"></a>[RFC 2119] </dt>
    <dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key
      Words for use in RFCs to Indicate Requirement Levels</cite></a>. IETF RFC
      2119, March 1997. Available at <a
      href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
    </dd>
</dl>
</div>

<div class="div1">
<h2><a name="references-non-normative" id="references-non-normative"></a>B
References (Non-Normative)</h2>
<dl>
  <dt class="label"><a name="cidoc"></a>[CIDOC] </dt>
    <dd>N. Crofts, M. Doerr, T. Gill, S. Stead, M. Stiff. <a
      href="http://cidoc.ics.forth.gr/docs/cidoc_crm_version_5.0_Dec08.pdf"><cite>Definition
      of the CIDOC Conceptual Reference Model, Version 5.0</cite></a>.
      Technical specification December 2008. Available at <a
      href="http://cidoc.ics.forth.gr/docs/cidoc_crm_version_5.0_Dec08.pdf">http://cidoc.ics.forth.gr/docs/cidoc_crm_version_5.0_Dec08.pdf</a>.</dd>
  <dt class="label"><a name="ebu-p-metadata"></a>[EBU P-Meta] </dt>
    <dd><a href="http://tech.ebu.ch/docs/tech/tech3295v2.pdf"><cite>EBU-P
      Metadata</cite></a> European Broadcasting Union specification 2007.
      Available at <a
      href="http://tech.ebu.ch/docs/tech/tech3295v2.pdf">http://tech.ebu.ch/docs/tech/tech3295v2.pdf</a>.</dd>
  <dt class="label"><a name="ebu-core"></a>[EBU Core] </dt>
    <dd><a href="http://tech.ebu.ch/docs/tech/tech3293-2008.pdf"><cite>EBU
      CORE</cite></a> European Broadcasting Union specification 2008. Available
      at <a
      href="http://tech.ebu.ch/docs/tech/tech3293-2008.pdf">http://tech.ebu.ch/docs/tech/tech3293-2008.pdf</a>.</dd>
  <dt class="label"><a name="emotionsml10"></a>[Emotions ML 1.0] </dt>
    <dd>P. Baggia, F. Burkhardt. J. C. Martin, C. Pelachaud, C. Peter, B.
      Schuller, I. Wilson and E. Zovato. <a
      href="http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/"><cite>Elements
      of an EmotionML 1.0 </cite></a>. W3C Incubator Group Report 20 November
      2008 . Available at <a
      href="http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/">http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/</a>.</dd>
  <dt class="label"><a name="exif"></a>[EXIF] </dt>
    <dd><a
      href="http://www.digicamsoft.com/exif22/exif22/html/exif22_1.htm"><cite>Exchangeable
      image file format for digital still cameras: Exif Version 2.2</cite></a>.
      JEITA Technical specification August 2002. Available at <a
      href="http://www.digicamsoft.com/exif22/exif22/html/exif22_1.htm">http://www.digicamsoft.com/exif22/exif22/html/exif22_1.htm</a>.</dd>
  <dt class="label"><a name="frbr"></a>[FRBR] </dt>
    <dd><a
      href="http://archive.ifla.org/VII/s13/frbr/frbr.htm"><cite>Functional
      Requirements for Bibliographic Records - Final Report</cite></a>.
      Technical specification 1998. Available at <a
      href="http://archive.ifla.org/VII/s13/frbr/frbr.htm">http://archive.ifla.org/VII/s13/frbr/frbr.htm</a>.</dd>
  <dt class="label"><a name="geolocationapi"></a>[Geolocation API] </dt>
    <dd>A. Popescu. <a
      href="http://www.w3.org/TR/2008/WD-geolocation-API-20081222/"><cite>Geolocation
      API Specification</cite></a>. W3C Working Draft 22 December 2008.
      Available at <a
      href="http://www.w3.org/TR/2008/WD-geolocation-API-20081222/">http://www.w3.org/TR/2008/WD-geolocation-API-20081222/</a>.
      The <a href="http://www.w3.org/TR/geolocation-API/">latest version</a> of
      the Geolocation API specification is available at
      http://www.w3.org/TR/geolocation-API/ .</dd>
  <dt class="label"><a name="iptc"></a>[IPTC] </dt>
    <dd><a
      href="http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf"><cite>IPTC
      Standard Photo Metadata 2008</cite></a>. IPTC Core Specification Version
      1.1, IPTC Extension Specification Version 1.0, Document Revision 2, June
      2008. Available at <a
      href="http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf">http://www.iptc.org/std/photometadata/2008/specification/IPTC-PhotoMetadata-2008.pdf</a></dd>
  <dt class="label"><a name="mediarss"></a>[MEDIA RSS] </dt>
    <dd><a href="http://search.yahoo.com/mrss"><cite>Yahoo! Media RSS Module -
      RSS 2.0 Module</cite></a>. Technical specification March 2008. Available
      at <a
      href="http://search.yahoo.com/mrss">http://search.yahoo.com/mrss</a>.</dd>
  <dt class="label"><a name="mpeg-7"></a>[MPEG-7] </dt>
    <dd><cite>Information Technology - Multimedia Content Description Interface
      (MPEG-7)</cite>. Standard No. ISO/IEC 15938:2001, International
      Organization for Standardization(ISO), 2001. </dd>
  <dt class="label"><a name="odrl"></a>[ODRL] </dt>
    <dd>R. Lannella, <a href="http://www.w3.org/TR/odrl/"><cite>Open Digital
      Rights Language (ODRL) Version 1.1</cite></a>. W3C Note 19 September
      2002. Available at <a
      href="http://www.w3.org/TR/odrl/">http://www.w3.org/TR/odrl/</a></dd>
  <dt class="label"><a name="p3p"></a>[P3P] </dt>
    <dd><a href="http://www.w3.org/P3P/"><cite>Platform for Privacy Preferences
      (P3P) Project</cite></a>. Available at <a
      href="http://www.w3.org/P3P/">http://www.w3.org/P3P/</a></dd>
  <dt class="label"><a name="tvanytime"></a>[TVAnytime] </dt>
    <dd><a
      href="http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx"><cite>TV-Anytime</cite></a>
      The specifications and schemas can be downloaded free of charge from <a
      href="http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx">http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx</a>
      .</dd>
  <dt class="label"><a name="videositemaps"></a>[Videositemaps] </dt>
    <dd><a
      href="http://www.google.com/support/webmasters/bin/answer.py?answer=80472&amp;topic=10079"><cite>Google
      Video Sitemap</cite></a>. Example available at <a
      href="http://www.google.com/support/webmasters/bin/answer.py?answer=80472&amp;topic=10079">http://www.google.com/support/webmasters/bin/answer.py?answer=80472&amp;topic=10079</a>
      .</dd>
  <dt class="label"><a name="vodcsv"></a>[VODCSV] </dt>
    <dd><a
      href="http://www.cablelabs.com/specifications/MD-SP-VOD-CONTENT2.0-I02-070105.pdf"><cite>Video-On-Demand
      Content Specification Version 2.0</cite></a>. CableLabs technical
      specification January 2007. Available at <a
      href="http://www.cablelabs.com/specifications/MD-SP-VOD-CONTENT2.0-I02-070105.pdf">http://www.cablelabs.com/specifications/MD-SP-VOD-CONTENT2.0-I02-070105.pdf</a>.</dd>
  <dt class="label"><a name="xgr-image-annotation"></a>[XGR Image Annotation]
  </dt>
    <dd>M. Hausenblas. <a
      href="http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies-20070724/"><cite>Multimedia
      Vocabularies on the Semantic Web</cite></a>. W3C Incubator Group Report
      24 July 2007. Available at <a
      href="http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies-20070724/">http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies-20070724/</a>.</dd>
  <dt class="label"><a name="xgr-vocabularies"></a>[XGR Vocabularies] </dt>
    <dd>R. Troncy, J. v. Ossenbruggen, J. Z. Pan and G. Stamou. <a
      href="http://www.w3.org/2005/Incubator/mmsem/XGR-image-annotation/"><cite>Image
      Annotation on the Semantic Web</cite></a>. W3C Incubator Group Report 14
      August 2007. Available at <a
      href="http://www.w3.org/2005/Incubator/mmsem/XGR-image-annotation-20070814/">http://www.w3.org/2005/Incubator/mmsem/XGR-image-annotation-20070814/</a>.</dd>
  <dt class="label"><a name="xmltv"></a>[XMLTV] </dt>
    <dd><a href="http://wiki.xmltv.org/index.php/XMLTVProject"><cite>XML TV
      Project</cite></a>. Available at <a
      href="http://wiki.xmltv.org/index.php/XMLTVProject">http://wiki.xmltv.org/index.php/XMLTVProject</a>.
    </dd>
  <dt class="label"><a name="xmp"></a>[XMP] </dt>
    <dd><a
      href="http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf"><cite>XMP
      Specification Part 2 - Standard Schemas</cite></a>. Technical
      specification, Adobe 2008. Available at <a
      href="http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf">http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf</a>
      . </dd>
</dl>
</div>

<div class="div1">
<h2><a name="change-log" id="change-log"></a>C Change Log (Non-Normative)</h2>

<table border="1">
  <tbody>
    <tr>
      <td>Date</td>
      <td>Change</td>
    </tr>
    <tr>
      <td>2009-01-19</td>
      <td>Initial publication.</td>
    </tr>
    <tr>
      <td>2009-03-16</td>
      <td>Integrated comments from the <a
        href="http://lists.w3.org/Archives/Public/public-media-annotation/2009Jan/0094.html">Media
        Fragments Working Group</a>, and <a
        href="http://lists.w3.org/Archives/Public/public-media-annotation/2008Nov/0029.html">Raphaël
        Troncy</a>. See <a
        href="http://lists.w3.org/Archives/Public/public-media-annotation/2009Mar/0052.html">editing
        summary</a>.</td>
    </tr>
    <tr>
      <td>2009-03-16</td>
      <td>Editing of the <a href="#uc-cultural-heritage-institutions">Cultural
        Heritage Institutions</a> use case.</td>
    </tr>
    <tr>
      <td>2009-03-19</td>
      <td>Integrated comments from <a
        href="http://lists.w3.org/Archives/Public/public-media-annotation/2009Mar/0080.html">Jean-Pierre
        Evain</a>.</td>
    </tr>
    <tr>
      <td>2009-04-02</td>
      <td>Removed the mobile use case.</td>
    </tr>
    <tr>
      <td>2009-04-29</td>
      <td>Integrated <a
        href="http://lists.w3.org/Archives/Public/public-media-annotation/2009Apr/0059.html">comments
        from David Singer</a>, except the "More structural comments".</td>
    </tr>
    <tr>
      <td>2009-04-29</td>
      <td>Added a health warning to the status section about ongoing
        terminology discussions.</td>
    </tr>
    <tr>
      <td>2009-12-24</td>
      <td>Added <a href="#req-r14">r14</a> and <a href="#req-r15">r15</a> to <a
        href="#requirements"><b>6 Requirements</b></a>.</td>
    </tr>
    <tr>
      <td>2009-12-24</td>
      <td>Revised <a href="#req-r09">r09</a> with concrete description.</td>
    </tr>
    <tr>
      <td>2009-12-24</td>
      <td>Changed the term of Media Object with Media Resource.</td>
    </tr>
  </tbody>
</table>
</div>

<div class="div1">
<h2><a name="acknowledgments" id="acknowledgments"></a>D Acknowledgements
(Non-Normative)</h2>

<p>This document is the work of the <a
href="http://www.w3.org/2008/WebVideo/Annotations/">W3C Media Annotations
Working Group</a>.</p>

<p>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). </p>

<p>The people who have contributed to <a
href="http://lists.w3.org/Archives/Public/public-media-annotation/">discussions
on public-media-annotation@w3.org</a> are also gratefully acknowledged. </p>
</div>
</div>
</body>
</html>