Add RecordDriver\Feature\IiifAwareTrait#5067
Add RecordDriver\Feature\IiifAwareTrait#5067ronja-koistinen wants to merge 2 commits intovufind-org:devfrom
Conversation
This trait provides common functionality through which to query a record driver for IIIF Presentation API manifests.
|
Thanks for sharing, @ronja-koistinen! Regarding array vs. generator, I don't think it makes much difference if we're creating the list using existing metadata... though a generator might be better if we wanted to add logic like retrieving manifests to inspect them, since that could quickly become expensive, and we wouldn't want to do it all up front. (Though really, I think we wouldn't want to do it at all, because the risk to performance almost certainly outweights the benefits). We might also want to think about a "definition of done" for this PR -- at what point do we have something we want to merge? Do we just want a "minimum viable product" that we can merge and start building upon, or do we want something a little more feature-complete (i.e. enough infrastructure to write tests to exercise the code). Also, is it possible we might want an interface to go with this trait so we can identify IIIF-capable record drivers? Or do we just want to stick with duck typing through |
|
I'm always in favour of strong typing, an interface sounds good. |
|
I also wonder whether there's some way we could put together a minimal viable example of linking to or embedding a viewer. I don't think we would want to go so far as to actually include a IIIF viewer in the core project at this point, but maybe there's some infrastructure we could build to encourage a common approach at least (like a configuration setting to generate the target of an iframe that incorporates the manifest, for example). |
This trait provides common functionality through which to query a record driver for IIIF Presentation API manifests.
The implementation of the
isIiifPresentationManifest()method is not a fool-proof way to identify which URLs in metadata refer to IIIF resources, because the wording in the spec is (note the SHOULD):At least the regex in my implementation tries to be Presentation API version-agnostic.
For an example of a record driver using this trait, see what Finna does in the SolrMarc driver.
In my first implementation,
getIiifManifests()was a generator, and maybe it still should be. I don't remember why I changed it...