Generic PersonCompany DEV: Difference between revisions

From AniDB
Jump to navigation Jump to search
mNo edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{TOCright}}
{{TOCright}}
=Concerns and Goals=
=Concerns and Goals=
As the [[CharDB_DEV|CharDB]], [[OstDB_DEV|OstDB]], [[MangaDB_DEV|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.
As the [[CharDB DEV|CharDB]], [[OstDB DEV|OstDB]], [[MangaDB DEV|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.
* 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.
Line 12: Line 13:
** person<=>person relations? (married?)
** person<=>person relations? (married?)


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


* <s>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?</s> - ''Names have their own table for every Entity that has titles.''
* <s>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?</s> - ''Names have their own table for every Entity that has titles.''
Line 21: Line 22:
* Also how are matching pseudonyms (they're not unique, are they?) handled?
* Also how are matching pseudonyms (they're not unique, are they?) handled?


* Looking at [[Generic_PersonCompany_DEV#Producer|Producer]], [[Generic_PersonCompany_DEV#Artist|Artist]], [[Generic_PersonCompany_DEV#Mangaka|Mangaka]] and [[Generic_PersonCompany_DEV#Seiyuu|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:
* Looking at [[Generic PersonCompany DEV#Producer|Producer]], [[Generic PersonCompany DEV#Artist|Artist]], [[Generic PersonCompany DEV#Mangaka|Mangaka]] and [[Generic PersonCompany DEV#Seiyuu|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]
*# 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?
*# keep using the current way that is xvcl everything and make several modules for each specialization?
Line 29: Line 30:
[[Image:People1.png]]
[[Image:People1.png]]


'''''Warning: Image doesn't reflect the current layout.'''''
{{eyecatch|Warning|Image does '''not''' reflect the current layout!}}


* To Fix:
* To Fix:
Line 128: Line 129:
* end date - if different from underlying entity
* end date - if different from underlying entity
* description - producer specific information
* description - producer specific information
* [ratings&co] - not implemented in the ui
* [ratings&co] - not implemented in the UI


====Seiyuu====
====Seiyuu====
<tt>derived from [[Generic_PersonCompany_DEV#Artist |Artist]]/[[OstDB_DEV |OstDB]]</tt>
<tt>derived from [[Generic PersonCompany DEV#Artist|Artist]]/[[OstDB DEV|OstDB]]</tt>
* relid - entity id
* relid - entity id
* typeid - type of entity
* typeid - type of entity
Line 142: Line 143:


====Artist====
====Artist====
<tt>derived from [[OstDB_DEV | OstDB]]</tt>
<tt>derived from [[OstDB DEV|OstDB]]</tt>
* relid - entity id
* relid - entity id
* typeid - type of entity
* typeid - type of entity
Line 154: Line 155:


====Mangaka====
====Mangaka====
<tt>derived from [[Generic_PersonCompany_DEV#Artist |Artist]]/[[OstDB_DEV |OstDB]]</tt>
<tt>derived from [[Generic PersonCompany DEV#Artist|Artist]]/[[OstDB DEV|OstDB]]</tt>
* relid - entity id
* relid - entity id
* typeid - type of entity
* typeid - type of entity
Line 170: Line 171:
* Persons can have '''one''' ''maiden name'', 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''' ''alias'', made from [title] firstname lastname (lang defaults to transcription)
* Persons can have '''multiple''' ''nickanmes'', made from 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)
* One can choose '''optional''' relations between persons and/or companies (not implemented in the UI).


===Company===
===Company===
Line 178: Line 179:
* Companies can have '''multiple''' ''synonyms'' (lang defaults to transcription)
* Companies can have '''multiple''' ''synonyms'' (lang defaults to transcription)
* Companies can have '''multiple''' ''short names'' (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)
* One can choose '''optional''' relations between persons and/or companies (not implemented in the UI).


===Collaboration===
===Collaboration===
<tt>Still very unspecified</tt>
<tt>Still very unspecified</tt>


* Collaborations '''need''' a type (unspecified at the moment, see [[Generic_PersonCompany_DEV#Generic_Fields_-_Collaboration|Collaboration]])
* Collaborations '''need''' a type (unspecified at the moment, see [[Generic PersonCompany DEV#Generic Fields - Collaboration|Collaboration]])
* Collaborations aren't limited to either companies or persons but can be a mix of both (unspecified at the moment)
* Collaborations aren't limited to either companies or persons but can be a mix of both (unspecified at the moment).


===Producer===
===Producer===
Line 228: Line 229:
**Company
**Company
* parentid
* parentid
**analog to the guise system for character we use this here as well
**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)
** 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
** that way we can credit the correct person while still being able to display both data entries under 1 entity
Line 258: Line 259:
**relations should be filtered down by type
**relations should be filtered down by type
**personlevel relations make not much sense for companies and vice versa
**personlevel relations make not much sense for companies and vice versa
** see character system whcih works that way
** see character system which works that way
*description
*description


Line 266: Line 267:
=Top Level Agglomerates=
=Top Level Agglomerates=
==Manga==
==Manga==
<tt>check [[MangaDB_DEV|MangaDB]]</tt>
<tt>check [[MangaDB DEV|MangaDB]]</tt>
* like animenetries at anidb
* like animenetries at AniDB
* description
* description
* genres/categories
* genres/categories
Line 274: Line 275:


==Character==
==Character==
<tt>check [[CharDB_DEV|CharDB]]</tt>
<tt>check [[CharDB DEV|CharDB]]</tt>
* arbitrary number of titles (with language information)
* arbitrary number of titles (with language information)
* picture
* picture
Line 282: Line 283:


==Song==
==Song==
<tt>check [[OstDB_DEV|OstDB]]</tt>
<tt>check [[OstDB DEV|OstDB]]</tt>
* arbitrary number of titles (with language information)
* arbitrary number of titles (with language information)
* length (in seconds)
* length (in seconds)
* genre (?)
* genre (?)
* artists(s) [relation]
* artists(s) [relation]
* appearance in animes [relation]
* appearance in anime [relation]
* ..
* ...


==Collection==
==Collection==
<tt>check [[OstDB_DEV|OstDB]]</tt>
<tt>check [[OstDB DEV|OstDB]]</tt>
* picture
* picture
* arbitrary number of titles (with language information)
* arbitrary number of titles (with language information)
Line 305: Line 306:


[[Category:Development]]
[[Category:Development]]
[[Category:CharDB]]

Latest revision as of 16:15, 13 May 2009

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