Pin citation key and merge files in one folder but not others

Hi,

I am creating a "Master" folder with all the files from all the other folders. I would like all the files in the original folders to stay exactly the same, but I'd like to edit the Master folder so that there are no duplicates (which will involve merging/deleting files), and I'd like to define a BBT citation key for this folder only -- leaving the others unchanged.

The problem is when I unpin a citation key in the Master folder so that I can change it, it unpins across *all* the folders and automatically updates them (even without me "refreshing" the BBT citekey).

Is there a way around this? That is: can I have conflicting pinned keys in different key folders, and can I merge/delete duplicates in one folder without merging/deleting them everywhere? (I assume at least deleting should be possible).

Thank you!
  • I'm not 100% sure I follow all of this, but I'm pretty sure a lot of the issues stem from misunderstanding the relationship between Collections and Items in Zotero -- Collections do behave very differently from folders:
    https://www.zotero.org/support/collections_and_tags#the_zotero_collections_model
  • Hi @adamsmith thanks for the response! When I say "folder" I did mean collection.
    I want to create a Master collection that has all the items (let's call them papers) from all the other collections (let's call them Project collections). So within each Project collection, I select all the papers and right click to "Add to New Collection --> Master."

    Now in the Master, picture I have something like:
    "Paper 1 Title" citekey_paper1
    "Paper 1 Title" citekeypaper1
    "Paper 1 Title" cite_key_paper_1

    I basically want to only have one version of "Paper 1" in the Master, and I want to change the citekey of this single copy to be citekey_paper_1 (or whatever) *without* changing that citekey anywhere else, or without otherwise affecting the files in any of the Project collections.

    Does that make sense? Is it possible?
  • Right, I wasn't correcting your wording, I was pointing out what I think is a misunderstanding about how collections work (see the link), which is very different from folders:

    1. You already have a place that has all your papers: it's the root of "My Library"
    2. When you add an item to a collection, you are not actually duplicating the item -- you're assigning the very same item to multiple collections, which means that obviously the citekey is going to be changed everywhere: it's the same item your modifying.

    It's obviously possible to create duplicates of items and move them, but that's almost never a good idea.
  • edited September 23, 2022
    I'd say the answer to both is "no", sorry, not in the way you want. Collections have pointers to items -- wherever an item appears it is the exact same item, and the citekey attaches to the item, not to the pointer-to-the-item.

    That said, an item can actually sort of have multiple citekeys -- if you include tex.ids= key1, key2, key3 in the extra it will export these to the bib output, and you can refer to the entry by any of these keys if you use biblatex. But they can't be collection-specific. It's just not how Zotero works.
  • Thank you for both of your responses! @emilianoeheyns, would I have to manually define each of these keys? Like starting from

    "Paper 1 Title" citekey_paper1
    "Paper 1 Title" citekeypaper1
    "Paper 1 Title" cite_key_paper_1

    Would I e.g. copy cite_key_paper_1 citekeypaper1 into the extra field of the first instance, and then merge the three?
  • Also I notice that when I'm within a collection and I "duplicate" an item, it can generate a new entry with a different citekey without affecting the previous version.

    So I have Paper2
    "Paper 2 title" citekeypaper2 --> duplicate
    "Paper 2 title" citekey_paper2

    Is there a way for me to do this duplication for all files within a collection, and then move these duplicates (i.e., do what @adamsmith said was almost never a good idea)?
  • I don't think so, no -- item duplication is only available individually.

    Could you maybe step back and describe what problem you're trying to solve (or goal to achieve) rather than what specifically you're trying to do in Zotero?
    It seems unlikely that there wouldn't be a better way to do this than creating hundreds of duplicate items that need to be managed individually, cause confusion in citations, etc.
  • edited September 23, 2022
    would I have to manually define each of these keys?
    BBT adds the tex.ids= line with the merged key automatically when you merge items (although you can turn that off if you don't want it).
    Also I notice that when I'm within a collection and I "duplicate" an item, it can generate a new entry with a different citekey without affecting the previous version.
    Just so we have this clear -- you don't duplicate an item "in a collection". You duplicate an item, full stop, and it is then also added to the collection you were in when you did that. But if you go to the top-level, you will see the duplicate there.

    From Zotero's (and therefore BBT's) point of view, there are no versions, and you simply created a new item and efficiently populated its fields using the data of the item you chose to duplicate, but it is entirely the same as doing this by hand (create a new item and retype the data) as far as Zotero is concerned. So a new item appears by any of these means, and BBT assigns this new item a citekey. The "previous" version is just one of many items in your library at that point, and it is unaffected by the new entry just like all others are unaffected.
    So I have Paper2
    "Paper 2 title" citekeypaper2 --> duplicate
    It just got that key because it was the first available key given the items data + the formula you use.
    Is there a way for me to do this duplication for all files within a collection, and then move these duplicates
    The collections (plural) an item appears in has no effect on its generated citekey, but if your question is "can I select multiple items, duplicate all of them in one go, and then remove these duplicates from the current collection and add them to another" (which has no bearing on BBT), the answer is "not through the Zotero GUI, no, although a bit of javascript in the developer screen could do it".

    edit: but very much what adamsmith said; it'd be better to explain the problem you're trying to solve rather than the means by which you have attempted to solve it.
  • Thank you for all of your help!

    There are two goals:
    (1) if I am writing paper in LaTeX in which I already used a citekey , I don't want this citekey to change.
    (2) I want a "clean" version of all the works I have ever referenced -- without duplicates and with the citekeys in a different format.

    One way of doing this that I'm experimenting with now is exporting and re-importing a collection. So I have that "Master" collection where I basically have all the items in my library. Now if I export this and then import it again, the files should be "new" items, which means that I can now merge duplicates and then define a new citekey format, which shouldn't affect anything in my other collections.
  • without duplicates and with the citekeys in a different format
    You mean those citekeys should or should not be different?
  • Potentially different than what they were in the original collection.

    For example, imagine that (for example, a coauthor) used the citekey "banana." for a paper.

    Now in my clean collection, I actually want the citekey to be author1_author2_YYYY

    The issue I'm facing with my import/export now is that say in the original collection, the paper was already called author1_author2_year, then in my exported-imported collection, BBT calls it author1_author2_YYYYa. I have the option "key keys unique" set to "within each library" but I guess that is different from "within each collection."
  • Sorry to clarify -- I think the "a" thing probably happens because when I re-import, there are multiple versions of the same paper that I then merge.

    But say I have merged the files and I change the format from author1_author2_YYYY to just author1_YYYY, and then refresh the BBT key, the "a" goes away. But when I change it back to author1_author2_YYYY, it comes back. I don't understand why this would be the case.
  • edited September 23, 2022
    I get that you don't want changing citekeys to break existing/old papers, but for that I'd recommend just turning on autoPinDelay (which is a behavior that will likely become the default when Zotero gets formal support for citekeys) and just use that one, pinned key everywhere.
  • How would that get around not breaking the existing papers? (The reason why there are so many citekeys in the first place is because the folders were copied from co-authors' libraries).
  • I'd consider working with groups for existing projects then.
    Groups are (for all practical purposes) independent libraries, so you could have one group "Old projects" for existing papers, which include existing citekeys, and then you copy all items into "My Library" where you auto-generate & pin the citekeys for you desired format.
    Conveniently, dragging items between libraries (i.e. between a group and My Library) will actually copy them, as you want to.
  • For example, imagine that (for example, a coauthor) used the citekey "banana." for a paper.

    Now in my clean collection, I actually want the citekey to be author1_author2_YYYY
    Add this to your extra field:


    tex.ids = banana.
    Citation Key: author1_author2_YYYY
    Sorry to clarify -- I think the "a" thing probably happens because when I re-import, there are multiple versions of the same paper that I then merge.
    That is correct. I'd advice against this import/export workflow.
    But say I have merged the files and I change the format from author1_author2_YYYY to just author1_YYYY, and then refresh the BBT key, the "a" goes away. But when I change it back to author1_author2_YYYY, it comes back. I don't understand why this would be the case.
    Likely because an item with the key author1_author2_YYYY exists in your library.

    If you want to dive deeper into this key generation question, we'll have to take it to github. But right now, just keeping "old" citekeys in an tex.ids= line in extra seems like a clean way to solve your problems.

    Or indeed use separate groups.
  • Thank you to both of you! One last question: If I go with the option of keeping old citekeys in the line in , is there an efficient way to accomplish this, considering that I probably have several thousand papers (because of all the duplicates)?
  • Pin the one whose key you want to keep, select the others, select "merge", and make sure you use the first article as the merge master item; all the non-master-items keys will go to the tex.ids= line.
Sign In or Register to comment.