Importing Endnote notes field
I have tried importing my endnote library into zotero using bibTex as the output style from Endnote, as instructed by the zotero documentation.
However, my endnote 'Notes' field ends up as the zotero 'Extra' field rather than as a Zotero note.
I balk at the thought of having to go through all 1000 imported entries and manually copying any notes from the 'extra' field to a zotero note.
By the way, I am using Endnote 8.
Any suggestions on how I can get round this, or comments on success/failure of importing the notes field from other versions of endnote would be much appreciated.
However, my endnote 'Notes' field ends up as the zotero 'Extra' field rather than as a Zotero note.
I balk at the thought of having to go through all 1000 imported entries and manually copying any notes from the 'extra' field to a zotero note.
By the way, I am using Endnote 8.
Any suggestions on how I can get round this, or comments on success/failure of importing the notes field from other versions of endnote would be much appreciated.
comment = {test note
}
You can probably fix the whole file with one or two careful find and replaces.
Otherwise, try RIS.
I tried RIS as well. This correctly added my endnote notes to my zotero notes. But it also resulted in various endnote fields undesirably turning up as extra zotero notes. I figured out I could avoid this by deleting various N1 entries from the endnote RIS export style.
Is there a way for the user to find out which endnote fields are being mapped to which zotero fields for BibTeX & RIS imports ?
Actually, I meant to ask is there a way for the user to find out which BibTex & RIS fields are being mapped to which zotero fields?"
The RIS specification allows for the use of carriage returns/line feeds to shorten the line length of field data.
How do you differentiate between a deliberate carriage return and one that is only being used in this fashion? Perhaps by using two returns in the former case?
Here's the relevant bit from our current RIS translator, which seems to suggests that we're considering newlines in notes as explicit newlines:
// otherwise, assume this is data from the previous line continued
if(tag == "N1" || tag == "N2" || tag == "AB" || tag == "KW") {
// preserve line endings for N1/N2/AB fields, for EndNote
// compatibility
data += "\n"+rawLine;
}
If someone wants to send a sample (single) RIS entry generated from EndNote® to support@zot....org, I'll check this.
I have just discovered that importing an Endnote generated RIS file (but not BibTex file) into 1.5 sync preview succesfully does the job of preserving carriage returns in the notes field.
However, exporting the resulting 1.5 library as RIS or Zotero RDF and then importing into 1.0.7 still does not result in maintenance of the carriage returns in the 1.0.7 notes :-(
But gladly, exporting the resulting 1.5 library as MODS and then importing into 1.0.7 does result in maintenance of the carriage returns in the 1.0.7 notes :-)
The problem with this workaround is that 1.5 does not import the keywords from the Endnote generated RIS file (although 1.0.7 does, without preservation of carriage returns). This was not a concern for me because I would have wanted to delete the keyworrds anyway.
The changelog notes that 1.0.0b3.r1 (January 8, 2007) added support for line breaks in RIS import. Any idea why this "feature" was apparently removed sometime before 1.0.7 & eventually added back in for 1.5?
In EndNote®'s export functions, everything is dumped as-is: long lines are not wrapped & only user-entered newlines remain in the output file. (This limitation is also why they do not follow the spec w.r.t. new markers for distinct keywords in export files--their export facilities can treat lists of authors or editors specially, but every other field is just dumped as-is.)
However: when EndNote X imports an RIS file, it ignores new lines--everything is concatenated together. Zotero 1.0.7 is doing the same thing on import as EndNote X does.
(It may be possible to push the new translator to <=1.0.7 without causing too many problems. I'll check.)