Monograph Ordering Working Group:

From the report:

“Might Columbia selectors be able to better streamline the ordering process by making better use of the POOF interface?”

Batch Processing Working Group:

From meetings: “Integrating LSTools into Columbia workflows”

From the phase 1 report: “The distributed batch processing model of Cornell is facilitated by the creation of LStools, which acts as a middleware interface permitting LTS staff interacting with the physical materials to also coordinate the bulk importing of the associated records.”

Non-MARC Metadata Working Group:

From meetings: “Development of MD capture & editing tool – will need outside support”

From the phase 1 report:

“The working group recommends the development of a joint-2CUL web-based metadata capture and editing tool for digital assets. This project’s logic seems to closely align with the desire to implement a common 2CUL LMS. By having a common capture and editing tool, the two institutions could work collaboratively on non-MARC projects, facilitate alignment of non-MARC metadata practices and potentially streamline one of the issues plaguing both institutions: enhancing quality of non-MARC metadata and inconsistency of field usage.

Ideally, the capture and editing tool will be able to export metadata in multiple schema and formats (e.g.: Dublin Core, VRA Core, MODS, RDF triples, CSV file, etc.) and include spell-checking and the inclusion of linked data authorities (e.g.: id.loc.gov, GeoNames, VIAF and Getty Vocabularies, when available in Linked Data). For Columbia, this tool would likely replace the need for OMEKA’s cataloging interface; for Cornell, this may replace the cataloging interface in SharedShelf.

The working group recognizes that this could require a considerable development effort and buy-in from the departments with which the Metadata Librarians / Coordinator have functional dependencies. Neither institution has a tool with the export functionality described above or that makes use of linked data authorities; if an adequate tool exists on the market, the working group would appreciate consideration into purchasing for both institutions. If locally developed, this tool could yield a shareable product for the metadata community that could be available as an open source solution. The working group envisions a multi-phase project whereby the first phase develops the tool and the second phase develops an API to publish metadata to common platforms at each institution; the creation of automated interfaces with our platforms would work particularly well if both institutions implement a common framework for storage and discovery, such as Hydra”.

E-Resources Troubleshooting Team:

From meetings: “Will need outside support for purchasing tools”, “[Decisions are] Extremely Alma dependent”, “Some potential for efficiencies w/Acq”.  

From the phase 1 report:

  • Off-campus access and variable browser configuration testing - BrowserStack - implementation underway. Both CULs had been using a product called BrowserCam until it was discontinued about a year ago. Since then, we have explored a few options to provide staff with a way to test off-campus use of resources. BrowserStack is now in use at both libraries. There is a subscription cost for BrowserStack that is currently being covered by IT units.
  • Troubleshooting tracking system - A single incident tracking system for managing all troubleshooting reports. The team is working on a features wish list to help inform our recommendations. We will consider systems that are already available in addition to other options. Both CULs have access to Jira and potentially other incident tracking systems. Some key features should be:

       LIBIT-L@cornell.edu and cul-eproblem@columbia.edu or other appropriate sources of reports should feed directly into the system to avoid re-entry.

       Easy to identify Cornell or Columbia issues

       Ability to route issues to non-e-resource staff and to communicate with vendors and patrons via the system.

       More information on troubleshooting tracking system can be found here.

  • Common ERM/LMS - To improve information access and data normalization that is essential to efficient and effective joint troubleshooting. Key possibilities include:

       Serials Solutions ERM Suite and Consortial add-on - The team is going to examine cost, implementation & migration workload, gain vs. loss regarding Alma migration to develop a recommendation whether to pursue an interim joint ERM option.

       2CUL's Alma implementation timeline will be an important variable.

  • Automated link/access checking - Callisto - http://sharpmoon.com/callisto/ - This product has to potential to improve our pro-active troubleshooting efforts by helping us identify access problems before our users report them and ensuring that IP address ranges are properly implemented by vendors. Callisto allows for a consortial view, allowing us to compare access to resources across the 2CUL partners.
  • No labels