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 has 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:
- 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]
 - 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
- 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
- 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 nicknames, 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
- analogue 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
 
creatorrelationtb
--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 which works that way
 
 - description
 
creatortagtb
- 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 anime [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
