PAGE 2, SUPPLEMENTARY. Click here to access main page for comments on this document.
NOTE Individual comments have been numbered in this transcription to simplify cross-referencing.
Hello, Mark,
Please find attached my comments on the CFC draft of AES60.
Best wishes, Ian.
| |
Item | Comment |
General comments: | |
| |
1 | The document claims to be based on EBU Tech 3293-2008 (see Page 1, Abstract, Paragraph 2). Alas, the EBU updated Tech 3293 in October, 2010 (to v1.2). However even though Annex E cites Tech 3293 v1.2 and Annex G appears, at a cursory glance, to reflect that update, the assertion in the Abstract is not just an oversight, for there are further problems elsewhere in the document, such as Page 7, Section 4.1.4.2.2 and Page 9, Section 4.2.1.1(see specific comments below). Therefore, there needs to be a detailed review to ensure that this document reflects the current status of Tech 3293. Having found several such problems, I did not analyse the document further for them, but I leave it to the Committee to resolve all such discrepancies throughout the document. |
| |
2 | I also found a missing Normative Reference (W3C Date and Time Format) and so the document will also need to be checked for any other citations of what ought to be Normative References.) |
| |
Specific comments: | |
3 | Page 1 Abstract Paragraph 2: " ... is also provided in case this metadata would be implemented - for example in archive exchange projects - using the Open Archive Initiative's Protocol ..." The parenthetical use of the dashes leads to the unintended limitation of using the metadata only for the Open Archive Initiative's Protocol, but this is (surely!) not intended. Removing that limitation, using a more natural form of expression and touching-up the syntax, I suggest: " ... is also provided to allow this metadata to be used in, for example, archive-exchange [NB hyphen] projects which use the Open Archive Initiative's Protocol ..." |
| |
4 | Page 4 Introduction: Typos: Paragraph 4: "cultural heritage databases" should be "cultural-heritage databases" ... |
5 | ... and "broadcasting" in two places should be "broadcast". |
| |
6 | Page 5 Section 0.1: Typo: "Examples are show ..." should be: "Examples are shown ..." |
| |
7 | Page 5 Section 1 Paragraph 2: " ... is also provided in case this metadata would be implemented - for example in archive exchange projects - using the Open Archive Initiative's Protocol ..." The parenthetical use of the dashes leads to the unintended limitation of using the metadata only for the Open Archive Initiative's Protocol, but this is (surely!) not intended. Removing that limitation, using a more natural form of expression and touching-up the syntax, I suggest: " ... is also provided to allow this metadata to be used in, for example, archive-exchange [NB hyphen] projects which use the Open Archive Initiative's Protocol ..." |
| |
8 | Page 5 Section 2: ISO 15836: 2009 The document is here (payment required to obtain it): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=52142 |
| |
9 | XML schema: I suggest refining the link to: http://www.w3.org/standards/xml/schema |
| |
10 | Namespaces in XML: I suggest refining the link to: http://www.w3.org/TR/xml-names/ |
| |
11 | Normative Reference missing (it's currently in the Informative links of Annex F): W3C Date and Time Format, cited in Section 4.2.14.1 (at least). http://www.w3.org/TR/NOTE-datetime |
| |
12 | I suggest that the Normative References to RFCs 2045 and 3339 should point to: http://tools.ietf.org/html/rfc2045 and http://tools.ietf.org/html/rfc3339 respectively. |
| |
13 | Page 6 Section 4.1.2: Because we are being offered an general example and because the numbers of the sub-sections need not have the value "1", "n.1.1.1" should be "n.m.o.p" - or perhaps better, "a.b.c.d". |
| |
14 | Page 6 Section 4.1.3: " ... an XLM-schema [sic] thus the data [...] XML-documents. The structure [...] will typical be something like:". should be improved to: " ... an XML schema. Thus, the data [...] XML documents. The structure [...] will be typically something such as:". |
| |
15 | Page 7 Section 4.1.4.1 Paragraph 2: "Reference data identified above is proposed by default but can be ..." Where is "above"? I suggest: "The reference data identified in section 4.2 is proposed by default but it [NB] can be ..." |
| |
16 | Page 7 Section 4.1.4.1 Paragraph 2: " ... in the case of exchange ..." is more naturally expressed as: " ... for exchange ..." |
| |
17 | Paragraph 3: " ... it is recommended to use predefined 'relations' ..." is more naturally expressed as: " ... it is recommended that predefined 'relations' be used ..." |
| |
18 | Alas, I am not sufficiently familiar with the terminology of the European Digital Library, but I think that 'relationships' is probably what is meant instead of 'relations'. |
| |
19 | Page 7 Section 4.1.4.2.2 "This group is only associated to a title ..." would be expressed better as: "This group is associated with only a title ..." |
| |
20 | Attributes startYear, endYear, startTime and endTime are missing. (They weren't present in Tech 3293 v1.1, but they are in v1.2 and see (e.g.) Sections 4.2.1.2.2 and particularly 4.2.7.6 and Annex G, at the bottom of page 84 in this (AES CFC document).) |
| |
21 | Page 8 Paragraph 3: "This resolution method is left to the appreciation of each recipient." I think what is meant is: "The resolution method is left to the discretion of each recipient". |
| |
22 | Page 8 Figure 2: The "??" after "IETF" can be removed. |
| |
23 | Page 9 Section 4.2.1.1 Definition Last paragraph: "If present, the startDate [...] in the date attribute ..." The EBUCore refers to the attributionDate attribute and the AES Core has the attributionDate attribute (see Annex F, mid-way down Page 59). The text here needs to be updated to reflect EBUCore v1.2, the citation of Annex E and the list in Annex G. |
24 | [No further analysis here of AES Core vs. EBUCore discrepancies - see General Comment. However, further work is needed to bring this document into agreement with Tech 3293 v1.2, rather than v1.1.] |
| |
25 | Annex A: " ... contribute to OAI (open Architecture Initiative) for metadata harvesting." Bearing in mind the document's Abstract and Scope, probably what is meant: " ... contribute to the OAI (Open Architecture Initiative) Protocol for Metadata Harvesting." |
| |
26 | Annex A: "... in case the schema urn would not be present ..." would be expressed better as: "... in case the schema urn is not present ..." |
| |
27 | Annex A: " ... associated to ..." would be expressed better as: " ... associated with ..." |
| |
28 | Typo: "Resource related information ..." should be "Resource-related information ..." |
| |
29 | Annex C: I can see that there is a problem with the layout of the "Aliases" and the links on a portrait-oriented page. If the portrait orientation is to be maintained, the inset of the link on the next line (as in the first item and - most of - the genre sub-section) works well and creating a table with alternate items shaded might help too. E.g. ebu_TitleStatusCodeCS http://www.ebu.ch/metadata/cs/web/ebu_TitleStatusCodeCS_p.xml.htm ebu_RoleCodeCS http://www.ebu.ch/metadata/cs/web/ebu_RoleCodeCS_p.xml.htm Library of Congress Subject Heading (LCSH) [link required] Consistency of layout - including typeface convention - is required though. Numerous links are still required. I don't know all the refinements required so as be able to help. |
| |
30 | Annex F: Consistency of layout with Annex C (however it is done) would be useful. This Annex exhibits a variety of styles and typefaces. |
| |
31 | "EBU Metadata": Given the text of the - out-of-date - link, I suggest: "EBU Metadata Specifications: http://tech.ebu.ch/MetadataSpecifications" |
| |
32 | EBU Metadata News: Given the text of the - broken - link, I suggest: http://tech.ebu.ch/metadata |
| |
33 | PBCore: This link now redirects to: http://pbcore.org/ |
| |
34 | IOC: This is a broken link and anyway, I'm not sure why it is here, for I see no reference to the IOC, Olympic or Olympics (never mind the UK's participation) in the document (and nor do any of those terms appear in EBU Core v1.2). Remove it. |
| |
35 | ISO 639: This link points to the Registration Authority for ISO 639, which could be a useful link to have too, but ISO 639-2: 1988 (as in the existing, Library Of Congress, link) itself is here (payment required to obtain it): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=4767 NB The link needs to follow the organisation's name (and location, if used). |
| |
36 | ISO 3166-1: 2006: The document is here (payment required to obtain it): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=39719 |
| |
37 | ISO 4217: 2008: The document is here (payment required to obtain it): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=46121 |
| |
38 | ISO 8601: 2004: The document is here (payment required to obtain it): http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm? csnumber=40874 |
| |
39 | IETF RFC 2326: The document is here: http://tools.ietf.org/html/rfc2326 |
| |
40 | IETF RFC 3066: The document is here: http://tools.ietf.org/html/rfc3066 |
| |
41 | IETF RFC 3339: This is cited (correctly) as a Normative Reference (Section 2) and so needs to be removed from here. |
| |
42 | W3C Date and Time Format: This Format is cited in the document and so needs to be moved to the Normative References in Section 2. |
| |
43 | MIME media type registry: This link appeared in Annex C and so it can be removed from this Annex. |
| |
44 | SMPTE 12 and 330: The SMPTE has changed the way it names its standards; see: http://www.smpte.org/standards/renumbering SMPTE ST 0012 is in two parts (payment required to obtain both of them): http://store.smpte.org/product-p/st%200012-1-2008.htm and http://store.smpte.org/product-p/st%200012-2-2008.htm SMPTE ST 0330 is here (payment required to obtain it): http://store.smpte.org/product-p/st%200330-2004.htm |
[Ends] Ian Rudd, June 2011.