OhioLINK, my employer, is seeking nominations and applications for the position of Executive Director. The search is being conducted with the assistance of Brill Neumann Associates, and the position description is linked from their current searches page (direct link to PDF, cached link to PDF).

The text was modified to remove a link to http://www.brillneumann.com/searches.html on May 17th, 2011.

The text was modified to remove a link to http://www.brillneumann.com/pdf/ohiolink_pd.pdf on May 17th, 2011.

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.

An interesting thing happened at my place of work (OhioLINK) today. We recently added links to our central catalog pointing to manifestations in Google Books. The way it was decided to set it up, though, was to only point to Google Books if the full text was available. We tweeted about it to let our community know that this option was now available. The tweet included a link to a particular record that showed (at the time) an example of this change: Mark Twain’s Life on the Mississippi.

Others picked up on the tweet and word got around. This morning I noticed a comment on one of those tweets via FriendFeed — the link to the full text was no longer visible on our sample record. Odd, I thought, and I started poking around. Other items in our catalog still showed the link to full text in Google Books. And the same record in Kent State University’s catalog, using the same linking mechanism, had a link to the item in Google Books, but — and this is the kicker — now only in “snippet” view. And that is probably the appropriate view given the copyright date of 1951.

What we’re guessing is that the book was erroneously in full view mode in Google Books. The large number of hits — caused by it being the example record in OhioLINK’s blog posts and tweets — triggered some sort of usage alarm at Google Headquarters, where someone (or some algorithm) took a second look at the classification of the item and changed the view from full to snippet.

In any case, we tweeted a second example that, given its copyright year of 1918, will most likely remain in full view mode.

My place of work has moved to office space in downtown Columbus. If you have saved contact information for me, please update it. Those connected to me via Plaxo will get updated information automatically.

These Parts Have Changed

These Parts Haven’t Changed

Despite the problems I’m having with the slidecast function of SlideShare, I’ve gotten the results “good enough” to post. You can see and listen to the presentation on the SlideShare site or do the same in the embedded version below.

I had the pleasure of presenting at the 2009 meeting of the Ohio Higher Education Computing Council (OHECC) on OhioLINK’s plans for a new discovery layer. Included below is a web version of the presentation slides and links to more information. I also attempted to record the audio from the presentation; if that is of an acceptable quality, I’ll add it here and synchronize it to the slide playback.The audio has now been added to the presentation on SlideShare and is available separately.

For a description of the OhioLINK project, see this earlier DLTJ posting with a description from the solicitation and this follow-up posting with answers to questions from potential bidders. (When reading these messages, please note that the time for submitting responses to the solicitation has passed.)

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.