New author system

[mjpost]

I am opening this draft PR to produce a build in service of wrapping up the new author representation. Discussion here can largely continue from #5471.

List of TODO items

UI changes:

• New author system UI changes #6824

The following are important tasks, but need not block merging:

• Modify the ingestion script to use the library and match ORCID iDs on ingested papers (cf. Missing functionality for modifying and ingesting data with Python lib #4766 )
• Add tooling to show people how to become verified
• Fix bulk metadata script to use library

Administrative tasks:

• Make sure submitting conferences use ORCID iDs on all papers (or as many as possible) (cf. Outreach to data providers to require ORCIDs #7048

[mjpost]

I'm about to be offline for the day, but have pushed a number of fixes to [Edit: #6895]. It would be very helpful to have all these catalogued, but you'll want to cross-ref this against the fixes I've done. Sorry, I should have been more systematic with that.

Here's another super-ambiguous one: https://aclanthology.org/P19-1140/. "Zhiyuan Li" appears to be a popular name.

[nschneid]

I'm about to be offline for the day, but have pushed a number of fixes to #6819.

You mean #6895 right? Yeah I can use that as a starting point. Unless it's easy to merge those into here so the number of errors in the build is reduced.

[mjpost]

Also let's just commit changes directly in #6895? Instead of doing separate metadata changes? About to push one more then I'm off.

[mbollmann]

I hear your concern, but in the interest of bringing this milestone to a close, I would argue that we simply throw a warning, and attempt to fix this afterwards, perhaps returning to an error down the road.

Updated & pushed.

[weissenh]

What do we do after the transition with metadata correction issues opened before the transition? Those which ask for changes concerning authors may use old ids that are no longer valid or have been appointed to someone else (e.g. catch-all ids for ambiguous names may then point to a specific person with ORCID info)
I've rarely seen it, but in principle one can edit the JSON block in the issue to mention a different id than the current one at submission time.

Ideally, there should be only a few still open metadata corrections before we merge into master. For any "old" metadata correction we approve after the transition, we have to be careful regarding assignment of authors to ids.

I know the bulk processing script needs to be adapted to the new library (and fix the reordering bug on the way).

[mjpost]

What do we do after the transition with metadata correction issues opened before the transition? Those which ask for changes concerning authors may use old ids that are no longer valid or have been appointed to someone else (e.g. catch-all ids for ambiguous names may then point to a specific person with ORCID info)

I see three options:

1. Try to get them all done prior to the transition
2. Close them all, with a request to resubmit
3. Take special care in handling them post-transition

(1) seems hard, and there is also a race condition. (2) seems like a lot of work. I suggest we go with (3).

To handle (3), we basically will know which are old and which are new, based on the transition date. The script will just take care not to trust IDs prior to that date. (The script should be setup to be wary of IDs, anyway, since they are user-editable, as you note).

[nschneid]

Would it be a good idea to make a post/reach out to stakeholders (ARR, EACL 2026) warning them that the author transition is coming? E.g.:

In the coming days, we will update our database to make core technical changes that will improve our ability to maintain high-quality author pages. We thank authors who have submitted corrections for their patience during this process.

The user-facing changes at this time will be minor; the upgrade is not expected to require any downtime or break existing URLs. Users may notice that /unverified will appear in URLs for author pages that are constructed based on the name string alone, without any verification that they represent unique individuals. We are moving toward adding ORCIDs to better identify unique authors, and will be working with upcoming venues to encourage submitting authors to include ORCIDs in their profiles so they are attached to papers received by the Anthology.

We are sure about no URLs breaking, right? Any current unverified author page will be forwarded to /unverified? (This matters for the current ARR cycle which uses author page in its processes.)

[mbollmann]

We are sure about no URLs breaking, right?

I could run another systematic comparison (build under old + new system and run a script to compare which pages are being generated) before we switch. Can't hurt to be too careful IMO.

Any current unverified author page will be forwarded to /unverified?

Unless there’s a bug here that I haven’t caught, yes:

acl-anthology/hugo/static/.htaccess

Lines 84 to 87 in 4fc9af2

	# If the requested author page does not exist, soft-redirect [303 See Other] to the /unverified URL
	RewriteCond %{REQUEST_FILENAME}/index.html !-f
	RewriteCond %{REQUEST_FILENAME}/unverified -d
	RewriteRule ^people/([^/]+)/?$ people/$1/unverified [L,R=303]

[nschneid]

Would it be a good idea to make a post/reach out to stakeholders (ARR, EACL 2026) warning them that the author transition is coming? E.g.:

In the coming days, we will update our database to make core technical changes that will improve our ability to maintain high-quality author pages. We thank authors who have submitted corrections for their patience during this process.

The user-facing changes at this time will be minor; the upgrade is not expected to require any downtime or break existing URLs. Users may notice that /unverified will appear in URLs for author pages that are constructed based on the name string alone, without any verification that they represent unique individuals. We are moving toward adding ORCIDs to better identify unique authors, and will be working with upcoming venues to encourage submitting authors to include ORCIDs in their profiles so they are attached to papers received by the Anthology.

@mjpost thoughts on an advance announcement? It seems like a good way to address the fact that there are a lot of open correction issues, i.e. we are busy on important work and will get to those soon. :)

[mjpost]

Yes, we definitely need to do this. My thinking is:

1. Complete New author system UI changes #6824
2. Set date for merging New author system #6807 (can we do early next week?)
3. Write blog post describing the new system and the ORCID iD aspirations
4. Reach out to many chairs point them to the blog post

[nschneid]

https://preview.aclanthology.org/master-new-author-system-ui/people/yang-liu/unverified/:

https://preview.aclanthology.org/master-new-author-system-ui/people/yang-janet-liu/:

Where are the Chinese characters coming from? I thought unverified = no entry in our database, so how would we be able to disambiguate the Chinese spelling of the name? Is this a bug in the API?

[nschneid]

^ It seems that if a Person instances has multiple entries returned by names, and one of them is in a different script, it gets displayed in parentheses. My question is why/whether an unverified person should ever have variant names across scripts.

[mbollmann]

Variants in foreign script can be recorded directly in the XML. EDIT: ...and if that author doesn't have an explicit ID, they're of course unverified.

[nschneid]

Ah. So my concern is, for the unverified Yang Liu page, 扬 刘 is but one possible Chinese variant of the name. Maybe it was the only one that happened to be present in an XML file where Yang Liu was unverified. But it seems misleading to show it in parentheses as if it represents ALL the unverified Yang Lius—some (presumably most) of whom didn't have a script variant in the XML.

I don't know if this is a representation problem in the library, or if the page should just not show the alternate script variant on unverified authors. Maybe this logic should be modified to check verification:

acl-anthology/bin/create_hugo_data.py

Lines 387 to 396 in efd9fde

	data["variant_entries"] = []
	diff_script_variants = []
	for n in person.names[1:]:
	data["variant_entries"].append(
	{"first": n.first, "last": n.last, "full": n.as_full()}
	)
	if n.script is not None:
	diff_script_variants.append(n.as_full())
	if diff_script_variants:
	data["full"] = f"{data['full']} ({', '.join(diff_script_variants)})"

[mbollmann]

I don't see how this would be a representation problem in the library; the author tag with the name variant needs to be resolved to an ID, and that can be an unverified one. Still, the Han name variant belongs to that author ID, so it will be returned as one of the possible names for this unverified person. That does appear perfectly correct to me.

[nschneid]

If we were being really nitpicky we might distinguish script variants that occur with all instances of an unverified author from ones that occur only some of the time (because there can always be multiple people under the same unverified author and their names can have different script variants). But this feels like overkill, and I was able to implement a front-end change in #6824 that removes this source of confusion.

[mbollmann]

If we were being really really nitpicky I would say different-script name variants don't really belong on the paper level at all, but instead could trigger/require a verified ID assignment so that the variant can be stored at the author level. :)