W3C home > Mailing lists > Public > public-media-annotation@w3.org > October 2010

Re: Response to your LC Comment -2405 on Media Ontology spec

From: Doug Schepers <schepers@w3.org>
Date: Tue, 05 Oct 2010 06:53:58 -0400
Message-ID: <4CAB03C6.5060101@w3.org>
To: tmichel@w3.org
CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
Hi, Media Annotations WG-

In general, I'm satisfied by these response to my comments, but I would 
need to see them in the spec before I can confirm that.  In particular, 
I'm confused by your solution around the "ma" prefix, and would like to 
see it in writing.  Is there a revised editor's draft available?


Thierry MICHEL wrote (on 9/29/10 2:56 AM):
> Dear Doug,
> The Media Annotations Working Group has reviewed the comments you sent
> [1] on the Last Call Working Draft [2] of the Ontology for Media
> Resource 1.0 published on 08 June 2010.
> Thank you for having taken the time to review the document and to send
> us comments.
> The Working Group's response to your comment is included below (your
> points are copied and our responses start with an arrow ->).
> Please review it carefully and *let us know by email at
> public-media-annotation@w3.org if you agree with it or not*
> before deadline date [09-oct-2010].
> In case of disagreement, you are requested to provide a specific
> solution for or a path to a consensus with the Working Group.
> If such a consensus cannot be achieved, you will be given the
> opportunity to raise a formal objection which will
> then be reviewed by the Director during the transition of this document
> to the next stage in the W3C Recommendation Track.
> Thanks,
> For the Media Annotations Working Group,
> Véronique Malaisé
> 1.
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Jul/0016.html
> 2. http://www.w3.org/TR/2010/WD-mediaont-10-20100608/
> -----------------
> MAWG Resolution:
> -----------------
> Ontology:
> As an editorial comment, there seems to be an academic tone here, with
> the use of the word "our" rather than "this specification", detailed
> rationales for decisions (which is good in itself, but ), and a
> generally tentativeness ("Although the set of properties is now limited,
> it already constitutes a proof of concept", section 4.1.1, "proof-read
> our interpretation", etc.). I recommend you simply state in the Status
> section that feedback is welcome (with short inline notes commenting on
> which sections are in particular need of feedback), that there may be
> considerations for possible future versions of the spec, and that you
> leave room for extensions; if this is done right and sees uptake, it
> will almost certainly be the first of a lineage of specs.
> -> The Ontology document will be updated in order to remove fuzzy
> statements or inquiries for feedback. Your solution is an elegant way to
> deal with them, and we will update the Status section accordingly.
> 1 Introduction
> The introduction could benefit by trimming it down. Split the
> relationship to Dublin Core into a subsection. Explain the uses of this
> ontology to the expected readers of the spec: possible implementers,
> content authors, and users of the ontology.
> -> Indeed, we will rewrite the Introduction section, split the mention
> of Dublin Core from the rest and be more precise regarding the goal of
> the Ontology.
> 1.1 Purpose of this specification
> After reading this, I'm left wondering whether this ontology is expected
> to be used in metadata itself, or if it is only a mapping. If someone
> were to use this ontology by itself, would that be a misuse? Explain why
> or why not in this section.
> -> We agreed at the last F2F that the Ontology can be used as a metadata
> scheme in itself, so we will update the Ontology document accordingly. A
> paragraph will be added that specifies the purpose of the specification
> and its scope: the property list, its RDF implementation and the set of
> mappings.
> 4.1.2 Core properties
> All the property names are prefixed with "ma:", which could be confused
> as part of the property name. Simply stating that the properties are in
> the Media Annotations namespace is enough (as long as you provide
> concrete examples of use).
> -> We decided on keeping the ma: prefix when describing the property
> names, but we are rewriting the syntax in which we present their ranges:
> it does not include semicolons anymore. In this way we hope that the
> syntax will be more clear. We are also adding concrete examples of
> properties' values in the table.
> 4.2.1 Rationale regarding the mapping table "Its namespace is "ma", for
> Media Annotation." The spec seems to conflate the namespace with the
> prefix; usually, a namespace is something like
> "http://w3.org/MediaAnnotations/", which is often bound in a serialized
> document with a common prefix, like "ma:" using a namespace declaration;
> the prefix is not considered universal. (In my opinion, this is a flawed
> design for Namespaces in XML, but that's the convention.)
> -> We corrected the sloppyness of calling the ma prefix a namespace at
> another place in the document, and will have to correct this in the last
> place where the confusion unfortunately still figures in the document.
> 4.2.2 The mapping table
> I really like the level of detail this spec goes into for performing the
> mapping (though I guess it's still a work in progress. The mappings seem
> a bit hidden, though, and they are really the meat of the spec. I assume
> you are trying to keep the spec manageably short, but I would suggest
> either keeping the tables inline in the body of the single-page spec, or
> splitting it out into chapters with each chapter a short description of
> the mapped ontology, followed by the table mapping itself.
> -> We considered the idea of splitting the table into sections, but it
> turned out to be quite a complicated operation. Having the table as a
> whole also shows a nice overview. We are now importing it in the main
> document, so following the first option that you suggest: keeping it
> inline with the body of the document.
Received on Tuesday, 5 October 2010 10:54:01 UTC

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