RE: Re: ACTION-255

Hello John,
Many thanks for the input!

One comment; our reviewer asked for a clarification of the "ma" prefix! In your version you have replaced it with a portion of  UIref. Perhaps that could be added?


Rgds
/Joakim


[http://www.ericsson.com/shared/images/Email_line.gif]

JOAKIM SÖDERBERG M.Sc, Ph.D
Multimedia Indexing, Senior Research Engineer, Chair W3C MAWG

Ericsson Research
Multimedia Technologies
Sweden
SMS/MMS +46761263915
www.ericsson.com


[http://www.ericsson.com/shared/images/Email.gif]



This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>


________________________________
From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Strassner John Charles
Sent: den 6 maj 2010 01:30
To: Felix Sasaki; Joakim Söderberg; public-media-annotation@w3.org
Subject: Re: Re: ACTION-255

Hi Joakim,

First, I agree with Felix. Second, with my hat as future Editor on, I'd like to tighten the language a little. There are, imho, four things that can be improved.

line 1:
Change "Annotaions" to "Annotations"

line 3:
This refers to specificationS, whereas the lines prior do not imply multiple specifications. See below for fix.

line 4:
This again refers to specificationS, but it is unclear if all specifications have to change in sync or not, and what happens if one changes and another doesn't. See below for fix.

line 5-6:
Change "results in non-backwardly compatible changes from" to  "result in changes that are not backward compatible with.."

For the second and third problems, I'd recommend text as follows:
"The W3C Media Annotations Working Group has defined a namespace URI, ma-ont, for use with the Ontology for Media Resource 1.0. As specifications that use this namespace URI progress through the standardization process, it is important that each subsequent revision of specifications that use this namespace MUST use the same namespace URI. However, should one or more specifications that use this namespace URI revert to Working Draft status during the standardization process, and a subsequent revision, published as a Working Draft (WD), Candidate Recommendation (CR) or Proposed Recommendation (PR) draft, result in changes that are not backward compatible with the original specifications, the namespace URI (ma-ont) MAY be changed."

Note carefully the insertion of the word "MUST" (see definition according to RFC 2119 below). This could be weakened to SHOULD if desired; however, SHOULD means that implementations would not have to use ma-ont, and imho, interoperability would be much harder to achieve.

Thoughts?

Text from RFC 2119:
1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

best regards,
John

Prof. John Strassner, Ph.D.
Head, Autonomic Research
Professor, Division of IT Convergence Engineering
Pohang University of Science and Technology
Pohang, Republic of Korea
johns@postech.ac.kr<mailto:johns@postech.ac.kr>

--- Original Message ---
>From : "Felix Sasaki"<felix.sasaki@fh-potsdam.de>
To : "Joakim S?derberg"<joakim.soderberg@ericsson.com>
Date : 2010/05/06 Thursday AM 12:43:44
Subject : Re: ACTION-255

Hi Joakim,

2010/5/5 Joakim S?derberg <joakim.soderberg@ericsson.com<mailto:joakim.soderberg@ericsson.com>>
Dear all,
Here is a suggestion for text concerning mawg namespace and ma prefix:
?
?
Media Annotations Namespace: http://www.w3.org/ns/ma-ont
?
The "ma" abbreviation is a prefix for the namespace (http://www.w3.org/ns/ma-ont) which identifies the "Ontology for Media Resource 1.0".
?
?
Stability of this namespace URI:
?
It is the intent of the W3C Media Annotaions Working Group that the Ontology for Media Resource 1.0 namespace URI will not change arbitrarily with each subsequent revision of the corresponding Ontology document as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a WD, CR or PR draft, results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification, the namespace URI will be changed accordingly.


I would change "will be changed accordingly" to "may be changed", since "ma-ont" is a nice prefix, and we don't want to force ourself to give it up.

Felix

?
?
?