Create a vocabulary of rel attributes for extra resources #7
Comments
|
|
|
|
|
IMO it's a little too specific to be widely useful. |
|
This issue was discussed in a meeting.
View the transcriptShould there be a TOC if supplemental materials are provided in an audio book?Wendy Reid: w3c/wpub#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 |
|
I'm in agreement with @HadrienGardeur here. |
@geoffjukes so do you think this list represents the most useful types of resources in web publications, for which we will define well-known |
|
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
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... |
|
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). |
|
Having wpub sepcific vocabulary will lead to updates of the spec as we will have new terms to add. |
|
@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). |
|
@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 |
You missed it:-), see the penultimate definition in, say, https://www.w3.org/ns/wp.ttl |
|
@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. |
|
This issue was discussed in a meeting.
View the transcriptCreate a Vocabulary of rel attributes for extra resourcesWendy 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 |
|
This is important if audiobooks is used as a single file. |
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?
The text was updated successfully, but these errors were encountered: