FAQ for IIIF and Linked (Open) Data

Living Document,

This version:
https://github.com/netwerk-digitaal-erfgoed/faq-for-iiif-and-lod/
Issue Tracking:
GitHub
Inline In Spec
Editors:
(Delft University of Technology)
(KB - national library)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 8 March 2024, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

This document lists frequently asked questions about IIIF and Linked (Open) Data with answers.

1. General

1.1. What is IIIF?

IIIF stands for International Image Interoperability Framework and is pronounced as "triple-eye-eff". The framework was established in 2011 by an international coalition of cultural heritage institutions, led by Stanford University Libraries and supported by the Andrew J. Mellon Foundation. In 2015 the IIIF Consortium was formed of 11 institutions including the British Library, La Bibliothèque nationale de France and the Bavarian State Library, which has since increased to 63 members worldwide. Dutch members include Leiden University Libraries and the National Library of the Netherlands. The IIIF Community actively maintains the standards, shares best practices, and discusses expansions in various groups, committees and at an annual conference.

IIIF has been developed in response to the lack of interoperability between the various interfaces used for the public presentation of digital collections. Institutions have often implemented custom solutions to connect backend to frontend, and have developed their own software for displaying digital objects. Think for example of the different search interfaces and viewers used among cultural heritage institutions. This status quo made it difficult to share codebases, gear user experiences to one another and to promote reuse of digital collections on other (thematic or aggregate) platforms. IIIF addresses this situation by standardizing access to image data (with the IIIF Image API) and metadata (with the IIIF Presentation API). In this document we’ll be referencing the latest stable versions of both API’s: version 3.0.

IIIF does not prescribe any particular software, but determines how different pieces of software communicate with each other. If this communication is standardized across institutions, custom implementations can be shared and further developed collectively. When the APIs are advertised as a public service, they can be used by individual users to open and edit objects in alternative tools or viewers; by aggregate platforms to thematically collect and present objects across collections, or by developers to build specialized software for certain types of objects such as manuscripts or maps.

1.2. What is the difference between IIIF and PDFs?

Dit kan eventueel verplaatst worden naar What is the relationship between the IIIF Image and Presentation APIs?

The structure of a IIIF Presentation Manifest can be compared to a PDF. A PDF includes one or more pages that can contain multiple objects (such as text and images) and layers (such as an OCR layer on top of scanned text). In addition to that, it can contain a table of contents and different types of annotations.

All this information (and more) can be included in a IIIF Presentation Manifest as well. A page is called a canvas, and everything that is placed on this canvas is called an annotation. Annotations have different motivations (such as painting or describing), which tells viewers how to display this information. A table of contents consists of different ranges in a IIIF Manifest.

An important distinction is that while a PDF contains all this information in a single file format, IIIF consists of different parts that can each be loaded and referenced individually when needed. This is much more friendly for building web interfaces and working with high resolution files while following linked open data standards.

From the data encoded in a IIIF Manifest, a PDF can be generated on the fly, as is demonstrated by the online pdiiif application. Conversely, it is difficult to extract source data from a PDF without losing information.

1.3. Why do I need IIIF?

TODO vergelijkingen met PDFs kunnen eventueel weg

IIIF is a set of standards and APIs designed to provide a consistent and interoperable way of delivering, navigating, and manipulating digital images across different platforms and institutions. Implementing IIIF offers several benefits, listed below, that can enhance the accessibility, usability, and discoverability of your digital collections. In relation to the previous question, key advantages of using IIIF over PDFs are added in italics.

1.4. Is IIIF part of the DERA?

The Dutch digital heritage reference architecture (DERA) defines a Data Platform as a group of components that ensures the availability of heritage information from a source holder and its enrichment with heritage information from other Data Platforms. The Data Platform is the place where customers (in particular Service Platforms) can find the data published by or on behalf of a source holder.

A Data Platform has functions for retrieving information from a Management Platform and integrating this information. In addition, it may have functions for obtaining enrichments from other Data Platforms, making them part of the information in the Management Platform. Furthermore, it has functions for publishing information via application interfaces so that it can be used by customers.

A Data Platform falls under the responsibility of a source holder. A Data Platform can stand alone in the technical realization or form a whole with a Management Platform. Examples of systems that realize (part of) a Data Platform are a triplestore and a IIIF Image Server.

The application interfaces of the Data Platform, including IIIF, are covered by the agreements in DERA. These interfaces are part of jointly increasing the findability of heritage information.

2. Application Programming Interfaces (APIs)

2.1. What is the relationship between the IIIF Image and Presentation APIs?

The Image API and Presentation API, two of the most central components within IIIF, work together to create a seamless viewing experience. The Presentation API provides the context and structure for the images, while the Image API handles the delivery and manipulation of image content. In a typical IIIF viewer, the Presentation API manifest is loaded first, and the viewer uses the information contained in the manifest to request the appropriate images from the Image API.

An overview of the relationship between the two:

2.2. How does the IIIF Image API compare to web maps?

The working of the IIIF Image API can be compared to web maps. When users open a world map on a device (such as Open Street Map), they see a tiny part of a gigantic image. This image is sliced into square parts, named tiles, which are created for different zoom levels (and are often differentiated for each level). Based on the viewport of the user’s device, only the necessary tiles are loaded, and stitched together (this explains the loading of maps in a chessboard pattern). While map webs work with a geographic coordinate system, the IIIF Image API uses the cartesian coordinate system of the pixels in the image.

2.3. Can I also publish collections with IIIF?

TODO describe howto publish collections with IIIF

2.4. Can I include other representations than IIIF Images in a IIIF Manifest?

Yes, representations which can be included in a IIIF Manifest include IIIF images, audio, and video, as well as non-IIIF 3D and PDF. Beware that viewers might not have the ability to show all representations.

2.5. What is the structure of a IIIF manifest?

A IIIF manifest is a [JSON-LD] document that describes the structure and metadata of a digital object or collection of objects, such as images, audio, or video. It is based on the IIIF Presentation API and comprises several key components, including pages, canvases, table of contents (ranges), and annotations. Here’s an overview of how these components fit together in a typical IIIF manifest:
Here’s a simple example of an IIIF manifest in JSON-LD format. This example represents a single-image object with basic metadata and a single canvas using the Presentation API 3.0: 
{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "https://example.org/iiif/manifest/123",
  "type": "Manifest",
  "label": {
    "en": ["Example IIIF Manifest"]
  },
  "description": {
    "en": ["This is a simple example of an IIIF manifest."]
  },
  "metadata": [
    {
      "label": {"en": ["Title"]},
      "value": {"en": ["Example Image"]}
    },
    {
      "label": {"en": ["Date"]},
      "value": {"en": ["2023"]}
    }
  ],
  "items": [
    {
      "id": "https://example.org/iiif/manifest/123/canvas/p1",
      "type": "Canvas",
      "label": {
        "en": ["Example Image Canvas"]
      },
      "height": 2000,
      "width": 1500,
      "items": [
        {
          "id": "https://example.org/iiif/manifest/123/canvas/p1/annotation_page/1",
          "type": "AnnotationPage",
          "items": [
            {
              "id": "https://example.org/iiif/manifest/123/canvas/p1/annotation/1",
              "type": "Annotation",
              "motivation": "painting",
              "body": {
                "id": "https://example.org/iiif/image/123/full/max/0/default.jpg",
                "type": "Image",
                "format": "image/jpeg",
                "height": 2000,
                "width": 1500,
                "service": [
                  {
                    "id": "https://example.org/iiif/image/123",
                    "type": "ImageService3",
                    "profile": "level1"
                  }
                ]
              },
              "target": "https://example.org/iiif/manifest/123/canvas/p1"
            }
          ]
        }
      ]
    }
  ],
  "thumbnail": [
    {
      "id": "https://example.org/iiif/image/123/full/150,/0/default.jpg",
      "type": "Image",
      "format": "image/jpeg",
      "height": 200,
      "width": 150
    }
  ],
  "viewingDirection": "left-to-right",
  "behavior": ["paged"]
}

2.6. How can I annotate IIIF resources?

TODO describe howto annotate IIIF resources

Each Canvas in a IIIF Manifest can include an Annotation Page consisting of Web Annotations with information from or about the Canvas, which is not immediately rendered visible by clients, as explained under What is the structure of a IIIF manifest?. These can include transcriptions (from OCR/HTR data), comments, tags, temporal or geographical information, and more. The annotations can be both referenced (linked) or embedded (included) as part of the Canvas. For OCR/HTR-data, for example, referencing is often preferred, to limit the size of the manifest. When needed, clients can then resolve the Web Annotation and process the data.

While referenced or embedded annotations are published as part of a IIIF Manifest, similar Annotations can also be created externally. An individual user might recognise a person in a photograph and would like to share this finding with the providing institution. Researchers processing large corpusses of archival data using the IIIF APIs might want to publish the results of their pipeline in an open format to “give back” to providing institutions. Crowdsourcing projects can make use of external tools that need to temporarily store the collected data in a format preserving the links to the original digital object. For all of these use cases, external Web Annotations are suited that reference the corresponding Canvases and, if needed, Manifests.

Supporting external Web Annotations hugely increases the reusability and potential enrichment of digital collections, but requires additional attention to identifiers and processing workflows for externally generated data:

An external Web Annotation will reference a specific canvas by using its id property containing an HTTP(S) URI. If the canvas does not resolve, the Annotation can reference the Manifest’s id as well. When one of those identifiers change, the Manifest does not resolve or the Canvas cannot be located within the Manifest. Thus the relationship between the external Web Annotation and the digital object will break. Maintaining a stable URI structure for IIIF Manifests and their components such as Canvasses is therefore important. Resolvable Canvases, although not required by the IIIF specifications, are recommended to accommodate external Annotations. In general, the Image API endpoints are not seen as stable identifiers by IIIF, as their structure often changes as a result of software updates or API changes (in fact, an institution might offer different endpoints for the same image, each conforming to a different version of the Image API). As exemplified by the use cases, institutions may provide a way for external parties to submit or propose Web Annotations that have been created by them. Institutions could provide documentation about the preferred process for submitting external Web Annotations, and might go as far as setting up an Annotation Server that is open to third party use.

TODO list different types of annotations and tools that can be used

2.7. What is the structure of an info.json as defined in the Image API?

The info.json file is a JSON document that provides essential information about an image served by a IIIF Image API-compliant server. It contains metadata and technical details about the image, such as dimensions, formats, quality, and available transformations. The info.json file is generated by the IIIF Image API server and is typically requested by a IIIF-compatible viewer or other client applications when they need to access or manipulate an image.

Here is an overview of the main components of a typical info.json file:

Here’s an example of a simple info.json file: 
{
  "@context": "http://iiif.io/api/image/2/context.json",
  "@id": "http://example.com/iiif/image/12345",
  "protocol": "http://iiif.io/api/image",
  "width": 6000,
  "height": 4000,
  "tiles": [
    {
      "width": 512,
      "scaleFactors": [1, 2, 4, 8, 16]
    }
  ],
  "profile": [
    "http://iiif.io/api/image/2/level2.json",
    {
      "formats": ["jpg", "png"],
      "qualities": ["default", "gray", "bitonal"],
      "supports": ["regionByPx", "sizeByW", "rotationBy90s", "mirroring", "gray"]
    }
  ]
}

2.8. Can I use IIIF to offer full-text search?

Yes, you can use IIIF to offer full-text search for your digital objects. While IIIF itself does not provide a built-in search mechanism, it supports the integration of full-text search through the (IIIF Content Search API][https://iiif.io/api/search/2.0/], which is another API next to the Presentation and Image APIs.

The IIIF Content Search API is designed to facilitate searching within digital objects, such as searching for text within digitized books or manuscripts. It provides a standardized way to request and retrieve annotations associated with the digital object. In the context of full-text search, these annotations typically contain textual transcriptions or OCR-generated text, along with the coordinates of the text on the corresponding image.

To implement full-text search using IIIF, you will need to do the following:

  1. Prepare your textual data: Transcribe or OCR your images to create text representations of the content. The text should be associated with the appropriate regions in the images, usually using the Web Annotation Data Model.

  2. Create a search service: Develop a search service that indexes your textual annotations and provides an API for querying the index. This service should implement the IIIF Content Search API specification, which defines the request and response formats for searching within annotations.

  3. Link the search service to your IIIF manifest: In your IIIF Presentation API manifest, include a reference to your search service using the "service" property on the appropriate level (manifest, sequence, or canvas). This will allow IIIF viewers to discover and interact with your search service.

  4. Use a IIIF viewer with search capabilities: Ensure that your IIIF viewer supports the Content Search API and can display search results, highlighting the matching text regions within the images.

Implementing IIIF can raise copyright concerns, as making digital content accessible to a wider audience may involve displaying copyrighted materials. To address these concerns, you can take several steps - organizational and technical - to ensure you are respecting copyright and other intellectual property rights while implementing IIIF:

  1. Understand the copyright status of your content: Determine the copyright status of the materials you plan to make available via IIIF. This may involve researching the creators, publication dates, and any existing licenses or agreements. Remember that copyright laws and terms can vary by country, so it’s essential to be aware of the regulations that apply to your specific location and collections.

  2. Obtain permissions when necessary: If you identify copyrighted materials within your collections, seek permission from the copyright holders to display and share the content via IIIF. This may involve reaching out to individual creators, publishers, or rights management organizations.

  3. Use access controls: Implement access control mechanisms to limit access to copyrighted materials, if necessary. IIIF supports access control through the IIIF Authentication API, which allows you to define access restrictions based on user authentication and authorization. This way, you can limit access to copyrighted content to specific user groups or individuals, ensuring that only authorized users can view the restricted materials.

  4. Apply appropriate licenses and rights statements: Clearly communicate the copyright status, usage restrictions, and licensing information for your digital content. You can include rights statements and licensing information in your IIIF Manifest using the "rights" property or the "metadata" section. This helps users understand how they can use and share the materials legally and responsibly.

  5. Use a IIIF viewer that respects copyright restrictions: Choose a IIIF viewer that supports access control mechanisms and displays rights statements and licensing information to users. This ensures that users are aware of the copyright status of the content and any restrictions on its use.

2.10. How can machines discover my IIIF manifests?

TODO describe/link IIIF Change Discovery API 1.0

Machines can discover IIIF manifests through several methods, which often involve exposing the manifests in a way that conforms to web standards and best practices. Here are some common approaches to enable machine discoverability of IIIF manifests:

<head>
<link rel="alternate" type="application/ld+json" href="https://example.org/iiif/manifest/123" />
</head>

{
  "@id": "https://example.org/object/123",
  "http://purl.org/dc/terms/hasFormat": {
    "@id": "https://example.org/iiif/manifest/123"
  }
}

The section How to reference IIIF manifests and images in linked data elaborates on the publishing part.

2.11. What about IIIF and CORS?

Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers to prevent unauthorized access to resources from different domains. CORS is relevant to IIIF because IIIF resources, such as images or manifests, may be hosted on different domains than the IIIF viewers or client applications that request them.

To ensure that IIIF resources can be accessed by viewers and applications across different domains, IIIF servers must be configured to include appropriate CORS headers in their HTTP responses. These headers inform browsers that the resources can be accessed by client applications on other domains, allowing the browser to display the resources without triggering security restrictions.

For IIIF Image API and IIIF Presentation API servers, the following CORS headers should be configured:

3. Linked (Open) Data

3.1. What’s the relationship between IIIF and Linked Data?

IIIF and Linked Data both aim to promote the accessibility and interoperability of digital resources across various platforms and institutions. While IIIF focuses on providing a standardized framework for delivering, navigating, and manipulating digital images, Linked Data is a more general approach to structuring and connecting information on the web. In fact, IIIF can be seen as an example of Linked Data. Despite their different scopes, IIIF and Linked Data share some common principles and are related in several ways:

3.2. How to add semantic metadata to a IIIF manifest?

The primary purpose of a IIIF manifest is to describe the structure and presentation of images and their associated resources. It is not designed to store or manage detailed semantic metadata about the content of the images. The focus is on interoperability and ensuring that images can be easily displayed and navigated in a variety of viewing environments. The aim of the label and metadata properties contained in a IIIF manifest is the presentation to end users; not machine processing. The only semantics it contains are language codes.

TODO see/incorporate https://iiif.io/api/presentation/3.0/#11-objectives-and-scope https://iiif.io/api/presentation/3.0/#metadata https://iiif.io/api/presentation/3.0/#language-of-property-values

However, IIIF does support linking to external resources that may contain semantic metadata. In a IIIF manifest, you can include links to other descriptive resources like metadata records, annotation lists, or external vocabularies using the seeAlso property. This allows institutions to maintain and manage their semantic metadata separately from the IIIF manifest, while still making it accessible and discoverable in the context of the images.

To reference semantic metadata in a IIIF Manifest, you can add a "seeAlso" property to the appropriate level in the manifest (e.g., manifest, sequence, or canvas), and provide the necessary details, such as the URL of the external resource, its format (using a [IANA-MEDIA-TYPES]), and an optional label to describe the relationship between the manifest and the external resource.

Here’s an example of how to include a "seeAlso" property in a IIIF Manifest: 
{
  "@context": "http://iiif.io/api/presentation/3/context.json",
  "id": "http://example.org/iiif/book1/manifest",
  "type": "Manifest",
  ...
  "seeAlso": [
    {
      "id": "http://example.org/iiif/book1/metadata",
      "type": "Dataset",
      "format": "application/json",
      "profile": "http://example.org/profiles/bibliographic",
      "label": {
        "en": ["Bibliographic Metadata"]
      }
    }
  ],
  ...
}

3.3. How to reference IIIF Manifests and media in linked data?

Referencing a IIIF Manifest in your linked data is usually not applicable, as the preferred way to make an IIIF Manifest is to get this from the meta-data in your linked data. Referencing media in your linked data is applicable, because then we’re dealing with the Image API which usually is a separate infrastructure component.

When referencing the Image API it is important to realize that an API is more than an image. You can reference an image, by crafting a specific Image API URL to request the full image. It’s better to inform the client that media is available via the Image API, so specify the URL with which information about the media can be requested (eg. info.json) and the protocol version in which the API is available.

The only two Linked Data schemas with specific guides for referencing IIIF Images are currently the Europeana Data Model (EDM) and Linked Art. For EDM, see Classes for EDM; for Linked Art please refer to the IIIF section of Digital Integration. These pages include the preferred methods for linking to IIIF Images and/or manifest. In addition, the Wikidata property P6108 exists for a IIIF Manifest URL.

For schema.org, the following modeling has been suggested: 
{
"@context": "https://schema.org",
"@type": "ImageObject",
"contentUrl": "https://maior-images.memorix.nl/sad/iiif/536423ef-c3be-f119-467c-a3a183cff3de/full/max/0/default.jpg",
"encodingFormat": "https://iiif.io/api/image/"
}
For schema.org, the following modeling has been suggested: 
{
"@context": "https://schema.org",
"@type": "ImageObject",
"contentUrl": "https://athenaeumcollecties.nl/atlassen-en-kaarten/detail/0bbe6ed8-3487-11e6-accc-378756137f8c/media/de918663-c0eb-7bc7-0cbb-b23180fcc623",
"encodingFormat": "https://iiif.io/api/presentation/"
}

With Linked.Art yhe IIIF Presentation API is considered to be a DigitalObject that is about the object, in the same way as the homepage of the object in a collection information system. The property used to refer to it from the object is, thus, subject_of. The conformsTo property should also be used with the Presentation API URI, and the Digital Object can also be given a format for JSON-LD.

For example: 
{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "https://linked.art/example/object/34",
  "type": "HumanMadeObject",
  "_label": "Painting",
  "classified_as": [
    {
      "id": "http://vocab.getty.edu/aat/300033618",
      "type": "Type",
      "_label": "Painting",
      "classified_as": [
        {
          "id": "http://vocab.getty.edu/aat/300435443",
          "type": "Type",
          "_label": "Type of Work"
        }
      ]
    },
    {
      "id": "http://vocab.getty.edu/aat/300133025",
      "type": "Type",
      "_label": "Artwork"
    }
  ],
  "subject_of": [
    {
      "id": "http://iiif.example.org/presentation/1/manifest.json",
      "type": "DigitalObject",
      "format": "application/ld+json;profile=\"http://iiif.io/api/presentation/3/context.json\"",
      "conforms_to": [
        {
          "id": "http://iiif.io/api/presentation",
          "type": "InformationObject"
        }
      ]
    }
  ]
}

Institutions have used custom solutions to reference IIIF Manifests and Images as part of MODS, METS and MARC standards of the Library of Congress.

4. Software

4.1. Which viewers can I use once I have implemented IIIF?

Once you have implemented IIIF, there are several popular IIIF-compatible viewers that you can use to display and interact with your digital images. These viewers support the IIIF Presentation API and Image API, offering a range of features for navigating, zooming, and annotating digital objects. Some widely used IIIF viewers include:

4.2. Which tools can I use to edit and enrich manifests?

If you opt for manually creating manifests and not the preferred pipeline from linked data, there are several manifest editors available, each with varying features and capabilities. Some popular manifest editors include:

5. Implementation

5.1. How can I create Image API endpoints for my images?

In most cases, a dynamic server is used to create IIIF Image API endpoints for a collection of images. This server processes the requests and converts the original image into derivatives with the requested parameters such as size, rotation, format and region. Servers can preprocess images by generating image pyramids and tilesets for different scales, to speed up delivery. The Image Information response provides, next to basic information about the image, a list of thumbnails and tilesets that have been preprocessed or cached on the server and will thus yield a swift response for clients. In addition it tells clients which operations are supported by the server. The Image Information response is thus generated by the image server.

The IIIF website lists some compatible server software in different languages and up-to-date information about pyramidal image formats can be found in the article Evaluating HTJ2K as a Drop-In Replacement for JPEG2000 with IIIF. Some image servers support different tile layouts such as DeepZoom or Zoomify next to IIIF.

It’s also possible to generate static tilesets, thumbnails and an Image Information response without the need for a dynamic server. These are sometimes indicated as Level 0 images, referring to the Image API compliance specification. Many image processing tools can be used to generate static tiles; examples are) [IIIF Tiler](https://github.com/glenrobson/iiif-tiler (Java) or Sharp (Node.js). For a serverless implementation with higher compliance levels, please refer to Serverless IIIF.

5.2. How can I generate manifests for my images, collections, .. ?

A IIIF Manifest contains, among other things, descriptive metadata about the image. Usually this metadata is available within your collection (or content) management system. This means a manifest can be made up - pre-processed or dynamically - from already available data, just "reformatted" conforming to the IIIF Presentation API specification.

When you have your data available in a triplestore, a [SPARQL11-OVERVIEW] Construct in combination with [[json-ld11-framing]) could be used to create the manifest from your linked data. A SPARQL Construct creates a graph which can be represented as JSON-LD. But the contents need to be shaped to conform to the format required by the IIIF Presentation API, including the addition of the right @context.

This approach is nicely show-cased by Triply in the article IIIF support in TriplyDB and can be generalized to other solutions.

Importantly, Triply’s example does not make use of the IIF Image API and has hard-coded some specific information about the image in the SPARQL query such as its dimensions and format. In order to include a canvas containing a IIIF Image, the triplestore needs to include information about each individual image (most importantly its dimensions, to create the canvas) and about the image server. Alternatively, this information can be requested for each individual image by requesting the Image Information responses and processing those as part of the query. This will slow down the query and should not be used to create manifests ‘on the fly’ but could nevertheless be used to create static manifests at a fixed interval.

TODO see/incorporate https://iiif.io/api/presentation/3.0/#57-content-resources

For viewers to quickly process IIIF Manifests, the info.json response can be fully embedded as part of the service property.

See: https://iiif.io/api/presentation/3.0/#57-content-resources

Creating a IIIF manifest from your heritage metadata involves understanding your metadata, familiarizing yourself with the IIIF Presentation API, mapping the metadata to IIIF properties, creating a JSON-LD document, validating the manifest, hosting it on a web server, and integrating it with a IIIF viewer. This process enables you to leverage the benefits of IIIF for presenting and sharing your heritage metadata in a consistent and interoperable manner.

5.3. Can I offer PDF downloads to users?

PDFs can be generated on the basis of a IIIF Presentation Manifest.

5.4. What do I need to ask my supplier in order to implement IIIF?

When discussing IIIF implementation with a supplier, you will want to ensure that they have the necessary expertise, infrastructure, and capabilities to support the IIIF standards and provide a seamless viewing experience for your digital collections. Here are some key questions to ask your supplier to help you evaluate their IIIF readiness:

5.5. Which suppliers support IIIF?

The following table shows several Collection Management Systems and image servers and their self reported support of IIIF APIs. Specific compliance levels are not stated.
Software (supplier) IIIF Presentation API IIIF Image API
Atlantis (DEVENTit) 2/3 2/3
Axiell Collections (Axiell)
Cantaloupe n/a 2/3
ContentDM (OCLC) V V
IIP n/a 2/3
MAIS (DE REE archiefsystemen)
Memorix Maior (Vitec) 3 2
Memorix Nexus (Vitec) 3 3
Omeka S (open source) 2/3 2/3
KLEKSI

5.6. How can I test my IIIF manifest?

Testing your IIIF manifest is an essential step to ensure that it is properly formatted, contains valid data, and works as expected with IIIF-compatible viewers. To test your IIIF manifest, you can use the following tools and methods:

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

Informative References

[IANA-MEDIA-TYPES]
Media Types. URL: https://www.iana.org/assignments/media-types/
[JSON-LD]
Manu Sporny; Gregg Kellogg; Markus Lanthaler. JSON-LD 1.0. 3 November 2020. REC. URL: https://www.w3.org/TR/json-ld/
[N-TRIPLES]
Gavin Carothers; Andy Seaborne. RDF 1.1 N-Triples. URL: https://w3c.github.io/rdf-n-triples/spec/
[RDF-CONCEPTS]
Graham Klyne; Jeremy Carroll. Resource Description Framework (RDF): Concepts and Abstract Syntax. URL: https://w3c.github.io/rdf-concepts/spec/
[SPARQL11-OVERVIEW]
The W3C SPARQL Working Group. SPARQL 1.1 Overview. 21 March 2013. REC. URL: https://www.w3.org/TR/sparql11-overview/
[Turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. URL: https://w3c.github.io/rdf-turtle/spec/

Issues Index

TODO vergelijkingen met PDFs kunnen eventueel weg ↵
TODO describe howto publish collections with IIIF ↵
TODO describe howto annotate IIIF resources ↵
TODO list different types of annotations and tools that can be used ↵
TODO describe/link IIIF Change Discovery API 1.0 ↵
TODO see/incorporate https://iiif.io/api/presentation/3.0/#11-objectives-and-scope https://iiif.io/api/presentation/3.0/#metadata https://iiif.io/api/presentation/3.0/#language-of-property-values ↵
TODO see/incorporate https://iiif.io/api/presentation/3.0/#57-content-resources ↵