Boxed sets and other multi-volume Editions

books
1

This is regarding when an Edition needs to represent more than one book, or be a boxed or slipcase set, or when one issue of a publication comes with one or more accompanying tomes (eg, a magazine with a free book).

The items may or may not be also sold separately from each other, or from the containing part. In some cases it’s possible that a set may contain items that are exclusive to that issue of the set, or items that are available separately and may be any one of a range of similar printings.

I have examples of these types of sets waiting to be added, and some added in the bookogs days.
Here is a set that contains two volumes only ever available together with the slipcase: https://ctlgs.org/c/books/edition/300840/clash-of-the-princes/
and here is a set that contains three volumes, each of which could be any one of a certain subset of Editions of their respective Book: https://ctlgs.org/c/books/edition/104731/fighting-fantasy-gamebox/

Another case is a periodical magazine which had a free book included as part of its package. As far as I’m aware, the book edition is exclusive to the magazine.: https://ctlgs.org/c/books/edition/292622/science-fiction-classics-do-androids-dream-of-electric-sheep/

I’m sure I read some comment on the forum not too long ago, and I think the response was to put all volumes in one submission for any set with solely exclusive contents. I consider this a poor solution. (I found it: Multi-volume works with slip cases ). This smacks of the same thinking that led to the poor implementation of File releases in discogs - crammed into the pre-existing structure for physical releases when they are a very different animal. A boxed set is not simply one Edition.

Each book within a set has all the properties of an Edition, and a slipcase can have many of them itself, too.

The way I see it, we have these options:-

  1. To try, as above, to cram multiple volumes into an entity structure not geared to multiple self-contained instances or references. This seems like the very poorest option to me as it doesn’t fully, logically, or clearly represent the Edition being described. The result is an inconsistent mess.

  2. Use an Edition to describe the containing box, case, or primary item, and then other Editions to describe the contained items. There would need to be some development to allow an Edition to link to a defined subset of other Editions - including a subset of 1.

So something like:

Book: My Lovely Slipcase

  • Edition: My Lovely Slipcase

    • Publisher: Wub Publishing Ltd.
    • Date First Published: 1999
    • Edition: 1
    • Contains
      • Link to Editions: My Lovely Book, Volume 1 {where published by Wub Publishing Ltd. between 1998 and 1999}
      • Link to Editions: My Lovely Book, Volume 2 {where published by Wub Publishing Ltd. between 1998 and 1999}

  • Edition: My Lovely Slipcase

    • Publisher: Wub Publishing Ltd.
    • Date First Published: 1999
    • Date This Edition Published: 2001
    • Edition: 2
    • Contains
      • Link to Edition: My Lovely Book - The Prequel {where specific ID}
      • Link to Editions: My Lovely Book, Volume 1 {where published by Wub Publishing Ltd. between 1998 and 2002 in a standard edition}
      • Link to Editions: My Lovely Book, Volume 2 {where published by Wub Publishing Ltd. between 1998 and 2002 in a standard edition}
      • Link to Editions: My Lovely Book, Volume 3 {where published by Wub Publishing Ltd. between 2001 and 2002 in a standard edition}

I’ve previously asked if a Book page could be filtered by GET parameters so we could build a filter query url to a subset of Editions. This would be a good use of such filtering. We could then use links in the Contents of an Edition to identify the Editions being contained. This would be simpler than developing the ability for an Edition to contain sub-Editions.

With the Gamebox example linked above, I’ve already partly tried to link to editions, but in the Notes and having to describe the parameters in words.

The benefits of this approach would be to properly represent both the Editions inside the set and the set itself as its own Edition. No crowbarring. When a marketplace is implemented, it will also enable people to sell partial sets, which they will inevitably have, without compromising the data, or forcing them to rely on a comment to explain that the set is only partial (I’m sure there will be fringe case exceptions).

Also, if I submit a set of 10 books where each book is the specific printing in my set, someone else might submit theirs because their set has a different allocation of printings. We’d get multiple instances of the exact same set.

I hope this makes sense because it would be good to get some decisions on how we’re moving on this. The multiple-Editions-crammed-into-one-Edition technique isn’t working for me.

All Features Great and Small - a feature request thread
2

Hmm, I can now see the case for each volume in a boxed set being its own Edition so it can be cataloged independently. A user should be able to add individual volumes to their collection, or the whole set as one item.

I’m thinking either a parent link on Edition (so a boxed set Edition can reference its contained Editions), or a dedicated “Set” entity type. Both could work — a parent link is simpler, a Set entity type gives more room for set-specific fields (box type, slipcase, etc.). I’d prefer the first approach if the right information can be captured in the existing Edition fields.

3

Thanks for reading my meandering waffle!

edit: you know what, ignore this up until the ‘alternative’ I mention - your approach. Keep it simple for the user.

In a traditional database relationship you’d model the child up to its parent, but in this case that won’t work. That would only give you a direct one-to-one mapping between the parent slipcase set and each one of its component parts. The parent needs to contain an array/list of child ‘references’; those references being a way to indicate one or more printings of child Editions for each book within the set.

So, in https://ctlgs.org/c/books/edition/104731/fighting-fantasy-gamebox/ we have three books, each of which might be one of several possible printings for that title, but only within a specific range. It’s no good linking solely to the Book entity (as I have done in the notes for that one) to say “this set contains this Book, this Book, and this Book” because there are printings from other publishers, and even printings from the same publisher in other editions that definitely never appear in that slipcase.

We need a way to say

This slipcase contains

  • The Warlock of Firetop Mountain, only Editions where Imprint=Puffin Books; Edition-No=2.
  • The Citadel of Chaos, only Editions where Imprint=Puffin Books; Edition-No=1.
  • The Forest of Doom, only Editions where Imprint=Puffin Books; Edition-No=1.

where the user can then click and see only the Editions that fit those criteria. Of course, it would only be effective if the data were entered correctly, but that’s the case for every database connection. It’s up to the user to make sure their input works effectively, like in any user-maintained database. Others can repair incomplete or incorrect data.

A straight-up direct link from one child Edition to one parent Edition would be ideal for Editions which are exclusive to the set, but that can be mapped using the above described system by saying ‘where ID in [x]’ where x is a single Edition ID in an array of 1.

.

An alternative is to map back from every child Edition in a Book to each parent Edition it appears in (and the child Edition might not be exclusive to only one set - I have examples of this type I need to add), and have users add that reverse join if they add a new Edition that might appear in the set. This is basically the approach you were suggesting.

The set-type parent Edition would then need to resolve the joined Editions down to Books - because it’s no good linking 13 different child Editions from the first volume back to a parent Edition, 8 Editions for the second volume, and 9 Editions from the third - because then the set would appear to have 30 books in it. It needs to show “these Books are in this set, and for each of them, any one of these Editions”.

The child Edition would also have to show which Set-type Editions it appeared in. But that’s the easiest part of all of this :smiley:

This is alternative is probably more robust from a database design perspective, but more labour to develop and for users to maintain (although also less complicated for the average user to edit - the interface on top of all this would be simple - just point an Edition at an - or a another - Set Edition it appears in).

.

I don’t think there are any properties in a boxed set that don’t already appear in an Edition. I can’t think of any. You’d need to add the different types of set to the formats list, but that ought to be simple enough.

.

To give an idea of what I have to deal with, I have a series of (four) slipcase sets which each exist in two separate editions (small e) with different designs. Each of the two sets contain the same titles (4 or 8 depending on the set), and those titles can be any of a seemingly random selection of variant printings, but there are certain printings that never appear in them (printings designated as special editions never appear). All the printings that appear in any of these sets were also released as standalone publications. They’re all gift-market sets.

Both editions of the sets would appear under the same Book (as parent Editions), and each of those parent Editions would have 4 or 8 child Editions. The child Editions would need to link back to both.