Re-sequence MARC fields by each tag when running a normalization rule
Currently, after running a normalization rule on a set of bib records, the bib records display the 5XX fields out of order, e.g. 500, 546, 506 etc. This occurs even after running the CnmarcBibReSequenceTask as fields between 500 and 899 are not sorted, or sorted only by hundreds (this was the information given to us by a member of staff when we reported the issue on the ExLibris Customer Portal).
Having all fields in the correct order would ease any future cataloguing needed on these records, or when staff members view the record for work purposes.
I've attached an example screenshot.
Catarina PB commented
Will all due respect Itai Veltzman , it is important for the 5xx, 6xx and 7xx fields to be in numerical order not only to follow the AACR2, RDA as Simon Hunt mentioned previously but also because as catalogers, this order makes our work easier as well as less chaotic for the user when searching information. It is for the purpose of time efficiency, easy to identify what's missing and what still needs to be added, etc~ So it's not about something bothering the catalogers, but making sure we can do our work efficiently, as well as to make it more practical. I can safely say that wasting my time searching for fields that should be in order anyway, is not on my priority list.
And one last thing, if the order didn't matter then there would be no need to order things by number at all; but ALAS, it is mentioned in the rules, we need it and it's a matter of uttermost importance.
Tamara Kemp commented
I would like to add my voice to this suggestion. We would like to see all fields grouped together in numerical order. So for Itai's example in the attachment, we would want to see both 506 fields appear together in the record so that a cataloger can quickly find the field. We have no need to have "new" fields grouped together at the bottom of the record when added at a later date. We need to see all fields collocated. We identified a work-around, but would like to see this functionality documented for Alma as well as a choice in how these fields sort.
Simon Hunt commented
What appears to be happening - both with a normalization job and when a record is merged while importing - is that "new" fields (those affected by the normalization, or fields being added to a record via import merge) are placed below the "old" or unaffected fields in the record.
For example, if your merge rules preserve the old 597 fields but replace all other 5XX fields, the final version of the bibliographic record displays the 597 field first.
In AACR2, there was a prescribed order of note fields that catalogers applied, including how to order notes in repeated 500 fields. RDA rules simply specify that note fields should be arranged in numeric order.
So, the placement of new/normalized fields at the bottom of the range violates both cataloging standards.
Gwion Dafydd commented
Yes, the main issue is that it needs to be in order so that our catalogers can find the specific fields quickly in order to do some editing work, especially if there's several 5XX, 6XX or 7XX fields within the bib record.
First we would like to make sure we understand the use case.
See our attached document in which we reproduce the workflow we believe you describe .
Is you main issue that when a record is open in the metadata editor with several 5XX , 6XX or 7XX fields they must be in numerical order so that a cataloger can quickly find specific fields?
If this is not the case then where exactly does it bother you that the fields within each 5XX , 6XX or 7XX group are not in numerical order?