OLE ERM Copenhagen April 12 2016 Data Model

OLE ERM Copenhagen April 12, 2016

Data Model

E-Resource Record at the Heart • • Centralized place to record information about an eresource, be it a package of titles, an individual database, collection of e-books, or something else Serves as the locus of e-resource activity A place to centralize and coordinate different workflows: subscription and purchasing, access, and licensing Brings together individual electronic holdings, license information, platform details, and purchasing/payment information.

Workflows Identified in E-Acq Group 1. 2. 3. 4. 5. 6. Trial (never fully speced out) Initial Acquisition Purchasing/payment Licensing Access Renewal/Cancellation Storage and collection of usage data and link resolver capabilities identified as needs but never speced out.

GOKb Integation with OLE

Workflow Goals • Planned to have capabilities for four sub-workflows in managing eresources 1. 2. 3. 4. Licensing Purchasing Access/Activation Renewals/Cancellations • Workflows would take advantage of routing within OLE when involving multiple departments/people • Workflows could be routed to multiple individuals or ad-hoc routed if new steps needed • Sub-workflows could occur simultaneously or in any order • Used alerts and action list to move through the process

Workflow lacks • • • High-level management view of all workflows and location of e-resources within various workflows (e. g. , Workflow dashboard) Ability to cancel/complete a workflow without completing all steps Ability to run parallel steps within the same workflow

Example: T&F SSH Package Start purchasing workflow Create e-resource: T&F SSH Collection Start licensing workflow Start access workflow Decision to purchase T&F SSH Collection Create independent eresource: T&F Titles Outside Package

Begin purchasing workflow ERM staff request title list for SSH package ERM staff reconcile title lists E-holdings and POs now appear on eresource ERM staff identify and attach e-holdings for existing subs to T&F SSH Titles ERM staff upload title list and attach to eresource record Acquisitions staff post the invoice in OLE Invoice follows routing and is approved for payment T&F Purchasing Workflow Payment information reflected on Eresource/e-holdings. Workflow complete Acquisitions staff create Requisition for bundled titles Req follows approval routing and becomes PO PO for bundle attached to T&F SSH Titles eresource

Licensing workflow Begin licensing workflow (License Request) ERM staff request copy of license and start License Request workflow Final signed license is attached to new Agreement Record Licensing Manager submits final license for official signature Licensing Manager records terms in Agreement Record License workflow complete ERM staff receive license and route to Licensing Manager negotiates license, following workflow

Begin access workflow (Access Dashboard) ERM staff verify access is turned on For bundled titles, import TIPPs to create new eholdings ERM staff link to GOKb (status: review) GOKb matched to bib records already in the catalog; brief bibs created if no match For already subscribed titles, import TIPPs that match existing attached e -holdings Brief bibs routed to cataloging staff for fuller cataloging Access workflow complete Cataloging staff catalog brief bibs ERM staff route through checklist • • Update Open. URL resolver Verify proxy Verify administrative URL Announcement to staff T&F SSH Collection Access Workflow

Challenges to OLE ERM • • GOKb integration proved challenging to implement Licensing support either over or under-developed • • • Original goal of ONIX-PL proved too complicated Simplified mapping may not have been flexible enough for libraries Difficulty coding workflows in a way that would prove both easy enough to use and complex enough to be useful Separate holdings/e-holdings created integration problems within the acquisitions system Performance problems for e-resources with 1, 000 s-100, 000 s of related e-holdings No clear path for migrating existing data into ERM and linking to GOKb

Data Model General Development Concerns • • • E-Resource is the hub of activity, but a lot of data gets fed through e-holdings, which may not fit library needs Difficulty balancing needs to provide access vs. needs for management/acquisition history Complexity of data model may end up requiring libraries to duplicate data they otherwise would avoid A lot of data had to be loaded in and out of OLE in order to keep it current No support for trials, usage data, or direct link resolution limited usefulness and meant keeping separate systems was a necessity