Skip to content

Tracking authors

Adding an author

Authors → Add author opens the AddAuthor dialog. You can search by:

  • Name — partial match against OpenAlex.
  • OpenAlex author ID — A1234567890, exact match.
  • ORCID — 0000-0002-1825-0097, exact match.
  • Semantic Scholar author ID — exact match.
  • Google Scholar ID — only if scholarly is installed; useful as a last resort.

Pick the candidate that matches your target. ALMa shows disambiguation context (affiliation, paper count, recent works) so you can avoid homonyms.

When you confirm, a backfill job queues in the background: recent works are pulled from OpenAlex, deduplicated against existing rows, and inserted as tracked papers (not yet in your Library). Watch the Activity panel; backfills typically complete within a minute.

Followed vs tracked

State Meaning
Followed You explicitly added them. ALMa creates an author monitor that surfaces their new works in your Feed.
Tracked The author appears on a paper in your corpus but you haven't followed them. Useful for co-author analytics and as input to author suggestions.

The Authors page lists Followed by default. The "Tracked" filter shows everyone, including the long tail of co-authors.

Identifier resolution

OpenAlex is the primary author registry, but real authors have multiple identifiers across sources. ALMa runs a hierarchical resolver after each Add to fill in:

  • OpenAlex author ID (always when known)
  • Semantic Scholar author ID (when matchable via DOIs / name)
  • ORCID (when on the OpenAlex profile)
  • Google Scholar ID (only if scholarly is enabled and resolves)

Each author row carries id_resolution_status:

Status Meaning
confirmed A direct ID match resolved this author.
probable Heuristic match (name + sample titles + affiliation).
ambiguous Multiple candidates; manual confirmation needed.
failed Nothing matched; check the spelling or try another ID.

For ambiguous / failed authors, the Authors page shows a Needs attention badge. Click in to see candidate matches and confirm manually.

Merging duplicate authors

If the same person appears twice because of a spelling variant or a split OpenAlex profile, open either author's detail card and choose Merge with author. The merge dialog searches the existing corpus, shows the two profile rows side by side, and lists metadata discrepancies such as name, affiliation, ORCID, Scholar ID, image, and profile metrics. Pick one value per field before confirming.

The same merge dialog is used from Needs attention when ALMa flags duplicate followed profiles. In that path the suspected duplicate is preselected, but the confirmation step is identical: choose which metadata survives, then merge. The primary author keeps the canonical row; publications from the alternate profile are reattached and the alternate OpenAlex ID is kept as an alias so it will not reappear as a new suggestion.

Refreshing

Three refresh paths:

  • Per-author refresh-cache — incremental, pulls only new works since the last refresh. Used by the nightly scheduler.
  • Per-author deep refresh — re-pulls the full bibliography. Use this after schema changes or if you suspect drift.
  • Deep refresh all — bulk equivalent of the above. Heavy; runs for several minutes on a large follow list.

All three are Activity-backed and report per-author progress.

Metadata and affiliation hydration

ALMa also keeps a lighter author metadata hydration ledger for profile fields, aliases, and affiliation evidence. It runs when a new author is first seen in the corpus, when you follow someone, when profiles are merged, and when you use Settings → Corpus maintenance → Rehydrate corpus metadata.

The hydration job reads OpenAlex, ORCID, Semantic Scholar, and Crossref when the needed identifiers are available. Affiliation evidence is stored per source and the displayed author affiliation is recomputed from weighted evidence, preferring current ORCID employment when available and using OpenAlex / Crossref as supporting evidence. If strong sources disagree, the Authors page can surface an affiliation-conflict row under Needs attention.

Author suggestions

Below the Followed list, the page surfaces Author suggestions — candidates you don't follow yet. Each suggestion carries a suggestion_type chip (library_core, cited_by_high_signal, adjacent, semantic_similar, openalex_related, s2_related) showing the bucket it primarily came from, plus a Suggested by N sources indicator when multiple buckets independently agreed.

See Authors → Author suggestions for what each bucket means and how scoring works.

Getting better suggestions

The rail is built fresh on every visit by combining six independent buckets. The signals that drive ranking are entirely fed by your actions, so a few small habits make a big difference:

  1. Rate your Library papers. Each star on a paper amplifies its co-authors in the rail:
  2. 5★ → co-authors carry 3× the weight of an unrated paper's co-authors.
  3. 4★ → 2×.
  4. 3★ / unrated → 1× (neutral).
  5. 2★ → 0.5×.
  6. 1★ → 0.2× (still in the pool but barely contributes). First / last authors on a rated paper get an additional 1.5× on top — they're the lead and senior author signals.
  7. Give feedback on papers. Paper feedback now also influences author suggestions. Liking or loving a paper gives a capped bump to its authors, nearby co-authors, topics, venues, keywords, and tags. Dismissing, disliking, removing, or low-rating a paper gives a capped negative signal to the same connected attributes. This is ranking-only; it does not delete papers or unfollow anyone.
  8. Dismiss authors you don't want. Rejecting a suggestion does two things:
  9. Suppresses that exact author for ~250 days.
  10. Adds their profile (topics, venues, co-authors, institution) to a learned dismissal cluster — future candidates whose attributes overlap that cluster lose up to 30 points (out of 100). So dismissing 2-3 authors from a sub-area you don't care about will start filtering similar authors automatically. The cluster has a 100-day lookback so old dismissals decay out as your interests shift. Co-authorship overlap counts as a very light penalty (≈0.8/paper) — you stay free to follow people the dismissed author wrote with.
  11. Network buckets refresh automatically. The openalex_related and s2_related buckets read from a cache that the suggestions rail refreshes asynchronously each time you open the Authors page, pulling fresh external candidates beyond what your Library co-author / citation graph already shows — no manual button.

The per-bucket weights are backend defaults tilted toward library_core (the strongest evidence), with the network buckets at 0.9 so external sources still get real airtime; they are not user-configurable in the UI today.

A candidate working in your #1 library topic will rank far higher than one sharing a fringe topic — the system weights shared topics by how prevalent they are in your Library, so your core area dominates naturally.

If a suggestion repeatedly surfaces a category of author you don't want, dismiss them — the rail will learn the cluster and stop bothering you.

Bucket calibration

Each Follow / Dismiss is logged with the bucket label that surfaced the author. Over time, ALMa learns which buckets actually produce authors you keep: a bucket where Follows dominate gets pushed toward 1.5×; one where Dismisses dominate gets pulled toward 0.5×. The chip on each card (e.g. ↑ bucket 1.18× / ↓ bucket 0.74×) shows the current multiplier — it appears only once the multiplier has moved meaningfully away from 1.0. The default bucket weights are the prior; this calibration is the posterior, multiplied in. On a fresh DB nothing changes — the system needs a few weeks of rail-side feedback to warm up.

Removing

Removing an author stops the monitor but does not delete their papers from your Library. Saved papers stay saved; new works just stop flowing into your Feed.

Follow and remove actions also feed Discovery ranking. Following an author gives their author profile a positive signal; removing or dismissing an author gives their profile a negative signal. Both are ranking-only effects: they help paper recommendations move up or down without changing any paper's Library or reading state.

API

# add an author by name
curl -X POST http://localhost:8000/api/v1/authors \
  -H 'Content-Type: application/json' \
  -d '{"name":"Andrew Ng","follow":true}'

# refresh
curl -X POST http://localhost:8000/api/v1/authors/A1234567890/refresh-cache

# resolve identifiers
curl -X POST http://localhost:8000/api/v1/authors/A1234567890/resolve-identifiers

See the REST API for the full set.