Why should Wikimedia implement IIIF? And what does that mean? There are several things they could do, some possibly quite straightforward.
Clarify two different things:
- Bring Wikimedia assets (images, audio, video) into shared IIIF annotation space, so that they become part of the IIIF Universe, can be annotated, referenced, mashed up, reused as Presentation API
- Allow image reuse via IIIF Image api:
- statically, via level 0 (extreme level 0) service
- dynamically, with image servers, allowing arbitrary regions, sizes, qualities and hence tiles, deep zoom
Various combination os these are possible and are all useful.
A simple Presentation API implementation would create a canvas for each asset and publish the canvas. One step up, collect the assets for a topic into a Manifest with additional (infobox etc) metadata from the topic
I had a go at this: https://wikipedia-to-iiif.ch.digtest.co.uk/wiki/Robert_Delaunay
Other examples: https://wikipedia-to-iiif.ch.digtest.co.uk/ Code: https://github.com/tomcrane/wikipedia-to-iiif
This is a bit of fun, but the point is to show that it's not that hard. The biggest flaw in this is its fragility - anyone annotating these canvases is dependent on the Wikimedia record, in particular the w,h of the canvas derived from a large image asset. That could change without warning, displacing annotation positions.
Wikimedia need to be the authority for Canvas dimensions and maintain a consistent w,h even if asset sizes change. That shouldn't be too hard. They would maintain a persistent Canvas URI as part of the Wikimedia application. This is just transformation of existing data and an extra db field or two.
Still in the Presentation API, each Canvas could have a single suitable large image, or a Choice of the available images.
The set of images available could be translated into a sizes-only level 0 Image API endpoint, proxying Image API requests onto the existing static resources (see https://tomcrane.github.io/scratch/osd/iiif-sizes.html)
Again, no new infrastructure is required, just extra supported endpoints.
AV works fine in this and if they go straight to Presentation 3 (likely, and a good driver of adoption) they can use existing AV assets without any changes.
This is the step up and Klokan did some work with Wikimedia a couple of years ago, getting IIPImage running for Wikimedia images: https://groups.google.com/forum/#!topic/iiif-discuss/UTD181dxKtU
This is where it might get daunting for Wikimedia to do this at scale, because running dynamic image servers for all of Wikimedia may induce fear and trembling.
Everything apart from dynamic image API I think could be done by additions to Wikimedia application/model, and requires no new infrastructure.
Combinations of these are useful:
- Simple Presentation (like my demo, but real)
- Simple static image api
- Both of these together (static sizes-only level 0 services on static images annotated to canvases)
- Dynamic image api
- Presentation and dynamic image api (the ultimate...)
Maybe everything up to the last point could be a IIIF-funded project for Wikimedia foundation?
my comments copied from slack:
(nod) looks overall in line with my thinking
doing dynamic image api right will depend probably on mapping the image api onto our existing internal apis. we currently don't support some things like rotation and tiling, but tiling's the most important one to add.
(and one we can use internally for things like panoramas, so that's a plus)
Our main limitation on media work right now is squeezing all the things we want to do into our budget with several other projects going on, so if there's talk of funding to pick up some contracting time to supplement my work, that could be something I can sell to the upper ups!