Open technelily opened 4 years ago
Hi! Thank you for contacting me.
Can you give me an example of a page where you would like this extension to discover a link to the new manifest?
For example, on this page, if you change the IIIF icon's link to http://www.getty.edu/art/collection/static/viewers/mirador/?manifest=https://media.getty.edu/iiif/manifest/0a16b443-214a-4a51-b425-06cead1d1cbf.json, the extension will find the new manifest as it does now.
Thanks.
Hi! Sorry for the delay. I want to be able to open a manifest link from an application, which doesn't currently have a IIIF viewer baked in, and be able to use Chrome to view the image. Here's an example manifest link:
https://media.getty.edu/iiif/manifest/0b9d2e80-915e-4f2f-bb3e-0595d10cd228
OK. The simplest way is to put a link like this:
This link may look a little funny, but it meets the following conditions:
Let's explain in more detail.
In the IIIF Drag-and-drop pattern, the following example is shown.
<a href="default_target?manifest=manifest_URI&canvas=canvas_URI">
<img src="iiif-dragndrop-100px.png" alt="IIIF Drag-n-drop"/>
</a>
As described on that page, the "default_target
" does not have to be a IIIF viewer.
So, the links listed below will work fine with most IIIF viewers and the "Open in IIIF Viewer" extension.
In fact, some sites put a link using non-IIIF viewer URLs in the "default_target
" part.
In the future, the "Open in IIIF Viewer" extension will implement a specification about discovery-import.
Formerly, the specification about importing IIIF resources into the viewing client was discussing as the IIIF Import API, and now it seems to be a part of the IIIF Content State API.
The draft of the IIIF Content State API proposes the following link formats (3.1.1 Linking: HTTP GET (query string) parameter).
<a href='https://example.org/viewer?iiif-content=http://dams.llgc.org.uk/iiif/2.0/4389767/manifest.json'>Link to Viewer</a>
The draft also proposes the following pattern to embed a IIIF viewer (3.1.7 Common initialization parameter).
<p>Loading a whole manifest</p>
<div
id="iiif-viewer"
data-iiif-content="http://dams.llgc.org.uk/iiif/2.0/4389767/manifest.json">
</div>
If you don't have a IIIF viewer instance equivalent to a "default_target
" or "https://example.org/viewer
", the data-iiif-content
pattern may be helpful.
When you add that description without a IIIF viewer installation, nothing happens, and no side effects, but crawlers or some browser extensions in the future may be able to discover a manifest.
However, it is noted as "This is probably not spec. It's a recipe.", so I'm not sure if it will be supported by the "Open in IIIF Viewer" extension. If there is a consensus among Mirador, UV, etc., and this description method becomes popular, it may be supported by the extension.
Similar needs have been discussed in https://github.com/IIIF/api/issues/2212, but they seem to have not reached a conclusion yet.
Therefore, at this time, it would be a good choice to put the link I mentioned at the beginning of this comment.
Thanks.
Thanks for this info. We don't want to alter the manifest link in the application but to keep the data clean and as-is. I was hoping there was a way to do this based on a whitelist, as it appears to be working in your test instances.
Hi - Great extension! We've had a change to our manifest structure here at the Getty. Is it possible to get the new structure added to the whitelist? Here's an example:
https://media.getty.edu/iiif/manifest/0a16b443-214a-4a51-b425-06cead1d1cbf.json
Would you like us to submit a pull request?
Thanks, Lily