This shows you the differences between two versions of the page.
public:bc_services_card [2023/03/17 18:12] scott.leslie |
public:bc_services_card [2024/05/09 05:04] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== BC Services Card Research Project ====== | ||
- | |||
- | {{ : | ||
- | |||
- | ===== Patron information in Evergreen ===== | ||
- | |||
- | Patrons are normally registered via the EG staff client, by staff at the circ desk ([[https:// | ||
- | |||
- | Several other Evergreen consortia (PINES and KCLS) use Quipu' | ||
- | |||
- | Evergreen also has a patron self-registration feature ([[https:// | ||
- | |||
- | There' | ||
- | |||
- | There is a lack of good documentation on how external applications can use EG's existing APIs, in part because those APIs were primarily designed to be used by EG's own component services. It would be worth investing in better documentation (and more user-friendly APIs, especially for creating/ | ||
- | |||
- | ==== Technical details ==== | ||
- | |||
- | Here's an entity relationship diagram for the database tables that store patron information (click to enlarge): | ||
- | |||
- | {{ : | ||
- | |||
- | A few notes: | ||
- | * actor.usr is the primary table for personal information. It is used for both staff and patron accounts. | ||
- | * Each user has a primary card (actor.usr.card) and may also have secondary cards, all of which are in actor.card. | ||
- | * Each user also has a username. Usually this matches the barcode of the patron' | ||
- | * The user may have a mailing address and a billing address, but they' | ||
- | * Email address is not required, nor guaranteed to be valid or well-formed. However, users can reset their password by clicking a link in the public catalogue which sends a reset email to whatever email address is in actor.usr.email. | ||
- | * The ident_value and ident_value2 fields may contain driver' | ||
- | * actor.usr.profile contains the user's profile, a.k.a. permission group or patron type. Patron and staff permissions are generally governed by which permission group they belong to. | ||
- | * actor.usr.home_ou specifies the user's home library. The hierarchy of libraries (branches, systems, federations, | ||
- | * Libraries can track additional information about their patrons using " | ||
- | * When patron self-registration is permitted, the data entered by the patron is initially stored in the staging tables shown on the far right of the diagram. Staff then have the ability to review this pending patron information and approve account creation. | ||
- | |||
- | |||
- | ---- | ||
- | ===== Coop Answers to Questions from March 16 Kickoff Call doc ===== | ||
- | |||
- | * Inventory of current technologies being used | ||
- | * List of current library sites and what is being managed for them | ||
- | * Any additional common challenges today not identified above | ||
- | * General intro to the library system, what changes and what’s static, | ||
- | * How are people and accounts created today? Go to branch -> some registration and card issuance, create account at home. What identifiers are collected, email, names, ? | ||
- | * When we say “record” what do we mean? | ||
- | * How strict are validation rules? How strict would they be with bcsc? | ||
- | * Is there business value for existing patrons to “link” their BCSC proactively? | ||
- | * Privacy/ | ||
- | * IDENTOS can help identify how this aligns to BCSC onboarding requirements | ||
- | * Conversation with non-SITKA libraries that would benefit from having access to brokering of BCSC? What are their requirements that differ from Co-Op? | ||
- | * Is there a desire to have additional / complementary digital library access vs overdrive? | ||
- | * Any other tables and key data elements that would be helpful (other than those already provided on the wiki) ? | ||
- | |||
- | ===== Docs from Other ILS ===== | ||
- | While our initial focus is on validating potential Sitka patrons via the BC Services Card, actually making this work will require standing up some sort of SAML server on our end and liasing with the BC Services Card to integrate. There are approx 20 other BC libraries using ±4 other ILS who, if they also wanted to offer validation via the Services Card, would need to standup similar SAML servers. So a secondary goal of this project is to see if we can architect our solution in such a way as it is the sector-wide integration against the Services Card, with us doing integration with the libraries. To that end, I asked other libraries (via the BC Libraries and IT list) to share any API docs they might have that can inform the consultants in architecting a solution. Below is what resulted: | ||
- | |||
- | |||
- | ^ Non-Evergreen ILS in BC ^ Library Name ^ Expressed Interest ^ | ||
- | |{{ : | ||
- | | |Okanagan Regional Library| | | ||
- | |[[https:// | ||
- | | |Richmond Public Library | x| | ||
- | | |Thompson-Nicola Regional District Library| | | ||
- | | |Vancouver Island Regional Public Library | | | ||
- | | |West Vancouver Memorial Library| | | ||
- | |SirsiDynix Horizon |Burnaby Public Library |x | | ||
- | | |Cranbrook Public Library | | | ||
- | | |New Westminster Public Library| | | ||
- | | |North Vancouver District Library | | | ||
- | | |Penticton Public Library| | | ||
- | | |Port Moody Public Library | | | ||
- | | |Surrey Public Library |x | | ||
- | | |Vancouver Public Library | x| | ||
- | |SirsiDynix Symphony|Greater Victoria Public Library |x | | ||
- | | |North Vancouver City Library | | | ||
- | | |Powell River Public Library | | | ||
- | | |Prince George Public Library | | | ||