Monograph Ordering Working Group:
From the report:
"Might “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 “Integrating LSTools into Columbia workflows"workflows”
From the phase 1 report: "The “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 “Development of MD capture & editing tool – will need outside support"support”
From the phase 1 report:
"The “The working group recommends the development of a joint-2CUL web-based metadata capture and editing tool for digital assets. This project's 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 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"Hydra”.
E-Resources Troubleshooting Team:unmigrated-wiki-markup
From meetings: "Will “Will need outside support for purchasing tools", "\tools”, “[Decisions are\] Extremely Alma dependent", "Some potential for efficiencies w/Acq". 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:
...