Bug 6851 - A utility that will search out analytics records and set the MARC header appropriately
Summary: A utility that will search out analytics records and set the MARC header appr...
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Command-line Utilities (show other bugs)
Version: master
Hardware: All All
: P3 enhancement (vote)
Assignee: Robin Sheat
QA Contact: Marcel de Rooy
Depends on:
Reported: 2011-09-07 02:44 UTC by Robin Sheat
Modified: 2018-01-08 10:25 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:

Bug 6851 - script to set the MARC leader for resources with analytics (5.35 KB, patch)
2011-09-07 06:10 UTC, Robin Sheat
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 6851 - script to set the MARC leader for resources with analytics (5.39 KB, patch)
2012-03-06 07:02 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Sheat 2011-09-07 02:44:15 UTC
In some cases, generated MARC data may not contain the correct headers to indicate sets (and parts of.) So I need to make a tool to fix this. It'll look at the 773$w headers to work out what needs to be linked.
Comment 1 Robin Sheat 2011-09-07 06:10:09 UTC Comment hidden (obsolete)
Comment 2 Paul Poulain 2011-10-24 11:38:16 UTC
Updating Version : This ENH will be for Koha 3.8
Comment 3 Paul Poulain 2011-10-25 15:05:50 UTC
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)
Comment 4 Katrin Fischer 2012-03-06 07:02:38 UTC
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>
Comment 5 Katrin Fischer 2012-03-06 07:03:05 UTC
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.
Comment 6 Robin Sheat 2012-03-07 23:08:55 UTC
I think I basically reverse engineered Koha to get the effect I wanted.
Comment 7 Marcel de Rooy 2012-03-08 08:29:01 UTC
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.
Comment 8 Robin Sheat 2012-03-08 09:04:42 UTC
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.
Comment 9 Marcel de Rooy 2012-03-08 09:41:54 UTC
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.
Comment 10 Marcel de Rooy 2012-03-08 13:42:58 UTC
Just a side note: I stumbled over some tabs instead of spaces. Some people do not like them ;)
Comment 11 Robin Sheat 2012-03-08 19:40:18 UTC
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.
Comment 12 Marc Véron 2016-05-23 15:19:38 UTC
Would that script still be useful?
(Latest activity on this Bug 2012-03-08 )
Comment 13 Katrin Fischer 2018-01-08 10:25:31 UTC
I think it could still be useful, but not sure it should still be assigned to Robin.