Where do I put multi-volume items in an iiif:collection?

[jpstroop]

Surfaced by @tpendragon:

In 2.1 we defined the viewingHint "multi-part", which is:

Valid only for collections. Collections with this hint consist of multiple manifests that each form part of a logical whole. Clients might render the collection as a table of contents, rather than with thumbnails. Examples include multi-volume books or a set of journal issues or other serials.

So we seem to agree that the way to describe a multi-volume bookset is with a collection that lists n references to manifests. However, when I have a collection that contains single and multi-volume books, it feels awkward to put the multi-volume books in collections : [ ] and the single-volume books in manifests : [ ] when they're really meant to collectively comprise a sigle collection regardless of these physical characteristics.

Proposal (not sure I like it, but may as well start somewhere...): recommend using the current properties when you're in a 'mixed-content' situation (i.e. have a collection that includes items AND actual sub-collections), and add a new property "members" that is less opinionated and can contain both. We'd need find or define a predicate for the context as well, and I'm not quite sure how this would fit into the SC model.

[tomcrane]

I have this need too, and I get round it currently with a bit of a fudge:

http://wellcomelibrary.org/service/collections/topics/Physiology,%20Pathological/

There are 5 books in this category, so I'd like to show 5 IIIF resources together.

One of these manifests (http://wellcomelibrary.org/iiif/b18031511/manifest) is not really a manifest; the server redirects to http://wellcomelibrary.org/iiif/collection/b18031511. I'm not suggesting this is the answer, it would be solved by a collection that could accommodate both.

The other reason (or excuse...) for this redirect behaviour is to have a consistent guessable URL for an IIIF resource given a Wellcome Library identifier:

http://wellcomelibrary.org/iiif//manifest always works, but it redirects to a collection for a multi-volume item.

[azaroth42]

To restate the issue slightly ...

It is currently possible to have collections and manifests within a collection, but it is not possible for them to be interleaved in a single ordering. The cause of this is the separation by type (collections and manifests) rather than by the reason that the resource is included in the collection (hierarchy of collections, versus leaf nodes in that hierarchy regardless of type). This was not obvious in 2.0, as 2.1 introduced the pattern of using a Collection for a Multi-Volume Work, which should be a leaf node but must go into collections.

Yes?

And thus we can (1) have a single ordered pool of members:

{
  "@type": "sc:Collection", 
  "members": ["Collection1", "Manifest1", "Manifest2", "Collection2", ...]
}

Or we can (2) separate hierarchy from leaves, without assuming type:

{
  "@type": "sc:Collection",
  "subCollections": [ ... ],
  "objects": [ ... ]
}

The advantage of (1) is that we accommodate future situations where the split is not hierarchical, but at the expense of always having to include information about the member resources to distinguish hierarchy collections from MVWs. (1) is debatably backwards compatible, and (2) is definitely not.

[sdellis]

Or, to keep things backwards compatible and simple, we could (3) add an optional "collections" property to Manifests to cover the MVWs cases.

[jpstroop]

@sdellis

Or, to keep things backwards compatible and simple, we could (3) add an optional "collections" property to Manifests to cover the MVWs cases.

How does that solve it?

{
  "@type": "sc:Manifest", # Assuming I am a book
  "collections": [ ]  # what goes here?
}

@azaroth42 Why is (1) debatably backward compatible? Because we're changing the rules for collections and manifests? I agree that it's messy, and that we'll have a hard time clarifying when to do which, but I don't think adding something new constitutes a breaking change.

[tomcrane]

It's not breaking, but maybe it's debatable because it means crawlers that are scraping the IIIF Universe as per Presentation 2.0 will stop finding all of that content if publishers move some if it to a new members collection.

That might not be a real problem.

[jpstroop]

Yeah, that's what I mean by changing the rules. But, it seems like this should have come up earlier if there are really a bunch of a implementers who care.

[sdellis]

@jpstroop : It solves it by allowing manifests to be members of another manifest (that gets treated as a "leaf node" even though it combines other works):

{
 "label": "I'm a Multi-Volume Work",
 "@type": "sc:Manifest", 
 "collections": [{
    "@type": "sc:Collection",
     "manifests": [
        { "@type": "sc:Manifest" , "label": "Volume 1" },
        { "@type": "sc:Manifest" , "label": "Volume 2" },
        { "@type": "sc:Manifest" , "label": "Volume 3" }
     ]
}]
}

This could be simplified to something like below, but I could see the need for the hierarchy to go deeper and we already describe the collections object in the API. I advocate for the example above, but would be satisfied with either.

{
 "label": "I'm a Multi-Volume Work",
 "@type": "sc:Manifest", 
 "manifests": [
    { "@type": "sc:Manifest" , "label": "Volume 1" },
    { "@type": "sc:Manifest" , "label": "Volume 2" },
    { "@type": "sc:Manifest" , "label": "Volume 3" }
 ]
}

[jpstroop]

I see. The second did occur to me, but I feel as though the line between collections and manifests gets even blurrier then. I suppose doing that and taking away viewingHint="multi-part" (which we've only added in this unreleased draft) could be an option.

[zimeon]

I feel that Rob's suggestion (1) of a collection being an ordered set (list) of members separate the their type is the cleanest from a model point of view.

If in suggestion (3) a Manifest may contain Collections of other Manifests then I'm not sure what the remaining purpose of a separate Collection type is.

[azaroth42]

Re breaking-ness, the implication of the spec currently is that everything goes in those two slots. By introducing another place, we're changing the implication. I'm not putting a stake in the ground that it's breaking, I'm just raising an interoperability concern.

Re Manifests of Manifests ... it seems like the super-manifest is a Collection. Agree that there's essentially no distinction between collections and manifests at that point, AND we would have the problem of how to interleave manifests, sequences, ranges and canvases.

[sdellis]

@zimeon in case there's any misunderstanding, (3) also provides an ordered set that serves the purposes of this use case. Also, can you clarify what you mean by "clean" from a modeling standpoint?

Even if collections could be perceived (or serve even) as super manifests, it does not mean that there is no distinction between them. Manifests are treated as leaf-nodes while collections are not. Manifests can contain sequences, ranges, and canvases while collections cannot. (And for what it's worth, I think @jpstroop is right about there being no need to have collections on manifests, as recursive manifests would fulfill the need.) Given this, I find it hard to understand what you mean by no distinction. Keeping them in separate lists further emphasizes that distinction.

@azaroth42 if I understand your interleaving problem correctly (covers, pages between volumes, etc) , I don't see how any of these approaches handle that with the examples given, unless you were implying that the members list could have canvases as well. If any list is going to have combined models for ordering purposes, I would say that sequences make the most sense, since their sole purpose is to provide order. Combining manifests and canvases in the sequence of a Multi-Volume Manifest would be one solution to the interleaving problem with the "manifests of manifests" approach (3).

[mikeapp]

I also find Rob's (1) more appealing. The collection serialization already requires the @type, I don't see that we lose anything from the client perspective if we have a single list (and require the viewingHint for MVWs). I'd imagine there are non-MVW cases where having an ordered list containing both collections and manifests would be useful.

I assume the interleaving problem requires creation of separate manifests for the covers, etc.

[jpstroop]

Rob's (1) is essentially what I initially proposed. I still don't love it, but I don't think I can come up with anything better. While the recursive manifests + dropping viewingHint="multi-part" does have some appeal, I think it would quickly be abused and potentially confused with the function of Ranges.

@mikeapp I think the interleaving problem @azaroth42 is talking about is "I have some manifests, and some collections and I want to present them in a specific order". It sounds like you you might be talking about Sammelbands?

[mikeapp]

Yes, the Sammelband use case seems like the derivative of the MVW, perhaps needing its own viewing hint? I assume that's what @sdellis is referring to by the possibility of including Canvases in an MVW collection.

[sdellis]

Yes, @mikeapp, I was referring to the Sammelband use case (thanks for clarifying @jpstroop). So, if Sammelband cover and inserts are intended to be represented by manifests, and if MVWs can be described by allowing "recursive manifests" (3), then these MVW use cases can be addressed without a breaking change. The "members" approach would also solve this, but it is a breaking change and allows some collections (distinguished by a "hint") to be considered as "works", which I find "unclean" from a modeling standpoint.

That said, as @mikeapp mentioned, the "members" approach (1) may be useful for another (yet undefined) use case that requires an ordered set of mixed collections and manifests. The only use case I can think of for this is perhaps archival collections. That seems like a different problem to me, but perhaps there's an interest in solving both of them by the same means? If so, let's define all use cases we're trying to address with the same change before proceeding.

[azaroth42]

Is this a Prezi 2.1 or Prezi 2.2 issue? If we're confident in the members solution, I'm happy with 2.1, but do we have people explicitly stepping up to implement it?

[jpstroop]

This is a blocker for us. We could certainly implement it from the creation side; would UV be interested in supporting rendering?

-Js

Sent via mobile. Please excuse typos, brevity, etc. On Jan 29, 2016 11:13 AM, "Rob Sanderson" notifications@github.com wrote:

Is this a Prezi 2.1 or Prezi 2.2 issue? If we're confident in the members solution, I'm happy with 2.1, but do we have people explicitly stepping up to implement it?

— Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/697#issuecomment-176840710.

[azaroth42]

I think the interleaving is beyond the Sammelband case. If you have a manifest that contains sequences, ranges and (recursively) manifests, we've simply moved the problem from collections down a level to also having it at the manifest level. Anyway, everyone is :-1: on that anyway.

---

For the Sammelband case, the currently adopted approach seems (still) correct. To make sure I understand the approach, as we've seen it already long ago at the BNF (1 codex that was rebound into 4 codices in the 1700s, with fly leaves and bindings ... so the inverse) ...

• Each state that should be discoverable and renderable as a completely separate object has a separate manifest
  • Thus there would be 5 manifests for BNF (original combined, plus four current), and 3 (original two, plus current combined) for the exemplar Princeton case
• If the same page is used in multiple manifests, then the same canvas URI is used. Otherwise it's just a canvas (e.g. the flyleaves and covers) that exists only in that manifest
• The combined manifest has ranges for the sections, that could be linked to the external manifest to pivot out to

Yes?

[jpstroop]

Just to clarify, this issue was never meant to be about Sammelbands.

[tomcrane]

I think (but will wait for @edsilv to confirm) that this wouldn't be very tricky to do in the UV.

For clarity, is this still supported?

{
  "@type": "sc:Collection", 
  "members": ["Collection1", "Manifest1", "Manifest2", "Collection2", ...],
  "collections": ["Collection101", "Collection102", ...],
  "manifests": ["Manifest201", "Manifest202", ...],
}

or is it members all the way down?

[sdellis]

@jpstroop, as @mikeapp mentioned, Sammelbands are a type of multi-volume item, so I think it's legitimate to bring it up as part of the use case.

@azaroth42 I think you're mistaken. Unless you're referring to a different problem, recursive manifests does not move the problem down to the manifest level. It clarifies that a multi-volume work is a manifest that can have multiple manifest children. As @mikeapp mentioned, covers and other pages can be represented as their own manifests in the list. If we're not on the same page, can you clarify what you see as "the problem"? While "members" seems more flexible, being opinionated and explicit is not always a bad thing. Again, "members" all the way down is breaking and recursive manifests is not.

[jpstroop]

There are getting intertwined here:

1. This issue: I have a bunch (avoiding IIIF language) of books, some are single-volume, some are multi-volume. The order in which this "bunch" of books is presented is significant. The "bunch" should be modeled as an iiif:Collection, as should the multi-volume works. Given this scenario, how do I:

   1. Distinguish between a multi-volume object and a "sub-bunch" in the collection?
   2. Intermingle multi-volume works and single-volume works to retain my order?

   I proposed members (and yes @tomcrane I think your example above is fine...anything else would be a breaking change).

2. Sammelbands (not this issue). Sammelbands are just plain old Manifests (I would not think of them as multi-volume since they share a binding, by definition) with metadata associated with ranges rather than the manifest itself, as @tpendragon proposed on iiif-discuss and @azaroth42 just reiterated.

[tpendragon]

Sammelbands (not this issue). Sammelbands are just plain old Manifests (I would not think of them as multi-volume since they share a binding, by definition) with metadata associated with ranges rather than the manifest itself, as @tpendragon proposed on iiif-discuss and @azaroth42 just reiterated.

:+1: This would only change if members could have canvases, but I think that's out of scope.

[sdellis]

@jon Thanks for clarifying.

The assumption that a multi-volume work should be represented as a iiif:Collection is what I am challenging. If it could be a iiif:Manifest (3) then you don't have to worry about distinguishing a "sub-bunch" in the collection because you won't have iiif:Collections in your list. You could intermingle multi-volume and single-volume works in a specific order. It would not be a breaking change. I don't see what the problem is there.

[azaroth42]

Can we close this issue and create a new one with an explicit proposal please? I can do it, or @jpstroop?

[jpstroop]

I can do tomorrow, or go ahead if you want to now

[jpstroop]

Can we do this and #646 in one?

[azaroth42]

Yes. I'll try and craft a proposal in a new issue before the call tomorrow.

[azaroth42]

Closed by #738