Kuali OLE Electronic Resources Management Development Kristin E. Martin Electronic Resources Management Librarian University of Chicago

Section I: Life as a SME (Subject Matter Expert)

 Subgroup under OLE Select & Acquire, began in 2012  Expertise in e-resources from individuals at partner libraries  Originally under leadership of Kristen Wilson at NCSU, then Kristin Martin starting April 2013  Developed series of user stories: what are the tasks we do in our daily work and how can software help us in those tasks?  Led to ERM data model  Later incorporated licensing work done by separate team E-Acquisitions Team

As a selector, I monitor information about our resources to ensure that we are getting what we have paid for. As an e-resource specialist, I need to see all resources that are part of a purchased collection. User Story Examples As a data manager/electronic resources librarian, I need to know what work is queued up for me (when physical formats do not appear) in the acquisitions-to-access workflow. As an E-Resources Manager, I know when a resource is not activated (i.e., available) in a timely manner so I can assess the quality of service I receive from a vendor. I need to be able to schedule correspondence with vendors to follow up on requests.

Participants Face to Face Meeting October 2012 Nora Roggeveen-Sams, Kuali Project Manoj Rawa, HTC Beverly Dowdy, Duke Tim McGeary, UNC Christine Roysdon, Lehigh Mary Guth, Lehigh Lori Duggan, Indiana Mark Hemhauser, Maryland Bob Persing, Pennsylvania Holly Zerbe, Pennsylvania Katie Rizzio, Pennsylvania Kristen Wilson, NC State Emily Lynema, NC State Kate Hill, NC State Ben Heet, NC State Rob Pleshar, UChicago

 Purpose  Terms & Definitions  Specifications & Business Rules  Required Data Elements  Acceptance Criteria  Test Data Requirements  User Roles/Permissions  Routing or Workflows: Notifications or Approval  User Interface Requirements Functional Specification Writing

Early E-Resource Record Mock-Up

 Specs get uploaded for review  Acceptance criteria get translated into test cases  Bugs get reported through feedback mechanism  New enhancements get entered through feedback mechanism  Developers communicate time spent on ticket  Questions, comments, and attachments can be placed on ticket Jira Ticketing System

Platform record Jira

Jira Ticket Comment Details

Section II : Kuali OLE ERM Data Model

ERM Data Model

 Centralized place to record information about an e- resource, 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, purchasing, access, and licensing  Brings together individual electronic holdings, license information, platform details, and purchasing/payment information. ERM Data Model: E-Resource Record

E-Resource Record Main tab close-up

Detail from the “Instances” tab

 The electronic equivalent of a print holdings and item record  Contains data specific to e-resources, including:  coverage data and perpetual access dates for serials  URLs and link text  Links to the e-resource and can be managed in batch from the e-resource record  Links to a Platform record for specific information about that platform ERM Data Model: E-Holdings Record

E-holdings detail

 Platform records:  Provide a centralized location for administrative information about the platforms where e-resources are hosted  Allow easy dissemination of access problems to all staff  Vendor/Organization records:  Are linked to e-resource, e-holdings, and platform records  Provide a centralized location for storing contacts and information about organizations associated with an e-resource, whether a paying vendor or not  Both records reduce duplication of data by providing centralized storage of information related to many parts of the ERM data cycle. ERM Data Model: Platform and Vendor Record

Platform Close-up

 Changing membership in E-Acquisitions Team and developers  Changes in our desired functionality  Limitations in software ability  Effective communication with developers and project manager regarding complex situation  Providing support for complexity without letting complexity dominate the system Challenges of Development

Thank You!! Kristin E. Martin