2018-03-19 - Data Migration Subgroup Notes

Chris Manly Arntson

Patty will take notes

Anne L. Highsmith began by describing the process required to go through each data element and make sure each source field serves the same purpose, and that the FOLIO field its mapping to is also congurent. It was discussed that Duke uses Aleph and Matt Harrington commited to adding a column for Aleph to the chart.

A discussion followed of reuired fields. According to the json file for userdata,

https://github.com/folio-org/raml/blob/53e6b3ec7a615a7d2c13acfc721c2077281c94f8/schemas/mod-users/userdata.json

the only required fields are username and ID. Charlotte Whitt noted that are more fields in the user interface that are marked required than those two. Chris Manly said that he will take this user interface divergence from the backend back to the User Management SIG, which has resumed meeting. They will consider discrepancies between the UI, the input API and the backend storage API.

A discussion followed about fields that are necessary for migration and those that FOLIO takes in a different way. Tod Olson described how in OLE, phone number is a repeatable field with a designated source type, with a check for preferred number. Chris pointed out that the User Management SIG had been satisfied with just two phone numbers as they were trying to strike a balance between flexibility and complexity. patty.wanninger asked if libraries couldn't manage extra phones and other info in the campus user ID system, as it was a FOLIO design principle to simplify and take only what is needed for the function. Wayne Schneider said there had been some drifting away from that principle, and Uschi Klute said that half of their libraries at least depend on the library platform to manage users, and have no other system.

It was agreed that it would be useful if we could standardize notation on the composite sheet.

"[]" mean a field can contain an array; i.e. is repeatable

RED ink mean the field is not needed in FOLIO

"*" star is a required field.

It was also agreed that it would be very handy to know the data type of each field. It was noted that most are "strings," and JSON does not have field length restricitions.

Anne agreed to go through the FOLIO fields and marked required and arrays.

A discussion of each field is still necessary to be sure (1.) the source field is definition and the FOLIO field are truly aligned and (2) that we are correctly defining these fields across all the sources. (i.e. we are correct that FOLIO 'barcode' is the same as Voyager 'patron_barcode.patron_barcode'[ ] is the same as Sierra 'barcodes' [ ] , LBS 'borrower.barcode', OLE 'barcode")

Anne will start a discussion thread for discussing questions about the review.

Next week we can review the messaged and aligned data, and resolve any differences in meaning of different entries, and develop a list of gaps where it seems required fields are not present currently in FOLIO. This review will be passed to the User Management SIG.

Uschi asked how would multiple emails be handled. Chris said the User Management SIG had considered a single email to be enough and others would either be "dropped on the floor" in migration or possibly could be written to a notes field. It is possible to advocate for a more complex (albeit more flexible) schema, though the UM SIG was satisfied with the briefer FOLIO schema back when it was first proposed.