ZineLibraries.info

Union Catalogue/xZineCorex
Update from last year: we’d started to define zinecore: Dublin Core for zines
Idea behind this is that we’ll have a metadata standard that we all accept, so that this basic set of fields will be consistent, regardless of our catalogues. AND THEN it will be the basis of our union catalogue (WorldCat for zines!!!)

ZineCore refresher:
Title
Creator(s)
Subject(s) / Genres
Content description/notes
Publisher(s)
Contributor(s)
Date of publication
Type
Format / physical description
Identifiers (union ID#)
Source
Language
Relation (see also)
Coverage (place of publication
Rights (freedoms and restrictions)

QZAP has been using zinecore in their catalogue now: hasn’t changed things necessarily, but gives a standard to shoot for

What we need to do next:
We’ve been talking about this through 4 unconferences…what’s next? Things to bring back to our cataloguers. Interference Archives in NYC also interested in starting a catalogue: maybe two groups working on this will help move things along. They are building the history of the collection as they build the catalogue. Not quite the same goals, but adds complexity.

Goal: worldcat for zines! So we all know between ourselves, but also to help point researchers to other places.

Collective Access might be the tool we build this in. Cataloging tool built on a LAMP stack, based on Dublin Core, open source, free to use. Next step for QZAP is to build an install profile — from the time you add the software, you can choose that user profile and it will pull the (in this case, zinecore) fields for that profile. CA is geared for digital objects, which is great for QZAP, but also will allow folks to add cover scans, etc.

There are other products, but this allows you to import data from comma/tab delineated files, Excel spreadsheets. Question about LibraryThing– should be able to pull as a spreadsheet? Also: MARC records should also be able to be pulled in? Some concerns with MARC fields/subfields…You can have multiple instances of DC fields.
So, there may be some human element to pull out elements one way or the other — or a script that runs to do that. But, those are also mostly easily identifiable elements, just something to know we have to do. A lot of trial and error, but.

If we’re adding to a union catalogue, will there be duplicate entries, or a field for holdings?
Zinecore is defining the object — one of the additional pieces we’ll need for the union catalogue is a Holdings record.
So — we’d use the union catalogue to find the record, then add it to our own individual catalogues. But, we’ll also have a bunch of separate records for, say, Doris — how do we clear this up?

We have an identifier for the record, but maybe also some kind of title identifier (or authority file!) to see all the Dorises. (A “work” record in RDA/FRBR-speak)
But! We don’t have professionals doing this, necessarily….
So, we need a name authority file and title authority file. So: Cindy Crabb will always be Cindy Crabb and not Cindy Ovenrack. So, you can see the other names the person goes by, but you can also redirect someone to all the things that person has published.

So, we’re talking about two sides of the catalogue: the names part is not directly about the record’s metdata.

This takes everyone using the same rules — does this fit our community?
If we build the system, it’s already there…but someone has to do the work for the Cindy Crabb/Cindy Ovenrack. Is this gonna be so large that this is necessary? Is this something that has to be done going in?
Knowing that we’re going to do this down the line…is important to know, software-set-up wise…but no, we don’t necessarily have to do it now.
Could Zinewiki be our authority file? (Yeah — people like that.) But would that just be adding a lot more work, to add Zinewiki entries? Or….can the union catalogue that would then push data back out to Zinewiki?

Unique identifier for each zine — could it be a Uniform Resource Identifier that could be linked into the semantic web? (E.g. linked back to Zinewiki?)
So Doris #3 is a part of this uniquely identified DORIS.

Question about Type — a little confusion about what it means in DC. The field is there if you need it, you can leave it blank if you don’t use it.

Authority files: you can have multiples, as long as they communicate with each other. Which goes back to having a URI, so there’s a unique key to help connect them together.

Lunch: let tech people have their tech conversations…and then come back.
What did folks want to get out if it? A plan/timeline. A way for us to know that we’re cataloging things in a way that will be useful down the line. We don’t need to be anxious about this now, y’all!
What might help the tech discussion is: talking about the quirky little things we do in cataloging. (e.g. description of the cover, a la Papercut Zine Library.)
Questions too about editions, donor information…how does that stuff fit into Zinecore? Is it separate? Extended DC?

Notes by Kelly