IIIF Presentation v3 manifest for IIIF Image API-backed resources

[cbeer]

We're trying to build a IIIF Presentation v3 manifest that supports ordinary IIIF Image v2.1-backed images. Here's a strawman where we plopped what we were doing with v2 presentation manifests into a v3-style manifest:

https://gist.githubusercontent.com/cbeer/8049c809d0f67ca24ac20e58d9214180/raw/c1d52a4064a2548c0e1a8e3a6759dd1046bf4b91/vv985tj8656.json

From @edsilv:
it was using the type property before, but as of the presentation 3 work it's switched to using format instead to determine which extension to load to view the content.
The example manifest you provide has an image/jpg format. I think we could add a clause here to test for that:

https://github.com/UniversalViewer/universalviewer/blob/v3/src/UVComponent.ts#L62

That will involve adding a new MediaType to Manifesto

[tomcrane]

Hi @cbeer - I've had a go at tweaking your example to make a Presentation 3 manifest referencing Image 2 services:

http://tomcrane.github.io/scratch/manifests/3/imagey.json

(caveat emptor... there may be other tweaks required)

Changes:

• Add in a fake v3 context, alongside the W3C anno context (@context ends with WebAnnos, then IIIF IIIF/api#1186)
• change the id to @id where the v2 Image API context has been introduced (this needs further discussion...)
• remove dctypes prefix; common DC types are aliased in the W3C anno context (to enhance readability)
  ** e.g., "type" : "Image"
• Your seeAlso link to MODS would benefit from a profile (not significant for this discussion)
• normalised some @type/type and @id/id in various places
• changed on to target (use W3C anno vocab)
• reordered the terms order in the body of the image annotation (no change in meaning, just to help readability for me)

Regarding the UV's choice of extension, I think it needs to consider:

1. What is the resource being annotated? dctypes provided coarse distinctions; Image, MovingImage, Audio etc. The format refines this, but it could be one of many image formats, not just image/jpg - might be png, tif etc; although it is expected to be a format that a browser can display.
2. If it is an image, does it have a IIIF image service that Openseadragon can use as a tileSource?

If the answer to these is both yes, it's the OSD extension.
If the answer to 1 is yes but 2 is no, it could still use OSD but would need #78 implemented.

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.