IIIF v3 canvas - requires a unique id

[ndushay]

per http://prezi3.iiif.io/api/presentation/3.0/#canvas

{scheme}://{host}/{prefix}/{identifier}/canvas/{name}

<snip>

If following the recommended URI pattern, the {name} parameter MUST uniquely distinguish the canvas from all other canvases in the object.  The URI of the canvas must not contain a fragment (a # followed by further characters), as this would make it impossible to refer to a segment of the Canvas’s area using the #xywh= syntax. Canvases should be able to be dereferenced separately from the Manifest via their URIs as well as being embedded within the Sequence.

See https://purl.stanford.edu/bd742gh0511/iiif3/manifest; this uses the same id for the pdf and for the txt file (also uses the same label)

[cbeer]

Do they not? We spent quite a bit of time last year during the spotlight-using-iiif sprint to remediate our resource ids so they'd be unique.

[ndushay]

they do not, unless I wasn't seeing what was there correctly. Take a look at https://purl.stanford.edu/bd742gh0511/iiif3/manifest and let me know if I'm wrong ... that would be an easy fix to this ticket!

[cbeer]

Ugh. I guess I didn't know we had resources that intentionally had multiple, published file entries. Maybe they belong on the same canvas? Time to follow up with @blalbrit, I guess.

[blalbrit]

@ndushay and @cbeer - this pattern is pretty widespread across our content. Most books that DPG has scanned have an image and a txt file published for each resource, for instance, and SMPL occasionally published multiple files per resource as well.

In the example Naomi provided, there is a legitimate question as to whether the txt file and the pdf should be in separate resources. Since the delivery mechanism, for the last x years at least, for an object like this was just a file list, we should break this one down a bit:

1. user expectation in the past was just "file list" because the object was a pdf and a file. It didn't matter to them whether the files were in a single resource or multiple resources.
2. our understanding of user expectation now for an object like this, based on access team requirements, is presumably "viewable pdf + downloadable text file"
3. IIIF (2 and 3, I think) could support this pattern through the use of "rendering" - http://iiif.io/api/presentation/2.1/#rendering

However, I'm finding it very difficult to understand how we can support all of the combinations of "rendering" without significant analysis that was not resourced or scoped for the current sprint - which was focused entirely on support for PDFs and 3D objects, alongside our usual image objects.

Some common patterns are:

1. images of book + downloadable pdf (manifest level rendering)
2. images of book + page-level text files + downloadable pdf + downloadable text file (manifest and resource level rendering)
3. media file + thumbnail (resource level rendering)
4. multiple representations of the object (as Naomi's example) where the PDF is the deliverable file and the text file is a downloadable ancillary file. (possibly resource level rendering, or manifest level rendering)

That's just off the top of my head, and we would need to set aside significant time to make sure that we were covering all the patterns in the repository.

[blalbrit]

Since @snydman is the major stakeholder representative here, and the support for PDF, 3D, and IIIF3 fell into the "should have" category for him, not the "must have", I would like for him to weigh in here as far as delivery expectations go.