Generic PersonCompany DEV

From AniDB
Jump to navigation Jump to search

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

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

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