Reaching the CROSSROADS of Two Lists for Periodicals Holdings
Coombs, Karen A., Computers in Libraries
ARE YOUR LISTS OF PRINT JOURNALS AND ELECTRONIC JOURNALS TRAVELING ON PARALLEL ROADS THAT WILL NEVER MEET? XML CAN BE THE THE CROSSROAD THAT FINALLY BRINGS THEM TOGETHER.
As the information technology and instruction librarian at SUNY-Cortland, I am responsible for designing, developing, and maintaining the library's Web site. One important part of it is our static Web-based list of our local periodical holdings. This list is mission-critical for us because we have no periodical holdings information in our OPAC. The situation is a legacy from our previous OPAC and is currently being remedied. However, adding our holdings is a time-consuming process that is still ongoing.
Additionally, last spring, the librarians were struggling with how to incorporate our full-text access into our overall list of holdings. Full-text access to resources is obtained in many ways: as an electronic-only subscription, as an add-on to a print subscription, or as "incidental" access provided via a subscription database such as Gale's Expanded Academic. Some libraries have chosen to catalog all of the electronic versions of their periodicals. However, others have chosen only to catalog those resources to which they specifically subscribe. This is because "incidental" full-text coverage for databases such as Expanded Academic changes on a regular basis, creating a maintenance nightmare.
To deal with this problem, we began subscribing to a product called Serials Solutions (http://www.serialssolutions.com) in order to maintain an up-to-date list of our full-text resources. Before Serials Solutions, we had no coherent way to know if we had electronic access to a particular magazine or journal. However, the Serials Solutions data is completely separate from our local print/microform periodicals holdings list.
As a result, we had two separate holdings lists: one for the local holdings and one for the full-text holdings. To make matters worse, neither of these lists was "searchable." Users needed to browse through the two different alphabetical lists to locate a particular magazine or journal. Needless to say, this was extremely confusing and frustrating for our patrons.
Therefore, I decided to attempt to consolidate these lists and make them searchable. This was meant to be a temporary solution while our periodical holdings were being put into the OPAC. The goal of this project was to create a single interface that would allow users to search all of our holdings (electronic, print, or microform) for a particular magazine or journal. Here's how I did it with XML.
Using XML as aVehicle
There were many reasons why I considered using XML to display the periodical information on the library's Web site. First, I believed that I could get both lists in XML format. I received an XML report of the library's full-text holdings from Serials Solutions, and the Access database where our physical periodical holdings were could be exported as XML. Second, I wanted to be able to have flexibility in how the data was displayed on the Web. I have learned in my 3 years as library Webmaster that I often have to reformat the way information is presented. I typically reuse the content and display it in a variety of ways on different pages or slightly tweak the look of a given page based on feedback from library staff and users. With XML, the content and the presentation are completely separated from one another, allowing the format to be completely altered easily. This precept also holds true for database-driven Web pages (which I also considered as an initial solution to the project).
At the start of this project, I considered importing the XML data into an Access database and displaying it to the Web using database-driven pages. Several of my SUNY colleagues have taken this approach. However, I abandoned this idea for two reasons. First, bimonthly, when I received an updated report, I would have had to re-import the electronic periodicals information and attempt to merge it with our local information. Second, upon initial testing, the importing process did not go smoothly. I could not successfully import the Serials Solutions XML without a great deal of effort. I wanted a solution that would simplify the process of updating the periodical list when the new Serials Solutions data came every other month. With XML, all I would have to do was replace the old XML file with the new one. This was highly appealing to me as I tried to cope with my ever-growing job responsibilities efficiently.
In deciding to use XML for this project a final factor came into play: the importance of learning XML for future applications. Over the last year, the number of potential XML applications in our library has grown dramatically. In particular, the possibility of using it to display data from the OPAC on Web pages outside of the OPAC is very promising. As a result, I saw this project as a testing ground for me to learn the basics of displaying XML on the Web.
Drawing My Own Road Map
When I started this project, I only knew the basics about XML. I understood how to write valid XML and that it took something called an XSL file in order to format the XML data for display. However, I realized that I would need to know a lot more in order to accomplish my goal of creating my single periodical search interface. I began the project by enlisting the help of a consultant I had previously worked with, and by interlibrary loaning books on XML. While there are many very good references on XML, XSL, and the other members of the XML family, I did not find a single resource that could answer all of my questions. Instead, I was forced to build my knowledge from various references, snippets of code from the Internet, and experience.
After reading, researching, and experimenting, I discovered that there are several components needed to display XML on the Web. The first is the XML file, which contains the data to be displayed. The second component is the XSL (extensible Stylesheet Language) file, which contains information about how to format and transform the data in a particular XML file. Using XSL, you can select particular pieces of the XML file to display and format the way they are displayed. The third component that is essential for display is an XML parser. A parser reads and displays the XML file. While some more recent browsers contain an XML parser, not all browsers do. As a result, the best way to display XML is to transform it into HTML on the Web server, which requires an XML parser on the Web server. The last component necessary in displaying XML is some type of Web programming language to call the XML document and the related XSL file and send them to the parser.
Having determined the necessary components, I began to make decisions regarding which XML parser and Web programming language to use. Because SUNY-Cortland runs Microsoft Web servers, I decided to use Microsoft's MSXML parser and Active Server Pages (ASP) to display my XML. However, I want to note that it is equally feasible to use open source software to accomplish this task. You could also use PHP instead of ASP, and there are a number of open source XML parsers.
Once I had installed the parser, the next step was to test it and the code for calling the files and sending them to the parser with a set of functional XML and XSL files. This step is critical. You need to make sure that the parser is working correctly. This is because you want to eliminate all the possible sources of error except the XSL file. Otherwise, when you test to see if your XSL file is working properly, you may get error messages not for improper code in the XSL file, but rather for the parser or the code that sends the files to the parser.
Once I had a functional parser and pieces of code to send the files to it, I was able to begin developing an XSL file in order to display my data. Constructing the most basic type of XSL is relatively simple. It is written in XML, which makes the basic construction relatively easy to understand. In addition, the language of the tag set is relatively straightforward.
One tricky part of writing a basic XSL file is using the X-Path language to select or examine specific pieces of data in the XML file. X-Path is like a set of directions that tells the parser to look at a particular structure of the XML file and then do something. Making an X-Path mistake is like giving the pizza delivery guy the wrong directions to your house, and he ends up either at the neighbor's house or in a completely unpopulated area. Consequently, it is a good idea to practice creating a simple XSL file that displays all the data from the XML file so you make sure your understanding of X-Path is solid before trying to select particular pieces of data under a given set of conditions.
Speed Bumps and Detours
One of the biggest challenges for this project came with creating a search interface that provided several search options: title begins with, title contains phrase, and title contains any words. Trying to fit each of these options in a single XSL file was daunting and ultimately the wrong strategy. One of the benefits of the XML family is that the code can be compartmentalized and thus be highly reusable. Accordingly, I created one XSL file for each search option. It is the role of the ASP code to determine what type of search is being done and to send the appropriate XSL for that search and the XML data to the parser, which then displays the search results.
After all of this work, I was still left with the task of combining the electronic and print/microform holdings lists. Initially, I believed that this would be the less difficult part of the project in comparison to displaying the XML. In truth, this turned out to be the most difficult part. The primary reason was that the two sets of holdings did not have similar data structures. This made it exceedingly difficult to combine the two lists into a single XML document.
As a result, I began to pursue a strategy that would make the two holdings lists "appear" as one via the Web. The key was to link the two lists using pieces of data. Ultimately, I chose to use ISSN and title in combination to link the data from the two lists. This link allowed users to move seamlessly from one list to the other without realizing that the data was stored in two places. Because the print/microform holdings are stored in a Microsoft Access database, I chose to leave it in its native form and to display it using database-driven pages.
Epiphanies on the Road
Overall, this strategy of using a combination of technologies (ASP, Microsoft Access, and the XML family) was an elegant and economical solution to the problem. Furthermore, it allowed me to develop a system that is compartmentalized. This is a distinct advantage when both the technology and the data's source and format are changeable. For example, when the job of adding periodical holdings to our OPAC is complete, I will want to combine the OPAC data and electronic holdings data. Because the code for this application is compartmentalized, making this change will be simple and seamless. This was one of the most important "aha moments" from the whole experience.
Another extremely important insight was the realization that there was no single way to accomplish this project. There is a wide range of information available on the XML family and its complementary technologies. There are many possible roads you can take to make XML work in a library setting. As a result, XML projects mean gathering information from a variety of sources and using it to build an application that best suits your environment.
Probably the most important "aha" from the whole experience was the idea of breaking up the project into smaller steps in order to accomplish the whole. This was especially important when I embarked on the actual code writing. By testing components of the overall application separately (the parser, the ASP that sent the files to the parser, the XML, and the XSL), I was able to save myself hours of frustration. Additionally, this type of approach mitigated some of the information overload that is inevitable with tackling a topic as large as XML.
Overall, the project took about 6 months to complete. An equal amount of time was spent in the planning and design stages as in the development and implementation stages. Finally, the combined searchable list went live in mid-October 2003. One of the most significant differences between the old and new lists is that the updating process is more efficient. Updating the list used to take an hour or more; now this change takes approximately 10 minutes. Additionally, I have received many positive comments on the new list from faculty, students, and library staff. In general, patrons find it easier to understand, more usable, and more effective than the old list. Based on this feedback, I feel that the project was successful.
The Next Road Trip
It was obvious from doing this project that XML is an extremely powerful and versatile technology. Ironically, the project was not an all-XML solution. However, it demonstrates XML's compatibility with a variety of platforms and environments. In a world where data is often stored in a variety of systems, and libraries are constantly trying to bring that data together, XML offers a great deal of hope. In terms of SUNY-Cortland, I am looking at using XML to bridge information in our OPAC and in the databases that drive our Web pages. Such ventures can help streamline redundant systems and can provide users with a more complete picture of the resources that the library has to offer.
"IN A WORLD WHERE DATA IS OFTEN STRORED IN A VARIETY OF SYSTEMS, AND LIBRARIES ARE CONSTANTLY TRYING TO BRING THAT DATA TOGETHER, XML OFFERS A GREAT DEAL OF HOPE."
Resources I Used in This Project
Baartse, Mark, et al. Professional ASP XML. Birmingham, U.K.: Wrox Press, 2000.
Birbeck, Mark, et al. Professional XML (Programmer to Programmer), 2nd ed. Birmingham, U.K.: Wrox Press, 2001.
Extensible Markup Language (XML) paper from W3C; http://www .w3.org/XML.
Kay, Michael. XSLT Programmer's Reference, 2nd ed. Birmingham, U.K.: Wrox Press, 2001.
Microsoft XML Core Services (MSXML) page of PerfectXML.com; http://www.perfectxml.com/msxml.asp.
The Extensible Stylesheet Language Family (XSL) from W3C; http:// www.w3.org/Style/XSL.
Karen A. Coombs is the information technology and instruction librarian at SUNY-Cortland in Cortland, N.Y. In addition to developing and maintaining the library Web site and OPAC, she is responsible for implementing and maintaining the library's electronic resources. She holds an M.L.S. from Syracuse University in Syracuse, N.Y. Her e-mail address is firstname.lastname@example.org. You can also reach her via her Web site at http:// facultyweb.cortland.edu/coombsk.…
Questia, a part of Gale, Cengage Learning. www.questia.com
Publication information: Article title: Reaching the CROSSROADS of Two Lists for Periodicals Holdings. Contributors: Coombs, Karen A. - Author. Magazine title: Computers in Libraries. Volume: 24. Issue: 1 Publication date: January 2004. Page number: 14. © 2008 Information Today, Inc. Provided by ProQuest LLC. All Rights Reserved.
This material is protected by copyright and, with the exception of fair use, may not be further copied, distributed or transmitted in any form or by any means.