Problem
Many Open Library authors who have a real backlog of works on file (5+ works) still have an empty alternate_names array. As a result, readers searching using a different script or language form of the author's name cannot find them via the OL search box.
For example, before today's manual edit the entry for "Chih-tsing Hsia" (work_count=29) had no native-script form on file, so a reader typing "夏志清" could not find him on OL.
The backlog exists on the long tail of the catalog — particularly authors whose primary name on file is a romanization while the native-script form is missing. Regardless of how big that backlog is, this bot is rate-limited to a small constant load (see Frequency below).
Proposed bot
A small bot that, for one author at a time, adds one well-evidenced entry to alternate_names and writes a short edit-comment citing the sources.
Evidence requirement (per edit)
Every edit must be supported by at least two independent reputable authorities. The strong default pair:
- Wikidata — the author's Q-id, with the multilingual
labels block matching the proposed addition
- Wikipedia article title in another language — typically the article in the author's native-language Wikipedia
Other acceptable corroborators: official publisher / university page, national library authority records (LoC, BnF, NDL).
If two independent reputable sources cannot be found, the candidate is dropped. The bot does not write speculative or single-source additions.
Why this isn't a typical LLM-writes-to-OL situation
The bot itself does not generate the alternate name with an LLM. The pipeline upstream of this bot is:
- A discovery crawler reads OL search to find authors with
alternate_names == [] and work_count >= 5.
- For each such author a research worker (which may use an LLM) gathers the two-source evidence from Wikidata + Wikipedia and produces a structured JSON proposal:
{ol_key, proposed_addition, comment, evidence: [{source, url, value}, ...]}.
- A QA gate checks the JSON for required fields, that the proposed addition matches the value reported by both evidence URLs, and that the OL author still has
alternate_names == []. Only proposals that pass the gate (score 100) are forwarded.
- This bot then takes the gate-approved JSON and submits the single addition via the OL API.
Concretely: the LLM proposes; an independent automated check verifies; the bot only commits proposals that survived both. The bot's input is not free-form LLM text — it is a structured proposal whose two evidence URLs the bot itself can re-fetch and compare against before PUT.
Scope guardrails
- One addition per edit (not bulk-replacing the array)
- Author pages only (
/authors/OL...A). No work / edition / subject edits in this bot.
- Only adds to
alternate_names (not removing or reordering existing entries)
- Skips any author whose
alternate_names is non-empty (someone else already handled them)
- Skips any author whose
work_count < 5 (not worth a name edit)
Frequency
Targeting ≤ 8 edits per day total (well below polite-bot thresholds), regardless of how large the candidate pool is. Each edit is a single PUT plus 2 GETs, paced at 1.5s between requests. Happy to tighten further if reviewers want.
Edit comment format
Pure factual citation. Example:
Adding native-script form per Wikidata Q778276 (zh label '苏童') and Chinese Wikipedia article title '苏童'.
No promotional content, no project attribution in the edit comment.
Account
Bot username: agenticcommonsbot (S3 keys configured; currently 403 on PUT pending bot review, as expected).
The S3-key authentication path is wired and a test login + GET against /authors/OL2630047A.json returns 200 cleanly. The PUT is the only step pending privilege grant.
Code
Forthcoming PR will add a directory AgenticCommonsBot/ to this repo with:
wikidata_author_alias_bot.py — single-file Python 3, stdlib only, S3-key auth via /account/loginREADME.md — usage, dry-run output, evidence checklistsample_proposal.json — a real two-source proposal for reviewsample_dry_run.txt — captured dry-run output against a live (still-empty) OL author so reviewers can see the exact request/response shape
Maintainer
Ask
Looking for a thumbs-up on the approach before opening the implementation PR, plus pointers on anything you'd like tightened. Happy to adjust the per-day cap, evidence requirements, edit-comment format, or anything else that helps reviewers.
Problem
Many Open Library authors who have a real backlog of works on file (5+ works) still have an empty
alternate_namesarray. As a result, readers searching using a different script or language form of the author's name cannot find them via the OL search box.For example, before today's manual edit the entry for "Chih-tsing Hsia" (work_count=29) had no native-script form on file, so a reader typing "夏志清" could not find him on OL.
The backlog exists on the long tail of the catalog — particularly authors whose primary name on file is a romanization while the native-script form is missing. Regardless of how big that backlog is, this bot is rate-limited to a small constant load (see Frequency below).
Proposed bot
A small bot that, for one author at a time, adds one well-evidenced entry to
alternate_namesand writes a short edit-comment citing the sources.Evidence requirement (per edit)
Every edit must be supported by at least two independent reputable authorities. The strong default pair:
labelsblock matching the proposed additionOther acceptable corroborators: official publisher / university page, national library authority records (LoC, BnF, NDL).
If two independent reputable sources cannot be found, the candidate is dropped. The bot does not write speculative or single-source additions.
Why this isn't a typical LLM-writes-to-OL situation
The bot itself does not generate the alternate name with an LLM. The pipeline upstream of this bot is:
alternate_names == []andwork_count >= 5.{ol_key, proposed_addition, comment, evidence: [{source, url, value}, ...]}.alternate_names == []. Only proposals that pass the gate (score 100) are forwarded.Concretely: the LLM proposes; an independent automated check verifies; the bot only commits proposals that survived both. The bot's input is not free-form LLM text — it is a structured proposal whose two evidence URLs the bot itself can re-fetch and compare against before PUT.
Scope guardrails
/authors/OL...A). No work / edition / subject edits in this bot.alternate_names(not removing or reordering existing entries)alternate_namesis non-empty (someone else already handled them)work_count < 5(not worth a name edit)Frequency
Targeting ≤ 8 edits per day total (well below polite-bot thresholds), regardless of how large the candidate pool is. Each edit is a single PUT plus 2 GETs, paced at 1.5s between requests. Happy to tighten further if reviewers want.
Edit comment format
Pure factual citation. Example:
No promotional content, no project attribution in the edit comment.
Account
Bot username:
agenticcommonsbot(S3 keys configured; currently 403 on PUT pending bot review, as expected).The S3-key authentication path is wired and a test login + GET against
/authors/OL2630047A.jsonreturns 200 cleanly. The PUT is the only step pending privilege grant.Code
Forthcoming PR will add a directory
AgenticCommonsBot/to this repo with:wikidata_author_alias_bot.py— single-file Python 3, stdlib only, S3-key auth via/account/loginREADME.md— usage, dry-run output, evidence checklistsample_proposal.json— a real two-source proposal for reviewsample_dry_run.txt— captured dry-run output against a live (still-empty) OL author so reviewers can see the exact request/response shapeMaintainer
Ask
Looking for a thumbs-up on the approach before opening the implementation PR, plus pointers on anything you'd like tightened. Happy to adjust the per-day cap, evidence requirements, edit-comment format, or anything else that helps reviewers.