ability to pass in only IIIF manifest into IIIF-Mirador component as config option

[lklic]

We are using multiple IIIF servers (4-5) to serve images in Mirador. The current config makes this quite messy as you have to write an IF statement for every IIIF server and play around with different configurations.

I think it would be much more useful to be able to simply pass in the URI of the json manifest into the component. This would also be very useful for researchers who want to reference IIIF images hosted in external collections: in libraries or museums, etc. While they can drag the IIIF manifest onto the viewer, they are not able to save this reference to the graph without creating a new config for the IIIF mirador component.

Please let me know if I have missed something in my understanding of how the component works, thanks!

[aindlq]

It is not enough to have just manifest, we also need to have RDF data for images that are in the manifest. So maybe it is OK to allow manual entry of manifest URL, but then we need to have some validation in place to check if we also have the RDF. What is the use case for external manifests, where do people construct them?

We are using multiple IIIF servers (4-5) to serve images in Mirador. The current config makes this quite messy as you have to write an IF statement for every IIIF server and play around with different configurations.

For this use case maybe we can think about something like https://docs.swissartresearch.net/et/do/#location , so the data about the IIIF endpoint is stored in the RDF and we just get it from there instead of hard-coding it in the config. What do you think?

[lklic]

The idea of dynamically storing data about the endpoint in RDF is brilliant!

What I am still confused about is why it was ever configured like this in the first place :)

It seems to go against the principle of institutions publishing and sharing images via IIIF, since it is locked down to a single IIIF config. Manifests are always generated by an institution.... although they can obviously be created by users on-the-fly as well. As in the case of Pharos, each institution has their own IIIF server and provides manifests for those images. The path for the server is always different. They come from many different servers, ranging from a simple IIIF server that just provides details about the image, or they could integrate information from a DAM/collections management system, including sequence numbers from a manuscript.

Why do you need RDF data about images that are in a manifest? Mirador only requires the manifest to load an image or sequence of images. And why can't the user just add that data if that is the case?

IIIF was really built for sharing and reusing images from other institutions. By hard-coding certain details about how to traverse a url and access the manifest, makes this all the more complicated. I would like to expose the actual manifest in my RDF by giving it an RDF type of IIIF: <http://www.example.org/image/12345/info.json> a <http://iiif.io/api/image>

Then for the mirador component I would just have one parameter "image-manifest" that allows one to bind the value of the manifest that needs to get loaded.

This would allow you to store links to manifests from anywhere, without needing to configure server urls or the like. As it is now, If a user wants to bring in a manifest from the British Library into RS, they would need to configure the component for that specific IIIF server.

I'm probably missing the full logic as to why is was set up like this, sorry for the ramble!

[aindlq]

You can already load any IIIF manifest or actually was able to (we disabled this ability few commits ago):

But this is not very useful because you can't do anything with the image, you can only view it.

Now thinking about what you said. Currently we have image upload, along the way we create corresponding RDF for the uploaded image, so we can refer to it later, add more data, search for images, etc.

What we need in addition is the ability to add new image to the system based on IIIF manifest. So user enters manifest URL, system downloads it, parses it and constructs corresponding Digital Object(s) that point to original IIIF manifest, so then Mirador knows how to retrieve actual tiles. Does it make sense?

And now just thinking out loud. In Pharos you can give people the ability to get IIIF manifest for images, where you also put https://iiif.io/api/presentation/2.1/#seealso1/#seealso or https://iiif.io/api/presentation/2.1/#service pointing to RDF (LDP?) representation of the image. So imagine that someone makes search, select few images, generate manifest for them, then goes to his own instance of ResearchSpace and add this manifest. But in addition to just creating Digital Object(s), we can also optionally copy related RDF data to the local system, so people can do they research without the need to have the full Pharos dataset in place or to use federation.

[lklic]

Can't we materialize any kind of RDF that we want during the image upload process? I think the current IIIF component functionality makes sense for users who are uploading their own images and serving them through the packaged IIIF server.

We have been discussing the possibility of RS generating manifests for a while, and I think this is a very desirable functionality. e.g. for users who are working in an archive, where they take multiple photos of a set of documents, and want to be able to construct a manifest using the presentation API. We could imagine having a folder in the clipboard with many images, users can reorder them as they wish, and then we can generate one manifest for them from the RDF.

For existing manifests that are provided by institutions, these are almost always created by a DAM/collection management system. Adding any kind of pointers within those manifests to RDF data in a RS instance is problematic as they are constructed automatically by (often) proprietary systems. At Harvard and many other institutions, we are not even able to add data in batch to these manifests, all of this work is done manually since the Digital Repository Service is used by the entire university. Downloading the manifest into the local RS instance and serving it there is a nice idea (allowing users to modify the manifest), but it we should take into account that institutions may update those manifests with updated information and we would not be able to benefit from these updates.

What happens with annotations on images that are created by users, and is this somehow connected to the current implementation?

Would we lose annotation functionality by having a config option in the component to just pass in the manifest url?

[robcast]

I would very much welcome the ability to access images or manifests from existing IIIF endpoints in the internet in RS without having to configure each endpoint in advance.

I think it should be as easy as providing just the IIIF URI for the image or manifest and giving it a type.

There are two different cases from a UX and functionality standpoint depending on if you are referencing a manifest (a sequence of one or more images with additional metadata) or a single image (IIIF Image API or Presentation API canvas).

The manifest consists of multiple images and I would think of it as the digital image representation of a book. It can be browsed in a viewer like Mirador.

@aindlq 's screenshot shows a manifest.

The image endoint is the digital representation of an single image. It can not be browsed, it can only be zoomed. Maybe you can draw annotations on the image. It does not provide contextual metadata.

@lklic 's example

<http://www.example.org/image/12345/info.json> a <http://iiif.io/api/image>

looks like it references an Image API endpoint (more specifically the image info resource).

When we start to use single image URIs e.g. for annotations it is also important to consider the difference between the IIIF Image API information (https://iiif.io/api/image/3.0/#5-image-information) and the IIIF Presentation API canvas (https://iiif.io/api/presentation/3.0/#53-canvas) that is usually part of a manifest.

It would be preferable for annotations to refer to a canvas because it has an explicitly specified resolution that doesn't change even if the underlying image service changes. It also makes it easier to harvest annotations of the same image because all annotations (ideally) reference the same stable canvas URI whereas image service URIs may look different.

A possible difficulty with referencing canvas URIs could be that in many services the canvas URIs are not separately resolvable.

[lklic]

Those are great points @robcast !

I am just revisiting this now again because the regex queries you have to write for each IIIF server are a real pain.

Also, mirador 3.0 came out today!

@aindlq do you think it would make sense to add a component config option to specify only a IIIF image manifest?

[lklic]

You can already load any IIIF manifest or actually was able to (we disabled this ability few commits ago):

Hi @aindlq, we just discovered that this functionality disappeared in the latest release, could this be added back? We do have a need for this as we had set up an image "Lightbox" that allows users to drag and drop different images to compare them.

Regarding the iiif manifest issue, we also just found that we are unable to use the "image overlay" functionality as shown here because our images are coming from different IIIF servers, so it doesn't allow for their comparison since the server config is different.

[gspinaci]

Up