MangaDB DEV: Difference between revisions

From AniDB
Jump to navigation Jump to search
mNo edit summary
 
(28 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{TOCright}}
{{TOCright}}
=General=
=General=
this is the place to contribute ideas on a possible future addition of manga data to anidb.
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]]
For other areas of active development on AniDB, check: [[Development]].
 
Directly related: [[Generic_PersonCompany_DEV]]


=Vision=
=Vision=


=Data=
=Data=
What are the things we should be able to store/provide?
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.).
 
We will have to ignore this idea in favor of simplicity. it's not feasible to completely mirror reality.
 
If an edition is worth it it should be added as a new manga entry. While this might seem entirely stupid it's the only feasible way to do this.
 
==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.


... list all entities and their attributes here ...
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=
=Situation and Problems=
*packs aren't standarized
*packs aren't standardized
*repacks and reedits are common
*repacks and re-edits are common
 
Hence because of that adding hashes or automating the add via those is somewhat impossible. The only way to do this would be if we break it down to the pagelevel which is somewhat silly. Furthermore as viewer are capable of showing the content without extracting many people don't decompress the packs. Because of that going down to that level is pointless.


=Implementation=
=Implementation=


==General==
==General==
===Mangaentries===
===Manga entries===
*like animenetries at anidb
* compareable to an anime entry
*description
* made up of several elements (chapter, volumes, etc.)
*genres/categories
* picture
*producer
*picture


===Volume level===
===Element Relation===
*is identical to the episode entries of anidb
* as certain blocks are content wise identical we need a mapping table between content and manga itself
*data: volume name, volume number, release date
* contains meta data that is not content specific (dates, numbers, pics)
* controls the order of elements (some internal number to shift content around)


===Chapter level===
===Elements===
*is somewhat identical to the episode entries of anidb
* comparable to an episode entry
*a range of chapters builds a volume
* content specific reusable elements
*data: chapter name, chapter number (release date)
* variable element which may be a volume, chapter, omake, illustration, etc.
* needs nesting capabilities to build a 2 level hirachy


===File level===
===Files===
*slightly identical to the file entries of anidb
* generic files with language flag and group assignment
*only generic files
* 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
*generic files can have language and a group
 
*more than 1 generic file per chapter! basically every language + group combo creates a new file
===Mylist===
*no size
* as files will exist on element (content) level, unbound of direct relation to manga, we want to store a mangaid in the data record to prevent every single appearance of the file/content in manga popping up in mylist; if the user really has multiple files of the same content in different manga he will have to add those files as well even if that means "duplicating" entries in listtb records. a unique key would hence need to be "uid, fid, mangaid" and not just "uid, fid"
*no hash
 
===Credits===
* while the content of a certain element might be identical the credits for said element might differ and hence we can't apply it on element level, but have to make it manga specific. this will mainly reflect on the publishing level. considering credits for manga are quite short duplicating the records shouldn't be too much work.
 
===Character===
* as we enforce a unique content rule character can be set on element level and will hence apply for every related bit.


==Database==
==Database==
===Approach 1===
[[Image:Mangadb-dbspecs3.png]]
[[Image:Realshitdiagram.png]]
 
====Automization====
a bit of automization could get done with parsing the filename, but most adding would be manual labor, which is inevitable considering we store no hashes and there is no real way to do this with them.


it's essential to have massfileadd tools for this. this includes massadd to anidb and massadd to mylist.
[[Category:Development]]

Latest revision as of 15:49, 2 January 2012

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.

Vision

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.).

We will have to ignore this idea in favor of simplicity. it's not feasible to completely mirror reality.

If an edition is worth it it should be added as a new manga entry. While this might seem entirely stupid it's the only feasible way to do this.

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

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

Element Relation

  • as certain blocks are content wise identical we need a mapping table between content and manga itself
  • contains meta data that is not content specific (dates, numbers, pics)
  • controls the order of elements (some internal number to shift content around)

Elements

  • comparable to an episode entry
  • content specific reusable elements
  • variable element which may be a volume, chapter, omake, illustration, etc.
  • needs nesting capabilities to build a 2 level hirachy

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 element (content) level, unbound of direct relation to manga, we want to store a mangaid in the data record to prevent every single appearance of the file/content in manga popping up in mylist; if the user really has multiple files of the same content in different manga he will have to add those files as well even if that means "duplicating" entries in listtb records. a unique key would hence need to be "uid, fid, mangaid" and not just "uid, fid"

Credits

  • while the content of a certain element might be identical the credits for said element might differ and hence we can't apply it on element level, but have to make it manga specific. this will mainly reflect on the publishing level. considering credits for manga are quite short duplicating the records shouldn't be too much work.

Character

  • as we enforce a unique content rule character can be set on element level and will hence apply for every related bit.

Database