[Bug 35095] New: Bibliographic record from local title only has 245$a
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Bug ID: 35095 Summary: Bibliographic record from local title only has 245$a Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha@gmail.com Reporter: caroline.cyr-la-rose@inlibro.com CC: jonathan.druart+koha@gmail.com, jonathan.field@ptfs-europe.com, martin.renvoize@ptfs-europe.com, matt.blenkinsop@ptfs-europe.com, pedro.amorim@ptfs-europe.com The manual says that when creating a local title in the ERM module, a bibliographic record is created with the values from the form being mapped to MARC fields. https://koha-community.org/manual/22.11/en/html/erm.html#create-a-new-local-... This is what it says
When you save the title, Koha will also automatically create a bibliographic record for you with as much of the metadata as possible. We map the KBART metadata to MARC21 in the following way: - publication_title = biblio.title print_identifier = 020$a||020$z||022$a||022$y online_identifier = 020$a||020$z||022$a||022$y date_first_issue_online = 866$a (before ‘-‘) date_last_issue_online = 866$a (after ‘-‘) num_first_vol_online = 863$a (before ‘-‘) num_last_vol_online = 863$a (after ‘-‘) title_url = 856$u first_author = biblio.first_author coverage_depth = title_url ? ‘fulltext’ : ‘print’ notes = $852$z publisher_name = 260$b
However, only the title is actually transferred to the bibliographic record. To recreate: 1. Enable ERMModule 2. Go to E-resource management > e-Holdings > Local > Packages 3. Click New package 4. Enter a package name 5. Click Submit 6. Go to e-Holdings > Local > Titles 7. Click New title 8. Fill out all the fields 9. Click Add to another package 10. Choose the package created previously 11. Click Submit 12. Click the title in the list 13. Click Local bibliographic record (next to Publication title) --> Note the record only has a title 14. Click MARC --> Only tabs 0 and 2 have information, leader and 245$a I don't know if this is by design or not. If it is, the manual should be amended to reflect the reality. If it's a bug, it needs to be fixed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32782 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #1 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- It seems store() in Koha/ERM/EHoldings/Resource.pm is only handling correct (full fields) biblio creation if titles are imported from a list. If the title is created and then linked to a package, only 'biblio.title' => $title->publication_title is passed, because there is no biblio linked to the title at that point. In other words: - If the local title is created from a list, biblio fields are mapped to the local title fields fully. - If the local title is created manually (then linked to a package), it only maps the publication_title to the created biblio. I don't think this is intended behavior, it feels like it should map everything in both situations. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=35115 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #2 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Pedro Amorim from comment #1)
In other words: - If the local title is created from a list, biblio fields are mapped to the local title fields fully.
While testing this I discovered bug 35115. It appears that the fields are mapped to the local title fields fully. However, the biblio MARC data gets stripped from the biblio itself. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #3 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 157504 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=157504&action=edit Bug 35095: [WIP] Add kbart to koha biblio mapping Original code was relying on marc_record coming from a biblio, but when first creating a eholding local title, there is no biblio. As such, we must get koha fields kbart equivalents, transform those koha fields to a marc_record, and finally AddBiblio using that same marc_record. Test plan: 1. Enable ERMModule 2. Go to E-resource management > e-Holdings > Local > Packages 3. Click New package 4. Enter a package name 5. Click Submit 6. Go to e-Holdings > Local > Titles 7. Click New title 8. Fill out all the fields 9. Click Add to another package 10. Choose the package created previously 11. Click Submit 12. Click the title in the list 13. Click Local bibliographic record (next to Publication title) --> Note the record only has a title 14. Click MARC ORIGINALLY:--> Only tabs 0 and 2 have information, leader and 245$a NOW: Notice that fields 100, 110 and 500 also have information This is a WIP, more mapping required." -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #4 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- @Jonathan Druart could use your help here. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #5 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 157505 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=157505&action=edit Bug 35095: Rearrange marc_record code if there is a biblio -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #6 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Hi Pedro, Is this bug NSO? In the comment you say this is a WIP, and more mapping is required. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #7 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Caroline Cyr La Rose from comment #6)
Hi Pedro, Is this bug NSO? In the comment you say this is a WIP, and more mapping is required.
Hi Caroline, I've set it as NSO in an attempt to get more eyes on it as I've gone as far as I can. I don't feel strongly about the status of the bug, so please feel free to set it differently! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #8 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Hi Pedro, Here are the mappings I'm thinking of for the fields in the interface to the fields in biblio/biblioitems and MARC21. I also found the list of KBART fields (I thought it was not very easy to find on their website...) https://groups.niso.org/higherlogic/ws/public/download/16900/RP-9-2014_KBART... starting on page 19, so I added those in the list too. Publication title: publication_title = 245$a (biblio.title) Print-format identifier: print_identifier = 020$a (biblioitems.isbn) for books or 022$a (biblioitems.issn) for serials Online-format identifier: online_identifier = 020$a (biblioitems.isbn) for books or 022$a (biblioitems.issn) for serials Date of first serial issue available online: date_first_issue_online = 008/07-10 (not mapped to db) and 362$a (not mapped to db) before the "-" or 363$i (not mapped to db) ; for serials only Number of first volume available online: num_first_vol_online = 362$a (not mapped to db) before the "-" or 363$a (not mapped to db); for serials only Number of first issue available online: num_first_issue_online = 362$a (not mapped to db) before the "-" or 363$b (not mapped to db); for serials only Date of last serial issue available online: date_last_issue_online = 008/11-14 (not mapped to db) and 362$a (not mapped to db) after the "-", should be in the same 362$a as the "first" or 363$i (not mapped to db), should be in a different 363 than the "first"; for serials only Number of last volume available online: num_last_vol_online = 362$a (not mapped to db) after the "-" should be in the same 362$a as the "first" or 363$a (not mapped to db), should be in a different 363 than the "first"; for serials only Number of last issue available online: num_last_issue_online = 362$a (not mapped to db) after the "-" should be in the same 362$a as the "first" or 363$b (not mapped to db), should be in a different 363 than the "first"; for serials only Title-level URL: title_url = 856$u (biblioitems.url) First author: first_author = 100$a (biblio.author); for books only Embargo information: embargo_info = this one I'm not sure, but probably 506$a (not mapped to db), although the KBART data seems very structured whereas the MARC21 field is a free entry field Coverage depth: coverage_depth = this one I'm not sure either... I looked but can't really find one field that encompasses what is described in the KBART document. Could be 008/24-27 (which is a letter code representing the contents). In doubt, I would put it in 500$a (biblioitems.notes). Someone else may be able to guide us here... Notes: notes = 500$a (biblioitems.notes) Publisher name: publisher_name = 260$b (biblioitems.publishercode) or 264$b (biblioitems.publishercode) Publication type: publication_type = 000/07 (m for monograph or s for serial), KBART only gives those two options even if there is an extensive list in Koha Date the monograph is first published in print: date_monograph_published_print = 008/07-10 (not mapped to db) or 264$c (biblio.copyrightdate); for books only? Date the monograph is first published online: date_monograph_published_online = 008/07-10 (not mapped to db) or 264$c (biblio.copyrightdate); for books only? Number of volume for monograph: monograph_volume = 490$v?... seems weird to me to have a volume without a collection title (biblioitems.volume ); for books only? Edition of the monograph: monograph_edition = 250$a (biblioitems.editionstatement); for books only? First editor: first_editor = probably 700$a if it's a person (not mapped to db), with "edt" in $4; for books only Title identifier of the parent publication: parent_publication_title_id = not sure but probably 773$z for books (not mapped to db); for books only Title identifier of any preceding publication title: preceding_publication_title_id = not sure, but probably 780$z (not mapped to db); for serials only Access type: access_type = 506 ind1 (not mapped to db) 0 for Open access, 1 for fee-based, could also be something else, like 506$f in combination with $2 Note that these aren't definitive and anyone is free to correct or add to them. I don't pretend to know everything, especially when it comes to MARC!! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Is this a duplicate of bug 32783 now? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32783 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #10 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- *** Bug 32783 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #11 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- (In reply to Katrin Fischer from comment #9)
Is this a duplicate of bug 32783 now?
Yes. Thanks! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #12 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi Caroline, thank you for the mapping info. I believe, ideally, we'd stick to koha fields instead of direct MARC fields, as this way we're able to use TransformKohaToMarc and I think that handles the MARC flavour for us. Inserting MARC fields here directly may open a can of worms in regards to MARC flavour. I'm not sure here. Thoughts? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- kohafields could be very limiting, there is a lot of things we don't have fields in biblio/biblioitems for or no good default mappings. Example: Date the monograph is first published in print: date_monograph_published_print = 008/07-10 (not mapped to db) or 264$c (biblio.copyrightdate); for books only? Without the 008 the date range search won't work for these records. Publication type: publication_type = 000/07 (m for monograph or s for serial), KBART only gives those two options even if there is an extensive list in Koha Having the right material type would be very helpful, but probably is also not covered. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #14 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- I'm in favour of mapping all the fields to the marc record but I understand that it is not ideal from the code standpoint. I just think it's a shame that staff would enter all this information in this form and not have it anywhere else than in the ERM module. If they want to have it also in the catalog, they would have to enter it twice. Could we maybe flip it around and enter the information in a cataloging framework and map that to the kbart form? I want to mention however that I have never managed electronic resources in any ILS when I worked in a library and so far none of our clients have this (we update them only on .05.04 or .05.05, they will be getting 23.05.05 later this fall) so I don't really have any "real world" use experience... Please take my comments with a grain of salt... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #15 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi Katrin and Caroline, below is closely related to bug 35115 but still applies here. There are 2 scenarios that I'm seeing: 1) the eholding title was imported from a list of biblios (biblio existed before the eholding title, may have a lot of MARC info) 2) the eholding title is created and added to a package, this prompts a biblio to be created from the eholding title info, the only MARC the biblio has at this point comes from the data in the eholding title, not a lot of MARC info) The current problem is that when a eholding title is saved, it'll update the MARC of its currently linked biblio (currently is doing this badly, overwriting the linked biblio's MARC), regardless if the biblio originated from a list or if it was created from the eholding title. Possible solution: 1) have all the MARC mappings in place to create the biblio when the eholding is manually created with as much MARC data as possible 2) dont do any changes to the biblio when eholdings title are created from a "import from biblio list" 3) dont do any changes to the biblio when eholdings title is updated (this means that post edits to the eholdings title are not reflected to the linked biblio) Another possible solution would be to prevent the edit of a eholding title if it has a linked biblio, and update the eholding title only when the biblio is updated from the MARC framework UI, but this also has issues because not all fields have mapping (see bug 32782), i.e. some eholding title fields would not be editable this way. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Koha Team University Lyon 3 <koha@univ-lyon3.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |koha@univ-lyon3.fr --- Comment #16 from Koha Team University Lyon 3 <koha@univ-lyon3.fr> --- Hi, first comment: don't forget unimarc users please! BZ32782 has been pushed, so I hope it wouldn't be an issue to add an unimarc -kbart mapping. Sonia -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.blouin@inlibro.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Maude <maude.boudreau@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maude.boudreau@collecto.ca -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com --- Comment #17 from Mathieu Saby <mathsabypro@gmail.com> --- Hi I realized this discussion can be linked with this bug I have just opened https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37306 It was about ISBN and ISSN, but the links I give could also be useful for improving and completing the mapping of other fields. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |esther.melander@bywatersolu | |tions.com --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- *** Bug 37503 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #19 from Koha Team University Lyon 3 <koha@univ-lyon3.fr> --- (In reply to Pedro Amorim from comment #15)
Hi Katrin and Caroline, below is closely related to bug 35115 but still applies here. There are 2 scenarios that I'm seeing: 1) the eholding title was imported from a list of biblios (biblio existed before the eholding title, may have a lot of MARC info) 2) the eholding title is created and added to a package, this prompts a biblio to be created from the eholding title info, the only MARC the biblio has at this point comes from the data in the eholding title, not a lot of MARC info)
The current problem is that when a eholding title is saved, it'll update the MARC of its currently linked biblio (currently is doing this badly, overwriting the linked biblio's MARC), regardless if the biblio originated from a list or if it was created from the eholding title.
Just personal thoughts, but I'm not sure to have all the elements: If the eholding title updates the Marc title : if it's from a Koha list, it's useless but not a problem as it's the same record, so the same data? If eholding title updates the marc title from a kbart file, I would say that it's better to upade it. I'm not totally sure because Marc record could be better but if the kbart file is the reference, we should do that. For a new "manual" creation of a local title, it should not be link to an existing biblio ? Better: have an option (more system preferences !) to choose if marc title is updated regarding the case. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #20 from Mathieu Saby <mathsabypro@gmail.com> --- Just an idea : I discover a new feature in 24.05 : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31791 Add the ability to lock records to prevent modification through the Koha staff interface Would it be interesting to use it, in order to protect records imported from kbart ? (Ideally, we would like to improve this functionality, which currently only allows you to block any changes to the records for a given source. It could allow certain modifications to be authorised. For example, for records from KBART, we could modify the title field, or add note fields, but not modify the ISBN, ISSN or URL.) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Pedro Amorim <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |januszop@gmail.com --- Comment #21 from Pedro Amorim <pedro.amorim@openfifth.co.uk> --- *** Bug 39524 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #22 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 180411 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180411&action=edit Bug 35095: [POC] Bibliographic record created from local ERM title/KBart file contains only the title According to the manuals page for ERM (https://koha-community.org/manual/24.11/en/html/erm.html#create-a-new-local-...), a local bibliographic record with basic fields taken from ERM resource information (publication_title, print_identifier, online_identifier, date_first_issue_online, date_last_issue_online, num_first_vol_online, num_last_vol_online, title_url, first_author, coverage_depth, notes, publisher_name) could be created. However, it seems that a bibliographic record created either from a KBart file line, or from an ERM resource info entered by hand contains only the title (cf. Koha::ERM::EHoldings::Title->store). Attached is a POC how one could enrich the record. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180411|0 |1 is obsolete| | --- Comment #23 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 180418 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180418&action=edit Bug 35095: [POC] Bibliographic record created from local ERM title/KBart file contains only the title According to the manuals page for ERM (https://koha-community.org/manual/24.11/en/html/erm.html#create-a-new-local-...), a local bibliographic record with basic fields taken from ERM resource information (publication_title, print_identifier, online_identifier, date_first_issue_online, date_last_issue_online, num_first_vol_online, num_last_vol_online, title_url, first_author, coverage_depth, notes, publisher_name) could be created. However, it seems that a bibliographic record created either from a KBart file line, or from an ERM resource info entered by hand contains only the title (cf. Koha::ERM::EHoldings::Title->store). Attached is a POC how one could enrich the record. It covers not only KBart import but also manual ER title creation. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 Adolfo Rodríguez Taboada <adolfo.rodriguez@xercode.es> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adolfo.rodriguez@xercode.es --- Comment #24 from Adolfo Rodríguez Taboada <adolfo.rodriguez@xercode.es> --- Created attachment 199901 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199901&action=edit Complete field mapping Hello, this patch supersedes the POC in attachment 180418. It covers the same approach (direct MARC construction) with complete field mapping for all KBART fields and adds an UPDATE path for existing linked records. The update only runs when the user explicitly checks "Update bibliographic record". Maybe in a different patch, it could be modified to exclude the option to "Update bibliographic record" when it was imported from a list. But that's another story. I think we should focus now on the field mapping. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 --- Comment #25 from Mathieu Saby <mathsabypro@gmail.com> --- I did not look at your code, but if this bug is moving somewhere could you please take a look at Bug 37306 (print identifier should be in 776) and give us your opinion? If the idea is approved maybe it could be incorporated into this ticket? -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org