Skip to Main Content

SUNY Libraries Consortium (SLC) 2017-2022

The SUNY Libraries Consortium (SLC) was an independent organization formed to implement the vision of the Member Libraries of the Consortium (Membership) and support SUNY students, faculty, researchers and staff.

History

Members:

  • Michelle Eichelberger, SLS, co-chair
  • Susan Davis, UB, co-chair
  • Noah Roth, Broome
  • Liz Simmons, Genesee
  • Jen Parker, Cortland
  • Ken Wierzbowski, Brockport

Charge:

The SUNY Shared Library Services (SSLS) team is interested in exploring how effective and feasible it would be to take on the management of a limited number of SUNY e-Resource Packages in the Network Zone. The Network e-Resource Task Force will focus on reviewing current interest in centralized management, determining criteria for management selection, and developing and recommending best practices for the SUNY Library community. The Task Force will begin its work in January 2020, with an expected end date in March 2020.

The Network e-Resource Task Force will investigate the following:

  • How to best manage e-Resource packages in the Network Zone, including inventory groups, import profiles, proxy considerations, etc.
  • Identifying commonly shared packages
  • What criteria to use for deciding what to manage centrally, bearing in mind limited SLS staffing and pre-existing work loads
  • How other Alma consortia manage e-resources centrally
  • Beta testing of pilot collections

Deliverables from the Network e-Resource Task Force will be:

  • Overview of what the centralized e-resource management would entail and how it will work.
    • Projected Completion Date: February 15, 2020
  • Test the pilot package and report on findings.
    • Projected Completion Date: March 1, 2020
  • Recommendations for centralized management of e-resources
    • Projected Completion Date: March 15, 2020
  • Presentation to SLC members on centralized management of e-resources.
    • Projected Completion Date: March 30, 2020

Meeting Minutes and Documentation

Test Documentation

Overview of what the centralized e-resource management would entail and how it will work.

  • Network E-Resource Task Force will determine set of criteria by which to judge proposed databases
  • If database is approved for central management, SLS staff will activate the database for fulfillment at the network level
  • Network e-resource activation will be a core service, not limited to extended service campuses
  • Network e-resource administrator will test activations with campuses to make sure access, including proxy settings and e-resource publishing, is working correctly
  • Once database has been accepted for central management, the network e-resource administrator will manage annual renewals, title changes for selective packages, etc.

Test the pilot package and report on findings.

  • In September 2019, Michelle Eichelberger worked with staff at Broome, Genesee, and Jefferson to activate individual STAT!ref titles in the Network Zone using inventory groups
  • The titles deployed successfully, were findable in an unexpanded Primo search, and worked with each campus's proxy server

Recommendations

Network E-Resource Task Force Recommendations:
 
Overview of what the centralized e-resource management would entail and how it will work.
  • Network E-Resource Task Force has provided criteria to evaluate which e-resources will be managed in the Network Zone. The SLS will use the criteria developed by the Task Force to independently evaluate all future requests for collections or resources to be managed in the Network Zone.
  • If database/collection is approved by the SLS for central management, based on the task force determined criteria, SLS staff will activate the database/collection for provision at the network level.
  • Network e-resource activation will be a core service, not limited to extended service campuses
  • Campus communication:
    • Communication from SLS/OLIS about managed packages will be timely and comprehensive.
    • Collections and databases will be proposed with the option to opt-out if the campus is not interested in participating in central management.
    • Campuses will be able to submit suggestions for centrally managed packages, via a form, to be reviewed and approved or denied by SLS/OLIS staff based on criteria.
    • Collections and databases will be identified with a "network" tag to help with access troubleshooting. The SLS will provide a communication channel to report problems with centrally managed resources.
  • Network e-resource administrator will test activations with campuses to make sure access, including proxy settings and e-resource publishing, is working correctly.
  • Once a database/collection has been accepted for central management, the network e-resource administrator will manage annual renewals, title changes for selective packages, etc.
  • The network e-resource administrator will make network-level database statistics available to campuses and will liaise with campuses interested in license information.

Criteria for central e-resource management, in order of importance:
  • Contract managed by OLIS/SLS. Justification: management by OLIS/SLS means that communication about new or discontinued titles comes directly to the office where central management is happening rather than needing to gather that information from subscribing campuses.
  • Package complexity: more complex packages, such as selective collections or single titles, are better candidates for central management. Justification: Aggregations are more efficiently managed in the IZ, as there is little maintenance required for these collections and the IZ offers members more direct control over their resources. Selective packages negotiated for groups of campuses require extensive campus work to keep up with annual titles changes. Centralizing this type of workflow would help campuses more than simple central activations of aggregator packages. Managing selective packages centrally would save campus staff time and reduce duplicate effort in individual title activation, deactivation, monitoring the CZ Updates Task List, managing local portfolios, etc.
  • Percentage of SUNY campus participation: The higher the number of participating campuses, the better, but a small group would not necessarily prevent a package from being managed centrally. Justification: it makes sense to provide central management for as many campuses as possible, but central management of all packages is not ideal for the following reasons:
    • Combining IZ usage stats and NZ usage stats is possible but not seamless [10/24/22: note that usage stats come from vendors and aren't generated by Alma/Primo so this is a non-issue. Michelle Eichelberger.]
    • NZ collections cannot be set up to be used with local display logic for general electronic services
    • Limited SLS staff time to support all packages for all campuses
Test the pilot package and report on findings.
  • In September 2019, Michelle Eichelberger worked with staff at Broome, Genesee, and Jefferson to activate individual STAT!ref titles in the Network Zone using inventory groups
  • The titles deployed successfully, were findable in an unexpanded Primo search, and worked with each campus's proxy server

Initial Proposal:
  • SLS takes on management of STAT!Ref and New England Journal of Medicine for SUNY campuses
 
Future Possibilities:
  • Add additional packages that meet the task force criteria
  • OA: centrally manage approved Open Access article-level content for SUNY Campus
  • Research centrally managing licenses in Alma for centrally managed packages

Management Known Issues

Primo:

  • Can't do display logic for NZ packages
  • Can't adjust display order for NZ packages, only for local packages

Analytics:

  • Campuses need to set up vendor and vendor stats to bring in local statistics for content managed in NZ. Management in NZ doesn't affect database admin/stats generation for campuses. Local usage will continue to be tracked by vendor.

Local Activation:

  • If campus has same CZ package or portfolio active in IZ, that will override network activation

Resource Sharing:

  • Makes ALMA Article Resource Sharing difficult as rotas only check IZ holdings