Closed moewew closed 3 years ago
Yes, I think this entry shouldn't really be inproceedings
and inproceedings
should be fixed as you say. However, I'm not sure what entrytype applies here as conference
is just a legacy alias to inproceedings
. I can only really see that unpublished
applies but this is too much of a catch-all for such structured entries?
We added conference data fields to @unpublished
a while ago in the standard data model (https://github.com/plk/biblatex/issues/687), so this would have been my first thought. But in principle I share your concerns that @unpublished
feels a bit meh here.
You could define a new type @conferencetalk
/@conferencepresentation
/@conferencesession
/@conferencecontribution
. It's a pity that @conference
is taken.
I have introduced a PRESENTATION
entrytype and moved all PROCEEDINGS
/INPROCEEDINGS
to this is as they made little sense as they were. This frees up INPROCEEDINGS
to include pages and remove duplicate editors.
Sounds like a good plan. I was wondering about the @proceedings
entries as well: They didn't really fit the description of what @proceedings
should be.
Consider
Note the duplicate editor and the absence of a
pages
field. The only@inproceedings
inbiblatex-apa-test-references.bib
ishttps://github.com/plk/biblatex-apa/blob/07224ffe6705c2b9d1d093ff560e1ea8e3bef382/bibtex/bib/biblatex-apa-test-references.bib#L1501-L1517
which has no
pages
and appears to be the entry for a session rather than a normal conference paper.I presume the idea for conference papers that were published in a proceedings volume is that once can use
@incollection
instead, but that would have serious backwards compatibility implications for people who build their.bib
files according to thebiblatex
standard data model.