Catalog numbers in MARC 852
Douglas Knox
Library where we discussed how Zotero could relate to various kinds of
bibliographic work in research libraries. There are many uses for
bibliographic lists that start with the catalog and maintain links
back to it. In several areas of our library we have realized that
Zotero's usefulness depends on automatically saving accurate call
numbers, which doesn't happen yet with Zotero and our catalog.
My colleague Brodie Austin and I have recently been looking at this
and related issues again in the light of what we learned from Avram's
workshop, and while we can imagine some potential translator
adaptations that could be idiosyncratic to our context, there are
three relatively small changes to the MARC.js translator that seem
likely to be of wider use. Brodie posted on the Zotero user forum in
January, and the essential changes are already contained in Brodie's
post and Avram's response at that time:
http://forums.zotero.org/discussion/16199/custom-call-number-fields-in-marc/
https://github.com/ajlyon/zotero-bits/raw/master/MARC.js
The changes are as follows:
1) add the MARC 852 field with subfields "khim" to the end of the call
number mappings after "090" and "099".
2) add support for repeating subfields. Avram's alternate version of
the MARC translator seems to work fine for this, with one correction:
3) add spaces between subfields.
I have posted a patch to add 1) and 3) to Avram's version of the MARC
translator here: https://gist.github.com/940023
This would likely benefit users of other library catalogs as well. The
topic of call numbers in the 852 field was discussed on the Zotero
user forum a couple of years ago, and resulted in a still-open ticket
that would map the 852 field to location in archive. It might make
more sense, however, to map the shelving subfields of 852 to call
number, and perhaps consider using other subfields for location in
archive.
http://forums.zotero.org/discussion/7205/problem-with-library-catalogue-translator/
https://www.zotero.org/trac/ticket/1488
http://www.loc.gov/marc/holdings/hd852.html
Douglas Knox
Bruce D'Arcus
On Mon, Apr 25, 2011 at 8:38 AM, Douglas Knox <kno...@gmail.com> wrote:
> A couple of weeks ago Avram led an intensive workshop at the Newberry
> Library where we discussed how Zotero could relate to various kinds of
> bibliographic work in research libraries. There are many uses for
> bibliographic lists that start with the catalog and maintain links
> back to it. In several areas of our library we have realized that
> Zotero's usefulness depends on automatically saving accurate call
> numbers, which doesn't happen yet with Zotero and our catalog.
Can you explain the use case here for the non-library/MARC people?
Bruce
Douglas Knox
Sure, I'm not a librarian or MARC expert, but I can try to better
explain what we're up to with a narrower and then a more expansive
understanding of "use case."
Quite simply, Zotero seems broken for us. It already tries to get call
numbers, we're a research library with lots of call numbers, and with
our catalog, Zotero not only misses many call numbers, it saves
purported call numbers that are entirely wrong (in our context).
My colleague Brodie pointed to this record back in January:
https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=696369
The evident Newberry call number there is "J 27 .28," and that's the
call number you would want if you show up in the Newberry reading
room. But if you click the Zotero icon, what you'll get instead is
"HX11 .F25 no.103," which is a Library of Congress classification
number that doesn't actually mean much to readers or staff in a
Newberry context. You won't see it in our online catalog unless you
click on the "Staff View" link, and there you can see it's in the MARC
050 field, while the Newberry call number in actual use is in the 852
field, which Zotero to date doesn't pay attention to -- though as I
mentioned, we're not the first to wish that it did. I don't know
enough to offer a full explanation of why these numbers are where they
are in various MARC fields, but my understanding is that it has to do
with cataloging practices that quite reasonably start from existing
catalog records elsewhere. It gets even more complicated, because some
call numbers we see in online catalogs aren't in the 852 or any other
fields of the MARC record we see in "Staff View," they exist only in
separate holdings records and from what I understand are inaccessible
to Zotero unless we screen-scrape the HTML catalog page. But adding
the 852 field would go a long way toward recording useful call numbers
and avoiding misleading ones.
So the immediate use case is that of any Zotero user who wants call
numbers from catalogs to "just work" in the way most of us would
expect when using the Newberry catalog or some of the other catalogs
that store call numbers similarly.
More expansively, beyond the context of this small patch, a research
library has lots of workflows that start from the catalog, hover
around it, and point back to it in various ways, but exist outside of
it. This kind of work can include making checklists and bibliographies
for administrative and reference purposes, and it also includes
exhibition and publication-based workflows that look a lot like
scholarly citation management elsewhere, except there is typically a
greater degree of collaboration, and more of a premium on keeping the
specificity of reference to particular items in a single institutional
collection. So beyond the modifications to the MARC translator
proposed here, we are also looking into saving (as Zotero attachments)
persistent links to our online catalog. Searching on call number
strings directly often doesn't go all that well.
Doug
Bruce D'Arcus
> Bruce,
>
> Sure, I'm not a librarian or MARC expert, but I can try to better
> explain what we're up to with a narrower and then a more expansive
> understanding of "use case."
>
> Quite simply, Zotero seems broken for us. It already tries to get call
> numbers, we're a research library with lots of call numbers, and with
> our catalog, Zotero not only misses many call numbers, it saves
> purported call numbers that are entirely wrong (in our context).
Hang on; let me stop you here.
Why should I (yes, someone who works on some technical details related
to Zotero, but also a scholar with background in archival research)
care about the call numbers? What if, for example, it simply dropped
the call numbers altogether?
Bruce
Douglas Knox
What an interesting question. I don't know you well enough to have my
own opinion on whether you should care, but I'll answer as if our
presumption is that you're looking for a reason to care because you
actively want to. But it's OK with me if you don't.
With Zotero's scholarly uses foremost in mind, I guess the question is
whether to think of Zotero solely as a citation manager for creating
footnotes and bibliographies in scholarly articles, which is certainly
a plausible way to think of it, or whether it's also potentially a
research platform, whatever that might mean. To consider a modest
research use beyond citation formatting, some scholars may still
wander through open stacks in university libraries more effectively
when they keep track of accurate local call numbers for items they are
interested in, whether they use Zotero or other software, or little
slips of paper scribbled on with golf pencils.
More grandly, I'd say a scholar with a background in archival research
might care because research paths are circuitous, and you never know
what steps you will want to retrace when evidence turns up where you
were not expecting it. Sometimes evidence turns up in or through a
library catalog, sometimes a particular record in a particular
catalog. If the research tool worries about the details, the
researcher's attention is free for higher-level tasks than the
interruption of many little cost-benefit calculations to decide
whether to put effort into copying a call number now because of the
uncertain chance that its absence might one day be regretted.
Doug
Bruce D'Arcus
> own opinion on whether you should care, but I'll answer as if our
> presumption is that you're looking for a reason to care because you
> actively want to.
Yes, that's a reasonable assumption :-)
> But it's OK with me if you don't.
>
> With Zotero's scholarly uses foremost in mind, I guess the question is
> whether to think of Zotero solely as a citation manager for creating
> footnotes and bibliographies in scholarly articles, which is certainly
> a plausible way to think of it, or whether it's also potentially a
> research platform, whatever that might mean. To consider a modest
> research use beyond citation formatting, some scholars may still
> wander through open stacks in university libraries more effectively
> when they keep track of accurate local call numbers for items they are
> interested in, whether they use Zotero or other software, or little
> slips of paper scribbled on with golf pencils.
>
> More grandly, I'd say a scholar with a background in archival research
> might care because research paths are circuitous, and you never know
> what steps you will want to retrace when evidence turns up where you
> were not expecting it. Sometimes evidence turns up in or through a
> library catalog, sometimes a particular record in a particular
> catalog. If the research tool worries about the details, the
> researcher's attention is free for higher-level tasks than the
> interruption of many little cost-benefit calculations to decide
> whether to put effort into copying a call number now because of the
> uncertain chance that its absence might one day be regretted.
I'm really trying to boil this issue down to it's concrete essence. Is
it fair to say something like ...
We want people that use our library catalog to be able to save items
in Zotero and subsequently find them on our shelves. Call numbers are
essential to making that possible, but currently are saved incorrectly
in ____________ ways?
E.g. I'm trying to understand the link between the MARC record and
what the user sees in their Zotero library.
Bruce
Douglas Knox
A cataloger could explain MARC details that I can't hope to, but there
are lots of places in MARC where call numbers and other kinds of
information can get squirreled away. Cataloging systems and local
practices differ and change over time. If miscellaneous information
from MARC doesn't show up in the user interface of online catalogs, to
most of us it is as if it isn't there, and end users and catalogers
alike have come to count on this invisibility. Now Zotero can get at
the whole MARC record and upset those expectations. If you look at the
Zotero MARC translator code, you will find it's prepared to look
through twelve different MARC fields with various subfields to try to
get a call number, sticking with whatever turns up last. In our case
and that of some other library systems, the result is that the end
user sees stuff that our existing systems presumed end users would
never see, and it's presented as "call number" by the authority of
Zotero. But Zotero somehow does not yet look in the one field where
our catalogers actually do often put call numbers they want us to see
and use. Our situation is perhaps not perfectly typical, but it is
also not entirely unique.
The only clarification I would add to your statement is that our
definition of "people who use our library catalog" includes internal
library use, including but not limited to use by professional
librarians and archivists. The varied work that goes on in libraries
these days can present some interesting use cases for the Zotero
community to think with, as well as perhaps an influential
constituency. (When trying to address the "why should I care about
Zotero?" question within a library, getting call numbers wrong, for
whatever reason, might conceivably present some challenges.)
Doug
Avram Lyon
I'd like to revive this discussion. I don't think there were any
reasons this wasn't implemented-- the call numbers in 852 should be
added, and repeating subfields should be supported.
The concern of library specificity of call numbers is a pretty
important one, but it sounds like we might be getting a multiple-value
set of call number and library catalog fields (paired catalog and call
number) in the near future. As present, we make no claims about whose
call number the field refers to -- so we can safely populate it with
852 data immediately.
I'm proposing this version, which Douglas proposed months ago:
https://github.com/ajlyon/zotero-bits/raw/master/MARC.js
Since we're entering the brave new world of translator unit tests, I'd
also like to have some MARC unit tests-- perhaps could you guys at the
Newberry send me some MARC records that use repeated subfields and the
852 field, so I can build some unit tests for these features?
Avram
> --
> You received this message because you are subscribed to the Google Groups "zotero-dev" group.
> To post to this group, send email to zoter...@googlegroups.com.
> To unsubscribe from this group, send email to zotero-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/zotero-dev?hl=en.
>
>
Douglas Knox
Here are a couple of Newberry records with repeated subfields in the 852 field. Your version of the MARC translator handles them well.
https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=790862
https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=792297
Doug
Avram Lyon
> Thanks, Avram, this would be good to see.
>
> Here are a couple of Newberry records with repeated subfields in the 852
> field. Your version of the MARC translator handles them well.
> https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=790862
> https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=792297
These are now fixed in the most recent version of MARC.js, which will
ship with Zotero 2.1.9 and Zotero 3.0
(https://github.com/zotero/translators/commit/3cd896002236b16b0d49f7243117e227840c2020)
This also served as the first unit test for MARC import -- we'll have
to start going over Florian's collected MARC test data and crafting
additional tests, so we can verify that his replacement MARC
translator is a reliable drop-in replacement for the existing
translator.
Avram