W3C home > Mailing lists > Public > public-media-annotation@w3.org > March 2009

Edits of the requirements document - action-85

From: Felix Sasaki <felix.sasaki@fh-potsdam.de>
Date: Tue, 17 Mar 2009 04:01:33 +0900
Message-ID: <ba4134970903161201g257112a5mc127e8b6b28e36e5@mail.gmail.com>
To: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Hi all,

here are the results of editing I did to the requirements document. See
summary of the comments and the edits (marked as "FS") below. Sorry that
this is a long mail, please search for "FS" to see what I did. See also a
diff document to the first public draft at

Comments from Raphael - to be edited by FS
FS: Most of these were made before the first draft publication and major
rewrite, and I hope all are addressed now.

* Status of this document: it is outdated for this document. I think it is
aimed to be a Working Group Note rather than a Rec.
FS: done for the publication

* Section 1: 'concret' -> concrete
FS: not in the draft anymore

FS: The whole section 2 is not in the draft anymore, so I did not go through
these comments.
* Section 2.1: Overview
 - The 3 dimensions fall a bit from the sky, making the reading a bit dry.
Is it possible to add some references showing where these 3 dimensions come
 - The current text contains a lot of questions ... "for us", so I guess not
meant for the working draft reader. Are they? For example: should we keep
the sentence: "Taking in consideration what the cognitive power of a medium
is might help us to distill the basics to be described to achieve the widest
coverage"? Or should be turn it into something like: "Taking in
consideration what the cognitive power of a medium is enables to distill the
basics to be described to achieve the widest coverage"?
 - Similarly, the text that describes the 3rd dimension (the task) contains
numerous questions. Would we like to keep them as it is? It seems to me that
the text should answer to these questions and not exposed to the reader of
the document.
 - The last sentence of the 5th paragraph is ambiguous: "The scope of the
Media ontology 1.0 is limited to content description". Do you mean the
physical content? the semantic content? both?
 - What means DC at the end of the 6th paragraph? Is there some missing
text? Is it a reference to the new working drafts of Dublin Core that
envisages to have wh* relationships? Furthermore, it would be interesting to
detail which explicit relationships the standards mentioned (CIDOC, MPEG-7,
WHOS, MF) allow. Is it possible to precise them?
 - In the 6th paragraph: 'witout' -> without; 'connceted' -> connected
Furthermore, I suggest to rephrase the following sentence:
"making links or graphs to connect the different pieces of the annotation
that belong together is very important for the precision/enhancing the
 - Is it a requirement of the Media Ontology to enable relation
 - The 7th paragraph contains numerous questions that I guess should not be
there but answered.

* Section 2.2: Media
 - Do we really consider all the media mentioned?
 - Providing examples would help to understand what do you mean by 'static',
'interactive', 'fixed', 'mobile', 'realistic', 'abstract', etc.
 - The authors say that "Queries need to be enabled to search on the
following dimensions:" but then I'm confused. The first two dimensions are
about the subject matter, the semantic content, which I thought was address
by the 2nd dimension (context). The 3rd one introduces the notion of form of
the media. Why not then adding the genre, another component that is
indispensable in EPG?

* Section 2.3: Context
The text ends abruptly, I guess there is some text missing.

* Section 2.4: Task
 - 'maintaining' -> maintain
 - Add a reference to the canonical processes

* Section 3.1: Video
FS: not in the draft anymore
 - Which video services sites are you considering? Video search engines?
Video sharing web sites? I think they have different requirements ...
 - I do not understand the problem explained in the 2nd and 3rd paragraph.
What is the task? I guess the task is not to specify what an API should
return for a particular command ... Getting the songs 'composed by' Dvorak?
Then a full text search will work in both cases.
 - I disagree with the NOTE, as I believe the aim of the Media Ontology is
to solve the semantic mismatch between the existing formats as much as
 - The last paragraph also introduces bad practices. Do not split properties
(first name, family name, etc.) but just use URIs for identifying resources,
and you get them for free.
 - The requirements talked about "commonly used properties for describing
video content, from these different standards". Is it possible to detail
these properties that should be covered by the Media Ontology?

* Section 3.2: Cultural Heritage
 - I like the description of the use case but I do not understand what are
the requirements. The requirements paragraph does not seem to exhibit any
particular requirement, or at least, it is not clear to me.
FS: the requirements and the use case description have been rewritten and
are worked on again by Veronique currently

* Section 3.3: Mobile
 - 'foramts' -> formats
 - Interoperability with formats for identification on the Web seems a
requirement in this use case. Is it possible to list these formats?
FS: the whole use case needs to be rewritten. I propose to do that after the
next draft publication.

* Section 3.4:
FS: section has been dropped
 - I don't understand what this use case is about. Is it about
"Interoperability for IPTV"? I would then suggest this new title.
 - The authors said: "In MPEG-7, there are parts related to this problem".
Which parts the authors refer to?

* Section 3.5: Tagging
FS: section has been dropped
 - I think this use case is partially out of scope. I explained: the XG use
case covers two sides of the coin. People tag on different platforms, and
one concern would be to identify uniquely these tags so that they can be
reused cross platforms. I think this part is out of scope for the Media
Ontology, and some initiatives such as TagCare deals with that problem! The
other side of the coin is the properties that allow the tagging such as the
TAG ontology or MOAT. I think the Media Ontology should be interoperable
with MOAT.

* Section 3.6: Life Log
FS: section has been rewritten, could you check again? The 3 dimensions were
not used, as in all other cases.
 - What is this use case about? Is it possible to describe it in terms of
the 3 dimensions (media, context, task) like the other use cases?

Hope that helps!
Best regards.
changes proposed from Michael Hausenblas, to be edited by FS. My remarks are
mentioned via "FS" again.
Hello Michael,

thank you very much for your review.

Michael Hausenblas さんは書きました:
> All,
> As of my action [1] I was appointed to review your Working Draft from 19
> January 2009 regarding 'Use Cases and Requirements for Ontology and API
> Media Object 1.0'.
> Short version: Nice use cases and good requirements. In order to increase
> readability, the content needs to be improved, esp. sections 1 to 4.
> Full version:
> ===============
>  Major issues
> ===============
> + Add a clear scope paragraph. I learned very late (somewhere in the
> '1. Introduction') that you are actually mainly targeting videos.


FS: I added a scope paragraph in the abstract and repeated it in the

> + Even though I always believed I know my work I was not able to decode:
> 'The "Ontology for Media Object 1.0" will address the intercompatiblity
> problem by providing a common set of properties to define the basic
> needed for media objects and the semantic links between their values in
> different existing vocabularies.'
>  - what is 'intercompatiblity'?
>  - what are media objects?
>  - what are semantic links?

Agree that this can be made clearer.
FS: I rewrote the paragraph:
"The "Ontology for Media Object 1.0" will address the  problem of
heterogeneous metadata for multimedia objects by providing a common set of
properties. It will also help circumventing the current proliferation of
video metadata formats by providing full or partial translation and mapping
between the existing formats. The ontology will be accompanied by an API
that provides uniform access to all elements defined by the ontology, which
are selected elements from different formats."

> + And it continues: 'The scope is mainly video media objects, but we take
> also other media objects into account if their metadata information is
> related to video.'
>  - how related?
>  - which metadata?

For "how related" I would say "if the metadata information can also be
applied to video, but not only to video, e.g. the creation date". For
"which medata", this is a question to be answered in the future.

> + The figure in section '3 Purpose of the Ontology and the API' is nice
> somehow questionable. Do user adapt the API? Do user visualise the API?
> Isn't the ontology itself the API? In which language (formal or
> is it defined? What *is* the API?

I think that the paragraph
"An important aspect of the above figure is that everything visualized
above the API is left to applications, like: languages for simple or
complex queries, analysis of user preferences (like "preferring movies
with actor X and suitable for children"), or other mechanisms for
accessing metadata. The ontology and the API provide merely a basic,
simple means of interoperability for such applications."
Tries to answer some of your questions.
- Adaptation of the API: if the API is changed it is not the API we will
have defined anymore.
- Visualize: see "... is left to the application", so "no"
- ontology = API: no, see also
- "in which language ...": see as a potential example, which is neither
formal nor logic-based
- "what is the API". Again see
As an example of an API specification we are aiming at IMO.

> + Rather than having an almost empty section '4 Terminology' that merely
> refers to RFC2119 you should use this space to define *your* terms (such
> media object).

Such a section will be part of the API and the ontology specifications.

> + In section '5.6 User generated Metadata' you use RDF/Turtle without any
> warning, hint or reference.

Good point, a warning and references seem to be appropriate.

> + Regarding '6.7 Requirement r07: Introducing several abstraction levels
> the ontology' I'd say this is an absolute must.

Do you have any existing implemention we could look at to be able to
judge the efforts of this?

> If you can't talk about the
> different abstraction layers, I guess the effort is pretty worthless.

At the TPAC meeting in October we had a presentation from a video search
engine with not more than *five*, "flat" properties, see
I think we saw a metadata mapping which was very useful and worth it, so
I would disagree with your statement above.

> =================
>  Minor issues
> =================
> + the TOC is not well-formatted, although pubrule-checker [2] seems not to
> complain - rather use use <ol> and <li>

mm ... I checked
and did not see any problems. Could you point me to the markup part
which you think has a problem?

FS: that is fixed now

> + in the section 'B References' the labels of [XGR Image Annotation] and
> [XGR Vocabularies] are mixed up (I think I remember seeing the latter
> document already, somewhere ;)

Good point, to be fixed.
FS: fixed

> + you want to go for a W3C Note, right? Then you want to remove the
> '(non-normative)' part in the references. You are not normative, hence as
> well not non-normative.

I had thought so too, but see

> All this said I guess you need a major revision of this WD.

I did not see any comments on the requirements which I think are the
most important "message" of the WD. Do you think these need a revision
or are stable? How would you fill the beginning of sec. 6
"This sections describes requirements for the ontology and the API. The
Working Group has agreed to implement the following requirements. "
"The requirements which the Working Group currently does not have
agreement to take into account are the following:"


>  I think the UC
> and the requirements as they are present are valuable and convincing, but
> the reader needs more explanation in the beginning. You can't assume that
> everyone has followed your WG-internal discussions and instantly knows
> you mean by media object or API.
> Tracker, this is ACTION-36 and I'm gonna close it.
> Cheers,
>       Michael
> [1] http://www.w3.org/2009/01/28-mediafrag-minutes.html#action01
> [2] http://www.w3.org/TR/media-annot-reqs/,pubrules

Mobile use case, to be edited by probably Tobias
Use case "cultural heritage insitutions", to be edited by Veronique
Comments form Dan Conolly, to be edited by FS later. Could we check these
tomorrow again?

    * please separate objective, testable requirements from goals/principles
Dan Connolly
FS: to be done after next call
    * please use a different label for requirements without WG support Dan
FS: to be done after next call

Received on Monday, 16 March 2009 19:02:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:24:34 UTC