Generic PersonCompany DEV: Difference between revisions

From AniDB
Jump to navigation Jump to search
Line 242: Line 242:
* verified
* verified


==Producerproducerreltb==
==creatorcreatorreltb==
-- used for "silly" relations like "marriage", collaborations, etc.
-- used for "silly" relations like "marriage", collaborations, etc.
* prelid
* prelid

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