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

RE : RE : Edits of the requirements document - action-85

From: Evain, Jean-Pierre <evain@ebu.ch>
Date: Tue, 17 Mar 2009 14:26:18 +0100
Message-ID: <14AE8514098875488F9FEACD90C747A2045A51@gnvasmail1a.gva.ebu.ch>
To: "Felix Sasaki" <felix.sasaki@fh-potsdam.de>
Cc: <public-media-annotation@w3.org>
Do we need consensus to repair broken links and reference to websites or
names of specifications ;-)

	-------- Message d'origine-------- 
	De: felix.sasaki@googlemail.com de la part de Felix Sasaki 
	Date: mar. 17.03.2009 14:00 
	À: Evain, Jean-Pierre 
	Cc: public-media-annotation@w3.org 
	Objet: Re: RE : Edits of the requirements document - action-85
	Hi Jean-Pierre,
	I would propose to send the rewordings to this list and integrate
them as soon as we have consensus on them.
	2009/3/17 Evain, Jean-Pierre <evain@ebu.ch>

		Dear all, Felix,
		You maybe remember that I suggested 6 weeks ago that some of
the links
		regarding TVA and EBU schemas are incorrect.  I had been
told that this
		would be done later as the document had to be published
a.s.a.p ;-). But it
		looks like if it is subject to some significant rewording
and this might be
		the opportunity to correct errors.
		Felix, who should I send the corrections to. Please advaise.
		       -------- Message d'origine--------
		       De: public-media-annotation-request@w3.org de la part
de Veronique
		       Date: mar. 17.03.2009 09:29
		       À: Felix Sasaki
		       Cc: public-media-annotation@w3.org
		       Objet: Re: Edits of the requirements document -
		       Hi all,
		       I also updated the Cultural Heritage use case, if you
have some
		comments about it, they are more than welcome of course.
		       Best regards,
		       On Mar 16, 2009, at 8:01 PM, Felix Sasaki wrote:
		               Hi all,
		               here are the results of editing I did to the
		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
		publication and major rewrite, and I hope all are addressed
		               * Status of this document: it is outdated for
this document.
		I think it is aimed to be a Working Group Note rather than a
		               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 from?
		                - 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
		                - In the 6th paragraph: 'witout' -> without;
'connceted' ->
		               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
		precision/enhancing the search".
		                - Is it a requirement of the Media Ontology
to enable
		relation relationships?
		                - 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
		                - Providing examples would help to
understand what do you
		mean by 'static', 'interactive', 'fixed', 'mobile',
'realistic', 'abstract',
		                - 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
		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
		formats as much as possible.
		                - 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
		               * 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
		               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
		               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
		               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 for
		               > 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 section
		               > '1. Introduction') that you are actually
mainly targeting
		               FS: I added a scope paragraph in the abstract
and repeated
		it in the introduction.
		               > + 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
		               > problem by providing a common set of
properties to define
		the basic metadata
		               > 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
		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
		               > + 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
		               > + The figure in section '3 Purpose of the
Ontology and the
		API' is nice but
		               > somehow questionable. Do user adapt the
API? Do user
		visualise the API?
		               > Isn't the ontology itself the API? In which
		(formal or logic-based)
		               > is it defined? What *is* the API?
		               I think that the paragraph
		               "An important aspect of the above figure is
that everything
		               above the API is left to applications, like:
languages for
		simple or
		               complex queries, analysis of user preferences
		"preferring movies
		               with actor X and suitable for children"), or
		mechanisms for
		               accessing metadata. The ontology and the API
provide merely
		a basic,
		               simple means of interoperability for such
		               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 as
		               > media object).
		               Such a section will be part of the API and
the ontology
		               > + 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 in
		               > the ontology' I'd say this is an absolute
		               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
		               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
		[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
		               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
		requirements. "
		               "The requirements which the Working Group
currently does not
		               agreement to take into account are the
		               >  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 what
		               > you mean by media object or API.
		               > Tracker, this is ACTION-36 and I'm gonna
close it.
		               > Cheers,
		               >       Michael
		               > [1]
		               > [2]
		               Mobile use case, to be edited by probably
		               Use case "cultural heritage insitutions", to
be edited by
		               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 Connolly
		               FS: to be done after next call
		This email and any files transmitted with it
		are confidential and intended solely for the
		use of the individual or entity to whom they
		are addressed.
		If you have received this email in error,
		please notify the system manager.
		This footnote also confirms that this email
		message has been swept by the mailgateway
Received on Tuesday, 17 March 2009 13:27:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:33 UTC