You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a month of public testing and feedback, the IIIF Editors are pleased to announce second draft revisions of the International Image Interoperability Framework Image and Presentation (formerly 'Metadata') API specifications.
10
+
11
+
*[IIIF Image API 2.0.0-draft2](/api/image/2.0/)
12
+
*[IIIF Presentation API 2.0.0-draft2](/api/presentation/2.0/)
13
+
14
+
Since the release of the first drafts. a few significant changes have been made:
15
+
16
+
### Image API
17
+
18
+
* Added `services` to info.json [[Changes](https://github.com/IIIF/iiif.io/commit/801e9e1628f34c77001d2b151df8efb88e1c688a)\|[Discussion](https://groups.google.com/d/msg/iiif-discuss/4rp3OvK0jtI/Gow0pF45bMIJ)]
19
+
* Added mirroring option to rotation syntax [[Changes](https://github.com/IIIF/iiif.io/commit/93869af7e4fee290c044392e0858d1805cf26e80)\|[Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/J7u9cyKZKU4)]
20
+
* Added clarification of `default` quality [[Changes](https://github.com/IIIF/iiif.io/commit/dd54d7dfaf4bd2b5ade8b1ab16b8ada8687eb7bb)] and rotation/background [[Changes](https://github.com/IIIF/iiif.io/commit/b2d6bfe59bd3fdbe3147c88333d2c922f4caf1d6)\|[Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/AnXBvw_gVI0)]
* Clarified and cleanly separated information about support for tiles vs. support for preferred sizes in `info.json`[[Changes](https://github.com/IIIF/iiif.io/commit/15c8445403d8ed72f300f8a3da6de2ce05cc8475)\|[Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/YOAAcALqoAE)]
23
+
24
+
25
+
### Presentation API
26
+
27
+
* Added server side rotation option with iiif:ImageApiSelector[[Changes](https://github.com/IIIF/iiif.io/commit/f94fda233731b4140a922ee673f09fd2f04dc053)\|[Discussion](https://groups.google.com/forum/#!topic/iiif-discuss/k2Lu6INn5KM)]
28
+
* Improved JSON to RDF mapping [[Changes](https://github.com/IIIF/iiif.io/commit/522f1664f244d3a6f35b05db4d66a7833b9b6bd2)]
29
+
* Minor Clarifications:
30
+
* Cannot reference locations outside of a Canvas
31
+
* Reduced focus on presenting digitized physical objects
32
+
* Explicit definition of physical scale algorithm
33
+
34
+
As always, we welcome your feedback, questions, and use cases, and encourage you to submit them to the [IIIF Discussion Listserv](mailto:{{ site.data.organization.email }}). Drafts will be kept open for comment until the beginning of August, with the goal of final release in September. However, we would appreciate feedback early in order to work on and gain consensus for any necessary changes.
This document is a companion to the [IIIF Image API Specification, Version 2.0][api]. It describes the significant changes to the API since [Version 1.1][api-11]. The changes are broken into two groups: [Breaking Changes][breaking-changes], i.e. those that are not backwards compatible from either a client or server perspective (or both); and [Other Changes][other-changes], i.e. those that are backwards compatible. The latter group consists mostly of new features.
13
+
This document is a companion to the [IIIF Image API Specification, Version 2.0][api]. It describes the significant changes to the API since [Version 1.1][api-11]. The changes are broken into three groups: [Breaking Changes][breaking-changes], i.e. those that are not backwards compatible from either a client or server perspective (or both) and mostly consists of new features; [Other Changes][other-changes], i.e. those that are backwards compatible; and [Deferred Changes][deferred-changes], i.e. those that will be made in a future iteration of the Image API.
14
14
15
15
In addition to changes in the API, the specification documents have been changed as follows:
16
16
@@ -40,6 +40,11 @@ This is a response to several requests for the ability to describe the capabilit
40
40
41
41
The `qualities` and `formats` properties have been moved into the object referenced in `profile`.
42
42
43
+
### Added `tiles` property to Image Information document
44
+
45
+
A `tiles` property was added to the top level of the JSON in the Image Information document response. The rationale was to promote consistency between information about tiles (regions of an image at different sizes) and the different sizes available (see `sizes` below), to clarify that the `scale_factors` are related to tiles rather than the complete image, and to allow different tile sizes at different scale factors. The property is a list of JSON objects, with `height`, `width` and `scale_factors` properties. This change therefore renames `tile_height` and `tile_width`, and moves them along with `scale_factors` into the new structure. The `height` property is now optional, defaulting to the same as `width`. This makes the default of square tiles easier to record.
46
+
47
+
43
48
### Required <abbrtitle="Cross-Origin Resource Sharing">CORS</abbr> for level 1 Compliance
44
49
45
50
One of the core purposes--if not _the_ core purpose--of IIIF is to share images between institutions. This is is impossible without the ability to exchange images and metadata across different HTTP domains. CORS is the standard way to do this.
@@ -97,8 +102,9 @@ In order to provide the same extension point as is in the [Presentation API][pre
97
102
98
103
### Added `sizes` property to Image Information document
99
104
100
-
Servers that do not support arbitrary size parameters for image requests may still wish make multiple sizes of an image available. The sizes that are available may be listed using the `w,h` syntax in the `sizes` property. Even when a server does support arbitrary resizing, it may be useful to report pre-cached or otherwise recommended sizes of an image, e.g. thumbnails.
105
+
Servers that do not support arbitrary size parameters for image requests may still wish make multiple sizes of an image available. The sizes that are available may be listed using an array of JSON objects in the `sizes` property of the top level of the Image Information response. The object has `height`, `width` and `viewing_hint` properties. The `viewing_hint` property was added from the Presentation API to allow the server to provide a hint to the client about the intended use of the given image size, such as 'thumbnail' or 'icon'.
101
106
107
+
Even when a server does support arbitrary resizing, it may be useful to report pre-cached or otherwise recommended sizes of an image.
102
108
103
109
104
110
### Published JSON-LD Context
@@ -109,6 +115,19 @@ The [context document][context] for the `info.json` document was not published f
109
115
110
116
As transition to JSON-LD (since it is not fully supported by browsers), clients that favor the "application/ld+json" media type in the accept header of their request may receive this as the Content-Type of the response. Also note that it is recommended that the server include the context URI in a Link header of the response if the request was for for "application/json". See [Section 5][info-request] and the documents to which it links for further details.
111
117
118
+
### Background Color for non-90 degree Rotations
119
+
120
+
Clarified that clients should request image formats capable of transparent backgrounds when rotation is not a multiple of 90 degrees, and that servers should return transparent backgrounds for such images. For formats that do not support transparent backgrounds, no requirements are specified.
121
+
122
+
123
+
## Deferred Changes
124
+
125
+
### Add Rights Information
126
+
127
+
A proposal was made to add rights level information from the [Presentation API][prezi-api] to the Image Information response for images to avoid requiring support for both APIs just to give a license or attribution statement for the image. This change was deferred until the next version of the API to coincide with the introduction of Authentication and Authorization information, and to allow extra time to gather use cases and requirements.
128
+
129
+
130
+
112
131
[api-11]: /api/image/1.1/"Image API 1.1"
113
132
[api-compliance]: /api/image/2.0/#compliance-levels"Image API 6. Compliance Levels"
This document is a companion to the [IIIF Presentation API Specification, Version 2.0][prezi-api]. It describes the significant changes to the API since [Version 1.0][prezi-api-10]. The changes are broken into two groups: [Breaking Changes][breaking-changes], i.e. those that are not backwards compatible from either a client or server perspective (or both); [Other Changes][other-changes], i.e. those that are backwards compatible. A third section, [Deferred Proposals][deferred-proposals], lists proposals that have been discussed but did not make it into this version of the specification.
14
14
15
15
In addition to changes in the API, the specification documents have been changed as follows:
16
16
17
17
* The use of [RFC 2119 keywords][rfc-2119] has been made more consistent.
18
-
* Language has been adjusted to make the document less focused on paged objects.
18
+
* Language has been adjusted to make the document less focused on paged, digitized objects.
19
19
*[Semantic Versioning][semver] will be used to enumerate releases.
20
20
21
21
## Table of Contents
@@ -65,6 +65,10 @@ Several new fields were added:
65
65
66
66
In order to manage requests for features that are not universally applicable, but still useful, the service construction that was previously under-specified has been extended to allow additional external specifications to be embedded or referenced. Services are now listed in an annex document, and include the oft-discussed geo-tagging and physical dimensions features.
67
67
68
+
### Server-side Image Rotation Option
69
+
70
+
Added and described an Open Annotation Selector object that allows specifying the parameters for an Image API URI separately. The original use case was server side rotation of a segment image, however all of the parameters could be useful in different situations.
71
+
68
72
### Start Canvas
69
73
70
74
An additional value of `start` was added to the `viewing_hint` value enumeration, to be used on a canvas to assert that it's the one to be rendered to the user first, regardless of its position in the Sequence.
@@ -77,6 +81,10 @@ An additional value of `top` was added to the `viewing_hint` value enumeration,
77
81
78
82
In 1.0 it was not possible to add most of the fields to content resources. This was not for any good reason, and the restrictions were lifted.
79
83
84
+
### Extra-Canvas Coordinates
85
+
86
+
Clarified that any reference to a location outside of the dimensions of a Canvas is an error.
87
+
80
88
## Deferred Proposals
81
89
82
90
### Zones
@@ -93,16 +101,20 @@ Only canvases may list their annotations, and thus it is impossible to refer to
93
101
94
102
### Target Audience
95
103
96
-
Particularly in the teaching and learning domain, it may be useful to specify the intended audience of resources. For commentary annotations this is important, and not covered in the base Open Annotation specification. It was decided to defer this until the Open Annotation community can determine a resolution to be adopted, but to promote use cases and existing solutions such as the IDPF use of schema.org's Audience classes. Also, not backwards incompatible and no clients are ready to use it yet.
104
+
Particularly in the teaching and learning domain, it may be useful to specify the intended audience of resources. For commentary annotations this is important, and not covered in the base Open Annotation specification. It was decided to defer this until the Open Annotation community can determine a resolution to be adopted, but to promote use cases and existing solutions such as the IDPF use of schema.org's Audience classes. Also, it is backwards compatible and no clients are ready to use it yet.
97
105
98
106
### Compliance
99
107
100
-
The Image API has a very well formed set of compliance requirements. The Presentation API, conversely, does not have any. This was not seen as a requirement that needed to be solved for 2.0, and was deferred for future work.
108
+
The Image API has a very well formed set of compliance requirements. The Presentation API, conversely, does not have any. This was not seen as a requirement that needed to be solved for 2.0, and was deferred for future work.
101
109
102
110
### Explicit Protocol
103
111
104
112
The Image API in 2.0 has a protocol field that makes the assertion that the `info.json` document is part of the IIIF Image API protocol. The Presentation API does not have this field. There were no features or implementations identified that would make use of the field, and as it will be backwards compatible it was deferred until a requirement is expressed.
105
113
114
+
### Minimum/Maximum Size Bounds for Annotation Rendering
115
+
116
+
The content or commentary resources linked via annotations to a Canvas may be only useful to render at certain sizes, such as trying to render an image below 10 pixels width or text at less than 4 points. While theoretically useful, no real world use cases have been presented that would justify its inclusion. As a backwards compatible new feature, it was deferred until a requirement is expressed.
117
+
106
118
107
119
[api-11]: /api/image/1.1/"Image API 1.1"
108
120
[api-compliance]: /api/image/2.0/#compliance-levels"Image API 6. Compliance Levels"
0 commit comments