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