The EPUB for Education profile represents the effort to adapt the functionality of the EPUB® 3 format to the unique structural, semantic and behavioral requirements of educational publishing.

Overview

Purpose and Scope

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 EPUB for Education 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:

Relationship to Other Specifications

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.

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

Terminology

Terms with meanings specific to EPUB 3.1 are capitalized in this document (e.g., "Author", "Reading System"). A complete list of these terms and definitions is provided in [[!EPUB31]].

Only the first instance of a term in a section is linked to its definition.

Conformance

Content Conformance

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:

Reading System Conformance

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:

It is anticipated that support for multiple renditions and annotations will be elevated to a requirement once those specifications become Recommendations.

Education Document Models

Reflowable Publications

The primary focus of this version of the EPUB for Education 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.

Fixed-Layout Publications

Although the creation of reflowable EPUB Publications is the preferred content model for the EPUB for Education profile, 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.

Note that due to the paginated nature of fixed layouts, Fixed-Layout Publications are exempt from the requirements in Content Structure.

Multiple-Rendition Publications

EPUB Publications that conform to this profile 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 "education".

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

Introduction

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

Identification

Publication

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 EPUB for Education profile as defined in 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>education</dc:type>
   …
</metadata>

Student Edition

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>

As teacher's guides do not have student editions, this guideline does not apply to their production.

Content

Structural Semantics

The EPUB for Education 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 Structural Semantics is RECOMMENDED, where applicable.

Styling

The standardization of CSS class names for controlling the appearance of teacher-specific content is under consideration for a future version of this profile.

Audience

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.

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>

Student Content

For accessibility purposes, it is strongly RECOMMENDED that student content not be represented as annotated images in teacher's editions.

Content Structure

Introduction

This section is informative

This section outlines key content structuring guidelines for the production of EPUB Publications that conform to this profile. Only differences from the core suite of EPUB specifications are noted.

Sectioning

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</h2>
     …
  </section>
  <section>
     <h2>Subsection 2</h2>
     …
  </section>
</section>

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.

Titles and Headings

Titled Sections

[[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 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>

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.

Untitled Sections

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 User 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>

Deep Nesting

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

Structured Components

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

Structural Semantics

These terms will remain under active development for the duration of the EPUB for Education initiative. It is anticipated that more terms will be added in subsequent iterations. Similarly, some terms may be deprecated or removed.

The EPUB for Education 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 EPUB Education 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.

Semantic Enrichment

The use of RDFa Lite [[RDFaLite]] is RECOMMENDED for enriching content.

Examples of content enrichment in this specification use RDFa Lite syntax.

Pagination

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 Page List for more information.

Images

The following guidelines are suggested for the inclusion of image content:

Scriptable Components

EPUB Scriptable Components [[ESC]] MAY be included in EPUB Publications that conform to this profile, and MUST be integrated and identified as defined in [[ESC-PKG]].

IMS Learning Tools Interoperability® (LTI®) and Outcomes

Integration with IMS LTI

This section is informative

A document that presents the best practice recommendations for using IMS Learning Tools Interoperability® (LTI®) is available at [IMSGuide].

The interactions involved in working with IMS LTI services, are illustrated in the following context diagram:

EDUPUB overview.jpg

Legend of the the context diagram above (from content out):

  1. EPUB 3 Content
    An EPUB Publication conformant with the definition in Content Conformance.
  2. Reading System
    An application conformant with the definition in Reading System Conformance. It is important to note that any EPUB Reading System that conforms to this profile MUST broker communications between the content and the Reading eco-system, or handle those tasks directly.
  3. Reading eco-system
    This is a stable, persistent provider of services to support the Reading System and provide a point of contact to learning systems. In this profile, the reading eco-system is a tool that is hosted with an LTI Tool Provider. [IMS LTI 1.2 Implementation Guide or IMS LTI 2.0 Implementation Guide]
  4. LTI Compliant LMS
    This is the learning system used by learners, instructors and other roles to support the learning environment. In LTI the term for a learning management system or learning platform is the LTI Tool Consumer. [IMS LTI 1.2 Implementation Guide or IMS LTI 2.0 Implementation Guide]
  5. Caliper Analytics™
    Caliper is an IMS standard that is used for capturing learning data, storing and analyzing it. It also defines a vocabulary for learning analytics. [IMS Caliper Analytics Implementation Guide ]
  6. Other LTI compliant Tool Provider
    This box represents other learning tools in the larger learning eco-system that can be linked to from an EPUB Publication. Embedded LTI links can securely link to these other tools. [IMS LTI 1.2 Implementation Guide or IMS LTI 2.0 Implementation Guide]

Caliper capabilities within EPUB 3 can be supported through an appropriate LTI capability.

Conformance

Content Conformance

If an EPUB Publication is designed for use in environments that support LTI launches and LTI’s Outcomes Management Service version 2, it MUST meet the following requirements:

  • If content is required to report its Outcomes, then it MUST conform to the requirements for Outcomes Reporting defined in 6.3.2.2 Content Structuring.

Reading System Conformance

An EPUB Reading System MUST meet all of the following criteria:

  • If it supports offline persistence to enable the local storage and delayed reporting of the Rich Outcomes data, support MUST be transparent to the operation of the content.
  • To support Outcomes Reporting, it MUST support one of two mechanisms: 1) act as Tool Provider, or 2) delegate the Outcomes to the Reading Eco-system. 
  • If the Reading System follows method (1), i.e., an internal Tool Consumer, then it MUST be certified as an [[LTI12]] or [[LTI2]] Tool Consumer.
  • If the Reading System follows method (2), delegation to the TP, then it MUST support educational Outcomes APIs specified in section 6.3.3

    LTI Link Conformance, discussed below, describes a method to do launches of other LTI tools (i.e., to “Other LTI compliant Tool Provider” as shown in the context diagram). These launches are nested within the original launch which opened the book. We call the original launch the ‘outer launch’ in descriptions below. We call in the embedded launch in an EPUB Publication the ‘inner launch’.

  • To support Embedded LTI Launch it MUST support one of two mechanisms: 1) the Reading System hosting its own Tool Consumer, or 2) a message protocol to delegate the Embedded Launch to the Reading Eco-system. Method 1 only applies to the case where the Reading System is a web app.
  • If the Reading System follows method (1), i.e., an internal Tool Consumer, then it MUST be certified as an [[LTI12]] or [[LTI2]] Tool Consumer.
  • If the Reading System follows method (2), delegation to the TP, then it MUST support LTI Link Content markup defined in LTI Links.
  • If the Reading System acts as an [[LTI12]] or [[LTI2]] Tool Consumer, for any of the purposes stated above, it MUST support appropriate parameter mapping from the outer launch. That is, parameters relating to user, course, and other supporting values MUST inherit from the original book launch.
  • If the Reading System acts as an [[LTI12]] or [[LTI2]] Tool Consumer, it MUST enable the administration and protection of the ‘Secrets’ and ‘Keys’ required by the Tools that can be launched from the Reading System.

These conformance constraints above boil down to a basic message: A Tool Consumer might have many more demands on it than a Reading System. It needs to host and protect many sensitive credentials. It needs to keep interface contracts on possibly many Tool Provider interface contracts. And it must be available if, for example, an Outcome Result message comes into it in the middle of the night for entry into a gradebook. In general, if an implementer’s Reading System is an offline- or remote- device, it is safer and more practical to delegate the embedded launch back to the Tool Provider. If, on the other hand, the reader is a server-based, online reader and is in the same security domain as the Tool Provider, then a Reader-based Tool Consumer is fine.

Reading Eco-system Conformance

If an EPUB Reading System is designed for use in environments that support LTI and Outcomes, it MUST meet all of the following criteria:

  • It MUST be certified as an [LTI12] or [LTI2] Tool Provider.
  • It MUST be certified as a client for the Outcomes Management 2.0 services (Line Item and LISResult) [LTIO2].
  • It SHOULD be certified as a service provider for the Outcomes Management 2.0 services (Line Item and LIS Result) [LTIO2].
  • If the Reading System is certified as an [LTI12] or [LTI2] Tool Consumer, it SHOULD enable LTI Outcomes data received from any launched Tool to be reported back to the entity that launched the Reading System (i.e., enable the outcomes to be reported back along the chained set of tools).

Outcomes

Introduction

Following LTI definitions, an Outcome is composed of data that comes from an interactive resource and is used to gather information about the user’s response to the resource. Typically this comes from an interactive assessment that the user elects to perform. This data is often routed to gradebooks in learning systems. The Outcome itself encapsulates two distinct objects:

  1. a lineitem identifies the type of the particular activity. For example, there may be exercises at the end of a chapter in an EPUB Publication. A particular lineitem might refer to question 3 of Chapter 17 of the text. The lineitem describes the particular question; e.g., ‘determine the surface area of regular polygons’.
  2. an LISResult identifies a score that a particular student generates for the associated lineitem. Continuing the example above, a result for the lineitem above might identify user ‘jsmith’ and assign a score of ‘0.76’.

Outcomes Reporting

To enable an EPUB Publication to report outcomes via LTI, all learning activities MUST be enclosed by [[HTML5]] flow content that carries an epub:type attribute with the value "assessment". In addition, each assessment MUST have an id attribute with a value that is unique with the scope of the entire EPUB Publication. The value of this attribute will be used to identify the assessment when submitting outcome data.

<div epub:type="assessment" id="unique_id">
        <div>...</div>
</div>

Each assessment marked up in this fashion will be able to report scores using the JavaScript APIs documented in section 6.3.3. When adding outcome support to an assessment, there are no additional JavaScript files that must be included in the EPUB Publication.

For outcomes to function and be identified inside of the Reading System and Tool Provider, an [[HTML5]] nav element with with the epub:type attribute value "assessments" MUST be included in the EPUB Navigation Document.

The link nodes within the assessment list MUST contain the following information:

  • href: a deep link to an assessment within the EPUB Publication. The link MUST point directly to an element that carries an epub:type attribute with the value "assessment" by using the value of its unique id.
  • data-maxscore: Max possible score for the activity.
  • data-graded: "1" if graded. "0" if not graded.
  • Each activity MUST have its own list item in the nav element:

Example:

<nav epub:type="assessments">
        <h2>List of Assessments</h2>
        <ol>
            <li><a href="c01.html#multiple_choice_01" data-maxscore="1" data-graded="1">Assessment 1 - The Brain</a></li>
            <li><a href="c01.html#multiple_choice_02" data-maxscore="1" data-graded="1">Assessment 2 - The Heart</a></li>
                …
        </ol>
</nav>

JavaScript APIs

Reading Systems MUST make the JavaScript APIs defined in this section available within each content page being rendered. These APIs all exist under the namespace of the host document.

EPUB.Education.reportScores([scores], callback);

  • Description: Report outcomes to the Reading System for transfer to Reading Eco-system, or directly to the originating Tool Consumer.
  • Parameters:
  • scores: Array of score objects containing score, location and optional metadata for the outcome.
  • callback (optional): Function to be called when outcome has been received by the Reading System but not necessarily processed by Reading Eco-System.

All score objects submitted via reportScores MUST be in the following format:

{
score: number,
location: string,
metadata: {…}
}

Where:

score
is a value between 0 and data-maxscore representing the User’s score for the activity.
location
is the unique identifier for the assessment. This MUST be equal to the value of the containing epub:type="assessment" element’s id attribute.
metadata (optional)
is a JSON object containing vendor-specific activity result data.

A specific vendor's implementation can store metadata and also return it via getScores. For example, if they want to let a student know they already did the activity, repopulate their answers, etc. It is up to the vendor how they want to handle this, and each one could have specific implementation details.

The callback function parameter is OPTIONAL. The function call returned will pass one parameter signaling if the score was a success: callback(err). The message text of the error can be accessed via the property err.message.

EPUB.Education.getScores([location IDs], callback);

  • Description: Retrieve one or more outcome results from Reading Eco-system via the Reading System client.
  • Parameters:
  • [locations]: Array of location values as submitted in score objects via reportScores. Example: [‘multiple_choice_01’,’multiple_choice_02’].
  • callback: Function to be called with results of outcome request.

The callback function parameter is required. The function call returned will pass two parameters: an error code and an array containing the last saved scored object for each location ID.

These score objects will include the same parameters as passed in via reportScores, with the addition of a timestamp (added by the Reading System or Reading Eco-system at submission time) denoting the original submission time of the score.

Sample return:

[
  {
    score: number,
    location: string,
    timestamp: UTCTimeStamp,
    metadata: {...}
 }
  …
]

Authorization

This section defines the means of authorizing access from the Reading System to the Reading Eco-System. The APIs below SHOULD use an HTTP Authorization header that contains the TP-provided access-token (TP-Access-Token) that was provided to it at the initialization of the EPUB Publication. The TP-Access-Token enables two capabilities: 1) it ensures the message is allowed into the Tool Provider and 2) it provides a means of correlating the computed response to the invocation from the TP.

Reading System responsibilities

The Reading System has to fulfill several responsibilities, as outlined in the following subsections.

At Reading System launch time

As described below in Launching EPUB Publications, when the Reading Eco-System launches an EPUB Publication it sends it a TP-Access-Token, and endpoints for services that it will require:

  • launch_presentation_return_url: redirect point when the book closes
  • result_handler_url: path to the Tool Provider’s result_handler to submit a result from the book
  • lti_launch_handler_url: path to the Tool Provider’s lti_launch_handler to start an embedded launch

At reportScores invocation

This event is activated when the content invokes EPUB.Education.reportScores. It marshals the parameters described into the following:

POST to result_handler_url with Authorization Header containing a TP-Access-Token and a body containing the JSON media type with following ‘flat’ fields

       access_token:                string
        [   (i.e., array)
                isbn:                     string
                activity_id:              string
                score:                    number
                score_detail:             json
                result_at:                iso8601 timestamp
        ]
returns: result_id

At getScores invocation

This event brokers a request from the Reading System to create a GET request to the Reading Eco-System to retrieve scores it has already submitted.

       GET to result_handler_url with path

       body:
       JSON media type
               access_token:                string
        [   (i.e., array)
                isbn:                        string
                activity_id:                string
                score:                        number
                score_detail:                json
                result_at:                iso8601 timestamp
        ]
        returns: 
                media type matching array elements in ‘reportScores’ above

At ltiLaunch event

This event brokers a request from the Reading System to create an embedded LTI launch. See Embedded Launch below.

       POST to embedded_launch_handler

       body:

       JSON media type with flat body:

               tool_proxy_id:                string
                resource_name:        string
                resource_link_id:        string
        returns false if Reading Eco-system is unavailable.

The tool_proxy_id is an identifier to a Tool Proxy stored on the inner Tool Provider.

The resource_name identifies which resource, among possibly many defined in the Tool Proxy.

The resource_link_id is the LTI resource_link_id and SHOULD be set to the unique activity_id defined in 6.3.2.2 Content Structuring.

Cross-system flows

This section is informative

Flow 1: Provisioning Learning Activities

Before grades can be created in a LMS gradebook, a gradebook column for the particular assignment needs to be created. LTI calls this column the LineItem. For example, a calculus exercise might create the lineitem MinMax.question-3.

Steps

  1. [TC] Instructor clicks on an LTI link (v1.2 / 2.0+) in a Tool Consumer (TC). The particular LTI launch will initiate a user experience to create or manage lineitems. The user’s launch is run within a context of a particular course and has to launch with a ‘LineItems.url’ capability. This will pass to the Tool Provider (TP) an endpoint that will allow it access the lineitem container capability for the current course.
  2. [TP] Accesses TOC metadata for the book.
  3. [TP] Accesses the list of assessments available for an EPUB Publication as specified within the assessments nav element. A UX selector dialog allows the instructor to associate an assessment that is configured as ‘gradeable’, with a new lineitem.
  4. [TP] Creates the new lineitem in the TC by POSTing to the lineitems url and providing it with the activity name and maxscore. (e.g., MinMax.question-3)

It might seem odd that the gradebook lineitem which lives on the TC is provisioned by a UX that is running on the TP. The reason for this is an access control constraint. In LTI Outcomes V2 the lineitem is owned by the TP not the TC. Only the TP that creates the lineitem can operate on it; e.g., set a grade into it. The course gradebook might have many different lineitems for a course and each of these lineitems is protected from being accessed or modified by, say, another vendor’s tool. It can only be maintained by the tool that creates it.

Flow 2: Launching EPUB Publications

Description

When the learner wants to use the EPUB Publication, the learner clicks on an LTI link to launch the book. This launch opens the book and passes some crucial information to the TP.

Steps

  1. [TC] User clicks on an LTI link (v1.2 / 2.0+) in a Tool Consumer (TC).
  2. [TP] Launch the Reading System with a reference to the EPUB Publication and also pass a TP access token (see comment below) and needed endpoints for various services.
  3. [Reader] persists the access token given to it for future uses (e.g., subsequently transmitting a result from an exercise.

Particular implementations might have several implementation-defined fields. But the minimum values mentioned above are sufficient to recover launch-time state for most uses.

Flow 3: Outcome Flow

The following Outcome Flow is relevant to Method 2 outcomes as described above in section 6.2.2; that is, delegating outcomes to a server-based Tool Provider.

Description

This flow shows the sequence of events for an assessment result submission and its forwarding through the Reading System, Tool Provider (TP), Tool Consumer (TC), and finally to gradebook

Steps

  1. [EPUB 3] Document activity link signals a result is available. A JavaScript reportScores sends the result to the Reading System.
  2. [Reading System] Reading System composes a POST with the access code provided to the reader on launch plus activity_id, result value, maxscore, and an arbitrary JSON-encoded data structure with whatever contents is desired.
  3. [TP] Looks up the Lineitem, matched by activity_id.
  4. [TP] PUTS a new result object to the result container for the specific lineitem.
  5. [TC] stores the result into the gradebook at the lineitem column specified.

Flow 4: Embedded LTI Launch

Description

An EPUB Publication can support embedded LTI launches. For example, a student at a learning institution can open an EPUB Publication and be reading it. The student comes upon a link to connect to publisher-supplied content, The student can directly ‘Single-Sign-On’ (SSO) to the publisher site and review that content.

There are many ways for an implementer to create an embedded launch. In the section on Reading System conformance there is great detail on the norms required. The following diagrams the two alternatives:

Alternative 1: Reading System hosts a Tool Consumer:

The constraints dictated in the Reading System Conformance section work fine for online Reading Systems in the same security domain as the Tool Provider, but avoid using it on lightweight, remote, or offline devices.

Steps

Creating a Tool Consumer (TC) in any environment, whether within an LMS or within an EPUB Publication, is fully described in the [IMS Impl Guide 1.2] or [IMS Impl Guide 2.0+].

Alternative 2: Reader delegates back to the Tool Provider:

Definition

An embedded launch that is delegated back through a Tool Provider requires that LTI metadata be stored that defines essential configuration data for an LTI launch. Most fundamentally, the metadata includes a consumer key, secret, and endpoint to direct the launch. Other launch metadata is optional.

In LTI 2+ this kind of metadata is stored in a discrete resource called the LTI ToolProxy [[IMSToolProxy]].

But In LTI 1 there is no such resource. Rather this metadata is stored in vendor-specific locations at the discretion of the LTI 1 implementor.

In the discussion below we will use the term ToolProxy informally. For LTI 2 systems it will indeed be the LTI ToolProxy. But for LTI 1 systems it will be some vendor-defined storage region that is capable of storing all essential LTI launch metadata.

Preconditions

Certain provisioning is necessary on the Tool Provider to prepare for the Embedded LTI Launches.

  1. [TP] In advance of any embedded launch it is necessary to create a ToolProxy that will be needed to support the interactions between the Inner Tool Consumer and Inner Tool Provider (InnerTC and InnerTP). A ToolProxy is a formal interface contract that provides all the information needed to performs launches, services, or support other messages between LTI-compliant partners. The ToolProxy includes endpoints, credentials, and capabilities of the interactions. It is extensively described in the LTI media type documentation for application/vnd.ims.lti.v2.toolproxy+json.
  2. The ToolProxy can be created manually, by a vendor-provided tool, or automatically by using an LTI 2+ Registration flow.
  3. The created ToolProxy should be stored in the ToolProvider in a location that is accessible to the embedded launch broker.

Flow

  1. [[EPUB 3]] Document activity link signals a launch is requested. A JavaScript launchActivity method invokes the Reading System with information that identifies the launch metadata.
  2. [Reading System] Reading System composes a POST with the original TP-access-token provided to access sources. It needs to pass three values to the Tool Provider (TP):
  1. identifier of a TP-stored ToolProxy that defines the interface contract to the new ‘inner’ tool being launched [IMSToolProxy]
  2. name of the ToolProxy resource (specific tool) to launch into
  3. name assigned to the resource_link in the EPUB Publication. This value will be used for the resource_link_id of the ‘inner’ launch [IMSLTIImplGuide] for the appropriate version.
  1. [TP] TP uses the access token to recover the context of the ‘outer’ launch. It then starts assuming the behavior of an ‘inner’ Tool Consumer.
  2. [InnerTC] First it looks up the ToolProxy for the inner launch that was referenced by the ReadingSystem. This interface contract gives details of the inner launch requirements including new endpoints, required parameters, signing details, etc. The innerTC derives launch parameters inherited from the outer launch and creates a new parameters for the inner launch. It transforms parameters based on the LTI Mapping Parameter table (below). Finally it signs the new launch parameters and redirects to the innerTP with the LTI POST-autosubmit idiom [[IMSLTIImplGuide]].
  3. [InnerTP] Behaves as any LTI launch. It renders its tool, lets the user interact. If it performs outcomes handling (either V1 or V2 outcomes) it performs them in the usual fashion and returns them via the endpoints provided in the inner launch (from the ToolProxy).
  4. [InnerTP] It finally redirects, using the normal launch_presentation_return_url to the ancestor TP.
  5. [InnerTC] Any returned results from the InnerTP need to be brokered back to the TP. This involves forwarding the message to the outer consumer after re-signing it.
  6. [TP] continues in the outer launch activity (e.g., in the EPUB Publication).

LTI Mapping Parameters

The following table shows the different LTI parameter categories and how they are handled in a brokered launch situation. Note that the Mapping column indicates the forward mappings (outer-to-inner launch). The final row shows the mappings required for reverse mappings. This is typically for inner results being passed back.

Outer Launch Mapping Inner Launch
User: user, role, name, email Avail parms broker depending on privacy settings
Course: context_id, label, title Avail parms broker depending on privacy settings
URLs to signed services Cross-domain: outer routes prepended to path
tool_consumer_instance_guid (outermost launch only) sourced_tool_consumer_instance_guid
invoke signed callback Cross-domain: callback handler verifies and re-signs

The sourced_tool_consumer_instance_guid requires special comment. It is used in to disambiguate user identity when LTI launches (either direct or embedded) come into a tool from possible different sources; i.e. through different embedded launches or a parallel communication from the origin Tool Consumer to the final Tool Provider.

Publication Metadata

Profile Identification

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 "education".

The following example shows an EPUB Publication identified as conforming to this profile.

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:type>education</dc:type>
  …
</metadata>

Educational Metadata

Educational Properties

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.

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.

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.

audienceType

Recommended Values
( corporate | higher-ed | professional | schools )*
Default Value
none
Usage
When expressing the [[schema.org]] educational metadata properties defined in this section, it is strongly RECOMMENDED that this property be set.
Examples
<meta property="schema:audience" id="aud01">schema:audience</meta>
<meta property="schema:audienceType" refines="#aud01">schools</meta>
<meta property="schema:educationalRole" refines="#aud01">student</meta>

educationalRole

Recommended Values
( Administrator | Mentor | Parent | Peer Tutor | Specialist | Student | Teacher | Team | Principal | teacher/uploader | curriculum admin | school admin)?
Default Value
Student
Usage
Professional/Technical/Corporate: Strongly RECOMMENDED
Schools: Strongly RECOMMENDED
Higher Education: Strongly RECOMMENDED
Examples
<meta property="schema:audience" id="aud01">schema:audience</meta>
<meta property="schema:educationalRole" refines="#aud01">teacher</meta>
<meta property="schema:audienceType" refines="#aud01">higher-ed</meta>

educationalAlignment

Recommended Values
see [[Schema Integration Guide]] https://idpf.github.io/epub-guides/schema-org-integration/
Default Value
none
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>

educationalUse

Recommended Values
( Activity | Analogies | Assessment | Auditory | Brainstorming | Classifying | Comparing | Cooperative Learning | Creative Response | Demonstration | Differentiation | Discovery Learning | Discussion/Debate | Drill & Practice | Experiential | Field Trip | Game | Generating hypotheses | Guided questions | Hands-on | Homework | Identify similarities & differences | Inquiry | Interactive | Interview/Survey | Interviews | Introduction | Journaling | Kinesthetic | Laboratory | Lecture | Metaphors | Model & Simulation | Musical | Nonlinguistic | Note taking | Peer Coaching | Peer Response | Play | Presentation | Problem Solving | Problem-based | Project | Questioning | Reading | Reciprocal teaching | Reflection | Reinforcement | Research | Review | Role Playing | Service learning | Simulations | Summarizing | Technology | Testing hypotheses | Thematic instruction | Visual/Spatial | Word association | Writing )
Default Value
none
Usage
Professional/Technical/Corporate: OPTIONAL
Schools: RECOMMENDED
Higher Education: RECOMMENDED
Example
<meta property="schema:educationalUse">demonstration</meta>

interactivityType

Recommended Values
( Active | Expositive | Mixed )?
Default Value
Active
Usage
Professional/Technical/Corporate: RECOMMENDED
Schools: RECOMMENDED
Higher Education: RECOMMENDED
Example
<meta property="schema:interactivityType">mixed</meta>

isBasedOnUrl

Recommended Values
( URL )*
Default Value
none
Usage
Professional/Technical/Corporate: RECOMMENDED
Schools: RECOMMENDED
Higher Education: RECOMMENDED
Example
<meta property="schema:isBasedOnUrl">http://www.example.com/book</meta>

learningResourceType

Recommended Values
( Activity | Assessment | Audio | Broadcast | Calculator | Discussion | E-Mail | Field Trip | Hands-on | In-Person/Speaker | Kinesthetic | Lab Material (Printed Activities, Instruments, Samples...) | Lesson Plan | Manipulative | MBL (Microcomputer Based) | Model | On-Line | Podcast | Presentation | Printed | Quiz | Robotics | Still Image | Test | Video | Wiki | Worksheet )
Default Value
none
Usage
Professional/Technical/Corporate: OPTIONAL
Schools: RECOMMENDED
Higher Education: RECOMMENDED
Example
<meta property="schema:learningResourceType">activity</meta>

timeRequired

Recommended Values
A string representing an [[ISO8601]] duration.
Default Value
none
Usage
Professional/Technical/Corporate: OPTIONAL
Schools: OPTIONAL
Higher Education: OPTIONAL
Example
<meta property="schema:timeRequired">P90M</meta>

typicalAgeRange

Recommended Values
( 0-2 | 2-5 | 5-8 | 8-10 | 10-12 | 12-14 | 14-16 | 16-18 | 18+ )
Default Value
none
Usage
Professional/Technical/Corporate: OPTIONAL
Schools: RECOMMENDED
Higher Education: RECOMMENDED
Example
<meta property="schema:typicalAgeRange">16-18</meta>

Accessibility Metadata

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 EPUB Publications that conform to this profile 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.

A mapping table from the ONIX to schema.org frameworks is available on the a11ymetadata.org site.

Annotations

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.

Distributable Educational Objects

Introduction

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.

Identification

10.2.1 Distributable Object Type

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

10.2.2 Education Conformance

To simplify (re)use and integration in 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:

  1. all requirements defined in 8. Publication Metadata; and
  2. the addition of an additional dc:type element [Publications301] with the identifier "education".

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

Embedded Objects

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

Sample CSS

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.

The CSS profile is subject to ongoing change as part of the evolution of the profile.

Validation

This appendix is informative

Content validation services will be referenced from here in a forthcoming iteration.

Example Documents

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 EPUB for Education samples repository.

These documents are subject to change, and can be added to, and removed, over time.

Educational Metadata Properties

Recommended Vocabularies

The following sections provide draft vocabularies for use with the schema.org educational metadata properties, but this appendix is expected to be removed once formal vocabularies are published by Dublin Core. Use caution when implementing these values as they are subject to change in the final published version.

educationalRole

  • Administrator
  • Mentor
  • Parent
  • Peer Tutor
  • Specialist
  • Student
  • Teacher
  • Team
  • Principal

Additional values from IMS

  • teacher/uploader
  • curriculum admin
  • school admin

alignmentType

  • assesses
  • teaches
  • requires
  • textComplexity
  • readingLevel
  • educationalSubject
  • educationLevel

educationalUse

  • Activity
  • Analogies
  • Assessment
  • Auditory
  • Brainstorming
  • Classifying
  • Comparing
  • Cooperative Learning
  • Creative Response
  • Demonstration
  • Differentiation
  • Discovery Learning
  • Discussion/Debate
  • Drill & Practice
  • Experiential
  • Field Trip
  • Game
  • Generating hypotheses
  • Guided questions
  • Hands-on
  • Homework
  • Identify similarities & differences
  • Inquiry
  • Interactive
  • Interview/Survey
  • Interviews
  • Introduction
  • Journaling
  • Kinesthetic
  • Laboratory
  • Lecture
  • Metaphors
  • Model & Simulation
  • Musical
  • Nonlinguistic
  • Note taking
  • Peer Coaching
  • Peer Response
  • Play
  • Presentation
  • Problem Solving
  • Problem-based
  • Project
  • Questioning
  • Reading
  • Reciprocal teaching
  • Reflection
  • Reinforcement
  • Research
  • Review
  • Role Playing
  • Service learning
  • Simulations
  • Summarizing
  • Technology
  • Testing hypotheses
  • Thematic instruction
  • Visual/Spatial
  • Word association
  • Writing

typicalAgeRange

  • 0-2
  • 2-5
  • 5-8
  • 8-10
  • 10-12
  • 12-14
  • 14-16
  • 16-18
  • 18+

interactivityType

  • Active
  • Expositive
  • Mixed

learningResourceType

  • Activity
  • Assessment
  • Audio
  • Broadcast
  • Calculator
  • Discussion
  • E-Mail
  • Field Trip
  • Hands-on
  • In-Person/Speaker
  • Kinesthetic
  • Lab Material (Printed Activities, Instruments, Samples...)
  • Lesson Plan
  • Manipulative
  • MBL (Microcomputer Based)
  • Model
  • On-Line
  • Podcast
  • Presentation
  • Printed
  • Quiz
  • Robotics
  • Still Image
  • Test
  • Video
  • Wiki
  • Worksheet

Educational Metadata Mappings

This appendix is informative

E.1 IMS/Schema.org mapping

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

Acknowledgements and Contributors

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 EPUB for Education 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