... this means Wellcome Collection developers as well as third parties.
In the current phase of work, there will be no impact. The current phase is about migrating the synchronisation activity and dashboard.
iiif.wellcomecollection.org
In the second phase of work (Autumn), we will be providing new IIIF endpoints for everything, at iiif.wellcomecollection.org.
We will also be providing IIIF Manifests in Presentation API version 3.0, which has a strong developer-friendliness design goal.
However, we will also provide IIIF 2.1 manifests (as in the current implementation) for backwards compatibility, and to service anyone relying on them now (e.g., Biblissima, From The Page, etc).
Eventually, when wellcomelibrary.org is retired, a stub API service running on wellcomelibrary.org can remain, redirecting any manifest or other API request to the new location on iiif.wellcomecollection.org.
Similarly, image service endpoints and thumbnails will be available on iiif.wellcomecollection.org - but they won't stop working on dlcs.io.
In theory, consumers of the current API need not do anything. If consuming IIIF programmatically, as long as your code follows redirects, it should just all work.
Moving to IIIF Presentation 3
However, we would like to propose an exception to this. Wellcome publishes IIIF Manifests for AV content, but they are not valid IIIF. They were an interim solution to keep the functionality of the Wellcome Player when moving to the UV.
Time-based media is properly supported in Presentation 3. Wellcome should stop publishing the pseudo-IIIF AV manifests completely, and only publish Presentation 3 manifests for AV (the old ones can redirect).
This means that the code on wc.org that reads manifests for AV will need to change. That should be a simple change, the data is all there, it's just carried by differently-shaped JSON.
The DigitalLocation returned by the Catalogue API will change at some point to give the Presentation 3 manifest by default, at a content-negotiable endpoint.
It's not immediately essential but it definitely be a nice-to-have for wc.org to consume the Presentation 3 manifests for viewing digital objects, rather than stay on the 2.1 versions. Especially as no new features will be added to the 2.1 manifests.
Again, the same concepts are present, but the JSON is a little different. It should be quite straightforward to start using the Presentation 3 manifests - IIIF-consuming code usually looks cleaner after porting to Presentation 3.
... this means Wellcome Collection developers as well as third parties.
In the current phase of work, there will be no impact. The current phase is about migrating the synchronisation activity and dashboard.
iiif.wellcomecollection.org
In the second phase of work (Autumn), we will be providing new IIIF endpoints for everything, at iiif.wellcomecollection.org. We will also be providing IIIF Manifests in Presentation API version 3.0, which has a strong developer-friendliness design goal.
However, we will also provide IIIF 2.1 manifests (as in the current implementation) for backwards compatibility, and to service anyone relying on them now (e.g., Biblissima, From The Page, etc).
Eventually, when wellcomelibrary.org is retired, a stub API service running on wellcomelibrary.org can remain, redirecting any manifest or other API request to the new location on iiif.wellcomecollection.org. Similarly, image service endpoints and thumbnails will be available on iiif.wellcomecollection.org - but they won't stop working on dlcs.io.
In theory, consumers of the current API need not do anything. If consuming IIIF programmatically, as long as your code follows redirects, it should just all work.
Moving to IIIF Presentation 3
However, we would like to propose an exception to this. Wellcome publishes IIIF Manifests for AV content, but they are not valid IIIF. They were an interim solution to keep the functionality of the Wellcome Player when moving to the UV.
Time-based media is properly supported in Presentation 3. Wellcome should stop publishing the pseudo-IIIF AV manifests completely, and only publish Presentation 3 manifests for AV (the old ones can redirect).
This means that the code on wc.org that reads manifests for AV will need to change. That should be a simple change, the data is all there, it's just carried by differently-shaped JSON.
The
DigitalLocation
returned by the Catalogue API will change at some point to give the Presentation 3 manifest by default, at a content-negotiable endpoint.It's not immediately essential but it definitely be a nice-to-have for wc.org to consume the Presentation 3 manifests for viewing digital objects, rather than stay on the 2.1 versions. Especially as no new features will be added to the 2.1 manifests. Again, the same concepts are present, but the JSON is a little different. It should be quite straightforward to start using the Presentation 3 manifests - IIIF-consuming code usually looks cleaner after porting to Presentation 3.