Incorrect fixed fields pulled from 006 fields

[Jason Boyer]

Evergreen (All supported through at least 2.9)
Other versions irrelevant

The 008 fixed fields are dependent only on the Leader/06 value for record type, but both the 006 and 007 fixed fields define their fixed fields based on their first character position (006/00 = Form of Material, 007/00 = Category of Material). Currently all 006 fields in a record are treated as if the 006/00 represents the same form of material as the leader/06, which leads to any fixed fields not shared among all 006/00 values to be potentially incorrect.

Here's an example: http://evergreen.lib.in.us/eg/opac/record/5436532 this is a kit that has 5 006 fields, one Book form (006/00=a), one Music form (006/00=j), and three Visual Material forms (006/00=g,k).

To make it easy to look at them, attached are the 006's and MARC attributes for this record. To make sense of them you'll need to keep http://www.loc.gov/marc/bibliographic/bd006.html and http://www.loc.gov/marc/bibliographic/bd008.html handy.

The 006 that has a /00=a defines Ills=a, Conf=0, Indx=0, Fest=0, and Form=0, but what we're given is a TMat=0, which makes no sense. The /00=j field defines Comp, FMus, Part, AccM, LTxt, and TrAr, none of which are defined in evergreen currently (see bug 1371647 in progress) but it contributes nothing because VIS defines /01-03 to be Time which would be ppn, and the s that would be AccM is in the undefined block for VIS subfields.

I'm hoping this starts some discussion about how to go about fixing this, I don't know if it's necessary to go to the same lengths that we do to support the 007 but I don't personally see a better way since they both work so similarly.

[Jason Boyer (jboyer)]

Apologies for all of the OCLC FF abbreviations, but they do seem to be fairly well known among catalogers and LC doesn't seem to use any abbreviations. (I got no time for that...)

[Mike Rylander (mrylander)]

As you point out, right now, we use the type+blvl to decide how to read the 006 (inherited from the way we decide on the 008), but we otherwise have all the infrastructure to properly define the positions. I think all we need is to map the value in 006/00 to the type map (BKS,COM, etc) when pulling info from the 006, and everything will just work.

Looking at https://www.oclc.org/bibformats/en/fixedfield/006.html (yes, it's OCLC docs, but they use the same mnemonics we do ... because of reasons) we see that it should be trivial to "switch" the contextual record type when evaluating the 006.

I don't think this looks like a lot of code, really. In fact, because 's' is the old, deprecated code for SER in the LDR, and is the correct value for SER in the 006/00, we can just change the config.marc21_rec_type_map entry of type_val to be 'as'. The rest of the type_val values in that table already describe the correct mapping for the 006/00. We will need an order-by on the code column to make sure that 006/00=a is looked up correctly, but bad specs are bad. This has the benefit of always working for the record-wide value, and even expanding the reach to catch old, crufty records that use the deprecated 's' value.

We could make it config-dependent by adding a table that says "these tags carries their own record type value; also, use (or don't use) the type_val and/or blvl_val fields", and creating a simple function akin to vandelay.marc21_record_type(). But, I don't think that's necessary, really. We already embed lots of marc21 info in stored proc logic, and if we continue to cordon of that mess into functions with "marc21" in their names then we're no worse off WRT alternate formats down the road. (Also, same goes for the order-by stuff I mentioned above). We just see we're dealing with an 006 and do the right thing...

Thoughts?

[Mike Rylander (mrylander)]

And, FWIW, the reason that the 007 stuff is so much more complicated is that it's a 2-level hierarchy with labels mapped to particular positions. The 006 is much simpler, like the 008, and doesn't get the same fancy treatment with labels. They're different animals, IOW.

[Jason Boyer (jboyer)]

I hadn't realized why the 007 was so much worse, but now that makes much more sense. It does sound like almost everything can be limited to a couple of vandelay.marc21_extract_* functions without a lot of bending over backward. I agree there's no need to go all the way to having a config value for these types of fields (there's an upper limit to the number of MARC fields that act this way, and hopefully we're just about to hit it).

[Lindsay Stratton (lstratton)]

I think is a related problem... if a record was added with the incorrect record type and is later fixed to the correct type, the corresponding fixed field value boxes do do not update to reflect the correct set of values. For example, if a record is added as type book, but needs to be changed to type realia the realia-specific values do not appear.