Skip to content

Add RecordDriver\Feature\IiifAwareTrait#5067

Draft
ronja-koistinen wants to merge 2 commits intovufind-org:devfrom
ronja-koistinen:feature-iiiftrait
Draft

Add RecordDriver\Feature\IiifAwareTrait#5067
ronja-koistinen wants to merge 2 commits intovufind-org:devfrom
ronja-koistinen:feature-iiiftrait

Conversation

@ronja-koistinen
Copy link
Contributor

@ronja-koistinen ronja-koistinen commented Feb 11, 2026

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):

If the request does not include an Accept header, the HTTP Content-Type header of the response SHOULD have the value application/ld+json (JSON-LD) with the profile parameter given as the context document: http://iiif.io/api/presentation/3/context.json.

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...

This trait provides common functionality through which to query a record driver
for IIIF Presentation API manifests.
@demiankatz
Copy link
Member

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 tryMethod?

@ronja-koistinen
Copy link
Contributor Author

I'm always in favour of strong typing, an interface sounds good.

@demiankatz
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants