Publish Presentation 4.0 Release Candidate

[glenrobson]

Links

• Original Issue: https://github.com/IIIF/api/milestone/31
• Pull Request: Presentation 4 api#2316
• Preview:

Specification: https://preview.iiif.io/api/prezi-4/presentation/4.0/
Model: https://preview.iiif.io/api/prezi-4/presentation/4.0/model/

Background and Summary

The Editors and the 3D TSG have worked tirelessly to add support for 3D to the IIIF specification. There has been much back and forth and lots of experiments and early implementations as the spec has developed. We have now reached a point where the specification is ready for review by the TRC.

The specification has been split into the main specification introducing the concepts and classes as use cases and a model document which gives the formal definitions of classes and properties.

In addition to the 3D support the specification introduces a new provides property to support accessibility use cases.

If approved by the TRC the prezi-4 branch will be merged into the main so the version 4 specification will be available from the IIIF website. It is proposed that the specification is noted as a release candidate which indicates the specification is stable and unlikely to change significantly prior to final publication.

Proposed Solution

1. Merge the prezi-4 branch
2. Publisise the release
3. Call for implementation

[cubap]

This has been so fun to follow. The spec is very well written but it is also considerate of how it will be consumed and where its limitations are. I want to start with this applause so that I can #YellAtClouds.

Old Pains

This addresses the 3D use cases very well and represents a positive advancement for IIIF Presentation. It has also reopened criticism I had during the 2 -> 3 move. Specifically, the choice was made not to proliferate "IxIF" specifications and to instead add A/V to the same spec that covers images. This was a real choice and at the time, since so many things were also changing in the syntax and form of the spec for images (and the alignment of Web Annotation), but it is still costing us.

Analogy to Illustrate:
If I were writing an Android app and designed it for compatibility with tooling from much older hardware and software, it may be an advantage to tell users "The minimum Android Version for this is 4.3!" That feels good and unless I require new security or hardware permissions, I would like to target the oldest responsible version that exists.

As a developer, I do this in web applications and pages, eschewing a new feature or allowing it to fail gracefully if a user with a legitimate but older setup is looking for access.

In these standards, there is no way to do this. Even if my Manifest file is exactly the same and works in presentation/3/ and presentation/4/ contexts, one might be served by a viewer and one might be unrecognized.

We know that this matters. In the Image API we have the concept of compliance. The host can let consumers know that there are limits to what we are able to do. This type of 'feature detection' is exactly what is now needed for Presentation API. The new viewer I build needs to check every Manifest now, not for the @context, but for all the resources within it so I can warn a user that I was built to support audio and images, but not video or object models. There are loads of viewers and repositories out there still driving Presentation 2 for legitimate reasons. If just switching the @context from "3" to "4" works for my photograph, then there were no breaking changes and semantic versioning says I shouldn't "upgrade" my JSON-LD.

We are continuing to build out an environment where my default expectation is that the Presentation specification allows for resource and preference types that I have no intention of supporting and have no way of communicating or discovering that limitation other than rolling my own feature detection matrix. In Presi 2, a Canvas had to have dimensions; adding audio only Canvases voided that promise and created a point of conflict that a viewer now had to test for with every resource. In Presi 4, there are literally new Classes of things to process before getting to the presentation part.

Save the Baby

There are reasons why if I'm driving a simple, old Manifest of boring old 2D pictures of some old codex that I may want to update to Presi 4. The way provides and activating describe interactions or supplementation is truly helpful, for example. When IIIF developed opinions about how label worked and noted that is was a collision with Web Annotation, it was separately made part of Presi 3 and Image 3. Presi 4 shows us how we could build a specification that "contains" the resources and describes them in a way that is useful and helpful for "presenters" to show them. In this way, an extension, like navPlace that is added to a Manifest would naturally apply to everything, but if I wanted to "copy" the functionality of a directional light from the Scene into a new RTI implementation for a "Canvas" resource, it would need to be explained and versioned into that container specifically.

Sample Cases

I have two real use cases at the moment that demonstrate the trouble.

Case 1: Movable Parts represents trying to encode and describe an intended interaction with a flat photograph or fragment thereof. The simplest case here is an annotated playing card. Presi 3 already tells us how to show each side. Web Annotation allows us to align them. Nothing stops the Manifest from being viewable in a common viewer. A new extension for interactions in 2D could easily enhance the intended presentation of this resource to see backside annotations and animated flipping for cognitive consistency as shown in the demo.

The Presi 4 activating or description of animations is exactly the type of thing needed here. It is not, however, exactly what is needed. It is silly for any of us to hound the Presi 4 team to make sure that all cases are covered in the new version, but why does the scope have to be so broad? A smaller team reusing and porting the idea of activation and animation into a 2D context so it works in Scenes and Canvases in its own, carefully described way would be much more efficient.

Case 2: Alternate Imaging covers all the specific purpose built mini-viewers I've made or seen for 2D that escapes the default.jpg box. Musical scores and opacity sliders and stereographs and infinite zoom and interconnected panes have all been demonstrated. RTI Images is an interesting one because the technology is literally decades old (I put this up a decade ago) and the implementation is very simple and very 2D. Again Presi 4 introduces some fun ways of considering position and lighting in a Scene that is exactly the type of interaction needed in RTI images but incompatible with the way it restricts the type of light and requires a normal map to render.

The result of these cases, if implemented, will be terminology and description frustratingly close to what's in Presi 4 right now but different enough to avoid collision when the implementation requires different data schemes. Worse, even if it is just an extension in how an Annotation might be considered and fully compatible with Presi 3, it will be a regression to "extend Presi 3" when Presi 4 is sitting right there. An extension could be proposed for both, but as it would be identically applied to the Canvas class, it would feel silly.

That is to say

I love this work. I will support and use IIIF Presentation 4 and look forward to its implementation. I cannot vote it down because I do not think it is in the scope of this release to change the overall structure of these standards. Seeing that there are already frustrating cracks, I don't think these habits will carry forward to Presi 6 and so I MUST 😕.

[tpendragon]

Hi all - this is great work! I haven't been keeping track of all the various decisions along the process. Right now I'm not giving either a 👍 or a 👎 because as I read the specification I find myself confused that it accepts both GLTF for scene rendering and presents itself as another spec to generate all the various aspects of a scene that I'd expect GLTF to do - cameras, lighting, applying multiple models in a scene, defining animation, etc.

Is this a competing specification against GLTF? Was something missing from GLTF that meant we couldn't, similar to how we'd done with video, simply accepted that as a format type to paint on a canvas? I assume there was, but without understanding that I don't feel like I can give a definitive yes or no.

Other than that I think everything's great and I understand the use cases clearly. Migration doesn't seem particularly challenging, which I love.

[azaroth42]

Thanks Trey!

It doesn't compete with GLTF, but does need to take into account model formats that don't have GLTF's capabilities. Some of the other formats don't have lights, if I recall correctly. Also, we thought it was important to be able to have some control over the lights and cameras at the IIIF layer for when multiple models with their own lights and cameras are included -- we don't want to force the client to randomly pick one.

Or, perhaps most clearly, the situation where the content can be rendered in 3d as a presentation, but isn't itself 3d. Not sure if you've seen it but if you recall Ed Silverton's playing cards floating in space, that would be a bunch of Canvases laid out in a Scene. In that case there's no model to render, but we still need to define the lights and cameras.

We don't define animations in 4.0, but we felt we needed to be able to refer to existing animations to be able to start, stop and reset them. They're a bit like video in a Canvas without duration: there's no control over the animation (it's either playing or not) like there's no alignment of the video to a global timeline so the video is similarly just playing or not.

[tpendragon]

Some of the other formats don't have lights, if I recall correctly.

Yeah, lights uses an extension: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_lights_punctual/README.md (which is real common is my understanding - like software will export that extension).

I'm hearing the justification is something like "GLTF is harder to write for the typical user base of IIIF than a IIIF manifest"? That same "cards in space" situation should be definable in GLTF too, it'd just be three planes with an albedo on each I think.

I'm also hearing "we want to support 3d formats that GLTF doesn't support" - also interesting. Thank you for that - I'm not surprised this is well trodden ground, is there some agendas or something I can look at to get more fully behind it?