This post was written by guest contributor Jasper Bernhofer. Bernhofer received a Bachelor’s Degree in Middle Eastern Studies and Philosophy from Martin-Luther-Universität Halle-Wittenberg and is currently writing his Master’s thesis in Semitic Studies at Freie Universität Berlin. His thesis includes the edition, translation and annotation of a medieval Samaritan-Arabic Bible commentary based on the oldest extant manuscript from the late 15th century
Reference managers, which have become a common tool in academic writing, seem to lend themselves almost naturally to historical research and to the management (and citation) of oftentimes vast collections of sources. Historians are commonly faced with managing or compiling large amounts of bibliographical data, containing both primary and secondary sources. Using a reference manager with a proper GUI allows one to easily add and edit bibliographical information as well as identify and consolidate potential duplicates. The data can also be imported or exported in standard compliant formats for further processing. Based on our experience with Zotero in the course of the project Open Arabic Periodical Editions (OpenArabicPE) (Dr. Till Grallert, OIB Beirut), dealing with TEI based digital editions of Arabic periodicals from the late Ottoman period (1875–1918), I would like to make some general remarks about Zotero’s usability in the field of historical research.
In the current project a bibliography of all periodicals mentioned in the six journals forming the corpus of OpenArabicPE was automatically generated. This bibliography comprises over 2000 entries, including a few hundreds duplicates. In order to facilitate the workflow of arranging the given data and adding new bibliographical information to it, the idea occurred to make use of Zotero. This included three basic steps: importing the given data, deleting duplicates and adding new information.

Bibliographical data exported from TEI to MODS using the example of the Arabic journal al-Muqtabas (Cairo and Damascus, 1906-1916).
The bibliography was imported to Zotero in the standard compliant MODS-format generated through automated transformation from the TEI bibliography. Based on the imported data’s structure and Zotero’s underlying ontology, the new entries were automatically sorted into specific item types (book, journal article, newspaper article etc.). However, entries that are marked as “periodical” in the MODS-file were imported as “journal articles,” as there is no correspondent item type provided by Zotero. For the project at hand, this proved to be a major disadvantage. The item type “journal type” does not include the needed attributes, most notably the attribute “place”. Only the item type “book” would provide the crucial attributes, but since Zotero does not allow bulk editing of entries, the only way is to change the bibliographical information in the file imported from “journal” to “book”. Thus, only by generating false information can one work around Zotero’s fixed scheme!

Depending on the item type, only certain bibliographical information can be added using the Zotero reference manager (note for example that “journal article” does not include “publication place”).
The second step of deleting duplicate items from the list worked well overall, although some items did not appear in the duplicate’s folder due to minor variations in the TEI-export, as, for example, another form of the name of the author or editor, or as vocalized words in Arabic script which Zotero does not recognize as corresponding to the same word without vowel diacritics.
Adding new information to the bibliography again demanded to work around the fixed structure of the interface. Specific attributes of a given item type (title, author, issue, etc.) cannot be changed individually! Only through the use of tags is it possible to create information that will be exported from the Zotero library (as opposed to information added to the attribute “Extra”).

The use of tags allows working around the fixed structure of attributes. In this case a tag denoting the frequency of publication was added to the entry.
Furthermore, the fixed scheme of last and first name cannot be imposed on Arabic names considering the practice of teknonyms, patronyms and honorific titles (especially Ottoman titles for the period in question). Apart from that, Zotero only allows the use of the Gregorian calendar when suppling a date to an entry.

The bibliographical data exported from Zotero to MODS show that the original TEI information “journal” (line 363) was changed automatically to “journal article” (line 348) and that added tags were exported (lines 350-358).
After these experiences and lessons, it was decided that the project would refrain from using Zotero, since the difficulties outweigh the advantages of working with a reference manager. It can be concluded more generally, that Zotero’s current structure does not fit the needs of working with sources in non-western languages due to the specific layout of names and dates. Furthermore, this seems to apply to work with primary sources in historical research in general. Since the list of item types is predetermined, as are the attributes corresponding to each one, it is impossible to adjust the layout according to the needs of a specific source or research task. In its current shape Zotero is designed to work with contemporary, mainly secondary sources in western languages. Researches who want to use Zotero or other common reference managers beyond this frame have to take this into consideration and make an informed decision based upon it.
Very interesting post which highlights some the technical difficulties in dealing with a fixed electronic programme and the specific requirements of a research project.
I have encountered a few of these challenges in my primary source work in Russian Cyrillic and Roman sources however I was able to overcome many of these issues by switching to the Zotero variant Juris-M (https://juris-m.github.io/) which is specifically modified to deal with for managing materials in multiple languages and from multiple legal jurisdictions. It seems to have been developed originally to deal with the three Japanese alphabets and adds additonal fields into the standard Zotero templates to allow for different scripts. There are additional features that allow you to choose what is output from these different fields, depending on whether you are working on a foreign language journal or an English language one.
What this shows is that Zotero is by no means as rigid and fixed as implied in your article, although changes may require some level of programming knowledge that is beyond your average computer user.
Your other posts were of great interest as well.