Since the public release of Zotero in 2006, there has been a steady trickle of requests for a means of identifying the items cited in a document or project within Zotero itself. Discussion of the issue has tended to focus on “document collections” as a potential solution. The idea would be to offer a special collection in the user’s personal library that contains all of the items cited in a given document. It is a testament to the Zotero user experience that this seems like it would be an easy thing to implement: under the hood, it is anything but.
The main difficulty is that Zotero (and so MLZ) permits items from multiple libraries to be cited in a single document. In contrast to the existing Duplicate Items and Trash folders, therefore, a “document collection” folder might contain items that are outside the current library. In a Zotero database, items contained in different libraries are separate copies, even if they contain identical metadata. This being the case, if an item is cloned from one library to another in order to form a unified collection of references for a particular document, the collection will not contain the original item, but a copy; and edits to the copy will not be reflected in the document when it is refreshed. It would surely be possible to implement a “live” connection between the item shown in a document collection and an original source item located elsewhere; but it would not be simple to do.
Pressure to address this use case has been growing in the home of MLZ, here in the Faculty of Law at Nagoya University. The majority of students in our postgraduate programs hail from jurisdictions in East, South East and Central Asia, and their work is inherently comparative in scope. We have a plan to deploy student-curated research libraries for specific subject areas, both as a study aid and as a publication of the Faculty. Since MLZ is widely used among our students, the obvious way to proceed is to fuel these new library projects with materials cited in student theses; and that workflow will run much more smoothly if cited items can be easily identified in MLZ itself.
In order to get a working solution in place with minimum effort, I opted to just mark items in place with a special-purpose tag. With the latest version of MLZ, the Document Preferences popup has a new tab for “Project Name”, containing a single field. When a value is entered in the field, a special-purpose tag is applied to all cited items whenever the citations are refreshed or updated in the document.
The tagging operation is cumulative: if a project is composed of several documents (chapters, say), setting the same project name in each document will result in a single tag that calls up all references cited in any of the documents. As a side effect, references removed from a document will not lose their project tag (to produce a “clean” set of current references, you can delete the tag, then open and refresh each of the target documents). Project tags cannot be colorized, and they cannot be renamed from within MLZ. Where an ordinary tag of the same name exists, a renaming or colorizing operation on the ordinary tag will not affect the project tag.
The one small glitch with this setup is that an ordinary tag and a project tag of the same name cannot be selected separately: selecting one will also select the other. After investigation, I concluded that this small anomaly is unlikely to cause serious confusion, that it is easily avoided by renaming the ordinary tag, and that providing for separate selection of the two tag types would require too much code complexity to be worth the candle.
So there you have it. I’m looking forward to getting our subject-area teams started with their libraries, and I hope that other MLZ users will also find this facility useful. In due course, if all goes well, perhaps this approach will find a place in mainstream Zotero.