2022-09-14 RS OST meeting notes

record meeting

make sure Alison records meeting

1

Alison

UCLA membership change

let RS OST know UCLA membership shift coming up

1

Sandra

UCLA guest spot for RS Analytics project team

discuss and decide adding in UCLA analytics expert from UCLA

2

Sandra

Aileen Madrano guest spot for RS A PT

No objections to LA guest spot.

Sandra: send contact info to Alison

Anonymization flaw workaround page (delay anonymization to gather AFN digitization reports)

Review edits; confirm if good to send to ‘consulting’ groups

review next steps (steps after ‘consulting groups’ feedback)

7

RS A PT

1. move forward with getting input from consulters

review Tipasa test plan

completing Tipasa sbs: populate with 10% holdings; three options: *random, *make query collection, *send ocns
(email implementation@oclc.org when ready to ‘put sand in sandboxes’)

OCLC asks “Stacy would like to start the deeper discussion of how the API-part of the Tipasa-Alma interop will work.   Like, what patron data is going back and forth, and do we have what we need to match for NCIP, and potentially for notifications? “ - someone from 1-3 of testers who have used/are using Alma user API &/or NCIP information to talk with OCLC

YES! forward any Tipasa/OCLC meetings to anyone you want

how to get “non-cohort” access to “Replace VDX with Tipasa” g-folder (also if they need to just ‘view’ or also be able to ‘edit’)

review skeleton test plan

config instructions for alma sb instances

20

testers: LA, R, I, SD, SB, D, and B

How to ensure a mix of holdings? Peter submitted, along with his request to use the 10% random holdings, to include a variety of material types.

When we test interoperability between Alma and Tipasa we’ll need to know what 10% of our holdings are in Tipasa.

How are the sandboxes linked?

Test plan will provide more details but broad strokes for now:

1. Set up Tipasa as a partner for the Alma → Tipasa piece. Documentation exists to do that.

2. Tipasa → Alma to link the original request in Alma to receive updates instead of creating a duplicate request in Alma as we do currently. Expect to be released in June?

OCLC is seeking more information about the API we developed re: patron data sharing via NCIP. Alison pulled in Joe on that conversation and will look to schedule a one-time meeting with other UC subject matter experts via the SILS Ops group.

To invite other attendees to Tipasa meetings forward the invite to them!

If people need access to the Replace VDX with Tipasa google drive folder email Alison their email and what level of access they need (view or edit)

Everyone: forward TIpasa pilot meeting invites as needed; contact Alison if problem forwarding.

Everyone: send UC emails & access level (view or edit) of anyone wanting access to “Replace VDX with Tipasa” g-folder to Alison

RLF requests sticking at B/LA

when RLF can’t fill, identify what’s happening, what could be done to ease this problem?

Scott will demo how they handle these requests currently.

Scott

This method addresses any request that’s been sitting at LA and Berkeley for a while, not just the RLF ones.

Filter borrowing requests to Partners = LA & Berkeley, Status: request sent to partner.

Export results to excel.

Find the “update date” in your sheet and decide how long you want to give the request to show up. Check on any request with an update date prior to that date and look at the rota. Move the request along (“Cancel partner”) if the partner immediately prior to LA or Berkeley is an RLF.

UCSC Case (06474638) update for this as of 9/2: Looking at these examples, it appears the items are only locating to the SRLF; they do not also locate in other UCLA holdings. Accordingly, when the request moves from the SRLF partner to the general UCLA partner, the request is matching to the same holding. When the borrowing request sends to the UCLA partner, a second request is not being created in the UCLA environment.

Since a request is not being created when the borrowing request sends a second time, the request is neither being filled nor rejected, thus resulting in your borrowing request being "stuck".

At this time, I believe it's best to share this case with the Alma Tier 2 team for further investigation into this behavior. One of my colleagues will be in touch with an update!

Wrap up

Review actions and decisions

5

Bike Rack

Capture important topics for future discussion

‘pu anywhere exceptions’: review shared messages, what would be next steps
metrics on how often ‘pu anywhere’ requests have to be changed to home campus (Jason) → may lead to: editing pu loc for this requests → may lead to: harmonizing bookbands

is the “randomized” part of the rota building actually randomizing things? Jason has a hunch that within the geographical groups it’s creating them alphabetically. (discovered in reviewing schedule c report)

RLF requests sticking at B/LA when RLF can’t fill, identify what’s happening, what could be done to ease this problem Sep 7, 2022

Should we have some kind of organized review of release notes that apply to resource sharing? (Mallory)

NRLF/SRLF rejected stuck at B/LA follow up: SH’s ‘guide’; test with what B/LA see; more escalation with ExL (scott, Mallory, Jason, patrick)

x/x