Batch Importer (Bib/Acq)
(UXPROD-47)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q2 2019 | Parent: | Batch Importer (Bib/Acq) |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Ann-Marie Breaux (Inactive) | Assignee: | Ann-Marie Breaux (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | crossrmapps, data-import, instances, marccat, marcimport, split | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Batch Importer (Bib/Acq) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimator: | Niels Erik Nielsen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | Small < 3 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Viktor Soroka | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | XXL < 30 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Taras Spashchenko | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Wayne and Shale (and MARCcat) may already have many of the bits and pieces for this already, but I'm not sure how much we got and how much is missing.
I'm assuming analysis and implementation work to be done in the area of batch loading on top of existing records. To the extend this is to be user configurable, the estimate assumes this is covered by some of the other UXPROD issues. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Folijet | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Leipzig (Full TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Leipzig (ERM Aut 2019): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Q2 2019 Data Import Priority 1 of 8 Note: While UI input is preferred, this will only cover command line input to start, and using the standard MARC data mapper Requirements:
Per Harry, aim for at least these performance metrics:
May need to review mod-data-loader and decide if it is replaced by the data-import-loader, or if the mod-data-loader mapping just needs updating or what Note that MARCcat will not happen until SRS Integration with MARCcat (
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 11/Jun/18 ] |
|
Ann-Marie Breaux, Wayne Schneider, shale99 I am trying to understand how this differs from
|
| Comment by Ann-Marie Breaux (Inactive) [ 19/Jun/18 ] |
|
Hi Cate BoeremaUXPROD-145 is an older feature that encompassed lots of different things: inventory instances, holdings, items, authorities - in MARC and delimited formats. The newer features (in the 600s) break 145 into more discrete elements. Should we maybe add 145's details to the Batch Importer epic (
|
| Comment by Cate Boerema (Inactive) [ 20/Jun/18 ] |
|
We definitely don't want duplicate and overlapping features so I think that's a good idea. We should wait until after the Gap Analysis is complete (should be by June 29th), as
|
| Comment by Hkaplanian [ 17/Jul/18 ] |
|
Can I assume this is MARC-21 only and we will need to add another feature for MARCXML? |
| Comment by Anne L. Highsmith [ 08/Apr/19 ] |
|
I'd like to comment on the requirements for point 3, especially sub point ◦Move non-FOLIO 001 to 035 $a field (only if unique 035)". The requirement for the 001 to be unique would create a serious problem for Texas A&M because in the course of migrating to FOLIO we are migrating bibliographic records from two different voyager databases. That means that the 001 fields from the bib records, marc holdings records, and authority records will overlap tween the two databases, so I cannot guarantee them to be unique. I would also suggest that in creating a 035 from 001 & 003, that you follow the convention to use the 003 as a prefix to the 001 rather than putting the 003 in 035 $be. Although I can't see that the LC MARC Documentation requires it, it is a very common means of dealing with 001/003 data. Example: 001 00964332 If you drop the requirement that subfield a be unique and use the 003 data as a prefix to the 001, then I can put the database code in the 003, create a unique 035 subfield a and still be able to tell the records from both databases apart. |
| Comment by Ann-Marie Breaux (Inactive) [ 10/Apr/19 ] |
|
Thanks for your comments, Anne L. Highsmith I have adjusted the number handling proposal based on your suggestions. One question - when you load your existing MARC records to FOLIO, if there is a record in both database for the same resource, will you be consolidating those into 1 MARC record (and surfacing as 1 Instance), or will you be loading those as 2 separate MARC records (and surfacing as 2 separate Instances)? I think the next step will be to review/confirm this with the Data Import subgroup and maybe with MM SIG. My goal is to get the requirements finalized by the end of the week, so that I can start writing the developer stories for this feature. |
| Comment by Anne L. Highsmith [ 10/Apr/19 ] |
|
We haven't yet made any decisions about how to handle bibliographic duplicates, so I can't answer your question. This may be obvious, but in case not, let me clarify my example of why this is an issue for us. It doesn't have to do with bibliographic duplicates; it has to do with the fact that the 001 field as created in and exported from Voyager is simply a sequential integer. TAMU Main Libraries bib record with field 001 = 1001 may be a record for an engineering dissertation done in 1953; TAMU Medical Sciences Library bib record with field 001 = 1001 might be the serial record for JAMA. But they're both field 001 = 1001, so the 035 $a would be identical under the original proposal, without some kind of qualifier. |
| Comment by Ann-Marie Breaux (Inactive) [ 11/Apr/19 ] |
|
Yes, Anne L. Highsmith thank you for the clarification. So as part of data migration, to deal with having totally different records with 001 of 1001, you're thinking some sort of qualifier to be able to distinguish them, so main1001 vs med1001, or something like that - and then that qualifier would carry down into the 035 (along with whatever 003 value) when the records came into FOLIO, and the FOLIO HRID was assigned. Is that right? And to be clear, since you'll just have 1 Inventory/MARC Database in FOLIO (right?) then the previous main1001 and med1001 records would end up with completely new and different FOLIO HRIDs in the 001 field. And then dealing with bibliographic duplicates once all the bib records are together in FOLIO is a completely separate issue (and not one I think we've worked through yet, but probably OK to park it for now). My guess is that we might need something similar to OCLC (or Jira for that matter), where a previous HRID is still accessible and searchable, even if that record is merged with another record. |
| Comment by Anne L. Highsmith [ 11/Apr/19 ] |
|
Yes,Ann-Marie Breaux , I envision it as you describe it. |
| Comment by Ann-Marie Breaux (Inactive) [ 26/Jun/19 ] |
|
Split the backend pubsub work into its own feature (
|