Subtitles in EPUB 3
by Keith Fahlgren
subtitle without referencing a scheme is really suboptimal. Using already-defined properties/definitions and referencing them explicitly (like the ONIX codelist example below) is a much better technique, but I did not come up with a compelling property for subtitle, hence the call for better options. See the comments below for a good discussion of those options.
There’s also a Bulgarian translation.
In a previous post, Thomas Rasche asked:
How are book subtitles best dealt with in Epub3? They could be included with a meta data property, but is there a recommended way so that a reader recognizes them, to display them sensibly (eg subtitles display in smaller font under the main title etc)?
EPUB 3’s metadata model is powerful and flexible. It is a big improvement over the limited metadata permissible in EPUB, but there are three real costs associated with EPUB 3’s metadata:
- Because of backward compatibility with EPUB, metadata in EPUB 3 duplicates at least three required metadata elements in both an old and new style:
title,identifier, andlanguage(probabycreatortoo). - Greater flexibility in metadata schemas means that EPUB 3 metadata sometimes seems quite verbose (but you’re generating your OPF using software with robust metadata stores anyway, so this isn’t much of a complaint, right?).
- Different metadata schemas describe the same thing with different words, so there are often many ways to accomplish the same thing and we don’t yet know what the convention will be.
That last issue of choosing a schema is the central issue in our subtitle problem. The EPUB Publications 3.0 specification provides a number of examples on how to include specific metadata but doesn’t exactly prescribe how a subtitle should be included. Instead, we’ll include two titles in a row, declare one as the subtitle, and indicate a display order.
Here’s the markup, using Dreams from My Father: A Story of Race and Inheritance as the example:
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title id="title" prefer="dcterms-title">Dreams from My Father</dc:title> <meta property="dcterms:title" id="dcterms-title">Dreams from My Father</meta> <meta about="#dcterms-title" property="display-seq">1</meta> <dc:title id="subtitle" prefer="dcterms-subtitle">A Story of Race and Inheritance</dc:title> <meta property="dcterms:title" id="dcterms-subtitle">A Story of Race and Inheritance</meta> <meta about="#dcterms-subtitle" property="title-type">subtitle</meta> <meta about="#dcterms-subtitle" property="display-seq">2</meta> …
What’s going on here?
In this markup, we do a range of things. We state both the title and subtitle using the legacy EPUB markup for backward compatibility and we do it in order, which is important for EPUB, but we also tell EPUB 3 reading systems to use the new syntax with the prefer attribute:
<dc:title id="title"
prefer="dcterms-title">Dreams from My Father</dc:title>
…
<dc:title id="subtitle"
prefer="dcterms-subtitle">A Story of Race and Inheritance</dc:title>
We also include the titles using the new markup for EPUB 3:
<meta property="dcterms:title"
id="dcterms-title">Dreams from My Father</meta>
…
<meta property="dcterms:title"
id="dcterms-subtitle">A Story of Race and Inheritance</meta>
Next we specify that the subtitle, is, in fact, a title-type subtitle. We do this by adding another meta element that refers to the subtitle with the about attribute:
<meta about="#dcterms-subtitle"
property="title-type">subtitle</meta>
Finally, we specify the display order of the two titles with meta elements and display-seq
<meta about="#dcterms-title"
property="display-seq">1</meta>
…
<meta about="#dcterms-subtitle"
property="display-seq">2</meta>
Other options
EPUB 3 is new enough that we don’t know which practices will become adopted by content creators and reading systems (so we don’t know about a smaller font, like the original question). The subtitle markup suggested above is a decent approach, but other options might be using http://open.vocab.org/terms/subtitle (not widely used in publishing today) or ONIX’s <Subtitle> element (very hard to reference cleanly).
If you’ve got a better suggestion for the markup above please leave a comment and I’ll update the post if a winner emerges.
Colons don’t make subtitles
While it may seem tempting to split title and subtitle on a :, don’t, ever: slide:ology.
If there are specific EPUB 3 questions you have that you’d like to see us write about, please leave a note in the comments—Thanks!
Subtitles in EPUB 3 by Keith Fahlgren is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.
Comments
That’s an awfully ugly solution. The about and property attributes seem to suggest a smart resuse of an existing extensible metadata standard (RDFa), but the actual details appear to abuse that standard to such an extent that it arguably breaks.
For sake of comparison, why not simply:
The SubtitleSo which is broken here: the epub 3.0 implementation, or just the example?
sorry, I missed the comment about escaping the markup in the code block.
Bruce, we’re not able to recover your markup; can you try reposting?
Possibly-useful comparison point: title markup in TEI (Text Encoding Initiative, used in scholarly/historical publications).
@Liza: The TEI example is interesting and includes some of the title types enumerated in this ONIX codelist for title types. It’s that list that’s used as an example in the EPUB Publications 3.0 spec:
<meta about="#title" property="title-type" id="title-type">01</meta> <meta about="#title-type" property="scheme" datatype="xsd:anyURI">http://www.editeur.org/ONIX/book/codelists/current.html#codelist15</meta>…unfortunately, that list doesn’t include a “subtitle” type.
While you can input a string like “subtitle” as your value when all else fails (and it may have here, but more below), the idea behind the metadata model was that values should be tied to a formal enumeration—such as an ONIX Code List—using the
schemeproperty to ensure standardized use and that the values used can be resolved to a common meaning (or at least in a manner that a Reading System can make sense of).Or that’s the issue I read into the first post, as I think what is being asked is what prevents someone from using “the subtitle” instead of “subtitle” as the value, and the answer is absolutely nothing when it doesn’t come from a recognized source. A value like “subtitle” is also prone to the problems of regionalization, which is why the EPUB spec examples use the ONIX numeric values whenever possible.
But, the valid counter-argument is what do you do when no one provides a formal enumeration of values that contains what you need? Rolling your own may well be all you can do, and we didn’t want to prevent that. The scheme, for example, doesn’t have to reference an RDF vocabulary, but could just be a string identifier telling the world you created the value yourself:
<meta about="#dcterms-subtitle" property="title-type" id="title-type">subtitle</meta> <meta about="#title-type" property="scheme" datatype="string">threepress-proprietary</meta>From a metadata purist perspective, I know this will make some people cringe, but as noted in the article, we wanted to ensure maximum flexibility, as good predictability as we could, but not prescribe how everyone must add their metadata (there may be very different needs depending on what kind of EPUB is created). EPUB 3 isn’t 100% pure RDFa, and time will tell what conventions people settle on.
I’m sure authoring guidelines will be forthcoming, too, and it may well be that some values like “subtitle” are agreed on for (interim) use and can omit a scheme. We did have an issue to avoid creating our own enumeration of title types, though, and closed it by deferring to scheme, but it seems subtitles are an anomaly.
But to wrap this up by looking briefly at the bigger picture, if there are needed property values missing from all commonly-used vocabularies and lists, canvassing to get the missing terms included in the most appropriate of them would be the stabler/better route moving forward. Metadata needs to be meaningful to be useful, so rolling your own should always be the last resort.
Hello, thanks for the comments based on my original post!
I would like to ask another epub3 question… Is there any substitute for a book’s back cover?
Currently, every distribution system asks for the back cover text to be supplied separately from the ebook file. Also, previews are supplied separately (or at least dealt with differently with each distributor, whether a set percentage of the book to view or set amount of pages). This is crazy IMHO, as this information belongs to the book, not the distributor. The responsibility for this should remain in the book and shouldn’t be separate/separated.
A book’s cover is visible outside of the DRM (it can be seen without purchase). Similarly with meta data. The visible contents prior to purchase could be more…like the back cover text (but why stop there: images, marketing images, preview, url-links etc.).
If an ebook is forwarded to another distributor etc., it then need only be the ebook file, and would contain all sales/marketing information, including the back-cover text.
Thanks again!
you’re making things worse, instead of better.
you really need to go back to the drawing board.
For all my writing earlier, I forgot about the Z39.86-201x Structural Semantics Vocabulary (the work Markus stole me away from, and the x just means we don’t yet have NISO approval but should be sometime this fall if all goes well). We define terms for a wide range of title types there, including subtitles.
EPUB incorporates a distilled version of this vocab for content documents, but I’d never really thought about whether it would be a conflict of interest to cross-reference like this for use in the package (I’ll leave that open for debate). One or the other I think could suit the purpose:
<meta about="#dcterms-subtitle" property="title-type" id="title-type">subtitle</meta> <meta about="#title-type" property="scheme" datatype="uri">http://www.daisy.org/z3986/2011/vocab/structure/#</meta>But that’s just me shamelessly flogging my other pet project, too… ;)
I’m not quite sure I see how. EPUB2 metadata provides little means of detecting what it is, and there are few requirements on usage. EPUB 3, if you strip away the type/role/scheme properties, would be no worse than that.
Given an actual RDF property, you can skip this scheme mechanism altogether, too. I used the vocabulary in a somewhat hacked up way in my last post to show it being used in this title-type/scheme method (on the assumption a reading system might only process title elements, and also being a long day), but given that it is a real RDF property you could (better) do:
<meta property="z3986:subtitle" id="z3986-subtitle">A Story of Race and Inheritance</meta>If your complaint is that this opens the door to a wide variety of ways of expressing metadata, I won’t disagree with you. But this kind of flexibility was a requested feature. I expect the theory on what people could do with this freedom will be much greater than the actual application, though.
matt, i was talking to keith and liza, not you.
for something as simple as a book’s subtitle,
things should be simple, and cut-and-dried.
if the i.d.p.f. can’t make that simple, give up.
Fair enough, but since I’m already started, consider that compatibility with v. 2 readers was also a requirement so that EPUB3 books can render on them (at least to some degree). I don’t pretend to speak for IDPF, of course, but how to make all these competing metadata requirements work within a framework looking to transition to properties doesn’t necessarily make for a simple answer.
The title-type/scheme approach isn’t broken RDFa at all, but it relies on (unarguably) an association mechanism that may lead to the kinds of standardization problems it aims to solve. It’s hard to predict whether that will prove to be true in practice at this stage or not. The hope/expectation is that common practices and means of identifying the meaning of title/roles/etc. will evolve (where they don’t exist already, like we have established with ONIX) and it will become a rote exercise in tagging to identify a subtitle, for example, once they do.
And although the dc:title elements are still required, there’s no reason that you have to use an equivalent dcterms:title when you can find a better fit for a specific type of title (the overarching question always being what vocabulary/reader support will evolve). The following would be an example of one way of including a dc:title element for the subtitle, while looking ahead to actual property parsing:
<dc:title id="subtitle" prefer="z3986-subtitle">A Story of Race and Inheritance</dc:title> <meta about="#subtitle" property="title-type" id="title-type">subtitle</meta> <meta about="#title-type" property="scheme" datatype="uri">http://www.daisy.org/z3986/2011/vocab/structure/#</meta> <meta property="z3986:subtitle" id="z3986-subtitle">A Story of Race and Inheritance</meta>The above would allow an EPUB2 reader to do whatever it might do with a second dc:title element. An EPUB3 reader that only handles title elements could likewise parse the title-type/scheme to see if it understands what to do with this title. And a more progressive EPUB3 reader might be able to make sense of the RDF property and skip the element parsing and association mechanisms entirely.
It’s too early to suggest that the above is ideal and should be used by anyone, but hopefully it shows why the complexity exists and how things look to evolve. A future version of EPUB would hopefully see only the trailing property used, which would bring the consistency/simplicity I expect you’re looking for.
It will be interesting to see which vocabularies get favoured for which types of EPUBs, as that, again, will be a key to determining how to implement metadata moving forward.
And I think these kinds of explorations of issues are extremely helpful to sorting out best practices, so my regards to Liza and Keith for getting the ball rolling on what is a bit of uncharted territory here.
My hope was that we could simply recommend
<meta property="onix3:Subtitle" id="onix3-subtitle">A Story of Race and Inheritance</meta>… but I have no idea if or when ONIX 3 will be referencable as a URI.
Right, without a mapping for the prefix the property would be invalid; that’s the flexibility the title-type/scheme option provides in not having to resolve to a term in an RDF vocabulary.
I don’t know if the ONIX folks have plans to make a vocabulary of their element set or not, either, but it’s certainly an interesting idea.
Is there any way to include thumbnail image in epub 3? Please suggest us, if you know how to include the thumb image in epub.
Thanks,