Re: Comments on the dedupe branch - for discussions later today

Appreciated.

Yeah, let’s wait on the meeting before adding the issues…

Explanations on your questions
3.1 – I removed it because (IMO) it didn’t actually talk to the topic, but just grabbed multiple concepts and threw them together.  I agree it would be good to have a use case where, but this wasn’t it.

3.3 – Good point.  They do indeed need cleanup!

3.4 – Yes, definitely should add a use case around that.

4.1 – I was trying to find a way to differentiate logically different versions (where you and I each have the same version, but you’ve added comments to yours) and technically different versions (where the author puts out a change).  Open for suggestions.

4.2 – Yes, first use case could use a cleanup.   I thought about 2nd and 3rd when I was working on it and felt that it was worth leaving them separate as they talk about two different types of distribution – a purchased subscription vs. a loaner.  But I’m open to alternatives.

5.3 – The way I looked at it, Reading Order and Alt Reading Order are two reasons we need Random Access, but they aren’t the only reason.  I wanted to keep them separate so that folks understood each of the three as separate requirements (though it may end up that they are all solved by the same thing technically).

6.1 & 6.2 – I wanted to leave the requirements in place so that people could see that there are other reasons we need the same concepts, but did indeed try to link it back.  Maybe putting back a specific use case for each would make them stronger in their current form.  Definitely open to suggestions.

7.1 – Referencing the schema.org work would seem like a great idea, even if only as part of a use case.  And as for Anita – fine with me, the name was already there.

7.2 – Same comment as 6.1/6.2, I felt it was important to clearly spell out that there is another reason we need those things.  But perhaps we can find an alternative way to accomplish the same thing.

B – Absolutely!  (I didn’t touch that section)

C – Agreed, good idea!

Thanks for taking the time to read over my changes and send this feedback!   Talk to you in a few.

From: Ivan Herman <ivan@w3.org>
Date: Monday, October 10, 2016 at 6:28 AM
To: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: 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)
[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