Publishing Working Group Telco — Minutes

Date: 2018-06-25

See also the Agenda and the IRC Log

Attendees

Present: Teenya Franklin, Deborah Kaplan, George Kerscher, Matt Garrish, Tzviya Siegman, Dave Cramer, Avneesh Singh, Wolfgang Schindler, Ivan Herman, Luc Audrain, Ben Dugas, Benjamin Young, Ric Wright, Jun Gamou, Juan Corona, Garth Conboy, Mustapha Lazrek, Ben Walters, Ben Schroeter, Caitlin Gebhard, Gregorio Pellegrino, Charles LaPierre, Murata Makoto, Franco Alvarado, Chris Maden, Brady Duga, Joshua Pyle, Romain Deltour, Bill Kasdorf, David Stroup, Adam Sisco, Laurent Le Meur, Reinaldo Ferraz

Regrets: Rachel Comerford, Marisa DeMeglio, Jeff Buehler, Jasmine Mulliken, Vladimir Levantovsky

Guests:

Chair: Tzviya Siegman

Scribe(s): Benjamin Young

Content:


Tzviya Siegman: I believe we have someone new this week
… Juan?

Juan Corona: hi everyone. I’m with EvidentPoint Software
… we’ve worked with IDPF in the past
… both as a contributor, developer, and we also contribute to the Readium project
… I’m very interested in a packaged web publication–EPUB4, naturally
… I want to bring my JS developer experience to the table
… I’d like to explore reading system implementations, polyfills, etc.

Tzviya Siegman: we’re excited to have you here and impressed by the homework you’ve done!
… feel free to contact us–the chairs (tzviya and garth) and the staff contact (ivan)

1. minutes approval

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

Tzviya Siegman: minutes approved.

Resolution #1: last week’s minutes approved

2. Pending PR-s

2.1. table of content

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

Tzviya Siegman: we had an issue about the Table of Contents in the manifest
… issue 234, but there’s also a pull request for this…
… pull request 246

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

Ivan Herman: the discussion was around having a separate file for a ToC
… but if it’s already in the entry page HTML file, then we use that
… and we also discussed using the same sort of Link mechanism in the manifest to point it in either case
… and this is why I created a PR for this, so we can move on quickly

George Kerscher: so I’m guessing this is the first thing most UAs would want to display
… so is this front and center? or is this twice removed?

Ivan Herman: the HTML file that references the manifest may also contain the Toc
… and in this case, the UA will have it
… if there is no ToC, then the manifest would be consulted
… and that may reference another file

Joshua Pyle: +1 to doc-toc in the landing page being sufficient

Garth Conboy: it seems like it’s either one step closer to find the ToC as it was to find the nav file in EPUB

Ivan Herman: that’s correct

Tzviya Siegman: and rel=”contents” did we invent that? or did that exist?

Ivan Herman: it exists already in IANA

Brady Duga: sorry, jumping in late, but are we discussing whether the ToC must be in the entry page?

Garth Conboy: it SHOULD be in the entry page, and if not it would need to be referenced from the manifest

Garth Conboy: https://github.com/w3c/wpub/issues/234#issuecomment-398788017

Brady Duga: I’m guessing bigbluehat is still annoyed that this still keeps the ToC out of the entry page potentially

Garth Conboy: right now we’re discussing the SHOULD of it, but we could still discuss that SHOULD becoming a MUST
… my hopes is that this is approvable and that we can move on to future work after that

Resolution #2: approve and merge the PR (#246) for TOC

Tzviya Siegman: hearing no objections, this is approved, and let’s move forward

2.2. links vs. externalResources

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

Ivan Herman: Pull request: https://github.com/w3c/wpub/pull/244

Ivan Herman: warning, this is a bikeshedding issue

Tzviya Siegman: do you want to skip it?

Ivan Herman: no, we do need to address it
… we’ve agreed that there are resources which are not in the resources of the publication
… right now the popular one (slightly) is links
… but it’s been a wide ranging discussion

Tzviya Siegman: any questions about this one?

Garth Conboy: or should we vote on this now

Garth Conboy: +1’s for switching from externalResources to links

Garth Conboy: +1

Bill Kasdorf: sorry, I’m coming in late, but isn’t it possible that a link would link to a core resource, not just a general resource?

Ivan Herman: this would be for non-core resources

Laurent Le Meur: +1

Luc Audrain: +1

Wolfgang Schindler: 0

Ivan Herman: 0

Matt Garrish: 0

Tzviya Siegman: 0

Bill Kasdorf: +0

Joshua Pyle: 0

Charles LaPierre: 0

EvanOwens: 0

Avneesh Singh: 0

Ric Wright: 0

Caitlin Gebhard: 0

Brady Duga: !garth

Bill Kasdorf: 0

Tzviya Siegman: k. I think we can move on with this one then

Resolution #3: merge PR #244 (in favor of links)

2.3. restructuring of the draft (was PR #238)

Tzviya Siegman: Matt did a major revision of the draft in #238
… I just wanted to be sure that everyone was clear on the new structure
… mattg could you go through the changes that you’ve made?

Matt Garrish: basically, we were going through all the terms and ideas twice
… so, this PR puts it into a single list, but with infoset and manifest subsections
… if you’re looking for information on any of these, then you’re not hopping around trying to make sense of each thing
… so section 3 was kind of the things left over after I did that
… so it explains why we have an infoset and manifest terminology
… then there was another PR that cleaned up some of the required values tables
… each pulled out into other columns

2.4. PR on guided navigation

Tzviya Siegman: there is an affordance PR open about guided navigation

Ivan Herman: that PR came from a previous life, so this is before the restructuring
… we also discussed restructuring where the affordances would be expressed
… we should probably close this PR without merging until we know where affordances will live in this new structure

Joshua Pyle: +1 to close without merging

Matt Garrish: some of this is already covered in the progression direction
… and I’m fine to close this PR and address it further if necessary

Resolution #4: close the PR (#214) on guided navigation without merge

3. Affordances

Garth Conboy: https://github.com/w3c/wpub/labels/topic%3Aaffordances

Tzviya Siegman: we do have a bunch of affordance issues
… what we decided last week is that these would be written up within an issue
… and then inform the use case document
… we do have a number of outstanding issues
… please everyone who’s signed up for these, please dive back in and file these issues
… if you’re not able to finish these, please let us know
… so that we can reassign them

Charles LaPierre: I am still working on personalization, and will be bringing this up in the Personalization TF meeting after this.

Joshua Pyle: to be clear, the affordances that I agreed to write that have to do with paging, I’m putting those in the UCR rather than for the WPUB draft
… once they’re in the UCR, then we’re going to point to the UCR from the draft
… is that correct?

Tzviya Siegman: I think we have to figure out the relationship between the UCR and WPUB draft

Joshua Pyle: as an implementer, it’s actually nice to have two documents rather than having all the reasoning mixed into the spec document

Ivan Herman: essentially yes, with one additional item
… we should not only reference the UCR document, but also say what of the manifest or infoset items are necessary or maybe sufficient for that use case to be doable
… so not only a link, but some sort of analysis of how it’s expressed according to the spec

Tzviya Siegman: any other comments on this topic?

4. schema.org discussion items

Tzviya Siegman: we have a list of terms we’re planning to raise with Dan Brickley that we’d like to get added to schema.org

Ivan Herman: I have https://github.com/w3c/wpub/wiki/Schema.org-problems
… this is a wiki page of the items that we map into schema.org
… so 6 items that I remember that may be troublesome with schema.org
… some of you have experience with schema.org
… so we should discuss these before we address these with Dan or whoever from schema.org
… should I go through these items one by one? to see about differing opinions?

Tzviya Siegman: we can do that

Ivan Herman: one problem is that we have a family of items
… there is the creator, but then there are many different classes and types of them (authors, editors, etc)
… in schema.org these are not ordered lists
… but for many publishers, the ordering is important
… we can express this in our context file
… but it’s not clear what the schema.org processors will do with that information (if anything)
… there’s also some mention of other places this has been a problem in schema.org
… one was recipe ingredient ordering
… they have something they use for ordered lists
… and we’ll need to see if that works for our terms
… Another item at issue is the class CreativeWork
… they have many sub-types, Comic, etc.
… if we want to create new items, what is the best mechanism for this
… but this is something we’ll need to synchronize with schema.org
… any questions or comments?
… the 3rd and 4th are related
… we need to be able to control the language of the terms
… we have that in the info set
… and it has the scope of the things expressed in the manifest
… and it is separate from the language expressed in the HTML file that contains or references the manifest
… right now, surprisingly, there’s no way to do this in schema.org
… there is a way to do it within JSON-LD, and I’ve included an example in the wiki
… but it’s unclear if the schema.org will use that properly
… where this matters are cases like author names being in one language, when the content is in another language
… at this point Google’s schema.org processor rejects that sort of expression
… but both of these things are absolutely improtant

Bill Kasdorf: when you refer to language, are you also referring to script? or is that important/

Ivan Herman: yes and no
… to be precise, I’m referring to codes in BCP47
… the values that are in BCP47 cover both language and script

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

Ivan Herman: so it is possible to express Chinese in either simplified or traditional
… so that’s covered with BCP47
… so these two are important
… there is a possible solution
… JSON-LD 1.0 has a way to express the same term in multiple languages
… a typical case is a name expressed in Chinese and transliterated in English
… that can be done via an indexing mechanism
… sadly, that’s completely unknown to schema.org
… it would make things much simpler, but I suppose we could live without them…though grudgingly

Joshua Pyle: I hope this isn’t a can of worms and it seems where making some progress with authors, editors, and things
… but one of the things I’d like to know as a processor of these documents
… if I mark up all these in JSON-LD, should I also markup my stuff in RDFa?

Ivan Herman: you don’t need to

Joshua Pyle: k. the ScholarlyHTML community was working on RDFa for expressing similar things

Tzviya Siegman: it’s going to be redundant anyway because we’re going to be displaying it in the markup

Joshua Pyle: I realize it’ll be redundant for display, but what about the RDFa spans and such to express these things?
… if I do those things, do they relate? or do they interact? which takes precedence?
… or which route do I take if I’m building something for both of these communities?
… I’d really like a format to rule them all

Ivan Herman: so it is a can of worms
… schema.org is expressed in generic terms
… and that community, they tell you that if you want to express these terms you can use JSON-LD or RDFa, then you can
… we decided up ‘till now to pick only syntax to express those things
… we could say, you can express them in one or the other, or both, and somehow resolve them
… my fear is that could complicate and confuse things
… though it is a generic problem, so might still need addressing somewhere
… my experience with RDFa is that it can be complicated to get the expression right
… and you’ll do lots of testing to get the expression correct to get the processors to be happy with the RDFa
… that is why, I think JSON-LD has become…not preferred as a requirement, but in practice the most widely used format for schema.org
… so, for the time being, we say use JSON-LD
… I can’t comment on the ScholarlyHTML CG
… I know lots of people there were pushing for the RDFa
… my preference would be for them to use JSON-LD in a script tag
… but I’m not active there, and it’s really their issue to address

Joshua Pyle: one last thing to wrap this up, I’ve no personal problem, I’d just like to not do it twice
… I like RDFa because it puts the schema on top of the data
… where as JSON-LD puts the data on top of the schema
… and JSON-LD is necessarily redundant
… so author name is always going to appear at least twice

Tzviya Siegman: yeah, we’re probably getting off topic
… and we could discuss this for hours

Ivan Herman: yeah. let’s push this to a different discussion

Tzviya Siegman: is there anything else here ivan?

Ivan Herman: yes, there’s one more about linking to external resources
… we have defined our own object, Publishing Resource object
… and we were wondering about using an existing type (whatever the name was…)
… and that looked like a very good idea
… except for reasons which I can’t really understand, is that the fileFormat can’t be used for the kind of use we need it for
… if that were addressed by schema.org, then we could just use their thing
… so, these are the things that I gathered with Dan Brickley

Garth Conboy: the issues that are in the agenda, page marks, land marks, etc.
… is that…

Avneesh Singh: we also need to explore conformance metadata to schema.org

Avneesh Singh: https://idpf.github.io/epub-vocabs/package/a11y/

Avneesh Singh: so there are 4 items that we did for EPUB
… and we discussed porting these to schema.org

Tzviya Siegman: was there ever an attempt to do this with schema.org?

Avneesh Singh: they said they’d discussed them, but it didn’t make it
… but we should re-raise it with them if we need it

Ivan Herman: I will have to add those to the wiki
… and at some point, we’ll need to make a clearer document to discuss this with them
… we’ll have to see where we go with this
… my guess is that they will say, “has anything changed since this was first submitted?”
… what are the new issues to make this worth reopening the discussion
… I’d like to find out if we have that before asking them again

George Kerscher: I think the discussion around this a long time ago, was around every web page in the world having a “conformsTo” statement
… wouldn’t be practical
… what’s different now, is that we have a WG where that need becomes clearer as it applies directly to our publishing needs

Avneesh Singh: so, this answer was from the WCAG group, that it would need to be optional/additive
… when we sent it to schema.org, we got absolutely zero response
… so we can point out that there was no previous consensus, and instead push for consensus this time for these new reasons

Tzviya Siegman: since that time, schema.org has done work with the openbadges community
… they’re also beginning to work with the fact checking CG folks
… it’s certification, but its a very different sort of certification
… but it does exist

George Kerscher: we should make it clear that conformance and certification are different

Tzviya Siegman: yes, but the tagging will be similar

Tzviya Siegman: schema.org claimReview for fact checking https://schema.org/ClaimReview

George Kerscher: true

Ivan Herman: schema.org has this mechanism for extensions
… we know many of them we hope to use come from bib.schema.org extensions for bibliography
… so, if we have other things that “deserve” to be in schema.org, but we could begin them in an extension
… it’s a possibility, but I’m a little bit worried
… we are currently trying to specify terms for our infoset terminology
… but if we open it up wider to include all kinds of publishing related terms, we may cause many more problems

Tzviya Siegman: we have specific needs of the larger group, but may not be part of the minimal set
… so maybe we’d want an a11y task force to take this up
… 222, 223, and 225 are about page lists and offlining
… so figure that out and come back to us in a week

George Kerscher: before we schedule anything with Dan, I think we really need to have our ducks in a row
… and that we’re all clear about what we’re asking
… do our a11y task force need to be ready at that meeting?

Ivan Herman: I’d prefer we have some sort of priority here
… some of these like language and ordering of authors, are absolutely fundamental for any web publication
… they, may become deal breakers for using schema.org
… so I would consider these a primary thing
… a mechanism to extend CreativeWork, however that gets solved is less of a concern
… the a11y terms I am not sure

Avneesh Singh: we talked about a backup plan
… if schema.org doesn’t want these terms, we’d like to use them from epub-vocab
… so it would not be a show stopper

Ivan Herman: the backup plan is good, we already have a few of our own terms, context file, etc.
… we’re working to keep that small
… but as you say there is a backup plan

Tzviya Siegman: that’s the end of the meeting them


5. Resolutions