Add "is not" property to the work

[bicolino34]

Problem

A clear and concise description of what you want to happen

There are a lot of works that might have the same titles, but are actually different works or the other work might be an adaptation of the first.

In case of manga, there are often two editions being published: Tankōbon and Bunkōbon. They have the same content, but different amount of chapters inside them.

• Tankobon is the standard edition
• Bunkobon is the cheaper version with smaller dimensions. And contains more chapters than the Tankobon

So, volume 1 of Tankobon might contain 5 chapters, and Bunkobon would have 10 chapters in the 1st volume. When the series gets fully published there might be 10 Tankobon volumes, but just 5 of Bunkobon. This might cause a confusion when making merges.

Currently, there is nothing preventing these works from merging and the librarian might accidentally do a faulty merge. There is an option of adding into a title info about the format, but I think a property to prevent merge would be a more reliable solution.

I think, this was discussed in some other issues, but no separate one was created.

Proposal & Constraints

No response

Leads

Related files

Stakeholders

---

Instructions for Contributors

• Please run these commands to ensure your repository is up to date before creating a new branch to work on this issue and each time after pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.

[Freso]

Related: https://github.com/internetarchive/openlibrary/issues/9452

[mekarpeles]

It's worth noting that admins already have a field that looks like this:

I'd like to discuss a few solutions.

1. Allowing librarians to create (subject) Tags for these common things like manga, Tankōbon, and Bunkōbon, as well as other common distinctions like Textbook, Non-Fiction. A challenge here is that Tags currently operate on Work rather than Edition
2. Extend admin section to include trained super librarians and give ability to let super librarians add keys for certain editions in areas where they are sufficiently subject-matter experts and have coordinated w/ @seabelis et al
3. Add a few specific fields/checkboxes to the form specifically for manga or other serials

[bicolino34]

Tankobon and Bunkobon editions should be in two different works. They should not be merged

[mekarpeles]

This gets even more confusing with series :)

For now, let's just make the metadata field available to super librarians, small permission change, then we can figure out the rest later

[Freso]

I'd like to discuss a few solutions.

1. Allowing librarians to create (subject) Tags for these common things like manga, Tankōbon, and Bunkōbon, as well as other common distinctions like Textbook, Non-Fiction. […]

Isn’t this already the case? I’ve added subjects like "non-fiction" and "dictionary" to Works before.

2. Extend admin section to include trained super librarians and give ability to let super librarians add keys for certain editions in areas where they are sufficiently subject-matter experts and have coordinated w/ seabelis et al

This seems to be the one you want to go with for the time being. Do you have any plan on a schema that addresses this issue? is_not:OL…W or different_from:OL…W (akin to Wikidata’s P1889) or WHATEVER_YOU_DO_IN_YOUR_LIVE_DO_NOT_MERGE_THIS_WITH:OL…W? Would these then be checked during a(n attempted) merge and block the merge if they exist and conflict? What happens if a Work mentioned with the tag is merged; will the process check the redirect table, or will the references get updated at merge time?

---

My own suggestion would be to implement https://github.com/internetarchive/openlibrary/issues/9452 for a free text field and show this note (if it exists) on the merge page. This would allow to not just warn about similar Works, but also provide more context for why they’re not the same. E.g., instead of just being told is_not:OL123456789W you can be told This is the 2009 bunkōbon; do not merge with the tankōbon of the same name or with the 2023 bunkōbon that contain the content of an additional 10 tankōbons.

The free text approach is also more flexible and with fewer pitfalls in cases where Works get merged or where new Works need merging (“should this newly created Work be merged with OldWork 1 or OldWork 2?”).

[bicolino34]

I provided too little information in the initial comment, so I will try to explain in more details.

Usually in Japan, authors first publish their manga in special magazines chapter by chapter per issue of magazine. Now also web publishing. Then, when there are enough chapters and if it gets popular enough, publisher might make a separate book with chapters of the manga.

Let's say that there are 10 chapters, so it might be published into two volumes of tankobon and if those prints sell well enough there might be a bunkobon edition that contains 10 chapters in one volume.

Chapter	Tankobon	Bunkobon
1-5	Volume 1	Volume 1
6-10	Volume 2	Volume 1

For example, manga "Blood Lad" which has 17 volumes in tankobon edition. And it was published in English with 17 volumes. See https://www.amazon.com/dp/B07JKDKMXG?binding=paperback&ref=dbs_dp_rwt_sb_pc_tpbk

But the same publisher also did this series as a bunkobon edition with just 9 volumes. See https://yenpress.com/series/blood-lad

There is also usually added complexity of the novel which can be conflated with the manga due to the same title as manga quite often is an adaptation of a novel. (not in the case of above mentioned manga)

[cdrini]

I love this idea; I would propose the following format

{
    "key": "/works/OL123W",
    "title": "Blood Lad Vol. 1 [Ch 1-5]"
    "is_not": [
        {
            "record": { "key": "/works/OL12W" },
            "notes": "Vol. 1 is Ch 1-5 in the Tankobon publication, but 1-10 in the Bunkobon publication"
        }
    ]
}

Pros:

• Can have multiple is_not, not just one
• Can have notes as to why they are different
• Can easily query for these; this means we can do things like programmatically prevent merges if is_not field is violated. This would not be possible with plain text field. The note means we could also display why a merge is blocked when someone tries to do one.

Other use cases:

• Authors with the same name but who are different people
• Editions with the same ISBNs but which are different books!