> Thank you for seeking input from the Koha Community before making this
Thanks for responding :)
> 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?
Not sure if you fully got my point. I propose to always check kohafield
mappings from Default, and at the same time keep kohafield in all frameworks in
sync. This requires some code changes of course. New would be that a kohafield
may have two mappings. This approach would make Koha more consistent, since it
currently is somewhat ambiguous in this regard (also partly as a result of
having no frameworkcode in indexed records).
> 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.
We agree on the need for code changes. They are inspired by the fact that we
want to show copyrightdate from both 260 and 264. Since this is all about Koha
to MARC and vice versa, indexing other data is out of scope. But surely, it
needs proper attention in the future.
Koha-devel mailing list
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/