Guides
Part of K-drama actors you can actually verify in 2027
What a K-drama actors database needs to get names and credits right
K-drama actors data: the schema an English-language index needs, why name order deserves its own field, and the fields that should not exist at all.
Most English-language indexes of Korean television were built for American TV and had Korean productions poured into them. That caused nearly every error. It is a schema problem, not a research problem.
The same mismatch appears in a K-drama actors directory, where fields copied from American television cannot hold Korean credits.
This page sets out the fields such a record needs, what each one prevents, and which fields should not exist at all. It names no performer and holds no data about anyone.
What to take away
- The identifying form of a name is the Hangul. Every romanisation is a label attached to it, not a competing version of it.
- Fields borrowed from American television break hereepisode counts, season numbering and a single unlabeled year all encode assumptions that do not hold.
- The fields you leave out matter as much as the ones you keep. Nothing personal, nothing about a person that is not about published work.
The schema, field by field
| Field | What it holds | The error it prevents |
|---|---|---|
| Name in Hangul | The Korean form as the production published it | One person split into several entries by spelling |
| Romanisation as published | The Latin form the source actually printed | An unrepeatable match to the source you used |
| Name order flag | Whether the stored romanisation is family name first | A whole index silently inverted |
| Alternate name forms | Every variant seen, with where it appeared | Searches that return nothing for a record you hold |
| Production title, original | The Korean title as published | Losing the record when the English title changes |
| Production title, official English | The title the production itself uses in English | Filing one production twice under two translations |
| Commissioning body | Broadcaster or platform, with territory | Two productions with similar titles merged |
| Season and part | Season identity, and the release event within it | Split releases counted as separate seasons |
| Episode identifiers | Which episodes, not how many | Counts that change with every recut |
| Role type | Lead, supporting, special appearance, voice, as billed | A tally that adds different things together |
| Production dates | When it was shot, labeled as production dates | Work filed in the year it aired rather than the year it happened |
| Broadcast or release dates | Domestic first, international separately, each labeled | One unlabeled year standing in for three facts |
| Source | The exact page or document the entry came from | An entry nobody can ever recheck |
| Checked date | When the entry was last confirmed | Errors carried for years behind a confident display |
The three-date problem behind the last group is worked through in the three years a production has, and the naming conventions behind the first group are in how this production system records itself.
Schema fields and errors prevented
- Name in Hangulprevents split entries
- Romanisation as publishedrepeatable source match
- Name order flagprevents inverted index
- Alternate name formsprevents empty searches
- Production title originalprevents lost records
- Role typeprevents mixed tallies
- Production datesprevents wrong-year filing
Why name order needs its own field
An index can store a romanised name correctly and still be useless, because the reader has no way to know which half is the family name. A boolean that records the order removes the ambiguity for every consumer of the data at once, and it costs one column.
Name order storage options
Order flag
- Ambiguity
- Removed
- Cost
- One column
- When confident
- Fine
- When unknown
- Say unknown
Split given/family
- Ambiguity
- Hidden guess
- Cost
- Structural change
- When confident
- Better
- When unknown
- Forces guess
Splitting into given and family fields is better when you are confident and worse when you are not. It forces a guess into a structural slot where nobody can later see the guess.
Where order is unknown, say so instead of guessing. Libraries encode the same principle in authority control: an identifier carries the variants instead of a preferred form pretending to be the entity.
Fields that should not exist
A directory of published work needs the work. It does not need the person.
Date of birth, age, home region, military service, and relationships are not fields in a professional work record. Family, health, and religion are not either, and holding them creates obligations and risks that the record has no reason to take on.
A public reference project holding such material does so under a published policy with sourcing requirements. Read the encyclopedic policy on material about living people; it argues for restraint from the inside.
The same applies to derived judgments. Popularity scores, rankings and any composite index are not observations, and a stored score is indistinguishable from a fact once it has been copied twice. The argument against them, made for another medium, is in why a television ranking measures visibility.
Normalizing without destroying
The instinct when data is messy is to clean it into one canonical form. Resist most of that instinct here.
Data cleansing that overwrites the source value loses the ability to re-derive anything when the rule turns out to be wrong. Keep the raw value as published, add the normalized value in its own field, and record which rule produced it. Then a change of rule is a re-derivation rather than a re-research.
The one place to normalize hard is dates, which should be stored in a single unambiguous format with the source's own format recorded alongside. Everything else is safer as raw plus derived.
Common questions
Should I store a display name at all?
Yes, as a derived field, chosen by a stated rule from the stored variants. What you should not do is store only the display name.
How do I handle a stage name?
As another name form with its own source, linked to the same entity. It is not a correction of anything.
What if the official page is gone?
Cite the archived version and record that you did. An entry sourced to an archive is stronger than one sourced to a live aggregator page that may itself change tomorrow.
Is a count of leading roles a reasonable field?
Only as a derived number with its definition attached, and even then it invites misuse. Store role type per credit and let anyone who wants a count compute it and defend the definition themselves. The wider orientation on this market is in the pillar on reading a Korean cast list.
