Generic PersonCompany DEV: Difference between revisions
Jump to navigation
Jump to search
Line 252: | Line 252: | ||
* next | * next | ||
== | ==creatorrelationtb== | ||
--defines the relation types | --defines the relation types | ||
*name | *name |
Revision as of 23:56, 30 December 2008
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:
- 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 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
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 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