MangaDB DEV

General

this is the place to contribute ideas on a possible future addition of manga data to AniDB.

For other areas of active development on AniDB, check: Development.

Directly related: Generic PersonCompany DEV

Data

First thing we need to be aware of what data we would like to actually store/how the real world looks like.

Content forms we care about

• (Light) Novels
• Manga
• Doujin
• Magazines

Releaseforms

Content comes in various forms made up of different elements.

chapter only releases

used where?

• official online distribution

content elements

• chapters

volume only releases

used where?

• some novels
• doujins

content elements

• volumes which consist of basically 1 "chapter"
• "chapter"; basically 1 per book
• omake (depending on wanted granularity)
• illustrations (depending on wanted granularity)
• other 1 page content (index etc.) (depending on wanted granularity)

mixed content

used where?

• everything else

content elements

• volumes which encapsule the content into datasets
• chapters
• omake (depending on wanted granularity)
• illustrations (depending on wanted granularity)
• other 1 page content (index etc.) (depending on wanted granularity)

Editions

To make things worse the same content is released in multiple editions. Multiple editions usually share the same content (usually chapters) but might add different bonus content (illustrations, omake etc.). Repackaging and rereleasing are further reasons.

Hence an edition may or may not reuse existing content. It's potentially wanted to "transfer" as much data as possible with this. (where content = credits, release dates) While i say transfer what really is wanted is not duplication, but adressing the same content from multiple angles to lessen maintenance.

Credits

• 作者, 著者 - Author
• 発行所, 発行 - Publishing Office
• 出版社, 発行者, 発行人 - Publisher
• 発売所 - Sales Office
• 編集, 編集人, 編集者 - Editing
• 編集協力 - Editing Assistance
• カパーイラスト, COVER ILLUSTRATION - Cover Illustration
• カパー&ロゴ - Cover and Logo
• 本文デザイン - Text Design
• 印刷, 印刷所 - Printing
• 装丁, 装幀 - Binding
• 製版, 本文製版 - Text Platemaking
• 製本 - book making (binding, publishing)
• ILLUSTRATION, SPECIAL ILLUSTRATION - porn mag illustrations

Additional ones may contain assistance, colouring, illustration.

Most credits apply on volume level and for regular manga are given in a short summary towards the end of the book. Though certain types of releases may contain content which doesn't fit that rule. Especially illustrations/guest work should receive credits on chapter level. Same goes for magazine releases

Character

• Chapter appearance

Nothing more to store here.

Situation and Problems

• packs aren't standardized
• repacks and re-edits are common

Implementation

General

Manga entries

• basically just a name and a summary/description of the entry
• further data can't be stored at this level
• categories/tags would be assigned on this level

Editions

• compareable to an anime entry
• made up of several elements (chapter, volumes, etc.)
• picture

Element Edition

• to make truly reuseable we need a layer between editions and elements
• release dates
• volume/chapter "number"
• controls the order of elements (some internal number to shift content around)

Elements

• compareable to an episode entry
• variable element which may be a volume, chapter, omake, illustration, etc.
• needs nesting capeabilities to build a 2 level hirachy
• only volume/chapter(/omake?) ones should be addable to mylist; rest is mainly only in for credits and completeness sake

Files

• generic files with language flag and group assignment
• possible would be to assign multiple hashes to each of these generic files to a) stop the clutter problem and b) still allow for automatisation without completely depending on filename parsing

Mylist

• as files will exist on chapter level, unbound of editions, we want to store an edition id in the data record to prevent every single edition popping up in mylist; if the user really has multiple editions he will have to add those chapter as well evne if that means "duplicating" entries the listtb records

Credits/Character

• credits will be set on element level; we can't add a manga or edition id in this for easy access as the data wouldn't be universally useable anymore
• to lessen the pain of data retrieval we will use a caching table which duplicates and condenses the data

Database

Example Data

example

Workflows

Adding new manga

• the add form should contain the data for mangatb, mangaeditiontb (to create the main edition as well), resourcetb, manganametb

Result

• 1 mangatb entry
• 1 or 2 manganametb entries
• 1 mangaeditiontb entry
• 0,1 or multiple resourcetb entries

=====Adding new

Proposed Alternative High Level Relationship

This is here for discussion as a simpler relationship structure to see if it can withstand debate.

Manga

• Manga has_one Publisher
• Manga is_one [ Magazine | Doujin | Novel ]
• Manga has_many Volumes (at least one)
• Manga has_one Release (likely a year)
• Manga has Relationships to other related Manga just like Animes do.

Volume

• Volume has_one Manga
• Volumes has_many Chapters (at least one)

Chapter

• Chapter has_one Volume
• Chapters may_have_many Anime (aid)

Any "entry" has a minimum of 1 row in all three columns in order to be in the system.

For example say Naruto chapter 9000 was released in JUMP, NarutoFanMag and the actual Naruto Manga later. This would be 3 manga entries, 3 volumes and 3 chapters entries in the database. This seems much easier as well as intuitive to the user. Just because a Chapter contains the same story in 3 different publications doesn't mean it needs to be the same row. It is a different physical object that just happens to have the same data (the likely won't be identical in many of the common cases).