Library question: propagating author ID explicitly to all items on author page

[nschneid]

I see that make_explicit(new_id) and merge_with_explicit(person) do this by calling

acl-anthology/python/acl_anthology/people/person.py

Lines 284 to 285 in 0bf14b5

	def _set_id_on_items(self, new_id: str) -> None:
	"""Set `new_id` on all name specifications that currently resolve to this person. Intended for internal use."""

Can I call person._set_id_on_items(person.id) directly to update just the XML for an already verified author? It doesn't seem to be working. @mbollmann

[mbollmann]

No, that doesn’t currently work like that (and there's a reason it's an underscore method...). This may be a functional gap in the library right now, batch-assigning IDs to papers that have been implicitly assigned to a verified author is not something I have considered.

[nschneid]

I finally found a way but it was not super intuitive...maybe would benefit from a library method:

log.info(f'Ensuring author ID {person.id} is explicit on all papers/volumes')
candidate_namespecs = [(ns,paper) for paper in person.papers() for ns in paper.authors]
candidate_namespecs += [(ns,volume) for volume in person.volumes() for ns in volume.editors]
for (namespec,item) in candidate_namespecs:
    if anthology.resolve(namespec) is person:
        if namespec.id:
            assert namespec.id == person.id
        else:
            namespec.id = person.id
            item.collection.is_modified = True

[mbollmann]

Yeah, identifying the right namespec is a pain. I guess a better API would be:

for paper in person.papers():
    namespec = paper.get_namespec_for_person(person)
    namespec.id = person.id

Or maybe even:

for paper, namespec in person.papers_with_namespecs():
    ...

[nschneid]

Also as a user I was surprised to have to set is_modified

[mbollmann]

NameSpecs don't track their parent so they can't "notify" them of a modification. That is mainly because we instantiate so ridiculously many of them that I wanted to avoid the extra reference. But probably, modifying NameSpecs is one of the main types of modification we do, so it might be worth it. I should profile how much overhead this actually causes.

[mbollmann]

If NameSpecs tracked their parent, another benefit would be that we could do namespec.resolve() instead of the clunkier anthology.resolve(namespec).