Versioned Manifests have Invalid id values not matching published URIs, ex: https://iiif.archive.org/iiif/3/...

[mathewjordan]

The id of this Manifest is:
https://iiif.archive.org/iiif/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

While the published URI (after a redirect) is:
https://iiif.archive.org/iiif/3/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

A /3 path is added within the URI here making the Manifest invalid.

According to https://iiif.io/api/presentation/3.0/#id

The value must be a string, and the value must be an HTTP(S) URI for resources defined in this specification. If the resource is retrievable via HTTP(S), then the URI must be the URI at which it is published.

Note, I found this after discussing an issue related to Clover IIIF and IA Manifests with @markpbaggett. I may have noted this previously but cannot find a related issue. Most viewers seem workaround this, however, Clover is highly dependent on the URI matching this id value. Regardless, this isn't really a Clover issue, but a presentation spec related one.

Best!

[glenrobson]

I think this is a valid use of the ID and is intended to help with supporting multiple versions of IIIF. The first link which is in the manifest, is the versionless identifier for the manifest and unless you specify a accepts header then you are forwarded to the default v3 version.

I'm not sure if we implemented it but the idea is you could add the following Accept header to get forwarded on to the v2 version:

application/ld+json;profile="http://iiif.io/api/presentation/2/context.json" 

When we need to move to v4 we would keep the same manifest identifier (and canvas identifiers) and in the short term only forward clients that request v4 and then in the long term we would update the default to forward to v4.

[mathewjordan]

Thanks @glenrobson

This hurts my brain a little, so I'm going to babystep through the issue as I might not have been clear in my original issue. Perhaps I should have titled this as Versioned Manifests have Invalid id values not matching published URIs.

There are two scenarios here, the first is the one that I'm struggling to grasp.

Request of a versioned Manifest, ex: /3

❌ If the requested Manifest URI is containing a version /3/ or /4, https://iiif.archive.org/iiif/3/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json, should this not match the id in the JSON-LD? In this instance, the issue seems to be more of backing into the requested id at the requested version rather than redirecting to the most current version.

For example, if I request the /3 version here:
https://samvera-labs.github.io/clover-iiif/docs/viewer/demo?iiif-content=https://iiif.archive.org/iiif/3/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

Would not the expected id be the URI at which it is requested in this case?

Request the generic Manifest

✅ If the requested Manifest URI is not versioned, this is handled just fine, as the requested URI does match the id in the JSON-LD of the Manifest it has found.

https://samvera-labs.github.io/clover-iiif/docs/viewer/demo?iiif-content=https://iiif.archive.org/iiif/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

[markpbaggett]

Maybe this is a different issue, but let's pretend I request this presentation v2 manifest:

https://iiif.archive.org/iiif/2/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

The @id here is https://iiif.archive.org/iiif/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json. If I dereference that, I get the version 3 manifest. Shouldn't this return the same v2 document?

[glenrobson]

This is the issue where we discussed the forwarding of URLs:

ArchiveLabs/iiif.archivelab.org#74

In the end we forwarded the versionless manifest URL to 3 as archivelab was still in existance so we didn't need to keep the v2 the deafult.

It looks like we don't have the content negotiation features we should have here:

iiif/iiify/app.py

Line 220 in 704649e

def manifest(identifier):

which would allow you to use the same URI for both versions and then switch based on the accept header.

It maybe better in this case just to include the version numbers in the id of the manifest but the intention was to keep the manifest ids and canvas ids the same between versions so that annotations target a v2 manifest would still work with a v3.

The alternative way of accessing v2 and v3 resources using the same URI is the method in the proposed cookbook: IIIF/cookbook-recipes#181 where both v2 and v3 manifests have the same URI and the only way to select the version is to use Accept headers.

What issues in clover do you come across when the manifest id doesn't match the final URL for accessing the manifest?

[markpbaggett]

@glenrobson , Clover assumes that the URL requested via the contentState iiif-content parameter matches the id that is returned in the JSON-LD. If it doesn't, Clover doesn't do anything and perpetually says "Loading ..."

In other words, Clover is happy with:

https://samvera-labs.github.io/clover-iiif/docs/viewer/demo?iiif-content=https://iiif.archive.org/iiif/cc4ia-Polar_Plunge_Promo_-_2018/manifest.json

But not:

https://samvera-labs.github.io/clover-iiif/docs/viewer/demo?iiif-content=https://iiif.archive.org/iiif/3/cc4ia-Polar_Plunge_Promo_-_2018/manifest.json

[mathewjordan]

@glenrobson My concern is more related to using the id of the Manifest as a source of truth. If the pathed /3 Manifest is requested, Clover is fully expecting the id of the JSON-LD resource to have that exact URI as its id value. Instead it finds a resource with a value not having this path and isn't smart enough to know that this Manifest is the one that was requested. While this can be easily worked around, it has me wondering what purpose an id value holds in a Manifest, as the likely code shift seems to be for viewer to accept any IIIF resource it is given.

[mathewjordan]

Note, I have updated the title to match more precisely with the documented issue.

[glenrobson]

1. Fix the helper to use the versionless URL.
2. Version 2 should have the version number in the ID.
3. Version 3 welcome model, we would proxy rather than redirect:

https://iiif.archive.org/iiif/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

4. update the id of the version 3 TBC:

https://iiif.archive.org/iiif/3/78_der-er-maske-en-lille-pige-der-drommer-om-dig-skuespiller-edgar/manifest.json

Glen to create issue on the API repo for the editors to look at for v4.

[glenrobson]

Create a new issue for 1-3 and leave this one as the 4 so we can see the discussion.