How Metadata Shapes Related-Title Suggestions
A field-by-field model for understanding how descriptive metadata can connect works while version metadata determines whether a candidate is usable.
In short: Metadata supplies the labels and relationships a discovery system can use: title, creator, subject, date, media type, series relation, format, and language. Shared work-level fields can make two titles meaningfully related, while version-level fields determine whether a candidate is usable. Missing, incorrect, and merely different metadata require different responses.
Metadata is not a verdict about taste. It is structured evidence that can connect records. The better the identity and descriptive fields represent a library, the more explainable its discovery paths can become.
Separate work fields from version fields
| Work-level fields | Version-level fields |
|---|---|
| Title and alternate title | Edit or cut |
| Creator or contributor | Duration |
| Subject or genre | Audio language |
| Release context | Subtitle availability |
| Series and episode relation | Format or quality label |
| Media type | Source-specific identifier |
Two items may be related as works but differ substantially as versions. EIDR’s public hierarchy distinguishes works, series, episodes, edits, and manifestations. DCMI terms similarly distinguish identifier, type, relation, format, language, date, creator, and subject.
Recognise several kinds of relationship
Descriptive similarity comes from subjects, genres, periods, or creators. Structural relation connects a series, season, episode, adaptation, or other explicit relation. Version relation connects editions of one work. Viewer-defined relevance asks whether any of those links answers the current discovery brief.
Do not assume the current product weighs every field equally. Norva describes recommendations derived from a connected compatible source, but exact selection logic requires current product evidence.
Build a visible-field diff
Compare one seed and candidate:
| Field | Seed | Candidate | Status |
|---|---|---|---|
| Work identity | Shared / different / unknown | ||
| Creator | |||
| Subject or genre | |||
| Date or period | |||
| Relation | |||
| Language | |||
| Version |
The table makes source-based discovery explainable without claiming access to an internal algorithm. Use only values actually visible or verified from the authorised source.
Distinguish missing, incorrect, and different
Missing means a field has no usable value. Incorrect means reliable evidence contradicts the value. Different means the candidate genuinely has another creator, period, language, or format. Only the second may justify correction, and only through an authorised metadata process.
Do not fill blanks with assumptions. Follow the incomplete-metadata diagnosis to identify which missing field blocks discovery and whether a legitimate source-side correction exists.
Test whether a relation helps the viewer
A technically shared genre may be too broad. Ask what the relation changes: does it surface a new period, creator, style, or format that fits the brief? Record one sentence: “Candidate B is related through creator and period, but differs in genre, which matches the request to broaden.”
Use the two-title relationship card when the visible connection is surprising. A transparent weak relation can still be useful; an unexplained card should remain a lead, not a trusted match.
Check version readiness separately
Before shortlisting, verify that the available version has the needed language, subtitles, episode mapping, device context, and source availability. Wording such as “same work” does not mean “interchangeable playback version.”
Norva organises variants according to its public features. Exact grouping, recommendation, and default-version behavior should be verified in the current build.
Original evidence: metadata diff
Choose one seed and three candidates. Complete the seven-field diff, then highlight which shared fields explain each suggestion and which version fields affect readiness. Ask another reviewer to identify the strongest and weakest relation from the table alone.
The exercise audits visible evidence in one sample. It does not establish causal weighting, universal metadata quality, or product performance.
Common mistakes and limitations
- Treating metadata as a prediction of personal taste.
- Mixing a work relationship with version equivalence.
- Calling every blank field incorrect.
- Inventing missing values to improve a path.
- Assuming card order reveals field weighting.
- Ignoring source-specific episode or language data.
Frequently asked questions
Which metadata field matters most?
There is no universal answer. The useful field depends on the discovery question and current verified product behavior.
Can artwork create a recommendation relationship?
Artwork can help recognition, but it is weak identity evidence. Prefer explicit titles, identifiers, creators, dates, and relations.
Should users correct every missing field?
No. Correct only through an authorised workflow with reliable evidence and a clear discovery or retrieval benefit.