Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1)
(UXPROD-4049)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Poppy (R2 2023) | Parent: | Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1) |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Dennis Bridges | Assignee: | Khalilah Gambrell |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | LC1, cataloging, ecs, metadatamanagement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
| Release: | Poppy (R2 2023) |
| Epic Link: | Features that will be implemented to enhance FOLIO's ability to support consortia (Phase 1) |
| Development Team: | Spitfire |
| PO Rank: | 0 |
| Description |
|
Current situation or problem: Inventory records contain a number of human readable IDs that are expected to be unique within a given library. Some of these identifiers may also need to be unique across consortia. FOLIO needs to identify what identifiers in the Instance, Holding and Item should be unique within a member vs what should be unique across members. In scope Apply the method for managing unique IDs across consortia members to the unique IDs enumerated below
Out of scope Use case(s) Proposed solution/stories Links to additional info Questions |
| Comments |
| Comment by Khalilah Gambrell [ 31/May/23 ] |
|
Hey Dennis Bridges / Ann-Marie Breaux / Christine Schultz-Richert, I outlined all instance/holdings/item/authority unique identifiers that I know about. As far as location codes, unfortunately we have not enforced any validation to prevent duplicates. In fact, libraries can change these values at anytime. Is it possible for phase one to have a handshake agreement to not create duplicates? I believe this is how it is handled today.
|
| Comment by Ann-Marie Breaux (Inactive) [ 31/May/23 ] |
|
Hi Khalilah Gambrell I think the tricky part for this is that there may be many libraries within MOBIUS with location codes of ref or gen or stacks or main, but I don't know for sure. Seems like something that should be discussed and coordinated with the IC folks analyzing and migrating their existing data. Then as long as the permissions to create/edit locations are locked down for the member libraries (and controlled by the MOBIUS consortial staff), there shouldn't be an issue with random new duplicative codes popping up. |
| Comment by Khalilah Gambrell [ 31/May/23 ] |
|
Hey Ann-Marie Breaux - I agree. We should discuss with ICs to make sure that it is unique. Is a location code based on library code only or the Institution code + Campus code + Library code? |
| Comment by Ann-Marie Breaux (Inactive) [ 31/May/23 ] |
|
Khalilah Gambrell It's just based on the location code. It doesn't have to reference the Inst/Campus/Library codes. On Snapshot, they do, e.g. KU/CC/DI/M, but some libraries just assign plain codes for locations. See attached example from Orchid Bugfest. Best bet is to talk to MOBIUS about it. I'm guessing they are using some guidelines, and/or could provide lists of the current location codes for the member libraries. I think the larger and more complex the library or group of libraries, the more they will try to follow clear conventions. Looking at Duke and Chicago in Orchid Bugfest bears that out. |
| Comment by Khalilah Gambrell [ 31/May/23 ] |
|
Ahh. Got it. Thanks Ann-Marie Breaux |