IIIF Content State API 0.9

[glenrobson]

Links

• Pull Request: Content State 0.9 Candidate api#1986
• Preview: https://preview.iiif.io/api/86a-content-type-for-content-state/api/content-state/0.9/

Background and Summary

Content State is a new specification to enable the sharing of a view or state of a IIIF resource between viewers. This work grew out of the IIIF icon drag and drop prototypes that were done back in 2015. Although this has been widely implemented in viewers after further discussion it was pointed out that it isn't very accessible and also can be quite difficult to use. The Content State specification aims to allow numerous methods of translating the state between viewers and supports the following interactions:

• Drag and drop
• Adding a iiif-content parameter to a viewer URL
• Copy and paste
• Posting to a 3rd party service like a Bookmarking or Citation service

The state of the viewer is encoded as an annotation which allows the transmission of complex state properties like transferring a two up view, search results and the point you are viewing in a video.

Proposed Solution

This is the first time Content State has been shared with the TRC and the Discovery TSG believe that the specification is ready to be implemented. By approving 0.9 we are calling for implementation experience so that we can move to a 1.0 release version.

[tomcrane]

Non-technical description of Content State:

https://tom-crane.medium.com/what-is-iiif-content-state-dd15a543939f

[julsraemy]

I voted 👍 but I had a question related to the support of complex Content State constructions by IIIF viewers and if we would need some kind of level compliance like in the Image API. For instance, if we want more than one Manifest to be open side-by-side, only Mirador could support this. What would happen when someone try to decode such a Content State base64url on the UV or Tify?

[tomcrane]

It is true that all IIIF clients will not be able to process all content states, just as all IIIF clients don't support all features of the Presentation API. For example a simple thumbnail-strip renderer of a manifest is a client of the Presentation API, but ignores most of it.

I think this is the same question as Presentation API compliance:

IIIF/api#76
IIIF/website#58

...with the same difficulty of formalising levels of compliance. I favour leaving it up to viewers to decide what to do with content states they can't render / don't understand. In this specific case, if the content state has targets in more than one manifest, a single UV instance could just alert the user that they are only seeing the first because one UV on its own is not a multi-manifest environment.

[julsraemy]

Agreed to leave this up to the clients. I hope the D4H Group can come up with best practices.

[mcwhitaker]

Would it be possible for the client to give the user the choice between multiple manifests in a content state when only one can be displayed? This would allow the user to use that same content state in multiple windows to mimic the experience.

[triplingual]

In the example of directing a video to start playing at a timepoint in a recording, what's the difference between using Content State and using the prezi 3 start property? I think I get it, but I could stand having it spelled out.

[tomcrane]

The value of the start property is the same thing in both cases:

In a manifest:

{
   "id": "https://manifests.org/mymanifest",
   "type": "Manifest",
   "start" : X
}

in a content state annotation:

{
  "id": "https://example.org/import/2",
  "type": "Annotation",
  "motivation": ["contentState"],
  "target": X
}

... where X is the SpecificResource that identifies the starting point.

In the manifest the start property is doing the pointing, in the anno the target is the pointer.

[regisrob]

JSON snippets in section 4. Examples of Content States and 2.2.5 Limitations of Simple URIs still have "http://iiif.io/api/presentation/0/context.json",
while 2.2.1 Full Annotation has "http://iiif.io/api/presentation/3/context.json" (which seems to be the correct one)

[regisrob]

Unless I missed it, it is not explicitely stated that partOf MUST be an array of JSON objects in a content state: it is only implied by the fact that this property is reused from the Presentation API 3.0. I think this is not obvious, all the more as most of the time a Canvas will be "part of" a single Manifest. So maybe the MUST should be explicitely indicated in the Content State API, or at least there should be a link to the partOf section of the Presentation API, or both?

[azaroth42]

Regarding start ... the start of a Manifest is asserted by the publisher for the Manifest's content, and so all consumers will get the same value in an easy to understand way. The benefit of content state is being able to have viewers that are interpreting the particular content state annotation to start at a different point, as appropriate to the use of the particular content state annotation. So I could create a content state that says "start at canvas 8 after the introduction because you don't need to read that", where the start of the manifest would say "start at canvas 2, after the cover and inside cover"

[glenrobson]

Issue 70 (IIIF Content State API 0.9)

+1: 29 [awead azaroth42 brndgtl cjnishioka cubap dlpierce emulatingkat hadro irv jcreel jonhartzler jtweed julsraemy kirschbombe ksclarke mattmcgrattan mbennett-uoe mcwhitaker mikeapp mixterj nfreire regisrob rentonsa shuddles thehabes tomcrane tpendragon triplingual zimeon]
0: 0 []
-1: 0 []
Not TRC: 0 []
Ineligible: 2 [beaudet gigamorph]

Result: 29 / 29 = 1.00

Super majority is in favor, issue is approved