Book Media Type & Multiple Series Possibility

[jakem742]

WHAT: Differentiate between trades, issues and omni's as a Book Type?
HOW: The "Book" object could include a string called mediaType to handle this.

WHAT: Differentiate between trades, issues and omni's as a Series Type?
This depends one whether you have separate series for one-shots ( #32), trades (#21) etc, but if so you would need a way to specify the series media type.
HOW: The "Series" object could include a string called mediaType to handle this.

WHAT: Handling Books with multiple issues contained (potentially from different series
Handling TPB's and omni's as "Book" objects would also mean that a single book can be a part of multiple series (eg. a trade oncorporating issues from multiple series.
HOW: Allow the possibility of 0..* Series objects, instead of 0...1

[GlassedSilver]

Omni as series type? Sounds a bit hacky to me…

Are the twelve omnis of Himouto! Umaru-chan really 12 series? I think not.

In a library where we have browse by series enabled this gets ugly quick.

[jakem742]

No, my point is you could have a separate series for each mediaType. ie. The main series composed of issues would have a mediaType of "issue" or whatever, while a collection of TPB's or omni's would have a mediatype of "Omni", "TPB" etc. This series could easily still consist of 12+ books. It's just helpful to define the type of media that the series is composed of to clearly delineate between the core series of issues and later publications in different formats.

[baodrate]

I think restricting series to a particular mediaType only makes them less flexible without offering many benefits. What are the structural differences between the "media types"? Are they handled differently in the data model? If not I think restricting a series to a specific media type reflects some assumptions about what a "series" is that isn't necessarily true.

For example: Fables #150 is simultaneously v22 of the TPB series. How would this be handled? Omitting it from one of the series? A "dummy" issue that the TPB collects? Two independent "books" with the same info?

Ultimately a "series" does not always have a 1-to-1 relationship with some entity in the publishing process. "Series" can overlap runs of different writers/artists, actual published book series' (e.g. any of many cases where comics are renamed/renumbered), and even publishers. It's easy to say "for the given series, these are the books in it", but it's a lot more difficult to describe the attributes that all series share. That's why I think it makes sense for collections ("series"/"story arcs"/"events") to be as flexible as possible

[GlassedSilver]

Two independent "books" with the same info?

If they released with two different EANs/ISBNs/etc... I think yes?

Another key difference you end up with is release date, especially multi-region considerations.

Omitting it from one of the series?

This is always the wrong way.

If the data schema cannot represent all cases it's failed because it will need shoehorning and shoehorning leads to inconsistency. It's bad enough when metadata providers do this, it's even worse if the standard does it. Hence, this entire project. Although I think your question was rhetorical, so I guess I digress.

A "dummy" issue that the TPB collects?

This leads to a hell of user error potential, because there will have to be made the assumption by metadata editors at sources of which is a dummy of what. But maybe I'm overestimating the problem of that.

Ultimately a "series" does not always have a 1-to-1 relationship with some entity in the publishing process. "Series" can overlap runs of different writers/artists, actual published book series' (e.g. any of many cases where comics are renamed/renumbered), and even publishers. It's easy to say "for the given series, these are the books in it", but it's a lot more difficult to describe the attributes that all series share. That's why I think it makes sense for collections ("series"/"story arcs"/"events") to be as flexible as possible

Big agree on that. If you ask me any lower hierarchy level should always be able to override a given set of attributes.

e.g.:

You set the artist for a series, artist dies, someone takes over for the last few chapters. Now, everyone already has their series' metadata file in-place, and it'd be silly for a few chapters to trigger a rewrite of my series ComicInfo.
Rather the chapters now having a new artist listed in their info should instruct the media library app/viewer/whatever to dynamically override in the presentation for the series that two artists are listed, maybe even for which ranges and for the chapter's details view to view what's written in the series metadata unless an override is present.

That way the series sets defaults for the entire stretch and any chapter, issue, whatever your granularity is can always override some info if it's needed.

Also, I guess that's how you could store ISBNs, etc...

Every issue has its own ISBN, the series can then, if wanted, show the list of ISBNs known, maybe even have it prefilled so when you add the ISBN to some issue that is still missing its other metadata a good library manager will look for known ISBNs and suggest adding that issue to the matching series.

The flexibility and functionality you gain with a defaults + override @ each level approach is astonishing and makes you independent in many ways.

Also, it combats the bad style to assumptive WRITE the data into a file when we only can assume it whilst at the same time not having to go with nothing to show.

(I guess there's mostly comic buffs hanging around here, so for your convenience I'll just point out I'm coming from the manga world where I store by chapter and not by issue or something else, although I do value storing chapters with their (if known and available) volume number in their ComicInfo)