Sammelbands and IIIF

[Trey Terrell]

In looking over our use cases for Sammelbands (individual books which have been bound together) and creating a presentation manifest for them, I've run into a conundrum.

Take a sammelband with three books, a front cover, and a back cover. In my mind this is three manifests and two canvases (in PCDM it would be a pcdm:object with three objects and two files, ordered appropriately). However, only a collection can have "manifests", but a collection can't ALSO have canvases. Further, even if a collection (or even just a manifest) COULD have both manifests and canvases, they couldn't be ordered with regard to one another.

The solutions that come to mind are these:

1) Don't have "sub-manifests." For the presentation manifest render all those pages as canvases and use ranges to group them appropriately into books. This is theoretically great, but that book's valid outside the Sammelband context, and it's a shame that the manifest URIs would be different. Further, you lose "load on demand" of those images in a viewer context.

2) Create manifests for the "title" and "back covers". Besides feeling heavy-handed (and maybe less important for IIIF, kind of a pain to implement, as the mapping from internal structure to IIIF wouldn't be 1 to 1), it just...feels wrong. Resolvable manifests for "covers of this sammelband" seems odd.

Thoughts? Other solutions? The only way I see to fix this at the spec level would be a pretty large change - something along the lines of "elements" instead of "canvases" and "manifests." Or allowing sequences to have child manifests? Who knows.

[Drew Winget]

I see what you're saying, but it seems to me that representing the whole Sammelband as a manifest and using ranges to identify the sub-books is at very straightforward solution. There is issue #646 that I think will solve your problem. Briefly, it proposes a way to specify the ordering of canvases with respect to ranges within the same range. So, for instance, your front cover and back cover might be canvases of the same top-level range as the three sub-ranges representing the three bound works.

However, this still seems somewhat moot to me. For logical ranges (tables of contents) used for content navigation, canvases shouldn't be included in some order in the display. In a book, the individual pages of the lowest-level sections are not listed separately. If something needs to be a navigation group, a range can be created for it. In the case of physical ranges (structural description), why not create a range for every structurally relevant piece, including canvases?

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Sanderson]

Drew, that's option 1 of Trey's suggestions ... and I think it's the best answer, at the moment.

There would be four manifests total: one for each of the three books that could be treated separately and one for the combined object.

The canvases in those different constructions could all be the same (e.g. have the same URIs) such that annotations will be shared correctly.  And any ranges that stay within a single book could be shared as well.

If the cover canvases of the combined object were not important, then the easy solution is a Collection with viewingHint of "multi-part" that collects together the three manifests.

HTH,

Rob

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Drew Winget]

Ah, yes, I lost my way while writing the second paragraph. I wanted to ask about including the canvases alone from other manifests representing the individual interior books. I'm glad to hear it would work like you're describing, however, I think this will be difficult in practice because canvases and ranges are not required to have dereferenceable @ids. 

The same canvas, with the same images on it, etc., can have a different @id, and that @id is not required to be dereferenceable. This also makes it difficult to build tools that recompose manifests from canvases taken from existing manifests. In theory a canvas is an independent object, but in practice it has to be copied into a target manifest and any modifications will yield a very different canvas (with new images, rotated images, removed images, etc.) that may still have the same @id (the opposite problem as above).

Does this mean it's the server's responsibility to duplicate these canvases in both serializations (the parent, and the separate manifests for each of the implicit children)? That's fine if it is, but it seems the community hasn't decided yet if there should be conventions around this.

[Trey Terrell]

> Does this mean it's the server's responsibility to duplicate these canvases in both serializations...

Yup, at least that's how it'd have to be done right now. I agree that as is Option 1 is probably the best, but it's a shame I lose the "load on demand" functionality I can get from Collections this way - I have to serve up all canvases from all N bound books all at once.

[Trey Terrell]

Just a heads up - we went with Option #1. For ranges, in the case of a sammelband it merges the volume's structure underneath a node for that volume. The manifests are very large, but it loads up and displays in Universal Viewer quite nicely. Haven't played with embedding metadata at the range-level yet (since the volumes have metadata), but I don't think UV supports that anyways.

Thanks for the help,

Trey

[Tom Crane]

Hi Trey,

There's a discussion about context-specific metadata in the UV here: https://github.com/UniversalViewer/universalviewer/issues/188

Tom

[Shaun Ellis]

Trey, have you been following the discussion in issue #697 as well?  Just want to make sure you're not painting yourself into a corner as it is related to the Sammelband use case and not yet resolved.

-Shaun

--

[Trey Terrell]

Hey Shaun,

Yup, I'm following. No worries about any corner painting, wouldn't take much work to change the implementation if something more suitable appears. Thanks for the warning, though.

Trey