| | |
|---|
05:53 | Small Talk | Monitor issues, mac desktops, AR glasses, and the introduction of a concept I predict will destroy us all: “side-to-side” meetings 🪦.
|
14:05 | WOLFcon | |
14:13 | Remote Storage | Stephanie pointed Thomas to a ticket: MODRS-121: Remote storage allows null barcodesOpen There was a meeting in February about Remote Storage through the mostly dormant Remote Storage channel. The recording and notes are here:
In this meeting we will cover what people are using for remote storage solutions, what issues they're running into, and whether folks are using the remote storage module/connectors vs something outside FOLIO.
|
15:36 | Caiasoft | Darsi says that Stanford uses Caiasoft. When deciding how to move forward, Stanford talked to their main developer. The developer said that when she had previously worked with Cornell, they had given up on the edge module--it lacked functionality and was inconsistent. For this reason, Stanford relies on APIs for everything. This includes (among other features) new requests, accessioning into Caiasoft (17:33), adding a transfer note, handling the transfer of bound-withs (retrieving children), and updating either marc holdings or source FOLIO holdings depending on the record. This functionality exceeds what is available through the edge module.
Thomas confirms that at Cornell, they also connect to Caiasoft via API. The middleware Caiasoft wrote handles locations (19:41) based on codes. This means that anytime Cornell wants to change location codes the middleware needs to be updated. There are also concerns about the new authentication scheme and updates that will be needed related to that.
|
21:55 | Issues with Dematic | Thomas says that one of the problems with Dematic is that there are 3 or 4 different connectors depending on the version. Another issue is covered here: https://folio-org.atlassian.net/browse/MODRS-121 There are problems if items have null barcodes. Caiasoft cannot accept an item if it does not have a barcode. Barcode is the unique identifier. Thomas says when people are flipping over entire holding records with multiple items attached (such as a serial record), some of the items may not have barcodes. This is causing an error with the remote storage middleware. The above ticket is to address this issue. Thomas asks what the expected behavior should be? Would we expect the system to use a value like HRID for the barcode or generate a new barcode? Should the action error out the items without barcodes? Should the entire batch fail? Darsi notes that the entire batch failing is not desirable. Alexis notes that if you generate a barcode, then you'd also have to pull the piece back and put a physical barcode on it.
Thomas asks if people flip items to remote storage before they are sent, or when it’s going into remote storage? At Stanford it is when the items are going in, but generating a barcode could make sense if you are doing this process before. Cornell sends things to an annex for processing, where they sit with a temporary location until staff can process them. Then the items go in to Caiasoft.
|
27:50 | Current Gaps? | |
29:13 | Library of Congress? | |
30:29 | Texas A&M | Lisa says Texas A&M shares a remote storage unit with others in the state. They are not allowed to send duplicate items. They use Caiasoft and would be interested in expanding their integration to include some of the features Stanford mentioned. Texas A&M has lists of items being sent to Caia, and those items are being compared by OCLC number to see if they are duplicates. Texas A&M also makes the records and sends them to Caiasoft. This is a laborious process. Fetching the data via API would be an improvement. The duplicate restriction is a difficult problem to solve--given the number of limited fields in Caia, this is very challenging and a human is unlikely to do better than a computer. They also have to dedupe at the item level. (37:00) Even with an API integration, Darsi wonders if there would still be human processes of deduplication. Lisa wonders if there might be possibilities for monographs at least. (39:19) Alexis notes that Stanford is part of the West project, which aims to keep one copy of every print serial. Manual checks are still required for that process. There might not be a way around this.
Thomas says that Cornell’s middleware for Caiasoft is hosted by Caiasoft. This might be a complication for a system with multiple libraries on multiple ILSs.
|
43:03 | Chicago and Dematic | Dale asks if Dematic users are concerned about being unable to update their metadata in their ASR? Can metadata be updated in Caiasoft? With Dematic, this may be a way of solving the null barcode problem: If the item has a remote location, then you could also check to see if there is a null barcode. If there isn't a barcode, then you could choose not to send it to the Dematic system. Thomas asks what order Chicago does their process. Dale says that they change the location, which introduces a record into remote storage. Then the items are sent to remote storage. Cornell moves things into a processing location first, which is a process difference.
(46:29) Thomas asks which connector Chicago uses. Dale says Chicago uses the edge dematic module. Staging director is going away on the Dematic side, and EMS will be required.
|
48:14 | Why isn’t remote storage in FOLIO? | |