Notes 11/4/15
- On Questionnaire form Call #(ITEM) question, I want to clarify that only item records without a call # will be labeled as PROBLEM, not bib records without an item record (all of our e-resource records).
Answer:
Call number field is relevant only for physical inventory. Note that even if holdings record created during migration phase for inventory that is ‘marked’ to be converted to electronic, is deleted from the system when P2E process is running.
- A few of our e-resource records with an 856 have provider name information, but most don’t. The records that do have the provider name in subfield 3. The “Electronic Resource Handling in Alma Migration” document says that the provider is in subfield 3, the form, however, lists the default subfield for provider information is subfield w.
Answer:
Migration will use field and subfield provided in Migration Form in the line for electronic provider information.
Rae-Ann notes – documentation is inconsistent. EXL: don’t rely on default migration values here, use what you have. Action: case 00184259 logged to correct/clarify the documentation
- On the Checkins & Holdings tab of the Data Mapping form, in the Holdings from Bib Summary Statement, I am unclear what location code we would put in this mandatory ##Value##, because we do not have a single location code for the materials described in the Bib Summary Statement.
- SUMM_LOC_CODE Location Code?? Yes If SUMM_LOC_SUBF not provided or not found, the Alma Library Code that will be used instead. This code must be present in Column D of the Alma Location tab of the Migration Form.
Answer:
This is default Alma library code and Alma location code (new Alma codes, as mapped from III in the form) that will be used when cannot be identified based on input data. You can put any code that you can recognize later by retrieval and correct data, if required, like YYYY. Post-migration, search for this location code to retrieve the records that did not map correctly.
- ACLS Humanities Ebooks
- Many CSU libraries have purchased a collection called ACLS Humanities Ebooks. The vendor provided us the records which do not have OCLC numbers, but instead use a vendor-provided identifier number in the 035 (see attached example record). Because many CSUs have these items, we would like to load them into the Network Zone, so that we can reduce duplication of effort when managing this collection (i.e., we would like there to be one knowledge base collection with all of these records that each CSU institution can just attach their holdings to). Is there a way to handle this during migration? There are, at least at CSUN, 4104 titles in the entire ACLS Humanities Collection.
Answer:
For both options described below –
- If linking to NZ should be avoided – move 035 to local 9XX; some searchable information should be available that will help to identify records as a set for further processing in Alma if required.
Option 1:
If history and keeping records in IZ is not important mark records by prefix defined in migration form for records to skip, like (SFX).
Records will not be loaded during migration. Records with linked POLs will be suppressed and loaded to IZ.
After migration create Collection in NZ and load records using spread sheet under collection.
Option 2:
If keeping history is important.
Add bib record IDs to suppressed records file;
Records will be loaded to each IZ.
Suppressed records are not published to Primo
After migration create Collection in NZ and load records using spread sheet under collection.
Question is: how does CALSTATE wish to manage this – centrally or institution-specific?
Jessica H notes: The ACLS Humanities eBook target is an active target in SFX Chancellor instance and is shared by several libraries à Lauren – not activated for Northridge. So potentially this is managed differently at different institutions.
Svetlana: Migration is not creating collections in NZ, so activation/clean-up will have to take place after migration. This is a workflow decision that may be different between institutions.
Lauren à because these records have local ids in the 035, will those be contributed to the NZ or go straight to the IZ. Action: EXL to check (Svetlana)
- Digital Bookplates at CSUN from the Bibliographic record
Fresno / San Jose are providing examples of digital bookplates in their item records, but at CSUN we have Digital Bookplates set up through data in the bibliographic record, specifically in the 970 field. Here's an example 970 field from a record:
970 10 |t<span class="bookplate">Generously Provided By: Bonita
J. Campbell<a href="http://library.csun.edu/WISE"
target="_blank"><img src="http://suncat.csun.edu/screens/
Campbell_Bookplate_small.jpg" height="183" width="146"
alt="Bonita J. Campbell Collection Digital Bookplate
Image"></a></span></span>
I've attached a screenshot of what this looks like on the user side, and here is a link to a record in the catalog that shows you can click on the bookplate and be
taken to a web page defined in the 970 field:
http://suncat.csun.edu:2082/record=b2655492
Is there advice from Ex Libris about how to migrate / reproduce this functionality in Primo? Obviously we know that the images themselves will have to be hosted on
our own server, but we want to be able to render the bookplate image in Primo in some way. I believe during one of the demos we were shown an example from Harvard that showed digital bookplate functionality.
Discussion: Some more background -- Northridge has the bookplates in the Bib 970 field. Fresno and San Jose have these in the item record. EXL confirms that Harvard solution requires NR modifications. In the Harvard case, they have the bookplates in the bib record; we’ll have to check about the case of the data in the item record. Action: Lynn will check internally just to make sure to get the solution details. Will follow-up with additional information.
Calstate asked a clarifying question: would the urls should come over from the item records during the migration? Lynn confirmed we can only use bib level info for display – and raised the possibility of moving the data from item level to bib level? Patrick added: if we’re all going to end up with bookplates urls, why not put them in a local field? Say a 9xx? Lauren notes that Northridge has them in the 970. Not sure if other CSU institutions are handling it the same way. But all agree that it would be possible to move it to another 9xx field for migration if needed. Lynn adds that for purposes of streamlining Primo normalization, best to standardize the handling of these bookplate urls as much as possible since we’re sharing a central rule-set. To this point, Patrick added that we would need to get cataloging/tech services team on board to make this decision. Action: Lauren will follow-up and get it on the tech services agenda.
- As part of the reclamation process we had OCLC place the OCLC# in the 001 and we added the control number identifier in the 003. In some instances, the OCLC# with the old prefix (ocl7 or ocm) is also found in the 035; in other instances the records have no 035 or have some other information in the o35.
It's come to our attention that for migration the MARC records must have the OCLC# prepended by the control number identifier in the 035. Example: 035 // (OCoLC)215253009. Please confirm.
Answer:
Matching
The NZ linking programs use values in the 035 $a and 035 $z fields to determine a match. Note that control field 001 in Alma is reserved for the Alma internal Bib ID (MMSid), so migration processes ensure moving any previously existing 001 content to 035 $a or 035 $z.
Numbers in 035: Non-OCoLC
As a rule, the exact string in the 035 $a or 035 $z fields are used for matching. For example:
(NhCcYBP)40015704661
(CaOOAMICUS)000026217529
(Gale)ESTCN6838
Exact string matching is done for the above numbers, but not for OCLC numbers which have unique and special prefix handling.
Numbers in 035: OCoLC
The OCLC numbers are often inconsistent.
If a OCLC number has the prefix (OCoLC), remove the prefix ocn, ocm, or on from the number portion of the OCLC number, and use only the value in parentheses to compare. This means that the following are considered equivalent:
(OCoLC)12341234 is the same as (OCoLC)ocm12341234
(OCoLC)567856789 is the same as (OCoLC)ocn567856789
(OCoLC)23456789 is the same as (OCoLC)on23456789
This is accomplished by a normalization routine as described below.
Normalization Flow
035a and 035z = 'OCLC Identifier' Normalization Flow:
for each
MARC "035"|"a" AND MARC "035"|"z" value as '(Prefix)'||'ID'
normalize lower_case '(Prefix)'||'ID'
normalize OCLC prefix ('Prefix') for (ocolc)' OR '(oclc)' AS '(ocolc)'
remove initial zero padding ('ID')
remove OCLC padding ('ID') for 'ocm' OR 'ocn' OR 'on'
end
For example:
035 |a (OCoLC)41319586 is normalized to: (ocolc)41319586
035 |z (OCoLC)ocn41319586 is normalized to: (ocolc)41319586
035 |a (OCoLC)ocm00041319586 is normalized to: (ocolc)41319586
035 |a ocm00041319586 is normalized to: (ocolc)41319586
035 |a (NotOCLC)00099556677 is normalized to: (notoclc)99556677
Multiple Matches
Matches and linking is only executed when there is a single match in the NZ. If there are multiple Bib records found in the NZ that match the record attempting to link based on the
chosen single shared identifier, the record is not considered a match. This is typically only possible when a record has multiple matching IDs and other records were contributed to the Network Zone previously that had only one of those IDs. For example:
Record IZ attempting to link to NZ contains multiple 035 $a values:
(abc)123
(def)456
Record NZ1 already contributed to NZ contains:
(abc)123
Record NZ2 already contributed to NZ contains:
(def)456
Matches Within the Same Institution
There can be matches of records within the same institution when duplicate records with different source Bib IDs exist in the previous system (relevant usually for sites that did not work centrally before moving to Alma). This type of duplication within a single institution is not handled by migration, and in such cases, there can be more than one record in the IZ that link to the same de-duplicated NZ record.
- Will we need to identify Bound-with records? If yes, should we follow the Orbis Cascade instructions?
Answer:
Migration is not required any special procedure for preparing, extracting boundwith.
But, may be III internal steps are taken by Orbis Cascade that we do not aware of. Please provide document you are referring to. Document is on the Confluence website. Action: Brandon sent Audrey the doc, we will look at it and let you know if we have any concerns.
- We have not done anything yet with the Fund tab in the Mapping Form. Can you provide us with an sample form to follow?
Answer:
Attached is a sample funds Excel Spreadsheet that I used at Pacific to submit funding structure. You can set Ledger / Summary Fund at will, as well as Fund Name. The Fund Code needs to be exactly the same as the Millennium Fund Code as this is what maps the fund in the Millennium Orders to the Alma Fund structure and ensures that the migrated Alma POL has a fund associated. When completing the Data Delivery Form, use the column headings from the Excel spreadsheet as shown in the below image.
Note: I did not include Library in my funds spreadsheet as, at Pacific, one library centrally ordered for all 3 libraries within Pacific. If you have different fund structures that need to be associated with different libraries, you would use that column to differentiate. I’d also recommend that you have Ledgers for each library within your institution that has a separate funding structure.
- We have many serial records with no Holdings records. No checkins at all. Is that a problem for migration?
Answer:
MARC 21 holdings records are not mandatory in III and migration can use MARC holdings file if provided. Holdings file is not mandatory for migration. Other data containing holding information is used - item and/or checkin, bib tags. Alma will create holdings info based on item information. Please check in your test load and verify if the level of detail is ok.
- In the case of serials with Holdings records, the "Extracting Records ... for Migration to Alma" document mentions extracting checkin records as "non-MARC holdings." Please explain what this means.
Answer:
I assume it is because checkin is not using MARC21 standard fields.
- Related to question 5, our exported MARC records do not include holdings information, they only have items information in the 945. In order to get Summary Holdings Statements we export the Holding records separately and link them to the bibliographic record via the OCLC# located in the 004 of the Holding records. (We've done this in MarcEdit.) What process will we use in migration?
Answer: Action: Svetlana opened a case to migration team to confirm expected behavior here – Maria Pena@ Fresno, case number 00184268
- In preparing local MARC fields for migration do you recommend we follow Orbis Cascade's document "Preparing for Migration of Local Bib Data to Alma Bibliographic Record Extensions"?
Answer: Standard list of fields approach is a good one to follow. Action: Lauren will bring this to the tech services meeting for discussion on this approach. Will probably not happen for the vanguard load.