What is a Series?

[gotson]

There's been some talk about series in a few issues, and my feeling is that the definition of a Series is not exactly clear. It also highlights some problems:

• The elephant in the room: the Volume
  A typical construct of the US comics industry, the volume is used alongside series to identify some kind of portion of a series. It is safe to assume that we most likely need to add the Volume in the data model, else the US comics fanbase would be lost without it!

• Collected editions (discussed in Collected issues #21)
  As suggested in Collected issues #21, having a way to specify the Edition for books in a Series could help to address this point. Some examples of _Edition_s could be:

  • collected editions (TPB for US comics, Intégrales for Franco-Belge, Tankobon for manga)
  • single issues (US comics floppies, manga published in chapters)
  • Black & White, or colorized edition
  • different translation of a manga. For example in the early days of manga published in France, the images would be reversed to be presented in Left-to-Right direction, but nowadays everything is published in the original reading direction. Some manga have been republished in the original reading direction. It could also be using a newly updated translation, or original onomatopoeia (again, in the early days, even drawn onomatopoeia would be translated and redrawn).

• Translation language
  The same series could be translated in multiple languages (think Tintin). Some people consider the original series and its translation to be the same series, some consider it to be 2 different series.

---

I also wanted to highlight the difference between:

• the data model
  This is how the data can be represented. The various fields in the database, the relationship between objects.

• the data organization
  This is how the data model is filled with actual data.

Some problems can be solved by either a good data model, or a good data organization, or both. Even a good data model can lead to bad data organization.

A good example of bad data organization is how ComicVine represents the TPB, where each TPB is its own Series. Many people consider this to be a problem, and would much prefer to have a Series for all the TPBs.

[gotson]

To add my own personal view (which doesn't mean that will go in the model!):

• i despise the Volume field. To me the volume could be used together with the series title to form an actual series, like Batman (2021). In order to group all the different volumes of a series, the Collection concept could be used (and that's actually how Komga works).
• i believe a Series should be a complete set, meaning that all books should be of the same kind of edition (all floppies or all TPB, not a mix), and from the same publisher. But i do find some appeal to the concept of Edition, which could link the different editions of the same series together.
• I think the different translations of the same series should be separated in different series, and could be linked together by using some kind of relationship. In my experience, a translated series is usually under a different publisher (local to the country of publication), and sometimes can have different reading order. It is not always 1 to 1 with the original books.

[Buried-In-Code]

To add my view (Probably more to do with how I've sorted/managed my comics til now). The way I see series is how League of Comic Geeks attempts to organise it's Series, where it has all the comics, all the TPB, all the editions and any other material/variants from that volume/series.
The way I see it is that the comics are the series and so any collections, variants of them are part of the series, so a TPB made up of Issue #7-10 is part of the same "series" as Issue #12. This doesn't work when they have Collections that cross different "series" in which case I'd often have it as it's own series rather than in both

[gotson]

To add my view (Probably more to do with how I've sorted/managed my comics til now). The way I see series is how League of Comic Geeks attempts to organise it's Series, where it has all the comics, all the TPB, all the editions and any other material/variants from that volume/series.
The way I see it is that the comics are the series and so any collections, variants of them are part of the series, so a TPB made up of Issue #7-10 is part of the same "series" as Issue #12. This doesn't work when they have Collections that cross different "series" in which case I'd often have it as it's own series rather than in both

Thanks, that's insightful. I think that echoes the point about the Editions in my first post above.

[Bitwolfies]

Yeah, my current main gripe with comicvine is how tbp's are treated as their own series each, meaning if batman (2021) had 7 tbp's, comicvine would say that's 7 series, a nightmare for organization.

Once a db exists for this project, a series should be able to encompass the following:

-Single issues
-One shots
-TBP's/collected editions (and their regional equivalents)
-Omnibuses
-Variant editions for each

Really as long as all of that can fall under 1 series, rather than making each its own, my gripes would be solved.

[bpepple]

* i despise the _Volume_ field. To me the volume could be used together with the series title to form an actual series, like `Batman (2021)`. In order to group all the different volumes of a series, the _Collection_ concept could be used (and that's actually how Komga works).

The volume number is needed in a few cases, for example Year Zero by AWA released 2 separate series in the same year and using Year Zero (2020) wouldn't work.

[gotson]

The volume number is needed in a few cases, for example Year Zero by AWA released 2 separate series in the same year and using Year Zero (2020) wouldn't work.

Year Zero (2020) and Year Zero (2020-2) would work 🙃

[Buried-In-Code]

As there can be multiple series released in one year, I'd be hesitant to use the Year as the identifier.
I think it'd cause less edge cases to just use a count instead.

[Mummraah]

Agree with what has said above re Comicvine's handling of TPBs as unique volumes. Again as said above a series should encompass all types of releases be it single, TPB, HC, omnibus etc. What would be hugely beneficial is ranged numbering fields for the collected editions so you could sort by it. Eg Not only is TPB vol 2 issue 2 of the TPBs but fields to identify it as issues 7-12 from the single issues.

For series released in the same year with the same name I've seen myself create custom 'volume end' fields but you then run into problems should they both end the same year....

[RossSmyth]

An interesting way is the way Dynasty Reader models its data. You can see how it is organized by going to a chapter and putting ".json" at the end of the URL. Example 1 Example 2

Essentially each chapter stands alone, and you can compose any amount of tags that you want, and none "own" the chapter. This allows chapters to be part of series, anthologies, magazine issues, authors' series, or anything else that is a tag. Then you can change the context you are viewing a chapter with by changing a combo box value.

This model I think has the benefit of separating the data (chapters) from how they are sorted (series, issue, anthology, multiple of these, or none). Though Dynasty themselves sidestep volumes by inserting a dummy tag representing a volume's name between chapters. This also avoids inheritance hierarchies that force things upon users.
The downside is that it means analyzing chapters in a global context as any chapter could be part of none or all "tags". It also means that changing a series' name would mean the software would have to alter all of the names in all chapter's metadata.

But I don't really have a stake in this, I was just passing by while looking at Komga.

[jakem742]

I would love to have a coherence between all types of media, regardless of whether a book is an omni, trade or issue.

The way I see it, a series is either:
(1) A set of published works in a particular format (ie. a collection of TPB's or issues by a specific publisher in a coherent set)
(2) All works associated with a particular STORY (ie. all media associated with a specific set of events in the narrative)

I imagine this thread is basically to identify which of these approaches to use?

I like the model that you've got at present tbh. Use the SeriesCollection construct to cover a set of events (story), and create series distinguishing a particular run of media by a publisher which forms a coherent set (eg. separate series for collections of TPB, omnibuses and issues).

Each series would then need a mediaFormat field to distinguish between the series. Most of the metadata could then be moved to the SeriesCollection entry, and the actual Series would only need uniquely identifying information (such as mediaType).

Or instead of Series -> SeriesCollection, you could label them Edition -> Series as you mentioned here. The series entry would then contain all descriptions and overview data for the story, while each edition would be a unique collection of media not found in any other edition.

[GlassedSilver]

Chapters should best be their own possible hierarchy in the data model and simply not be necessary, e.g. you may not want to track the different pencilers per chapter or don‘t know them, so you put them at the book level. (yes I said book, a book can be a volume which has its own ISBN/UPC/JPC/EAN)

So whilst some may want to store (or have to store) data per chapter, like most manga users who obtain and read chapter-based rather than volume-based (tracks much better against MAL, Kitsu, AniList, Tachiyomi, etc… anyways) others may think of chapters as an unnecessary level of granularity.

If we make chapters their own level of hierarchy we can also consider importing series name from parent (book/volume/series, by ID)

that is, if UUIDs are wanted. Personally I think it‘d be smart to have them when we already start metadata static rather than relationally on the filesystem. Just a thought though. But chapter ought to be its own entitity.

[BlobCodes]

Chapters should best be their own possible hierarchy in the data model and simply not be necessary, e.g. you may not want to track the different pencilers per chapter or don‘t know them, so you put them at the book level. (yes I said book, a book can be a volume which has its own ISBN/UPC/JPC/EAN)

I think that's a good idea. Also, there's even multi-volume releases which have to be taken care of. (Example: Ranma 1/2 2-in-1 edition)
Maybe there could be a separate class adding markers at specific pages: