It appears that tremendous technical challenges must be overcome in order for common user interface software to perform search and retrieval on disparate databases. Future evaluation of a vendor’s common user interface product must be weighed against four critical technical challenges:
- Database Access
How exactly is the software able to access disparate databases and combine them into one result set? What are the “nuts and bolts” behind this process? Specifically the following questions:
- What are the database access protocols used by the software in the search and retrieval process against the target database (Z39.50, SQL XML, SRW, etc.)?
- Does the target database have a corresponding protocol server that can deliver search results from the software?
- If the software utilizes a login ID and a “screen scrape” process to retrieve data from a target database, has the vendor accounted for copyright issues?
- Has the vendor accounted for the fact that many commercial databases already have exclusive Internet access agreements to information carriers (such as Dialog or Ebsco)? For example, Canada Law Book has exclusive arrangements with Quicklaw to provide Internet access to its databases. A third party vendor would need to purchase these rights to legally provide Internet access to the databases through their software.
- How does the software account for disparate databases having different indexing structures for search terms? For example, if a user entered the subject keyword term “Quarter Horses” into the main screen, how would the disparate database know that the search was subject based and not title or author based?
- How does the software manipulate the results? How is the merging, ranking, de-duping, sorting and limiting of records handled?
- Patron Authentication
How exactly is the software able to control patron access to subscription-based databases and Inter-library loan requests? Specifically the following questions:
- If the software relies on the library’s ILS system to authenticate a patron for entry into a database or initiate an inter-library loan, how does it accomplish this when patron databases have proprietary storage formats? What interoperability standards or protocols are used (e.g. NCIP, SIP1)?
- If the software accomplishes proprietary patron database access by utilizing SIP1, SIP2 or NCIP access interchange protocols, has this process been tested and documented with ILS vendors?
- What security facilities does it provide to ensure privacy of patron records?
- Does the software allow for IP authentication and other methods of guest access to non-residents?
- Interlibrary Loan Initiation
In all likelihood, a user will want to generate an ILL request for any materials not in local holdings. This raises the question, how would any common user interface product perform this task? Specifically the following questions:
- If the software was able to perform search and retrieval on disparate databases and return a result set, how would the software link holdings information from the local ILS to the result set?
- If the patron did decide to initiate an inter-library loan request how would this be accomplished? Would the ILL request work within software already embedded in the common user interface or would it interface with third party ILL software?
- Would the ILL request follow recognized protocols (ISO 10160/10161 or Generic Script)?
- “Googlification” Trends
Michael Gorman in an address in 2002 noted that one of the key challenges librarians would face in the near future was the onslaught of the “everything is available on the web” concept. While we as librarians can outright dismiss this concept as ridiculous, we cannot as easily dismiss the rapid encroachment of both Yahoo and Google attempting to make this concept a reality. Google flushed with cash from its recent public share offering, has begun to approach both book and database publishers to offer abstracts of their materials on the Internet (indexed by Google). A good example of this is Google’s recent “Book Search” initiative. This initiative allows keyword searches to be matched with both web sites and abstracts of published books . This trend is also growing to include indexing and abstracting databases with the Cros Ref Search pilot project . This pilot project includes 25 publishers (including Blackwell’s, Oxford University Press and John Wiley to name a few) who are allowing Google to webcrawl and index their e-journal databases. OCLC’s Open WorldCat pilot project has also exposed library bibliographic records to Internet searches by allowing both Google and Yahoo to webcrawl and index their holdings databases. For more information on the OCLC Open WorldCat pilot project see Appendix E.
Should this trend continue it could eventually eliminate any need for common user interface software. It would allow the user to rely on Google to find abstracts of material, then use their local library ILS to find local holdings. If ILS software companies correctly read this trend, they will provide Google the API to allow the user to search Google first, then drill from Google into their local ILS to check for local holdings. How Google would handle consortia and partner recognition under this model remains to be seen.
It will be difficult for publishers and ILS software companies to resist the financial windfall that this trend will present. Google could potentially offer royalty and advertising share structures that would add another revenue stream to their bottom line. For database publishers it will decrease expenses in marketing their product by allowing them to concentrate on providing “data” without having to provide a search interface. In the end result, the shareholders of these companies will push for this type of change if it means a healthier balance sheet.
The second phase of “Googlification” is marked by the recent release of its software API package. Google Web API allows for organizations to develop their own customized “Google” interface that searches both local documents and the Internet at the same time. The ease and simplicity of using the Google Web API locally could spell the end of such products as Bibliomondo’s “Zone Pro” and Endeavor’s Encompass, which appear to be little more than “intranet” software. If Google decides to approach database vendors to provide their API for added access to the intranet, this would eliminate the need for any metasearch software.
The larger question to “Googlification” is how will the continued development of common user interface software be affected should this trend continue to grow?
There does appear to be a large number of metasearch products in the library software market today. Continued research will be required to determine if any of the products will meet the needs and priorities of the Saskatchewan public library sector. Should the library directors choose to pursue this, it appears that there is not a full common user interface product ready at this time. Some next steps to begin research would be to invite several vendors to hold demos. The products could then be evaluated against our technical considerations list to determine if there is sufficient functionality to begin a full evaluation process.