Draft Specification 23 July 2015
NOTE The EPUB Working Group is developing this profile through a series of iterative releases. This document represents the product of the sixth iteration of this development cycle. |
This version:
http://www.idpf.org/epub/profiles/edu/spec/edupub-20150723.html
Latest version:
http://www.idpf.org/epub/profiles/edu/spec/
Previous version:
http://www.idpf.org/epub/profiles/edu/spec/edupub-20150706.html
Copyright © 2014-2015 International Digital Publishing Forum™
All rights reserved. This work is protected under Title 17 of the United States Code. Reproduction and dissemination of this work with changes is prohibited except with the written permission of the International Digital Publishing Forum (IDPF).
EPUB® is a registered trademark of the International Digital Publishing Forum.
Editors
David Stroup, Pearson
Markus Gylling, International Digital Publishing Forum (IDPF)
Matt Garrish, Invited Expert
Yonah Levenson Hirschman, Pearson
Tzviya Siegman, Wiley
Status of this Document
This document is a Draft Specification, produced by the IDPF EPUB 3 Working Group, based on an initial member submission by Pearson in December, 2013.
Unlike traditional IDPF specifications, the development of this profile is anticipated to follow an agile model, with core features and functionality defined in the initial release and less critical features ‒ or features that require more time to properly detail and implement properly ‒ following later.
Functionality and features in the profile will continue to be evaluated over the duration of the development cycle and could be modified or deprecated based on real-world usage.
This document may be updated, replaced, or rendered obsolete by other documents at any time. Its contents do not necessarily reflect the consensus of the Working Group.
Open issues in this draft
See the latest working group teleconference minutes for a list of open issues.
This section will be removed when this document leaves draft status.
Table of Contents
2.2 Reading System Conformance
3.3 Multiple-Rendition Publications
3.4 Teacher's Editions and Guides
6. Assessments, Outcomes and Analytics
6.1 Integration with IMS Caliper, QTI, and LTI
6.2 IMS Learning Tools Interoperability (LTI) and Outcomes
6.2.2 Reading System Conformance
8.2.3 audience/educationalRole
10. Distributable Educational Objects
10.2.1 Distributable Object Type
Appendix D. Educational Metadata Properties
Appendix E. Educational Metadata Mappings
Appendix E. Acknowledgements and Contributors
This section is informative
Digital content in education has the potential to significantly improve learning outcomes, as it can better support accessibility, adapt to individual learning modes, increase engagement and experiential learning through interactivity, provide immediate assessments and analytics, and increase social connectivity.
To this end, the EDUPUB profile defined in this specification represents the effort to adapt the functionality of the EPUB® 3 format to the unique structural, semantic and behavioral requirements of educational publishing.
The profile builds on the EPUB 3 specification in the following ways:
Refer to the EPUB Specifications for definitions of EPUB-specific terminology used in this document.
The following typographic conventions are used in this specification:
markup
All markup (elements, attributes, properties), code (JavaScript, pseudo-code), machine processable values (string, characters, media types) and file names are in red-orange monospace font.
markup
Links to markup and code definitions are underlined and in red-orange monospace font. Only the first instance in each section is linked.
http://www.idpf.org/
URIs are in navy blue monospace font.
hyperlink
Hyperlinks are underlined and in blue.
[reference]
Normative and informative references are enclosed in square brackets.
Term
Terms defined in the Terminology are in capital case.
Informative markup examples are in monospace font.
NOTE
Informative notes are preceded by a "Note" header.
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
All sections of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they may contain.
All examples in this specification are informative.
As a profile of EPUB 3, these guidelines build on the functionality defined in the following core specifications:
Unless explicitly overridden, this profile inherits all requirements defined in these specifications.
EDUPUB-compliant Publications are always valid EPUB 3 Publications, but, due to the additional production requirements detailed in this document, the reverse is not necessarily true.
In addition to meeting the requirements specified in EPUB Publications [Publications301], an EPUB Publication conformant with this profile must meet all of the following criteria:
In addition to meeting the requirements specified in EPUB Publications [Publications301], an EPUB Reading System conformant with this profile must meet all of the following criteria:
NOTE
It is anticipated that support for multiple renditions and annotations will be elevated to a requirement once those specifications become Recommendations.
The primary focus of this version of the EDUPUB profile is on the creation of reflowable XHTML-based EPUB Publications.
Reflowable Renditions of the content are typically more accessible than pre-paginated (fixed layout) Renditions, making the content more widely accessible to a broader range of students.
The semantics defined in this profile are also better suited to annotating markup structures that have not been artificially broken by page boundaries, and the requisite chunking of content into separate files that practice causes. Navigation is similarly simplified for users of assistive technologies when content structures are not broken apart by pagination.
The use of reflowable Renditions is therefore strongly recommended.
Although the creation of reflowable EPUB Publications is the preferred content model for EDUPUB, Authors MAY create Fixed-Layout Publications provided they are produced to be accessible to a wide audience.
This specification does not attempt to define accessibility for all users, but conformant Fixed-Layout Publications MUST meet all of the following criteria:
These requirements represent the minimum threshold to be conformant with this profile. They do not replace any local or national accessibility requirements an Author has to meet in order to sell and distribute their content for educational use.
EDUPUB Publications may contain more than one Rendition of the content, but each Rendition must conform to the requirements for reflowable or fixed-layout content defined in this specification.
When an EPUB Container includes more than one Rendition, it must conform to the requirements for multiple-Rendition EPUB Publications defined in [MultipleRenditions]. In addition to the Release Identifier, the metadata.xml file must include the dc:type identifier "edupub".
NOTE
Authors are encouraged to include a Rendition Mapping Document to allow Users to switch from one Rendition to another without losing their place (e.g., to simplify moving between fixed-layout and reflowable Renditions, or from a structured audio to text Rendition).
Teacher's editions and guides are important tools in educational instruction. Both provide guidance to the teacher, but a teacher's edition represents a superset of the work the students are using, while a teacher's guide typically provides general instruction and guidance on the curriculum (i.e., there is no student edition).
This section does not introduce special processing requirements for either. In particular, it is assumed that teacher and student editions are packaged separately, as EPUB ‒ and the Open Web Platform generally ‒ does not provide a means of reliably hiding content from different classes of readers.
A teacher's edition must be identified as such in the package metadata by including a dc:type element [Publications301] with the value "teacher-edition".
The following example shows an EPUB Publication identified as a teacher's edition.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>teacher-edition</dc:type>
…
</metadata>
A teacher's guide must be identified with the value "teacher-guide".
The following example shows an EPUB Publication identified as a teacher's guide.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>teacher-guide</dc:type>
…
</metadata>
Teacher's guides and editions are also identified as compliant with the EDUPUB profile as defined in 8.1 Profile Identification, so must conform to all requirements in this specification.
The following example shows both the edpub and a teacher's guide identifiers.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>teacher-guide</dc:type>
<dc:type>edupub</dc:type>
…
</metadata>
As a teacher's edition represents an annotated version of a student edition, it should identify the corresponding student edition in a dc:source element:
The following example shows a teacher edition that includes the source student edition identifier.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>teacher-edition</dc:type>
<dc:source>urn:isbn:9780000000001</dc:source>
…
</metadata>
NOTE
As teacher's guides do not have student editions, this guideline does not apply to their production.
The EDUPUB content model does not include structural semantics specifically for the construction of teacher editions and guides, but the inclusion of such semantics is under consideration for a future version of the profile.
At this time, the use of semantics defined in 4.4 Structural Semantics is recommended, where applicable.
The standardization of CSS class names for controlling the appearance of teacher-specific content is under consideration for a future version of this profile.
As a teacher's edition contains both the text of the student edition together with annotations, answers and other instructional aids for the teacher, there is a need to accessibly differentiate the teacher content from the content that all students have access to. Reliance on visual CSS styling alone, for example, impacts on the overall usability by instructors.
While the use of structural semantics enhances the meaning of the content, it does not, in itself, indicate who the content was intended for. Instead, to address discoverability for users of assistive technologies, all teacher content must be labeled using the [ARIA] aria-label attribute.
The following example shows an answer section labeled as belonging to the teacher edition
<section epub:type="answers" aria-label="teacher edition content">
…
</section>
This specification does not require specific language for this attribute to allow for localization, but the text used should clearly identify the audience is teachers.
NOTE
As teacher's guides are exclusively for teachers, content does not have to labelled.
The audience may also be specified using the [schema.org] audience property for reliable machine processing (e.g., to selectively hide teacher-only content in a Reading System, or to enable filtering of content prior to distribution). Processing of this metadata is optional.
The following example shows the inclusion of the schema.org audience property to identify that an answers section is intended only for teachers.
<section id="answers01"
aria-label="teacher edition content"
epub:type="answers">
<meta resource="#answers01"
typeof="schema:WebPageElement"
property="schema:audience"
content="teacher"/>
…
</section>
For accessibility purposes, it is strongly recommended that student content not be represented as annotated images in teacher's editions.
This section is informative
This section outlines key content structuring guidelines for the production of EDUPUB-compliant EPUB Publications. Only differences from the core suite of EPUB specifications are noted.
The section element must be used only to group sections of content that contribute to the structural hierarchy (e.g., that could appear in the table of contents). Such content is contained in linear spine items [Publications301]; secondary non-linear content is not subject to the requirements in this section.
If the root of an XHTML Content Document consists of a single section of content, a section wrapper may be omitted (i.e., the body represents the implied section). Any subsections of the root section must be wrapped in section tags.
Each section must have a heading expressed either in an [HTML5] ranked heading element or an [ARIA] aria-label attribute. Sections must not have more than one heading element, but may include both a heading element and an aria-label. If a section includes both a label and a heading, the value of the aria-label attribute must not be the same as the heading (use the [ARIA] aria-labelledby attribute to explicitly link a heading to its section).
A section can be divided into subsections by nesting the section element, but once the first subsection is introduced only additional subsections are allowed to follow it (i.e., only another section element can follow the end of a subsection). This requirement also applies to the use of the section elements for subsectioning in any other [HTML5] sectioning content.
The following example shows how subsections must be contiguous.
<section>
<h1>Section 1</h1>
<p>…/p>
<section>
<h2>Subsection 1</h1>
…
</section>
<section>
<h2>Subsection 2</h1>
…
</section>
</section>
NOTE
The restriction against content between section elements exists to reduce the confusion that can arise when content is read by assistive technologies, as it is not always clear what section the continuation of content belongs to.
For article-based EPUB Publications, the [HTML5] article element may be used in place of the section element to group each article. The use of the element must follow the requirements defined in this section, including the use of section elements to represent the internal hierarchy.
Due to the paginated nature of fixed layouts, Fixed-Layout Publications are exempt from the requirements in this section.
[HTML5] heading elements must be used to provide headings only for [HTML5] sectioning content (including the body element).
When using a heading element for a section, the rank must reflect the nesting of that section within the document hierarchy (as noted in 4.3.10 Headings and sections [HTML5]). For example, a top-level section will have an h1 heading, child sections of it will have h2 headings, and so on. Note that untitled sections are included when determining the current heading rank (see 4.3.2 Untitled Sections for more information).
The heading does not have to be the first element of the section, and may be included inside a [HTML5] header element. If the section also includes a subtitle in a separate element, both the heading and subtitle must be enclosed in a header.
<header>
<h1>Chapter 1. The Battle</h1>
<p epub:type="subtitle">Once More Unto the Breach</p>
</header>
NOTE
See 4.12.1 Subheadings, subtitles, alternative titles and taglines [HTML5] for additional markup patterns for subtitles.
The application of headings must reflect the hierarchy regardless of how the content has been chunked for distribution (i.e., it is not necessary that the first section in each file begin with an h1).
The [ARIA] aria-label attribute must not be included on a section if it provides the same text already available in a ranked heading, as it can lead to duplicate announcement of the heading to users of assistive technologies.
If a section of content in the document hierarchy does not have an explicit heading (e.g., an untitled introduction) ‒ or sectioning is used to group significant content, such as learning objectives, that a reader using an AT would need access to ‒ the [ARIA] aria-label attribute must be used to provide an accessible name.
Adding this attribute allows users of assistive technologies to navigate to the section despite the lack of a heading, in addition to giving meaningful context.
Despite the lack of an explicit ranked heading, untitled sections are still part of the document's structural hierarchy and affect the heading rank of any child sections they contain. For example, the untitled section in the following example counts as the second level in the document outline, so the next ranked heading is an h3 even though no h2 appears in the markup:
<section epub:type="chapter">
<h1>Chapter 1: Lists</h1>
<section aria-label="Chapter body">
<section epub:type="learning-objectives">
<h3>1.2 Learning Objectives List</h3>
When the document hierarchy exceeds six levels of nesting, re-use the h6 element for the seventh nesting level and deeper. Avoid deep nesting of content, if possible, as the flattened structure below the sixth heading level impacts on the ability of users of assistive technologies (AT) to move through the document without repeatedly returning to the table of contents.
Do not use heading elements where the heading does not reflect the document hierarchy, as this use will impact on movement by AT users (e.g., inside figure captions).
When aside, article and nav elements with headings are included in a section, the heading rank must start one level lower than the containing section (e.g., if a section has an h3 heading, an aside within it will start with an h4 heading).
NOTE These terms will remain under active development for the duration of the EDUPUB initiative. It is anticipated that more terms will be added in subsequent iterations. Similarly, some terms may be deprecated or removed. |
The EDUPUB profile includes a set of structural semantic terms and content production rules designed to standardize the markup of educational materials.
The formal definitions of these terms, and requirements for their use, are defined in the normative EDUPUB Structural Semantics Vocabulary [EDUStructure].
Publishers are strongly recommended to represent all publication structures using the markup and terms defined in [EDUStructure]. The use of other terms from [StructureVocab] is optional, as is the use of custom terms.
Following is a categorized list of the terms available, with links to their definitions. Note that categorization does not imply usage restrictions, particularly in the case of sectioning terms.
The use of RDFa Lite [RDFaLite] is recommended for enriching content.
Examples of content enrichment in this specification use RDFa Lite syntax.
If a reflowable Rendition has a statically-paginated alternative representation (e.g., print), it is strongly recommended that page break markers be included. Including this information enables students to synchronize their reading with the paginated representation, as many classrooms are mixed print/digital environments.
The pagination source must be identified using the dc:source and source-of properties [Publications301] when including markers. The source may be a reference to the EPUB Publication if pagination is derived from another Rendition in the Container.
A page-list nav [ContentDocs301] must be included in the EPUB Navigation Document when page breaks are included. See 7.4 Page List for more information.
Although any core media type image format defined in 5.1 Core Media Types [Publications301] may be used in an EPUB Publication, the following guidelines are suggested:
EPUB Scriptable Components [ESC] may be included in EDUPUB-compliant Publication, and must be integrated and identified as defined in [ESC-PKG].
This section is informative
A document that presents the best practice recommendations for using IMS Learning Tools Interoperability™ (LTI™), IMS Caliper Analytics™ and IMS Question & Test Interoperability™ (QTI™) based content within an EPUB3 context, is available at [IMSGuide].
NOTE
Further recommendations and best practices for integrating EDUPUB content with assessments, outcomes and analytics services is planned to be integrated in a future iteration of this specification.
NOTE This section is currently under development in coordination with IMS Global. As a result, some requirements reference specifications that are not yet publicly available. Requirements without formal citations are noted in brackets and will be updated in a future revision. |
If an EPUB Publication is designed for use in environments that support LTI and Outcomes, it must meet all of the following criteria:
If an EPUB Reading System is designed for use in environments that support LTI and Outcomes, it must meet all of the following criteria:
A complete table of contents that fully reflects the heading hierarchy of the work is important for all readers, as it ensures that students are able to efficiently access any section necessary.
Consequently, the required toc nav [ContentDocs301] must include links to the complete structural hierarchy to conform to this profile.
A brief table of contents represents a shortened and/or specialized version of the table of contents. For example, sublevels of the document hierarchy might be removed for clarity and/or explanatory text added to each section heading.
A brief table of contents is identified by the epub:type attribute value "toc-brief".
The following example shows a toc-brief nav that provides chapter summaries.
<nav epub:type="toc-brief" id="toc-brief">
<h1>Brief Table of contents</h1>
<ol>
<li>
<p><a href="chap1.xhtml">Chapter 1 ‒ Introduction</a></p>
<p>A brief history of the evolution of scientific thinking.</p>
</li>
<li>
<p><a href="chap2.xhtml">Chapter 2 ‒ The Greeks</a></p>
<p>Archimedes, Aristotle, Euclid and Pythagoras</p>
</li>
</ol>
</nav>
As the nature of the brief table of contents is more structurally fluid than simple lists of links, it is typically not included in the EPUB Navigation Document, as nav elements in that document are subject to the restrictions defined in 2.2.4.1 The nav element: Restrictions [ContentDocs301]. If the brief table of contents is included in the EPUB Navigation Document, it must adhere to those requirements.
NOTE
If Authors only seek to include a reduced version of the toc nav [ContentDocs301] in the spine [Publications301] (i.e., requiring no specialized content, and where only some sub-tree branches are pruned), the use of the hidden attribute [ContentDocs301] with the toc nav is encouraged to avoid duplicating structures.
If an EPUB Publication includes figures, tables, and/or audio and video content, it is strongly encouraged that navigation lists for these be included in the EPUB Navigation Document, as inclusion simplifies access to the content for all readers.
A figure list is identified by adding the "loi" term to a nav element, a table list by the "lot" term, and audio and video lists by the "loa" and "lov" terms, respectively [StructureVocab].
If page break markers are included in the EPUB Publication, a page-list nav [ContentDocs301] must be included in the EPUB Navigation Document.
Likewise, if the EPUB Publication is statically paginated through the use of fixed layout pages, a page-list nav must be included, even if no print equivalent exists.
An EPUB Publication conforming to this specification must be identified as such in the package metadata of each of its Renditions by including a dc:type element [Publications301] with the value "edupub".
The following example shows an EPUB Publication identified as EDUPUB-conformant.
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>edupub</dc:type>
…
</metadata>
Educational metadata is needed to describe the suitability of content for educational settings, and to facilitate search and retrieval.
The [schema.org] CreativeWork type includes educational metadata properties that Authors can set in the EPUB Package Document to identify the nature and suitability of the content. In addition, the [schema.org] EducationalAudience type can be used to express the intended audience of the work. This specification does not require the use of any of these properties.
The usage recommendations in the following subsections are suggested based on the intended audience: schools, higher education, and professional/technical/corporate.
NOTE
See the audience/audienceType property for how to declare this audience.
In some cases, a default value is assumed for educational properties when they are not specified in the metadata. Default values are indicated in the allowed values sections.
NOTE
A mapping between schema.org and IMS metadata properties is provided in Appendix E.1.
This specification does not enforce case-sensitivity on the values of these properties. If Reading Systems or other processing agents seek to utilize these properties for specialized behaviors, they must normalize the case of their values prior to evaluation.
Recommended Value(s) corporate, higher-ed, professional, schools No default value. Cardinality Zero or more Usage When expressing the [schema.org] educational metadata properties defined in this section, it is strongly recommended that this property be set. Example <meta property="schema:audience" id="aud01">schema:audience</meta> <meta property="schema:audienceType" refines="#aud01">schools</meta> |
Recommended Value(s) Refer to D.1.1 educationalRole Default value: Student Cardinality Zero or one Usage Professional/Technical/Corporate: Strongly recommended Schools: Strongly recommended Higher Education: Strongly recommended Example <meta property="schema:audience" id="aud01">schema:audience</meta> <meta property="schema:educationalRole" refines="#aud01">teacher</meta> |
Recommended Value(s) "schema:educationalAlignment" (Refer to the [SchemaGuide].) No default value. Cardinality One or more Usage Professional/Technical/Corporate: optional Schools: recommended Higher Education: recommended Example <meta id="ea02" property="schema:educationalAlignment">schema:educationalAlignment</meta> <meta refines="#ea02" property="schema:alignmentType">teaches</meta> <meta refines="#ea02" property="schema:targetName"> Calculate probabilities using the Addition Rules and Multiplication Rules. </meta> <meta refines="#ea02" property="schema:targetUrl"> http://example.com/competency502041 </meta> |
Recommended Value(s) Refer to D.1.3 educationalUse No default value. Cardinality Exactly one Usage Professional/Technical/Corporate: optional Schools: Strongly recommended Higher Education: Strongly recommended Example <meta property="schema:educationalUse">demonstration</meta> |
Recommended Value(s) Refer to D.1.5 interactivityType Default value: Activity Cardinality Zero or one Usage Professional/Technical/Corporate: recommended Schools: Strongly recommended Higher Education: Strongly recommended Example <meta property="schema:interactivityType">mixed</meta> |
Recommended Value(s) URL No default value. Cardinality Zero or more Usage Professional/Technical/Corporate: recommended Schools: recommended Higher Education: recommended Example <meta property="schema:isBasedOnUrl">http://www.example.com/book</meta> |
Recommended Value(s) Refer to D.1.6 learningResourceType No default value. Cardinality Exactly one Usage Professional/Technical/Corporate: optional Schools: Strongly recommended Higher Education: Strongly recommended Example <meta property="schema:learningResourceType">activity</meta> |
Recommended Value(s) A string representing an [ISO8601] duration No default value. Cardinality Zero or one Usage Professional/Technical/Corporate: optional Schools: optional Higher Education: optional Example <meta property="schema:timeRequired">P90M</meta> |
Recommended Value(s) Refer to D.1.4 typicalAgeRange No default value. Cardinality Zero or more Usage Professional/Technical/Corporate: optional Schools: Strongly recommended Higher Education: recommended Example <meta property="schema:typicalAgeRange">16-18</meta> |
Identifying the accessible qualities of an EPUB Publication is of vital importance in educational contexts, as the needs and preferences of students will dictate whether any given Rendition of the content will be sufficiently usable by them in their studies.
The [schema.org] CreativeWork type includes accessibility metadata properties [A11YProperties] that Authors can set in the EPUB Package Document to identify the accessible qualities of a given Rendition of the EPUB Publication.
Authors must use the accessibilityFeature property to identify any applicable accessibility features, repeating the property for each feature. A recommended list of values to use with this property is maintained at the W3C Web Schemas wiki [A11YProperties].
At a minimum, all EDUPUB-conformant EPUB Publications must specify the value "tableOfContents", as a complete table of contents is required as described in 7.1 Table of Contents. It is strongly recommended that the other properties be specified whenever applicable. Note, however, that It is not valid to include the value "none", as there is always at least one value that can be specified.
Refer to the schema.org metadata integration guide [SchemaGuide] more information on how to include these properties in the Package Document.
In distribution contexts that require the use of an ONIX record, the accessibility properties defined in Code List 196 [ONIXCodes] should be specified, as appropriate.
NOTE
A mapping table from the ONIX to schema.org frameworks is available on the a11ymetadata.org site.
Reading Systems should provide a mechanism to ingest ‒ and support the rendering of ‒ annotations that conform to the Open Annotation in EPUB specification [OpenAnnotation].
Support for exporting and synchronizing annotations is optional.
This section is informative
In educational contexts, there is a need to distribute and consume not only complete publications, but components of publications and other objects not necessarily originating within a publication. Such "distributable objects" could be complete EPUB Content Documents (for example, a chapter of a book), sections of such a document (for example, an exercise or a set of learning objectives), media resources (such as a video or an interactive feature), or a combination of such resources that are not necessarily contiguous within the parent EPUB Publication.
This section provides the specifications that pertain to creating Distributable Objects [DistributableObjects] that are intended for education and which conform to this specification.
This specification does not define a specific type of Distributable Object to identify educational content.
For general educational content distribution needs, the distributable-object type defined in the [DistributableObjects] is recommended.
Other, more specific types, such as EPUB Scriptable Components [ESC], may be used, as appropriate (provided the Distributable Object conforms to all requirements in the respective specification).
To simplify (re)use and integration in EDUPUB workflows, distribution channels and EPUB Publications, any Distributable Object whose content conforms to this profile may be identified as conformant. The following metadata must be expressed to indicate conformance:
In the case of Packaged Objects [DistributableObjects], this metadata is expressed in the package metadata [Publications301]. For Embedded Objects [DistributableObjects], the metadata is expressed in the collection metadata [Publications301].
As Distributable Objects are created and consumed for many purposes, it is not a requirement that all the Distributable Objects used in a Rendition be identified as conforming to the EDUPUB profile.
If the Author is responsible for the creation of a Distributable Object in a compliant EPUB Publication, however, it is recommended that the Distributable Object be identified as conforming to the profile.
EPUB Publications conformant with this profile may embed any type of Distributable Object provided the resulting Rendition(s) remain conformant to the requirements of this specification.
This appendix is informative
A sample CSS file is available at http://www.idpf.org/epub/profiles/edu/res/sample.css
The sample CSS file is provided for informational purposes only. Authors are free to use any CSS class names and styles with their documents.
NOTE
The CSS profile is subject to ongoing change as part of the evolution of the profile.
This appendix is informative
NOTE
Content validation services will be referenced from here in a forthcoming iteration.
This appendix is informative
For informational review of the markup patterns defined in this specification, EPUB Publications conformant to this profile are provided at the EDUPUB samples repository.
These documents are subject to change, and may be added to, and removed, over time.
NOTE The following sections provide recommended vocabularies for use with the schema.org educational metadata properties. These vocabularies are expected to be removed in a future iteration after formal vocabularies are published. |
Additional values from IMS
This appendix is informative
The below table contains a correspondence mapping between the educational metadata terms of schema.org [schema.org] and IMS as described in Appendix E of [IMSGuide].
schema.org term |
IMS term |
GUID [identifier] |
|
targetURL |
Resource URL |
name |
Title [title] |
description |
Description [description] |
keywords |
Keywords [subject] |
typicalAgeRange |
From Grade |
typicalAgeRange |
To Grade |
productID |
ISBN [identifier] |
learningResourceType |
Type [type] |
educationalAudience |
UseType |
educationalUse |
UseType (repeat) |
Thumbnail |
Thumbnail |
educationalAlignment |
Mapping to Curriculum Standards |
AlignmentObject |
Mapping to Curriculum Standards (repeat) |
AlignmentType |
|
educationalRole |
|
timeRequired |
|
interactivityType |
|
useRightsURL |
|
isBasedOnURL |
EPUB has been developed by the International Digital Publishing Forum in a cooperative effort, bringing together publishers, vendors, software developers, and experts in the relevant standards.
The EDUPUB Profile 1.0 specification was prepared by the International Digital Publishing Forum's EPUB Working Group, operating under under the leadership of:
Active members of the working group at the time of publication were:
IDPF Members
Invited Experts/Observers
[A11YProperties] Schema.org Accessibility Metadata Properties.
[ARIA] Accessible Rich Internet Applications (WAI-ARIA) 1.0, J. Craig, et al.
[ContentDocs301] EPUB Content Documents 3.0.1
[CSS21] Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos, et al. 7 June 2011.
[DCMES] Dublin Core Metadata Element Set, Version 1.1.
[DICT] EPUB Dictionaries and Glossaries 1.0.
[DistributableObjects] EPUB Distributable Objects.
[EDUStructure] EDUPUB Structural Semantics.
[EPUBCFI] EPUB Canonical Fragment Identifier (epubcfi) Specification.
[ESC] EPUB Scriptable Components.
[ESC-PKG] EPUB Scriptable Components Packaging and Integration.
[HTML5] HTML5: A vocabulary and associated APIs for HTML and XHTML.
[IDX] EPUB Indexes 1.0.
[JPEG] JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) .
[LTI12] Learning Tools Interoperability® (LTI) Implementation Guide v1.2. Final Specification. S.Vickers, IMS Global Consortium Inc. January 2015.
[LTI2] Learning Tools Interoperability® (LTI) Implementation Guide v2.0. Final Specification. Vickers, IMS Global Consortium Inc. January 2014.
[LTIO2] Learning Tools Interoperability® Outcomes Management v.2.0. Public Draft. S.Vickers, IMS Global Consortium Inc. December 2014.
[Manifest] EPUB Manifest Role.
[MediaOverlays301] EPUB Media Overlays 3.0.1.
[MultipleRenditions] EPUB Multiple-Rendition Publications.
[OCF301] Open Container Format 3.0.1.
[ONIXCodes] Onix Code Lists. EDItEUR.
[OpenAnnotation] Open Annotation in EPUB.
[PNG] Portable Network Graphics (PNG) Specification (Second Edition) . David Duce. 10 November 2003.
[Publications301] EPUB Publications 3.0.1.
[RDFaLite] RDFa Lite 1.1. Manu Sporny. 07 June 2012.
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987). M Duerst, et al. January 2005.
[schema.org] schema.org.
[sRGB] IEC 61966-2-1:1999 Multimedia systems and equipment. Colour measurement and management. Colour management. Default RGB colour space. sRGB
[StructureVocab] EPUB 3 Structural Semantics Vocabulary .
[SVG] Scalable Vector Graphics (SVG) 1.1 (Second Edition) . Erik Dahlström, et al. 09 June 2011.
[SchemaGuide] Schema.org Metadata Integration Guide for EPUB 3.