Zine Library Catalogue Final Report

In the spirit of zine-making, Amanda and I intend to reformat and publish our final report for this project as a zine. However, for those who might be following our progress online and also for review by our instructor before we can format, publish and distribute our paper-based report, we’re pre-publishing it electronically to this blog. Enjoy. There’s also a PDF version here.

Introduction

This zine is the story of how the Anchor Archive Regional Zine Project’s catalogue was born. The Anchor Archive is a not-for-profit organization in Halifax, Nova Scotia that encourages zine making and reading and makes independent media and information more accessible by focusing on self-publishing, art, do it yourself media, and education. This is done primarily through running a library, offering workshops, and hosting events. It was started in July 2005 by 2 women in the front room of their house, and it’s entirely run by volunteers on a very small budget (although since we got non-profit status last year we’re starting to get grants and employing people for special projects).

We hope that this zine will help other small libraries with unique collections that are embarking on similar projects, and so we’ve included as much relevant information as we can without getting too technical as to be boring. We explain how we came up with the system requirements, how we evaluated and chose software, how we designed the system, how we found the resources to do the project, and our future plans for implementing the system and making it sustainable. We also include resources on zine libraries and open source software.

We have documented this project on our blog, which includes more technical information than you’ll find here. You can visit the catalogue from the blog too. We welcome your feedback and questions about the catalogue. Write to us at anchorarchive@robertsstreet.org or 5684 Roberts Street, Halifax, Nova Scotia B3K 1J6, Canada.

We want to thank all of the people who helped with the project and offered their unique and valuable expertise: Sarah Evans, Sonia Edworthy, Neskie Manuel, Mark Leggott, Keith Lawson, the School of Information Management, the Robertson Library, Laura Kennis, Skye Louis, Lucas Dambergs, and Susanna Eve.

The Original System by Sarah Evans

Once upon a time, 3 years ago, Sonia and Sarah set about the task of turning their zine collections into a zine library.

We had both accumulated wonderful collections of zines and art books and other bits and pieces from all over the world, and were excited to be able to share with others. Several local zine fairs and lots of great conversations had convinced us that this was a worthy endeavor, and that Halifax was ready for it. There was really no other fun all-purpose public space around, and a zine library felt like the perfect foundation for somewhere that could be an access point for all kinds of DIY art and activism.

When we moved into Roberts Street, we piled our boxes of zines in the living room. How would the zines be organized? Really, their presentation and organization dictates how they are accessed and used. First, we made a list of general categories. Some categories described zines by type (“Poetry,” “Comics,” “Literary and Art Comps.”) Others categories described common zine subjects (“Gender and Queer,” “Food and Cooking,” “Bikes and Transportation.”) Then we went through the zines and put them in piles according to the topics. Some were manageable stacks, other unwieldy piles. We subdivided categories if they seemed too broad – like “Travel” (the multitude of zines about adventures on the road) led to “Cities and Places” (more generally about specific locations). Other topic divisions were somewhat arbitrary: “Women’s Health” is distinct from “Mental and Physical Health” because there are so many zines about periods and abortions. And how is “Activism” different than “Politics” anyways?

More than half of the zines were categorized broadly as “Personal Zines” (also called Perzines.) This is a somewhat troubling catch-all category for zines usually made by one person about their life and experiences. Sometimes the writing is journal-style, or sometimes it involves stories and poems. These are in boxes with letters, sorted by title. As much as possible, we pick out themes in zines to organize them by category. But many tend to get lost in the perzine boxes, since folks generally browse the collection by topic.

First the zines went on a narrow shelf with metal bookends separating them and popsicle stick flags identifying the categories. Then our wonderful modular shelving unit was built, and each category got its own box. This is awesome because it’s easier for patrons to take a box out and browse by topic. Several topics took over additional boxes, and some new subjects were added as we decided they were necessary (“Education and Schooling” for all the dropout and deschooling zines; “Work and Jobs” for ones about unions and work experiences). Some continue to confuse us – does Radical Pet go in “Parenting”? “Health”?

Individual zines are not marked (except for the “Anchor Archive” stamp) so they move around between boxes depending on who is doing the shelving. Recently I found a personal zine called “Greenzine” in the “Environment and Nature” box. Nope. This is trouble, but also just what happens with a growing and changing system. As zines are donated, they get added to the “New” box and then eventually get sorted into the categories as whoever is volunteering sees fit.

Our system for membership is even more sketchy. By paying $2, working a shift, or donating a zine, someone can become a member and borrow zines. For our opening, we made nice little copied membership cards and numbered the first 2 or 3. After that, we just used recipe cards with people’s names and (hopefully) phone numbers, emails, and addresses on them. Membership cards are kept in a little recipe box and people record the zines they take out, the date, and the date due (two weeks). This functions as an honour system, and doesn’t work very well. Some zines have disappeared forever; some are gone and then come back a year later. We sporadically make calls to everyone with overdue zines, and half the phone numbers are disconnected. This is the risk of lending zines, but we have so few open hours and our space is so small that we really have to lend them to allow folks to fully read and appreciate all the zines. We’ve replaced many missing zines, but some are irreplaceable and gone forever.

Every week or so I look for a specific zine to read again or show someone. I look in every category box where it might be, I look in the alphabetical perzine boxes, and then in the pile of returns. If it’s none of those places, I assume someone has taken it out, hope that they are enjoying it, and double-hope they’ll bring it back.

We’ve known for awhile that we needed a new system, but haven’t had the time or resources to create something different. Then some library school students started hanging around the zine library…

The New System

I used to write a zine when I was a teenager (it was called “Yum”) and was very involved in the zine scene for a few years in the mid-90s, but then I lost touch with it when I started university and stopped writing my zine. A year and a half ago, I moved to Halifax to go to library school at Dalhousie University and I discovered this amazing zine library in Halifax called the Anchor Archive and simultaneously rediscovered the amazing world of zines that I had forgotten. When I realized the Anchor Archive zine library needed a better system of organization, I figured it would be the perfect opportunity for me to share my librarian knowledge and create something for them, and for me to get experience managing a technology project and learn about open source software (open source software seemed ideal to use for the system, and I wanted to learn more about it). I wanted to do the project as a directed studies course so that I would have the time to do the project and some assistance from my professors at school. It took me a while to convince my school that this was a good idea and to find an instructor who would supervise me. Eventually, I was able to do the project with Mark Leggott, the Head Librarian at the Robertson Library at University of Prince Edward Island, who loves open source software and offered to supervise some library school students working on open source software projects. It was good in the end that I had to wait, because in the meantime my friend and classmate Zac got involved with the project and agreed to do the directed studies course with me, and it would have been really hard to complete it without him since he has a Computer Science degree and programming abilities. It was also nice to have the moral support of working as a team.

As Sarah described in the previous article, the current system for organizing zines is good for browsing for zines by topic, but it’s not good if you want to search for a specific zine or subject that’s not represented by the box categories, or for searching for more than one subject at once. The current system also makes it hard to keep track of whether a zine is in, out, overdue, or missing. To figure out what kind of system would work better, we thought about the Anchor Archive’s collection and users, talked to the volunteers about what they wanted, and researched the systems used by other zine libraries and libraries with zine collections.

Zine libraries and zines in libraries are a growing trend in the library world and zine world right now. I wouldn’t say that zines are about to take over libraries, but public and academic libraries all over the U.S. and Canada are establishing zine collections. In public libraries they are often part of youth services, while in academic libraries they’re often special collections. There are also zine libraries, like the Anchor Archive, that are dedicated solely to zines and other alternative media scattered all over North America and the rest of the world. To learn more about the zines and libraries phenomenon and to find zine collections in libraries or zine libraries near you, check out the resources listed at the end of this zine.

Libraries take a lot of different approaches to cataloguing zines, since zines are quite unique and different from both books and magazines or journals. Most public and academic libraries use standards of classification and categorization, such as Anglo-American Cataloguing Rules (AACR2), machine-readable catalogue (MARC) records, and the Dewey Decimal System. The good thing about using standards is that it allows libraries to share resources. The bad thing is that standards standardize things, simply put, and do not always accurately represent unique, alternative, or local content. You could definitely say this describes most zines. Zines are about breaking rules and doing things your own way, not conforming to what other people are doing. As well, zines do not even include all of the bibliographic information you find in most books. Many do not have publication dates, page numbers, or sometimes even authors or titles.

Still, some libraries catalogue their zines using AACR2 and MARC records so that zines can be included in a library’s main catalogue along with the rest of the collection and zine records can be shared with other libraries. The majority of zine libraries, however, recognize that zines demand a different approach, and so different zine libraries do different things. Many zine libraries do not have catalogues per se but provide a list of their zine titles, organized by subject. This is likely a reflection of the limited resources of zine libraries. Libraries with zine collections sometimes don’t catalogue their zines because they don’t circulate, or they’ll catalogue their zines in a database that’s separate from the main catalogue. Others have catalogues with limited search capabilities. Two zine libraries that have more developed catalogues are the Independent Publishing Resource Centre and the Salt Lake City Public Library.

After looking at all of this stuff, we decided we wanted something that was

  • unique and customized to the Anchor Archive’s collection and users, and thus did not use library standards like AACR2 and MARC records;
  • simple to use, since volunteers would be coming and going, and there may not always be someone involved with the Anchor Archive who has librarian training or a computer science background;
  • cheap, since the Anchor Archive has very little money;
  • going to allow users to add tags and reviews to catalogue records;
  • able to accommodate an electronic catalogue and system for circulation (borrowing), but not anything extra like acquisitions, interlibrary loans, etc.

Open Source Software for Libraries

We decided to use open source software for the Anchor Archive’s catalogue because of financial limitations, but also because open source software is highly customizable and the Anchor Archive has similar values to the open source movement (they are both DIY, into sharing resources, and anti-copyright). So our next step was to look at different software programs available and evaluate them. We read articles, looked at postings on the Zine Librarian Yahoo group to see what other zine libraries were using, and installed some programs to try them out ourselves. The great thing about open source software is you can install and try programs yourself at no cost. On top of the considerations listed above, we wanted a program that was mature and widely used enough to have a large community of users and good instructions available online. To learn more about open source software and libraries, you can check out the resources at the end of the zine.

We considered programs like LibraryThing and Wordpress, but these would only allow us to make a catalogue and couldn’t manage circulation. We looked at the integrated library systems Koha, Evergreen, PhpMyLibrary, and OpenBiblio. We couldn’t find much information about the latter two, which put them out of the running. Evergreen was designed for large library systems with multiple branches and has only been used extensively by one library system, so it didn’t seem to be customizable enough for us. Koha, on the other hand, seemed like a good option. Koha has been around since 2001 and is used by small, medium, and large libraries all over the world. It is sophisticated software that can do a lot of different things that libraries do, and it would certainly manage both an online catalogue and circulation system. However, it does a lot of things the Anchor Archive would never need to do and it’s structured heavily around the use of MARC records. In the end we decided that using Koha would mean dismantling a lot of it in order to make it simple enough for Anchor Archive users, so instead we decided to go with Drupal.

Drupal is a content management system, and it was made for designing websites, but it can do a lot of other things as well (some people would say it can do anything.). We chose it because we thought it would allow us to build a customized system for the Anchor Archive almost from scratch, rather than having to fit the Anchor Archive into another system that is designed for a traditional library. We were also excited about doing something new with Drupal, since Drupal is not commonly used for library catalogues or systems, although many libraries use it for websites and other stuff. You can read more about Drupal in Zac’s articles.

System Summary

The online catalogue for the Anchor Archive tries to be a simple, straightforward, and ultimately flexible solution to the Anchor Archive’s need for an electronic, searchable catalogue and a convenient way to keep track of the circulation of zines. The system makes use of free, open-source and highly-popular Drupal content management software, which is very flexible and has a large community of users and developers.

The Anchor Archive’s collection includes books and CDs as well as zines, but for now we created the catalogue for zines only. In the future the catalogue could easily be extended to books and CDs also. We decided to use the following fields in each zine record: Title, Author, Contributors, Primary subject (or the box in which the zine is stored), additional Subject terms, Publication date, Geographic location, Number of pages, Physical description, Language, Summary or Abstract, and Notes about the zine. The system also allows users to add subject or keyword tags and reviews to zine records.

We decided on these fields after considering the types of information which could likely be found for many zines. We wanted the system to be able to handle typical details, but we also recognised that lots of zines lack the kinds of information described above, so none of the fields are required except for the title.

We created controlled vocabularies for the primary subject and additional subject terms fields, which means that cataloguers will have a list of pre-decided words to choose from when adding a subject to a zine record. We debated this, because it adds an element of control and standardization that is not welcome in the zine world. But in the end we decided it was important for helping users to search. For example, without a controlled vocabulary, zines about bikes could have many different subject terms, including bicycles, bikes, and cycling, and to find all of the zines about bikes users would have to search for all of these different terms. If, on the other hand, we use a controlled vocabulary and decide that bicycles is the preferred term, all of the zines about bicycles will be retrievable using this search term and users will be directed to use this search term.

Our system keeps track of bibliographic records and copies of zines separately. In a bibliographic record, the system keeps all of the attributes of a zine mentioned above. The Anchor Archive has multiple copies of many zines. Rather than duplicate all of this bibliographic info for each copy of a single zine, we decided to keep track of the copies of a zine separately from the details of the publication and then link the records together. This is important as a way to tie all of the copies of a zine together, and also as a way of keeping track of each copy of a zine separately.

The reason we need a record of each copy of each zine is for the Anchor Archive to be able to keep track of the circulation of zines. If we have two copies of a zine and one is on loan, there needs to be a way to easily find out that another copy is still available.

Users can search for zines in the catalogue in a number of ways. Users can search the entire contents of the catalogue using simple keyword searching, or they can search for phrases, multiple words, and subject terms in an advanced search. They can also search specific fields, such as the Title or Author field of zine records. Users can also browse the collection based on subject terms, including the terms for the boxes in which zines are stored. Finally, there is a listing of recently-added zines.

The system allows librarians to check items in or out of the collection, to view the check-out history of any item in the collection, to see all items checked out by a specific user, and to review a list of all zines currently checked out.

Users are added to the system by librarians or volunteers when they become members of the Anchor Archive. At this point, they are given a username and password which they can use to log in to the system from anywhere and check their accounts or add tags and reviews to zine records. All borrowing clients or patrons of the Anchor Archive will need to be issued system accounts in order to borrow materials. People who are not registered members of the Anchor Archive will be able to search the catalogue and view the library’s collection, but they won’t be able to add tags or reviews to zines.

About Drupal

The Anchor Archive system was built using Drupal. Drupal is free software, meaning that everyone is free to use it, modify it, and learn from it as they see fit, so long as any changes are also shared freely. Drupal is a content management system for the web, meaning it is used to allow websites to add and manage content in a consistent way. Blogging software is an example of simple content management software, and while Drupal is able to manage blogs, it’s far more flexible than that. Drupal is highly modular, meaning that the system itself doesn’t do a whole lot, but it can be extended with modules that provide extra functionality.

Modules are central to every Drupal system. A typical system makes use of many different modules, each of which adds some function to the system. These functions could be tiny, like making sure that no two posts have the same title, or large, like the core of an online store. A good analogy is that modules are like pieces of Lego – you need to put a lot of little pieces together to make something useful.

Getting into Drupal can be a bit intimidating. When you first start using Drupal, it can take a while to figure out how modules work, how they interrelate, and how the system itself works. It took me a long time to get over how little Drupal does until we started layering modules together to do useful things. Then I began to realise that Drupal can do almost anything, it just takes some effort to find the right modules for the job.

There are so many modules available that do all manner of things that there is usually more than one way to accomplish a task in Drupal. Figuring out which way is the best way can take time. Fortunately, because the user community is so large, there are vast forums at drupal.org where new users can search for answers to questions that have already been asked – and most questions have already been asked. For some tasks, the best way to accomplish them may be to create a custom Drupal module. In the Anchor Archive system, we decided that the best way to provide circulation functions (loaning zines to users of the library) was to create our own circulation module.

Writing or modifying a module requires understanding of the programming language of Drupal, PHP. It also requires understanding of the structured way which modules must be written in order to interface with Drupal’s internal functions.

System Modules

The Anchor Archive online catalogue uses a number of Drupal modules to make the system work. This is a summary of the major modules which we used in making our system, and the functions which they perform in the system, including the module we wrote ourselves.

The Content Construction Kit (CCK) is one of the most important modules in many Drupal systems. In Drupal, content is stored in nodes, which have different fields which store data. For instance, the title of a node is a field. In a blog post (which would be considered a node), the content of the post is stored in a field, probably called ‘body.’ CCK allows you to create your own field types and add them to nodes. In our system, we have a content type called “zine records” and most of the elements of zine records (title, author, publication date, language, description, etc.) are stored as CCK field types. We have other nodes or content types for items (individual copies of zines) and users. Lots of other modules create their own field types, and they all rely on CCK to make this happen.

The Views module is used to create and display lists of nodes. Views is another really important module in lots of Drupal systems. It allows you to create tables with different CCK fields in each column. In our system the “New Zines” list is generated with the Views module. Views can also be used to do precise searching.

Basically, Views uses filters to restrict what they display, so they’re useful for making search functions. A View with no filters finds everything. Filters in views can be fixed, meaning they always display the same thing, or they can have “exposed” filters. Exposed filters let users control the criteria that Views uses to find results. In our system, we have a View called “Search by field” which allows users to search for records based on their title, author, subject terms, geographic location, or publication year. Each of those fields is an “exposed” filter in the View. There is also a “hidden” filter in there which causes the View to only look at zine records, instead of any of the other content types in our system, such as items or user profiles, for example.

When you view a zine record, you see a list of all of the copies of that zine - this essentially combines data from two different content types and is a Views list embedded in a CCK field type. Making this work requires three modules: Views, CCK, and the View Field module to tie Views into CCK. The View which creates this list takes as an “argument” the node-id of the zine record. “Arguments” are like “filters,” only they’re set by another part of the system instead of by users entering something in a form.

The Taxonomy module allows you to create controlled vocabularies, add terms to these vocabularies, and associate a vocabulary with a particular content type, so that then the vocabulary appears as a field in the content type when one is entering a new item. When entering data into a vocabulary field, a user would normally select a term from a list, but when you create a vocabulary you can also set it up as Freetagging, which means that content is categorized by typing terms instead of choosing from a list. You can also set up a vocabulary as a hierarchy, with broader, related, and ‘use for’ terms, or you can disable this function in an individual vocabulary. In our system we use taxonomies for the subject of the box in which a zine is stored in the library, and also for the subject terms which cataloguers assign to each zine and for the terms which users assign to each zine using the Community Tags module.

The Community Tags module allows users to add keywords to content. On our system, this means that users can tag zine records with descriptive terms, and other users can browse those terms or search by them. When anyone views a zine record, all of the tags which have been added by users are displayed in a tag cloud, where more popular terms are shown in a larger font than less popular ones. This module has some problems, but it’s still a good way to allow users to contribute to the catalogue.

Automatic Nodetitles is a module while allows users to skip filling in the title field when creating new content of certain types. In Drupal, every node must have a title. In our system, we use the title field in item records as the call number for a copy of a zine. Automatic Nodetitles allows us to skip entering a title in new item records and instead use whatever PHP code we want to generate one automatically.

Node Go To module allows you to set the location where the system goes after adding, updating or deleting nodes of each content type. In our system, we use Node Go To to forward users to the page for adding a new item record once they finish inputting a zine record, and vice-versa. This allows us to set up simple workflows to save cataloguers time when adding new records to the system.

Faceted Search provides a way to browse for content based on taxonomy terms within the system. This module displays a list of terms from all vocabularies, sorted by the number of items which are connected to each term. When you click on a term, you see a list of zines associated with that term. You also see a new list of all the taxonomy terms associated with all zines in the new list. This allows users to narrow their browsing results by using multiple terms at once. Faceted Search is similar in functionality to another module called Directory, which is also useful for browsing taxonomy terms, but in a different way.

Node Profile module allows you to use nodes to store user profile information. In Drupal, almost everything is a node. Users are not, though - they’re users, and there are limits to the kinds of fields which can be added to user records. Using CCK, the possibilities for field types in nodes is limitless, but this functionality isn’t transferable to user records. What Node Profile does is associate one content type in Drupal with user records. Each user record is connected with one (and only one) node from the node profile content type. This allows you to incorporate any custom CCK fields into user records through the user profile content type. In our system, we use two little modules called Address Field and Phone Number, which create special CCK field types for addresses and phone numbers and also make sure that the contents which users enter into these fields look like real addresses and phone numbers.

Computed Field is another CCK-based module. It defines a new CCK field type called Computed Field which allows you to use whatever PHP code you want to generate a result. This module requires some special knowledge of how PHP and Drupal work, but it is extremely flexible in that you can use it to display almost any specialised result you want. We use Computed Field to return the circulation status of items (whether they’re checked in or out of the library) as a CCK field. This field can then be referenced by Views, and could provide a means of searching for items based on their circulation status or any other special information you want.

Circulation is a module which we wrote specifically for the Anchor Archive to handle circulation functionality within the catalogue. Circulation is used to track when users borrow zines, when they’re due, etc. This module is available for anyone who wants to use it or learn from it; however, it was built specifically for the Anchor Archive system and may need to be adapted for use elsewhere.

The module is built to work with MySQL and would need minor changes to work with another database management system. Circulation is a fairly simple module. It keeps track of circulation information in its own table within Drupal’s database. The module defines a new permission state within Drupal for users who are allowed to check items in or out (like Librarians, Volunteers or system administrators). For those with permission, the module does a few things:

  • It creates a page where all items which are on loan to users are displayed in a table.
  • It creates a page where Librarians can check an item out of the collection. This page has a text box for a username, and another text box for the call number of the zine to be checked out. The module uses autocomplete functions for both of these text boxes. Librarians can enter any part of a user’s name and the autocomplete function will locate the full system username. Librarians can also enter any part of the call number or the even the zine’s title and the autocomplete function will locate a complete call number.
  • It hooks into the display of item records to provide detailed circulation information about that item. For items which are checked out, the module outputs a table showing when it was checked out, when it is due and which user has the item. It also includes a function to check the item back into the collection. For items which are checked in, it includes a function to check the item out. For all items, the module includes a function to display the entire circulation history of that item (who has borrowed it in the past, from when to when).
  • It hooks into the display of user records to provide detailed information about all of the items which that user currently has out. For each item the user has out, there is a function (a button) to check the item back in to the collection.

When an item is checked out, a new entry is created in the circulation table in the database which includes a value for the item checked out, a value for the user who has borrowed the item, the date when the item was checked out, and a due date. By default, items are due 14 days after they are borrowed, however administrators can change this value in the preferences section of the module.

When an item is checked in, the module finds the entry in the circulation table which indicates the item is checked out, and it adds a new value to that entry for the date when the item is returned to the collection.

And that’s pretty much it. There’s a lot of other behind-the-scenes work that is done to make the module properly interface with Drupal, but in terms of functionality, there’s not much more than that.

The Future

The system has now been created, but the bulk of the collection of over 2000 zines still needs to be catalogued before the system can be used. While volunteers could catalogue the collection, this would take a long time and could result in inconsistencies. Instead, the Anchor Archive is planning to hire a librarian in the coming months to coordinate the cataloguing project, plus a student to assist with cataloguing. The coordinator will also train volunteers on how to use the system and how to catalogue zines, and s/he will create user guides for the new system. The training and user guides are an important part of making sure the system is sustainable. We want to make sure that the system is used long into the future and that the Anchor Archive folks have the knowledge to make changes to the system as needed and solve any problems that may arise. We see the system itself as something that will continue to evolve as Anchor Archive folks begin to use it and think of ways to make it better, respond to user feedback, and discover new things that can be done with Drupal.

We’ve applied for a few different grants that will allow us to hire people to continue the project, mainly through the federal and municipal governments, and we have our fingers crossed that at least one of these will come through.

This process is expected to take 4 or 5 months, and when the system is full of zine records and member records and ready to launch, we’re going to have a big party.

Resources

Zines and Libraries:

Zine Librarian Zine #1 and #2 by Greig Means
P.O. Box 12409, Portland, OR 97212

Bartel, Julie. (2007). From A to Zine: Building a Winning Zine Collection in Your Library. Chicago: American Library Association, 2007.

Zine Librarians Yahoo Group

Baltimore County Public Library Zine Collection zine (available in print and online)

The Book of Zines

Zine World

zineresoure wiki

Zine Libraries Interest Group blog

Barnard Library zine links page

Open Source Software:

Raymond, Eric S. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Cambridge, MA: O’Reilly, 2001.

Stallman, Richard. Why Software Should Be Free.

Open Source Software and Libraries Bibliography – contains almost every article about open source software and libraries in existence

Choosing and using free and open source software: A primer for non-profits

oss4lib: Open source systems for libraries.

The official Drupal website

dupalib: A place for library drupallers to hang out