[Bug 42532] New: Map biblioitems.ean to 024$a by default (MARC21)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 Bug ID: 42532 Summary: Map biblioitems.ean to 024$a by default (MARC21) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs@lists.koha-community.org Reporter: caroline.cyr-la-rose@inlibro.com QA Contact: testopia@bugs.koha-community.org There is an EAN field in biblioitems but it is not mapped to anything by default. I propose to map it to 024$a in new MARC21 installations. To recreate : 1. Make the following query in the database to see what is in 024$a and what is in biblioitems.ean select extractvalue(metadata, '//datafield[@tag="024"]/subfield[@code="a"]') as 024a, ean from biblio_metadata left join biblioitems using (biblionumber) where extractvalue(metadata, '//datafield[@tag="024"]/subfield[@code="a"]') != ''; --> Returns a list of numbers in 024a and NULL in ean 2. Just to make sure, run batchRebuildBiblioTeables.pl ./misc/batchRebuildBiblioTables.pl -c 3. Redo the query in step 1 --> Still nothing in ean -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Assignee|koha-bugs@lists.koha-commun |caroline.cyr-la-rose@inlibr |ity.org |o.com Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #1 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Created attachment 198646 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198646&action=edit Bug 42532: Map biblioitems.ean to 024$a by default (MARC21) This patch adds a link from 024$a to biblioitems.ean in the default bibliographic framework for MARC21 installations. To test: 1. Make the following query in the database to see what is in 024$a and what is in biblioitems.ean select extractvalue(metadata, '//datafield[@tag="024"]/subfield[@code="a"]') as 024a, ean from biblio_metadata left join biblioitems using (biblionumber) where extractvalue(metadata, '//datafield[@tag="024"]/subfield[@code="a"]') != ''; --> Returns a list of numbers in 024a and NULL in ean 2. Just to make sure, run batchRebuildBiblioTeables.pl ./misc/batchRebuildBiblioTables.pl -c 3. Redo the query in step 1 --> Still nothing in ean 4. Apply patch and reset_all 5. redo steps 2 and 3 --> ean is now filled -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This enhancement links the release notes| |biblioitems.ean database | |field to the 024$a MARC | |field in MARC21 | |installations. | | | |Note that this only applies | |to *new* installations. If | |you have an existing | |installation and wish to | |link biblioitems.ean to | |024$a, go to Administration | |> Koha to MARC mapping and | |add 024,a to | |biblioitems.ean. You will | |then need to run | |batchRebuildBiblioTables.pl | |. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #2 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- I think this might require a change to misc4dev for KTD after it is pushed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Hmm that's an interesting one. Unfortunately, it would only make sense if the first indicator in 024 is "3". There's lots of 024$a that wouldn't make sense in biblioitems.ean. But we don't have that type of granularity when it comes to mappings. Hmm.... I think this could be useful on a case by case basis but not by default :/ -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #4 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- In that case, 520a should not be mapped by default to biblio.abstract since the abstract is only if 520 ind 1=3. And biblioitems.illus is mapped by default to 300b but 300b can be other things that illustrations, esp. for things other than books. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #4)
In that case, 520a should not be mapped by default to biblio.abstract since the abstract is only if 520 ind 1=3. And biblioitems.illus is mapped by default to 300b but 300b can be other things that illustrations, esp. for things other than books.
Well the "Abstract" constant is used for ind 1=3. I think an argument could be made for biblio.summary being better than biblio.abstract but that might be splitting hairs. Yeah... biblioitems.illus is not great. I don't know why we actually even have that field. It doesn't look like it's used in many places. I take the point though. The hard part with 024$a is that there's a lot of other numbers that can show up there. But then I'm not sure that "biblio.ean" gets used much either. What's your target use case for it? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #6 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- (In reply to David Cook from comment #5)
What's your target use case for it?
We want to dedup titles on isbn, issn and 024$a without going through the index. We figured the easiest way would be to have all three values in the db rather than having to extractvalue the crap out of biblio_metadata. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Caroline Cyr La Rose from comment #6)
(In reply to David Cook from comment #5)
What's your target use case for it?
We want to dedup titles on isbn, issn and 024$a without going through the index. We figured the easiest way would be to have all three values in the db rather than having to extractvalue the crap out of biblio_metadata.
Ah right. Yeah, I can understand that. And using biblioitems.ean beats adding a new column like biblioitems.standard_identifier. I'd have to double-check how biblioitems.ean gets used, but I wonder if biblioitems.ean needs a rebrand... interesting. I reckon... let's check to see where biblioitems.ean gets used. Maybe a rename is in order... I do have a customisation that adds "Identifier-standard: 024$a" to the duplicate check when saving records, so your use case does make sense. Just want to make sure we're not abusing the "ean" field... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #8 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- As far as I could tell, the column was added for UNIMARC where the EAN is a separate field (073 https://unimarc.org.ua/ifla/biblio2023/2023n1_0_0_UNIMARC_073_International_...) I did a git grep with biblioitems.ean and these are the only places where it's used C4/Acquisition.pm: biblioitems.ean, C4/Acquisition.pm: $query .= ' AND biblioitems.ean = ?'; C4/Acquisition.pm: COALESCE(biblioitems.ean, deletedbiblioitems.ean) AS ean, C4/Acquisition.pm: $query .= " AND biblioitems.ean = ? "; C4/Acquisition.pm: " (biblioitems.isbn LIKE CONCAT('%', ?, '%') OR biblioitems.ean LIKE CONCAT('%', ?, '%') OR biblioitems.issn LIKE CONCAT('%', ?, '%') ) "; C4/Serials.pm: push @where_strs, "biblioitems.ean LIKE ?"; Koha/EDI.pm: $bib_hash->{'biblioitems.ean'} = $itemid; acqui/addorder.pl: "biblioitems.ean" => $input->param('ean') || '', installer/data/mysql/en/marcflavour/unimarc/mandatory/unimarc_framework_DEFAULT.yml: kohafield: biblioitems.ean installer/data/mysql/updatedatabase.pl: "UPDATE marc_subfield_structure SET kohafield='biblioitems.ean' WHERE tagfield='073' and tagsubfield='a'"); misc/release_notes/release_notes_17_11_00.html:<li><a href="http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13766">[13766]</a> Make biblioitems.ean longer and add index</li> misc/release_notes/release_notes_17_11_00.md:- [[13766]](http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13766) Make biblioitems.ean longer and add index The field seems to be used in the acquisitions module (I don't know how), but in MARC21 systems, it will always be empty since it's not mapped to anything. I *think* the use in Acquisitions is for display and searching orders (again, I don't know for sure, I don't read perl). So for MARC21 orders of DVDs for example, we could display and search for the CUP number if it were stored in biblioitems.ean. I would refrain from doing a complete overhaul of biblioitems just for this. I think this is self contained and doesn't need any other change. There are already plans to merge biblio and biblioitems that have been doing the rounds for years and years and asking for an overhaul of biblioitems to me is just another way of putting any change in limbo forever. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- As 024 is repeatable and can contain a lot of different numbers, which Koha will place in 024 separated by |. I am worried we will have a lot of information, but not be able to tell what kind of number or identifier we are actually looking at. For this reason I am not sure it should be a default mapping as it can potentially be quite confusing. But libraries could add as their mapping if they think it's useful for them individually. That it wasn't added when UNIMARC added it, was for this reason - MARC21 not having a separate field and the mapping logic not allowing to be specific enough. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Especially the $2 list of options is very long and broad: https://www.loc.gov/standards/sourcelist/standard-identifier.html -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #10)
Especially the $2 list of options is very long and broad: https://www.loc.gov/standards/sourcelist/standard-identifier.html
Yeah this one is my concern as well. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #9)
For this reason I am not sure it should be a default mapping as it can potentially be quite confusing. But libraries could add as their mapping if they think it's useful for them individually.
That would be my preference as well -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #13 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Just to be clear, the mapping is for 024$a, not all of 024 ($2 would not be included). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Caroline Cyr La Rose from comment #13)
Just to be clear, the mapping is for 024$a, not all of 024 ($2 would not be included).
Yep, that's what I meant - you have the id/number, but you cannot tell which identifier you are looking at necesessarily. it could be a lof of things which may look "the same" in length or structure. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42532 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|caroline.cyr-la-rose@inlibr |koha-bugs@lists.koha-commun |o.com |ity.org --- Comment #15 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- I still think it's valid and there is precedent for columns used for something else than what their name explicitly suggests (abstract and illus) and repeatable values in a single column (isbn and issn are both repeatable), but I don't have the energy to fight for this. Removing myself from assignee. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org