Upgrade StorageNotes on using COinS
I've just begun experimenting with COinS, and I thought I should post some of my findings to help other newbies.
1) Zotero does not parse local files for COinS metadata. If you're playing with a test file or something, you MUST upload it to a server first - Zotero won't "see" the COinS till it's on a live server.
2) As of this writing, Zotero fails when processing the output of the COinS Generator. (see discussion below).
3) Zotero handles multiple COinS authors in some slightly peculiar ways, so be careful with those fields (see below).
ON THE COINS GENERATOR
OpenURL defines a lot of fields for specifying authors. The three we're concerned with here are:
rft.aufirst: The author's first name, e.g. "April"
rft.aulast: The author's last name, e.g. "Ryan"
rft.au: The author's full name e.g. "April Ryan"
If you give the COinS Generator the name "April Ryan", it'll produce a COinS reference containing these three fields:
rft.aulast=Ryan
rft.aufirst=April
rft.au=April+Ryan
Unfortunately, Zotero cannot handle duplicate author info. If Zotero sees the same author specified in an rft.au field as was specified using rft.aulast and rft.aufirst, then it will not recognize the COinS data, and will fail to put an article button in location bar. This is a silent failure; no error message is generated. If you'd like, you can see my test case.
If a page contains multiple COinS references, and the first one has only one author, but the second one has duplicate author info as above, then Zotero may give you an error message stating that the script has failed. This only happened once during my testing, though, and I wasn't able to reproduce it, so it may have been caused by some unrelated factor. Also, I'm afraid I didn't get the exact text of the error message.
Since using the COinS Generator is recommended in these forums, this bug has no doubt caused several newbies some serious head-scratching. It took me three hours to diagnose this problem, working backwards by comparison with a working COinS reference from another site.
ON MULTIPLE AUTHORS IN COINS DATA
When you have multiple authors, there are two ways you can arrange these fields.
* Use rft.aufirst and rft.aulast for the primary author, and rft.au for all subsequent authors.
* Use rft.au for all authors.
As noted above, you cannot list an author once using rft.aufirst and rft.aulast and then re-list the same author using rft.au.
With an rft.au field, Zotero will "guess" which is the "first" and "last" name by splitting the field along the spaces and treating the last name given as the surname. Earlier names are left in the order they appear. So given the input rft.au=Leticia+Melisant+Hines, Zotero will declare the name "Hines, Leticia Melisant".
That makes perfect sense until you hit Asia. Suppose you're looking at an article having two authors: Leticia Melisant Hines, and Hsien Lu Chen. The Chinese customarily arrange their names family-name first, e.g. Chen Hsien Lu. In this case, you'll have to use rft.aufirst and rft.aulast to specify the order for the Chinese author. Incidentally, this will cause the Chinese author to be listed as the primary author for the article. If Chen Hsien Lu is a first-year graduate student working in the lab of Professor Extraordinaire Leticia Melisant Hines, that might ruffle some feathers. And that doesn't even consider what happens if you have a mix of eastern and western authors in a number 3 or greater.
This problem seems to be a weakness of the OpenURL spec itself - the spec assumes that names will follow the western pattern, and doesn't offer any way to do it the other way around if you're dealing with any more than one author. They considered character encoding issues; you can write a properly formatted OpenURL reference using Japanese hiragana or Chinese kanji. You just can't put the names in their native order if there's any more than one author.
Subdividing the rft.au field would have done it - say, rft.au=Hsien+Lu/Chen, where the family name always follows the slash. That way you could specify the order of the names for multiple authors. I mean, nobody has a name with a slash in it, right?
In general, I'm going to stick with plain rft.au for all authors.
P.S. The forum accepts HTML input, but there's no indication which tags are supported. I used several lists in the first version of this post - including the OL, UL, DL, DT, and DD tags. Then once I hit preview I had to go back and remove them, because they all inherited the formatting you've specified using your site-wide CSS file, and it looked ridiculous. Oh, and apparently HTML mode treats line-breaks as a BR tag, so if you've also specified P tags for your paragraphs, you'll wind up with huge empty spaces between paragraphs.
To prevent people wasting time using markup that'll just have to be removed, could you please specify on the commenting page which tags are safe to use?
1) Zotero does not parse local files for COinS metadata. If you're playing with a test file or something, you MUST upload it to a server first - Zotero won't "see" the COinS till it's on a live server.
2) As of this writing, Zotero fails when processing the output of the COinS Generator. (see discussion below).
3) Zotero handles multiple COinS authors in some slightly peculiar ways, so be careful with those fields (see below).
ON THE COINS GENERATOR
OpenURL defines a lot of fields for specifying authors. The three we're concerned with here are:
rft.aufirst: The author's first name, e.g. "April"
rft.aulast: The author's last name, e.g. "Ryan"
rft.au: The author's full name e.g. "April Ryan"
If you give the COinS Generator the name "April Ryan", it'll produce a COinS reference containing these three fields:
rft.aulast=Ryan
rft.aufirst=April
rft.au=April+Ryan
Unfortunately, Zotero cannot handle duplicate author info. If Zotero sees the same author specified in an rft.au field as was specified using rft.aulast and rft.aufirst, then it will not recognize the COinS data, and will fail to put an article button in location bar. This is a silent failure; no error message is generated. If you'd like, you can see my test case.
If a page contains multiple COinS references, and the first one has only one author, but the second one has duplicate author info as above, then Zotero may give you an error message stating that the script has failed. This only happened once during my testing, though, and I wasn't able to reproduce it, so it may have been caused by some unrelated factor. Also, I'm afraid I didn't get the exact text of the error message.
Since using the COinS Generator is recommended in these forums, this bug has no doubt caused several newbies some serious head-scratching. It took me three hours to diagnose this problem, working backwards by comparison with a working COinS reference from another site.
ON MULTIPLE AUTHORS IN COINS DATA
When you have multiple authors, there are two ways you can arrange these fields.
* Use rft.aufirst and rft.aulast for the primary author, and rft.au for all subsequent authors.
* Use rft.au for all authors.
As noted above, you cannot list an author once using rft.aufirst and rft.aulast and then re-list the same author using rft.au.
With an rft.au field, Zotero will "guess" which is the "first" and "last" name by splitting the field along the spaces and treating the last name given as the surname. Earlier names are left in the order they appear. So given the input rft.au=Leticia+Melisant+Hines, Zotero will declare the name "Hines, Leticia Melisant".
That makes perfect sense until you hit Asia. Suppose you're looking at an article having two authors: Leticia Melisant Hines, and Hsien Lu Chen. The Chinese customarily arrange their names family-name first, e.g. Chen Hsien Lu. In this case, you'll have to use rft.aufirst and rft.aulast to specify the order for the Chinese author. Incidentally, this will cause the Chinese author to be listed as the primary author for the article. If Chen Hsien Lu is a first-year graduate student working in the lab of Professor Extraordinaire Leticia Melisant Hines, that might ruffle some feathers. And that doesn't even consider what happens if you have a mix of eastern and western authors in a number 3 or greater.
This problem seems to be a weakness of the OpenURL spec itself - the spec assumes that names will follow the western pattern, and doesn't offer any way to do it the other way around if you're dealing with any more than one author. They considered character encoding issues; you can write a properly formatted OpenURL reference using Japanese hiragana or Chinese kanji. You just can't put the names in their native order if there's any more than one author.
Subdividing the rft.au field would have done it - say, rft.au=Hsien+Lu/Chen, where the family name always follows the slash. That way you could specify the order of the names for multiple authors. I mean, nobody has a name with a slash in it, right?
In general, I'm going to stick with plain rft.au for all authors.
P.S. The forum accepts HTML input, but there's no indication which tags are supported. I used several lists in the first version of this post - including the OL, UL, DL, DT, and DD tags. Then once I hit preview I had to go back and remove them, because they all inherited the formatting you've specified using your site-wide CSS file, and it looked ridiculous. Oh, and apparently HTML mode treats line-breaks as a BR tag, so if you've also specified P tags for your paragraphs, you'll wind up with huge empty spaces between paragraphs.
To prevent people wasting time using markup that'll just have to be removed, could you please specify on the commenting page which tags are safe to use?
My findings indicate you have to change slightly the result of COinS generator:
rft.aulast=Ryan
rft.aufirst=April
rft.au=Ryan,+April
This means: Last name first in the rft.au filed, and comma-plus signs (,+) so that both fields are considered as last and first names.