| Summary: | Add more mapping when creating eholding from biblio | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Jonathan Druart <jonathan.druart> |
| Component: | ERM | Assignee: | Jonathan Druart <jonathan.druart> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | minor | ||
| Priority: | P5 - low | CC: | flyingendpaper, jonathan.druart, jonathan.field, martin.renvoize, michaela.sieber, pedro.amorim |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32782 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35095 |
||
| Change sponsored?: | --- | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Bug Depends on: | 32030 | ||
| Bug Blocks: | |||
| Attachments: | MARC print serial record | ||
Jonathan, can I get your help here please? Or Katrin maybe? Hm, do we have maybe some example data for these? I'll also add Heather for a real MARC expert. Interesting! First, I'm blushing--I'd say I'm a MARC Conversationalist and not a MARC Expert--I dream of MARC Fluency! That said, the MARC bits are the clearest to me! I'm not sure what I'm looking at--if someone can fill me in, I'm happy to help. Initial reactions, looking at the FIXME lines: The 260 is obsolete but still used. If it's a digitized, older resource (think HathiTrust or JSTOR resource available only via the paid licenses) the biblio for the print version may use 260. A newly published item's biblios will use 264s. I don't know what "embargo_info" is. Help? Looking at the other FIXMEs, it looks like you might be looking at Linking Entry Fields. A Preceeding Entry will be a 780, with suitable subfields. "Parent publication" is vague--if this is for a supplement, the "parent" is in a 772. If this is a Host/Analytic relationship, the Host is in a 773. But if this is all for an electronic/print relationship, those relationships are in 776s. The "first issue online...last issue online" stuff tends to not actually appear in cataloging records because it changes so much. A serial MARC record will have the dates published/sequential designations (if known) in 362 fields (there can be more than one in a record). Published dates should also be in the 008 positions 007-014 (two dates). But in the digitized/published online version, the dates could be different, so they are actually seldom tracked in the cataloging records--they're usually mentioned in the discovery/search interface entry for the resource. Tell me more! Tell me where I'm wrong so I can learn! And when I understand more what this "my $publication_title..." text is and what it's doing, I can come up with sample MARC records for y'all. We don't use ERM, but I've worked where it is used, so know what it's supposed to do. I also use it as a patron!:) Fun!! --h2 Brainstorm! OCLC does something similar brilliantly--I just realized what this probably is--like a macro to derive the electronic version from the print, microformat, etc., version record. Hold on--I'll post more today. Back soon. --h2 So I created a video showing what the OCLC Connexion Client's macro, "GenerateERecord" does, but it was too large to attach to this bug, so I uploaded it to my YouTube account: https://youtu.be/orzMYemsY5I I'll attach a copy of the source (print) MARC record to this bug. I tried to attach the OCLC macro file to this bug, so the developers could look at it, but it's too large--let me know if I can somehow provide that info! The functionality that I'd love to see in Koha: In the Advanced Bibliographic Editor, I'd like a new Macro that's called, "Generate e-record," because I usually have to edit/upgrade a bib record before generating the e-record. In addition, when displaying a bib record in the staff client, I'd like to select the "Edit" button, and have a new option that's called, "Generate e-record," that does this resulting in the record displayed in the editor that my login uses (eitehr the Basic or the Advanced). The generated e-record should be in a framework that's chosen via a syspref; I'd like the choice to be either generate the new e-record using the *same* framework of the source record, or a designated framework. E.g., we and many Koha libraries don't use different frameworks at all--they're unnecessary--so all our bibs are int he Default framework and we would want the generated record to also be in the Default framework. However libraries that do use frameworks might want, e.g., the generated bib to be in something like an ERecord framework. This is such an exciting development! --h2 Created attachment 146157 [details]
MARC print serial record
This is the MARC record exported from OCLC (via the OCLC Connexion Client software) for the print, serial title used in my video to show the functionality of this software's "Generate e-record" macro.
So, if I understand this correctly, what we are trying to do here is take a MARC record (not necessarily print serial, could be an ebook or eaudio MARC record for example) and upload it into Koha in ERM as an eresource title? In the database structure this is essentially KBART2 format so the mappings are MARC21 -> KBART. Right now, I think we only take the most basic information. I hope I've understood that correctly? There are a few people who have already trod this path I believe, for example: https://github.com/zbw/marc2kbart/blob/master/imf/marc2kbart.fix and https://github.com/adambuttrick/marc_to_kbart/blob/master/convert.py These mappings make sense to me. We will never get a perfect match as some KBART fields are simply not described in MARC. For example, embargo_info means "you can't use this material until this date". That would never exist in MARC. I think it's possible that quite a lot of the fields you listed would not naturally be found in MARC. What do you think Heather/Katrin? If this bug is for mapping MARC21 --> KBARTx, then disregard my comments! (I have no experience with this and can't imagine my library being interested in it.) However, I do have experience with mapping MARC21, so could chime in about that if helpful. If this bug is for creating a way (macro?) to create a MARC21 eResource record from a MARC21 non-eResource record, then I'm interested in that & my comments might be helpful. (I wish I spoke Developer better!!) Sorry about the confusion, I should have added more context in the first comment. As Jonathan said it's indeed about a MARC21<->KBART mapping. (In reply to Jonathan Field from comment #7) > https://github.com/zbw/marc2kbart/blob/master/imf/marc2kbart.fix This one seems to have info we don't have. > https://github.com/adambuttrick/marc_to_kbart/blob/master/convert.py This is the one I used initially. I think I will keep this bug opened but lower its priority, it does not seem important for now. Correct me if I am wrong and that you really need an additional mapping. Shall I delete my previous comments? They don't seem relevant! I've heard that some vendors provide both, e.g. MIT Press: https://direct.mit.edu/books/pages/MARC_records_KBART_files https://help.taylorfrancis.com/s/article/How-do-I-request-and-retrieve-MARC-and-KBART-records So the mapping seems to exist! Cheerio! h2 *** This bug has been marked as a duplicate of bug 35095 *** |
There is a lot of FIXMEs here, we could do better and provide more mappings. my $publication_title = $biblio->title; my $print_identifier = $record->subfield( '020', 'a' ) || $record->subfield( '020', 'z' ) || $record->subfield( '022', 'a' ) || $record->subfield( '022', 'y' ); my $online_identifier = $print_identifier; my ( $date_first_issue_online, $date_last_issue_online ) = $fix_coverage->( $record->subfield( '866', 'a' ) ); my ( $num_first_vol_online, $num_last_vol_online ) = $fix_coverage->( $record->subfield( '863', 'a' ) ); my ( $num_first_issue_online, $num_last_issue_online ) = ( '', '' ); # FIXME ? my $title_url = $record->subfield( '856', 'u' ); my $first_author = $biblio->author; my $embargo_info = ''; # FIXME ? my $coverage_depth = $title_url ? 'fulltext' : 'print'; my $notes = $record->subfield( '852', 'z' ); my $publisher_name = $record->subfield( '260', 'b' ); my $publication_type = ''; # FIXME ? my $date_monograph_published_print = ''; # FIXME ? my $date_monograph_published_online = ''; # FIXME ? my $monograph_volume = ''; # FIXME ? my $monograph_edition = ''; # FIXME ? my $first_editor = ''; # FIXME ? my $parent_publication_title_id = ''; # FIXME ? my $preceeding_publication_title_id = ''; # FIXME ? my $access_type = ''; # FIXME ?