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.
Has this problem been solved now? I got two tough questions in a row today: One is the frequent error “This document contains EndNote citations. Please convert them before using Paperpilefor Word.” But I’ve never actually used endnotes; The other problem is this. All my changes to the citation are automatically restored. I just broke down and cried. Looking forward to your reply, apart from these two questions, I really like paperpile.
@Luna_Qi has the document been revised / edited by anyone else who could’ve added a citation using EndNote? In any case, you can check by displaying the hidden field codes (which all in-text citations contain) by hitting Alt+F9 on Windows (or Option+F9 on Mac) and searching the term EN.CITE. If found, remove the whole field as shown in the screenshot below and switch back to the normal view using Alt+F9 again.
Let me know if that works. Otherwise, if possible please share the document with us via chat or email for the team to review (even if just a copy with most of the text removed – we just need to see the citation codes).
As for the changes to the citations, could you please specify whether you hit the auto-update option (Shift+A) from the library as mentioned above on this thread? Let me know.
locking metadata would be useful since sometimes the auto-updated metadata is incorrect. As a part of this, having a better system for reporting incorrect auto-updated metadata would be beneficial. I proposed such a feature here: Button to Report Inaccurate Auto-Updated Metadata - Feature Request