0027 alternative page order

[glenrobson]

No description provided.

[glenrobson]

Use case:

Change:
current form to current order

Implementation Notes

Add a paragraph explaining the following from the spec:

"user interfaces that interact with this order should use the order within the selected Range, rather than the default order of items."

from the sequence text in https://iiif.io/api/presentation/3.0/#behavior

Add a paragraph explaining that behaviour of a range can be a list and could include individuals or paged alongside sequence if you would like the range canvases to be shown as paginated. Also note ranges can have viewingDirection in case of right to left ordering of pages.

Restrictions:

Sequence ranges need to be top order ranges (can’t be embedded in a table of contents). Text from specification:

“Ranges that have the behavior value sequence must be directly within the structures property of the Manifest, and must not be embedded or referenced within other Ranges." from https://iiif.io/api/presentation/3.0/#54-range

Example

• Example: Context should be a string
• Use minimum amount of pages to show issue. (~6)
• The editors would prefer real manuscript images. As the recipe is showing out of order as sequence a and in order as sequence b you could potentially use the picart_german images from UCLA: https://fixtures.iiif.io/. The canvas labels should show the page numbers to demonstrate the order.

Related recipes

Add a note to the table of contents recipe to say its an example of different way of using ranges. (for this type of note see: https://preview.iiif.io/cookbook/0045-css/recipe/0045-css/)

OK to go to TRC if its possible to get the items above done.

[glenrobson]

Also discussing renaming as alternative page sequences.

[kirschbombe]

I would put this up in the implementation section - this is just how it works, not a restriction.

[leontpng]

Good morning, and thank you for the feedback!
We included this in the Restrictions section because using Ranges for ordering purposes limits their use for other functionalities, such as a Table of Contents, which is also a common use case for book objects. We should probably make this more explicit.

[kirschbombe]

Not sure about this - it's not a restriction per se, just that if someone were to use no-nav the items wouldn't display. I'm not sure it needs to be mentioned as a restriction?

[leontpng]

For clarity, we can move this to Implementation. We considered this a 'formal' restriction of the specification since sequence is disjoint with no-nav or thumbnail-nav and must not be used together.

[kirschbombe]

The suggestion for other behavior properties was specifically about using paged or individuals to show that one can override the manifests behavior if resequencing affects the layout for some reason. As a general note about behavior being an array, I would probably remove it. Or, combine it with the paragraph below about viewingDirection and simply say that one can add the viewingDirection property and/or other behavior values to overwrite manifest values. As it is now, this bit it somewhat confusing.

[kirschbombe]

Here you mention representing the book in its current order, then having intended order as the secondary option, but the example shows the reverse - should the example match the use case as described?

[leontpng]

Thanks again for the feedback. With @giacomomarchioro's previous edits as base:

• I reordered some sections in Implementation for clarity
• I rephrased the Restrictions to explain what it means in terms of usability, not being able to embed or reference canvases
• I rephrased the Range properties section (viewingDirection and layout-specific behaviors besides sequence)
• I reordered the manifest structures to better reflect the use case

[giacomomarchioro]

I would change the title to Alternative page sequences as Glen suggested, this will make the recipe easier to find for user that used Sequences in the past implementation.