Upgrade StorageCustom Call Number fields in MARC
I work at the Newberry Library in Chicago. We use a number of unusual numbering/classification systems including Cutter. This means that we use non-standard MARC fields for encoding call numbers. Specifically, we use the 852 field, as seen in the example below:
852 7_ |b gen |h J |i 27 |i .28 |t 1 |2 localCutter
(https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=696369) for the record)
I have modified the MARC translator to look for this field by adding the following to MARC.js:
this._associateDBField(item, "852", "khim","callNumber");
The problem, however, is that in the 852 example above, subfield "i" is repeated. This is not uncommon in our catalog records. Unfortunately, Zotero only grabs the first subfield, and ignores the second one. In this case, you end up with "J 27" in Zotero.
I'm not a developer, and don't know Javascript that well, but I know enough to poke around in the code. It appears to me that Zotero uses an array whose length is based on the number of subfields that have been passed to the _associateDBField function (ie in this case four).
Is there a way to tell the _associateDBField to loop through multiple references to the same subfield? Has anyone dealt with a similar problem?
Thanks,
Brodie
852 7_ |b gen |h J |i 27 |i .28 |t 1 |2 localCutter
(https://i-share.carli.illinois.edu/nby/cgi-bin/Pwebrecon.cgi?DB=local&v1=1&BBRecID=696369) for the record)
I have modified the MARC translator to look for this field by adding the following to MARC.js:
this._associateDBField(item, "852", "khim","callNumber");
The problem, however, is that in the 852 example above, subfield "i" is repeated. This is not uncommon in our catalog records. Unfortunately, Zotero only grabs the first subfield, and ignores the second one. In this case, you end up with "J 27" in Zotero.
I'm not a developer, and don't know Javascript that well, but I know enough to poke around in the code. It appears to me that Zotero uses an array whose length is based on the number of subfields that have been passed to the _associateDBField function (ie in this case four).
Is there a way to tell the _associateDBField to loop through multiple references to the same subfield? Has anyone dealt with a similar problem?
Thanks,
Brodie
Please test.