Duration of an audiobook

[HadrienGardeur]

For an audiobook, we need to ideally express:

• the total duration of the publication
• the duration of individual audio resources

Schema.org uses https://schema.org/duration for this purpose but there are a few points worth listing:

• ISO 8601 for a duration is not always the friendliest format
• media fragments (used in a TOC for example) are based on seconds instead
• it would require the use of "@type": "Audiobook" as well, since duration is not defined on CreativeWork or Book
• it's also undefined right now on 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 https://github.com/w3c/wpub/issues/229#issuecomment-413520551 applies as well.

[danielweck]

Thanks for pointing this out.

Indeed, I am discovering the "duration" ISO_8601 syntax: https://en.wikipedia.org/wiki/ISO_8601#Durations

I am more familiar with Media Fragments: https://www.w3.org/TR/media-frags/#naming-time

...and of course SMIL (well, the EPUB3 Media Overlays simplified model): http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#app-clock-examples https://www.w3.org/TR/SMIL3/smil-timing.html#Timing-ClockValueSyntax

[llemeurfr]

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. 45min, or 30s). Easy to write, to read and to parse. I understand this is a fork from schema.org. Nb: using the ISO 8601 syntax we would have values like PT45M or PT30S.

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.

[iherman]

Is ISO 8601 very different from the xsd datatype for duration? The advantage of xsd is that it is integral part of the environment...

[llemeurfr]

@iherman no it's the same. Did you see xsd:duration used in well know XML schemas?

[iherman]

I have not really, but simply because I never really looked for it, ie, my opinion is not really relevant...:-(

[iherman]

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.)

[HadrienGardeur]

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.

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.

[llemeurfr]

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.

[llemeurfr]

I think these are two different things.

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.

[HadrienGardeur]

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?

• All audiobooks have tracks, very few have ToC right now, this is an easy way to build a timeline based on tracks
• This can also help with caching (the UA would for example cache an hour worth of additional audio)

That second point is something that we really need to explore by the way. Without indications such as:

• duration (audio/video)
• size (images, audio and video)
• resolution (images and audio)
• bitrate (audio and video)

... 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:

• the available storage of a given device
• the storage available specifically to the UA
• various limits that are set for specific APIs (that's the case for the Cache API used by Service Workers for instance)

[HadrienGardeur]

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.

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:

• as you can see, fragments are expressed using #t=
• but it's also possible to provide a range (called a time interval in the spec) using media fragments such as #t=10,20

[llemeurfr]

About media characteristics

without ... 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.

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.

resolution (images and audio) The common meaning of resolution is "the recommended printing resolution for an image in dots per inch" -> raster images only, e.g 72 dpi.

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:

• do we want to impose a time interval here?
• or do we say that the UA may or may not be able to show the duration of a section, depending the way the author understands some note in the best practices document?
• or do we accept to consider microdata as an OWP technology?

[HadrienGardeur]

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.

This is different from what I've pointed out in https://github.com/w3c/wpub/issues/307#issuecomment-413821054.

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).

With a simple time, the UA cannot easily infer the duration of the section. With a time interval it is possible with some processing.

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.

do we want to impose a time interval here?

IMO that's not necessary.

[danielweck]

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.

[HadrienGardeur]

Going back to the initial issue, these are the two questions that we want to address in our next call:

• do we need to express the duration of the whole publication?
• do we need to express the duration of individual resources?

Once we've answered both questions, we can decide how (keeping in mind that https://schema.org/duration is the most likely candidate).

[ghost]

As RS we probably need to express duration of the whole publication in for example book shelf and individual resources in "toc".

[HadrienGardeur]

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 readingOrder? Why?

[ghost]

It is because we put chapter duration in toc level of RS affordance (of course data of duration could be eventually existed in readingOrder) and at this moment my understanding is we have not decided if RS should treat readingOrder as toc of whole book.

[HadrienGardeur]

They're two completely different things. To illustrate with the Flatland example:

• this is the reading order
• this is the TOC

[ghost]

Ok, I was confused by the readingOrder include some information ("name": "Part 1, Sections 1 - 3") seems needed for toc. Thanks for clarification. Then we need this in toc rather than readingOrder since it would be better for UI to display duration in Table Of Content (duration for each item in toc) because item in toc could be sub items of readingOrder. I don't think it's practical to calculate duration of each toc item from readingOrder.

[HadrienGardeur]

Hmm I disagree.

All audiobooks produced today have the equivalent of a readingOrder and it would be very easy to provide the duration of such tracks.

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 readingOrder and recommending media fragments in the TOC:

• we can calculate a timeline tied to the TOC when both are present (that's easy to calculate)
• and we can always fallback a list of tracks for every other case

[ghost]

and it would be very easy to provide the duration of such tracks.

I think this is base on presumption that TOC is machine readable but we are not sure about it yet in wide WP scope.

All audiobooks produced today have the equivalent of a readingOrder

What if some audiobook could be voice controlled by google home in near future?

I also don't think that a TOC will ever be a requirement in WP.

Neither me. I can not say duration is requirement as well. I would rather that spec can provide a (standard) way to express duration than make it as a requirement just like toc. Base on this, maybe as you said readingOrder is an alternative way (and better way eventually?) but think about it straightforwardly RS would need duration to be displayed corresponding with toc item. Is there any reason we need to put it into readingOrder and calculate it to toc rather than just put it in toc?

Maybe we can extend this a bit by

1. do we need to express the duration of the whole publication?
2. do we need to express the duration of individual resources?
3. do we need to express the duration of individual toc item?

I agree with 1, thinking it would be nice if we have 3 but I wonder what 2 can provide rather than toc.

[wareid]

Summary from the taskforce meeting (for the benefit for the rest of the group): There are two options to express duration (and many places where duration can be expressed), one is to use the schema.org schema:duration (Duration - schema.org) which requires including the “@type” of Audiobook and the time format from ISO 8601. The other option is to include duration in the resources, which would require an extension of the publicationLink we are already using. The importance of how we provide information comes up in a few ways for UserAgents:

• Total duration of the audiobook
• Duration of chapters within the TOC
• Duration of files We’d like to discuss how best to express this in the WP in general (this also would likely apply to video in some ways as well).

[iherman]

Thanks @wareid for the summary. Just few very general remarks.

• We already explicitly mention the schema.org Audiobook type in the spec, as the recipient for the readBy term. Ie, using schema.org's duration does on introduce anything new in this respect. Extending publicationLink in this respect is of course under our control, ie, no problem either. I do understand that the ISO formalism is ugly (it is:-), but I would still prefer to stick to schema.org whenever we can.
• My absolutely and completely layperson's comment is whether the structures we are discussing here are valid for audiobooks only. I could imagine, for example, a 'publication' consisting of a series of videos (something like a playlist) which would share many of the issues that are discussed here. I know that generalizing is always dangerous, because one can become lost in further details, but I nevertheless wonder whether there is a more general term that does exist that we may use, although audiobooks would be the most important embodiment of that category...

[HadrienGardeur]

My absolutely and completely layperson's comment is whether the structures we are discussing here are valid for audiobooks only. I could imagine, for example, a 'publication' consisting of a series of videos [...]

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.

[iherman]

@HadrienGardeur

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.

Thanks for the confirmation. Two (not necessarily high priority) comments.

1. Is there an accepted term in the community for a publication including, e.g., videos (I note that we may touch some of the animated manga/BD type publications with this)? audiobook is probably the most important category and type for now in practice, but we may want to be prepared for having another publication type for the more general category. This may be an issue to take up with @danbri at TPAC: extensions of schema.org to include other forms of publications.
2. While extending the PublicationLink is the obvious way (and I am fine with it) to add these additional attributes, we may want to look at the clean semantics. Indeed, whilst PublicationLink started as some sort of a copy of a <link> element by adding media type and the like, adding, e.g., duration means that we are characterizing the targeted resource itself, and not the link (knowing very well that the borderline between these two are fuzzy). This may lead to two possible changes:
   1. Rename PublicationLink to something like a PublicationResource (I know, this is only a change of name, but those are important).
   2. If we say PublicationResource we might want to consider the term id instead of url (or have both), because we want to have the subject clearly stated for the statements we are adding. (Yeah, my Semantic Web past is resurfacing:-(

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).

Cc @TzviyaSiegman @GarthConboy @wareid

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  1.1. duration, ISO format
  Ivan 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
  

[llemeurfr]

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 more reading samples in e.g. https://developer.mozilla.org/fr/docs/Web/HTML/Element/time. This means that "2 hours 15 mn" can be encoded either as PT2H15M or 2h 15m.

Embracing the web would mean adopting this w3c syntax for durations, not the ISO syntax strictly speaking. This also means the schema.org is more restrictive than the w3c on the syntax of a duration.

[iherman]

@llemeurfr I have added this to https://github.com/w3c/wpub/wiki/Schema.org-issues. Hopefully we can discuss these at TPAC.

@wareid @TzviyaSiegman @GarthConboy

[HadrienGardeur]

Also FYI, in Readium we've decided to convert everything to seconds instead since that's what we're already using for:

• table of contents
• bookmarks
• current position in the audiobook

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.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  6.5. audio duration
  Ralph 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: https://github.com/schemaorg/schemaorg/issues/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
  

[danielweck]

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 So we need to figure-out how to align here.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: 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
  View the transcript

  Duration of an audiobook #307
  Juan 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
  

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Move the duration property to web publications
  View the transcript

  duration in the context of WPUB
  Wendy Reid: https://github.com/w3c/wpub/issues/307
  Wendy Reid: https://github.com/w3c/wpub/issues/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”