A chart can show that a research phrase is becoming more common. The next questions are harder: which institutions are working on it, and which papers should I read?
I built paper-trends to connect those steps. It uses publication metadata from OpenAlex to generate interactive reports for academic conferences.
You can try the CVPR report without signing in. Click a phrase such as “diffusion models,” then click a related institution to keep exploring.
The source code is on GitHub, under the MIT license.
Following a trend back to its papers
The interaction starts with a phrase. Clicking it opens a panel with its yearly trend, related institutions, topics, and papers. Clicking an institution opens another view of its publication trends and characteristic phrases.
Here is that interaction in the ECTC example, a conference focused on electronic packaging:
The GIF shows an earlier interface snapshot, so individual figures may differ from the current online reports.
One analysis pipeline, three ways to use it
The project has three interfaces that share the same Python analysis code:
- A CLI for fetching data and generating reports.
- A Streamlit app for changing periods, comparing conferences, filtering papers, and exporting CSV files.
- Static HTML reports for sharing a particular analysis.
The pipeline is:
- Retrieve conference records from OpenAlex.
- Normalize and store the records locally.
- Calculate phrase trends, topics, and publication statistics.
- Build the report and its linked detail-panel data.
- Render the HTML output.
Sharing the analysis code keeps the counting rules consistent across the CLI, app, and reports.
Keeping interactions in a static report
The online demo runs on GitHub Pages. Clicking a phrase does not start a Python process or make an OpenAlex API request.
The report generator precomputes the data needed by the detail panels. Browser-side JavaScript uses that data to display trends and navigate between related entities.
This works well for a fixed report: the expensive analysis happens during generation, while readers can explore the result without installing anything or supplying an API key.
There is a tradeoff. The report is a saved snapshot, and precomputed detail data adds to its size. Changing the analysis period or fetching another conference requires the local app or CLI and a new analysis.
The public examples cover CVPR and ECTC from 2016 through 2025. The full Streamlit app runs locally, and fetching records requires an OpenAlex API key.
Defining what a keyword trend means
Counting every abstract that mentions a phrase once can include papers where the phrase is only background context.
For the phrase trends, the project counts a paper when the normalized phrase appears:
- In its title, or
- At least twice in its abstract.
The report compares shares of papers, which helps account for changes in the total number of publications.
This is still a vocabulary-based measure. A paper can discuss a technique without using the exact phrase, and terminology can change over time. A falling phrase share does not necessarily mean the technique is being used less.
Topic analysis is a separate view, using TF-IDF and non-negative matrix factorization (NMF). The resulting topics help organize the corpus, but they are not authoritative labels for a research field.
Conference metadata needs checking
One issue during validation was separating a main conference from its workshops.
A source-name search could return both. Even records assigned to a main-conference source could contain metadata pointing to workshop proceedings.
The fetch pipeline therefore uses source matching, configured DOI-prefix fallbacks, and checks for identifiable workshop records. Those checks use metadata supplied by OpenAlex, including source names and known workshop URL patterns.
This improves the dataset, but it does not establish that the result exactly matches an official proceedings list. Coverage still depends on the upstream records.
The practical lesson: a plausible paper count is not enough to validate a conference dataset. Inspecting source matches and unusual records can reveal problems that aggregate charts hide.
Recording when the data was fetched
A report’s generation date and its data-fetch date describe different things.
The project records a successful fetch timestamp in a sidecar file and associates it with the corpus using a SHA-256 hash. Reports can then show whether that provenance matches the data being analyzed.
If the record is missing or does not match, the fetch date is shown as unknown. A file’s modification time is not used as a substitute: copying a dataset should not make it appear freshly fetched.
Try it
The project supports English and Chinese interfaces and reports.
I’d be interested in feedback on the exploration workflow: when you notice a changing research phrase, what would you want to inspect next—institutions, related topics, or individual papers?
Top comments (0)