Acquisitions: Monograph Ordering
The ordering function is an area where it's more possible to imagine an integrated environment than many other technical services functions because of the nature of an order as opposed to actually handling a physical piece. For example, Columbia could order books for Cornell, and have them delivered to Cornell, especially when we arrive at the place where we use the same library management system.
Issues to explore:
- Might Cornell be able to use its corporate Amazon account to order materials for Columbia?
- Might Columbia selectors be able to better streamline the ordering process by making better use of the POOF interface?
- Might the two institutions be able to share one ordering specialist for more difficult/challenging-to-obtain items?
For more, see this group's Phase 1 Report.
Acquisitions: Monograph Receiving
- Meet and discuss findings with the other relevant working groups (Ordering, Copy Cataloging, Batch Processing).
- Explore points of "harmony" and "discord" revealed in Phase 1.
- Critical issues to explore:
- Shelf ready
- Cataloging upon receipt
- University accounting restrictions
For more, see this group's Phase 1 Report.
Acquisitions: Print Serials
Because the requirements of print serials are so distinct and dependent on the organizational structures, we have found potential shared activities rather limited. It is hard to see how staff at the two organizations could effectively substitute for each other. However, making the organizational structures more similar (e.g., re-centralizing checkin at Columbia, discontinuing series and sets orders at Columbia) might lead to greater similarity in staff expectations and procedures. With the changes in Cornell’s handling of binding tasks, Columbia may also want to reconsider where responsibility for binding and adding is located.
The team considers ongoing exchange of information about serials in general and specific serial problems as beneficial to both institutions. Perhaps both staffs could utilize a blog or Facebook page for problem and solution sharing. Changes in handling print serials at each institution should be shared with the other.
There may also be some possibility of combining the title lists from both institutions which might result in more desirable service charges, and broader collection development cooperation.
Cornell’s documentation (certainly in the area of print serials) is notably more robust than Columbia’s, and sharing documentation and its upkeep would be very useful, although there are limits to what can be standardized between the two institutions.
For more, see this group's Phase 1 Report.
Automation & Technology: Batch Processing
To investigate and learn what batch functionalities and record load features are built in to ALMA and see how easily existing record load workflows at Cornell and Columbia can be expected to migrate.
Leaving established workflows in place, jointly experiment implementing MARC services with new vendors where practicable.
Explore the use of WorldShare Metadata Collection Manager to identify record harvesting for HathiTrust and other record sets.
To make a joint data map/dictionary of terms and MARC fields used in conjunction with record identifications for extracts between the two CULs.
Work with other 2CUL TSI groups in areas of functional overlap to coordinate phase II efforts.
For more, see this group's Phase 1 Report.
Cataloging & Metadata: Copy Cataloging
Possible documentation sharing especially related to RDA training for copy catalogers
Collaboration on general training of copy catalogers
Assessing impact of specific areas of 2CUL collection development integration on copy cataloging workflows and practices at both institutions
Possible consolidation of the efforts of the 2CUL copy cataloging working group with either 2CUL original cataloging working group or the 2CUL receiving working group
Plan for the Columbia 2CUL copy cataloging group to visit Cornell in the fall of 2013
For more, see the link to this group's Phase 1 Report on their wiki page.
Cataloging & Metadata: Database Maintenance
Obviously maintenance is done very differently at both Columbia and Cornell, but ultimately it doesn’t make a difference how each system does it as long as the work gets done. Except for a few specific maintenance processes which will need to be reviewed in later phases of this project, it may be best to keep each institution’s “database maintenance culture” similar to how they were pre-2CUL, especially since both systems would require major overhauls of maintenance procedures, policies, and personnel in order to make them work the same. Unlike many of the processes being looked at for 2CUL, large changes in database maintenance procedures will affect many staff members in libraries across both campuses.
For more, see the link to this group's Phase 1 Report on their wiki page.
Cataloging & Metadata: Non-MARC Metadata
The working group has identified some areas of possible collaboration during Phase 2 of the 2CUL Technical Services Integration; note: the order of the following list does not necessarily reflect prioritization.
Common Development of Single Metadata Capture and Editing Tool
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.
Research Data Services Collaboration
The working group recommends whenever possible, collaboration in development of research data handling and research data services, particularly as it relates to scientific metadata creation. Because support of research data services is relatively new to libraries, sharing of ideas and experiences will be extremely useful for advancement of our ability to assist patrons in this area. Research metadata support tends to be very domain specific and creating a shared knowledge base between the two institutions would benefit both, and could potentially expand upon 2CUL collaboration outside of technical services.
Formalized Consulting Framework
The working group recommends the development of a more formalized consulting framework between the two institutions. This would allow for being able to transfer consultation requests based on expertise requirements. For instance, a Cornell-based consultation request concerning MODS or OMEKA metadata could be transferred to Columbia whereas a Columbia-based consultation concerning VRA Core or Kaltura metadata could be addressed by Cornell.
Shared Documentation
The working group recommends creating a space for shared documentation related to non-MARC metadata. This would allow metadata practice at both institutions to build upon each other meanwhile providing the information needed if the two institutions align non-MARC metadata practices. Further, if the common metadata capture and editing tool is developed, shared documentation would further aid in 2CUL collaborative metadata projects.
Collaborative Training and Investigations
The working group recommends beginning cross-training for new standards. Further, the two institutions should collaboratively conduct investigations of new tools and standards for metadata creation and management. Co-leading investigations could yield shared tools and practices. Aligning investigations and training could save a net-effort across the two institutions as compared to conducting two separate investigations/trainings.
Metadata Working Group (MWG) Reconfiguration
The working group recommends a reconfiguration of the Metadata Working Groups (MWG) at each institution. Each MWG would engage both institutions in metadata-related forums via Skype, Polycom or Webex. Further, a Columbia representative could join Cornell’s MWG Forum Steering Committee and a Cornell representative could join Columbia’s MWG. Currently these forums occur at Cornell once-per-month during the academic year and are publicly announced and attended; a steering committee, commonly referred to as Metadata Working Group, plans the forums. To view past forums, see: https://metadata-wg.mannlib.cornell.edu/. At Columbia, the Metadata Interest Group meets in irregular intervals, on average every two months. Meetings are planned by the Metadata Coordinator. Events are only announced to a metadata e-mail list, though anybody is welcome to attend or request to be added to the distribution list. In addition, Columbia’s Digital Projects Librarian also hosts “Digital Library Seminars”, which are open to the public.
If non-MARC metadata practices at the two 2CUL institutions extend to become fully-integrated, a joint functional-MWG should form. This functional-MWG would be a separate but parallel entity than the current forum-based MWGs; a separate steering group should guide the effort of the forum-based MWG.
For more, see this group's Phase 1 Report.
Cataloging & Metadata: Original Cataloging
Below are some areas that we have identified for further exploration. Collaboration in some areas (e.g. training) can proceed more or less immediately, while others will need careful planning. We propose to continue to develop this list as we proceed with Phase 2.
- The Original and Copy Cataloging groups held joint discussions during Phase 1 and we recommend combining these two groups for Phase 2. This group will need to work closely with the acquisitions and batch processing groups to make recommendations on workflow and related issues such as cross-training.
- Training (and, where appropriate, documentation)
- Developing guidelines for collaborative cataloging covering such areas as balancing demand and capacity, workflow and handoffs, clarifying expectations, communication, etc.
- Identifying areas where changing collection priorities (e.g. as a result of collaborative collection development) may have an impact on cataloging workload
- Identifying and evaluating vendor services of potential interest, e.g. vendor-supplied cataloging, shelf-ready processing, vernacular data, etc.This may progress to joint negotiations with vendors and establishing common service expectations
- Representation on external bodies (e.g. CONSER) and associated activities including reporting and voting
- Joint policy and standards development: this needs to take place within a framework that will accommodate differences due to contrasting collection priorities and service expectations
- System-related services, including batch processing, reporting, troubleshooting, and their impact on workflow
For more, see this group's Phase 1 Report.
E-Resources: General and Troubleshooting
A sub-group of the eResources Group will be analyzing the knowledge bases of systems currently and/or potentially used. Selection and shared implementation of joint systems will be critical to realizing an integration of eResources activities.
A critical part of this review will need to be the requirements demanded by the University level financial services units. The number of institution specific procedures or policies for managing funds and payments will have a major impact on our ability to blend and streamline workflows. During TSI and the implementation of a new system it will be important to look critically at procedures and practices and where common ground and efficiencies would be found.
The team has begun working on Phase 2 objectives, particularly in the areas of better harmonizing points of discord and recommending tools to enhance the potential for joint 2CUL troubleshooting. A few of the eventual recommendations we will be making will be dependent on other 2CUL efforts, such as the timeline for a joint LMS. Some of the specific topics or tools we have been exploring are:
- 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.
- Workflow and information access - We are working to better organize and eventually consolidate useful information about policies, procedures, and best practices.
- Develop guidelines of what to handle at 2CUL level, what to route to "owning" library.
- Provide a dashboard of common responses, access to troubleshooting tools, and contact information for us4e by all troubleshooting staff.
- 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.
For more, see the E-Resources and E-Resources Troubleshooting Phase 1 Reports.