My place of work, OhioLINK, is part of a larger group called the Educational Technology Division of the University System of Ohio. In that capacity, we’re seeking two senior repository software developers to work in our downtown Columbus, OH, office.

The position description can be a little tricky to get to — the Ohio State University jobs website does not allow deep linking into job descriptions — so I’m reproducing the entire description here:

Position Information

Number of Positions Available 1     Both current Ohio State employees and the general public may apply for this unclassified professional position.       University Title Senior Systems Manager-Not Sap   Working Title Sr. Repository Developer   Department Office of Research-OARnet   Department Location Columbus   Requisition Number 347544 [Also requisition number 347545]  Summary of Duties Supports software development operations for Ohio Academic Resources Network (OARnet), in collaboration with the Chancellor for the Ohio Board of Regents (OBR) and the University System of Ohio (Education Technology Division), in accordance with university policies, goals, and objectives; participates in regular operation of SCRUM-based software development team; identifies project development requirements in conjunction with stakeholders, including Product Owner, community representatives and SCRUM team lead; develops technical solutions to meet the business objectives of product requirements in accordance with established OARnet/OBR software development standards; divides technical solutions into component-level features; assigns, monitors, and reviews component-level feature development, testing and integration tasks performed by team members; serves as technical SME for application development environment; performs investigation and tracking of industry trends and exploration of advanced technologies; serves as an expert consultant within and outside OARnet, and significant participation in advising and planning committees and task forces; designs, plans, and coordinates development/construction of systems; serves as a mentor to other development associates.   Additional Information Successful completion of a background check required.   Required Qualifications Bachelor’s Degree in computer & information science or an equivalent combination of education and experience; extensive (5 years) Java development experience involving DSpace/Manakin, Cocoon, XML/XSLT and HTML/CSS site creation; considerable experience (3 years) with JBoss Application Server; considerable experience (3 years) with Linux/Unix, Perl, shell scripting; experience (1 year) with Log4j, JUnit, Maven and Apache Commons.   Desired Qualifications Master’s of Library Science degree; experience with digital archive projects including metadata schema creation.   Target Salary $76,000 – $84,000 Annually   Job Category Information Technology (IT)   Job Appointment (FTE%) 100%   Full/Part Time Full Time   Temporary or Regular Regular   Posting Start Date 10-09-2009   Posting End Date 10-25-2009   Does this position accept online applications? Yes   Faculty Application Instructions

OARnet is a constituent of the University System of Ohio Educational Technology Division, and OARnet’s administrative agent is Ohio State University. To apply for the position, go to Ohio State University’s Job Site, select “Search Postings” and use either requisition number 347544 or 347545.

On Friday, OhioLINK released an addendum to its inquiry for a comprehensive discovery layer that answers questions submitted from potential bidders. This is a distilled version of that addendum — posted here with the desire to reach others that may be interested in submitting a bid. Please note that this posting is not the official call for proposals nor the official addendum (it isn’t even the entire addendum). Nothing said here binding on the proposal process. If you are interested in making a proposal for a solution or part of the solution for what we are seeking, please contact Mary Pasquinelli, Sr. Purchasing Agent at Wright State University (OhioLINK’s administrative agent), and reference ITN 601908 (Room 301 University Hall, 3640 Colonel Glenn Hwy., Dayton, Ohio 45435, phone 937-775-2411, FAX 937-775-3711, email: mary.pasquinelli@wright.edu).

• Section 22.2 Specific Features, subsection 1.4.2, Page 24: Subsection 1.4.2 states: “The system supports delivery resolver availability data embedded into facet(s).” Please explain what this means.

A facet must be generated for broad cross-sections of availability. For instance: “Online” (digital copy available), “On-Campus” (on-shelf status in the patron’s institution/branch), “2-3 Day Delivery” (as in PCIRC/INN-Reach requesting), “2-3 Week Delivery” (as in traditional ILL).

• Could you elaborate on the delivery resolver? What already exists versus what we envision as being part of the solution?

OhioLINK is seeking a delivery resolver that will bring together all existing modes of delivery to the user – what is available now (through digital delivery), what is available today (on campus), what is available in a couple days (through INN-Reach), and what is available in a couple weeks (through Interlibrary Loan). The delivery resolver must be flexible enough to handle existing modes of delivery as well as enable the addition of new modes of delivery (for example, possibly a subscription to the Google Book Search corpus), and distill all of the complexity of the delivery options into a single link for the user.

OhioLINK already has a requesting and delivering system for physical items through the INN-Reach software from Innovative Interfaces. We have a link resolver and a knowledge base for access to electronic articles. The proposed solution need not replicate/duplicate these existing services.

• Will the metadata for these databases come directly from the database vendors, in varying formats, or will it come as a single set of data/single format from OhioLINK and the Electronic Journal Center – in other words, will the data come from the database vendors directly, or will it come out of the Electronic Journal Center as a single set?

Metadata for the databases listed in section 12.2.1 will come directly from the sources (database vendors as well as other sources such as the Electronic Journal Center, Electronic Book Center, and the Digital Resource Commons) in a variety of formats.

• P. 11-13, Sections 12.2.1 and 12.2.2 – Regarding the desired content listed: How will you determine what content is part of your unified index and what is searchable via your federated search engine?

It is OhioLINK’s desire to put as much into the unified index as possible. To the extent that OhioLINK can get content from the provider, it will be added to the unified index. The federated search engine will be a fallback for those providers that cannot or will not offer OhioLINK a license to load the data into the unified index.

• Regarding section 22.2 Specific Features, of the Vendor Response Form, in 2.3: “Calculates/resolves a persistent identifier for each record retrieved through the federated search engine”. Please provide further description of what is meant by “persistent identifier”.

Views of records obtained through the federated search engine must be repeatable. This requires the formation of a persistent identifier that can be used in permalink URLs in such a way that enables subsequent users to get back to the same record. This is needed in order to put URLs for records into course management systems and other locations.

• What if some of the databases listed as part of the unified index end up being accessed through a federated search (e.g., SportsDiscus) and some databases in your federated search list become part of the unified index? Can you please discuss how you would handle this?

OhioLINK expects some fluidity in the mixture of databases in the unified index and federated search components. Volatility will come in the form of updates/reloads of source data, the addition and removal of licensed databases, additions of new member data (e.g. local institutional repositories, special collections projects, etc.), and capabilities of data sources to start providing (or no longer providing) data to OhioLINK for the unified index. The candidate solution for the unified index component must be able to load and unload data to match these situations. It must be possible to add and remove data sources in the federated search component. The user interface must be capable of mapping its permalinks for records from unified index sources to federated search sources, assuming the existence of common unique identifiers between the unified index source and the federated search source.

• P. 5, Section 3.1 – This section states: “OhioLINK is evolving its suite of services in the face of changes in user expectations.” Are there predominant user groups you are interested in, and do these groups have unique needs?

Based on the sheer quantity of users, the predominant user group is undergraduate students. Studies show that this user group is focused on finding highly relevant answers quickly. These users also tend to cast a broad search initially, and then refine it as needed. Students are also likely to be at websites other than the libraries, so there is a strong need to insert the start of the search process in websites such as course management systems, campus portals, and departmental websites.

• Do you envision that the vendor will take over the responsibility for negotiation of formats and schedules from the data sources or do you see OhioLINK staff still playing a role in acquiring the data and the vendor simply supplying an interface to put the data into the system?

As originally envisioned, OhioLINK would continue to be involved in receiving the metadata and loading it into the system. However we would consider a scenario in which the solution provider did that on our behalf – with the exclusion of the licensing. Depending on the proposed system, it may also be efficient in terms of cost and effort for the solution provider to negotiate formats and delivery schedules with the data source on OhioLINK’s behalf, and OhioLINK staff would be responsible for the ongoing loading of data that meets the agreed upon format and schedule.

• Once a user executes a search in the membership of OhioLINK, is it anticipated that there will be availability information from each of member institutions?

Yes. Whether or not an institution has rolled out the discovery layer interface to its constituency, the proposed system must look for availability of items at that institution. This information is available now in the form of PCIRC status at the OhioLINK INN-Reach catalog.

• Can you give a sense of average or peak user searches in OhioLINK?

OhioLINK cannot currently track use comprehensively across its many resources, so we do not have this data. We do have high-level statistics, but we do not warrant that this would be representative of actual use. For the past calendar year, OhioLINK users conducted around 30 million searches. 2.9% of these searches – approximately 870,000 – were conducted in the peak month. 19.15% of these searches – approximately 167,000 – were conducted on the peak day of the month.

Note that the goal of this ITN is to deploy a system that is more useful to users; thereby drive more traffic to use these library resources. A proposed solution must be able to scale readily as demand grows and shrinks. We would anticipate this might entail clusters of servers and requisite load balancers.

• How do you expect to handle db sources that are subscribed to by member institutions?

It is OhioLINK’s desire to handle as much as possible in the unified index even if not all member institutions have access to all resources. This requires appropriate authentication (whether by IP address or by login) and access controls for this data loaded into the unified index. In addition, the federated search must consider authentication when selecting remote databases that receive a broadcasted search.

• For 3rd party records or vendor records that member institutions do not have the rights to load to OhioLINK, how do you expect those records to be served here?

These records would be harvested from the local catalog and would be handled as if they were a database for which authentication was required (e.g. a locally-subscribed database).

• Question 3.10.1 of the vendor response (page 26 of the ITN) says, “By default, display federated search results below unified index results.” What does “below” mean? At the end of the screen or separate?

“Below” is an overly prescriptive word. It is anticipated that the unified index will return records in orders of magnitude faster than the federated search engine. What is desired is the results from the unified index are immediately displayed for the user with a portion of the results screen reserved for dynamic updates of summary/progress from the federated search engine. This requirement says that results from the federated search will be presented on a different screen from the unified index results. Question 3.10.2 of the vendor response (“Upon user request, integrate unified index and federated search results into single display”) represents the ideal scenario, where records from the unified index and the federate search engine are combined, de-duped, and re-ranked onto a single display.

• Regarding integration of federated search with unified index results interface. Do you want a description of an interface of the federated search separate from unified interface?

We want to know how the federated search component will integrate with the user interface. The user interface will handle the higher-level functions – result set operations, record marking, permalinks, etc. – and the user interface will get records from the unified index and federated search components. As such we are not envisioning a separated federated search engine user interface. A response needs to indicate how the federated search component will integrate into the overall user interface.

• Will you be requiring library pricing or centralized pricing?

OhioLINK does not require a specific pricing model. The model needs to be compatible with our objective to offer a unified discovery layer for all OhioLINK members. The solution will be purchased as a group.

• Do you require that the vendor host the solution or OhioLINK host the solution?

As originally envisioned, OhioLINK would host the system on its own servers. (See section 12.4 (The OhioLINK systems environment) for details on OhioLINK’s requirements for services.) Notwithstanding that, OhioLINK would consider a solution physically hosted by the vendor.

• Is there a preferred timeline for deliverables?

The implementation timetable is a function of the approval timetable and the complexity of the proposals. Ideally, we would anticipate bringing up the initial discovery layer deliverable for the next school year (starting roughly August 15, 2009). The implementation at that time might only be some of the eventual components and sources to be included. We would consider an incremental build-out.

• Is there a sense that this will be a phased implementation? Is there a desire to see it all happen at a hard launch? Is there a sense that the institutions will join gradually or that member institutions will all go live on a single launch date?

We are interested, of course, with having as complete and robust a system as early as possible. To the extent that one proposal provides a realistic but more rapid implementation, this will be looked upon favorably. Without seeing the implementations proposed it is impossible for us to determine how individual libraries will come online- whether all together or in some phasing. From a data sources perspective, we would anticipate that sources would be added gradually as each is profiled and loaded.

An exception to any phased rollout plan is the display of the availability of a physical item from a member institution. When the system checks for the availability of physical items, such a check must be comprehensive across all members of OhioLINK that hold an item, not just a subset of sites.

• Regarding section 22.5 Secondary Evaluation Elements, in item 9.7: “Can you provide a full-feature trial using OhioLINK data?” Could you specify what data?

The data would consist of the candidate solution harvesting MARC records from the ILS, harvesting records from OhioLINK’s OAI-PMH servers (dSpace, ETD center), and loading records from index and abstract databases for which OhioLINK already has the data.

Note, that the full-featured trial is not required in the ITN response due on December 15, 2008. OhioLINK will work with zero, one or more proposed solutions to build the full-featured trial in the course of evaluating the responses.

• Section 12. Specifications, subsection 12.2.1, Pages 11-13: Subsection 12.2.1 describes sources to be included in the Unified Index. Can you please provide file formats, estimated update frequency, and whether regular (annual) reloads of the datasets will be required for each of the sources listed in this section?

It is not possible to answer the format and frequency schedule parts of this question because such parameters have not been set for a significant number of sources. There are sources (at least PSYCinfo and Compendex at present) that require annual reloads.

Earlier today, Wright State University issued an invitation-to-negotiate¹ for a discovery layer on behalf of OhioLINK. This post contains the details specific to the project, and I’m posting it here with the desire to cast a wide net of parties that may be interested in responding. In doing so, please note that this posting is not the official call for proposals, and nothing said here binding on the proposal process. If you are interested in making a proposal for a solution or part of the solution for what we are seeking, please contact Mary Pasquinelli, Sr. Purchasing Agent at Wright State University, and reference ITN 601908 (Room 301 University Hall, 3640 Colonel Glenn Hwy., Dayton, Ohio 45435, phone 937-775-2411, FAX 937-775-3711, email: mary.pasquinelli@wright.edu).

Introduction and overview

• Provide a unified, general search environment for the entire consortium for all types of content in the local integrated library systems, institutional repositories (including, but not limited to, those housed in the Digital Resource Commons), the OhioLINK Electronic Journal and Electronic Book Centers, the Electronic Theses and Dissertations service, consortially-supplied databases, and locally subscribed databases for each individual OhioLINK institution.
• Supplement, not replace, existing search interfaces for specific content types.
• Provide basic and advanced search features, flexible search session and user profile features, and rich export options.
• Provide a search experience closer to that of common Internet search engines, closer to the end-user’s daily online reality.
• Incorporate modern Web 2.0 interface features like faceted searching, tag clouds, end-user tagging and ratings, and search history breadcrumbs.
• Deliver the appropriate copy (electronic or physical) requested by users while hiding the varied and intricate nature of library services such as Open URL, OhioLINK PCIRC, and interlibrary loan.
• Make all of the above available to non-library service points/systems such as campus portals and learning management systems.

OhioLINK believes the best course of action to provide this service is to build a pre-computed index of as much metadata as possible while using a federated search tool to interrogate remaining databases for which metadata is not available for pre-indexing.  Results from the pre-computed index and the federated search are available to the new end-user library interface proposed herein as well as to other non-library services points.  Users are led to the appropriate copy through a delivery resolver.  These four components make up the envisioned system:

Unified, Pre-computed Index

Federated Search

End-user Interface

Delivery Resolver

Modularity and interoperability

Any respondent can respond to any or all portions of the project. Respondents who address some subset of system components, but not the complete system, must explain interactions and standards compliance.  They must explain how each module interacts with other vendors’ products, describing standards, APIs, and any other appropriate aspects of interoperability.

The OhioLINK authentication environment

User authentication: PCIRC. OhioLINK’s PCIRC service is based on the Innovative Interfaces INN-Reach software. Users identify themselves to this system based on a combination of a barcode/unique-identifier index, a fuzzy match of the user’s name, and an optional PIN.

User database. OhioLINK does not operate a union database of users from its member institutions. Instead, OhioLINK relies on member institutions to authenticate users based on local campus mechanisms (whether through a Shib-IdP or by supplying attributes to the OhioLINK-hosted Shib-IdP). Several existing OhioLINK services have personalization databases that are created in an ad-hoc manner by users at member institutions. The ideal candidate solution under this ITN would leverage Shibboleth attributes from the IdP (e.g. Shibboleth Targeted-ID or eduPersonPrincipleName) as a key into a database of user personalization, as opposed to forcing the user to create an account specific to the candidate solution.

The OhioLINK systems environment

Candidate solutions that use PostgreSQL or MySQL as a relational database management system are preferred. Oracle is acceptable.

Candidate solutions that use Apache HTTPD and/or Tomcat are preferred. OhioLINK strongly prefers systems that allow its technical staff to control the configuration of the HTTPD and Tomcat services.

OhioLINK prefers installations of software on servers controlled by OhioLINK and/or its member institutions. Software-as-a-Service (vendor-hosted implementations) will be considered, however.

The dataset of MARC data for member-curated collections comes from 63 discrete installations of Millennium systems from Innovative Interfaces. Most MARC records from these systems are aggregated into a Millennium-based union catalog run by OhioLINK using the INN-Reach software. Since some records are unique to institutions, an ideal candidate solution will harvest bibliographic and holdings records from each of these installations rather than relying on the aggregation of the OhioLINK union catalog. Candidate solutions are expected to integrate into the PCIRC service at the union catalog.

Footnotes

1. Invitation to Negotiate: A competitive process whereby suppliers and contractors have an opportunity to initially submit pricing proposals for consideration. Once reviewed, the University has the opportunity to determine which proposers it wishes to conduct negotiations with for the purpose of arriving at the terms deemed to be in the best interest of the University and OhioLINK.

The Ohio Library and Information Network (OhioLINK) is seeking a hard-working, analytical individual to participate in the creation and maintenance of our internationally recognized set of online library information services, with special focus on the Ohio Digital Resource Commons. OhioLINK serves the higher education population in the State of Ohio with over 85 college and university member institutions.

The position requires a four-year degree in Computer Science, or a graduate degree in Information or Library Science, or equivalent technical experience. The candidate should have strong programming skills in languages such as Java, and should be comfortable working in a Unix/Linux environment with open source software. Experience with the following is highly valued: Digital Repositories, Cocoon, Apache Tomcat, XML/XSLT, PostgreSQL. Experience with the following is desirable: DSpace/Manakin, HTML/CSS site design, metadata, Subversion, Perl, shell scripting.

Salary:  $49,000 minimum

If you are interested in this position, please send a resume, a summary statement of experience, and an indication of your salary expectations to resume@ohiolink.edu.

The text was modified to update a link from http://www.ohiolink.edu/member-info/ to http://www.ohiolink.edu/members-info/ on January 13th, 2011.

Applications are invited for two positions at OhioLINK: an Assistant Director of Library Systems — User Services Development and an Assistant Director of Electronic Licensing. OhioLINK is a consortium of Ohio’s college and university libraries and the State Library of Ohio. It serves more than 600,000 students, faculty, staff, and other researchers at 87 institutions. OhioLINK provides a multitude of services including over 100 databases consisting of bibliographic, electronic journals, electronic books, images, videos, and audio files. For more information about OhioLINK, see http://www.ohiolink.edu/

Assistant Director of Library Systems — User Services Development

The ADLS – User Services will work closely with the Director of Library Systems, with OhioLINK staff, and with personnel from OhioLINK member institutions in a leadership role in developing and maintaining current and new OhioLINK services from the user experience perspective. This job will provide consultation, direction, and support to the User Services Committee, whose members come from primarily reference department positions at member institutions.

In other capacities, this position also serves as the primary liaison to new libraries joining the OhioLINK consortium, as principal liaison to the 2 Year Colleges and Independent Colleges and provides troubleshooting for member libraries in resolving day-to-day access problems. A full job description is available.

Review of resumes begins April 7th. Resumes accepted until position is filled. To apply for this position, please send resume and three references to resume-usd@ohiolink.edu.

Assistant Director of Electronic Licensing

The Assistant Director of Electronic Licensing will be responsible for taking the leadership role in the planning, management, evaluation, and licensing of shared electronic information resources by the OhioLINK community. Working closely with the Executive Director, Office Manager, and in liaison to the Cooperative Information Resources Committee (CIRM) this position: assumes a lead role in negotiating license terms and pricing for shared electronic resources with vendors; establishes and coordinates with the Office Manager the invoice processing through OhioLINK and its fiscal agent to member libraries for annual renewals and new licenses for shared electronic resources; assumes the lead role in the creation of and agreement by members to cost sharing models appropriate for each share electronic resource; manages, monitors, and projects the OhioLINK financial resources for shared electronic resources; and as liaison to the Cooperative Information Resources Committee (CIRM) works interactively with the chair on the agendas and overall management of the committee’s activities. A full job description is available.

Review of resumes begins April 7th. Resumes accepted until position is filled. To apply for this position, please send resume and three references to resume-el@ohiolink.edu.

The Ohio Library and Information Network (OhioLINK) is seeking an energetic, creative individual to participate in the creation and maintenance of our internationally recognized set of digital library and electronic information services. OhioLINK serves the higher education population in the State of Ohio with service to over 85 colleges and universities.

The position requires a four-year degree in Computer Science, or a graduate degree in Information or Library Science, or equivalent technical experience. The candidate should have strong programming skills including experience with Perl and Java, and should be comfortable working in a Unix/Linux environment with open source development tools. Experience with the following is highly desired: Apache Tomcat, JSP, XML, XSLT, SQL, Eclipse IDE. Experience with the following is desirable: Cocoon, DSpace, Fedora Digital Repository, aspect-oriented programming.

Salary: $49,000 minimum

If you are interested in this position, please send a resume, a summary statement of experience, and an indication of your salary expectations to resume@ohiolink.edu.

As a part of work for an OhioLINK strategic task force, I have been exploring the creation and operation of regional/collaborative/shared digitization centers. This is a report of findings to date after an open call for information. The report is structured with questions to be explored when considering a regional digitization center followed by narratives from conversations with the Collaborative Digitization Program (formerly the Colorado Digitization Program), the Mountain West Digital Library, and the Ohio Historical Society. My thanks go out to Leigh Grinstead, Liz Bishoff, Karen Estlund, Angela O’Neal, and Phil Sager for their assistance.

I am still interested in talking with collaboratives about similar programs, both “on the record” and in private conversations. Please get in touch with me if you would like to chat.

Questions for Exploration

1. Who does the digital conversion? Is it staff at the hosting institution (where the equipment is located), or does the institution contributing the materials perform the scanning operation at the host institution?
2. Where and when is the description done? Description of the digitized item was universally done by the contributing institution, but the location (at the scanning center or at the contributing institution) and timing (before conversion, during conversion, or after conversion) vary. Answers to the first question — whether contributing staff members are performing the conversion — affect this question.
3. Is contribution of materials to the Ohio Digital Resource Commons required? If the regional scanning center is used to digitize materials (or in the case where the consortium is subsidizing a scanning service to perform the digital conversion), what conditions are put in place for contributing those materials to the central repository.
4. What is the cost structure for use of the regional scanning center? Options range from complete subsidy by consortium (most notably when the CDP funded the equipment at their regional scanning centers) to contributing institutions being charged at cost recovery rates by hosting institutions. There can be various cost structures applied, such as a consortial subsidy for equipment and training with labor supplied by contributing institution or contracted from hosting institution.
5. What training is offered? Topics for training range from optimal use of digitization equipment to digitization project planning to metadata creation standards. The training can be based on group instruction, one-on-one consultation with contributing institutions, or a combination of both.
6. Who will fill the role of “metadata editor”? The need for a collective expert in metadata creation was found in many of the projects. This person is typically charged with training contributing staff on the appropriate use of local metadata conventions, coaching individual staff on particular projects, and reviewing records that will become part of a consortial database.

Report from the CDP

The original climate that generated the interest in scanners was one where institutions did not want to outsource digitization because they didn’t want the materials leaving their direct control. The CDP, on the other hand, did not want institutions to buy cheap scanners that would result in lower-quality scans. The CDP purchased the scanners ($2,500 each, in 1999 dollars) plus desktop workstations and created a training program for the use of the equipment. The center provided the location for the equipment and hands-on assistance with using the equipment; it was incumbent on the staff at the institution with materials to be digitized to perform the scanning themselves. Before using the equipment, those performing the scanning had to attend a CDP “Introduction to Digital Imaging” training session on the proper use and techniques for obtaining high-quality images. Scanning projects that received CDP funding had priority over other users of the equipment, but there was little contention for the equipment at the centers. Descriptive metadata could be keyed at the time of the scan; CDP provided a web-based template (called “DC builder”) or staff could use their own system (an ILS, ContentDM, etc.). Contribution of the associated metadata to the CDP union catalog of metadata — Heritage West — was required for CDP-funded grant projects. Images were locally hosted.

In 2003, the CDP conducted an evaluation of the scan centers in the form of focus groups. They found two different responses. First, institutions on the western slopes of Colorado made much heavier use of their scan centers. These institutions tended to be smaller and/or economically disadvantaged, and the availability of the hardware and software to conduct the scanning operations was more critical. In front range libraries, where institutions tend to be better-funded, the centers were not as heavily used for projects and tended to be used for training and demonstration sites; these participants felt that the greatest value in the CDP came from the professional networking and training opportunities the locations, the grants that the CDP provided and the creation of the best practices and website that brought all this together.

The regional scan centers are not used today. The primary reason is the diffusion of experience within the community that was spurred by the early success of the centers. As funding cycles continued, institutions purchased their own equipment (generally replicating the equipment at the centers) so as avoid the need to transport materials and staff to a regional center for larger projects. The focus of grant funding within CDP also shifted from image-based collections to EAD and sound collections. There is still an “Introduction to Digital Imaging” workshop, but the focus is now on requirements for in-house equipment and/or what to seek from a vendor in an RFP. The imaging workshop is typically taught as part of a three-day workshop series with an “Introduction to Digital Project Management” (storage, preservation, handling socially sensitive materials, how to display them) before and “Introduction to Metadata” (focused on Dublin Core) after. The biggest issue facing the consortium now is oversized scanning; only the very largest university library would have this kind of equipment.

The Colorado model of teaching staff at the institution on the use of the equipment along with the creation of regional scan centers was picked up by several states: North Carolina; Alabama; Kansas; Missouri; and Wyoming (except that regional centers were not practical due to the wide population dispersion). Tennessee is working under a current IMLS grant to build three regional center plus a suite of mobile equipment.

Liz suggests that we should look for ways to support collaborative efforts within the institution with museum and archives on the campus. The Florida Center for Library Automation (FCLA) has a program in place where the local university library is the contact in partnerships with public libraries and local museums.

Leigh noted that in recent years, CDP projects include a “metadata editor” that is hired to look at record quality and work with individual institutions to improve records. Having a metadata editor, someone familiar with the CDP guidelines and the field in general, look at four or five records at the very early stage of a project is critical to the success of the quality of the rest of the project. In a recent project, nearly half of the partners were going to export records out of a local collection management system. It was discovered that the records were not consistent; local implementation/practice of cataloging standards has a higher overall impact than community best practice. Having a local cataloger participate on the team migrating the records from a local system to a central system is key to success.

Mountain West Digital Library

Content is ingested into the MWDL either through digital conversion centers at the regional institutions or through the efforts of the contributing institution. The regional institutions perform digital conversion for contributing institutions at cost-recovery rates. These regional centers use the equipment and staff at the hosting institution, and are very busy at times resulting in difficult choices to balance needs of the host institution with that of requests from other institutions.

The regional centers also conduct on-site training and technical education at contributing institutions about best practice for digital conversion. The on-site program includes a technical evaluation of the equipment to be used to ensure that it can produce conversions that meet the minimum requirements for the MWDL. In the course of this evaluation, staff at contributing institutions are taught some technical aspects of scanning such as the actual DPI scanning capabilities of the hardware versus interpolated resolutions (and why this is important). Staff also receive an introduction to Photoshop for de-skewing and other standard practices. They also are instructed in the Western Standard Metadata Best Practices. This hands-on approach — with the contributing institution’s people, equipment and materials — enables strong connections between the contributing institution and the hosting institution. It makes the contributing institution feel like a part of the larger program. Most contributing institutions with local digital conversion operations will FTP files to the ContentDM server at the regional institution; some institutions contribute materials through the transportation of a portable hard drive.

Each regional hosting center is responsible for the digital preservation of the material on their server. At this point there is no common agreement across the MWDL for standards on digital preservation; this is an area of work to be addressed in the near future by the cooperative.

The cooperative is starting work in several new areas. First is the digital conversion and posting of oral histories from contributing institutions. While it is anticipated that such resource will be highly valued, quick progress on this project is hampered by the same permission problems that face similar projects with relatively old audio. The cooperative also has a state LSTA grant for a Utah institutional repository with a portal connected to the MWDL. The state archives are also beginning a program to post state government documents, including items related to the Olympic Games held in Utah. The hands-on approach to training staff at contributing institutions is very labor-intensive and uneven across the project participants. MWDL is in the process of hiring a program director, and a component of that job description is to provide this kind of training across the project.

Ohio Memory Project (Ohio Historical Society)

OHS staff will work with contributing institutions on a one-on-one basis as well as conduct workshops on introduction to scanning. Many of the participants are from contributing institutions that have had staff changes and the new staff want to know how to use the equipment purchased during the grant-funded phase of the project. There is also a desire for more advanced training, such as Photoshop basics.

OHS staff recognize that a compromise is needed between institutional capabilities for scanning and the very best practices in the field. They have found it hard to establish and mandate an absolute standard for the parameters and quality of digital scans. Institutions that scan their own materials are responsible for their own storage and preservation.

This year has seen the release of two personal repository services: http://PublicationsList.org/ and the U.K. Depot. These two services have an admittedly different focus, but I think it is still interesting to compare and contrast them to see what we can learn.

The Depot

The deposit interface, for those putting content directly into the centralized Depot repository, has four main stages. First, the “Type” stage, specifying whether the object is an article, a book chapter, or a conference paper:

Next, the “Upload” stage, where one can upload the file and supply a few more properties:

Then the “Details” stage, where the descriptive metadata (minus the controlled vocabulary subjects — that comes in the next screen) is input:

And finally, the “Subjects” page, with an AJAX-driven expanding-and-collapsing hierarchy of subjects:

To retrieve contents from the repository, there is a “browse” interface for looking by ‘year’ or by ‘subject’ — no other browse facets and no search interface. The Depot was just formally released this month, so I would bet that functionality like that is in the works.

PublicationsList.org

The single item entry page is a just-the-facts interface. Note that the content hosting service is only available to those who have upgraded to the “Publications List Professional” version (which costs £9.99, or approx $20/€15, per year).

The system can also accept a variety of citation manager file formats for bulk entry. (See snapshot to the right.) PublicationsList also has a built in search-and-select interface to PubMed for finding publications matching your name and automatically populating the metadata fields in your personal citation.

Then end result is a web-based bibliography with links to the publications (either hosted on PublicationsList or on other sites). The free version is hosted on PublicationsList.org (see the service founder’s page as an example) and the professional version can embed the publications list in your own page.

PublicationsList does provide discounts and additional functionality for groups (such as departments, research centers, etc.).

Observations

The one-stop, redirection service in The Depot is a good concept, too. If a researcher wanted to deposit their content in a repository and they weren’t sure if their institution had a repository to hold it, OhioLINK would be a natural place to look for a content hosting service in the state and we could redirect the author to the appropriate location on a campus. OhioLINK could also be playing the role of repository-of-last-resort for Ohio academic researchers by providing a space and services for published content, whether or not the institution in question has set up a formal repository space on the DRC.

Footnotes

1. For a really good discussion of that problem, see Davis, P.M., & Connolly, M.J.L. (2007). Institutional Repositories: Evaluating the Reasons for Non-use of Cornell University’s Installation of DSpace. D-Lib Magazine, 13(3/4). Retrieved March 14, 2007, from http://www.dlib.org/dlib/march07/davis/03davis.html.

OhioLINK is engaged in building a “trusted digital repository” on behalf of its membership. As we build it, we want to have an understanding of what “trusted” means, and so we are engaging in an audit process to assess whether we can claim to be trustworthy. This process is panning out to have four major phases:

1. Research common and best practices for preservation.
2. Evaluate the OhioLINK policies and processes against common and best practices.
3. Perform a gap analysis between where we are now and where common and best practices suggest we should be.
4. Propose and adopt policies and processes that get us closer to the ideal common and best practices.

This is a report at the end of phase 1. Earlier this year, two major reports were released that address how one measures a “trustworthy repository.” The two reports are summarized below, followed by a recommendation.

Trustworthy Repositories Audit & Certification: Criteria and Checklist

The nestor working group says a trusted, “long-term digital repository is a complex and interrelated system” (nestor 2006). However, more than just the “digital preservation system” drives the management of the digital materials. In determining trustworthiness, one must look at the entire system in which the digital information is managed, including the organization running the repository: its governance; organizational structure and staffing; policies and procedures; financial fitness and sustainability; the contracts, licenses, and liabilities under which it must operate; and trusted inheritors of data, as applicable. Additionally, the digital object management practices, technological infrastructure, and data security in place must be reasonable and adequate to fulfill the mission and commitments of the repository.

A trusted digital repository will understand threats to and risks within its systems. As articulated by Rosenthal et al. (2005), these potential threats include media failure, hardware failure, software failure, communication errors, failure of network services, media and hardware obsolescence, software obsolescence, operator error, natural disaster, external attack, internal attack, economic failure, and organizational failure. Constant monitoring, planning, and maintenance, as well as conscious actions and strategy implementation will be required of repositories to carry out their mission of digital preservation. All of these present an expensive, complex undertaking that depositors, stakeholders, funders, the designated community(ies), and other digital repositories will need to rely on in the greater collaborative digital preservation environment that is required to preserve the vast amounts of digital information generated now and into the future.

The TRAC:CC contains 84 criteria broken out into three main sections: Organizational infrastructure; Digital object management; and Technologies, technical infrastructure, and security. Within each of these sections are various subsections and under the subsections are the criteria themselves.

1. Organizational infrastructure
   1. Governance & organizational viability
   2. Organizational structure & staffing
   3. Procedural accountability & policy framework
   4. Financial sustainability
   5. Contracts, licenses, & liabilities
2. Digital object management
   1. Ingest: acquisition of content
   2. Ingest: creation of the archivable package
   3. Preservation planning
   4. Archival storage & preservation/maintenance of AIPs
   5. Information management
   6. Access management
3. Technologies, technical infrastructure, and security
   1. System infrastructure
   2. Appropriate technologies
   3. Security

Some sample criteria are:

• A1.1 Repository has a mission statement that reflects a commitment to the long-term retention of, management of, and access to digital information.
• A2.2 Repository has the appropriate number of staff to support all functions and services.
• A3.5 Repository has policies and procedures to ensure that feedback from producers and users is sought and addressed over time.
• A5.4 Repository tracks and manages intellectual property rights and restrictions on use of repository content as required by deposit agreement, contract, or license.
• B2.5 Repository has and uses a naming convention that generates visible, persistent, unique identifiers for all archived objects (i.e., AIPs).
• B2.9 Repository acquires preservation metadata (i.e., PDI) for its associated Content Information.
• B3.4 Repository can provide evidence of the effectiveness of its preservation planning.
• B4.4 Repository actively monitors integrity of archival objects (i.e., AIPs).
• B5.3 Repository can demonstrate that referential integrity is created between all archived objects (i.e., AIPs) and associated descriptive information.
• C1.1 Repository functions on well-supported operating systems and other core
• infrastructural software.
• C1.5 Repository has effective mechanisms to detect bit corruption or loss.
• C1.7 Repository has defined processes for storage media and/or hardware change (e.g., refreshing, migration).
• C1.9 Repository has a process for testing the effect of critical changes to the system.
• C3.3 Repository staff have delineated roles, responsibilities, and authorizations related to implementing changes within the system.

TRAC:CC states that the “criteria are written to be applicable to any kind of digital repository or archives.” As such, criteria should be placed within the context of vision and goals of the Ohio DRC. One demonstrates compliance with the criteria through documentation (evidence), transparency (open examination of the evidence), adequacy (degree to which the evidence meets the vision/goals), and measurability.

Digital Repository Audit Method Based On Risk Assessment

The process has six stages, some with multiple tasks:

1. Identify organizational context
   • Specify mandate of your repository or the organization in which it is embedded
   • List goals and objectives of your repository
2. Document policy and regulatory framework
   • List your repository’s strategic planning documents
   • List the legal, regulatory, and contractual frameworks or agreements to which your repository is subject
   • List the voluntary codes to which your repository has agreed to adhere
   • List any other documents and principles with which your repository complies
3. Identify activities, assets and their owners
   • Identify your repository’s activities, assets and their owners
4. Identify risks
   • Identify risks associated with activities and assets of your repository
5. Assess risks
   • Assess the identified risks
6. Manage risks
   • Manage the risks

The report includes a catalog of risks taken from other checklists and repository audits that can be used to spur the thinking of the auditor.

Recommendation

I’m looking for information about the formation and management of regional digitization centers for one of the OhioLINK strategic task forces. For our purposes, a “regional digitization center” is a place that has the hardware, software, and human expertise to convert a variety of media to digital form. (We’re primarily looking at small format imaging, but could also include broadside imaging, audio capture, and video transformation.) There is plenty of information to be found about the services that centers provide and even more evidence of regional groups wanting to create these centers, but precious little about the operation of the centers themselves. (As in zilch in professional literature searches, and only a few hits via general web searching.) The kinds of things I’m looking for are:

• Operational structures, ranging from staff at the center that do the actual digitization to centers that just provide equipment and the organization wanting the digitized materials providing the staffing.
• Cost structures for initial center development and ongoing support.
• Project plans for building and promoting regional digitization centers.

Here’s what I’ve found so far. There is a really good message from Liz Bishoff from the time she was the Executive Director of the Colorado Digitization Program. There is also this bit from an article Liz Bishoff wrote for First Monday:

To assure that the institutions had access to equipment that supported these standards, the CDP established five regional scan centers. These centers provide the Colorado institutions with relatively easy access to scanning equipment, assistance by trained staff in scanning, and access to the union catalog and local databases via the Web. Each institution has to do their own scanning. Training sessions on scanning and metadata are being conducted throughout the spring and summer, 2000 at these regional scan centers. It is hoped that the combination of consulting on scanning, training, and quality equipment will result in a consistent quality image, as well as developing expertise at the local institution level.¹

The same themes are repeated in an interview from the NINCH Guide to Good Practice. Beyond the CDP project, though, the findable information drops off quickly. I’ve found that the Making of Modern Michigan project has spawned quite a number of regional centers, as have other efforts. I’m going to get in touch with folks in Colorado and Michigan, but in the meantime if you know of something I’ve missed (or you run one of these kinds of centers yourself) please let me know.

The text was modified to remove a link to http://lists.mdch.org/public/digistates/2003-September/000020.html on January 20th, 2011.

Footnotes

1. Bishoff, L. (2000). Interoperability and standards in a museum/library collaborative. First Monday, 5(6). Retrieved May 18, 2007, from http://www.firstmonday.org/issues/issue5_6/bishoff/.