Zenodo translator turns software into report
Hello!
When I browse to https://zenodo.org/record/580337 my browser switches the Zotero icon to software/code, but upon importing, the item becomes a report.
Despite Software, while neither "article", nor "preprint", nor "report" appear in the source of that page, which might effect this behaviour, according to https://github.com/zotero/translators/blob/master/Zenodo.js.
Zotero 5.0.34.5
Firefox 52.6.0
Chrome 63.0.3239.132
Is this happening to other people as well? What could be the reason? Thanks for any hints!
When I browse to https://zenodo.org/record/580337 my browser switches the Zotero icon to software/code, but upon importing, the item becomes a report.
Despite Software, while neither "article", nor "preprint", nor "report" appear in the source of that page, which might effect this behaviour, according to https://github.com/zotero/translators/blob/master/Zenodo.js.
Zotero 5.0.34.5
Firefox 52.6.0
Chrome 63.0.3239.132
Is this happening to other people as well? What could be the reason? Thanks for any hints!
I think the easiest way to fix this would be to re-set the item type using the detectWeb function, i.e. something like
item.itemType = detectWeb (doc, url)
(untested)Do you mean that the time is ripe for a PR to change this behaviour? Or that I should apply it to my fork? I would be interested in the latter, but would rather inquire about the reasons for the original suggestion?
I have incomplete understanding of this situation, but I can't help thinking that maybe stopping to use work-arounds (even while downstream support (CSL) is lacking!) would help to resolve such chicken-or-egg-type conundrums?
Not quite sure I understand the workaround part -- are you just saying we should fix this in the Zotero translator (agreed) or something else?
I'll try to update the translator. Maybe only in March, because the first free slot in my schedule occurs then.
Having dealt with having to make compromises around "most common" practices based in BibTeX for many years now, I'll fight tooth and nail to keep CSL and its input standardized to avoid that.
I've asked the Zenodo colleagues in https://github.com/zenodo/zenodo/issues/1428 about this as well.
What I disagree with is the idea to do that by taking a standardized metadata format (and while CSL JSON isn't formally specified, it follows the CSL specifications which are) and basically inventing new types in it.
I think that's bad practice with potentially very bad outcomes. For example, we haven't made the final call on how the software item type will be called in CSL. Say Zenodo now goes ahead and calls this software and then we end up calling it computer_program -- we then have a massive amount of incorrect metadata out in the wild that we have to deal with. That's how standards fall apart. I know it can be frustrating that standards take time to adjust to new requirements. They're still preferable to metadata anarchy.
Both bibtex and CSL is used by many different tools and styles. The expectation that they all gracefully handle unexpected input isn't warranted -- we don't require it for CSL and it's definitely not the case for bibtex.
I care somewhat less about what ends up happening with bibtex because it's already broken, but please don't suggest that people start customizing CSL JSON.
Regarding Bib(La)TeX & biber, my impression until now (own tests and asking around) was that they _do_ gracefully fall back to `@misc`. This "definitely not the case" is the first time I hear of potential problems.
https://github.com/zotero/translators/pull/1578