Bug 32325 - Valid 006/00 values should not depend on Type of Material selection
Summary: Valid 006/00 values should not depend on Type of Material selection
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 32321
Blocks:
  Show dependency treegraph
 
Reported: 2022-11-22 19:09 UTC by Andrew Fuerste-Henry
Modified: 2022-12-07 17:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2022-11-22 19:09:51 UTC
In the 006 control field, the value in position 00 sets the "form of material" ("language material," "notated music," etc). That value informs the type of material configuration ("Books," "Computer files," etc).

For example, if the leader position 06 and the 006 position 00 are "m," then the material type should be "Computer files" and the other 006 positions and parts of the 008 should behave accordingly.
(https://www.loc.gov/marc/bibliographic/bd008c.html)

In both the regular and advanced cataloging editors, Koha shows one both the 006 position 00 value *and* the material type. That's handy, but Koha makes the material type manually editable rather than derived from the position 00 value. In fact, Koha forces position 00 to only allow one to enter values that match what you've selected for material type. So to change the value in position 00, one must first change the type of material.

Instead, one should be able to set 006/00 to any value allowed in the MARC specifications and that choice should set the Type of Material and thereby define how the rest of the 006 behaves.
Comment 1 Heather 2022-12-07 17:04:09 UTC
(In reply to Andrew Fuerste-Henry from comment #0)
> Instead, one should be able to set 006/00 to any value allowed in the MARC
> specifications and that choice should set the Type of Material and thereby
> define how the rest of the 006 behaves.

You are correct, Andrew!  An example could be creating a serial record for Mojo magazine (which comes with an audio CD every month).  E.g.:
Leader position 06 = a (language material)
--Coded for the "main" format of the paper magazine
006 position 00 = j (musical sound recording)
--Coded for the additional characteristics of the CD enclosed with every paper magazine issue
(You could also have an 007 for the CD characteristics, by the way.)

When one chooses this value "j" for the 006 position 00, it should set the rest of the 006 field options accordingly--and it does.

I can't think of an example of when the leader position 06 and the 006 position 00 would be the same--since the 006 is for "additional material characteristics," an 006 is used only when another type of material is present--if the title is all one sort of material, one doesn't need 006 or 007 field(s).

So:
> In both the regular and advanced cataloging editors, Koha shows one both the
> 006 position 00 value *and* the material type. That's handy, but Koha makes
> the material type manually editable rather than derived from the position 00
> value.

I think this is actually correct behavior.  The Leader 06, and the 006 00 will usually differ, so the 006 00 *should* be manually set by the cataloger.  The 006 00 should not be derived, IMO, because the whole point of adding an 006 is to bring out additional material characteristics present in the title not accounted for in the Leader and 008.

> In fact, Koha forces position 00 to only allow one to enter values
> that match what you've selected for material type. So to change the value in
> position 00, one must first change the type of material.

This actually isn't my experience. We're on 21.11, and I was able to create a new reocrd with a Leader & 008 coded for a textual serial and then set an 006 00 to "j" in both the advanced bib editor and the basic bib editor.

But maybe I'm misunderstanding the problem?  Or the problem's occuring in versions above 21.11?

Cheerio!
h2