IIIF manifest import

Omeka S
1

To the developers, what’s the status of incorporating ability to import an object (metadata+images) via IIIF manifest?

In the use case of posting an image/document to archive.org, which is completely free and gives you a full IIIF manifest (the only service I’ve found that enables this), they actually don’t generate the info.json files at the image level (as far as I’ve explored within the manifest). So even if I parsed the manifest into its subsequent canvases, there is no IIIF image link to use. Of course, I could go directly to the default.jpg link - but it’s very clunky - the intention of IIIF is to enable portability right?

To the community, has anyone done any work on this, have any modules or workflows around this?

–
Ben Bakelaar
edison.rutgers.edu (Omeka-S)
metascripta.org (Omeka-S)

2 Likes
2

Typically something using the IIIF manifest “Presentation API” system also implements the full Image API, with info.json files and all. This might be a requirement of the spec, though I’d have to check to be sure.

Just taking a random archive.org image as an example: the image with a manifest at https://iiif.archivelab.org/iiif/C-1996-484/manifest.json does seem to have an Image API “info” file as well, at https://iiif.archivelab.org/iiif/C-1996-484/info.json.

As for importing the whole manifest, the Omeka S core at this point only supports the Image API. I believe there are several modules that can display IIIF manifests (the Universal Viewer is one, I think?) but I don’t know too much about them.

1 Like
3

Ahh OK I see, they don’t actually link the info.json file in the manifest, but you can retrieve it if you just append info.json to the root canvas ID.

So it sounds like a new “IIIF Import” module would be required in order to enable manifest import functionality which automatically parses the manifest.json, extracts the metadata into a new item, and then imports each image via the canvas ID/info.json file. Do any other projects or institutions have interest in this? Any developers out there that would like to price this?

To me, it seems like an obvious functionality to include. It feels very clunky to have to deconstruct a manifest into its individual images (canvases) and import the info.json one by one.

1 Like
4

There’s definitely interest around… really all axes of interoperability with the various IIIF standards.

I know some modules and projects work with manifests but I’m not sure I have anything to point to. Simply displaying the manifest by using Mirador/etc., optionally importing some metadata as well, is one option that’s probably relatively simple. Again, there are some existing modules that do at least some of this.

Parsing the manifest and looking for Image API links within and importing the whole thing as an item with IIIF Image media attached: that’s also a good idea, but you’re of course discarding some of what might be in a more complex manifest if you go that route. I’m not sure if there are modules out there that do this.

1 Like
5

Is it really necessary / desirable to import an IIIF manifest (or info.json)?
Would’t you rather just store the manifest (or info.json) link and use this external info from the source in Omeka-S for presentation. In this case there’s no need to copy data & images, you just rely on the external iiif/image server, the source!

1 Like
6

加入外部iiif.json的功能是有的，好像是在universalviewer中指定一个字段，在都柏林的相应字段中输入iiif.json地址就可以在前台展示。唯一的缺点是不会自动生成所缩略图

7

@coret in concept yes that’s great, but Omeka-S has no way to display the metadata contained in the IIIF manifest, or to make that metadata searchable.

In our use case, we have uploaded copies of large PDFs (of microfilm scans) to Archive.org. I think to clarify my original post, what we would want is to 1) import the metadata, 2) import the THUMBNAIL image into Omeka-S, and then 3) display the IIIF object in a viewer on the item show page.

1 Like
8

Hi, sorry for the off-topic question, how can I find the “info” file from the image API?

I am missing this step as I am also finding a problem with an IIIF manifest.

Thank you.

9

This is in the items or structure section of the iiif manifest, but the simplest way to find one is to open the development tools of your browser (ctrl+shift+i) and to check the network for xhr requests.

10

(
To reduce the off-topic chatter, Matteo and I DMed, but for the sake of searchability, here’s the upshot:

There’s a tool out there for finding image URLs, though it’s buried a bit in some IIIF training: Finding Images in Manifests

Before pasting a IIIF URL exposed by that tool into Omeka, it may need info.json (or /info.json as the case may be) added to the end
)

2 Likes
11

I would like to join the discussion here because I ultimately found the following:

When creating a media of type IIIF URL and specifying the external URL, I noticed that Omeka S downloads the image in the background and creates the derivatives locally. I assumed that the IIIF images are not downloaded, but only linked to the content provider. Why is this not the case?

Sure, if the content provider no longer offers the image, I don’t get that in Omeka itself. But the exchange of images is the charm of IIIF.
Maybe there should be an option in Omeka: Save image locally or link. That would be a good possibility.

12

Omeka S downloads the image for a “IIIF image” media just for the purpose of making thumbnails. The “original” that the thumbnails are produced from is not retained, and when you view the media with the embedded panning/zooming viewer, that’s using the remote IIIF image server directly, not using any local copies or thumbnails.

The thumbnails are only used to have something to present in browse pages and so on.

1 Like
13

And how does Omeka behave when the external source changes? Is the thumbnail then also created again automatically?

14

If the image at a particular IIIF Image API URL changes, the “live” rendering when embedding the media would update to match, since it’s just directly contacting the remote server.

The thumbnails would remain as they were first generated. Not all IIIF image servers support the same set of resizing and cropping operations, so we really can’t rely on them directly to get the thumbnail. Plus, the Omeka S thumbnail system just runs on stored thumbnails and has no provision for them to be dynamic in this way.

I don’t know that this is a really realistic scenario, though; almost every IIIF image URL I’ve ever seen is based on the name of an underlying file or otherwise a unique identifier. A change that meaningfully alters the image such that it would require a new thumbnail but that also retains the same URL feels unlikely.

1 Like
15

I know that I jump in this discussion quit in late, but I think the original topic here is really interesting and important. We would definitely need a module to import metadata via IIIF manifests.This module should help staff to get metadata in through a kind of format-crosswalk configuration tool.

17

I will just note as a change relevant to the conversation as a whole: Omeka S 4.0.0 added some simple support for ingesting and displaying IIIF presentation manifests as media, in addition to the previous support that was only for the image API. Institutions seem more likely to expose presentation manifest URLs than Image API info.json ones nowadays, so even on that simple level this can represent and improved experience (and of course also allows for things like a single Omeka S media that points to and shows a series of related images that are in a single manifest).

This isn’t an “importer” but will display some metadata through Mirador.

1 Like
18

Given the thread, could you expand a bit on the IIIF Presentation manifest ingestion not being an importer? I think I saw some implications over at the Sandbox just now (e.g. it doesn’t seem to generate a thumbnail), but I’d like to hear more.

(As a side note, this explains why entering a manifest URI into the IIIF Image type media add never worked. It was not clear to me, even working frequently with IIIF, that the “Image” used there was used in its IIIF-specific sense rather than in a conventional sense.)

19

As I see it, there are several use cases for IIIF objects in Omeka.

For purposes of preservation and stability, many faculty, scholars, and project leaders may be interested in using Archive.org to host previously unpublished materials. If you go “archive first”, rather than “archive as a backup”, then all of your materials / collection are in Archive.org, but lost in a sea of other things (sure you can make a collection page too).

In this case, let’s say you wanted to create a search and discovery interface for this collection, which has been published to Archive.org - then, the IIIF import with both metadata + images is desirable. Of course, you’d probably want to then add additional metadata to the objects in Omeka-S, which is not part of the manifest.

2nd scenario, if you are publishing your “primary” digital objects within your Omeka installation, perhaps you will have a spreadsheet with metadata about each object, which is easily imported and can include a IIIF manifest link, which then allows viewing of the document in Mirador or UniversalViewer. You still get the benefit of scenario #1, and you don’t have to take up (potentially lots of) hard drive space locally.

3rd scenario is that you fully publish metadata + images in Omeka, but have an “alternate version” pointed to Archive.org. In this case, you could also install the IIIF Image Server module and display the images with a document viewer + serve the Omeka-based IIIF object out to the public - but if you are working with high resolution images or very large files, it may be desirable to let Archive.org handle the IIIF functionality.

Particularly when dealing with unpublished scholarly collections which are not part of the library repository, aka many digital humanities projects, I think an Archive.org-first solution is best, with an understanding that the Omeka-S site may have a lifespan of ~5 years as opposed to 10+ unless there is funding to maintain it.

Overall, academic / university IT are becoming much stricter about security and maintenance, unlike prior generations of instances, installations, and custom web apps that could sit on servers for 10+ years without updates.

1 Like
21

This is a very interesting question indeed.
@jflatnes, I liked very much the new capabilities brought by the new 4.0.x version of Omeka S, but I also think a more advanced integration of external IIIF manifest sources should be done, giving to Omeka S an even more significant role in the “Digital Asset Management market”.
I particularly appreciated the clear overview exposed by @benbakelaar and I find the three scenarios very consistent and a very good way to explain three of the most important use of Omeka S in conjanction with third party systems that can be viewed as complementary.
That’s my specific case. I work in OCLC and I develop projects with CONTENTdm, that’s a very good Digital Library tool to create and manage digital collections.
Some libraries that use Cdm, also like to use Omeka S for its degital exhibition capabilities.
I think this is a quite common situation ad a growing need, like le first scenario represented by @benbakelaar.

At the moment, I decided to maintain the usage of “IIIF Image as a media”, because this way I’m still able to use derivative images to build exhibition, that is not possible with the “IIIF manifest as a media”.
Then I take advantage of the Mirador module to access the original digital objects as a whole trough the IIIF Manifest stored in a specific metadata of the item (tipically dcterms:hasVersion).

Hope this contribution can help this interesting discussion.

1 Like
22

This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.