CRM <--> IIIF links

[azaroth42]

Similar to the EDM <--> IIIF links in #558, we're (@azaroth42, @workergnome, et al.) looking at how to reference IIIF resources from within CIDOC-CRM.

Image API

We think that the Image API endpoint is an E38 Image. Note that Images are abstractions, not representations:

The original painting of the Mona Lisa in the Louvre may be said to bear the same instance of E38 Image as reproductions in the form of transparencies, postcards, posters or T-shirts

As such this seems okay for the base URI. Thus we can use P138i has representation from the Object to the endpoint. We can then distinguish it from other images with dcterms:conformsTo, following the IIIF specification:

_:object a E22_Man-Made_Object ;
  P138i_has_representation <iiif-base-uri> .

<iiif-base-uri> a E38_Image ;
  dcterms:conformsTo <iiif.io/api/image> .

Presentation API

We think that a Manifest is an E73_Information_Object, that is about the object. For more details we need to resolve some of the other issues ... notably #1066 and the venerable #76

_:object a E22_Man-Made_Object ;
  P129i_is_subject_of <manifest-uri> .

<manifest-uri> a E73_Information_Object, sc:Manifest ;
  dc:format 'application/ld+json;profile="???"' ;
  dcterms:conformsTo <???> .

Consistent would be to reference api/presentation from conformsTo (re #76) and the context URI for the profile (re #1066), following similar patterns in the W3C (annotation, activitystreams, etc)

[workergnome]

I might suggest modifying the Image API to be:

 <iiif-base-uri> a E38_Image ;
    dc:format 'application/ld+json;profile="???"' ;
    dcterms:conformsTo <iiif.io/api/image> .

As a hint to naive viewers that they won't get very far trying to drop it into a \ tag.

[azaroth42]

Proposed docs: http://linked.art/model/object/digital/#iiif

[Conal-Tuohy]

Here's something I haven't understood about IIIF, and I'd appreciate some guidance; it's a question that came up on the TEI-L mail-list the other day too, and I think it's likely to arise in many other cases: where you have some non-IIIF data structure which is designed to point to images, and you want to use it to point to IIIF images, how does it capture the specifics of the IIIF image protocol; i.e. how should it represent the fact that there's an IIIF image server there and not just a plain web server serving images?

IIUC, the IIIF Image base URI will not respond successfully to a GET request with e.g. Accept: image/jpeg, which makes it infeasible to treat those URIs equivalently to regular image URIs. Is that correct?

So here in your example you have a specially-typed link to the IIIF Image base URI (and people on the TEI list were talking about a similar approach from within TEI <facsimile> markup), but what I wonder is why you wouldn't simply link to a particular (representative) image, which would have that base URI as a prefix, but would have some other segments following, making it a URI which would respond to a image request and be usable not just from an IIIF-aware client, but more generally by any kind of image-aware user agent.

I believe (correct me if I'm wrong) that the IIIF image server serving an image tile is supposed to include an HTTP link header to the base URI anyway, to allow an IIIF-aware client to discover the API. It seems to me that this is an issue best dealt with in the protocol itself, rather than in every one of the myriad metadata systems that point to resources served with that protocol.

[azaroth42]

Meta-comment: I don't think it's the place of IIIF to determine how other non-IIIF structures work, and hence I don't think there's a IIIFy answer to your (or TEI-L's) underlying question. As you say, this is best dealt with at the protocol level ... but people like to record the data in representations, rather than rely on the transport layer.

For CIDOC-CRM, we rely on the semantics of VisualItem or Image as being the abstract notion of the content, not a specific instance of it. The service endpoint represents (to some degree) the abstract "source" image, as there isn't necessarily one source image that could be delivered. It redirects to a description of it in JSON-LD in the same pattern as the typical 303 See Also resource/page distinction. And then the format is there to say that it's JSON-LD not an image representation. This isn't great, but there's no CRM notion of a digital service.

The original painting of the Mona Lisa in the Louvre may be said to bear the same instance of E38 Image as reproductions in the form of transparencies, postcards, posters or T-shirts, even though they may differ in size and carrier and may vary in tone and colour.

Note that the Presentation API does exactly what you suggest -- the annotation links to a representative image, which then links to the service from which that and other images can be requested :)

[azaroth42]

Propose close wontfix given:

I don't think it's the place of IIIF to determine how other non-IIIF structures work

If other organizations care to document these things, great.

Treating silence as assent after 21 days.

[azaroth42]

Per #600, it would be possible to put these sorts of things in a cookbook entry if there was interest. Closing.