Should there be a property in image and prezi APIs to link to a preferred viewer instance?

[zimeon]

This question came up in discovery discussions at Ghent that we might have a registry allowing discovery of sets of IIIF resources via either IIIF Collections or via a sitemap of HTML pages that have microdata (#557) linking to the IIIF resource. In the second case the discovery system will already know the "preferred" access page which might be presented to discover system users (along with drag and drop options) which may give a particularly good UX tailored to the resource, and likely make the host institution happy for extra traffic. If starting from an IIIF Collection and finding Manifests or Image Services, there is currently no way to find an access point.

[zimeon]

Might use predicate edm:shownAt but domain is currently ore:Aggregation (see defs in EDM ontology )

[jpstroop]

By viewer instance do we mean a specific viewer only (Mirador or UV), or additionally one or another of those hosted at a specific place. Didn't the BL have this use case?

[jpstroop]

If the latter, and the goal is to actually constrain, I guess my opinion is (as it was with the BL use case), why are you bothering to tell the world about your manifests at all? Just publish a sitemap for search engines and be done with it. If it's just a preference and the goal is to provide a preview or default location, then this seems worth pursuing.

[glenrobson]

My understanding was that this also included an option to link back to our version/location of the viewer e.g:

http://hdl.handle.net/10107/1295136

So if somebody uses our manifest in another discovery solution then they would have the option of seeing it in our interface too. Will help make the case to management that sharing the manifest helps use and re-use of resources. This would be the same argument we use for contributing to Europeana.

[tomcrane]

Is "related" too vague? See https://github.com/IIIF/iiif.io/issues/557#issuecomment-143713543 - here "related" is being used to steer towards a page on the library site. It so happens that the page the library asserts as related is the page that embeds the library's preferred viewer.

[tomcrane]

It depends on whether it's worth introducing a new term that explicitly means "rendered in a IIIF viewer here"

[mattmcgrattan]

So, we (erroneously) use 'seeAlso' in our manifests to link back to Digital.Bodleian. This is clearly incorrect, and it should link to some machine-readable metadata resource, and will, within the next week or two.

But ... we'd also like to be able to do something that linked back to the source viewing environment. Exactly as per Glenn's https://github.com/IIIF/iiif.io/issues/648#issuecomment-163940968.

[jpstroop]

2.1 adds rendering, which might be appropriate, even though we don't explicitly mention viewing on the web as an example. @IIIF/editors, agree?

[mattmcgrattan]

Rendering, as written, seems to imply a non-IIIF rendering.

[jpstroop]

@mattmcgrattan, Now that I'm not typing with my thumbs....

If I recall correctly, the original use case came from @tomcrane, and had to do with the ability to provide a link to a PDF download. However, we said:

A link to an external resource intended _for display_ or download by a human user [...].

and the fact that we required a format and a label, e.g. (from 5.1):

"rendering": {
  "@id": "http://www.example.org/iiif/book1.pdf",
  "label": "Download as PDF",
  "format": "application/pdf"
}

Says to me that, e.g.

"rendering": {
  "@id": "http://digital.bodleian.ox.ac.uk/mything.html",
  "label": "View in Digital Bodleian",
  "format": "text/html"
}

is a reasonable use of rendering. @IIIF/editors, agree?

[mattmcgrattan]

Yeah, that works for me.

[azaroth42]

My initial reaction was the same - that's not what that is for - but on reflection it's exactly what we want. The provider of the manifest is explicitly linking to a rendering of the resource in html. It could be a iiif viewer or it could be totally custom, which is the spirit of the issue imo.

So :+1: from me.

[azaroth42]

Can we explicitly record the use case for the Image API please? Assuming we can use rendering, the problem is solved for prezi, so the requirement would be to justify duplicating it in info.json.

[tomcrane]

So now we have two options for xxx in

"xxx": {
  "@id": "http://digital.bodleian.ox.ac.uk/mything.html",
  "label": "View in Digital Bodleian",
  "format": "text/html"
}

related A link to an external resource intended to be displayed directly to the user, and is related to the resource that has the related property. Examples might include a video or academic paper about the resource, a website, an HTML description...

or

rendering A link to an external resource intended for display or download by a human user as an alternative rendering of the resource that has the property. Examples include a rendering of a manifest as the PDF or EPUB with the images and text of the book...

If the manifest declares the latter, it's "a rendering of me here" - which I agree sounds the right answer. I will change the Wellcome usage of it (currently "related" as in http://wellcomelibrary.org/service/collections/genres/Allegorical%20paintings/)

If we all agree on this, the Presentation API should make this use case explicit and draw attention to it as a recommended pattern for linking to the preferred viewing environment.

[tomcrane]

use case for the Image API

This gets a bit shakier because you might want "within" as well - the info.json is page 321 of a book.

[tomcrane]

make this use case explicit

I have dropped "alternative":

rendering

A link to an external resource intended for display or download by a human user. It is RECOMMENDED that this property is used to link from a manifest, collection or other resource to the preferred viewing environment for that resource, such as a viewer page on the publisher's web site. Other examples include a rendering of a manifest as a PDF or EPUB with the images and text of the book, or a slide deck with images of the museum object. A label and the format of the rendering resource must be supplied to allow clients to present the option to the user. This is a more specific relationship than the related property above, which could be any related resource rather than an alternate view of the resource.

[tomcrane]

Hmm, people might misinterpret that RECOMMENDED. Maybe drop the RFC2119 language:

... This property can be used to link from a manifest, collection or other resource to the preferred viewing environment for that resource, such as a viewer page on the publisher's web site. Other examples include...

[jpstroop]

I'd always assumed that related is about the resource where rendering is (some version of) the resource .

I think stating that rendering is a more specific version of related is misleading, so I'd rather see us drop that sentence.

[tomcrane]

So...

rendering

A link to an external resource intended for display or download by a human user. This property can be used to link from a manifest, collection or other resource to the preferred viewing environment for that resource, such as a viewer page on the publisher's web site. Other uses include a rendering of a manifest as a PDF or EPUB with the images and text of the book, or a slide deck with images of the museum object. A label and the format of the rendering resource must be supplied to allow clients to present the option to the user.

[jpstroop]

:+1: to @tomcrane's text. You could put the original use case first (EPUB, PDF) if you wanted, just because 😉, but I think overall this scopes the difference between the two properties more cleanly.

[azaroth42]

:+1: to @tomcrane's text as well.

Reiterating call for clear description of the requirement to add it to Image in addition to the clarification for Prezi...

[jpstroop]

I can't come up with one for image API, or at least I can't come up with one that doesn't suggest you should really be using the prezi API.

[jpstroop]

@tomcrane Do you want to make a PR for the revised "rendering" text?

@IIIF/editors does that text solve this whole issue, or is there more to do?

[azaroth42]

It does for me. :+1: but, again, we agree no change needed for image api, yes? Original issue says for both, so would like confirmation that we considered and rejected.

[mikeapp]

:+1: on rendering and the @tomcrane text, and leaving the Image API unchanged

[mattmcgrattan]

Any potential change to the Image API would also seem to go against the idea that the info.json is something that can be derived programmatically.

[jpstroop]

Agree with @mattmcgrattan, though we've already gone there to some extent by letting in rights info. Still, without a use case I'm for #654 putting this one to :bed:.

[glenrobson]

Regarding adding it to the image API, I think we discussed using sitemaps to allow discovery of IIIF images that weren't part of Manifests. If that is the case then the sitemap html links would probably be the link back link you could use rather than requiring anything in the info.json.