With the first working draft of the EDUPUB profile released, I figured it was worth looking at exactly what is EDUPUB.
I’m not going to give a marketing spin on the profile; it should at least somewhat speak for itself what an educational profile of EPUB is aiming to achieve. If not, go give the original IDPF announcement a skim.
Rather, I’m going to look at all the pieces that make up the profile, for those trying to practically wrap their heads around how it works.
What is a profile?
But before getting too deep, the profile question is one that’s been wildly misunderstood at times.
I remember when the AAP initiative was announced there was some wackiness written about how EPUB 3 had failed and a new profile of it was being defined. The problem with the theory was that the AAP was never out to define an authoring profile… and didn’t define one. Their goal was to establish the features most needed for trade publishing, to give reading system developers a guide to their particular priorities.
An actual profile, on the other hand, is a specialization of the EPUB 3 for a particular use: an agreed on set of markup guidelines and principles. Like the Web, the content you find inside an EPUB container can vary wildly from one publication to the next. At the same time, different branches of publishing sphere have common requirements. Having everyone invent the same markup patterns and metadata becomes an exercise in waste, as it only leads to custom validation needs and is unlikely to net you better support in reading systems than run-of-the-mill markup.
You could, of course, come up with a minimal profile of EPUB for novels, but to date no one has presented a compelling case or reason to. A profile is largely unnecessary, too, considering how few features of EPUB novels use. But when you look at magazines, journals, educational works and similar publishing forms that are complex but structured, there is much more of a common backbone they all follow. Profiles set out to establish these commonalities.
It doesn’t mean a profile will lead to all works looking the same. Far from it. Do magazines look anything alike despite shared structures? Do textbooks currently?
A profile is also a means of steering production in the right direction. Place accessibility at the core of EDUPUB, and compliance is no longer left to the discretion of the producer. Sure, you don’t have to create educational content compliant with the profile, but it gives schools, content aggregators and the like the ability to set a baseline for purchasing content. Don’t meet the requirements of the profile and we don’t want your content.
What is the EDUPUB profile?
Perhaps the easiest way to wrap your head around EDUPUB is to break it down into its constituent pieces, so here goes…
Structure and Semantics
Structure and semantics are, naturally enough, at the core of all things digital content, and EDUPUB is no different.
The main profile specification defines only a few structural requirements in section 4, however: the use of sections, headings for them, pagination markers and some image production suggestions.
The bulk of the work so far has been on the semantic side: analyzing what is available in the existing EPUB Structural Semantics Vocabulary (SSV) and looking at what additions are needed. Not everything in the SSV is included in EDUPUB, but there’s also no restriction that you can’t use the terms just because they aren’t in the list in section 5. The list is more of a distillation of key terms for education, rather than just throwing a blanket statement to use everything.
One thing to note about section 5 is that the links on the semantics do not take you to the SSV. They instead point to a new EDUPUB semantics document that has been prepared specifically for EDUPUB, which defines additional requirements for their use and, in some cases, default contexts in which the semantics can be assumed.
This new semantics document does not replace the SSV, either; it only prescribes usage of the terms for EDUPUB-compliant content. It’s similar to how the Indexes specification defines the use of the
index-* terms, but they’re also formally listed in the SSV since it’s the default vocabulary for use with the
The review of semantic terms has also led to a much-needed rethink of some of the existing terms. Deprecated now is
note, for example, which has been an endless source of confusion with both
marginalia has also been deprecated, as it’s hard to differentiate from a bare
aside element. The
annotation semantic was dropped because the Open Annotation in EPUB specification makes it pointless, but more on annotations later.
In other words, even if you aren’t terribly interested in EDUPUB, you might want to have a look at the SSV to see what has changed.
EDUPUB is the first specification to take advantage of the ability to use schema.org metadata in the EPUB package document.
The prefix “
schema:” was reserved during the EPUB 3.0.1 revision to make it easier to begin integrating publication-level metadata using schema.org properties. Originally, the goal was to take advantage of the accessibility metadata properties, but there’s also a companion set of educational metadata properties well-suited to EDUPUB. One vocabulary, two problems solved. Much nicer than having to integrate more and more vocabularies, one for each purpose.
The requirements to use the accessibility and education metadata aren’t too onerous, either.
For accessibility, you have to at least include one
accessibilityFeature property, but you can specify the value “
none” if you can’t find anything nice to say about it.
None of the educational metadata is currently required, but the specification contains various recommendations depending on who you’re targeting.
Have a read through section 9 for more detailed information.
(If you’re wondering how you express schema.org metadata in the package document without RDFa or microdata attributes, give the integration guide a quick run through.)
The rest of the EDUPUB profile consists of implementing general-purpose EPUB technologies, albeit that some of these technologies are being developed specially for EDUPUB.
The first such technology is widgets, also known as reusable scripted components. These are being defined in the EPUB Widget Packaging and Integration specification, with an API to come later (which might lead to a second specification, or a more general name for the existing one).
I doubt I need to explain why reusable scripted components are integral to educational publishing. There are various graphs and charts that appear over and over in books that could be made dynamic, just as a mundane starting point.
The specification also presents an interesting opportunity to create saleable widgets, for those slaves to the almighty dollar.
Distributable objects are another concept born out of the EDUPUB work but that are being developed more broadly for any EPUB publication.
A distributable object is sort of like the content equivalent of a widget: a component of a publication that can be reused in another context. It could be an entire chapter, or it could be something as small as a learning object or concept.
Two common scenarios for their use are for selling pieces of a publication and building new textbooks (open textbooks). For example, if a publisher defines each chapter of the book as a distributable object, instead of receiving 101 publications, each containing one chapter, an aggregator or vendor could parse apart the full publication and automatically generate the individual pieces.
For open textbooks, picture a scenario in which a program is able to parse the distributable objects within another publication and automatically pull the ones you want into the new book you’re building.
Distributable objects are defined using the new
collection element in the package document. For more information on how to create them and how they work, have a look at the EPUB Distributable Objects specification.
They aren’t really a content feature as far as the end user goes, but an intriguing bit of metadata for the production side.
The Open Annotation in EPUB specification has been under development since last fall, although initially unrelated to the EDUPUB work.
It’s an attempt to bring standardization to the form and exchange of annotations in EPUB, which to date has been a bit of a wild west.
The benefits of being able to move your annotations between any version of a book you own should be clear enough, but having a standard will also allow the sale of annotations that can work across vendor editions (cheat sheets and the like).
Annotations are also a convenient way to craft a teacher’s edition of a work, but that topic will be handled in more depth in iteration two of EDUPUB.
I won’t ramble on too much about annotations in this post, as I’ll return to them in more detail in an upcoming one.
Assessments I’ve left to the end not because they’re less critical a feature (in fact they’re probably the most), but because there isn’t anything practical in EDUPUB yet.
Section 8 of the profile will handle integrating some external technologies, but with no concrete detail as yet, there’s not a lot more to say other than stay tuned.
And there’s your quick tour of EDUPUB, in as much of a nutshell as I could make it.
The profile is being defined iteratively, so what you’ll find in the specifications now may not be what you find at the end, and there are many incomplete details at this point. (I’ll try to post updates as things are materially changed.)
Otherwise, go forth and multiply your experimental EDUPUB content and see what issues you encounter. One goal of the iterative approach is to incorporate real-world feedback into the evolution.