Publishing Working Group Telco — Minutes

Date: 2018-06-11

See also the Agenda and the IRC Log

Attendees

Present: Jun Gamou, Tzviya Siegman, Luc Audrain, Zheng Xu, Hadrien Gardeur, Deborah Kaplan, Caitlin Gebhard, Rachel Comerford, Wolfgang Schindler, Franco Alvarado, Laurent Le Meur, Wendy Reid, Dave Cramer, Derek Jackson, Joshua Pyle, Jeff Buehler, Gregorio Pellegrino, Ben Schroeter, Garth Conboy, Bill Kasdorf, Tim Cole, Ric Wright, Jean Kaplansky, David Stroup

Regrets: Avneesh Singh, George Kerscher, Romain Deltour, Marisa DeMeglio, Adam Sisco, Ben Walters, Jasmine Mulliken, Nick Ruffilo, Benjamin Young, Teenya Franklin, Vladimir Levantovsky

Guests:

Chair: Tzviya Siegman

Scribe(s): Joshua Pyle

Content:

Ivan Herman: ivan+

1. Minutes from previous meetings

Tzviya Siegman: Minutes from the F2F. Comments?

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-05-31-pwg.html

Tzviya Siegman: https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-06-04-pwg.html

Tzviya Siegman: Minutes from F2F Day 1 approved.
… Minutes from F2F Day 2 approved.

Resolution #1: Minutes of F2F approved

Tzviya Siegman: Minutes from last week approved.

Resolution #2: Minutes of last week meeting approved

2. Covers

Tzviya Siegman: https://github.com/w3c/wpub/issues/210

Tzviya Siegman: DAISY team in not here (in another meeting). Should cover be part of the infoset or stand-alone?

Luc Audrain: The cover was identified as something generally useful for book shelf support. It could be a thumbnail, but any image (icon) could be useful.
… We had a discussion about where (within schema.org) a cover could be described.

Deborah Kaplan: We need to be able to associate alt-text with a cover. If images are part of structural properties then they must be described like other content.
… Creators need just one place to put the cover, describe the cover, etc…

Rachel Comerford: If the cover is included in the infoset, do the reading systems have a way to access that?

Ivan Herman: I am worried about the question. My recollection is that using any schema.org properties for a cover is a problem because all they do is assign a URL to an image. You could add metadata to the object which refers to the image. The cover is a resource (like any other) in HTML5 and can therefore use any of the a11y features of HTML5.

Dave Cramer: http://schema.org/ImageObject

Dave Cramer: I think I disagree with dkaplan3. I see the utility in a cover independent of what content authors would be doing for the reader. As an author I want to determine how to display a cover (via HTML etc).

Hadrien Gardeur: I have provided two ways to do this in the example. Perhaps we should consider using rel values. This issue is related to TOC and Privacy Policies as well as covers.

Garth Conboy: I agree with dauwhe and Hadrien. In EPUB land there was confusion and reader could display two covers… I don’t think we want to force reading systems to hunt through the content to find the cover.

Deborah Kaplan: We need to have (what we don’t have in EPUB) clear, consistent instructions on what to do with a cover that covers the vast majority of use cases. Image content (that is important, like a cover is) must have metadata that describes it.
… it is not okay to have a place for an image without defined procedures for defining the image as a requirement.

Dave Cramer: +(a)1(1y)

Garth Conboy: I agree with dkaplan3.

Deborah Kaplan: +1 Ivan

Ivan Herman: When we refer to external resources, we should use http://schema.org/StructuredValue. There is a description. There is a URL. So we are half way there. What is missing is a “rel” equivalent. I am not yet sure how we would do that.

Ivan Herman: http://schema.org/StructuredValue

Bill Kasdorf: Is the cover actually important content?

Deborah Kaplan: Decorative images do require blank alt text.

Bill Kasdorf: So we do still a way to indicate blank alt text.

Deborah Kaplan: Indeed.

Ivan Herman: No one has answered this question: If I have a resource that I want to indicate as a cover. I am not sure how to do that.

Tim Cole: Covers are artwork that may have an image.

Ivan Herman: Are we sure that a cover will always have an image?

Tim Cole: Covers are creative content. An image is not required.

Hadrien Gardeur: I don’t everything listed will be structured data.

Luc Audrain: during the F2F we suggested using ARIA roles.

Ivan Herman: ARIA roles are not in JSON-LD.

Tzviya Siegman: “@type”: “http://bib.schema.org/CoverArt”

Tzviya Siegman: Can we resolve the cover image issue without addressing related items?

Garth Conboy: Cover needs to be optional. If present it should be an image.

Laurent Le Meur: def of CoverArt: The artwork on the outer surface of a CreativeWork.

Ivan Herman: I have a slightly radical proposal. Schema.org came up as a convenience. We should realize that we are talking about values assigned to terms which are not in schema.org.
… I think we are hitting the limits of schema.org. We could define our own type. Hadrien did this for Readium.

Tim Cole: We can define a type in our own vocabulary. Google will ignore the additional type but works for systems that care about it.

Tim Cole: http://bib.schema.org/additionalType

Hadrien Gardeur: It is possible to have our own structure since we have a context. We can have something like “spine” etc that map back to schema.org. I tried the Google tester and it seemed to understand. We need our own context for other reasons.

Ivan Herman: One of us should propose a specific type that we will use.

3. Proposed Context

Tzviya Siegman: https://github.com/w3c/wpub/issues/212

Tzviya Siegman: https://github.com/w3c/wpub/issues/215

Tzviya Siegman: Question about this?

Hadrien Gardeur: We have an initial structure to start from. We can map those without difficulty.

Ivan Herman: There is a JSON-LD context for various reasons in the repository. We should review it.
… I put in a pull request to map above to schema.org adding some more entries.
… PR 221.

Ivan Herman: https://github.com/w3c/wpub/blob/master/common/context.jsonld

Tzviya Siegman: https://github.com/w3c/wpub/pull/221

Wolfgang Schindler: Does the context say that the reading order an ordered list while other is unordered?

Hadrien Gardeur: Yes.

4. Audio Books

Tzviya Siegman: Wendy Reid will be inviting members to join an Audio Books Task Force. Thanks to Wendy Reid for heading this TF.
… please reach out if you are unfamiliar with any of this.

5. Bike-shedding on Names

Dave Cramer: Spine is a problematic term with a lot of history. I worry about non-English speakers. Is “spine” meaningful around the world?

Ivan Herman: “Spine” in EPUB was initially confusing to me. I did not know that. I agree with dauwhe

Bill Kasdorf: so what’s wrong with reading order?

Garth Conboy: What other terms are acceptable?

Bill Kasdorf: +1 to readingOrder

Dave Cramer: Something like reading order. Descriptive terms out-weigh the cost of a longer name.

David Stroup: sequence or readingOrder

Ivan Herman: schema.org has plenty of long terms. readingOrder seems perfectly fine to me.

Laurent Le Meur: agree with Ivan

Tzviya Siegman: Proposed: use readingOrder

Ivan Herman: +1

Tzviya Siegman: +1

Bill Kasdorf: +1

Luc Audrain: +1

Wolfgang Schindler: +1

Rachel Comerford: +1

Laurent Le Meur: +1

Caitlin Gebhard: +1

Zheng Xu: +1

Franco Alvarado: +1

Derek Jackson: +1

Jeff Buehler: +1 reading order

Ben Schroeter: 0

Tim Cole: +1

Dave Cramer: +1

Hadrien Gardeur: +1

Garth Conboy: +0.5

Wendy Reid: +!

Deborah Kaplan: +1

Jean Kaplansky: +1

David Stroup: +1

Joshua Pyle: +1

Resolution #3: readingOrder it is!

Tzviya Siegman: Resources?

Bill Kasdorf: addlResources?

Jean Kaplansky: extra!!!

Ivan Herman: I would be more careful and suggest “extraResources”.

Jean Kaplansky: Think of the non-native English people in the world. :)

Laurent Le Meur: +1 for extraResources

Bill Kasdorf: +1 to extraResources

Luc Audrain: Why extra ?

Luc Audrain: +1 to “resources”

Wolfgang Schindler: We need to consider external resources which may or may not be included. The line is blurred between “within” and “without” our publication. Ancillary is more clear.

Jean Kaplansky: Non-native English-Speaking people are less likely to know “ancillary” or that “addl” is an abbreviation of “additional”

Luc Audrain: I agree with Hadrien. Why not just “resources”?

Bill Kasdorf: do we need to distinguish ancillaryResources and externalResources?

Ben Schroeter: etCetera

Laurent Le Meur: Ancillary does not work well for French speakers.

Zheng Xu: +1 to “resources”

Bill Kasdorf: otherStuff

Jean Kaplansky: “extra” is probably as good as we’ll get.

Proposed resolution: resources (Tzviya Siegman)

Luc Audrain: +1

Dave Cramer: +1

Hadrien Gardeur: +1

Jean Kaplansky: +1

Ivan Herman: +0.8

Garth Conboy: +1

Wolfgang Schindler: +1

Bill Kasdorf: +1

Zheng Xu: +1

Tim Cole: 0

David Stroup: +1

Tzviya Siegman: 0

Wendy Reid: +1

Joshua Pyle: 0

Franco Alvarado: 0

Derek Jackson: 0

Laurent Le Meur: +1; same with extraResources

Ben Schroeter: 0

Jeff Buehler: 0

Caitlin Gebhard: 0

Proposed resolution: extraResources (Tzviya Siegman)

Ivan Herman: +1

Tzviya Siegman: +1

Jean Kaplansky: +1

Franco Alvarado: +1

Bill Kasdorf: +1

Wolfgang Schindler: -1

Laurent Le Meur: +1

Joshua Pyle: +1

Garth Conboy: +0.8

Hadrien Gardeur: 0

Tim Cole: 0

Jeff Buehler: 0

Ben Schroeter: +1

Luc Audrain: -0.99

Zheng Xu: -1

Dave Cramer: 0

Wendy Reid: -1

Resolution #4: resources it is!

Tzviya Siegman: there are many action items to be delivered this week. Please check GitHub with affordances label.

Tzviya Siegman: https://github.com/w3c/wpub/labels/topic%3Aaffordances

David Stroup: can we add properties to ‘resources’ to make the necessary distinctions folks want to make?

Ivan Herman: There were some questions that folks should review an act on.

Ivan Herman: I would prefer folks edit and make pull requests.

Joshua Pyle: Meeting adjourned.

6. Resolutions