Implement IIIF Content Search 2.0

[tomcrane]

While #4740 is mostly just another bit of porting to do, this one is a bit more complex.

It would be nicer, cleaner and generally more elegant for the Presentation 3 manifests to reference IIIF Search 2.0 search within endpoints - not Search 1.0 endpoints, and not both Search 1.0 and Search 2.0 endpoints.

Search 1.0 is aligned with Presentation 2 and search results are Open Annotation annotations. Search 2.0 is aligned with Presentation 3 and search results are W3C Web Annotations. All is harmonious.

Trouble is, the Search 2.0 spec doesn't exist. It's high priority, next-on-the list after the release of Presentation 3.0, and a Technical Specification group will be formed. It had to wait for P3 to be finished.

It's possible to have a Search 1.0 service for a P3 manifest if you are willing to look the other way over some linked data issues, but even so, it's ugly. We wouldn't want to leave it like that.

(See notes - https://docs.google.com/presentation/d/1jdnNBu1Ek6Czr3vr2dEhYMDQ6euGjHhwREG5TPycGng/edit#slide=id.g88059d92be_0_5)

In fact we're at the same point we were when the current version of search was developed on wl.org - the published spec didn't exist, this work threw lots of use cases and requirements at it.

At this stage there's no need to introduce new features to the search that we're going to port, just to translate it to use the model of P3 and W3C Web Annos. In this respect, it's going to be pretty obvious what the equivalent bits of Search 2.0 will look like, so it should be straightforward, and relatively safe, to anticipate Search 2.0 and just implement it now. That is what I suggest doing.

The danger is that the eventual Search 2 implementation could end up in a different place - the Technical Specification Group could go down a very different path. We'd have to go back and update. But... a working implementation is a very strong hand to play.

[tomcrane]

We won't attempt to implement a hypothetical Content Search 2.0 for now, but the search services in Presentation 3 manifests need to point to something so there is still a bit of time required to decide and implement exactly what that something is. Probably the bare minimum translation of OA to W3C Web Annotations.

NB P2 and P3 manifests must use the same Canvas @id / id - they are the same conceptual resource. This makes targeting search results across versions less problematic.

[tomcrane]

The work in the above comment is now done.

The IIIF 3 Manifests point to a IIIF Search 1.0 impl.

The Canvas Identifiers are deliberately the SAME in both IIIF 2 and IIIF 3 Wellcome Manifests - the id is for the conceptual space, not a particular blob of JSON. Therefore linked data purists shouldn't be upset about IIIF Search 1 results pointing at resources of type sc:Canvas (IIIF2) rather than Canvas (IIIF3) - they are the same thing.

And more importantly, it works, and you can build a client from it that handles search correctly from a IIIF3 manifest:

http://tomcrane.github.io/wellcome-today/wc.org/3/thumbs.html?manifest=https://iiif.wellcomecollection.org/presentation/b28047345

(That link won't work until a deployment is done)

Incidentally the first meeting of the new IIIF Search Technical Specification Group is this Friday. Leave this issue open for later Search work? I don't think we need to do anything more in the current phase of work other than testing everything we have.

[tomcrane]

@pollecuttn @jtweed see above comment. To keep the board nice we could close this and make a new Search 2 issue later.

[pollecuttn]

@tomcrane Yes that makes sense if you want to close this and then have a new issue for Search 2