Monday, November 06, 2006

Zotero and RefWorks

There's been a lot of talk about Zotero and RefWorks out in library blog-o-land. I've had oblique experience with RefWorks (I wrote my own master's paper using citeulike, which I wouldn't really recommend to anyone due to the fact that, at least at the time I was using it, it was mostly geared towards science-y stuff and having to manually type in references was a Colossal Pain) as we officially support it here in my library and I'm on the committee that coordinates RefWorks issues. It's more or less a success here -- people that use it tend to really really really enjoy it once they get into it. However, I've always been somewhat resistant to RefWorks for a few issues -- some technical, some ideological:

1) It's not intuitive to use. Okay, nowadays we tend to expect our applications to be immediately decipherable and usable, and that may or may not be a realistic expectation based on the complexity of the given application. RefWorks definitely has usability warts however that probably relate from it being a website, and not an application -- users have to log into RefWorks and remember their group code, userid, and password if they haven't saved that info.

2) It's not free. Okay, it's "free" if your institution has paid for it -- the costs are transparent to you -- but due to the fact that I've had a long and somewhat goofy love affair with open source I'm naturally going to have to give some pretty serious credence towards open solutions. As it stands now when a patron leaves our university their RefWorks account stays, but who knows at what point that may change. Ceding control of your data to an external organization is always risky behavior.

3) Connectivity. If RefWorks is down, or someplace between you and RefWorks is down, your data is inaccessible. This doesn't happen often, admittedly.


Things I like about RefWorks that are not present in Zotero (that I could tell -- haven't messed with Zotero enough to be authoritative about it):

1) Buncha buncha bib format exports. The list is downright dizzying. Sure, you may not need to export your bib into the exact format needed by Meat Science, but dammit, somebody somewhere does and its nice to have a comprehensive field of export formats from which to choose. This is an acknowledged issue for the folks at Zotero, although I doubt they will ever reach RefWorks's array without some serious dedication.

2) Write-N-Cite. I actually know near-zilch about this; it doesn't work with Linux or But I've talked to a couple of patrons about it and they really like it.


Where Zotero shines:

1) Open source. (okay, okay, I'll stop harping about it)

2) Folksonomy-ish tagging.

3) Saved searches. The concept of saved searches is something I first encountered with Thunderbird -- I don't use it that often but when I do use it I'm always, damn, that's cool.

4) The ability to store data as well as metadata, like page images or PDFs of articles. This doesn't work in Linux though so I can't test it out.


Things Zotero needs to do to be an Absolute, Complete World Beater:

1) Get it so the plugin works across the board. As it stands right now using Linux and Zotero leads to a less than optimal experience -- I can't save PDFs, and for some reason at least one other person in the library can get our local catalog software to sync up with Zotero and I can't. This may be another Zotero-Linux issue. Oddly enough, I have no problem importing items from the statewide union catalog, which runs the same OPAC.

2) More export formats.

3) Resolve the weirdness with OpenURL support. When I first used it, trying to "Locate" an item bounced me to GMU's OpenURL resolver -- great for GMU, less great for anyone outside GMU. And yes, I know that there's some sort of Automagic OpenURL Discovery tool in Zotero's preferences -- I found it (belatedly -- first I unpacked the Zotero .xpi file and replaced the GMU OpenURL resolver with our own) eventually, but there should be some sort of install wizard that either guesses your resolver or asks you for it manually. I think Zotero people are working on this.

Needless to say even in this somewhat unfinished state I'm a big fan of Zotero and am eagerly looking forward to new developments.


Ilene said...

I don't want to defend RefWorks as perfect or anything, but I do want to point out that there are some reasons to be able to log in to specific accounts: Example: I teach at two universities and I have a RefWorks account at each of them. I don't necessarily want to blend the things I download into one database. In addition RefWorks will let you sign up for as many accounts as you want. Why??? If you want to, you can share the password with some colleagues/students/etc. and use it to create a joint database of citations. Very handy! We had a group of faculty in the College of Education create a database of over 10,000 items in order to review how a certain statistical method was being used in the literature. I've also created accounts to teach use of RefWorks.

Also... in terms of authentication, UMUC (and probably others) has gotten around the group code. Students use the same logon username and password used to authenticate for other resources:

John Fink said...

Ilene, thank you for your comment!

I have a complex relationship with RefWorks, much like I have a complex relationship with commercial OPACs. I agree that RefWorks is net benefit for our university -- patrons love it. I'm primarily worried about ownership of data, and secondarily about cost. I imagine that neither one of these concerns matter too much to patrons.

Your point about the group code is useful, and indeed when I talk about RefWorks I try to stress that when creating an account users ought to use the link on our web page, which bounces them to a proxy if they're coming from off campus, but occasionally I have to resort to handing out the group code.

About the group code though -- as a former systems administrator, it makes me squirm. It's not protected in any way -- there's nothing to prevent a patron from handing out the group code to anybody from anywhere so they can set up a RefWorks account, and there's no real way for us to make sure that someone who's using RefWorks on our group code is actually associated with our university.

My ideal solution would be some locally-hosted RefWorks clone that could be tied to LDAP or some other authentication scheme. That way, we'd be able to have locally stored information that, like circ records, probably should be kept private *and * we'd be able to exert more control over who had access to the service.

thadk said...

I haven't tried Zotero and have primarily been using Refworks (with a combination of Ohiolink export, Library export, Google Scholar export (for common primary sources) and RefGrabIt to avoid 98% of typing)
That said, here is my uninformed Zotero wishlist:
Import tags + contents
Import refworks export format.
Work better than RefGrabIt bookmarklet which takes basically no information from the page unless there is encoded information and then it is still far more sparse compared to an actual export on most sites (ACM).
Will not slow down Firefox w/ 40 tabs.
Metadata stored in intelligent, easy to backup location.

I do use the Write-N-Cite in-text citation find/replace/update bibliography feature of Refworks. It admittedly creates a fair amount of extra work that needn't exist managing processed and unprocessed document branches even if it is less work than it would be otherwise. That might be hard to leave behind. The processing is actually platform independent, the front end just sticks in escaped reference numbers into the word document. I could probably still use it in Zotero if I saved those numbers but that doesn't help us get away from Refworks.

Gabriel Hurley said...

Zotero has word processor integration similar to Write-N-Cite. Extensions can be downloaded for Microsoft Word and OpenOffice.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.