Open daryanypl opened 7 years ago
Using related
might be a better fit than parent
or child
. If it's not strong enough, we might consider other existing options.
If something is truly an appendix, it should probably show up in spine
/resources
or another specific collection rather than in links
.
After a slack conversation, here's the decision reached: For now, we will use related and let the app figure things out based on the media type. So, make the assumption that a parent epub, if exists, would not be in pdf format, and a child appendix, if exists, would be in pdf format. When we get a better idea of real world usage, we'll consider if we need an expansion.
Related (pun intended): a discussion of the relationship between this spec and DAISY's Navigable audio-only EPUB3 Guidelines ( http://www.daisy.org/ties/navigable-audio-only-epub3-guidelines ) might be helpful. As far as I understand DAISY's effort never took off.
Sometimes audiobooks come with pdf appendices, like when a book on economics includes charts and graphs. And sometimes it's possible to link an audiobook to an ebook, allowing the user to either read or listen, depending on whether they're in transit or in their living room. It might be good to add a "parent" and an "attachment" options to https://idpf.github.io/epub-vocabs/package/link/ .
We can use the already existing "alternate", so our manifest would look something like: { "metadata": {...} "links": [ {"rel": "alternate", "href": "https://hadriengardeur.github.io/webpub-manifest/examples/MobyDick/manifest.json", "type": "application/webpub+json"}, {"rel": "alternate", "href": "https://[...]/appendix.pdf", "type": "application/pdf"}, ]}
But what if the ebook's format is also pdf, how can the user's app know which is the parent ebook, and which is the appendix? Perhaps we should add something like: "links": [ {"rel": "parent", ... {"rel": "attachment", ...