Sonny Software

Recently, I have been working with CiteULike a lot (http://www.citeulike.org). It's a nice way to bookmark papers. And it would be great if it teamed well with Bookends.

Any one already working with the combination?

CiteULike has very simple and speedy export funtions to Endnote (text-file) and to BibTex. Strangely, when I import the .bib-File to Bookends I the fields seem to overlay. I get an author like "Mcquire, S. },citeulike-article-id = {70632"

In the .bib-File this entry is:
Any ideas what's wrong`How to fix that?

The file you list isn't BibTeX. It looks like RIS...

Jon
Sonny Software

Wow - your fast Yes, I'd pasted the wrong one. It's corrected now.

Just happened to be in the neighborhood...

The problem is that you have tags here that Bookends doesn't know about (nonstandard BibTeX), such as

citeulike-article-id

The fix is to edit the BibTeX import filter (make a NEW one based on the one we supply) to account for the new tags. Then it should work.

Jon
Sonny Software

Thanks, works well. I'm impressed - with the support and the Import Filters Manager...

CiteULike is cool. Thanks for tipping us off, chriggi.

I have made an import filter for CiteULike BibTeX -- easier than I thought it would be -- kudos to Jon. And it works almost fine now I've told it to ignore the non-standard tags.
There's just one thing: I get the issue number before the volume number in the volume field, like this '(1) 87'. Does it matter? Is there any way to fix the filter to put them the right way round?

nicka wrote:There's just one thing: I get the issue number before the volume number in the volume field, like this '(1) 87'. Does it matter? Is there any way to fix the filter to put them the right way round?

Bookends expects the first item in the Volume field to be the volume, and a subsequent entry to be the issue.

You can fix this by

1. Ignore the issue # (of course, you may not want to).
2. Put the Issue # in a user-defined field instead of the Volume field.
3. If you can, write a Perl script (or similar) to reorder the issue and volume output in the BibTeX file (beyond my knowledge).

Jon
Sonny Software

There is now only one workflow issue left: I collect references with CiteULike and import them from time to time to Bookends. Now, if I import them all and end up with tons of duplicates.

My workaround is to tag (give a keyword) references with a temporary identifiere (like numbers _4) for the next import. Not very nice, though.

Isn't there a way for Bookends to identify duplicates and ignore or remove them?

Hi,

Of course.

Refs -> Remove Duplicates

Jon
Sonny Software

Sorry. That was too easy.

One last: During the export-import process special characters like the german umlaute (Ä, Ö, Ü) get messed up (e.g. "Ökonomie" becomes "?ñkonomie").

Any ideas how to fix that?

Importing from a text file? You probably need to change the text encoding the Bookends expects (see File -> Import Text Encoding). If it's coming from a web source, it's probably either ISO Latin1 or UTF-8.

Jon
Sonny Software

Jon wrote:Importing from a text file?

well, the .bib-File mentioned above. UTF 8 did the job. Great support. Thanks a lot!

chriggi wrote:

There is now only one workflow issue left: I collect references with CiteULike and import them from time to time to Bookends. Now, if I import them all and end up with tons of duplicates.

My workaround is to tag (give a keyword) references with a temporary identifier (like numbers _4) for the next import. Not very nice, though.

Funny. I had exactly the same problem and thought of this solution too. It's nice that it is so easy to remove duplicates in Bookends, but I think a better solution would be at the CiteULike end, if it were possible to show -- and therefore export -- only the references gathered in the last x days in CiteULike. I'll email the guy who runs it and ask if he has thought of doing that.

Jon wrote:

Bookends expects the first item in the Volume field to be the volume, and a subsequent entry to be the issue.

You can fix this by

1. Ignore the issue # (of course, you may not want to).
2. Put the Issue # in a user-defined field instead of the Volume field.
3. If you can, write a Perl script (or similar) to reorder the issue and volume output in the BibTeX file (beyond my knowledge).

Thanks for the very quick response, Jon. Neither (1) nor (2) much appeals -- (1) could get my PhD thesis rejected, and (2) would require reformatting all my existing article references.
I don't know any Perl, so unless someone reading this does and is kind enough to post a script, that's out.
For the moment, then, I'm on option (4): tidy up imported references by hand.
I've discovered since my last post that some tidying is also required for the date field if CiteULike has stored a month and a year, because it formats them as eg 'May 1999' soetimes, at least, not in proper Bookends style as yyyy-mm-dd. I don't see any way round this.

Isn't the problem with issue before volume a general one for BibTeX imports, though, since the fields in a BibTeX reference don't seem to have to come in any particular order? If so, it would be very nice to have a fix in Bookends. (I guess this is a feature request.)

Yes, I suppose there could be a special BibTeX exception where the volume and issue are put in the proper place, regardless of their ordering in the record. I'll look into that.

Jon
Sonny Software

Hm, the code actually used to check for that, but I removed it because of some conflicts it caused. I've added some new safeguards, though, and restored the function. So the volume(issue) will be imported correctly regardless of their order in the record being imported. This will appear in 8.1.3.

Jon
Sonny Software