include volumes-without-frontmatter on people pages - #8008
Conversation
|
Build successful. Some useful links:
This preview will be removed when the branch is merged. |
|
Volumes-lacking-frontmatter are now included in the list of "papers" to display. Now https://preview.aclanthology.org/show-vols-without-frontmatter/people/zeerak-talat/unverified/ shows the year, indicating there is a volume to render, but the volume does not show up—perhaps because there is no |
| # + volumes with no frontmatter | ||
| chain( | ||
| person.papers(), | ||
| filter(lambda vol: vol.frontmatter is None, person.volumes()), |
There was a problem hiding this comment.
| which the YAML exporter should take care of */}} | ||
| {{ $paper := index (index $.Site.Data.papers (index (split . "-") 0)) . }} | ||
| {{ $paper := "" }} | ||
| {{ if findRE `\.\d+$` . }} |
There was a problem hiding this comment.
Oof, I really dislike this. That also only works for new-style IDs, not old ones, right?
There was a problem hiding this comment.
Giving this more thought, I think adding volumes to a list called "papers" is hacky and probably not the right solution, for exactly these reasons (needing hacky ID checks to differentiate them again later, and also requiring two different kinds of templates to render them).
Idea for a better solution: Add has_frontmatter to what gets exported by volume_to_dict() in create_hugo_data.py and check for this in the Hugo template to conditionally render volumes. Still needs them to have their own list-entry-author template or something similar, though.
There was a problem hiding this comment.
Yeah that seems workable:
- Add all volumes to
papers(so really it is a list of items associated with the person) - In the template, skip rendering ones where
has_frontmatteris true - We still need to know whether each item is a paper or volume to know which exported YAML to use for lookup. I agree the ID format check is not a great way to do it. Maybe look up the full ID as a volume first, and if no match, assume it is a paper?
- We also need to construct the URL (
page) differently depending on whether it is a paper or volume. - And we need a volumes/list-entry-editor.html template
That’s likely the reason, and no, I think there isn’t. I believe that, if volumes should (conditionally) appear on author pages, we should rethink how this rendering works on the Hugo side in the same way that I propose for the library in #8000. We already have a PR that tries to add talks, and we shouldn’t have to invent new mechanisms like this for every type of item we might want to display. |
|
Before going further with this, I feel like I should ask: would it be possible to require all volumes to have frontmatter, even if there is no PDF for it? Advantages:
In the XML frontmatter looks like: <frontmatter>
<url hash="1c02f868">2024.woah-1.0</url>
<bibkey>woah-2024-online</bibkey>
</frontmatter>In the schema it looks like only the bibkey is required: acl-anthology/python/acl_anthology/data/schema.rnc Lines 113 to 121 in 07ecf93 I'm not familiar with the ingestion code. Would it be simple to generate a |
I probably wouldn’t go that way, because:
If we’re thinking to go that way I’d rather have the library instantiate a frontmatter always (without modifying the XML needlessly), but problem 2. doesn’t go away from that, and there’s also a functional difference in that people are considered “authors” on frontmatter but “editors” on volumes. I might need to think about this a bit more, frontmatter handling is a bit of a mess. |
|
As a site user, I still think it could be useful to have a page where I can get the BibTeX for citing the volume. That is accomplished on the frontmatter page. E.g. compare |
|
That is actually another inconsistency in how we handle frontmatter, I would argue, as they really shouldn't have the volume BibTeX. |
|
In that case, why do we need a separate page for frontmatter at all? Why not just link to the frontmatter PDF on the volume page, below the full PDF button, and include the citation info on the volume page? |
|
That would make sense if they should have the same citation info as the volume. I was wondering whether they shouldn't, because they’re not the same thing. |
|
I can think of one time that I cited a front matter page (e.g. vii) in reference to a panel that was held at the conference and was not listed elsewhere in the proceedings. But I don't know if there is a use case for citing the frontmatter as a unit. |
|
Discussed with @mjpost today. He couldn't think of a reason to keep separate pages for the volume and the frontmatter. |
|
What would that mean for the frontmatter’s Anthology ID? There would be no page more corresponding to it. Would it just redirect to the volume page? |
|
Yeah, redirect |
2 participants
closes #7973