[librecat-dev] sorting MARC fields

[Patrick Hochstenbach]

Can you create an issue for this and explain how you would like to see the MARC ordering implemented?
I’m now on a vacation for the next month and am busy to clean my inbox :)

> On 13 Jul 2017, at 12:47, Uldis Bojars <captsolo at gmail.com> wrote:
> 
> On 13 July 2017 at 12:13, Patrick Hochstenbach <Patrick.Hochstenbach at ugent.be> wrote:
> There is no sorting of MARC fields in the Fix language. One can add fields by `marc_add` fixes. The order of the new fields is in the order you execute the marc_add commands.
> 
> I am still trying to understand if sorting is needed (in our use case, at least):
> 
> One place where the MARC spec mention field order is this: "Control fields precede data fields in the record and are arranged in the same sequence as the corresponding entries in the directory."
> 
> https://www.loc.gov/marc/specifications/specrecstruc.html
> 
> If we assume that this is true and control fields should come before data fields, then adding control fields using 'marc_add' would result on MARC data that violate this assumption.
> 
> A quick fix [to avoid the need for sorting] here would be to allow inserting new fields before "100" field (= after the last control field).
> 
> With the marc_paste (the nephews of marc_copy and marc_cut) you can decide where in the record the new marc record should be pasted:
> 
>   # Paste mycopy after the last 300 field
>   marc_paste(mycopy, at:300)
> 
> https://metacpan.org/pod/Catmandu::Fix::marc_paste
> 
> This is a cool feature! :)
> 
> What would happen if there are no "300" fields in the record?
> 
> In general there is no condition how MARC records could be sorted. Marc tags can be repeated:
> 
>    500 $aZorro, this is my First note
>    500 $aAlso a nice not, but not the first
>    500 $aWell this is the last note
> 
> Sorting the notes will result in errors in the catalogging. MARC is not a table or database format but markup language ..
> 
> Agreed. If sorting were to be implemented it would need to preserve the order of the existing fields that have the same code.
> 
> Uldis
> 
> > On 13 Jul 2017, at 10:25, Uldis Bojars <captsolo at gmail.com> wrote:
> >
> > set_array(ok_fields, FMT, LDR,
> >     008, 040, 041, 075, 100,
> >     240, 245, 246, 260,
> >     377, 380, 388, 400, 490,
> >     600, 630, 650, 670, 677,
> >     700, 720, 908, 910)
> >
> > do marc_each()
> >
> >     copy_field(record.0.0, fld_type)
> >
> >     unless in(fld_type, ok_fields)
> >         remove_field(record)
> >     end
> >
> >     remove_field(fld_type)                  # is this needed?
> >
> > end
> >
> > remove_field(ok_fields)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.uni-bielefeld.de/mailman2/unibi/public/librecat-dev/attachments/20170713/17bc2aa3/attachment.asc>