Updating Version : This ENH will be for Koha 3.8

Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)

Created attachment 8028 [details] [review]
[SIGNED-OFF] Bug 6851 - script to set the MARC leader for resources with analytics

This will find records that have a 773$w record that points to something
else. For these, it will set the MARC leader position 19 value to 'c'.

It will also find records that have a 001 value that is pointed to by
another record's 773$w. For these, it sets the leader position 7 to 's'.

With these set, Koha knows to present the links in the details views to
connect the resources.

Note: this is intended to be a post-migration script, in case your
imported records had incomplete headers.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>

Hi Robin, 

I was looking at your patch and had to make some notes for myself to 'unwrap' the relationships for myself. If my tests are correct, your script changes every record with childs into a serial AND a set. Most of the time those are 2 different things and it perhaps depends on what the library intended to do. After running your script my parent records show both links: show volumes and show analytics. When using Usecontrolnumber those will be the same (see bug 7609). Perhaps it would make sense to decide to either make the records a set or a serial and mark the child records correspondingly:

I. Sets and volumes

Set record: leader pos 19 = a = Set (http://www.loc.gov/marc/bibliographic/bdleader.html)
A set record will show a link to the volumes.
Link: search for 001 of set record in $w of child records (rcn index).

Volume record: leader pos 19 = c = Part with dependent title (http://www.loc.gov/marc/bibliographic/bdleader.html)
A volume record will show a link to the set.
Link: search for $w in 001 to find the set record (Control-number index).

II. Serial records and analytics

Serial record: leader pos 7 = s = Serial (http://www.loc.gov/marc/bibliographic/bdleader.html)
A serial record will show a link to search for analytics.
Link: search for 001 in $w to find the analytical records (rcn index).

Analytical record: Has 773, and leader pos 7 = a or b = monographic or serial component part (http://www.loc.gov/marc/bibliographic/bdleader.html)
A analytical record will show a link to the parent using information from 773.
Link: search for $w in 001 to find the serial record. (Control-number index).

The other thing is that I think this needs a big warning sign. It rewrites a lot of data and perhaps it would be cool to have a confirmation flag or something. I know it's in the folder for migration scripts, perhaps only being super careful here. 

Both things are not enough for me to fail - going to sign-off.

I think I basically reverse engineered Koha to get the effect I wanted.

QA Comment:
1) General: I agree with Katrin that this script should be handled with care. In that aspect I would recommend to use some command line option(s) for actually making the change. Just running without options could print usage information, just like many other admin scripts do.
As a side-note, I would be interested in a dry run option: How many records would you change before confirming to change them? (But that could be a followup, of course.)

2) I can understand that you may want to run this change on your data. But could the parent not be a collection too, or even an integrating resource (just mentioning two other possibilities in leader pos 7)? What about pos 19 on the parent site? As for the child, why per se value c on pos 19? Couldn't it be b (indep. title)? You don't touch pos 7 on the child, but is it already good?
If you would like this script to be more generic, it should offer probably more options. If it is so very specific, is that clear enough now? Just asking ;)

3) You use ModBiblioMarc and mention this in a comment. Just glancing through code, I have the impression that we loose framework on the record. Am I right?

4) Why do you delete the hash key from $ctrl_to_bib in the second while loop? If you would reach a second child record pointing to that parent, don't you want to update it as well?

Changing status to reflect the need for at least some answers. Thanks.

1) Dry run options can certainly be possible.

2) Regarding the variety of different collection types, that's definitely something that could be considered. Mostly, I wrote it for a specific case that I had. Allowing it to be smart would add a whole host of complexity that would have made it take a lot longer to implement. Mostly, it's aimed as a starter for people who have similar use cases to improve upon. In my case, I had records from another (non-MARC) system that were linked via 001 and 773$w, but the leader had nothing to say that they were collections, and so Koha didn't show them up as such. This lets at least a basic level of linking happen. If you're in a position to determine what specific collection types you have, odds are you records are a lot cleaner than the ones I had anyway and probably include that information.

3) Losing the framework information might occur, I'm not sure. It wasn't an issue in my situation so I didn't check.

4) That hash is only used to track the parents we need to update, it doesn't have anything to do with the children. Once a parent has been updated once, there is no need to touch it again.

Robin, referring to your comments:

1) Could you add at least an update option or so to prevent "accidents" for now? Dry run would be nice for future development.

2) I understand. 

3) Please check. This could be an issue.

4) You are right, of course. Thanks for clarifying.

Just a side note: I stumbled over some tabs instead of spaces. Some people do not like them ;)

It's an annoying vim bug I haven't found a way to fix. I think this was written before I habitually perlcritic'ed everything.

Would that script still be useful?
(Latest activity on this Bug 2012-03-08 )

I think it could still be useful, but not sure it should still be assigned to Robin.