Although I consider myself rather technologically literate (I can write a blog! I can make a web page! I know how to construct a basic for loop!), I find myself amazed every time I am forced to think about what makes what seems a simple computer operation, like a search for a known article in a library catalog, work. One simply types in the metadata detailing what they know, and a page appears that lists all of the places you can find that article in full text. It even links you to inter-library loan services! But, as Boston and Gendon in the book Electronic resource management in libraries: Research and practice and Walker in The E-Resources Management Handbook demonstrate, the process is far from simple. It requires numerous programs, all working in tandem, to make that list of full text appear.
For something like the known item journal search to work, first a list of what journals we have and where such journals are located must be created. According to Weddle and Grog in Managing the Transition from Print to Electronic Journals and Resources , this process is handled by an A-Z journal list, usually by a global, proprietary knowledgebase, as one librarian or even library keeping track of such things would be a monumental task. The library still must create a local knowledgebase, however, detailing their own campus holdings.
In order to find a specific article using this knowledge base, a request for that article's location must be made. URLS cannot be used because they change to frequently. Instead, every request that goes from that journal's request is named via an openURL link resolver, which contains some metadata about the item. The local knowledgebase is then queried using this metadata, and the correct results are returned.
At UW Madison, when one finds a specific journal, the results page also includes a list of suggested materials. This is another piece of programming, described by Boston and Gendon. Using openURL, a program looks for other materials in the knowledge base that contain similar words or subjects, and also returns them. This is added to facilitate resource discovery, showing people resources that they might never have considered.
That is at least three pieces of complicated programming, on top of the web programming required to display the material and the database software required to store the knowledgebase, and the licensed journals required to have the materials. It reminds me of something I was linked to on google plus, the beginning of which is below:
_____________________________________________________________________
"You just went to the Google home page.
Simple, isn't it?
What just actually happened?
Well, when you know a bit of about how browsers work, it's not quite that simple. You've just put into play HTTP, HTML, CSS, ECMAscript, and more. Those are actually such incredibly complex technologies that they'll make any engineer dizzy if they think about them too much, and such that no single company can deal with that entire complexity."
Let's simplify.
You just connected your computer to www.google.com.
Simple, isn't it?
What just actually happened?
Well, when you know a bit about how networks work, it's not quite that simple. You've just put into play DNS, TCP, UDP, IP, Wifi, Ethernet, DOCSIS, OC, SONET, and more. Those are actually such incredibly complex technologies that they'll make any engineer dizzy if they think about them too much, and such that no single company can deal with that entire complexity."
______________________________________________________________________
Sometimes I wonder, is all this complexity truly necessary? Do users need to be able to tag, to personalize their webpages, to conduct federated searches? What is actually being used in the suite of tools and interlocking functions that appear to create a coherent whole to the library user?
I admit, I am unsure what the right answer to this is. I tend to be wary of jumping on every new technology bandwagon that comes along, but I also understand the desire for improving user access and resource discovery in any possible way. In my own personal experience, as a user and reference librarian, some of these complex tools, such as the system for finding full text I described above, or improved content linking via both papers citing an article and papers cited by an article, are essential for resource discovery.
But in my experience some things mentioned in articles like Boston and Gendon's and Walker's tend to just not be useful, or at least under used by patrons. For example, both of these articles mention that one new method of resource discovery is bringing up suggested articles when a patron does a known item search. UW Madison includes this whenever a full text of article is sought using FindIt. However, I have never seen a patron use this service, although I have helped with many a full text or known item search. I admit, I tend not to point it out to them, as I am often disappointed in the results. They seem to never identify the topic correctly. I could see such a thing being useful if it was more accurate, but the current program does not seem to have the intelligence to be very useful.
Basically, I think that we need to continuously strive to build a system that truly helps a user in their resource discovery and electronic access, and this will be complicated technologically, no doubt. But at the same time, assessment of the tools we are providing, and user studies, must be conducted so that we know when a technology is being useful and when it is just adding another, unnecessary, layer.
No comments:
Post a Comment