[Koha-devel] MARC frameworks in Koha

[Christopher Davis]

Marcel,

Thank you for seeking input from the Koha Community before making this
decision. If I understand your message correctly, you are saying that if
the "Default" MARC framework has kohafield mappings which are configured to
pull copyright date from MARC 260$c *and* MARC 264$c, and if Koha sometimes
only "asks" for the kohafield mapping codes from the "Default" MARC
framework, then why rewrite the code to pull kohafield mappings from MARC
frameworks other than "Default" if the mappings of the other frameworks are
identical to "Default's" mappings (i.e., MARC 260$c *and* MARC 264$c). Is
this correct?

In answer to your question, I think that prudence demands that we rewrite
the code. For example, if the records with MARC framework "A" were
cataloged according to AACR2 standards (copyright recorded in MARC 260$c)
and the records using framework "B" were according to RDA (copyright in
264$c), then a code rewrite would be necessary. My library has both AACR2
MARC records and RDA MARC records, so, for the time being, as long as Koha
can displays the copyright information from both MARC 260$c *and* 264$c,
I'm happy. When the day comes, however, when Koha will finally index
non-MARC metadata records such as Dublin Core and BIBFRAME, It would be
wise to have the code always "ask" for what bibliographic framework a
record uses.

Thanks for listening,


Christopher Davis
Systems & E-Services Librarian
Uintah County Library
cgdavis at uintah.utah.gov
(435) 789-0091 <14357890091> ext.261
uintahlibrary.org
basinlibraries.org
facebook.com/uintahcountylibrary
instagram.com/uintahcountylibrary


On Mon, Aug 7, 2017 at 4:51 PM, Jesse <pianohacker at gmail.com> wrote:

> I can't respond to the librarian part of this, but I strongly agree as a
> developer. To make things worse, I believe there are _tiny parts_ of Koha
> that respect the per-framework mappings, leading a librarian into a false
> sense of hope.
>
> +1 to removing per-framework mappings in the UI and code.
>
> 2017-08-07 7:12 GMT-06:00 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>:
>
>> Hi developers or librarians,
>>
>>
>>
>> If you are interested in say sorting search results or lists by
>> publication date based on 260 and RDA 264, please read further.
>>
>> OR If you use varying kohafield mappings across your MARC frameworks. Say
>> you connected biblio.copyrightdate to 260$c in framework A, but to 264$c in
>> framework B.
>>
>>
>>
>> Bug 10306 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1
>> 0306) is aimed to resolve the issue of having the copyrightdate in two
>> MARC fields.
>>
>> It allows you to have multiple mappings per kohafield. So you can connect
>> 260c and 264c to copyrightdate. Current Koha allowed you to add the second
>> mapping already in the frameworks, but it silently ignores one of the two.
>>
>>
>>
>> In finishing this development however, I got stuck at the following
>> question: Should Koha really allow varying kohafield mappings per
>> framework? In the above example the multiple mappings feature should
>> resolve the need of having a different assignment for copyrightdate between
>> framework A and B. Both could simply have two mappings for copyrightdate.
>>
>> Although Koha more or less allows you to add kohafield assignments per
>> framework via the MARC frameworks, it does not really support kohafields
>> per framework. (The Koha to MARC mappings tool in Administration does
>> change the mappings in Default and copies them to other frameworks.) We
>> have GetMarcFromKohaField calls in the codebase that do not pass a
>> framework code. And when we process search results or import records, we do
>> not have a framework code either. So in those cases Koha just uses the
>> kohafield mappings from the Default framework, although you might have
>> specified another mapping in the associated framework of a search result.
>>
>>
>>
>> I would propose now to make the decision that we only use one set of
>> kohafield mappings (those from Default), and that we do no longer allow
>> changes to kohafield mappings in the other frameworks.
>>
>> The possibility of adding multiple mappings per kohafield hopefully
>> removes most objections to that approach as illustrated in the frameworks A
>> and B example.
>>
>>
>>
>> I submitted my changes so far on the Bugzilla report. If we agree on
>> Default as the authoritative framework for these mappings, I will still add
>> code to change GetMarcFromKohaField calls etc.
>>
>>
>>
>> If you have stringent reasons for maintaining varying kohafield mappings
>> per framework and your need for them cannot be resolved with multiple
>> mappings, please respond and provide information about the fields you are
>> mapping differently across your frameworks.
>>
>>
>>
>> Any other feedback is welcome too.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Marcel
>>
>>
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha-community.org
>> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
>> website : http://www.koha-community.org/
>> git : http://git.koha-community.org/
>> bugs : http://bugs.koha-community.org/
>>
>
>
>
> --
> Jesse Weaver
>
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20170808/13381f3a/attachment-0001.html>