Do not deprecate embedded info.json in prezi3

[azaroth42]

It was asserted in Image 1.0 days that people would embed the info.json response in Presentation API manifests, as an optimization to prevent needing to retrieve the document.

If there are no examples of this in the wild, having had 4 or 5 years and two major versions to do it, I suggest that we deprecate this in favor of simplicity and easier cross-version compatibility

[zimeon]

👍 agree with proposal and rationale

[jpstroop]

Ditto, especially given #1068

[mikeapp]

👍

[azaroth42]

Discussion on 08/30: Agreement.

[tomcrane]

Apologies for being late to respond, but I do have a case for including information normally found in the info.json response directly in the manifest, and therefore requiring the image API context.

Example - https://wellcomelibrary.org/iiif/b28117542/manifest

Each canvas has a thumbnail, with a service. The service provides level 0 access to a set of four pregenerated thumbnails. While the UV and Mirador don't yet use this kind of information. it has proved very valuable in developing client applications that can make a decision about what thumbnail to request for each canvas, without further HTTP requests.

That is, the presence in the manifest of information about all available thumbnails enhances the user experience significantly, when dealing with lots of thumbnails on screen at once. It allows the publisher to provide a choice of thumbnail sizes directly in the manifest ("please use these sizes for enhanced user experience").

"thumbnail": {
    "@id": "https://dlcs.io/thumbs/wellcome/1/70cce4af-f841-4757-b0b8-c5fa1aedd18f/full/71,100/0/default.jpg",
    "@type": "dctypes:Image",
    "service": {
        "@context": "http://iiif.io/api/image/2/context.json",
        "@id": "https://dlcs.io/thumbs/wellcome/1/70cce4af-f841-4757-b0b8-c5fa1aedd18f",
        "protocol": "http://iiif.io/api/image",
        "height": 1024,
        "width": 730,
        "sizes": [
            { "width": 71, "height": 100 },
            { "width": 143, "height": 200 },
            { "width": 285, "height": 400 },
            { "width": 730, "height": 1024 }
        ],
        "profile": [ "http://iiif.io/api/image/2/level0.json" ]
    }
}

The images that annotate the canvases have full-feature Image API services (level 1 or level 2), but a wise client doesn't have to go near them to be confident of generating a field of thumbnails for all the canvases very quickly, because these hints directly in the manifest provide what it needs to construct thumbnail requests.

[jronallo]

I just discovered yesterday that the Bodleian manifest editor embeds the info.json in the manifests it creates. http://iiif.bodleian.ox.ac.uk/manifest-editor/

[glenrobson]

At NLW we embedded parts of the info.json as a matter of course: http://dams.llgc.org.uk/iiif/2.0/1/manifest.json. This is probably a hangover from the version 1.0 implementation.

[azaroth42]

Given that there actually are implementations, new proposal is to close wontfix and continue to allow embedded info.json. (c.f. #1269)

[zimeon]

👍 agreed not to deprecate at Toronto WG meeting. So, no-op. Closing.

[azaroth42]

Re-opening for the cross-version issue, as opposed to the lack of use.

Per #1349, as far as I can tell, we either deprecate embedding earlier versions or we can't have consistent data structures. I prefer consistency for everyone over utility for a few.

[tomcrane]

I realise I am the one of the (very) few mentioned, but I am very strongly in favour of the pattern for one specific use case, and have been trying to encourage support for it from publishers and in viewers. The ability to embed the available preferred sizes of canvas thumbnails in a manifest yields a huge performance benefit which we use in several tools and bespoke viewers. I think this is in a different category of optimisation than, say compacting repetition in anno lists. See example above - #1217 (comment) - it can mean the difference between one and hundreds of HTTP requests.

[tomcrane]

An alternative pattern would be to list the images as distinct resources (i.e., no service) - the above example would be 4 image resources for the thumbnail property (with their sizes, obviously). This has the disadvantage of not being consumable by OpenSeadragon and other Image API clients, as it's not an info.json. However, the utility of the pattern is for higher level Presentation API clients, so this is not a disaster.

[tomcrane]

To clarify, instead of the level0, sizes only version above, I'd have:

"thumbnail": [
   {
    "@id": "https://dlcs.io/thumbs/wellcome/1/.../full/71,100/0/default.jpg",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 71,
    "height": 100
  },
  {
    "@id": "https://dlcs.io/thumbs/wellcome/1/.../full/143,200/0/default.jpg",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 143,
    "height": 200
  },
  {
    "@id": "https://dlcs.io/thumbs/wellcome/1/.../full/285,400/0/default.jpg",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 285,
    "height": 400
  },
  {
    "@id": "https://dlcs.io/thumbs/wellcome/1/.../full/730,1024/0/default.jpg",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 730,
    "height": 1024
  }
]

[tomcrane]

HTTP2 solves some aspects of this, but by no means all of them.
Sprite sheets also make for an enhanced user experience; I would add one or more additional images to the above, after the normal thumbs, where the same sizes can be used by a sprite-sheet-aware client:

  // ... regular thumbs, then:
  {
    "@id": "https://dlcs.io/thumbs/spritesheets/.../thumbs_200.jpg#801,801,143,200",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 143,
    "height": 200
  },  
  {
    "@id": "https://dlcs.io/thumbs/spritesheets/.../thumbs_400.jpg#1601,1601,285,400",
    "@type": "dctypes:Image",
    "format": "image/jpg",
    "width": 285,
    "height": 400
  }

But that's one for the cookbook, not this issue. Of interest to @aeschylus.

[azaroth42]

Reclosed by #1408

[eroux]

I concur with @tomcrane here, we serve volumes with about 600 pages in average, and loading thumbnails is already taking quite a lot of resources and requests, so if we can avoid multiplying the requests by 2 that would be great. Requests cost time when they are on distant servers (we have our servers in the US but users in China), and we don't want to double that cost if we can avoid it...