[Bug 10306] New: acquisitions shows publisher from 260 only
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Bug ID: 10306 Summary: acquisitions shows publisher from 260 only Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs@lists.koha-community.org Reporter: nengard@gmail.com The acquisitions module show publisher info from the 260, but now libraries are using RDA and need the 264 to show if there is no 260. This is easy enough on XSLT styled pages, but acquisitions is not one of those. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de Summary|acquisitions shows |acquisitions shows |publisher from 260 only |publisher from 260 only | |(RDA) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |10344 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Héctor Eduardo Castro Avalos <hector.hecaxmmx@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12756 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Héctor Eduardo Castro Avalos <hector.hecaxmmx@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=13723 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Marjorie Barry-Vila <marjorie.barry-vila@ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila@ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Yeah, I've been wondering a lot about this sort of thing. "publisher" is a column in the database which maps to 260... which makes sense... but it should potentially also map to 264... but it can't currently do that. I'm not sure whether the solution is to improve the mapping so that a person can add multiple fields/subfields to a column... or if this particular case should be hardcoded in the short term... or what. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|acquisitions shows |Publication information can |publisher from 260 only |only be mapped to either |(RDA) |260 or 264 (RDA) --- Comment #2 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- It's really important that we fix this, because otherwise while the catalogs still contain 'mixed data' we will have lots of places not only in acq where there will no publication year, publication place or publisher be shown for part of the records. I think changing the mapping so you can have 2 fields is probably the more complicated thing to do - also, how will the system act if both are present? My feeling would be to prefer the newer field 264 over the older 260 in case both are present. I am not sure how to reflect this in the GUI properly, but we need a fix soon. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- To be clear, the problem stems from our Koha-to-MARC-Mappings - the problem will show up whereever we get the information from the biblio and biblioitems tables. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major --- Comment #4 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Well, actually we got a problem everywhere but in the XSLT files, that already have been adjustred to at show 264 in some way. I think with more and more libraries starting to get RDA data - we can update this to be a bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Galen Charlton <gmcharlt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gmcharlt@gmail.com --- Comment #5 from Galen Charlton <gmcharlt@gmail.com> --- To outline a way of dealing with this: One way of looking at the problem is that RDA and the 260/264 forces us to deal with the fact that some attributes that we might want to stick in a column in biblio or biblioitems needs to draw from multiple MARC fields. XSLT and XPath give ways to do that sort of parsing... so we can add it to Koha something like this: - Create a new table to store XSLT stylesheets. This could be a combination of standard stylesheets (e.g., the MARC21 to MODS transforming) and local ones. - Create a new table to specify mappings to columns, something like this: koha_attribute_map kohafield # name of table and column to store the results xslt # reference to the XSLT to use, if need be xpath # what to use to extract the value The process would then be, when saving a bib record, that for each attribute specified in koha_attribute_map, the XSLT (if specified) would be applied to the MARCXML, then the XPath used to extract a result, which is then placed in the column specified by kohafield. This process could be used to supplemnt the one-subfield-to-one-column mapping that the MARC frameworks already specify, or with a bit more work, replace it. I should note that this general idea is inspired largely by similar mechanisms in Evergreen. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hector.hecaxmmx@gmail.com --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- *** Bug 12756 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #7 from Héctor Eduardo Castro Avalos <hector.hecaxmmx@gmail.com> --- (In reply to Galen Charlton from comment #5)
- Create a new table to store XSLT stylesheets. This could be a combination of standard stylesheets (e.g., the MARC21 to MODS transforming) and local ones. - Create a new table to specify mappings to columns, something like this:
koha_attribute_map kohafield # name of table and column to store the results xslt # reference to the XSLT to use, if need be xpath # what to use to extract the value
The process would then be, when saving a bib record, that for each attribute specified in koha_attribute_map, the XSLT (if specified) would be applied to the MARCXML, then the XPath used to extract a result, which is then placed in the column specified by kohafield.
It seems to be a good solution, Galen, with this you can fix the problem with UNIMARC too. The new 264 field is unsearchable in Zebra, I filed a bug for this <http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14198>. But since there are a new development with Elastic Search I don't know the future of Zebra in Koha. Regards. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #8 from Nicole C. Engard <nengard@gmail.com> --- How do people feel about Keyword to Marc mapping as a solution here? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hbraum@nekls.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Nicole C. Engard from comment #8)
How do people feel about Keyword to Marc mapping as a solution here?
Not very positive, because Keyword to Marc mapping only allows one mapping, when you theoretically might want to use 264 "or" 260 depending on which is available per record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #10 from Nicole C. Engard <nengard@gmail.com> --- (In reply to David Cook from comment #9)
Not very positive, because Keyword to Marc mapping only allows one mapping, when you theoretically might want to use 264 "or" 260 depending on which is available per record.
But, we could enhance it to do what we need ... couldn't we? Just spit balling ideas here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to Nicole C. Engard from comment #10)
(In reply to David Cook from comment #9)
Not very positive, because Keyword to Marc mapping only allows one mapping, when you theoretically might want to use 264 "or" 260 depending on which is available per record.
But, we could enhance it to do what we need ... couldn't we? Just spit balling ideas here.
I'd be down with that. A while back, I was hard-coding something like that (checking to see if the record had a 264 and if not falling back to the 260), but got sidetracked by more important things. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #12 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think enhancing the Koha-to-MARC-Mappings would be better than using the Keyword-to-MARC-Mappings for some reasons: - the keyword system gets the data from the MARCXML record for display each time, so I suspect it to be slower than the Koha-to-MARC-mappings that get the information from the db and it might slow down Koha a bit more. - I'd like to keep the option to use a database column for things like the publication year when writing reports, as the XML functions also seem quite slow in comparison. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10306 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #12)
I think enhancing the Koha-to-MARC-Mappings would be better than using the Keyword-to-MARC-Mappings for some reasons: - the keyword system gets the data from the MARCXML record for display each time, so I suspect it to be slower than the Koha-to-MARC-mappings that get the information from the db and it might slow down Koha a bit more. - I'd like to keep the option to use a database column for things like the publication year when writing reports, as the XML functions also seem quite slow in comparison.
Ahh, I misread Nicole's comment. I thought she was talking about enhancing Koha-to-MARC-Mapping. Yeah, no, I think Koha-to-MARC-Mapping is the way to go. I don't think it would make sense to use Keyword-to-MARC-Mappings. Especially since there are already so many places where we're using/need to use Koha-to-MARC-mapping... it makes sense to enhance the thing that we're already using. -- 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