Remove Sequence (!)

[azaroth42]

Counter proposal to #1407:

Remove Sequence completely, and the Manifest has an items array of Canvases.

• The Sequence behaviors are already available for Manifest, and this simplifies where they live.
• The multiple sequence case is not implemented in current viewers after 5+ years, and there are no known instances of Manifests with second or further Sequences
• It simplifies the default case of Manifest -> Sequence -> Canvas to just Manifest -> Canvas
• Ranges no longer have to be concerned with which Sequence they're applied to
• Ranges are still available for reordering of the set of Canvases of the Manifest
• Can put 'non-sequential' on Manifest to solve 1407
• Can put 'hidden' on Canvases in the Manifest to have non sequential Canvases but are still described.
• Can use 'hidden' Canvases to have sub-canvases in the main bucket
• Gets most of the benefits of id map with losing the simple order use case

[tomcrane]

Side benefit - can't be tempted to model a multi-volume work with sequences.

[tomcrane]

The edge case of contested or alternative views of a manuscript can still be met, by publishing more than one manifest, one for each contested representation. At the moment, this use case is driving an extra layer of indirection in the spec that very few people (no people?) need.

[sdellis]

If it's strictly a list of Canvases, should the array be called canvases, not items?

[nicolasfranck]

That would definitely make it more simple but..

that would make it mandatory for a viewer to process the ranges? Now ranges are a nice feature on top of the manifest, showing a table of contents next to the slider of canvases. If I understand correctly, a range would also become a filter for the canvases listed below in the manifest?

[irv]

@nicolasfranck makes a good point; do we need some explicit semantics in a range to indicate it's the "preferred" view (a better viewingHint: top)? a lightweight client could then use that range rather than implementing the ability to display all ranges and switch between them.

[tomcrane]

The proposal doesn't change the function of Ranges or give them any mandatory extra duty. Imagine a simple thumbnail strip viewer, that just renders the canvases as thumbnails in their natural order. This viewer would now process manifest.items (the new list of canvases) instead of manifest.sequences[0].items (the old list of canvases).

The structures property would still hold the ranges, and be used by viewers capable of generating tables of content for navigation. Additional ranges could also be used for alternative ordering of the canvases, or any other structural information they are used for now.

Allowing 1..n sequences supports very specialist use cases that impose an extra layer in the model that everyone has to deal with, and those specialist use cases can be met by Ranges too.

[azaroth42]

@sdellis In v3, everything is items all the way down :)

@nicolasfranck A simple viewer would just display the array of Canvases in the order given, in the same way that viewers currently display the first sequence. Additional sequences could still become Ranges rather than separate Manifests, but the simple viewer wouldn't process them. That said ... most viewers don't process multiple Sequences.

[nicolasfranck]

Ok, I see. It is an edge case.

I am in favour of this simplification, but we should consider how to deal with this:

It is not always a question of reordering. Sometimes a range has canvases that others haven't. In that case the manifest cannot decide a good order of all possible canvases that a simple viewer could use. There is no default order.

use case: a manuscript has been recollected using pieces of paper found at different places, and scholars do not agree which papers should be included and in what order.

That been said, one can also use a different manifest, as a different version requires also different metadata to be shown. Maybe add a way to link to alternate versions of the manifest?

[tomcrane]

@nicolasfranck - this is #1407, but in the absence of sequence.

A manifest could have the new behaviour non-sequential to indicate that a client should defer to ranges for (possibly many) ways of navigating the manifest. (see #1417 (comment)). This pushes the edge use case to edge of implementations; if you happen to load a manifest like this in a very simple viewer it doesn't break it, but won't be able to convey the full richness (which is fine).

For linking to alternate Manifests, see #1251 (comment)

[ahankinson]

How does linking to alternate views of a manifest, through publishing multiple independent manifests, work within the context of a URI for the 'object' being represented?

Ex. we have a UUID, 1234-56-789 that represents a 'manuscript' within our system. Our URIs are then https://iiif.bodleian.ox.ac.uk/iiif/manifests/1234-56-789. If we have to have two separate manifests to represent alternate orderings of that manuscript, what URI/URL should we use to identify that single object?

[workergnome]

@ahankinson my feeling is that nowhere in the IIIF spec is there the idea that there is a one-to-one relationship between a Real World Object (a manuscript, say), and a IIIF Prezi manifest. That might be something that is done by convention by an institution, but that's not an assumption that's made in the system.

For instance, at the Getty, we've discussed, for a given Painting, have a Collections manifest, a Publication manifest (with book-specific images), and a "Conservation" manifest (with additional detail shots). There's not a good 'canonical' manifest, because they're all valuable, context-specific presentations of the object.

[ahankinson]

The 'real world' object is a useful abstraction in our case -- more specifically, we're using the UUID to identify the record that contains the digital representation of the real-world object. I think the ability to have a constant resource identifier is, if not in the IIIF spec, at least in the common understanding of how REST / URIs are supposed to function.

[workergnome]

I think the distinction I'm making is between an resource identifier for the object and an resource identifier for a presentation of the object. IIIF does not require that there's a one-to-one cardinality between these two things.

[ahankinson]

So if I understand your argument, you're essentially saying that we should be publishing our IIIF manifests as:

https://iiif.bodleian.ox.ac.uk/iiif/view/ABCD-EF-GHI/

and

https://iiif.bodleian.ox.ac.uk/iiif/view/LMNO-PQ-RST/

Which are both views on record 1234-56-789. Is that what you're suggesting?

[nicolasfranck]

@ahankinson the presentation api does not have any abstract parts, like a canonical manifest that should not be used directly but it alternate views instead.

[workergnome]

@ahankinson, that's what I'm suggesting--or that it's equally valid to have both

https://iiif.bodleian.ox.ac.uk/iiif/view/1234-56-789/

and

https://iiif.bodleian.ox.ac.uk/iiif/view/ABCD-EF-GHI/

but that both could be about record 1234-56-789. I agree that there's a need for a good way to point from the Real World Object to the manifest, and vice versa, but I don't think that URL comparisons is the right way to do it, because of the cardinality issue.

[ahankinson]

So in that case it seems to me that we have a different understanding of 'Presentation' in 'Presentation API' --

1.) Does 'Presentation' mean "I want to share a way of presenting a manuscript to a user in a viewer", i.e., the resource is the manuscript, and the Prezi API helps communicate all known views and information of the manuscript suitable for display; or

2.) Communicate independent views as "Presentations" as the resource, i.e., the resource is the view, and is an extra layer of abstraction on top of the digital object.

I have always operated under the assumption that the Prezi API gives us the ability to publish the record as an presentational abstraction of the resource, and not the view, but perhaps I'm wrong?

It would seem then that the 'cost' of removing sequences is that we need to publish largely identical manifests, with just slightly different orderings in the items array, and that it increases the complexity of publishing our records. So for the benefits of simplifying the spec, the complexity of implementing it is disproportionately increased for the implementers.

[jpstroop]

publish largely identical manifests

Or a single Manifest with multiple Ranges showing the different orders? Multiple Ranges isn't any more expensive than multiple Sequences.

[nicolasfranck]

I think it is more complex for the one implementing the viewer ;-)

[jpstroop]

Multiple Sequences vs multiple Ranges?

[ahankinson]

As discussed over coffee: Ranges are an option for multiple views, but would need clarity over the use of ranges for physical ordering (physical pages existing in multiple orderings) v. intellectual ordering (chapter 1, chapter 2, movement 3, etc.)

[jpstroop]

Beyond a label? A set of Ranges could represent anything kind of structure.

[ahankinson]

A range might control the presentation order of a set of canvases, so presumably the viewer would need to know how to do it -- e.g., when scholar X described MSS Y in the 19th C., it was in order Z, but when it was re-bound it was 'corrected' and modern ordering is now order Z^1. The modern scholar would want to switch the order of canvases between both order Z and Z^1.

That would be different than the intellectual ordering, which would be "Chapter 1 starts on Canvas N", which would be independent of physical ordering.

[jpstroop]

I get that. You'd have three ranges w/ "behavior" : "top". They could have different labels or even metadata if necessary.

[ahankinson]

Would we need to type the range, 'ordering': 'physical' v. 'ordering': 'logical'? How would a viewer know whether to use a range to re-order the thumbnail view in a physical ordering, vs. a range that represented a newspaper story on non-sequential canvases?

That is, if a range represents non-sequential canvases, how would a viewer know to not render them sequentially without an ordering hint?

[jpstroop]

Ranges are @lists. They're always ordered.

[ahankinson]

Sure -- I'm more asking how would a viewer know that a particular list should be reflected in the order of the image thumbnails in the viewer, v. the order of the labels in the TOC.

[jpstroop]

I'd think you'd default to Manifest.items, but I see your point.

[workergnome]

BL Meeting proposal:

We will eliminate sequences, and instead have an items property directly on the manifest, which contains the canvases included within the manifest.

We will create two new behaviours. One is sequence, valid for ranges, which indicates that this range should be used to represent the ordering of the content. The other is unordered, valid for manifests, which indicates that the manifest’s items are not explicitly ordered.

By default, a viewer behaves as if there were a range with the viewing hints sequence and no-nav containing all items, ordered using the order of items array on the manifest. If any ranges are explicitly tagged with the viewing hint sequence, the viewer MUST NOT create an implicit range, and should instead use the tagged ones. By default, the first range tagged sequence is the default.

[workergnome]

As a refinement--ranges with the sequence behaviour are only valid at the top level and can't be nested.

[zimeon]

Closed by #1471

[zimeon]

Discussed on 2018-02-28 Technical Community Call. Some discussion of authoring client behaviors and questions about whether hierarchical Range can be have sequence behavior (-> #1489). No objections to removing Sequence resources.