Bug 21321 - Use marc field 264 (when exists) to get (and show) information about place/name/date of production
Summary: Use marc field 264 (when exists) to get (and show) information about place/na...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Database (show other bugs)
Version: 17.11
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-06 12:58 UTC by Theodoros Theodoropoulos
Modified: 2019-10-14 19:56 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Theodoros Theodoropoulos 2018-09-06 12:58:07 UTC
The use of Marc field 264 (instead of 260) is currently promoted very much by LC because it is more flexible and versatile (also because it used by RDA). Many records downloaded from Library of Congress nowadays have all the place/name/date of production information only in 264.

Koha must take this into account when storing such information in various database tables (and consequently when displaying it in UI tables).

To give an example workararound scenario (maybe not the best, I'm just thinking out loud): one should check the presence of 264 and if found, it's data should take precedence when populating ie biblio.copyrightdate. If not, the current functionality (that uses 260) can still be used. This must be repeated for all new and modified bibs.
This implies changes to core Koha structure, so a relevant discussion might be required beforehand...

ps. Having said that, maybe the (gradual) use of biblio_metadata in all UI tables might give administrators the flexibility to be able to choose one marc field over the other in the UI tables for their installations, but at least the issue of this new field -and it's implications- must be known to the community... After all we will all come across it sooner or later!
Comment 1 Theodoros Theodoropoulos 2018-09-06 13:02:43 UTC
Of course 264 should be taken into account when indexing bibs in zebra/elasticsearch, but these were tackled already in BZ14198
Comment 2 Katrin Fischer 2018-10-28 18:24:12 UTC
Hi Theodorus.

I think this is a fixed issue. Newer versions of Koha allow you to map multiple fields to biblio.copyrightdate, which is used to display the publication year in a lot of places. So the field will be populated for RDA (264c) and for non-RDA  (260c) records.

When changing the mapping now, you might have to run a script to populate the data in your database, but this should better be discussed on the mailing list.
Comment 3 Katrin Fischer 2018-10-28 18:25:44 UTC
I've filed bug 21705 to improve the default behaviour.