1

I am working on several .bib databases, like first.bib, second.bib, third.bib, etc.

Among these bib files, same key existed for different records, like an author wrote two papers within one year, and the keys generated for them are same, let's say authorname2018, but actually there are different papers.

The setting in preference can only solve the issue within one .bib file, enter image description here

so my question is how to generate different keys among multiple .bib files when importing records, without merging these .bib files into one .bib file?

  • On what level do you want to generate different keys? Do you want to configure JabRef to make sure that there are no duplicate keys across several files? Do you want to merge the .bib files into one large .bib file and want to avoid duplicates there? Or do you want your duplicates to be handled on the BibTeX/Biber side (I think that is not possible). – moewe Mar 30 at 17:28
  • Sorry for confusion. I want to have unique keys among multiple .bib files. I don't want to merge these multiple .bib files. In current situation, I have same keys for different records within these .bib files. I hope jabref can automatically generate different keys in the future when I import new records. Hope my question is clear now. – Sam Mar 30 at 17:43
  • 2
    JabRef is able to generate keys on import, but obviously only per bib file. Each bib file is a unique library. Libraries are independent of each other. It's not possible to have this among multiple libraries – Christoph S Mar 30 at 20:38
  • Since the question is about JabRef and general .bib files and not the specific packages natbib and biblatex I have removed those tags. I guess it is not surprising that the function you are looking for is not yet implemented as usually .bib files are kept independent of each other. – moewe Mar 30 at 20:57
1

The solution is quite obvious: As the default pattern [auth][year] of the BibTeX key generator could be duplicated in any other file, but JabRef have no way to check that, the ball is in your court: You must provide another pattern, ensuring that will produce always unique keys. For instance:

  • [auth][year][firstpage] or if this is not enough ...

  • [authorIni][year][firstpage]. This one use the first 5 characters of the first author’s last name, and the last name initials of the remaining authors. But if this is not enough (!) add also a [shorttitle] or the [keyword3]. See the help of the program. There are more options...

But if you already used [auth][year] it could be hard check how each key have changed. And long keys are hard to remember. So another approach is construct the key based in the database, for example using [auth][year]F for first.bib, [auth][year]S for second.bib, and so on. Then you can predict exactly how the keys have changed. And it is still a handy key.

As far as I know, the pattern preferences are global for all databases, i.e., you cannot store a particular pattern for a particular database, but as you can re-generate all the keys in a second, whenever you want, change the preferences seem a very insignificant issue.

And well, ... another option is merge the files. You do not like that but IHMO the best option, as generate the same simple and unique [auth][year] keys for all the references. And you can have still the source identified as keyword, for instance.

It is worth to note that biblatex can print subsets of cited references based in a keyword, so this is not a good reason to split a database.

JabRef could also work with these subsets easily, simply with a search of something as keywords=SecondFile, so why split it?

But if you want split it anyway, once selected the references in JabRef (with this search or in any other way), is as simple as Export selected entries option of the File menu., so merge the databases should not be a problem. Just make a backup and test it! ;)

  • Great explanation of the philosophy underpinning Jabref, and I will not split .bib for one project any more. – Sam Apr 1 at 4:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.