Paper archives at QZAP.

This interview with Milo Miller, co-founder of QZAP, the Queer Zine Archive Project, is part of an ongoing series of interviews with CollectiveAccess users. Miller (who uses the pronouns ze and hir) has been making zines in some form or another since ze was 16, and has been facilitating QZAP for the past 13 years. Hir current zines include Listicle! (a zine of delightful listicles), Rumpy Pumpy #1–4 and “Us Amazonians – A Kirsty MacColl Fanzine”.  Some of their past work can be found at Currently, ze lives in Riverwest, Milwaukee where ze plots non-violent revolution around a boomerang formica table bearing swanky cocktails and yummy edibles with zis partner-in-crime and their pet rock Nigel.

Q: Could you give us some background information about your institution? Does your institution have a public-facing CollectiveAccess site?

A: QZAP, the Queer Zine Archive Project is a small collectively organized digital archive of LGBTQ+ zines.  Our public websites are: (a blog/info site run on Joomla) and (CA Pawtucket instance).


Q: Describe how Collective Access (CA) functions at QZAP. Why did you decide to use it? What do you use it for? How many volunteers interface with it? How does it contribute to the organizational mission?

A: CA is the repository for all of the documents that we put online. Prior to CA we were using a Gallery 2 instance that did not provide much in the way of being able to separate metadata out into individual fields. We switched to CA to be able to better provide finding aids for the zines that we scan. Since it is central to our project we train all of our interns and volunteers to use it to catalog the zines.  In reality there are probably four to six folks who are accessing it at any given time.

QAZP's CA back-end

QAZP’s CollectiveAccess back-end.

QZAP’s CollectiveAccess instance uses the xZINECOREx metadata standard. xZINECOREx is an emerging metadata standard [designed specifically around the descriptive needs of zines. As I wrote in my zine “xZINECOREx: An Introduction”:

It’s based somewhat on Dublin Core, which is a metadata standard for describing… lots of stuff. What we did was we listed out the Dublin Core Simple Element Set, and then created/named parallels in xZINECOREx. There are some elements that DC uses that don’t really apply to zines, and vice versa, so that’s why we decided that we needed our own standard.

I work actively on the ZL Union Catalog project. When we first came up with xZINECOREx it was super easy to just run with it and implement it in Collective Access. Since xZINECOREx and Dublin Core are so closely related I think I honestly just did a find/replace for DC_term and ZC_term in CollectiveAccess.  (It’s been a couple of years, so I can’t really remember.)

As the Zine Libraries site states, we’re working on refining ZiMM (Zine Mutual Metadata), which will be more finely tuned to Dublin Core, and we (at QZAP) will most likely implement that as well.

Q: Tell us about a time you ran into a problem with something you wanted to do in CollectiveAccess. What was the problem and how did you solve it?

A: We think it’s a pretty amazing product/project.  The biggest hurdle that we face is that we just don’t have the technical expertise or funding to configure it as we would like it.

The two things that have been most challenging both relate to Pawtucket. It has been very hard to get all of the metadata facets to display on the object pages as “clicky” links.  We would like it to be much more interactive, so that the metadata describing the object leads users to more objects that have similar metadata.  We have it working somewhat, but realize that it could be much more extensive. Also, designing and developing the UI/UX has been a bear.  Our current instance looks “OK” but it’s not going to win any awards.  It’s basically the generic out-of-the-box one with some of the colors tweaked.  If the pawtucket templates were better documented it would be easier to figure out what and where to make changes.

Finally, the iPhone and mobile templates suck.  The biggest problem is that they don’t seem to support PDFs or the JavaScript PDF viewer.  Since we’re working exclusively with PDFs it means that a lot of our audience can’t access the documents.

Q: What’s one thing you wish you knew how to do (or do better) with CollectiveAccess?

A: See above.  It’s mostly the nitty-gritty code that I don’t understand, and can’t seem to fix or help myself. I also wish that there had been much better documentation about places and geographic information, especially that it’s nested. From the get-go we kind of munged that up, and I fear that it’s going to take a lot of rubber chicken waving to get it fixed.

Q: What’s your favorite back-end trick or feature? How has this trick or feature been helpful to your institution?

A: I loved how easy it was to configure and arrange/re-arrange the data entry interface(s) to match the metadata that was most important to us.


Q: Have you ever used resources or sought advice on CollectiveAccess from other institutions that use it? Have you ever participated in discussions with other members of the CollectiveAccess user community?

A: I’ve posted occasionally to the CA forum with mixed results.  I generally feel pretty dumb because I’m neither a coder nor a trained archivist, so I feel like I’m often not asking the question in the right way to get the help that I need. I’ve also worked quite a bit with Eric Goldhagen from Open Flows, who has deployed a few CA instances.  We’ve worked through some problems together with some success.

Q: What advice do you have for organizations who are considering adopting CollectiveAccess as a cataloging or digital collections platform?

A: Make a good plan, I guess?  Or have money and labor available to throw at getting it set up the way you want?