Bug 35095 - Bibliographic record from local title only has 245$a
Summary: Bibliographic record from local title only has 245$a
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: ERM (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact:
URL:
Keywords:
: 32783 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-10-18 16:02 UTC by Caroline Cyr La Rose
Modified: 2024-04-22 20:12 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 35095: [WIP] Add kbart to koha biblio mapping (3.22 KB, patch)
2023-10-20 11:47 UTC, Pedro Amorim
Details | Diff | Splinter Review
Bug 35095: Rearrange marc_record code if there is a biblio (1.13 KB, patch)
2023-10-20 11:49 UTC, Pedro Amorim
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Caroline Cyr La Rose 2023-10-18 16:02:03 UTC
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-title-record

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.
Comment 1 Pedro Amorim 2023-10-20 09:51:30 UTC
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.
Comment 2 Pedro Amorim 2023-10-20 10:23:19 UTC
(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.
Comment 3 Pedro Amorim 2023-10-20 11:47:09 UTC
Created attachment 157504 [details] [review]
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."
Comment 4 Pedro Amorim 2023-10-20 11:48:03 UTC
@Jonathan Druart could use your help here.
Comment 5 Pedro Amorim 2023-10-20 11:49:14 UTC
Created attachment 157505 [details] [review]
Bug 35095: Rearrange marc_record code if there is a biblio
Comment 6 Caroline Cyr La Rose 2023-10-20 19:35:22 UTC
Hi Pedro,
Is this bug NSO? In the comment you say this is a WIP, and more mapping is required.
Comment 7 Pedro Amorim 2023-10-23 08:09:39 UTC
(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!
Comment 8 Caroline Cyr La Rose 2023-10-23 19:56:53 UTC
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.pdf 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!!
Comment 9 Katrin Fischer 2023-10-29 11:46:57 UTC
Is this a duplicate of bug 32783 now?
Comment 10 Pedro Amorim 2023-10-30 09:11:35 UTC
*** Bug 32783 has been marked as a duplicate of this bug. ***
Comment 11 Pedro Amorim 2023-10-30 09:11:56 UTC
(In reply to Katrin Fischer from comment #9)
> Is this a duplicate of bug 32783 now?

Yes. Thanks!
Comment 12 Pedro Amorim 2023-10-30 15:35:35 UTC
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?
Comment 13 Katrin Fischer 2023-10-30 15:54:32 UTC
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.
Comment 14 Caroline Cyr La Rose 2023-10-30 16:10:45 UTC
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...
Comment 15 Pedro Amorim 2023-10-31 11:21:40 UTC
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.
Comment 16 Koha Team University Lyon 3 2024-01-22 12:35:12 UTC
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