Posted on by & filed under epub, epub3.

Update: I should have been clearer that the “bare” use of 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:

  1. 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, and language (probaby creator too).
  2. 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?).
  3. 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.

Cover of Dreams from My Father: A Story of Race and Inheritance

Here’s the markup, using Dreams from My Father: A Story of Race and Inheritance as the example:

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:

We also include the titles using the new markup for EPUB 3:

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:

Finally, we specify the display order of the two titles with meta elements and display-seq

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


15 Responses to “Subtitles in EPUB 3”

  1. Bruce

    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 Subtitle

    So which is broken here: the epub 3.0 implementation, or just the example?

  2. Bruce

    sorry, I missed the comment about escaping the markup in the code block.

  3. Keith Fahlgren

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

    …unfortunately, that list doesn’t include a “subtitle” type.

  4. Matt Garrish


    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 scheme property 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:

    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.

  5. Thomas Rasche

    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!

  6. bowerbird

    you’re making things worse, instead of better.

    you really need to go back to the drawing board.

  7. Matt Garrish

    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:

    But that’s just me shamelessly flogging my other pet project, too… ;)

  8. Matt Garrish

    you’re making things worse, instead of better.

    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:

    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.

  9. bowerbird

    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.

  10. Matt Garrish

    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:

    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.

    • Keith Fahlgren

      My hope was that we could simply recommend

      … but I have no idea if or when ONIX 3 will be referencable as a URI.

  11. Matt Garrish

    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.

  12. Mangal Kumar

    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.