-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duration of an audiobook #307
Comments
Thanks for pointing this out. Indeed, I am discovering the "duration" ISO_8601 syntax: I am more familiar with Media Fragments: ...and of course SMIL (well, the EPUB3 Media Overlays simplified model): |
You're right @HadrienGardeur, the ISO 8601 syntax for a duration is un-intuitive (but easy when you look closely) and I didn't see it used in the read world (e.g. real life XML schemas). We must consider that this duration property is essentially used for display purposes (in the UA), therefore the second is a sufficient precision and an audiobook duration will never be much more than 24 hours. A duration is minutes or seconds would therefore be ok. I'm sligthly in favor of reusing the SMIL timecount syntax (e.g. Apart from the global duration of the audiobook (which will appear along with the description of the work), my feeling is that the duration of individual "chapters" should be expressed at the level of the ToC rather than the level of individual (physical) resources. |
Is ISO 8601 very different from the xsd datatype for duration? The advantage of xsd is that it is integral part of the environment... |
@iherman no it's the same. Did you see xsd:duration used in well know XML schemas? |
I have not really, but simply because I never really looked for it, ie, my opinion is not really relevant...:-( |
All that being said, I am a little bit wary of using something different than schema. That would mean that we would have to use a different property than https://schema.org/duration, ie, that type of data in our metadata will not be necessarily recognized... (But I do not have experience in this, ie, I do not have a strong opinion on this.) |
I think these are two different things. At a ToC level, we can point to a range using media fragments, but IMO that's mostly useful for a "timeline" feature or displaying the relevant title when listening to an audiobook. |
If we stay at a functional level, we should indicate at the Toc level a duration that the user can easily understand (after some processing for proper display), so that he can choose if he has enough time to listen to the chapter. It's an indication of "volume". I agree that such information should also be usable in a timeline. If the ToC is expressed in HTML as it is today, this can be inserted using microdata (again). Does a media fragment makes the trick in this case? I doubt. |
Maybe. What is the interest of a duration at the (physical) resource level? there is no benefit for the user IMO. There may be a benefit for the UA: which one? What is sure is that the duration of the whole audiobook (good for the user) and the duration of individual resources are not on the same plan. |
That second point is something that we really need to explore by the way. Without indications such as:
... it'll be very difficult for a UA when it should or shouldn't cache something for offline reading or download it in a package. The size of the cache will always be limited by:
|
That's not what I'm suggesting at all, I don't want to see microdata in the ToC (or anywhere frankly). Here's an example of an audiobook ToC:
|
About media characteristics
Apart from the size of the resource, why are the characteristics you are listing useful for caching? IMO media characteristics are only useful when one needs 1/ to check that the UA can read the content (this is the case for the audio codec value) 2/ to select one piece of content among several alternatives.
Let's discuss that in #308. About the duration of a section in an audiobook ToC With a simple time, the UA cannot easily infer the duration of the section. With a time interval it is possible with some processing. Question is:
|
This is different from what I've pointed out in #307 (comment). Even if you support the format, you might not want to attempt caching a 400Mb video when your overall available cache is 50Mb (I think that's the total cache available in Safari for example).
That's not entirely true. Take a look at the Flatland example and you'll see that it's very easy to extract a timeline from it.
IMO that's not necessary. |
I think promoting the use of time intervals instead of single time pointers for the "table of contents" links is a bad idea, because ranges clearly indicate when playback ends. TOC links conventionally reference discrete locations to navigate to, which provides a consistent user expectation whereby whenever such a link is activated, playback (i.e. the reading / listening experience) continues until the end of the audio book, unless otherwise interrupted. This applies to "continuous" media (as per the SMIL definition), which is not just "audio books", but also text-only publications that are narrated via synthetic speech (thereby providing a flowing aural rendition), as well as synchronized text + pre-recorded audio (EPUB3 Media Overlays). PS: by "table of contents" I really mean any navigational structure that references locations within the publication resources, such as hierarchical list of headings, flat list(s) of landmarks, page list, etc. |
Going back to the initial issue, these are the two questions that we want to address in our next call:
Once we've answered both questions, we can decide how (keeping in mind that https://schema.org/duration is the most likely candidate). |
As RS we probably need to express duration of the whole publication in for example book shelf and individual resources in "toc". |
In the TOC rather than in |
It is because we put chapter duration in |
They're two completely different things. To illustrate with the Flatland example: |
Ok, I was confused by the |
Hmm I disagree. All audiobooks produced today have the equivalent of a It's not clear how many audiobooks have the equivalent of a TOC right now. I also don't think that a TOC will ever be a requirement in WP. By requiring a duration in
|
I think this is base on presumption that TOC is machine readable but we are not sure about it yet in wide WP scope.
What if some audiobook could be voice controlled by google home in near future?
Neither me. Maybe we can extend this a bit by
I agree with 1, thinking it would be nice if we have 3 but I wonder what 2 can provide rather than toc. |
Summary from the taskforce meeting (for the benefit for the rest of the group): |
Thanks @wareid for the summary. Just few very general remarks.
|
That's entirely correct and ideally we want to address this by potentially introducing the ability to specify the bitrate (audio & video) and the height/width (video and images) as well. Since these terms are already available at schema.org (https://schema.org/bitrate, https://schema.org/height and https://schema.org/width), this would simply require extending the publication link model with them as well. |
Thanks for the confirmation. Two (not necessarily high priority) comments.
Again, these are not central issues for now, just jotting them down for a possible later discussion. And if there is consensus that this is worthwhile discussing, I am happy spawn these into a separate issue(s). |
This issue was discussed in a meeting.
View the transcript1.1. duration, ISO formatIvan Herman: link: Issue 307 Wendy Reid: one of the challenges is the relationship between track length and chapter length … so how do we express duration in an audiobook? … schema has audio duration, using an iso format (ISO 8601) … this could also affect video content … our alternative would be to extend publicationLink … we also discussed bitrate and format, which would be expressed similarly … this also drifts closer to best practices … do we want to recommend bit rates and formats, or do we want to leave it to the market? Ivan Herman: I don’t fully understand the options … there is the matter of the duration property, and what it’s value can be … I’m not fond of the ISO format … but I still use them … I would be hesitant to invent our own format to replace the ISO one … we shouldn’t do that … we should just deal with the ISO format … this is also the format recommended by schema.org … so we should follow what they do … we can raise the issue with schema.org at TPAC, and danbri will be at one of our sessions … that is also true if we take the duration as a property for publicationLinks … even if we have defined the object, we still need to be aligned with schema.org … so no matter where we use duration, we should keep to what’s defined in ISO Benjamin Young: https://www.w3.org/TR/html51/textlevel-semantics.html#the-time-element Benjamin Young: html5’s time tag and datetime attribute all use ISO 8601, so it’s the prevailing winner … even if you find it ugly Ivan Herman: we do Wendy Reid: no one is arguing, but we needed to bring it up to the larger group … schema has a value for audiobooks, but it might be harder to extend to video Ivan Herman: that’s a different question |
A note about the transcript of @BigBlueHat comment: the HTML time element supports either a date (using the W3C datetime format, which is a subset of the ISO 8601 format) or a duration. If it represents a duration, it can be formatted either using the ISO 8601 duration format or using a W3C custom format ("more readable" says the spec). See https://www.w3.org/TR/2014/REC-html5-20141028/infrastructure.html#valid-duration-string Embracing the web would mean adopting this w3c syntax for durations, not the ISO syntax strictly speaking. |
@llemeurfr I have added this to https://github.com/w3c/wpub/wiki/Schema.org-issues. Hopefully we can discuss these at TPAC. |
Also FYI, in Readium we've decided to convert everything to seconds instead since that's what we're already using for:
It feels easier to always work with seconds rather than juggle constantly between ISO 8601 for the primary reading order/metadata and seconds for everything else. |
This issue was discussed in a meeting.
View the transcript6.5. audio durationRalph Swick: -> https://github.com/w3c/wpub/wiki/Schema.org-issues#duration-values [audio] duration alues Wendy Reid: duration in schema refers more to a CV - as in I was in a job from jan 2017 to feb 2018 … the html equivalent is more relevant than schema.org Dan Brickley: see lower section of https://schema.org/Duration for properties whose value is datatyped schema.org/Duration, which does lean towards 8601 Ivan Herman: we should allow for the iso standard to be used Ralph Swick: -> https://www.w3.org/TR/2018/WD-html53-20181018/infrastructure.html#durations [HTML 5.3] Durations Wendy Reid: we would like to extend the iso standard to be used Dan Brickley: whereas https://schema.org/temporalCoverage covers date ranges, and we had some issue about openended ranges Dan Brickley: schemaorg/schemaorg#2086 Dan Brickley: next step is to follow up https://pending.schema.org/duration and clarify whether it is a temporal quantity, versus a period (temporalCoverage); could be clarified 6.6. additional vocabularies Ivan Herman: general question - there is a large vocabulary for publications in schema.org, but new types of publications are unavoidable … what steps should we take to add new types Ralph Swick: -> https://github.com/w3c/wpub/wiki/Schema.org-issues#what-is-the-mechanism-this-community-should-follow-for-new-publication-types mechanisms for new publication types? Dan Brickley: we generally push to wikidata to do the work Ivan Herman: proceedings is a good example Dan Brickley: https://www.wikidata.org/wiki/Q1143604 Dan Brickley: you can use wikidata directly Ivan Herman: so in my json-ld, I would use Q1143604 instead of Proceedings? Dan Brickley: yes Ivan Herman: we could create an alias in the JSON-LD context file for the wikidata name Dan Brickley: that too Dan Brickley: workaround is “Proceedings” is a term in the surface syntax defined by a json-ld context, but maps to Q1234-style URLs |
Media Fragments URI ( https://www.w3.org/TR/media-frags/#naming-time ) normatively references RFC 2326 ( http://www.ietf.org/rfc/rfc2326.txt ), but note RFC 7826 https://tools.ietf.org/html/rfc7826 |
This issue was discussed in a meeting.
View the transcriptDuration of an audiobook #307Juan Corona: (chatter among the group) technical details Daniel Weck: Media Fragment URI uses NPT Normal Play Time https://www.w3.org/TR/media-frags/#naming-time Ivan Herman: let’s stick to what we have now, because we ran out of time for the draft Benjamin Young: latest Normal Play Time (NPT) RFC https://tools.ietf.org/html/rfc7826#section-4.4.2 Daniel Weck: … ISO 8601 not suitable, hoping duration from Schema.org will be ammended https://en.wikipedia.org/wiki/ISO_8601#Durations (affects totalTime too from Schema) Ivan Herman: introducing our own element now is not viable Wendy Reid: let’s close this issue George Kerscher: not sure if we need the duration for each chapter … there’s the use case but people just want to know the book duration … everything else could be calculated along, from the files Wendy Reid: but there’s a track, we do get them as individual files, sometimes. but we get them as tracks instead most of the time … it’s to get the best UX … I want to know I’m 5 mins into a 25 min chapter for ex. George Kerscher: so you get them as tracks.. you process them.. but what do you need? Wendy Reid: it’s more complicated than that though Juan Corona: it’s not 1:1 Brady Duga: my question is like george’s, wendy is this reflecting what’s current now? … duration in the metadata is one form for us, but it’s not accurate. It’s concerning to have it like this Wendy Reid: let’s talk about it, how does a pub look like when it’s packaged Daniel Weck: bigbluehat RFC 2326 is referenced normatively by Media Fragment URI, do you suggest we explicitly reference RFC 7826 instead? Wendy Reid: duration is on the chopping block I know, but we need it for the UX Brady Duga: ToC, chapters mapped to the range of the chapters/tracks… you need to know how to calculate it. Benjamin Young: DanielWeck: RFC 2326 states it’s obsoleted by RFC 7826, so I’d link to the newer one George Kerscher: audio file sequence, you have a pointer to the beginning or the offset. Brady Duga: if you have the info before hand you can calc it. but in the web you don’t know this info until you download it all Romain Deltour: its a metadata issue, not a playback issue Brady Duga: george you are right you can calc it, but it’s hard when you are streaming it Wendy Reid: we need to know where in the chapter you are, with knowing the duration and offsets mixed with aggregation of the chapters or not Lloyd Rasmussen: do we need to have an API and the player to coordinate this Brady Duga: would the publishers give us this detailed ToC information? Wendy Reid: the spec won’t eliminate this missing data, or bad data, but we can validate it and provide feedback Daniel Weck: there are different ways to organize the files, theres a case theres a chapter with a title, … or more sophisticated with a ToC, and files contain more than one chapter … have the information on the manifest, along with the link … any objections to this? Wendy Reid: close issue with duration, use npt, until we get a new direction Daniel Weck: media fragments has a different reference Benjamin Young: there is a new one Leonard Rosenthol: is it compatible with media fragments? Benjamin Young: depends on what you are using, if npt> link,, to reference the new rfc coordinate with that group. Wendy Reid: media fragments for now then Resolution #1: Close issue #307 (duration) after discussion with schema, we will use NPT (Media Fragments) until they confirm or inform us otherwise research needs to be done Benjamin Young: general question, not on the TF sorry. … it’s not essential for pkg, its for navigation … why is it in the manifest? … it looks like annotation Juan Corona: .. could it be on its own Benjamin Young: someone could share this info like an annotation … I feel like this content is not essential to the manifest, it could be tripped on Wendy Reid: this is in the proper context though, this is out leading solution for now Benjamin Young: there’s too much going on on many spaces … a track in HTML5 is something else … HTML wants a playlist system, it’s missing … this is a good use case, to converge with. Daniel Weck: this is the reading order … page-list, audio streams Wendy Reid: any objections to close this? Daniel Weck: who edited the draft? Ivan Herman: this is not for me, tbd in a PR |
This issue was discussed in a meeting.
View the transcriptduration in the context of WPUBWendy Reid: #307 Wendy Reid: #420 Wendy Reid: duration for entire content vs. duration at the resource level Ivan Herman: duration currently defined in audiobook draft - nothing in there for duration is audiobook specific … ability to add duration to a resource is generic - doesn’t have to be audio could be video or whatever else … does it make sense to have a duration for the book as a whole? for audio books, it is a requirement, but not for a general web publication. but this may not be restricted to audio books. Maybe there could be a video book. The concept is generic, but it may be a requirement for audiobooks and not for general web publications. Avneesh Singh: generic, but in audio profile should be compulsory. But what is duration of whole book? Does that include branches that are not included in the reading order? Wendy Reid: Never seen a case where resources are not part of the reading order, but it could be possible. So we should include them in the entire duration. Brady Duga: what is definition of accurate as far as duration? Want to make sure there is no requirement for the reading system. Ivan Herman: what happens today? Brady Duga: we determine the duration Benjamin Young: agree with duga Avneesh Singh: Duration is important metadata Marisa DeMeglio: we will need this for sync media too; might not be a precise, e.g. user turns off page number announcements Lloyd Rasmussen: agree that the reading system should manage those values Ivan Herman: book level duration is more like general advisory information, not necessarily used by user agent for processing. … if this is the case, then requiring it to be present sounds like a step too far. Should have/nice to have … we have the duration set for an audio or video file. Is it required to provide that info as part of the resource description, or will reading system also ignore that? Benjamin Young: https://schema.org/duration Benjamin Young: we use schema.org duration property … what is the point on insisting or not insisting… is it a requirement for reading systems? What is the use case we are trying to solve for? Wendy Reid: top level duration is useful for user experience, e.g. product detail page. most commonly used on reading system side to break down chapters for example. Brady Duga: we won’t use resource level durations but will pre-process all the audio to determine. But a web only reading system may not have this capability. Wendy Reid: maybe the metadata is not used, but it can be provided in case the reading system can make use of it Avneesh Singh: +1 to move to WP Wendy Reid: should we move this to WP since it is not necessarily specific to audiobooks? Proposed resolution: Move the duration property to web publications (Wendy Reid) Benjamin Young: issue 420 - are we moving the requirement? Ivan Herman: the term definition should be generic for WP, then we’ll discuss 420 Ivan Herman: +1 Garth Conboy: +1 Tim Cole: +1 Bill Kasdorf: +1 Laurent Le Meur: +1 George Kerscher: +1q+ Franco Alvarado: +1 Ben Schroeter: any opposition to the proposal to move to WP? Ben Schroeter: vote Ben Schroeter: +1 Brady Duga: +1 Avneesh Singh: +1 Resolution #2: Move the duration property to web publications George Kerscher: ivan mentioned attribute about total duration - when a publication is time based media, then the total time would be very useful and I would examine it before downloading an audiobook Joshua Pyle: +1 George Kerscher: like number of pages of a book Benjamin Young: duration only allowed on audio books and media, but at the top level for creative works we could use https://schema.org/timeRequired … “estimated time to consume” Ivan Herman: sounds like a great match Benjamin Young: schema.org/timeRequired = “Approximate or typical time it takes to work with or through this learning resource for the typical intended target audience, e.g. ‘P30M’, ‘P1H25M’.” Wendy Reid: interesting alternative. must think on it. Ivan Herman: maybe we could in the WP document we make an explicit reference to time required at the top level and see if we can live with that, and keep the precise resource durations separate Bill Kasdorf: +1 to distinguishing between timeRequired and duration Wendy Reid: I will add to 420 George Kerscher: “Approximate reading time” |
For an audiobook, we need to ideally express:
Schema.org uses https://schema.org/duration for this purpose but there are a few points worth listing:
"@type": "Audiobook"
as well, sinceduration
is not defined onCreativeWork
orBook
PublicationLink
or the equivalent in schema.org that's currently a draft (I can't remember the exact term)For the duration of individual resources listed in the reading order, the same issue raised in #229 (comment) applies as well.
The text was updated successfully, but these errors were encountered: