Generic PersonCompany DEV

Concerns and Goals

As the CharDB, OstDB, MangaDB and AniDB's producers all tend to include data about individuals or companies it would be a good idea to extract the generic data for individuals and companies into two separate tables which are then used by all other parts.

• I.e. instead of having all the data inside the producer table, it would only include those data fields which are producer specific and would refer to a person or company table for the general data.

• The question is, which fields can be considered generic (and should thus be listed in the person/company table) and which fields are specific.

• And also which relations should be possible between entries.
  • person<=>company relations? (works/ed for?)
  • company<=>company relations?
  • person<=>person relations? (married?)

• And multiplicities, i.e. has each producer only one person/company related to it, or multiple ones? - Each producer as only one entity assigned to it. Although one of those entities is Collaboration which can hold multiple companies and/or persons.

• Also, should names be a separate table (like anime titles) or are there only a small number of names we'd want to store per person/company? - Names have their own table for every Entity that has titles.

• Is mangaka sufficiently different from producers? Or should mangaka simply be stored/handled like producers?

• The concept of pseudonyms is still very unclear, what is the multiplicity? And are they also related to producers? Or persons?
• Also how are matching pseudonyms (they're not unique, are they?) handled?

• Looking at Producer, Artist, Mangaka and Seiyuu we see that they are very similar the only thing changing are the names of the generic fields (like start date), so a question is should we either:
  1. have multiple modules for each specialization or should we keep it only under one module and differentiate with something like show=addentity&type=person[&edit=1]
  2. keep using the current way that is xvcl everything and make several modules for each specialization?

Suggestion 1

The big picture

Warning: Image doesn't reflect the current layout.

• To Fix:
  • Add missing Collaboration and CollaborationEntities tables
  • Add missing PersonTitle table
  • Decide if we actually need the Pseudonym table

Data Fields

Generic Fields

Generic Fields - Person

• image
• url (en)
• url (jp)
• url wiki (en)
• url wiki (jp)
• birth place
• birth date
• death date
• gender
• blood type
• nationality
• place of residence
• description (extra data goes here)

Generic Fields - PersonTitle

• title - some title, like: phd, bsc, etc
• [name] - this is LASTNAME firstname for oriental names and firstname LASTNAME for western names
• firstname - also know as Personal names
• lastname - also know as Family name
• lang - language of title
• type - type of title
  • 1 - Main title
  • 2 - Alias
  • 3 - Maiden name
  • 4 - Nickname
• verified

Generic Fields - Company

• image
• type - type of company
  • 1 - Company
  • 2 - Organization
• url (en)
• url (jp)
• wiki (en)
• wiki (jp)
• date founded
• date closed down
• description - other stuff goes here

Generic Fields - CompanyTitle

• name - name of the company
• lang - language of title
• type - type of title
  • 1 - Main title
  • 2 - Synonyms
  • 3 - Short
• verified

Generic Fields - Collaboration

• type - collaboration type
  • 1 - Joint work
  • 2 - Band
  • 3 - ... ?
• url (en)
• url (jp)
• wiki (en)
• wiki (jp)
• start date
• end date
• description - other stuff goes here

Generic Fields - CollaborationEntities

• relcolid - Id of the Collaboration
• reltb - type of entity
  • 1 - company
  • 2 - person
• relid - entity id

Generic Fields - CollaborationTitle

• name - name of the Collaboration
• lang - language of Collaboration
• type - type of Collaboration
  • 1 - Main title
  • 2 - Synonyms/Alias
  • 3 - Short
• verified

Specializations

Producer

• relid - entity id
• typeid - type of entity
  • 1 - company
  • 2 - person
  • 3 - collaboration
• titleid - titles used by the entity
• start date - if different from underlying entity
• end date - if different from underlying entity
• description - producer specific information
• [ratings&co] - not implemented in the ui

Seiyuu

derived from Artist/OstDB

• relid - entity id
• typeid - type of entity
  • 2 - person
• titleid - titles used by the entity
• debut on - Start of career
• retired on - End of career
• description - Some seiyuu specific info
• [ratings&co] - not implemented in the ui

Artist

derived from OstDB

• relid - entity id
• typeid - type of entity
  • 2 - person
  • 3 - collaboration (allows to make bands)
• titleid - titles used by the entity
• debut on - Start of career
• retired on - End of career
• description - Some artist specific info
• [ratings&co] - not implemented in the ui

Mangaka

derived from Artist/OstDB

• relid - entity id
• typeid - type of entity
  • 2 - person
  • 3 - collaboration (allows us to have several persons working under the same penname)
• titleid - titles used by the entity
• debut on - Start of career
• retired on - End of career
• description - Some mangaka specific info
• [ratings&co] - not implemented in the ui

further notes

Person

• Persons need one main title, made from [title] firstname lastname (lang defaults to transcription)
• Persons can have one maiden name, made from [title] firstname lastname (lang defaults to transcription)
• Persons can have multiple alias, made from [title] firstname lastname (lang defaults to transcription)
• Persons can have multiple nickanmes, made from lastname (lang defaults to transcription)
• One can choose optional relations between persons and/or companies. (not implemented in the ui)

Company

• Companies can either be of type Company or Organization
• Companies need one main title (lang defaults to transcription)
• Companies can have multiple synonyms (lang defaults to transcription)
• Companies can have multiple short names (lang defaults to transcription)
• One can choose optional relations between persons and/or companies. (not implemented in the ui)

Collaboration

Still very unspecified

• Collaborations need a type (unspecified at the moment, see Collaboration)
• Collaborations aren't limited to either companies or persons but can be a mix of both (unspecified at the moment)

Producer

• One can make a Producer either from a Person, a Company entry or a Collaboration entry.
• One chooses from the related entry which names should the producer be known as.

Seiyuu

still very unspecified at the moment

• One can make a Seiyuu from a Person.
• One chooses from the related entry which names should the Seiyuu be known as.

Mangaka

still very unspecified at the moment

• One can make a Mangaka either from a Person or a Collaboration entry.
• One chooses from the related entry which names should the Mangaka be known as.

Artist

still very unspecified at the moment

• One can make a Artist either from a Person or a Collaboration entry.
• One chooses from the related entry which names should the Artist be known as.

Suggestion 2

creatortb

• image
• url (en)
• url (jp)
• url wiki (en)
• url wiki (jp)
• birth date
• death date
• description
• role[] - relevant for in which system the entity will be shown/used (filter)
  • Mangaka
  • Artist
  • Anime Producer
  • Seiyuu
• type
  • Person
  • Company
• parentid
  • analog to the guise system for character we use this here as well
  • let's say person A works under pseudonym B as a mangaka. then we add both persons and set the parentid for the child (the pseudonym)
  • that way we can credit the correct person while still being able to display both data entries under 1 entity

creatornametb

• name
• lang - language of title
• type - type of title
  • 1 - Main title
  • 2 - Alias
  • 3 - Maiden name
  • 4 - Nickname
• verified

creatorcreatorreltb

-- used for "silly" relations like "marriage", collaborations, etc.

• prelid
  • married
  • works for
  • works with
  • ...
• producerid
• next

Producerrelationtb

--defines the relation types

• name
• restriction
  • relations should be filtered down by type
  • personlevel relations make not much sense for companies and vice versa
  • see character system whcih works that way
• description

Producertagtb

• tag system like used for character to add further non numerical data

Top Level Agglomerates

Manga

check MangaDB

• like animenetries at anidb
• description
• genres/categories
• mangaka(s) [relation]
• picture

Character

check CharDB

• arbitrary number of titles (with language information)
• picture
• description
• seiyuu [relation]
• appearance in episodes [relation]

Song

check OstDB

• arbitrary number of titles (with language information)
• length (in seconds)
• genre (?)
• artists(s) [relation]
• appearance in animes [relation]
• ..

Collection

check OstDB

• picture
• arbitrary number of titles (with language information)
• number of tracks
• release date
• genre (?)
• artist(s) [relation]
• anime(s) [relation]
• ...

System

This details a bit of what is done and what we are aiming at