How Source-Based Recommendations Support Discovery
Source-based recommendations form paths through the media and metadata already available from a compatible source rather than supplying a separate catalogue.
In short: Source-based recommendations help you move from one known title to related items already represented by your connected source. Their coverage depends on what that compatible source contains and how its metadata describes each work. Treat every suggestion as a discovery lead, then verify identity, version, availability, language, subtitles, and relevance before shortlisting it.
This model is useful because it narrows exploration to a library the viewer can actually inspect. It also has a clear boundary: a discovery interface cannot recommend a source item it does not know or repair metadata it never received.
Separate four layers
| Layer | Question |
|---|---|
| Source availability | Which media records are currently represented? |
| Work identity | Which film, series, season, episode, or version is this? |
| Descriptive metadata | Which creators, subjects, dates, genres, languages, and relations are available? |
| Viewer decision | Does this candidate fit the current discovery brief? |
Confusing these layers leads to false conclusions. A missing suggestion can reflect source coverage or incomplete metadata; an irrelevant suggestion can still be an available work whose visible relationship is too broad for the current brief.
Understand the source boundary
Norva is software that organises and plays media from a compatible source the user owns or is authorised to use. It does not include a media catalogue in the subscription. Its public features describe recommendations from the connected source.
Therefore, “source-based” should not be rewritten as universal, global, or unlimited. Availability, languages, subtitles, and versions depend on the source and media. Review the complete discovery guide for the search, browse, and recommendation roles around this boundary.
See how metadata creates paths
DCMI metadata terms distinguish title, creator, subject, date, type, format, language, and relation. EIDR’s work on media identifiers and hierarchies illustrates the difference between a creative work, series, episode, edit, and manifestation. These fields can support meaningful paths such as same creator, related series, similar subject, or shared period.
The presence of a field does not prove its weight in the current product. Use the metadata discovery explainer to observe which relationships are visible without inventing an internal formula.
Verify each recommendation as a lead
For one candidate, record:
- the seed title;
- visible shared attributes;
- important differences;
- exact candidate identity;
- available version and access options;
- whether it answers the discovery question.
Open the detail surface before playback where possible. A candidate can be related at work level yet unsuitable because the available version lacks the required language or subtitles. Conversely, a surprising candidate can be valuable when one credible relation fits the brief.
Use the related-title evaluation card when the relationship is not obvious.
Diagnose coverage gaps carefully
When a known related work is not suggested, search for it directly. If search finds it, compare its metadata with the seed. If it is absent entirely, note source availability rather than blaming recommendation relevance. If it exists but key fields are blank or inconsistent, follow the incomplete-metadata workflow.
Do not edit dates, creators, or categories merely to force a relationship unless the source’s authorised metadata workflow and evidence support the correction.
Original evidence: source-boundary map
Choose one seed and five visible suggestions. Build four columns for availability, identity, metadata relationship, and viewer decision. Use “unknown” whenever a field is not visible. Ask another reviewer to explain why each candidate entered or left the shortlist.
The map reveals where evidence ends. It can show that a relation is visible or missing; it cannot identify an internal ranking rule or measure recommendation quality across all libraries.
Common mistakes and limitations
- Describing source-based suggestions as a separate media catalogue.
- Assuming card order reveals relationship strength.
- Treating absent metadata as a negative attribute.
- Ignoring version and accessibility needs.
- Claiming a particular algorithm or personalisation method without proof.
- Correcting source metadata without authority or evidence.
Frequently asked questions
Can a recommendation include an unavailable title?
The visible state depends on current source and product behavior. Verify availability separately and use the unavailable-title workflow when a card cannot be opened.
Why do two sources produce different discovery paths?
They can contain different works, versions, and metadata. Compare those inputs before comparing the resulting suggestions.
Does a source-based recommendation guarantee relevance?
No. It is a lead. The viewer still evaluates the visible relationship against a specific discovery brief.