Comments on the dedupe branch - for discussions later today

Leonard, all,

first of all, the changes in the dedupe branch of the UCR document are great, thanks Leonard for this!

I do have a number of (mostly minor) comments below. I was wondering whether I would put them into the issues' list, but I was afraid of polluting the github issues with a number of potentially ephemeral comments; ephemeral, because the idea would be to discuss the document, including these, later today, and if we agree on them (or reject them) on the call, they may be incorporated into the text right away. I am fine turning the issues into "real" issues after the call if it helps the editors.

The comments are purely in document order, not in the order of any other priorities of any kind.

* Section 3.1 Horizontal dependencies
 There was a use case in the original use case document on device independence. The idea was to have a (albeit possibly simple and obvious) use case for each of the horizontal aspects listed into the explanation text, hence the DI use case. I am not sure it is a good idea to remove it.

* Section 3.3. Constituent Resources
 The first 5 use cases are not 'personalized', so to say. They should be but, reading them closer, I wonder whether all of them are not subsumed by the other use cases that follow, ie, whether they could simply be removed (maybe the 'preload' feature of the 2nd is not reflected yet?)

* Section 3.4, Metadata
 It may be a good idea to add a use case on the fact that publishers need a way to include, or include a reference to, metadata whose vocabularies are defined by a specific area and whose role is essential in the publication chain. ONIX is an obvious example (this issue did come up during the discussions)

* Section 4.1, Distribution and Versioning
 I am not sure I understand the "(technically)" side remark…

* Section 4.2, Distribution Process
 The first use case says "He expects to be able to receive the PWP as a file (rather than only having access to it)". I am not sure that is true. As the rest of the sentence says, Ahmed "expects...to be able to load it onto its different reading devices.", but he does not care whether this is via a file or some other mechanism.
 I wonder whether the second and third use cases in the same section are really different. They both refer to the fact that the access to a publication is time limited. If so, they should be merged, imho.

* Section 5.3, Alternative reading orders
 Isn't that section, and the related requirement, subsumed by 5.1 (Random access)?

* Sections 6.1 and 6.2 (Archival Discovery and Newly Published Versions)
 Both sections, though define formally a new requirement, say that "this requirement is the same as XXX". We should not define a duplicate requirement formally in this case; those are automatically put into the table in the appendix, may be referred to from an external document, may be used, later, as a reference to see whether a spec fulfills all requirements, etc. We could
  - Either describe the extra, archival-related use case and then refer back to the existing requirement (like what do at the beginning of section 7 for Accessibility) or
  - Remove those sections altogether and add the relevant use cases where they belong.
 I am, mildly, in favour of the first approach

* Section 7.1, Accessibility metadata
 - I wonder whether it is useful to put an explicit reference to the Accessibility Metadata that is on its way to become part of schema.org <http://schema.org/>…
 - (absolutely minor) I was also wondering whether the name 'Anita' is really appropriate as the name for a use case on Hindi Braille. The corresponding wikipedia page[1] does refer to Sanskrit, but also says that "The name Anita is mostly used in Hungary and Spanish, Portuguese, Italian speaking countries as well as Indian languages with Sanskrit origins." but, at least to my ears, it is a bit misleading. What about using a more clearly Indian name like, see [2] (note that 'Anita' does not appear on [2]…). (B.t.w., we do not have a single Japanese or English name on among our users…)

* Section 7.2 Alternative media
 * Same as for 6.1 and 6.2: let us not define a formal requirement if it is an alias to an existing one

* Appendix B. Acknowledgement
 We should add Marcos, Mike Smith, and Hadrien Gandeur to the acknowledgement list…

* Appendix C. References
 I wonder whether we should not remove the [pwp] reference. By now it is fully out of sync, including its editors' copy. We may want to put it back if we publish the final version of the UCR but, for now, it may only be the source of confusion...

Talk to you later!

Ivan

[1] https://en.wikipedia.org/wiki/Anita_(given_name) <https://en.wikipedia.org/wiki/Anita_(given_name)>
[2] http://www.iloveindia.com/babynames/traditional-girls.html

----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704