Bot Account Application: AgenticCommonsBot

[WendyLee07]

Bot Account Application Request

Account Name: AgenticCommonsBot
GitHub Username: WendyLee07 (working as part of the Agentic Commons project)
Purpose: Fill missing native-script alternate_names on long-tail OpenLibrary author records (CJK / Cyrillic / Arabic / etc.), citing Wikidata + Wikipedia as independent evidence sources.

Request

• Please grant bot privileges to the AgenticCommonsBot account
• Please add AgenticCommonsBot to the "API" usergroup

Why this matters

Many OL authors with a real backlog of works (5+) still have an empty alternate_names array — readers searching with a different script or language form of the author's name can't find them. For example, before a recent manual edit the entry for "Chih-tsing Hsia" had no native-script form on file, so a reader typing "夏志清" couldn't find him.

Bot behavior (per edit)

For one author at a time:

1. GET /authors/OL...A.json
2. Verify alternate_names is still empty (skip if already populated)
3. Append exactly one well-evidenced addition
4. PUT the updated record with a factual-citation edit comment

Scope guardrails

• Author pages only (/authors/OL...A). No work / edition / subject edits.
• Append-only — never removes or reorders existing entries.
• Skips authors with work_count < 5 (low search value).
• ≤8 edits/day total, well below polite-bot thresholds.

Evidence requirement

Each proposed addition requires two independent reputable sources:

• Wikidata — author's Q-id with matching multilingual label
• Wikipedia article title in another language (typically the native-language wiki)

If two sources cannot be confirmed, the candidate is dropped — no speculative or single-source additions.

Edit comment format

Pure factual citation, no slogans or project attribution:

Adding native-script form per Wikidata Q778276 (zh label '苏童') and Chinese Wikipedia article title '苏童'.

Pipeline architecture

This is not a free-form LLM editing OL. The pipeline is:

1. Discovery crawler finds candidates with alternate_names == [] and work_count ≥ 5
2. Research worker (LLM-assisted) gathers two-source evidence and produces a structured proposal
3. Independent QA gate re-fetches both evidence URLs and verifies the proposed value matches before the bot sees it
4. Only QA-passed proposals reach the bot, which performs the single PUT

The LLM proposes; an independent automated check verifies; the bot only commits proposals that survived both.

Code

Already up for review at openlibrary-bots#451 — single-file Python 3 stdlib, S3-key auth, with a sample two-source proposal (Su Tong → 苏童 for OL2630047A) and captured dry-run output (login 200, GET 200, PUT 403 as expected pending this grant).

Operator contact

• GitHub: @WendyLee07
• Email: wiki-bot@agentic-commons.org

Thank you for reviewing! 🙏

@mekarpeles @hornc

[tfmorris]

Agentic Commons sounds like a cool concept and improving findability for non-Latin script names has been a long time goal, but I'm not sure anything "agentic" is needed here. I applauded the initiative, but I think it needs a little tweaking.

Some specific comments:

• alternate_names == [] will exclude records which have been merged or which have had alternate name forms added, but which don't include non-Latin forms. I think this can be relaxed.
• work_count > 5 is fine, but another higher value approach might be to work from a list of authors sorted by descending work count
• "discovery crawler" sounds a little worrying (perhaps this is the "agentic" part?) since OpenLibrary is already getting hammered with crawler traffic. The candidate list could be easily generated from the monthly bulk data dumps and then re-verified at edit time.
• Wikidata & Wikipedia aren't really independent sources, but Wikidata alone is fine as long as it's a reliable match
• The example author record has no Wikidata ID or birth/death dates, so is a weak match, unless the list of works was used, which isn't clear. The lowest hanging fruit are the authors with Wikidata IDs assigned, but no non-Latin name forms. Note also that Wikidata has many more OLIDs than OpenLibrary has Wikidata IDs, so it would be more productive to work from that end.
• Su Tong already has multiple author records, so the most important task is merging them with the canonical record https://openlibrary.org/authors/OL713582A
• The way the proposal is worded, it sounds like only a single name form would be added per edit, but once you have the Wikidata ID, it would be much better to add all available (unique) name forms, including Arabic, Hebrew, Russian, Thai, etc (and perhaps other romanized forms like the Wikidata AKA "Tong Zhonggui". Since this is a findability aid, it is OK, in my opinion, to be promiscuous.

EDIT: Similarly, the other example has multiple author records

before a recent manual edit the entry for "Chih-tsing Hsia" had no native-script form on file, so a reader typing "夏志清" couldn't find him.

A search shows https://openlibrary.org/authors/OL16201417A which got added without the romanized version of its name due to #11877 (now fixed), although it doesn't show the record with your recent edit due to #12890.

[WendyLee07]

Thanks @tfmorris — going through each point.

On "agentic" first: you're right, there's no LLM needed for this bot. We'll drop that framing.

1. alternate_names == [] is too narrow — agreed. Switching to "no non-Latin form present" using a Unicode-block check.
2. Sort by work_count instead of threshold — agreed, sorting descending and processing high-impact first.
3. Don't crawl OL, use the dump — agreed. We'll stream ol_dump_authors_latest.txt.gz monthly, filter offline, and only do a single GET per candidate right before PUT (to re-verify in case the dump is stale).
4. Wikidata alone is enough — agreed, you're right they're not really independent. Using Wikidata as the single source, anchored on the cross-linked Q-id.
5. Start from authors that already have a Q-id — agreed. Restricting candidates to OL records with remote_ids.wikidata populated. Switching the sample from OL2630047A to the canonical OL713582A.
6. Duplicate author records (Su Tong / Chih-tsing Hsia) — agreed dedup is more important, but it's a different problem (entity resolution, merge history). Keeping this bot strictly on alternate_names; dedup might be a separate follow-up later.
7. Add all unique forms in one edit, be promiscuous — agreed. Each edit adds all missing non-Latin Wikidata labels in one PUT, after dedup against current alternate_names (NFC normalized).

I'll update openlibrary-bots#451 over the next couple of days to reflect this design.

Thanks again.

[WendyLee07]

Hi @tfmorris — gentle bump on my reply above. Anything else you'd like clarified or trialed before this can move forward? Happy to run a longer shadow window, share more dry-run samples, or split the ask into smaller pieces if that helps. Thanks!

[tfmorris]

Hi @WendyLee07. I missed the request for feedback/reply. Since you appear to have agreed with all the points I raised, I don't have any objections. I agree that dedupe is a separate problem.

HOWEVER, I'm just an interested observer of the project and have no control or authority, so you really need to get buy-in from @mekarpeles @hornc or some other staff member.

[WendyLee07]

Thanks @tfmorris, appreciate the review.

@mekarpeles @hornc — would either of you (or another staff member) be the right person to look at the bot proposal + PR? Summary:

• Issue: Bot Account Application: AgenticCommonsBot #12887 (design, now updated per tfmorris's feedback)
• PR: Add AgenticCommonsBot for evidence-driven alternate_names additions openlibrary-bots#451 (standalone script)
• Scope: read-only crawl avoided — uses monthly dump + Wikidata Q-id anchor, adds all missing non-Latin labels per author in one edit

Happy to run a shadow window, share dry-run samples, or scope to a smaller pilot if that helps. Thanks!

[hornc]

@mekarpeles this is one for you; I have no authority to grant bot access, and do not understand how the bot repo is meant to function, other than as an archival record.

I note this bot has rapidly drifted from adding native-script names, which has a clear utility, to adding every and all non-Latin script names, with seemingly arbitrary conditions. From the brief glance I had at the code, seems to mean "John Smith" will potentially get alternate names in Aramaic, Syriac, and Rongorongo, but an name like '夏志清' gets nothing, not even a transliteration, because it is already 'Non-Latin'. I think this is another case of an LLM being too eager to please and making rapid changes taking us further away from the original value proposal, making it harder to review. Either way, it's for @mekarpeles

[WendyLee07]

Quick correction: there's no LLM driving label selection. Candidate selection is a streaming filter over the monthly OL dump; identity is anchored on the existing OL↔Wikidata Q-id; label choice is Unicode-block filter + NFC dedup. The script in #451 is ~200 lines of stdlib Python.

"Promiscuous" was the earlier suggestion in this thread to add all available forms once a Q-id is anchored. Happy to tighten — e.g. cap at top N languages by sitelink count so Aramaic/Rongorongo only land if there's actual Wikipedia presence.

Latin transliteration (夏志清 → Hsia Chih-tsing) is valuable but a separate scope; happy to follow up once this one lands.

Deferring to @mekarpeles on the access decision.

[tfmorris]

I agree with @hornc that this shouldn't be restricted to non-Latin labels, but a don't think a multitude of labels is a problem. The whole point of this is to improve findability, so any number of unique, valid, AKAs imported from Wikidata (where they are provided by interested human contributors) is an improvement.

While this won't technically provide transliterated labels using library Romanization tables for non-Latin scripts, it will provide something very close - human provided Latin script equivalents which will be recognizable to users. Library-official transliterations can be provided separately using something like the Library of Congress' ScriptShifter to help with deduplication, but the Wikidata labels will improve findability.

@WendyLee07 to be explicit, I suggest removing the Latin script filter and instead add all unique Wikidata labels (but note, as always, this is just my personal opinion, not OpenLibrary team feedback).

For @hornc 's example, the ten added AKAs from Wikidata primary labels would be:

C. T. Hsia
Chih-tsing Hsia
Hsia Chih-tsing
Zhiqing Xia
Ся Чжицин
夏志清 (unless it's the primary name in OpenLibrary)
Սիա Ճըցին
شیا، چی-تسینگ، ۱۹۲۱- ۲۰۱۳م.
هسيا كيه تسينج

the few AKAs listed in Wikidata are all already covered by the primary labels for the various languages.

The official LC romanization from ScriptShifter is Xia, Zhiqing which is, in this particular case, included in the list above, but that's not guaranteed since the library romanization rules don't always match common usage.

This strategy naturally excludes languages that people didn't care enough about to add a label for on Wikidata, while assuring findability for all the others, no matter what character set they use.

[WendyLee07]

Thanks @tfmorris and @hornc for the discussion.

The core question is where responsibility for correctness sits:

• Native-script only → the OL publisher must be able to personally vet what they publish; accountability stays on the publisher's side
• All Wikidata labels → accountability shifts upstream to Wikidata contributors; the publisher trusts their vetting rather than re-verifying

Both are defensible. Deferring to @mekarpeles / @hornc on which model OL wants.

In the meantime, I've paused alternate_name additions (currently manual entry under my personal account, not the bot) until there's a definitive answer.