https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |katrin.fischer@bsz-bw.de --- Comment #1 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Jonathan, can I get your help here please? Or Katrin maybe? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 --- Comment #3 from Heather <heather_hernandez@nps.gov> --- 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 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 --- Comment #5 from Heather <heather_hernandez@nps.gov> --- 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 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 --- Comment #7 from Jonathan Field <jonathan.field@ptfs-europe.com> --- 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? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber@kit.edu -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 --- Comment #10 from Heather <heather_hernandez@nps.gov> --- 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-... So the mapping seems to exist! Cheerio! h2 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32783 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- *** This bug has been marked as a duplicate of bug 35095 *** -- You are receiving this mail because: You are watching all bug changes.