-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collected issues #21
Comments
I don't quite get your link, it shows 31 issues in a volume, nothing collected about it. |
That’s my point, the collected issues are shoved in the links above, as their own series, rather than as apart of the series they’re collecting. |
I don't understand what you are trying to say. Can you be more specific? I have no knowledge on those comics, so I may be missing the point. Can you also describe what you mean exactly by "collected"? Is this something like how trade paper backs contain multiple single issues? |
Yeah that’s it, tbps often become their own series for whatever reason, it’s annoying to deal with when you want them to be organized with non tbps in the same series. |
It's quite common for TBPs to collect issues from multiple series of the same universe. In that case it makes sense to be their own series. It's more a source of truth organisation question, which will not impact the metadata format to be honest. |
My issue was when say, I had 7 tpbs from the same single comic series, and each one became their own separate series, rather than grouping together, in the case of mixed series I get it, but otherwise it’s very annoying. |
This is terrible in ComicVine, for instance for Marve Epic Collection: Marvel publishes several "Epic Collection" series... I have seen that in Comicvine, some of these have been implemented as Series (for example, those related to Star Wars, like this one Star Wars Legends Epic Collection: The Empire). On the other hand, other "Epic Collection" series have been included in the wiki as individual one-shots, when they actually comprise a single volume with several numbered issues. For example, Silver Surfer Epic Collection should be a single series that include the following books as issues, not as they appear now in comicvine, each issue as a separate series: Issue 1: Silver Surfer Epic Collection: When Calls Galactus #1 - Volume 1 (now belonging to Volume Silver Surfer Epic Collection: When Calls Galactus ) Issue 2: not yet published Issue 3: Silver Surfer Epic Collection: Freedom #1 - TPB (now in Volume Silver Surfer Epic Collection: Freedom ) Issue 4: not yet published Issue 5: not yet published Issue 6: Silver Surfer Epic Collection: Thanos Quest #1 - TPB (now in volume Silver Surfer Epic Collection: Thanos Quest) Issue 7: not yet published Issue 8: Silver Surfer Epic Collection: The Infinity Gauntlet #1 - TPB (now in volume Silver Surfer Epic Collection: The Infinity Gauntlet Issues 9-12: not yet published Issue 13: Silver Surfer Epic Collection: Inner Demons #1 - Volume 13, (now in Silver Surfer Epic Collection: Inner Demons) |
At the moment the same story in a TPB and in a single issue will not be linked together, that's because the TPB is one Book, and the single issue is another Book. BookBrainz addresses this by abstracting the story as a Work, which can be contained in multiple Editions. In that model, there is a single Story, contained in a single issue, and a TPB. If we had this model, we could link a TPB and single issues. Is that something we would be interested in? |
My current issue is that, sometimes TPB's will be their own series, rather than apart of the series of books its collecting (excluding when a TBP has multiple series. I was hoping that, if an official db was made around this new metadata type, TBP's would be added to existing series, rather than made their own. |
This isnt so much an issue with the format of this new metadata, but one of if you create a db that users can download comic info from. Ill try to articulate the issue as best I can. Say for instance, we have a comic series, we'll call it batdog, batdog has 30 issues total, all of those 30 issues, are apart of the same series, "batdog" this is good, as it groups them all together. Now lets say batdog has some TBP's, the first one, contains issue 1-15, and is called, "Batdog: origins". the second one is called "batdog, the second' With the current way comicvine does things, both of those would be made into their own separate series, titled "batdog origins" and "batdog, the second". This is bad, as now, those tbp's not only wont integrate with eachother, but they wont integrate with the standard comics either. The solution, of course, is to have the series be "batdog" for all the comics + tbp's with the tbp's titles as well, the tiles of the book. Changing the data from Series: Batdog: origins Series: Batdog, the second To the proper way Series: Batdog Series: Batdog Its long winded, but I hope that describes my issue. |
That's 2 different things:
Here i cannot fix point 1, but we can make sure we properly model data to cater for various use cases. As for your example, there's 2 way of seeing it (i don't count the shitty CV way to have a TPB = a serie):
Point 2 is easy, doesn't change the model, and is in line with the publishing world. Point 1 is more exhaustive, and you can know which TPB collects which single issues. You can also handle reissues, etc. |
So the options are, make ALL the tbp's their own series, meaning they will group fine, or what I suggested, that's what you said right? |
I think you misunderstand what a data model can provide, and tour particular bad experience with comicvine. A data model is a way to model data, if used badly (like CV) you get bad results. It's not the model"s fault. Make TPBs as a TPB series is how many tools already do, or even publishers will advertise the tpb as a different series altogether. If you want to be able to know which tpb collects which single issue, we need a different data model. |
No, my issue will come into play if a db is ever created, I guess I shouldn't have made my post just yet, its not an issue with the data format, just a future db. |
Then make sure the data model can fit your requirements, the future db will use it. |
At worst, I just have to manually edit the series like I do with comicvine, its not a huge deal, all I want is for the db to have tbps series, match the series name they're collecting, thats all. |
I do think it would be a good idea to have something like a "collects" attribute on Book which would refer to one or more other Books. So you might have Batdog Origins TPB, which could still be its own series if that's how the various sources of truth have set it up, but then it would have a "collects" attribute pointing to the (separate, unique) Books Batdog Origins 01, Batdog Origins 02, and Batdog Origins 03, where each of those Books belongs to the distinct Batdog Origins series, not the Batdog Origins TPB series that the collection itself is in. This model could handle the more pathological cases, like when a publisher creates an Infinite Batdogs crossover collection which collects issues from several different series (Batdog, Catbird, Infinite Batdog Origins) into a single TPB. And in theory, this small part of the metadata could reside in a separate, open-source repository which is complementary to ComicVine, so it wouldn't necessarily require either getting sources of truth to change their models, nor reimplementing ComicVine from the ground up. |
BookBrainz approach is not bad i think, but do we think of a series as a story? Because if we do than the Single Issues and TPB is the same Batdog with 30 issues total Batdog TPB collecting issues 1-15 Because it is, in fact the same thing, just different format |
Exactly what I was asking for, thank you! |
That's doesn't always work. TPB can collect issues from other series too. For example the Fables TBP collect some issues from Jack of Fables. |
It doesn't always work that's true, comics have a large amount of fringe cases unfortunately |
I think a simple approach would be to allow a book to be part of multiple series. I don't really understand UML, but I think it reads that, a |
I think we need to go back to what is a Series. When saying Series, people will usually understand:
We also have bad examples of how series are handled in CV, where for instance each TPB is a series of its own, instead of all the TPBs forming their own Series. I do agree though that it would be interesting to have the link between different editions of the same series, ie Single Issues vs TPBs. We could introduce the concept of Edition, and have an Edition being the link between a Series and its Books. You would have for the Batdog example above
That doesn't solve the problem of TPBs that collect issues from various Series, but i think in that case there is always a dominant Series, in the example i gave, it's Fables. Or we could also have a Back to the BookBrainz work thing, i think it could be very well adapted to handle covers, which were mentioned in #18. By having each cover being a separate work, we can have the original date of the Work itself, and the published date of the Book. Something i wanted to do soon was to "test" the model on various use cases, ie having real world examples on how the data would be like. I think it would be good to test the model on complex cases. |
As you mentioned, it really comes down to how series get handled. I personally like the idea of Editions of a particular series, where the series describes the set of story events and the editions collects a particular mediaType or set of published books. Series Only Model (Series object contains all media types) My proposal would be to have a mediaType associated with each book, and then a book is associated with 1 or more series. The user's software could then filter books in a series by mediaFormat to get only the books of a certain type. I have mentioned this concept in (#40). Edition > Series model (Separate editions for each media type / publication run) It would be extremely helpful in these circumstances to also tie that TPB to specific story events. I imagine issues would be the typical way to refer to these events, as they are the base unit for story events. So each TPB book could also have references to Series "issues" either as a direct relationship with the issue's "Book" object, or through an independent list of objects associated with the Series object. Having a set of events associated with the series objects makes the most sense to me, as this allows all Book objects to be related to 1 or more events, regardless of whether they're an issue, TPB, Omni, etc. So basically Book --> Edition (published set) --> Series (story). The Series object contains a list of numbered events (correlating to issues, I imagine). Each book contains a relationship with an Edition, and a numbered list of the events it contains (either through relationship with the series, or simply as a set of numbers). |
I don't think that's a safe assumption. There are many cases (crossover events/special event books e.g. holidays/etc.) where there is no "dominant" series or it is not one of the series whose issues is contained within. |
How will collected issues be handled? Comic vine handles them pretty awfully, making them their own series rather than apart of the series of issues they're collecting (example, https://comicvine.gamespot.com/transformers/4050-29903/, each and every one of the 7 collected issues have their own series page, and are issue one of their respective series, had to manually edit each one in comictagger) Most add tpb to the end despite it being available digitally, which is also annoying.
I think a solution would be to have a specific tag or option for collected editions, a simple true/false toggle to say if its a collected issue in a series would work well, it would be apart of the same series as its non collected counterparts, but apps could separate them into their own categories, so you could use the same issue # and title fields, its just that one tag would change what its categorized as. (would look like this)
The text was updated successfully, but these errors were encountered: