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=10306) 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
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@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=10306) 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@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
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@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@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@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@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@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/
Thank you for seeking input from the Koha Community before making this decision.
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. Marcel
Marcel, Thank you for clarifying my understanding. It sounds like Koha will simultaneously pull and display copyright date information from more than one MARC subfield and that's great. What would happen if a MARC record only has, for example, a 264$c and no 260$c? Will Koha throw an error if it encounters scenarios like this? I hope that those questions do not sound stupid. As far as non-MARC data is concerned, if Koha can pull copyright date from two MARC subfields, then it stands to reason that it could pull the date from two MARC subfields and a Dublin Core field/element, yes? Regards, Christopher Davis Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov (435) 789-0091 <14357890091> ext.261 uintahlibrary.org basinlibraries.org facebook.com/uintahcountylibrary instagram.com/uintahcountylibrary On Wed, Aug 9, 2017 at 5:34 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Thank you for seeking input from the Koha Community before making this decision.
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.
Marcel
_______________________________________________ Koha-devel mailing list Koha-devel@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/
Thank you for clarifying my understanding. It sounds like Koha will simultaneously pull and display copyright date information from more than one MARC subfield and that's great. What would happen if a MARC record only has, for example, a 264$c and no 260$c? Will Koha throw an error if it encounters scenarios like this? I hope that those questions do not sound stupid.
No problem. Koha will handle it fine. 264c and 260c will always be 'alternating'.
As far as non-MARC data is concerned, if Koha can pull copyright date from two MARC subfields, then it stands to reason that it could pull the date from two MARC subfields and a Dublin Core field/element, yes?
Yes, but I keep this thread to Koha<->MARC now. Obviously, we can pull other data too in some future scenario.
Hi Marcel and Christopher, maybe to explain this a bit more, Koha will already display all the information from 260 and 264 in the detail view and result lists, because in those views the full MARC record is used as the source for the displayed information. There are other, brief views, that pull information from the columns in the biblio and biblioitems tables only. The mappings define, how these columns are filled with information. For example the default mapping for copyrightdate is 260 at the moment. An example for a 'brief' view would be the list of records in the cart, or the information shown in the acquisitions module. Christopher got me thinking: For 260 and 264 are repeatable, as a side effect of cataloguing rule changes, they might even appear both in a record (even if they shouldn't). Which year will be given priority? For display purposes in the brief views, only one year should be displayed. I agree with the idea of making the mapping on the default framework the standard to use for all MARC records. If we support other formats at some point, we could add a default BIBFRAME or default Dublin Core mapping maybe? Katrin On 09.08.2017 16:05, Christopher Davis wrote:
Marcel,
Thank you for clarifying my understanding. It sounds like Koha will simultaneously pull and display copyright date information from more than one MARC subfield and that's great. What would happen if a MARC record only has, for example, a 264$c and no 260$c? Will Koha throw an error if it encounters scenarios like this? I hope that those questions do not sound stupid.
As far as non-MARC data is concerned, if Koha can pull copyright date from two MARC subfields, then it stands to reason that it could pull the date from two MARC subfields and a Dublin Core field/element, yes?
Regards,
Christopher Davis Systems & E-Services Librarian Uintah County Library cgdavis@uintah.utah.gov <mailto:cgdavis@uintah.utah.gov> (435) 789-0091 <tel:14357890091> ext.261 uintahlibrary.org <http://uintahlibrary.org> basinlibraries.org <http://basinlibraries.org> facebook.com/uintahcountylibrary <http://facebook.com/uintahcountylibrary> instagram.com/uintahcountylibrary <http://instagram.com/uintahcountylibrary>
On Wed, Aug 9, 2017 at 5:34 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl <mailto:M.de.Rooy@rijksmuseum.nl>> wrote:
> Thank you for seeking input from the Koha Community before making this decision.
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.
Marcel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel <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/ <http://bugs.koha-community.org/>
_______________________________________________ Koha-devel mailing list Koha-devel@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/
Christopher got me thinking: For 260 and 264 are repeatable, as a side effect of cataloguing rule changes, they might even appear both in a record (even if they shouldn't). Which year will be given priority? For display purposes in the brief views, only one year should be displayed.
TransformMarcToKoha already picks the first year from copyrightdate; this is not changed. In the new code it will handle fields sorted by tag. So 260 will be handled before 264. Within the same tag, it will handle fields based on their order in the MARC record itself. With 1950 in field 260 and 1960 in field 264, a string results like ‘1950 | 1960’. In case of copyrightdate the current logic of picking the first year (from 260 in this example) will be applied. So returning 1950. I assume that the example of a 260 and a 264 is rare, but I can imagine that there are multiple 264s in a RDA record. In that case it depends on the order of the 264s in the MARC.
I can't think of something better for now, thx for finding out and explaining! On 10.08.2017 10:33, Marcel de Rooy wrote:
Christopher got me thinking: For 260 and 264 are repeatable, as a side effect of cataloguing rule changes, they might even appear both in a record (even if they shouldn't). Which year will be given priority? For display purposes in the brief views, only one year should be displayed.
TransformMarcToKoha already picks the first year from copyrightdate; this is not changed. In the new code it will handle fields sorted by tag. So 260 will be handled before 264. Within the same tag, it will handle fields based on their order in the MARC record itself. With 1950 in field 260 and 1960 in field 264, a string results like ‘1950 | 1960’. In case of copyrightdate the current logic of picking the first year (from 260 in this example) will be applied. So returning 1950. I assume that the example of a 260 and a 264 is rare, but I can imagine that there are multiple 264s in a RDA record. In that case it depends on the order of the 264s in the MARC.
_______________________________________________ Koha-devel mailing list Koha-devel@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/
participants (4)
-
Christopher Davis -
Jesse -
Katrin -
Marcel de Rooy