 |
||||
 |
 |
|||
|
METHODS IN CELL BIOLOGY, VOL. 48, pp.
607-625, Laura M. Shoman, Ed Grossman, Kevin Powell, Curt Jamison,
and Bruce R. Schatz
I. Introduction
III. Concepts and Conventions
IV. Browsing and Searching
V. Sharing Data
VI. Discussion VII. The Future References I. Introduction The Worm Community System (WCS) is a digital library that contains knowl-edge about Caenorhabditis elegans, and a software environment that enables the user to interact with the community library across the international computer network, the Internet. The functions of the software environment enable the user to browse, search, and retrieve the existing knowledge of the community. In addition, users may add data and literature to the library for timely dissemina-tion to the research community and for private collaboration with colleagues at local or remote sites. This capacity for dynamically updating information should help to better propagate knowledge across the community. This chapter provides a survey of the system's history, features, and requirements, and describes basic uses of the system. II. System Information and Requirements A. History The first version of WCS (WCSr1) was funded by the National Science Founda-tion as a research model, a prototype of a research community electronic collabo-ratory (National Research Council, 1993; Pool, 1993). WCSr1, distributed in 1991, ran in more than 25 laboratories. The second version (WCSr2), described below, was also funded by NSF and was released in the summer of 1994 as an X-windows application that runs on Sun workstations, and, through X-windows emulators, on Apple Macintosh and DOS personal computers. The initial applica-tion was developed at the University of Arizona in Tucson, starting in 1989. In 1993, the project relocated to the University of Illinois, Urbana-Champaign (UIUC). B. Overview and Content The WCS contains a variety of data objects (such as documents, genes, clones, and lineages) within one application. Relationships between the concepts in these data types are indicated by links. These links are created initially by the system when new data are incorporated, building on the current store of information. In addition, links can be created by individual users to define new relationships among the data, thereby creating new knowledge. Links also provide one method for navigating through the data. The purpose of the system is to support the display and recording of patterns in the information space, where the patterns are formed by links between objects and represent important relationships. Information in WCS attempts to span the range of all that a researcher might find useful, including formal and informal literature and data. The literature includes abstracts from most of the Caenorhabditis Genetic Center bibliography, full text of all articles from the complete Worm Breeder's Gazette (the C. elegans community newsletter), and abstracts from the most recent worm meetings. The data include genomic data from the MRC/WUSTL mapping and sequencing project (genes, maps, sequences), community data from the Minnesota stock center (stains, people), and the beginnings of cellular data (cells, lineages). Part of the WCS software is run from a computer in the local laboratory. Data are accessed "live" and in real time across the Internet from a server at UIUC. This model of computing allows for relatively instantaneous updates of the data as new objects are added by users, and does not require massive amounts of disk storage at each local site. The software environment provides for transpar-ency, hiding from the user the complexities of handling the different physical locations and the different data types and supplying a simple uniform set of commands for the library of community knowledge. As a tool, WCSr2 complements ACeDB. Although WCSr2 and ACeDB are both hypermedia-based biological databases, they differ in a number of ways. WCSr2 is a community system. To that end, it allows interactive creation and editing of new objects by end users within the system. It also supports editorial and privacy controls, allowing users to restrict access to data and to determine how reliable a particular piece of data is. Finally, while ACeDB distributes its database with the software, WCSr2 has a client-server architecture with a central database. This allows all users immediate access to new data, instead of relying on periodic updates of the database. C. Availability and System Requirements Current information about WCS can be found on the Community Systems Laboratory (CSL) server, anonymous ftp csl.ncsa.uiuc.edu (141.142.221.11). From the WCSr2 subdirectory, get README. Additional documentation may also be available (e.g., the users' manual in a variety of formats, and a quick start sheet). Directions to the binary code and additional, up-to-date system information are given in the README file. The following information pertains to WCSr2. Workstation Requirements. Sites will need to have an Internet connection from a Sun workstation to access the CSL server. The data, search engines, thesaurus server, etc., reside on the CSL server at UIUC. The following machines are suggested for workstations: SparcStation 5, SparcStation LX, SparcStation 10, or SparcStation 20. Tolerable, but very slow performance can be achieved on SparcStations 2,1+, and IPX. The "minimum recommended configuration" would be a SparcStation2 with at least 32 Mbyte of random access memory (RAM). These workstations should run version 4.1.x of Sun's operating system, or Solaris 2.3 or later. At the time of this writing, WCSr2 had not been tested on earlier versions of Solaris. The Sun station should run at least 32 Mbyte of RAM. There are several factors, local and regional, that affect the performance of the system in each laboratory. These factors include the local hardware configu-ration and network at each institution, the level of traffic on the Internet, and the nature of search or retrieval being performed. For example, searching data for a broad term that will retrieve hundreds of "hits" may take up to a minute, perhaps longer, depending on various factors as indicated above. Retrieving the cell lineage or other graphical displays will take longer, in part because of the size of the data traveling across the Internet. The search query is sent to the CSL server in Illinois, and then data responsive to the search are sent back to your local workstation--the data are not stored locally on your workstation. This system design is different from the earlier release of WCS and from current releases of ACeDB. A central location for data allows the community to access the most current data and provides for immediate dissemination of information (at the level desired by the author) to the community. X-Windows Plaiform. The local software requires an X-windows environ-ment and, in addition to that environment, will take up approximately 10 Mbyte of space on a hard drive. This disk space requirement may increase over releases, but no dramatic increase is anticipated. On Sun workstations, CSL staff have used both M1R5 and OpenWindows (the Sun product) with good results. Nodes. Users have run WCS on microcomputer nodes, using the local Sun workstation as a server. The Apple Macintosh or PC clone must be connected with Ethernet to the Sun workstation that, in turn, is connected to the CSL server over the Internet. WCS is an X-windows application and cannot be run on a Macintosh or PC clone without an X-windows environment. Macintosh users have used Apple's product, MacX. DOS-based machines have used PC-Xview for Windows, a product from Network Computing Devices, to good effect. A Macintosh node running off the server should have a mininum of 8 MBytes of RAM. The Mac should be in the 68040 processor family. Higher-end 68030 Macs will run MacX acceptably if no other applications are running. A DOS-based node should have a minimum of 8 Mbytes of RAM. The processor should be a 486/66. Monitor Resolution. On either machine (Mac or DOS) the monitor should have a resolution of 1024 x 768 pixels. Apple's 16-in. monitor has a resolution of 800 >< 600 pixels and is considered acceptable by some users. Color is not used in WCS. Input Devices. The interface requires a keyboard and a mouse (or trackball) input device. Printing. Printing can be done from the Sun server transparently, using the existing printing configuration through X-windows. Printing directly from a Macintosh is done through MacX. III. Concepts and Conventions A. Information Space The data in this digital library exist in an information space: all the information consists of objects, which are also called information units (iu or ius, plural), which are interconnected by relationship links to form the space (Fig. 1). This information space is much like a web. The information units are points within the web; links are the threads of the web, giving definition to the space while being a part of the web itself. B. Types Object types, sometimes referred to as data types, include
2- and 3-factor data, deficiencies, genetic rearrangements (e.g.,
translocations), strain names, gene names, chromosomes, contigs, clones,
sequences, cells (lineage history), docu-ments, images, persons, and
laboratories. A user can add new data that are "recognized"
by the system as fitting into one of these preexisting categories.
A user might, for example, enter a new gene or a document. The system
will then present the user with the appropriate form to complete,
and the data will be incorporated into the system. In addition, the
system will ~'type-check" each entry within the form to confirm,
for example, that the new gene name is unique or that it contains
a clone that references an actual clone on the physical map. C. Navigating Information Space A user may enter the space of existing objects by first issuing a search to retrieve objects and then navigating links from these objects to other related objects. A user can also share objects with the community, adding them to the space by first issuing a command to create objects and then completing the form presented by the system. A user may also create links between objects~between a new object and existing objects, or between two (or more) existing objects. Commands can be issued on a selected object. The basic commands for manipu-lating the information units are the same for all objects in the system. Once commands have been learned for one object type, the same commands can be used on any object or collection of objects (sets). Commands are issued through the command buttons (e.g., Search All and Search This Type in Fig. 2) and popup menus (Utilities and Type Selection menu in Fig. 2 and other menus presented on other windows). See Fig. 2 and below. D. Interface Conventions The WCS uses a graphical user interface. The Search Window (Fig. 2) is the starting point. The display on the local monitor may vary from the illustrated display due to equipment differences; however, the general principles discussed here apply to all kinds of displays.
IV. Browsing and Searching A. Browsing The Browser is made up of those fields and windows on the left side of the Search Window: the Type Selection menu, the Locator box, and the Browser Window (see Fig. 2). The Browser is the quickest way to locate information by object type. The Browser is also used when new data are being added (see Section V on Sharing). To use the Browser, click and hold on the Type Section menu to display a list of all of the types known by WCS. Highlight the data type to be browsed to select it. The selected type appears in the Type Selection menu, and the list of objects of that type appears in the Browser Window. If you know the name of a particular object, type the name in the Locator box. The Browser Window will scroll to the object (presuming it is in the object store). To retrieve the object, click on the name in the Browser Window or finish typing the name in the Locator box and press the Return/Enter key. B. Searching The right side of the Search Window can be used to build powerful, complex queries using nested boolean searches and restricting the types of data and fields that will be searched. The Query Specification box and the Type and Field Restriction menus make up a functioning unit called a Panel (see below). In addition, the buttons Thesaurus and History are found on the right side of the Search Window. These will be explained below. The broadest search is performed by typing words in the Query Specification box and then clicking on Search All (or pressing the Return key). The application first removes prefixes and suffixes, and then looks for the matching string of characters in the documents and forms. The results of the search appear in a new window labeled Set of lUs (a set of information units). If no matches exist for the search query, a dialog box will appear. The set is actually an object; the commands invoked on a single object can be invoked on a set as well. For example, one such command will retrieve all of the items that are somehow related (through links) to all of the objects in the set. See Fig. 3 for a sample search session.  Fig. 3 Search WCS by typing a query (mec-7) and clicking the Search All button. The results are seen in the set of information units: Results of Search For: (mec-7). The results include documents, the gene object itself, and 2-factors. The gene object is selected and retrieved. Links from the gene object are shown in the set of 54 objects. any of these objects can be retrieved for further study. To restrict the search to one type of data, select the type from the Type Selection menu, enter the word(s) in the Query Specification box, and click on Search This Type. To restrict the search to one or more types of data, and one or more corresponding fields within the data type, use the Panel (Fig. 4). Panels consist of (1) a Query Specification box, (2) a Type Restriction menu, (3) a Field Restriction menu, and (4) boolean search tools (parentheses and boolean boxes).
Specify the query. Use the Type Restriction menu to restrict the type(s) of objects to be searched. Fields within that data type may also be restricted, to further focus the search. The Panel can also be used to "stack" queries. Panels are added to the query structure by clicking on the Panel button on the Search Window. For example, one can search for mec-7, mec-3 and "touch" by using panels to focus each search. Boolean searches can be constructed by adding parentheses (Fig. 5).
 Fig. 5 Complex and powerful queries are manageable using multiple Panels and incorporating parenthetical Boolean statements within a search query. C. Thesaurus The thesaurus provides a list of terms associated with the search term(s) used in the most recent query and may thus be helpful in suggesting additional terms to search for. The Thesaurus command button is located on the Search Window, and clicking on the button brings up the Thesaurus Window (Fig. 6). The Result Terms are not synonyms for the Query Terms, but, rather, terms that occur within the same sentence or abstract. A search performed from the Thesaurus Window is performed within all data types, not on those types that may have been specified in the previous query. The Thesaurus also provides an additional field, New Query Term, allowing the user to add a term not listed in the other windows.
D. Links Data within the information space are linked. Following links among the information units is one method of navigating through the information space (see Figs. 3 and 7). After a search has retrieved a set of objects, one can follow links among the objects or show a list of the objects related to a specific item within the set. To show or follow the links of a specific object, select the object. Use the Links menu to show or follow links. Showing the links from an object provides a set of objects related to the selected object (as in Fig. 3). Following the links opens each object (see Fig. 7).
E. Other Display Features The History menu keeps track of the most recent 20 windows opened. The user can select from that list to return to a particular object. Documents may have figures, tables, or line drawings associated with them (Fig. 8). To retrieve any existing images, display the document. The Display menu item Show Images will be enabled if figures accompany the selected docu-ment. Images may also be retrieved as objects of a set or by showing or following links from a document.
Cells are displayed as a lineage display, as in Fig. 9. The lineage allows the user to view data in a variety of ways. A user can browse the entire lineage representation. Using the Arrange menu, the display can be manipulated, provid-ing flexibility and dynamic interaction with the data. Every branch point and terminal branch are live objects that can be linked arbitrarily to other objects, including selected text in documents, selected fields in genes, and clones. There is a sample gray-scale image of the organism that can be retrieved with the Find Image command. Such images illustrate a cell at some level of development.
 Fig. 9 The Cell Lineage display allows a user to view graphic information on a particular cell and then interact with the data, following development of the cells through generations, linking cells to other objects within the system, and viewing images of the organism. V. Sharing Data As a national prototype of an electronic community system, WCS provides the worm community with an unparalleled opportunity to share information, including informal and formal research, and community folklore. An individual in one laboratory can create a new object and create links between the new object and existing objects. An individual at a different laboratory (even on a different continent) can retrieve that information practically instantaneously, and can use it to create new relationships among other objects within the space. This ability to share data is balanced by a feature that allows the author of the new object to control how the new object is distributed. Collaboration across the country can now occur, with security and privacy features protecting the team effort until sharing is deemed appropriate by the owner. A. Login and Object Ownership Select Login from the Utilities menu in the Search Window. A window will open, requesting name and password. The user should enter data in the Name field, last name first and then first initial. Review the listing in the window below the Name field. If the user's name appears in that list, a password has been assigned by the system. Contact CSL for the password needed to log in, sending e-mail to wcs@csl.ncsa.uiuc.edu, requesting the password. Once an individual logs in, that person controls read/write privileges and retains editorial control over any objects he or she has created. B. Linking Objects Login is also required to make links between existing data. For example, when reviewing search results, a user might see certain patterns, relationships, or connections between different data. The user may make links between those objects. To link two objects, use the Links menu to Start a link at one object and Finish a link at the other. C. Creating a New Object Use the New button to create a new object after picking its type from the Type Selection menu. A new object window for that type will appear. If a document is being created, the individual who has logged in is presumed to be the first author. To enter a value-object in a field, select the field. The value can be entered in two ways: by typing or by copy-and-paste. If typing text, the characters entered are type-checked. If a clone name is entered in a name field of an allele, the system will respond with an error message. Multiple objects can be entered into a single field, type-checked as a set by tabbing after entering each object. If the data typed in fields other than the new object's Name field represent other objects already within the system, a link is automatically gener-ated between the object being created and the existing object. Copying and pasting an existing object into a new object will also create an immediate link. To copy and paste, retrieve the data to be embedded and select Copy from the Display menu (Fig. 10). The allele object has been copied. Click on the new object window, and make sure the appropriate field (where you want to paste the object) is selected, highlighted with a cursor or box. The allele field is selected in the gene : test-i object. Select Paste from the Display menu. The name of the existing object will appear in the highlighted field.
A user may also create and save a set of objects. In the Utilities menu, select New Set. A new window will open, a Set of lUs with no items in it. When an object is found of particular interest, use the Display menu to copy the object and paste it into the New Set window. D. Publishing New Objects When creating a new object, the owner has the opportunity to restrict who reads and writes to the object. The level of privacy or security can be adjusted by the owner at any time. The default is that all users may read objects that are added to the system, but not write to them. When creating a new object, select Permissions from the Utilities menu. The Permissions window will be displayed (Fig. 11). Assigning a user Writer privilege automatically grants them reading privilege. Assigning a user Reader privilege assigns that individual reading privileges and denies reading privileges to all users not in the Reader list. Other users may not retrieve the object. Much like the 'real" community, the virtual community system provides for moderating and curating of data. As can be seen on the Permissions window, the default is that new data are posted to WCS, without review or moderation. As the community uses the system to disseminate information, however, levels of review will be implemented. A moderated object will be sent to a moderator who may apply some criteria yet to be developed to screen each submission. Criteria may be general, not necessarily editorial in nature. For example, the Worm Breeders' Gazette is a moderated journal. Submissions are sent to a central clearinghouse and informal screening ensures articles conform to a certain type. A curated object is reviewed by an evaluating individual or group to ensure not only that it meets certain editorial guidelines, but that the data are appropriate. The criteria that the community chooses to use and the individuals that will fill these vital roles have not been identified. Technologically, the mechanisms are available within WCS to provide various levels of quality of research to the community, from informal data to peer review. The community can develop the appropriate standards and implement the technology.
VI. Discussion Research communities encounter and incorporate new technologies in the pursuit of knowledge as a matter of course. For example, full texts and abstracts have been available on-line through various commercial services for decades, and have been used by scientist and scholar from the beginning. The Internet and its predecessors, ARPANET and NSFnet, have long supported the transfer of data between researchers. Although the initial impetus for the ARPANET was to run remote jobs on supercomputers, the primary uses of the network were communication, collaboration, and data exchange among advanced research laboratories working for the Department of Defense. The decentralized network typology and evolution of the loosely regulated anarchy of the Internet grew out of ARPANET. On-line services provide an alternate method of distribution of material that is simultaneously published in paper form. The issues of quality control in on-line services do not focus on the quality of the material being distributed on-line. Peer review and quality control for content are unrelated to the availability of the abstract or article in the on-line environment~the article has received editorial approval (and perhaps is available in print) before the information is made available on-line. Quality generally refers to the methods of indexing, integrity of data input, and usability of the service. At the other end of the spectrum, the proliferation of USENET newsgroups, ftp sites, gopher hosts, mailing lists, and other Internet services has led to exponential growth in informal communication, information that is not subjected to any kind of peer or critical review before being "posted." There may be some form of moderation prior to posting, meaning that there is a human being who reviews the post for "appropriate, subject-related content," but who does not look at the quality of the data. Traditional channels of informal communication in the worm community include regional and international meetings and the Worm Breeder's Gazette. These channels were supplemented in July 1994 with the introduction of a USENET newsgroup, bionet.celegans. In addition to informal channels, the Internet has also served as a testbed for several experiments, including electronic journals and biological databases such as GenBank. Unlike commercial on-line services, these electronic journals are not the digitized files of printed journals or abstracts made available on the Internet, but are written, edited, and distributed entirely on the Internet. Some experiments have attempted to incorporate various levels of quality control; others are clearly vanity press publications. In the case of GenBank, the quality and duplication of data have been major concerns. GenBank supports direct submission through electronic data publishing (Cinkosky et al., 1991), but the volume of submissions has required development of submission tools and methods specifically to reduce the level of redundancy, thereby improving quality of data. Tremendous resources have been devoted to the cleanup and management of the database by Los Alamos National Laboratory and the National Center for Biotechnology Information. Further discussion of the changes in scientific research and of the many prob-lems accompanying changes in the delivery of scholarly and scientific information is available elsewhere and is outside the scope of this chapter (see, for example, Gardner, 1990; Harnad, 1992a,b; Harrison et aL, 1991; Hoke, 1994a,b; Hunt, 1990; Langschied, 1994; Okerson, 1991, 1993; Olson, 1994). As can be seen by the few examples presented here, however, the incorporation of technological advances into the research process is not new and not without periods of experi-mentation and adjustment. That this chapter appears as part of the community literature is a reflection of the adjustment process. Whether the community will incorporate the system within its information-sharing patterns by using the system's electronic publishing features is part of the ongoing experiment. The WCS supports a mechanism of electronic publishing, one that provides for various levels of quality control through a variety of methods. Policies for using these are to be established by the community. The first level is access: one must run the WCS front-end application to access and read WCS material. The second level is at a password level: to enter data, or to create links, a user must have a password and must log into the system. The third level of quality control is accomplished by the automated assignment of authorship to a particular item: once logged into the system, a user is recognized as the author of the object created and the user name is shown in the author field of a document (as one example). Higher levels of quality control, through moderation, curation, and peer review, can be accommodated. As implemented in the software, the quality-control methods build on the contemporary model of quality control within the community, where curation is done by people at the MRC and at The Sanger Centre, and moderation of informal publication is done by the editors of the Worm Breeder's Gazette. Privacy control also models the community: research and collaboration are orga-nized around groups in laboratories, not necessarily individuals. At present there are no "WCS guidelines for authors," and there is no restric-tion of data that can be added (except that noted above concerning object types). Any implementation of peer review would require cooperation between the developers and leadership within the worm community. The lack of formal guidelines and peer review mimics the current state of the community, which has monitored itself and has provided a level of socialization to new members that guides research and publication practices. To date, the sample of added data has been too small to tell what publication niche will be filled by WCS. The changes in technology exemplified in the WCS provide opportunities and challenges to the scientific community, and solutions will evolve out of discussion and collaboration between laboratories and the developers. VII. The Future The goal of WCSrl was to bring up an electronic community system of inter-linked data and literature for C. elegans available across the network. The goal of the current WCSr2 is to support collaboration within the community, enabling entry and publishing of data and links across the network. Future releases will explore the ability of a network information system to provide a facility for "dry-lab biology," where experiments can be run electronically by analyzing correlations between units in the information space. This will involve expanding the data sets to include other model organisms and central archives such as GenBank, GDB, and Medline. Although these are largely available on the Internet today, the database items are stored as flat text, rather than as structured objects with powerful search functions, relationship links, graphical displays, and analysis programs (Mount and Schatz, 1994). The WCS is thus not only a national model of the future of genome databases and science information systems (Cour-teau, 1991; Pool, 1993), but also a harbinger of the new paradigm in biology prophesied by Walter Gilbert (Gilbert, 1991). Acknowledgments The Worm Community System was partially funded by the National Science Foundation under Grants IRI-90-15407, IRI-92-57252, and BIR-93-19844. Other support was provided by the University of Arizona and the University of Illinois. In addition, the National Library of Medicine provided a copy of the IRX search software, which was then modified and adapted for WCS. Scott Hudson provided his user interface tool kit as the foundation for the "front end" of the system, implemented much of the release 1 version, and provided significant design advice for release 2. Terry Friedman wrote much of the original "hack end" of the system. John Calley developed the lineage display. Hsinchun Chen created the Thesaurus functions. Samuel Ward provided support of many kinds for WCS at the University of Arizona. Jean Thierry-Mieg and Richard Durbin have kindly provided the genome data from ACeDB. Theresa Stiernagle and Bob Herman provided stock data and they edit the Worm Breeder's Gazette, which CSL then digitally encodes. In earlier days of this project, these data and much additional help were provided by the former curator of the stock center, Mark Edgley. Finally, we are grateful for the many comments from the users of WCS. References Cinkosky, M. J., Fickett, J. W., and Gilna, P. (1991). Electronic data publishing and GenBank. Science 252, 1273-1277. Courtean, J. (1991). Genome databases. Science 254, 201-207. Gardner, W. (1990). The electronic archive: Scientific publishing the the 1990s. Psychol. Sci. 1(6), 333-341. Gilbert, W. (1991). Towards a paradigm shift in biology. Nature 349, 99. Harnad, S. R. (1992a). Interactive publication: Extending the American Physical Society's discipline-specific model for electronic publishing. Serials Rev. 18(1-2), 58-61. Harnad, S. R. (1992h). PSYCOLOQUY; a model forum for "scholarly skywriting." Serials Rev. 18(1-2), 60. Harrison, T. M., Stephen, T., and Winter, J. (1991). Online journals: Disciplinary designs for electronic scholarship. The Public-Access Computer Systems Review 2(1), 25-28. Hoke, F. (1994a). Scientists predict Internet will revolutionize research. The Scientist May 2, 1994 [Online], 8(9). Available: gopher.cic.nct, /e-serials/alphabetic/s/the-scientistlthe-scientist-940502. Hoke, F. (1994b). New Internet capabilities fueling innovative science. The Scientist May 16, 1994 [Onlinel, 8(10). Available: gopher.cic.net, Ie-serialslalphabetic/s/the-scientist/the-scientist-940516. Hunt, F. (1990). People, pitfalls and the electronic archive. Psychol. Sci. 1(6), 346-349. Langschied, L. (1994). Electronic journal forum: VPIEJ-L: An online discussion group for electronic journal publishing concerns. Serials Rev. 2O(1), 89-94+. Mount, D. W., and Schatz, B. R. (1994). A genomic database for Eseherichia coli: Total information on a given organism. In "Biocomputing: Informatics and Genome Projects" (D. W. Smith, ed.), pp.249-267. Academic Press, San Diego. National Research Council (U.S.). Committee on a National Collahoratory: Establishing the User-Developer Partnership (1993). National collaboratories: applying information technology for scien-tific research. National Academy Press, Washington, D.C. Okerson, A. (1991). The electronic journal: What, whence, and when? The Public-Access Computer Systems Review 2(1), 5-24. Okerson, A. (1993). Electronic journal publishing on the Net: Developments and issues. In "New Technologies and New Directions: Proceedings from the Symposium on Scholarly Communication, University of Iowa, November 14-16, 1991" (G. R. Boynton and S. D. Creth, eds.), pp.51-64. Meckler, Westport, Connecticut. Olson, J. (1994). "Electronic Journal Literature: Implications for Scholars" Mecklermedia, West-port, Connecticut. Pool, R. (1993). Computing in science~Beyond databases and e-mail. Science 261, 841-843.
|
||||
The Search Window contains elements common throughout the
rest of the application: popup menus, objects, buttons, and scroll
windows. To perform a function, for example, issue a command to an
object or enter data into a field, the object, box, or field must
be selected. To select an object or a field, click on it once. A selected
item will be highlighted in some way, either by a rectangular outline
or a reverse highlight (white characters on black background). In
the case of a box or a field, the cursor must be in that space before
data can be entered; you can type into a boxed field as well. Depending
on the function being performed, data may be added by (1) typing characters,
(2) copy and paste functions, or (3) selecting data from popup menus.
Popup menus in the Search Window include the Type Selection menu,
and the Type and Field Restriction menus. The user can type queries
or names of known objects in the Query Specification box and the Locator
box. Buttons in windows indicate Tools, Com-mands, or popup Menus
that list commands. Tool buttons are Thesaurus and History; Command
buttons include Search All and Search this Type; the Menu buttons
are Panel and Utilities. Scroll bars, on the right side of the Browser
Window, for example, allow movement through each window. As information
is added to a window, scroll bars may appear on the right side, or
on the bottom (to permit scrolling left and right across an image
or lineage).
