W3C home > Mailing lists > Public > public-swbp-wg@w3.org > February 2006

[MM] First version of multimedia ontology requirements document

From: Jacco van Ossenbruggen <Jacco.van.Ossenbruggen@cwi.nl>
Date: Fri, 03 Feb 2006 12:04:07 +0100
Message-ID: <43E338A7.10107@cwi.nl>
To: swbp <public-swbp-wg@w3.org>

Hi all,

I had an action item to send a first version of a requirements draft to 
the list [1].

Please feel free to add to the text below.  I expect Raphael and 
Giorgos's group to add two other perspectives by posting a follow up 
mail in this thread (so others can easily track the progress we are making).

Of course, others (Chris?) are also invited to add any requirements or 
perspectives they find missing in the current draft.
Feel free to post follow ups!



[1] http://www.w3.org/2006/01/26-MMTF-minutes.html#action21


Multi-perspective Requirements for a Common Multimedia Ontology Framework

This document provides requirements for a common multimedia ontology
framework.  It recognizes the fact that multimedia ontologies are used
for different goals by different applications.  It discusses the
presentation-oriented perspective (Van Ossenbruggen & Geurts), the
archival-oriented perspective (Troncy) and the analysis-oriented
perspective (Stamou et al.) [[ALL: Feel free to add or change this


Presentation-Oriented Requirements for a Multimedia Ontology Framework
by Jacco van Ossenbruggen and Joost Geurts

This section provides a short list of requirements that originate from
the work at CWI om the Cuypers system, an automatic, web-based
multimedia presentation engine, have partly been previously described
in [Geurts05].  The requirements reflect this perspective, they focus
on being able to model background knowledge and annotate media items
in a way that allows them to be presented in a coherent way that
satisfies user needs and his device constraints.

The framework should support:

1. Comply to Semantic Web standards and best practices as much as
   Both modeling background knowledge and multimedia annotation is an
   expensive task, the framework should allow and encourage re-use and
   sharing of information as much as possible.  It should do this
   without overcommitment to a specific standard of formalism.  For
   example, the framework should support both applications that need
   DL-reasoners and applications that need the expressivity of

2. Support addressing a wide variety of multimedia fragments.

   When annotating part of a HTML or XML document, one can link to
   this part using the standard fragment identifier in the URI of the
   rdf:about.  For almost all other media types, the semantics of the
   fragment identifier has not be defined or is not commonly accepted.
   Other ways to identify media fragments have thus to be supported
   (see MPEG-7 for an example).

3. Support structuring of annotations.

   A set of annotations of a complex multimedia artifact is more than
   a set of instances of a multimedia ontology.  Typically, there is a
   preferred order in which the annotations are entered or displayed
   (e.g. first dc:title, then dc:creator etc), some annotation
   properties are mandatory while others may be optional, etc.  In
   addition, annotations may follow the structure of the multimedia
   artifact.  So a set of annotations of a video fragment may be
   structured along the same scene/sequence/shot hierarchy as the
   video itself.

4. Support annotations of media items in terms of the delivery context.

   With the wide variety of Web access devices, it becomes essential
   for a web service to know what the device capabilities are that
   playback of a media item, and other characteristics of the delivery
   context that influences their presentation.  Examples include
   required network bandwidth, screen resolution, update frequency,
   color depth etc.  Note that applications also need to be able to
   describe the delivery context of the client itself. (an explicit
   link with the W3C work on CC/PP and device independence might
   provide for this functionality).

5. Support the distinction between annotations that address the
   digital artifact and the physical object depicted by the digital

   Almost all media items are digital recordings of real physical
   items that also require annotation.  Confusing the two is a mistake
   often made in practice (e.g. does the dc:creator of an digital
   image of a painting refer to the painter or the photographer?).
   The framework should support making explicit distinctions between
   the two and also allow annotators to make explicit the potentially
   many different type of links between them (e.g. an image could
   depict a part of a painting, an X-ray of a painting etc).  See the
   distinction between Work and Image in [VRA],[Geurts05].

6. Be lightweight and support plug-in of other ontologies.

   No multimedia ontology framework is ever going to be complete.
   Overly complex standards such as MPEG-7 have proven to have many
   practical problems in terms of it usability.  We are convinced the
   framework should have a small, lightweight core that can be easily
   extended.  For example, a scientific multimedia application might
   need very detailed annotations of the subject matter from a
   specific scientific field.  The framework should support plugging
   in such domain-specific ontologies.  In addition, many applications
   require existing ontologies to be reusable and plugged into the
   multimedia ontology framework.

7. Be open and have a license that provides unrestricted fair use.

   The framework is only going to be successful if it can be widely
   used by a large and heterogeneous community (e.g. for both
   professional and private usage).

[Geurts05] Joost Geurts, Jacco van Ossenbruggen, and Lynda Hardman
           Requirements for practical multimedia annotation. In:
           Workshop on Multimedia and the Semantic Web Heraklion,
           Crete pp. 4-11 May 2005.

[VRA]      Visual Resources Association Website: http://www.vraweb.org/
Received on Friday, 3 February 2006 11:04:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:46 UTC