premiosCine: The Scraper That Turns Awards Histories into a Joinable Dataset
From IMDb event pages to TMDB enrichment to Power BI, this repo shows how identity keys, category normalization, and a few practical hacks can turn messy film awards into something you can actually analyze.
- premiosCine is built around stable IMDb IDs, which makes awards data joinable across scraping, enrichment, and BI instead of trapped inside isolated exports.
- TMDB enrichment is not a side quest here. It is the step that turns raw event pages into structured records that can actually be compared across years.
- The repo treats historical cleanup as part of the analysis layer, especially in category unification and the awkward 1930 Oscars edge case.
- Its value is narrower than a general movie scraper, but that narrowness is what makes it credible for film research.
The smartest thing in premiosCine is not that it scrapes awards pages. It is that it refuses to treat a scraped page as the final unit of truth. The repo is designed to carry the same film or person through multiple systems without losing identity, which is why it can answer research questions instead of just archiving names.
The real product is not scraping. It is reconciliation.
Awards data looks simple until you try to compare it across decades. Event pages change, category names drift, people and films get mixed together, and the same award can be described differently in different sources. premiosCine treats that mess as the core problem, not an edge case.
That is why the project leans so hard on IMDb IDs. A title can be translated, retitled, or duplicated. A stable ID can travel.
Scraping en PHP de la web Filmaffinity para obtener las puntuaciones a partir del código del usuario
How premiosCine builds a universal key
The extraction layer lives in Python, centered on ImdbAwardScrapping.py. It walks IMDb event pages by year, separates film awards from person awards, and pulls IMDb identifiers with simple regex patterns like tt... and nm.... That looks modest, but it is the design choice that makes the rest of the pipeline deterministic.
# Conceptual shape of the scraper
for year in years:
page = fetch_imdb_event(event_code, year)
awards = parse_best_sections(page)
for award in awards:
if award.is_film_award:
imdb_id = extract_tt_id(award.link)
else:
imdb_id = extract_nm_id(award.link)
save_row(year, award.category, imdb_id, award.title)The key move is not parsing more HTML. It is deciding that every later step will trust the ID instead of the label. Once that happens, enrichment stops being guesswork.
Why TMDB enrichment is the difference between data and analysis
After extraction, the repo uses a tight three-step pattern: limpiar_lista, obtener_tmdb_id, and enriquece_datos. In practice that means deduping records, resolving TMDB through IMDb identifiers, and then hydrating the dataset with structured metadata.
| Approach | Strength | Weakness | What premiosCine does instead |
|---|---|---|---|
| Title or name matching | Easy to start | Breaks on duplicates, translations, and remakes | Uses IMDb IDs as the join key |
| Raw scrape and dump | Fast to produce | Hard to analyze across sources | Adds TMDB enrichment for structured fields |
| Manual spreadsheet cleanup after the fact | Flexible | Usually disconnected from the pipeline | Builds normalization into the workflow |
The repo uses tmdb.Find(imdb_id), which is the right kind of boring. It avoids fuzzy matching on names and titles, so the mapping is anchored to the same identifier that came out of IMDb. That is how you get a dataset that stays consistent when the same film appears under different labels or languages.
The last mile is where the project gets practical
This is where the repo stops pretending that history is tidy. The categorías unificadas.xlsx file is not a cleanup afterthought. It is the mechanism that lets category names survive long enough to become a timeline.
The Spanish CSV export matters for the same reason. A semicolon-delimited file is a small compatibility choice, but it removes friction for Excel users in Spanish locales. That is classic data engineering: spend a little effort up front so the dataset is easier to use later.
| Historical problem | Naive response | premiosCine response |
|---|---|---|
| Category names drift over time | Keep the raw labels as-is | Map them into a unified category file |
| Older ceremonies do not fit cleanly into one year | Ignore the anomaly | Handle the 1930 Oscars as a special case |
| Spanish Excel misreads commas | Tell users to reformat | Export a semicolon CSV alongside the standard one |
What the Power BI layer makes visible
Once the data is cleaned, the Power BI model turns the pipeline into an analytical instrument. At that point the repository is not asking whether it can collect awards. It is asking what patterns only appear after you align categories, years, people, and films into one model.
That opens the door to questions that raw lists cannot answer cleanly: category trends over time, gender distribution in technical awards, and cross-event comparisons between Goya and Oscar data. The point is not a dashboard for its own sake. The point is an artifact that can support actual research.
| Question | Without joinable data | With premiosCine |
|---|---|---|
| How do categories evolve across decades? | You see inconsistent labels | You get a unified timeline |
| Which people and films recur across awards? | You have separate pages | You can trace shared IDs |
| What changes between Goya and Oscar analysis? | You compare two piles of exports | You compare two linked datasets |
One pipeline, two kinds of awards
The repo also makes a useful distinction between film awards and person awards. That matters because the analytical object changes. Sometimes the unit is a title. Sometimes it is a human being. premiosCine keeps both in the same pipeline without pretending they are the same thing.
What premiosCine does better than a generic awards scraper
Generic scrapers tend to stop at collection. premiosCine goes further by building a path from source pages to normalized, enriched, BI-ready records. That is narrower, but more useful for anyone trying to compare awards histories rather than just browse them.
| Project type | Best at | Weak at | Why premiosCine stands out |
|---|---|---|---|
| Scrape-and-dump repo | Fast extraction | Long-term analysis | It preserves identity through the full pipeline |
| Name-based matching system | Simple setup | False matches and duplicates | It anchors joins to IMDb IDs |
| Broad movie analytics platform | Wide coverage | Less archival precision | It focuses on awards history and normalization |
There is a real researcher’s instinct behind that choice. The project does not try to model all cinema data. It picks a hard, specific slice, then makes that slice trustworthy enough to ask better questions.
