Question about approach for sequences in v3

[mejackreed]

I would be happy to help out on how manifesto might approach sequences in Prezi v3.

The two approaches I've thought about:

• Add 'get' canvas functions to ranges #79 seems to try and teach Range to behave more like a Sequence is there the desire to move that direction?
• Or would we want to teach getSequences to be able to parse v3 ranges that have the behavior sequence and return Sequence?

Has anyone else been thinking about support of this?

An example of a manifest hand crafted w/ v3 range sequences: https://gist.githubusercontent.com/mejackreed/a0c7e3ce7990042b2842980d136371d7/raw/manifest.json

[stephenwf]

Given that manifesto is an abstraction, I'd be inclined to agree with both implementations. Having a Manifest.getSequences() that returns a range or set of ranges, falling back to perhaps a virtual range with all canvases might be a natural way to surface that.

In that scenario we could build on the functionality of ranges and use them, as you say, as though they were sequences. It also raises the question that @edsilv has asked before about whether some of the utilities in Manifold should be part of manifesto. There is a lot of range construction and parsing there that could fit into this too.

@mejackreed do you know if the sequence behavior property limit how the range can be represented? Can it only be made up of a flat list of canvases without selectors? Can it be nested like other ranges?

[MImranAsghar]

Hi guys, the reason I made the changes in #79 of returning only top level canvases of the range, was because ranges with sequence behaviour are not nested. so basically, for sequences behaviour, top level canvases would be used according to their doc. These ranges (sequence behaviour) contain only flat list of canvases which are also being returned by getCanvases. But not too sure about whether selectors can be present in ranges with sequence behaviour though. If there are not selectors present with sequence behaviour, then I’m assuming maybe the changes in #79 (without fragment selectors part) would be sufficient?

[mejackreed]

From https://iiif.io/api/presentation/3.0/#54-range

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. These Ranges may have limited hierarchical nesting, but clients are not expected to traverse very deep structures in determining the default order.

That makes me think that we can make the assumption that behavior == sequence ranges should function like v2 ranges and are not nested.

[stephenwf]

That sounds easy enough, so maybe all we need is a getSequences() to return the appropriate ranges on a manifest?

[stephenwf]

And then with your changes @MImranAsghar in #79 we should have enough to gather the running order of the canvases.

[mejackreed]

One question that came to mind was should getSequences return proper Sequence objects rather than Range that could behave like sequence? Or does this matter? Feels more like a question about how Manifesto can interpret what the manifest presents, or should it properly cast IIIF resources.

[stephenwf]

Would the opposite work too? Returning Presentation 2 sequences as ranges as a way of moving forward with support for Presentation 3 as the mental model?

[mejackreed]

Yes, that could also work. I think we should determine how maybe manifesto wants to assert this going forward?

To get all of the sequence like things should I?

manifestoInstance.getSequences()

// or

manifestoInstance.getRanges().filter(r => r.getBehavior() == 'sequence')

// or both?

And should these have similar returns? Sequence[] or Range[] or?

[MImranAsghar]

I think using both would be okay too in case of v3 and just getSequences in case of v2.

[MImranAsghar]

Hi guys, I was wondering what you guys are thinking as final decision on this to proceed? I would love to work on any further changes that need to be made if that's okay.

[MImranAsghar]

I gave something similar a try here #84 which we can use in combo with #79 . Here getSequences return either sequence or range or both. Thinking that the reason we shouldn't just return ranges is b/c for v2, ranges shouldn't be representing seqs. So in that case it returns seqs like it used to, but for v3, ranges (seq behavior) are returned. what do you guys think? @stephenwf @mejackreed

[MImranAsghar]

Hi @stephenwf , did you get a chance to look at the above two pull requests?