This Work seems to have been set up for a Series: https://bookbrainz.org/work/39065ab5-7796-4544-a02f-4439fec42137
I know nothing about these comic books, but it seems a bit odd to create a Work for each chapter. The Work should be for the book or if it is a collection then the individual works that it contains.
As the OS @RavenWorks you might like to comment.
The situation is, each chapter can be found in three places:
and significantly: the last two are different: for example,
The whole reason I started entering this into BookBrainz was so that I could catalogue where each story (not just the main ‘chapters’, but also the non-numbered ‘side stories’) can be found in print – so that if someone owns a few volumes of “collected”, they can know which volumes of “complete” they should buy (which is a very relevant scenario, since “collected” stops partway through the story which is only finished in “complete”, but as mentioned, the Volumes do not line up).
I’m coming to this from MusicBrainz, where each track of an album has its own Work (or rather, has its own Recording, which typically has a Work) so that people can describe all the places that a particular song can be found (across singles, albums, and compilations); based on that it seemed natural that chapters which are published individually (whether in issues or inconsistent collections) would be described by Works, but if there’s a different approach that would still communicate the same information, I’d be happy to learn about it!
Thanks for the quick reply.
If the chapters are the titles of individual works, then rightly they get their own Work.
The problem might be with the Work “Omaha” the Cat Dancer: https://bookbrainz.org/work/39065ab5-7796-4544-a02f-4439fec42137 which seems to have been set up for a series, rather than a book.
A Work is not used as a means of collecting parts of a series, and unfortunately a way of dealing with series has not been implemented, but it has been discussed.
Ohh, I understand now. Yeah on MusicBrainz, both an opera and its individual movements are Works, for example. I assumed the same thing applied here, especially since there was a type ‘serial’ (although I wasn’t sure whether that should refer to the container or its parts, so I’ve been using it for both, which definitely isn’t ideal…)
So BookBrainz has no way to refer to, for example, the Lord Of The Rings trilogy, only its individual books, which aren’t connected to each other by any metadata at all? (Other than having the same author of course…)
Not yet, but that is just a matter of time.
Sounds good! I know it’s all a work in progress 
So for the time being, is the better response to delete that ‘series’ work and re-make it when the database has a proper schema for it, or to leave it in this better-than-nothing state so it can be converted once the site can handle it properly?
We don’t know when and how series will be created but the “part of” relation will not be used for sure (It 's used in the wrong direction anyway). So I think it’s better to remove it before other users will copy this “pattern” 
OK, done! Thanks for the clarification.
That was fast, thx. But I think I forgot to mention that it is always better to merge or rename a “wrong” entry.
So I hope the database will not implode now
What is there to merge it into? The entire point was that this was something that conceptually shouldn’t exist, wasn’t it?
Yes of course, everything’s fine. But I was told that it is better for the database structure, not to delete sets of data. Maybe the “Delete” button should be removed to avoid this @mr_monkey.
Nothing will implode and the database is set up to work with deletions just fine, it’s just that we encourage users to merge duplicates for example rather than to delete, so as not to lose any information.
OK I understand that. But I just had to merge 5 dupe profiles of Jane Austen without any info added and a work dupe without any rel. But because the title was written in upper cases merging created an alias, which I had to remove afterwards. It would really safe time in these cases to delete the data.
Some other websites might be linking to any of those duplicates, and with merging you ensure that they are redirected to the entity you merged into.
The case above is a bit different, since the work shouldn’t redirect to any other existing work, and it’s OK to simply delete it.
My two cents: deleting it was wrong, because it removes useful information from the database.
If there is a sub-optimal way of modeling the info pending the addition of concepts like “group of works” or “series”, then that should be taken.
It would of course be useful to have a canonical annotation to make it easy to find such cases once the model is extended.
I don’t agree. A series is not a work and modifying the function of the Work in that manner is a band-aid solution.
In a past life, I discussed ways of dealing with author series: Series by authors - how to manage
It is critical that BB implements a system in the near future as the database is expanding and there are already numerous series. The longer a decision is delayed, the more difficult it will be to implement any type of system.
If adapting the Work to collect a series is the only solution, then I totally agree that keeping track of them is essential.