RE: A first DRAFT of my action item

Hi. John and all.

@John: Thanks a lot for updated ontology doc J

 

I will reflect the revised parts to XML source file of ontology doc.

 

For the taking a look at the updated part, I made the diff version between new one [2] from john and old one [3]. 

(diff tool [4] from W3C is not working well. So I try to use new diff tool [5], but I think it has some bugs.)

Please take a look at this and if you have any comment, please let us know.

 

[1] http://tinyurl.com/287g5x2

[2] http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0-jcs.html

[3] http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html

[4] http://www.w3.org/2007/10/htmldiff

[5] http://www.aaronsw.com/2002/diff/

 

Best regards,

Wonsuk.

 

 

From: public-media-annotation-request@w3.org [mailto:public-media-annotation-request@w3.org] On Behalf Of Strassner¡¡John Charles
Sent: Tuesday, May 25, 2010 5:16 PM
To: public-media-annotation@w3.org
Subject: A first DRAFT of my action item

 

Hello all,

attached please find a first DRAFT of my review of the latest ontology document from Wonsuk.

I have tried to accomplish three things:

  1) correct and standardize English usage and grammar
  2) add a conformance section
  3) insert conformance statements into the document where appropriate

In performing the above, I found a LOT of mis-spellings, which I have tried to fix. I'm sure I may have missed some. I found a LOT of inconsistencies (e.g., 16 bit, 16bit, and 16-Bit all occurred multiple times in the document), which I have tried to standardize. This is one example of many. I'm sure I missed some. There was mixed American and British English - I defaulted to American English EXCEPT where the standard itself used British English. There were many minor differences between "syntax" and "semantics" - I have made every effort to reconcile these.

For instances such as:

  "The unique portable identification of an asset is the combinations of its Provider_ID and its Asset_ID."

I have tried to make this into a real conformance statement, as follows:

  "The unique portable identification of an asset MUST be defined as the concatenation of its 
    Provider_ID followed by its Asset_ID."

This eliminates "combinations", and provides something to test conformance against. Note, however, that not all elements in the mapping table had strict definitions. For example, several just had "String" as a datatype, with no character length indicated. This is not sufficient to provide a conformance statement against.

However, in doing the above, I have encountered a number of problems when edting the specification. I wasn't sure how to fix these, so left them alone. Note that these SHOULD :-) have conformance statements associated with them.

In general, the Actors elements in the mapping table are all not specified very well. The Studio_Royalty_Flat_Rate is ill-specified (e.g., no currency symbol is given, no upper limit is given). 

There were several elements, such as Screen_Format, that **seem** to imply conformance level values (e.g., enumerating of Standard, Widescreen, Letterbox, OAR), but did not explicitly do so. In addition, they did not indicate if this was a completely defined enumeration or not.

I was not sure what was meant by a "numeric string" (e.g., in ma:frameSize or in ma:numTracks).

For the DIG mappings, the ma:identifier datatype is ill-specified. It says "ComplexType: sequence of UID (string <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#string> ) and ID_TYPE (URI <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#anyURI> )"; the obvious problem is, what does "sequence" mean (one instance or many). Note also that this is the first usage of UID, and as such, it should be defined. (Earlier, UUID was introduced, also without a definition!). The ma:license DIG mapping is ill-specified (i.e., "Complex types using different fields..." needs a more precise definition).

For the ID3 mappings, what exactly is a "numeric string"? This needs to be defined.

For the LOM mappings, the datatype "string(vCard)" is not precise. What version of vCard are you using? In addition, the vCard format allows private extensions, and is best described as a complex data type, not as a string, imho. In addition, what is a Duration datatype? (It was mis-spelled as Duraction).

Why, in MediaRDF, do you suddenly switch from "string" to "plain literal"? Datatypes shoudl be consistent. Note that most of this table is NOT specified...

In MediaRSS, several properties are complex types, but you have their datatypes as "string".

For the MPEG-7 mappings, there are many questions on the datatypes. For example, what is meant by "string + qualifier..."? What type of string, exactly. Is only one qualifier to be specified, or can a set be specified? What is the format of the qualifier? etc.

One important class of problems encountered occurrences of text that did not propose a final goal, as well as text that did not state a clear objective. An example of the original text illustrating this is:

    "Some more fine grained definition of the properties has still to be done: we need to define their 
     formal properties (if they are symmetric, etc) to enhance more efficient concrete mappings. The 
     mappings have to be as precise as possible to be efficiently used in the related API."

If I was a reviewer and saw this statement, I would immediately recommend that the document be returned to the working group because it was not complete. While the intent is of course very good, the  problem is that the above statement implies that the document is not finished. Therefore, why is it worthy of being declared a Recommendation?

Another example is: 

   "The group still looks at rationale for including and excluding formats to be considered in the final 
    mapping table". 

This is an open-ended statement, and as such, is not appropriate for a standard in its current form. There is no way that conformance can be defined for such a statement.

Sentences such as: "Audio PID(s) shall correspond with Languages. Two character language code from 639-1." are typically considered incomplete. For example, "639-1" is not completely specified; ideally, it should have a citation. Similarly, sentences such as "String, having a maximum of two characters per language, 1024 characters total, one language per element" are confusing:

  1) can a language code have 0 or 1 characters? (that is what "a maximum of two implies!)
  2) "element" isn't precisely defined

More fun (not!) is the following (referring to "advisories"):

  "String, one advisory per element, max 1024 characters for all advisories...There are at most
   six occurrences fo "Advisories", with a combined maximum of at most 12 characters".

The obvious problem is that 12*6 << 1024!


regards,
John
 

 <http://mail.postech.ac.kr:80/receiveMDNResponse.do?from=johns@postech.ac.kr&to=public-media-annotation@w3.org&mid=13497127.1274775340562.JavaMail.root%40mail1.postech.ac.kr&store=%2Fstore02%2Fmindex%2F989%2Fjohns&host=mail.postech.ac.kr> 

Received on Tuesday, 25 May 2010 16:42:19 UTC