Description for Link Objects

[JackieFei]

Can we set the description (not title) for each audio track?

Currently we can set the description for audiobook in metadata element, but not for track.

[HadrienGardeur]

@JackieFei could you describe the use case for that?

It's worth pointing out that the current WP draft has a description in its links as well: https://w3c.github.io/wpub/#publication-link-def For the sake of fully supporting WP, we might need it in RWPM anyway.

[JackieFei]

Our use case is :

The audiobooks are for educational usage.

The publisher have a request : add a brief descriptions for each track (chapter and section).

These descriptions intend to be displayed at somewhere of the Reader Apps when each track is playing.

(Maybe popup after clicking the info button.)

We don’t know how to fullfil it with audiobook spec yet.

[llemeurfr]

Just a question: is the brief description you need about 1/ tracks or 2/ chapters/sections of the book?

As a matter of fact, tracks are not always associated with proper chapters/sections. For instance, if a chapter is veeery long, an audio provider may cut it in several pieces for technical reasons. On reverse, if a book is made of many tiny sections, an audio provider may group several sections in one audio track, to avoid having 100 audio pieces. Or a distributor (Apple does it fro what I know) may create a unique audio track from N original tracks for distribution.

Therefore, even if tracks and sections/chapters are often synchronized, this is not a generic law. In fact tracks are not semantically relevant. This is why my question is important.

[JackieFei]

Currently in our use case, the brief description is for each track.

And we believe the brief description for chapters/sections will come sooner or later.

(APPLE Audiobooks Specification Version 5.3 says: 1 hrs < each track < 23 hrs. This maybe force the publisher to make a longer track.)

We agree the W3C description is not a generic law.

Maybe the description should be optional in both readingOrder and toc for different use cases.

[llemeurfr]

Maybe the description should be optional in both readingOrder and toc for different use cases.

Your own use case seems to be that you want to describe chapters, and as it happens chapters sections correspond to track.

"maybe" and "different use cases" seems a bit generic. What can be the real use of describing a physical track which does not correspond to a chapter (think about the case where a chapter is made of two consecutive tracks)?

[JackieFei]

Suppose 3 use cases:

Case 1: 1 track = 1 chapter/section

  "readingOrder": [
    {
      "href": "1_0.mp3", 
      "description": "chapter 1"
    },
    {
      "href": "1_1.mp3", 
      "description": "section 1"
    },
    {
      "href": "1_2.mp3", 
      "description": "section 2"
    }
  ]

description in readingOrder is for each track.

Case 2: 1_all.mp3 = 1_0.mp3 + 1_1.mp3 + 1_2.mp3 each track is 100 seconds, so 1_all.mp3 is 300 seconds. 2_all.mp3 is just another track.

  "readingOrder": [
    {
      "href": "1_all.mp3"
    },
    {
      "href": "2_all.mp3"
    }
  ],
  "toc": [
    {
      "href": "1_all.mp3",
      "description": "chapter 1"
    },
    {
      "href": "1_all.mp3#t=100",
      "description": "section 1"
    },
    {
      "href": "1_all.mp3#t=200",
      "description": "section 2"
    }
  ]

description in toc is for chapter/section (partial of one track). In this case, description in readingOrder is less helpful than in toc.

Case 3: We are not expecting a chapter is made of two consecutive tracks. But if it happened, may we can set :

  "readingOrder": [
    {
      "href": "a.mp3"
    },
    {
      "href": "b.mp3"
    }
  ],
  "toc": [
    {
      "href": "a.mp3",
      "description": "chapter 1"
    },
    {
      "href": "b.mp3",
      "description": "chapter 1"
    },
    {
      "href": "b.mp3#t=150",
      "description": "chapter 2"
    }
  ]

[laudrain]

I see in real world audiobooks the 3 use case. I think also that a TOC is necessary for accessibility reasons. Then I would say that description should always be in TOC as in case 2 and 3 above

[HadrienGardeur]

Purely from a spec perspective, we don't really care about tracks and how the document is divided.

We would simply add description in the Link Object and authors would be free to use it in both readingOrder or toc.

[llemeurfr]

I think that the best behavior for an auiopub player will be to take the following approach:

• if the audiopub has a ToC, use it for navigation and display the labels attached to ToC entries
• if the audiopub has no ToC, use the reading order (i.e. tracks) for navigation. In such a case it could use the labels attached to ToC entries.

Even if the spec of the manifest does not constrain the behavior of user agents, a Best Practices document should clearly state this.

Therefore yes, it is sufficient to add description to Link Object, used both in readingOrder and Toc.

[HadrienGardeur]

The spec already does what you're suggesting, more specifically:

• using toc is the preferred option
• linking to an HTML document is a fallback
• using title of the resources in readingOrder is another fallback

As far as I'm aware, we're not discussing the usage of description in the context of the ToC though, this is something different.

[HadrienGardeur]

Quick summary of what we discussed last time:

• W3C Publication Manifest has both name and description for each Link Object in readingOrder and resources
• RWPM only has title currently (equivalent of name)
• the use cases for using name vs description are not obvious within the W3C specification
• things would be a little better with RWPM as title can be used to extract a TOC from readingOrder as a fallback when toc is missing

@JackieFei looking back at your examples, I really don't understand why you can't use title for what you want to achieve. Do you really need two separate strings?