Create a vocabulary of rel attributes for extra resources

[llemeurfr]

There is already a rel="cover" value (https://www.w3.org/TR/wpub/#cover) defined in the spec for referencing a cover from the list of resources. Other values already defined in the WP model are "pagelist" and "contents" (the ToC).

Audiobooks may have useful extra-resources, like a "booklet".

Which are the most useful rel values that should be defined by this group? Should it be part of the model (i.e. standardized) or expressed as best practices?

[HadrienGardeur]

related is a common relation for referencing such resources and could be used in the context of resources specifically for that.

[llemeurfr]

relatedis a generic name, as sort of see also. Doesn't a "booklet" deserve a more precise token?

[HadrienGardeur]

IMO it's a little too specific to be widely useful.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  Should there be a TOC if supplemental materials are provided in an audio book?
  Wendy Reid: https://github.com/w3c/wpub/issues/408
  Wendy Reid: issue 408: should there be a TOC? spec says there must be if supplemental content is present in the resources. Any opposition?
  Avneesh Singh: +1
  Garth Conboy: TOC is an ordered list; for many of these supplemental contents there is no specific order
  Wendy Reid: if we don’t put it in the TOC it is not referenceable for a user agent
  Garth Conboy: putting in TOC implies an order that it may not have
  Avneesh Singh: it has some order; not entirely random
  … alt text html file follows dame principle, must be in TOC
  Marisa DeMeglio: reminds me of landmarks in EPUB - not necessarily inherent order
  … don’t agree that supp content needs same treatment as alt content
  Wendy Reid: supp content can be a list of charts or pics of an author
  Avneesh Singh: concept is similar
  Ivan Herman: why is supp material so special that having it listed in the resources is not enough?
  Joshua Pyle: +1 to Ivan
  Bill Kasdorf: +1 to resources
  Wendy Reid: how should resources be represented in reading order?
  George Kerscher: resources always referenced by something; having them in TOC is provides standard mechanism to get at them
  Ivan Herman: resources is a list of references to files, each of which can have one to many rel values
  … from that point on it’s up to the user agent to find
  George Kerscher: is the rel value in the manifest?
  Ivan Herman: yes, and there may be several values as well
  Wendy Reid: See also https://github.com/w3c/wpub/issues/405
  Brady Duga: want to avoid getting bad audiobook TOCs, prefer it be an optional requirement because reading system may be able to impose its own more accurate TOC
  … TOC should not be required just to have a list of supp materials
  George Kerscher: Brady has a very good point.
  George Kerscher: TOC should be meaningful and something a RS can trust.
  Laurent Le Meur: agreed, for textbooks we have a special rel called cover, that allows us to put it in a TOC or not. if there is a small set of supp content that we always find in audiobooks, let’s use rel values like we use cover
  Wendy Reid: instead of a required TOC of supp content, we require rel value that is applicable to that type of content
  George Kerscher: having a TOC that, when present, is good and utilizable, sounds like putting a requirement on the reading system to use it if present
  Wendy Reid: if the publisher has gone to the effort, it is likely that the reading system should pay attention to it. But can’t define “good” TOC
  Marisa DeMeglio: it might be confusing if treatment is different across reading systems
  Laurent Le Meur: we are living with that with covers currently - reading systems deal with differently
  … if the rel value is not in the TOC, then the reading system won’t see it? Best practice instead of requirement
  Benjamin Young: not necessarily an ordered list; publishers can’t define order if we just have resources floating - needs to be expressible by publishers
  Laurent Le Meur: need to define what is wanted - are there other things besides booklets?
  Benjamin Young: if this is a foundational data model that we are going to share, we may have publications with a whole host of supp content
  Avneesh Singh: if there is an order that publisher want to define for supp content TOC is compulsory
  Ivan Herman: if there is supp content that has an order, there is no need to make TOC is compulsory, because that is what will be used. The toc doesn’t really make sense for content that is not in order. Unnecessary to require TOC “if x and y are true”, for example.
  George Kerscher: consistency between base spec an audiobook spec would be great, as much as possible.
  Brady Duga: the more I hear about potential use cases, the less I think we should use TOC for supp materials, and tackle when we discuss synchronized media
  … textbook and audio appear at the same time, for example
  Marisa DeMeglio: we have an issue currently regarding alternative media, like adding synchronized media to an audiobook (audiobook with text use case)
  Wendy Reid: we should create a mechanism to enable this, but also for when this doesn’t happen
  Marisa DeMeglio: maybe we should have the information in more than one place, even though that can be a bummer for reading systems
  Wendy Reid: will revisit this topic soon
  

[geoffjukes]

I'm in agreement with @HadrienGardeur here. cover is special because every book has one. I don't think we have a single book with a booklet (plenty of maps, images and worksheets though 😄 )

[llemeurfr]

plenty of maps, images and worksheets

@geoffjukes so do you think this list represents the most useful types of resources in web publications, for which we will define well-known rel values? if yes what would be their definition? what kind of publication (e-book, audiobook ...) are they attached to? if no what is, in your opinion, the best list we can create?

[iherman]

I do not have a problem with the original issue proposal, but we may want to have a better look at how we do this.

At this moment, the spec says, for the value of rel:

One or more relations. The values are either the relevant relationship terms of the IANA link registry [iana-link-relations], or specially-defined URLs if no suitable link registry item exists.

what this issue may lead to is a series of extra terms that are not in the IANA registry, i.e., we may end up with a whole lot of URL-s as possible values. While this may be o.k. if we have only a few of those, this may become a serious user issue if we have a large vocabulary for those. I am not sure what exactly the best way would be to go ahead, just raising a red flag...

[llemeurfr]

Note that cover` is represented as "rel": "https://www.w3.org/ns/wp#cover" ("cover" is not part of the IANA values set in https://www.iana.org/assignments/link-relations/link-relations.xhtml).

[laudrain]

Having wpub sepcific vocabulary will lead to updates of the spec as we will have new terms to add. There may be a way to call for additions to IANA registry. Asking them to add "cover" would be a good test.

[llemeurfr]

@laudrain to be precise, new terms will require an update of the Web Publication Manifest Ontology document, where "cover" should be defined (it is not yet).

[iherman]

@laudrain: not absolutely sure we would need an update to the spec. The WG, or whoever takes its place later, can update the ontology (as @llemeurfr says) and the WP spec itself would simply refer to the ontology. If we have some other registry-type approach (like the IANA registry) then a similar mechanism may apply.

(E.g., the rel attribute is defined in the HTML spec, and 'just' refers to the registry for possible values.)

[iherman]

@llemeurfr

"cover" should be defined (it is not yet).

You missed it:-), see the penultimate definition in, say, https://www.w3.org/ns/wp.ttl

[geoffjukes]

@llemeurfr To answer you question of me - no, that list is just the tip of the iceberg, which is kind of my point.

Publishers the extra resources whatever they want. We call them "Bonus Material". Others call it "Supplemental Material".

For Blackstone, audiobooks with "extra resources" (and they are in the minority) rely on a 'label' datapoint to drive what is displayed to the user, and the file is referenced by filepath.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Postpone discussion of Audiobooks #7 (Rel values) until we receive more feedback
  View the transcript

  Create a Vocabulary of rel attributes for extra resources
  Wendy Reid: this might be confusing for a while, but we’ll manage. First issue: final issue before next draft of audio spec: vocabulary of rel attributes for extra resources
  Ivan Herman: See Audio issue #7
  Wendy Reid: we’re already using a rel attribute for the cover, but do we need them for supplemental content?
  … based on our discussion, do we want to create a list of rel values, eg ‘booklet’ or do we want to use the IANA link relations value set?
  … this list is fairly complete, has a few publication-specific things, eg ‘appendix’, ‘author’, ‘chapter’
  … this could potentially cover most of our use cases. Thoughts?
  Simon Collinson: silence
  Wendy Reid: I expected this topic to be contentious
  Ivan Herman: I don’t recall the process of adding something to the IANA list, but the cleanest way, if we’re only missing one or two, is to try and get them into that list.
  Wendy Reid: Good point.
  Dave Cramer: I want to express caution about these kinds of vocabularies… our experience in EPUB is that these have been a pain - hard to maintain, and I’d hope that we only add terms when there’s a behavioral necessity
  Romain Deltour: +1
  Dave Cramer: people like labelling these things from a metadata perspective, but is a reading system going to do something different based on this rel value if it’s a booklet vs appendix vs colophon vs etc. etc.
  … I hope that the need comes up for the vocabulary, rather than defining one first and hoping that it’s used
  Wendy Reid: I lean on the side of Dave, because we’re in the early days of this sort of content… it might not even get used.
  … or if we open it up, it might get used too specifically
  Ivan Herman: It’s probably fine to postpone this issue - don’t close and forget, leave it open for now, but follow what Dave says
  … we should see if there’s a need for it, then go down the IANA path
  … if we record that in the issue then postpone resolution, that’s fine.
  Wendy Reid: Any opposition to postponing?
  Laurent Le Meur: ok for postponing
  Luc Audrain: +1 to postpone
  Proposed resolution: Postpone discussion of Audiobooks #7 (Rel values) until we receive more feedback (Wendy Reid)
  Romain Deltour: +1
  Ivan Herman: +1
  Garth Conboy: +1
  Nick Ruffilo: +1
  Tim Cole: +1
  Bill Kasdorf: +1
  Laurent Le Meur: +1
  Dave Cramer: +1
  Simon Collinson: +1
  Joshua Pyle: +1
  Ben Schroeter: +1
  Rachel Comerford: +1
  Resolution #2: Postpone discussion of Audiobooks #7 (Rel values) until we receive more feedback
  

[webysther]

This is important if audiobooks is used as a single file.