|
| 1 | +--- |
| 2 | +title: Presentation API 4.0 Change Log |
| 3 | +layout: spec |
| 4 | +tags: [presentation-api, change-log] |
| 5 | +cssversion: 2 |
| 6 | +--- |
| 7 | + |
| 8 | +# IIIF Presentation API 4.0 Change Log |
| 9 | + |
| 10 | +This document accompanies the IIIF Presentation API Specification, Version 4.0, and describes the changes made in this major release, including backwards incompatible modifications from version 3.0. |
| 11 | + |
| 12 | +--- |
| 13 | + |
| 14 | +## 1. Breaking Changes |
| 15 | + |
| 16 | +### 1.1. Classes |
| 17 | + |
| 18 | +#### 1.1.1. Introduce an abstract Container class with three concrete subtypes |
| 19 | + |
| 20 | +Version 3.0 used Canvas as the single container class for all content, relying on optional `height`, `width`, and `duration` properties to accommodate both spatial (image) and temporal (audio) use cases. This created ambiguity: an audio-only Canvas carries no meaningful spatial dimensions, but was still modelled as a two-dimensional surface. |
| 21 | + |
| 22 | +Version 4.0 introduces an abstract **Container** class with three concrete subtypes. **Canvas** remains the container for two-dimensional spatial content and may have an optional temporal range. **Timeline** is a new purely temporal container without spatial coordinates, intended for audio-only content; it requires `duration` and has no `height` or `width`. **Scene** is a new unbounded three-dimensional container using a right-handed Cartesian coordinate system; it may also carry `duration` for time-based 3D content. |
| 23 | + |
| 24 | +Canvas-based Manifests conforming to version 3.0 remain valid. Publishers with audio-only resources currently modelled as Canvases without spatial dimensions should migrate those resources to Timeline. |
| 25 | + |
| 26 | +#### 1.1.2. Canvas now requires `height` and `width` |
| 27 | + |
| 28 | +In version 3.0, `height` and `width` were recommended on Canvas but could be omitted for audio resources. Because audio-only content now has its own Timeline container, Canvas `height` and `width` become required in version 4.0. Publishers who previously omitted these properties on audio Canvases must migrate to Timeline. |
| 29 | + |
| 30 | +### 1.2. Property Renames |
| 31 | + |
| 32 | +#### 1.2.1. Rename `placeholderCanvas` to `placeholderContainer` |
| 33 | + |
| 34 | +The `placeholderCanvas` property introduced in version 3.0 has been renamed `placeholderContainer`. The semantics are unchanged—the referenced Container provides content displayed before the primary resource loads or when it cannot be rendered—but the name now correctly reflects that any Container type (Canvas, Timeline, or Scene) may serve this role. |
| 35 | + |
| 36 | +#### 1.2.2. Rename `accompanyingCanvas` to `accompanyingContainer` |
| 37 | + |
| 38 | +Similarly, `accompanyingCanvas` has been renamed `accompanyingContainer`. The referenced Container still provides supplementary content rendered alongside the primary resource (such as a still image shown during audio playback), but the name is generalised to accommodate the full Container hierarchy. |
| 39 | + |
| 40 | +### 1.3. Protocol |
| 41 | + |
| 42 | +#### 1.3.1. Update context for new major version |
| 43 | + |
| 44 | +The JSON-LD context document URI has been updated for the new major version. The `@context` value must be the new 4.0 context URI, or include it as the final item in an array when extension contexts are also present. |
| 45 | + |
| 46 | +--- |
| 47 | + |
| 48 | +## 2. Non-Breaking Changes |
| 49 | + |
| 50 | +### 2.1. Three-Dimensional Content |
| 51 | + |
| 52 | +#### 2.1.1. Add Scene as a three-dimensional Container |
| 53 | + |
| 54 | +The Scene Container class represents an infinite three-dimensional space using a right-handed Cartesian coordinate system, with the coordinate origin at (0, 0, 0). Scenes may optionally have `duration`, enabling time-based 3D content such as animations. Content resources and other Containers are positioned within a Scene using Specific Resources with Transform annotations. |
| 55 | + |
| 56 | +Scene provides a first-class container for 3D models, spatial compositions, and interactive three-dimensional experiences, complementing Canvas for two-dimensional and Timeline for audio-only content. |
| 57 | + |
| 58 | +#### 2.1.2. Add Lights for illuminating Scenes |
| 59 | + |
| 60 | +Five light types are defined for Scenes. **AmbientLight** provides non-directional uniform illumination across the entire Scene. **DirectionalLight** simulates a distant source with parallel rays from a specified direction. **PointLight** radiates from a specific position in all directions. **SpotLight** emits a cone of light from a position and direction, with a configurable angle. **ImageBasedLight** uses an environment map to provide both illumination and reflections, enabling physically-based rendering. |
| 61 | + |
| 62 | +Scenes should include at least one light; clients may supply a default if none is specified. |
| 63 | + |
| 64 | +#### 2.1.3. Add Cameras for viewpoints into Scenes |
| 65 | + |
| 66 | +Two Camera types define viewpoints into Scene space. **PerspectiveCamera** simulates the human eye with a field-of-view angle and near/far clipping planes. **OrthographicCamera** uses parallel projection, useful for technical, architectural, or orthographic visualisations. Cameras specify their position and orientation, and the client presents this viewpoint to the user on load. |
| 67 | + |
| 68 | +#### 2.1.4. Add Audio Emitters for spatial audio in Scenes |
| 69 | + |
| 70 | +Three audio emitter types enable spatially-positioned audio within Scenes. **AmbientAudio** applies equally throughout the Scene regardless of viewer position. **PointAudio** emanates from a specific three-dimensional position, with volume attenuating by distance. **SpotAudio** emits a cone of audio from a position and direction with a configurable angle. Emitters have `source` and `volume` properties, associating them with audio content resources. |
| 71 | + |
| 72 | +#### 2.1.5. Add Transforms for positioning content within Scenes |
| 73 | + |
| 74 | +Three Transform types modify the local coordinate space when placing content inside a Scene. **TranslateTransform** moves the origin to a new position. **RotateTransform** rotates around a named axis by a given angle. **ScaleTransform** scales dimensions uniformly or independently per axis. Transforms are specified as part of Specific Resource descriptors in painting Annotations, and are applied in the order listed. |
| 75 | + |
| 76 | +#### 2.1.6. Add AnimationSelector for three-dimensional content |
| 77 | + |
| 78 | +The AnimationSelector enables referencing a named animation embedded within a 3D model resource. This supports interactive 3D content where specific animations are activated based on user interaction or scripted viewing sequences. |
| 79 | + |
| 80 | +#### 2.1.7. Add `interactionMode` for Containers |
| 81 | + |
| 82 | +The `interactionMode` property specifies how users are expected to interact with a Container's content. This is particularly relevant for Scene-based content where interaction models (guided tour, free exploration, and so on) differ substantially from the passive consumption of image or audio content. |
| 83 | + |
| 84 | +### 2.2. New and Revised Selectors |
| 85 | + |
| 86 | +#### 2.2.1. Add WktSelector for ISO standard geometries |
| 87 | + |
| 88 | +The WktSelector accepts Well-Known Text (WKT) geometry strings to identify regions within Canvases or positions within Scenes. It supports two-dimensional polygons and multipolygons as well as three-dimensional geometries, enabling precise and complex spatial selections that rectangular fragment identifiers cannot express. |
| 89 | + |
| 90 | +#### 2.2.2. Add AudioContentSelector and VisualContentSelector |
| 91 | + |
| 92 | +AudioContentSelector and VisualContentSelector select, respectively, only the audio or only the visual track from a combined audio-visual resource such as a video file. This enables, for example, painting only the audio component of a video file onto a Timeline, or presenting the visual component of a video independently of its audio. |
| 93 | + |
| 94 | +#### 2.2.3. Incorporate ImageApiSelector into the core specification |
| 95 | + |
| 96 | +The ImageApiSelector, previously defined as an extension, is incorporated into the core specification. It allows Specific Resources to reference an image through IIIF Image API parameters rather than a pre-formed URI, enabling resolution-independent and crop-aware image references. |
| 97 | + |
| 98 | +### 2.3. New Properties |
| 99 | + |
| 100 | +#### 2.3.1. Add `backgroundColor` on Containers |
| 101 | + |
| 102 | +The `backgroundColor` property specifies the background colour for a Container as a hex RGB value (e.g., `#ffffff`). Clients should render this colour behind any content painted onto the Container. This is useful when the background colour of an object is significant, such as an artwork customarily displayed against a particular ground, or a film that begins and ends on black. |
| 103 | + |
| 104 | +#### 2.3.2. Add `spatialScale` on Canvas |
| 105 | + |
| 106 | +The `spatialScale` property maps the coordinate units of a Canvas to real-world physical measurements using the new Quantity class. This enables publishers to express the actual physical dimensions of a depicted object, supporting applications such as on-screen measurement tools, comparison views across objects of different scales, and augmented-reality placement. |
| 107 | + |
| 108 | +#### 2.3.3. Add `provides` for accessibility feature declarations |
| 109 | + |
| 110 | +The `provides` property declares what accessibility features a resource makes available, such as subtitles, captions, audio description, or sign language. This allows clients to present this information to users and to make appropriate interface choices before a resource is loaded or rendered. |
| 111 | + |
| 112 | +#### 2.3.4. Incorporate `navPlace` into the core specification |
| 113 | + |
| 114 | +The `navPlace` property, previously available as a registered community extension, is incorporated into the core specification in version 4.0. It accepts GeoJSON Feature or Feature Collection values and enables geographic navigation interfaces for Collections and Manifests. This complements the existing `navDate` property, which serves the equivalent role for temporal navigation. |
| 115 | + |
| 116 | +#### 2.3.5. Add `fileSize` on content resources |
| 117 | + |
| 118 | +The `fileSize` property declares the size of a content resource in bytes. This allows clients to present file-size information to users before they choose to download or stream a resource, and to make informed decisions about network usage. |
| 119 | + |
| 120 | +### 2.4. Data Model Additions |
| 121 | + |
| 122 | +#### 2.4.1. Add the Quantity class for dimensioned numerical values |
| 123 | + |
| 124 | +The Quantity class pairs a numerical value (`quantityValue`) with a unit of measurement (`unit`). It is used by `spatialScale` and by other properties where a bare number is insufficient without knowing its unit. This avoids encoding unit information in property names and enables unambiguous machine processing of physical measurements. |
| 125 | + |
| 126 | +#### 2.4.2. Reintroduce Collection paging via Collection Page |
| 127 | + |
| 128 | +A Collection Page class, based on the Activity Streams paging model, enables large Collections to be distributed across multiple HTTP responses. Paging was removed from version 3.0 on the grounds that it was not implemented and was insufficiently specified. Version 4.0 reintroduces it with a clearer definition aligned with Activity Streams conventions. |
| 129 | + |
| 130 | +--- |
| 131 | + |
| 132 | +## 3. Editorial Changes |
| 133 | + |
| 134 | +### 3.1. Specification divided into two documents |
| 135 | + |
| 136 | +Version 4.0 is published across two documents: a main specification page covering the purpose, use cases, worked examples, and property-by-property definitions; and a separate data model page covering the formal class hierarchy, processing rules, embedding and referencing constraints, and technical requirements. This structure distinguishes practical guidance for publishers from the normative model for implementers, and follows the pattern established by other IIIF specifications. |
0 commit comments