I want to leverage the discovery API to publish links to structured data about ALL my cultural objects, not just those with IIIF images

[beaudet]

Description

Since we would need to implement the discovery API anyway, I would like include see-also links in manifests with no canvas (or an empty canvas) so that our top level IIIF collection includes all collection objects rather than only the objects with IIIF images.

Additional Background

By creating manifests as container objects with see also links to structured data, an institution can leverage the IIIF discovery API to facilitate publishing of structured data as well as IIIF images to aggregators.

[azaroth42]

Out of scope to solve discovery in general, rather than discovery of IIIF resources?

[beaudet]

That is indeed the question I think is very important to discuss. I wouldn't assume it's out of scope for IIIF, particularly if there's a manifest artifact. Quite to the contrary, I think it's very important for IIIF to support this because otherwise I believe the utility of IIIF Discovery will be significantly diluted otherwise. IIIF discovery will then become an API of secondary interest. I still maintain that I have not heard articulated a use case for IIIF Discovery that involves an actor explicitly seeking out only IIIF image resources. Rather, they are seeking objects. IIIF resources merely decorate those objects. If we indeed conclude the use case in this ticket is out of scope, I think we are also resolving to make IIIF Discovery a secondary protocol whereby IIIF resources are located AFTER an initial query for the objects those resources represent. This would be further underscored by the obvious conclusion that unless IIIF discovery enables discovery of the source objects, that an entire institution's collection cannot therefore be represented by IIIF Discovery. Even more challenging, it means IIIF Discovery should make it painfully obvious that a IIIF collection can never be synonymous with an actual physical collection except in cases where IIIF resources are actually available for each object. We might also find institutions creating placeholder IIIF resources like "no image available yet" image to get around such limitations if the benefits of IIIF Discovery as a general use Discovery layer outweigh the disadvantages of placeholder IIIF objects. Please, let's discuss this.

[azaroth42]

Per discussions in iiif/iiif.io#1146, the "empty" manifest acting as a tombstone or placeholder is a problem for discovery in general, and current feeling is that it should not be allowed.

That aside, we are not going to solve discovery of arbitrary resources across arbitrary sets of organizations. We can take that as a given, I hope, as it has been more than a decade of work for Europeana (for example) or trillions of dollars for Google. Following from the charter and the initial scoping discussions, we are intentionally and explicitly not creating a federated-search-for-objects solution. We're facilitating the discovery of IIIF resources so that they can be more easily aggregated by aggregators such as Europeana or Google, providing a way to consistently find better domain-specific metadata (seeAlso), stay up to date with changes via notifications, and then (as you say) after the query has been performed in some out-of-band system, then get the references to the results back into the user's IIIF enabled environment via the import-to-viewer solution, when there are IIIF resources available.

[beaudet]

After reading 1146, I'm not convinced there's a strong feeling one way or the other. What I do see expressed in that discussion is that there is concern that a "IIIF collection" might not be a complete collection from an institutional perspective.

I don't think IIIF is in the position of solving discovery per se and that would certainly be a problem best left up to the aggregators, but what IIIF Discovery could provide quite easily is a very simple mechanism for allowing collections of objects with pointers to richer, non-IIIF-Discovery scope metadata. The bulk of the Discovery work is obviously IIIF resource specific, but I don't see why it needs to exclude such breadcrumbs. If an aggregator wants to ignore those and focus only on the objects with IIIF resources, so be it. I would think aggregators would be very interested in an approach that might normalize the way they find and traverse definitive and complete sets of collections. I don't think they'd be as interested in having to develop a parallel process just for traversing sets of IIIF assets. If designed as such, that might actually impede adoption of the IIIF Discovery standards. Seems like the aggregators should weigh in on this.

[zimeon]

It is already the case that one can include plain image files as well as IIIF Image API resources in IIIF Presentation API descriptions. To extend beyond that to yet-to-be-available items ties to questions like https://github.com/IIIF/iiif.io/issues/1146. I would say that extension of IIIF discovery of things not described using the IIIF Presentation API would be extending the scope too much.

[beaudet]

I think it would be prudent to ask the aggregators, who are arguably the primary customers of the Discovery API, to weigh in on this.

[mattmcgrattan]

Vatican 2017: If the solution chosen supports discovery of non IIIF resources, it should be possible to determine which resources are IIIF and which not?

[aisaac]

Vatican 2017: this is about whether our discovery solution should be usable for non IIIF resources. And to what extent is that important -- should iiif resources just be part of a bigger set of resources (requiring filtering a lot) or should other resources be optionally part of IIIF sets (requiring filtering a few). In that context, it seems to be in scope but as part of a broader issue regarding such policies / approaches.

[olivergoetze]

Dear all,

I would like to chime in on this issue, especially since @beaudet has been asking for the opinion of a data aggregator.

For our portal (German Digital Library and Archives Portal) it would also be important to be able to publish metadata-only objects via IIIF. A big amount of the (not only) archival material presented in our portal is not yet digitized, nevertheless it's still of value for our scientific user group. Furthermore, because of the hierarchical context of the material (precedent classification and holding data records), there will always be objects left without digitized images.

In the long run, we are thinking about using IIIF manifests for our own object metadata display format, but to be able to implement this, we need the ability to use IIIF manifests for objects without images.

In my view, it would also be a big factor facilitating acceptance of IIIF in the archival sector. We would be glad if we could further discuss this issue.

Best regards Oliver Götze

[aisaac]

The Discovery API specification allows its activity streams to refer to "non-IIIF resources". Cf https://iiif.io/api/discovery/1.0/#object

Activities must have the object property. The value must be a JSON object, with the id and type properties. The id must be an HTTP(S) URI. The type should be a class defined in the IIIF Presentation API, and should be one of Collection, or Manifest. The type, therefore, may be any class, including those not defined by the IIIF Presentation API, and consuming applications should validate the type as being one that is appropriate for their usage.

Therefore this use case can be supported, we believe. (discussed at IIIF Discovery TRC call 1-2-2023: https://docs.google.com/document/d/1qiFtJEcWSnE60KTVagmzEKMnLBCrcSObSSlUGFqoNsw/)