Bug 21705 - Map copyrightdate to both 260/264c by default for new MARC21 installations
Summary: Map copyrightdate to both 260/264c by default for new MARC21 installations
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: MARC Bibliographic data support (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Caroline Cyr La Rose
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-28 18:25 UTC by Katrin Fischer
Modified: 2023-12-28 20:42 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This enhancement adds a default mapping from 264c to biblio.copyrightdate for MARC21. Previously, it was only mapped to 260c. Now it is mapped to both. **This only affects new installations. For current installations, you need to add it manually through Administration > Koha to MARC mapping.
Version(s) released in:
22.11.00


Attachments
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations (2.15 KB, patch)
2021-12-02 22:59 UTC, Caroline Cyr La Rose
Details | Diff | Splinter Review
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations (2.15 KB, patch)
2022-10-05 19:04 UTC, Caroline Cyr La Rose
Details | Diff | Splinter Review
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations (2.20 KB, patch)
2022-10-05 19:46 UTC, David Nind
Details | Diff | Splinter Review
Screenshots - Display of 260c (has a label) and 264c (has no label) (78.49 KB, application/pdf)
2022-10-05 20:05 UTC, David Nind
Details
Bug 21705: Map copyrightdate to both 260/264c by default for new MARC21 installations (2.29 KB, patch)
2022-10-07 06:15 UTC, Marcel de Rooy
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2018-10-28 18:25:27 UTC
It's a bit of a pain to fix when you don't change the mapping right away and deal with both RDA and non-RDA records still. It would be nice to have both mapped by default in the Koha-to-MARC-Mappings.
Comment 1 Caroline Cyr La Rose 2021-12-02 22:59:26 UTC
Created attachment 128186 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline
Comment 2 David Nind 2021-12-04 07:20:05 UTC
Hi Caroline.

I'm not seeing copyrightdate in steps 6 and 7.

The database query I used was (where XXX = the newly created record number): select * from biblioitems where biblionumber = XXX;

Both mappings for biblio.copyrightdate appear in  Koha to MARC mappings.

Note: For step 5 I'm assuming biblioitems.publishercode should be biblio.copyrightdate.

David
Comment 3 David Nind 2021-12-04 07:45:13 UTC
I changed the assignee to Caroline.
Comment 4 Caroline Cyr La Rose 2022-10-05 19:03:42 UTC
Hi David, 

I think you were misled by my test plan. I copy-pasted from another one and forgot to change everything I should have... I'm rewriting the test plan and hopefully I won't make any more mistakes...

Caroline
Comment 5 Caroline Cyr La Rose 2022-10-05 19:04:32 UTC
Created attachment 141394 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:

1. Apply patch
2. Delete existing frameworks
2.1. In the database, run the following commands
delete from marc_tag_structure;
delete from marc_subfield_structure;
delete from biblio_framework;
3. Load default framework
3.1. In a terminal, run
./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4. In the staff interface, go to Administration > MARC bibliographic framework
--> The default framework should be there
5. Make 264c appear in the editor
5.1. In Administration > MARC bibliographic framework, click on Actions > MARC structure next to the default framework
5.2. Search for 264
5.3. Click on Actions > Edit subfields
5.4. Click on tab c
5.5. Check the 'Editor' box 
5.6. Click 'Save changes'
6. In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
6.1. Go to Administration > Koha to MARC mapping
6.2. Search for copyrightdate
--> biblio.copyrightdate should be mapped to 260c as well as 264c
7. Create a bibliographic record with a value in 264c
7.1. Go to Cataloging
7.2. Click 'New record'
7.3. Fill in mandatory fields (000, 003, 005, 008, 040c, 245a, 942c)
7.4. Enter a date in 264c
7.5. Click 'Save'
7.6. Note the record number (no need to add an item)
8. Create a bibliographic record with a value in 260c
8.1. Go to Cataloging
8.2. Click 'New record'
8.3. Fill in mandatory fields (000, 003, 005, 008, 040c, 245a, 942c)
8.4. Enter a date in 260c
8.5. Click 'Save'
8.6. Note the record number (no need to add an item)
9. Check the database biblio entry for both records, they should both have a value for copyrightdate
9.1. In the database, enter the following query, replacing AA with your biblionumber from step 7.6 and BB with the biblionumber from 8.6
select biblionumber, copyrightdate from biblio where biblionumber in (AA, BB)
--> Both biblios should have a date in copyrightdate

I hope I didn't forget anything! :)

Caroline
Comment 6 David Nind 2022-10-05 19:46:44 UTC
Created attachment 141400 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline

Signed-off-by: David Nind <david@davidnind.com>
Comment 7 David Nind 2022-10-05 20:05:40 UTC
Created attachment 141402 [details]
Screenshots - Display of 260c (has a label) and 264c (has no label)

(In reply to Caroline Cyr La Rose from comment #4)
> Hi David, 
> 
> I think you were misled by my test plan. I copy-pasted from another one and
> forgot to change everything I should have... I'm rewriting the test plan and
> hopefully I won't make any more mistakes...
> 
> Caroline

Thanks Caroline for the comprehensive updated test plan! It made it very easy to test.

I've signed off, but did note that:

1. For step 7 with the 264c, the date I entered shows in the normal display (and the OPAC) as a date on its own line - without any label.

2. For step 8 with the 260c, the date I entered shows in the normal display after the label "Publication details".

See the attached screenshots. 

Also, I'm not sure why, but the commit message changed back to the original one when I signed it off (comment #6).

David
Comment 8 Caroline Cyr La Rose 2022-10-05 20:16:45 UTC
(In reply to David Nind from comment #7)
> 
> Thanks Caroline for the comprehensive updated test plan! It made it very
> easy to test.
> 
> I've signed off, but did note that:
> 
> 1. For step 7 with the 264c, the date I entered shows in the normal display
> (and the OPAC) as a date on its own line - without any label.
> 
> 2. For step 8 with the 260c, the date I entered shows in the normal display
> after the label "Publication details".
> 
> See the attached screenshots. 
> 

Yes, that is normal, it has to do with indicators. Since 264 can be used for more than publication (it can be used for production information, manufacture information, etc.) it needs to know what you are cataloguing in there exactly. If you want 'Publication', you need to write 1 in the second indicator https://www.loc.gov/marc/bibliographic/bd264.html


> Also, I'm not sure why, but the commit message changed back to the original
> one when I signed it off (comment #6).

Not sure either... I was sure I'd obsoleted the older patch... Maybe someone more used to bugzilla will be able to enlighten us
Comment 9 David Nind 2022-10-05 21:05:40 UTC
(In reply to Caroline Cyr La Rose from comment #8)

> Yes, that is normal, it has to do with indicators. Since 264 can be used for
> more than publication (it can be used for production information,
> manufacture information, etc.) it needs to know what you are cataloguing in
> there exactly. If you want 'Publication', you need to write 1 in the second
> indicator https://www.loc.gov/marc/bibliographic/bd264.html

Thanks Caroline! There is always something to learn with MARC21 and cataloguing...
Comment 10 Marcel de Rooy 2022-10-07 06:15:17 UTC
Created attachment 141475 [details] [review]
Bug 21705: Map copyrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment 11 Marcel de Rooy 2022-10-07 06:16:29 UTC
Please inform users of existing installations more explicitly via release notes about adding 264 too.
Comment 12 Caroline Cyr La Rose 2022-10-07 13:18:47 UTC
Hi Marcel,
I added release notes specifying it is only for new installations and where to add it for current installations.
Do you want me to also add a dbrev like in bug 30850?
Thanks!
Caroline
Comment 13 Marcel de Rooy 2022-10-10 06:44:23 UTC
(In reply to Caroline Cyr La Rose from comment #12)
> Hi Marcel,
> I added release notes specifying it is only for new installations and where
> to add it for current installations.
> Do you want me to also add a dbrev like in bug 30850?
> Thanks!
> Caroline

Let's see if our RM should insist..
Comment 14 Katrin Fischer 2022-10-10 06:49:00 UTC
Historically we haven't changed mappings on update and it's not enough anyway, as you would create an inconsistent state of the data: the mappings only work for the new records. So this could lead more to confusion than being actually helpful. If people want this, they also need to run the script to update existing data or be aware of the change. (
Comment 15 Marcel de Rooy 2022-10-10 06:58:47 UTC
(In reply to Katrin Fischer from comment #14)
> Historically we haven't changed mappings on update and it's not enough
> anyway, as you would create an inconsistent state of the data: the mappings
> only work for the new records. So this could lead more to confusion than
> being actually helpful. If people want this, they also need to run the
> script to update existing data or be aware of the change. (

True, but please read the context.
Comment 16 Katrin Fischer 2022-10-10 07:35:23 UTC
(In reply to Marcel de Rooy from comment #15)
> (In reply to Katrin Fischer from comment #14)
> > Historically we haven't changed mappings on update and it's not enough
> > anyway, as you would create an inconsistent state of the data: the mappings
> > only work for the new records. So this could lead more to confusion than
> > being actually helpful. If people want this, they also need to run the
> > script to update existing data or be aware of the change. (
> 
> True, but please read the context.

Ah, sorry... can we blame Monday morning?
Comment 17 Tomás Cohen Arazi 2022-10-17 20:48:22 UTC
Pushed to master for 22.11.

Nice work everyone, thanks!