It happens that Scholar and Paperpile have the wrong metadata for an article. After custom editing of the fields, it would be nice if they could be locked so that auto-update doesn’t change it back to the faulty state.
In the same vein, is it possible to register a corrected bibtex with Paperpile in an effort to crowdsource improved metadata?
1 Like
Locking fields may defeat the purpose of running an auto-update and lead to some frustration, but we are interested in hearing whether making additional edits after an auto-update is a common experience.
W.r.t. crowd-sourced metadata - this is not something we are currently planning, for a number of reasons (see this thread). Mendeley has been doing this and the result is, in my opinion, a mess.
Maybe auto-update should verify with the user whether it wants to update an entry that has manually edited fields? I’m thinking of the use case where a lot of the references are marked for auto-update in a batch. I guess the work-around is to de-select every element known to be hand-curated, but this seems prone to error. The issue is that hand-curation of a reference takes a while, so it is a bit of a loss if that work is overwritten without any way to restore it or preempt it.
I can see how crowd-sourced versions of the metadata might go the wrong way, but a halfway solution might be to let users see different bibtex options sourced from the canonical sources and from other users, and then pick their favorite? Scholar already lists multiple versions of papers, often with unique bibtex files (most of them rubbish, supporting your argument about crowdsourcing…)
Speaking for myself, I have more than once had to edit an entry after doing an auto-update, because sometimes the auto-updated data values are wrong in some way. (Often it’s the reference type, but sometimes it’s a typo or truncated journal name or something.)
What if there was a box you could check within the “Edit Details” window that would lock the metadata and exclude it from auto-updating even if it was accidentally included in a batch update? That way users would have to actually choose the option and it wouldn’t automatically go into effect if one of the fields was manually updated. Auto-update is only useful if it improves the metadata, and it doesn’t always do that.