Message-Id: <199602041826.MAA19154@library.wustl.edu> Date: Sun, 4 Feb 1996 12:26:23 -0600 From: Jeff Huestis <mailto:Jeff-Huestis@LIBRARY.WUSTL.EDU> Subject: Loose Ends To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
The first posting to WebCat-L raised the issue of how vendors would license their web gateway products. At least two methods came forward: 1) pricing according to the number of concurrent "sessions" allowed, and 2) pricing according to the number of volumes in the client library's collection (analogous to software companies charging on the basis of the size of a central processor). A number of people pointed out that the problem with the first approach is that the inherent "statelessness" or "connectionlessness" of the HTTP protocol means there is no "session".The problem, as I see it, with the second approach, is that it doesn't reflect heavy use of resources outside the local collection, via Z39.50 connections. Young institutions with undersized collections focus on "resource sharing" and "access vs. ownership" to compensate for the mismatch between collection size and user demand. More established institutions are being forced into this approach by tightened budgets. Pricing by collection size seems to be measuring the wrong thing. Pricing for a web gateway should clock the institution's presumed appetite for the resources of the world library. Tuition and grant revenues (with adjustment between public and private institutions) might be used as an indirect measure of this "appetite".
There was an extended discussion of the *functional* problem of statelessness as it related to the concept of "search history". The alternatives seem to be 1) maintaining state information in the web gateway, or 2) maintaining it in the desktop client. It was reported that some gateway products are already maintaining some sort of search history. (An aside: from my limited experience, it appears that the new "frames" facility requires state information at the server end. Can somebody more knowledgeable comment on this?)
Maintaining current context in the client implies that *each* cycle of the interaction requires the client to send the saved state back to the server as CGI form data. Obviously, maintaining state information in the web gateway is the more efficient way to do things, avoiding re-execution of entire searches just to get the next subset of data, etc. Almost certainly, this will be the standard approach adopted by vendors. And maintaining a "session" will be a prerequisite to other gateway services beyond protocol conversion, such as maintaining user authorization information. Someone mentioned InfoSeek Professional's saving *persistent* state information over time. This profiling by a major search engine, taken together with facilities like "URL Minder" (which monitors changes in registered web pages) suggests other services such as Selective Dissemination of Information (SDI). The URN/URC/PURL approach to stabilizing web linkages (analogous to replacing shelf location information with call numbers in catalog records) is another possible function for the gateway.
But the client-empowering CGI approach has advantages which argue that it should be supported too. These advantages were hinted at by references in the week's discussion to saving the CGI form data as a "bookmark". If the CGI data can be saved as a bookmark, it can also be used as a hyperlink from a web document into a library catalog or other database.
Consider a scenario in which the user searches a catalog and finds a record in which there is a URL for the electronic version of the resource cataloged. He clicks on the link, and pulls up the full text document. In the body of the text, or in footnotes and bibliographies, there are citations some of which are highlighted as links. If the cited reference is also in electronic form, the link takes you to the document. If the document is not in electronic form, but is held in the library's catalog, then following the link connects back to the catalog, locates the document surrogate and displays it on the screen with its non-electronic URL (ie., its call number). Conceivably, the catalog search could be performed on other libraries' catalogs via Z39.50 linkages, with the result being a partially filled out interlibrary loan request on the user's browser display. Both the local holding display and the interlibrary loan service assume the ability to connect to a catalog, and execute a one-step probe to an individual record--in other words, a CGI application with all the necessary form data concatenated onto the URL.
Jeff Huestis Washington University Libraries
References:
Z39.50: http://lcweb.loc.gov/z3950/agency/ CGI: http://www.yahoo.com/Computers/World_Wide_Web /CGI___Common_Gateway_Interface/ URN/URC/PURL: http://purl.org/ http://WWW.CNRI.Reston.VA.US/home/cstr/handle-intro.html http://domen.uninett.no/~im/uninett/prosj/urn.html URL Minder: http://www.netmind.com/URL-minder/URL-minder.html