softconf2aclpub: read author ORCIDs from .orc side files

[mjpost]

What

When converting from ACLPUB format, softconf2aclpub.py now reads the
ACLPUB .orc ORCID side files and attaches each author's ORCID to the
generated papers.yml.

This mirrors the .orc side-loading the ACL Anthology does in
bin/ingest.py.
Converting from ACLPUB format isn't necessary (the Anthology can ingest
ACLPUB directly), but some people do it anyway, and previously the
converted papers.yml dropped author ORCIDs.

.orc format

ACLPUB writes one .orc file next to each paper's .bib, with one entry
per author (1-based index, matching the paper's author order):

Author{1}{Orcid}:0000-0002-9659-1532
Author{2}{Orcid}:
Author{3}{Orcid}:0000-0001-2345-6789

Behavior

• ORCIDs are attached to authors by 1-based index; entries with an empty
  value are skipped.
• The value lands in the lowercase orcid author field (the same field
  the program-committee export and downstream ingestion already use).
• Side files are looked up per paper (by Submission ID) under, in order:
  cdrom/bib/, bib/, attachments/, and ..
• Fully backwards compatible: a no-op when no .orc file is present, so
  existing scrape-only workflows are unaffected.

Note for reviewers

The side-file lookup directories / key (Submission ID) are a best-effort
default; happy to adjust the search path or matching key to whatever
location your build places the .orc files in.

[crux82]

Thanks, this looks useful and the no-op behavior when no .orc file is present seems safe.

Before approving, I’d like to clarify two things:

1. Is orcid already the canonical author field used by the OpenReview conversion path as well, or would this make Softconf behave differently from OpenReview?

2. Is the expected .orc side-file location/name documented anywhere? The code searches cdrom/bib/, bib/, attachments/, and . using the Submission ID. If this is not already documented, could we add a short note to the README or the softconf/ documentation?

The code itself looks reasonable to me, but I think the expected input layout should be documented so users know how to make use of it.

[mjpost]

1. orcid is the openreview author field already used by aclpub2. This brings the Softconf/ACLPUB conversion into line with that practice.
2. The .orc side file is just Rich Gerber adding that for us. I'll add a note about documentation and push it up, soon.

[mjpost]

Actually, looking at this code in more detail, it doesn't work the way I expected. I assumed that the conversion happened offline after downloading full, completed proceedings from ACLPUB, but that does not appear to be the case.

[crux82]

Thanks, that makes sense. I’m wondering whether we should avoid making .orc side files part of the normal aclpub2 workflow, though.

For aclpub2, it seems cleaner to have papers.yml be the single canonical source of paper metadata, including author ORCIDs via the existing authors[].orcid field. The .orc files sound like a legacy ACLPUB/Anthology side-file mechanism. If we support them directly in softconf2aclpub.py, we may end up with two parallel sources of truth that can diverge.

Would it make more sense to treat .orc files only as an import/conversion aid, i.e. merge their contents into papers.yml, and then have the rest of aclpub2 rely only on papers.yml? If the .orc files are not normally present when softconf2aclpub.py runs, perhaps this should be a separate explicit conversion step rather than part of the default Softconf conversion path.

[nschneid]

Sounds reasonable to me. @mjpost?

[mjpost]

Would it make more sense to treat .orc files only as an import/conversion aid, i.e. merge their contents into papers.yml, and then have the rest of aclpub2 rely only on papers.yml? If the .orc files are not normally present when softconf2aclpub.py runs, perhaps this should be a separate explicit conversion step rather than part of the default Softconf conversion path.

Hi, I think this is what the script does? I am not adding .orc files: they are optionally present in the Softconf sources, and this script merges them in when creating the papers.yaml stream.

Ideally we would do away with this script entirely, since the Anthology supports direct ACLPUB ingestion. But if it is here, we'd like it to catch the ORCIC iD data that Softconf/ACLPUB now exports.

[crux82]

Thanks Matt, that clears it up — I'd missed that get_files() runs first, so the .orc data really is only an input while building papers.yml. No objection to the design.

Two small things I'd like to fix before merging:

1. An .orc can also end up as a paper attachment. get_papers() globs attachments/<Submission ID>_* with no extension filter, and find_orc_file() explicitly supports <Submission ID>_*.orc — so the file would be consumed for ORCIDs and listed as Supplementary Material:

for filename in glob(os.path.join("attachments", f"{row['Submission ID']}_*")):
    if filename.endswith(".orc"):
        continue

2. The 1-based index isn't aligned with the author list here. In the Anthology the index runs over bibentry.persons["author"], i.e. the same list ACLPUB wrote the .orc from. In get_papers() the list is filtered first (if row[f"{i}: Last Name"] != ""), so a blank interior author row shifts every following ORCID by one and silently assigns the wrong ORCID to the wrong person. Keying off the CSV column index keeps them in sync:

orcids = read_orc_file(find_orc_file(row["Submission ID"]))
for i in authors_i:
    if row[f"{i}: Last Name"] != "":
        author = {...}
        if orcids.get(i):
            author["orcid"] = orcids[i]
        authors.append(author)

Minor: cdrom/bib/ and bib/ can't match by Submission ID (ACLPUB names those by Anthology ID, cdrom/bib/$year.$venue-$volume.$pn.bib), so attachments/ is the only live path here. And re.fullmatch would match the Anthology implementation exactly.

With those plus the README note, good to go from my side.

Unrelated to this PR, but worth a separate issue: OpenReview profiles sometimes store ORCIDs as full URLs while .orc files use bare IDs, and neither path normalizes them.