I want to continue to add bibliography entries into a bibtex database and periodically import into zotero. The problem is duplicate entries go into the library.
isn't it really easy to just sort the .bib by creation date and only export new entries?
In general duplicate detection is planned, but otherwise I'm not sure how you even expect this to work logistically.
Given that the direction in which you're using Zotero is very unusual (since getting data into Zotero is, for most users, it's key advantage over, say, jabref) I don't think a solution specific to this issue is likely to happen.
When the import function is enabled, data appears both in a child directory (with a default name of the time, date of import) of the library and in the (parent) library directory itself.
It would be better if imported items remained only in a child directory and the user could have the option to transfer data to the main library directory either manually or automatically.
Preferred import behaviour:
Select bibtex file to import
bib file imported to a child directory
contents of library directory deleted
imported bib file contents transferred to library directory
This type of sequence would be analogous to typical use of a file manager (e.g. nautilus).
The could be an import configuration setting to either import automatically files directly to the library directory, or import manually as described above.
The option to sort the bib file by creation date is not feasible because the bib file is a single text file, so it would not be possible to rearrange text in order of creation date.
Current behavior is meant to mimic, e.g. iTunes such that all items are members of your library & items can (but aren't required to be) part of one or more collection. There are many threads discussing this design choice. You could sort Zotero items by creation date, to easily get what you're hoping to accomplish. Or you could delete items before the import. (Note that this strategy is not advised if you are editing items, drawing them from non-BibTeX sources, using the word processor plugins, etc.)
It seems that if items in the library are deleted and the new bibtex import contains copies of the items, a document which was created with (deleted) items shows a dialogue window stating that references are lost. The references then need to be re-entered into the document.
Note that this strategy is not advised if you are....using the word processor plugins
I guess I don't see the logic in
The option to sort the bib file by creation date is not feasible because the bib file is a single text file
If the BibTeX file is created manually, you can append entries to the bottom (so that it is sorted. Some BibTeX-producing reference managers can output the date entries were added, If the BibTeX is, e.g. alphabetically sorted, just take a diff.
So article Y would be added after article X. No particular reason, but the bibtex file was organised by entry type (probably following the descriptions by Patashnik in 'bibtexing').
Also realised that it is possible to copy a bibtex item to the clipboard which is then imported directly into zotero.
So perhaps the best way for bibtex users is to make one first import into zotero; make new bibtex entries in the original bibtex file using a favoured text editor; copy each new bibtex entry directly into zotero using the copy-clipboard
FWIW: I'm a BibTeX user. I import into Zotero first (because adding references is so easy). When I'm writing a paper, I'll export most of the references I think I'll use into a BibTeX file. As I write, I'll either regenerate the file from scratch if there is a lot to change (as LyZ/Lytero/etc. probably do, but I don't use them) or will quick-copy individual references out of Zotero into my BibTeX file.
(I have some additional management via refbase, JabRef, and a few other tools, but I'm just pointing out that a Zotero-centric workflow is perfectly possible for BibTeX users.)
(probably following the descriptions by Patashnik in 'bibtexing').
And, for the clarity of others reading this thread, there are no recommendations made for .bib database organization. Some other tools will sort by type or allow you to sort by type, but it is neither a recommendation or requirement that one do this (if anything, sorting on cite-key is arguably more useful).
Upgrade Storage
In general duplicate detection is planned, but otherwise I'm not sure how you even expect this to work logistically.
Given that the direction in which you're using Zotero is very unusual (since getting data into Zotero is, for most users, it's key advantage over, say, jabref) I don't think a solution specific to this issue is likely to happen.
It would be better if imported items remained only in a child directory and the user could have the option to transfer data to the main library directory either manually or automatically.
Preferred import behaviour:
Select bibtex file to import
bib file imported to a child directory
contents of library directory deleted
imported bib file contents transferred to library directory
This type of sequence would be analogous to typical use of a file manager (e.g. nautilus).
The could be an import configuration setting to either import automatically files directly to the library directory, or import manually as described above.
The option to sort the bib file by creation date is not feasible because the bib file is a single text file, so it would not be possible to rearrange text in order of creation date.
@articlex,
abstract=...
@bookx
author=...
So article Y would be added after article X. No particular reason, but the bibtex file was organised by entry type (probably following the descriptions by Patashnik in 'bibtexing').
So perhaps the best way for bibtex users is to make one first import into zotero; make new bibtex entries in the original bibtex file using a favoured text editor; copy each new bibtex entry directly into zotero using the copy-clipboard
(I have some additional management via refbase, JabRef, and a few other tools, but I'm just pointing out that a Zotero-centric workflow is perfectly possible for BibTeX users.)