gilbertd at sunflower.bio.indiana.edu (Don Gilbert) writes:
>For those who prefer to use the Mosaic client from NCSA for
>internet browsing, an alternate entry to the IUBio Archive
>for mosaic is this URL:
>gopher://ftp.bio.indiana.edu/11%09%2Btext/html
>This will provide an HTML page with entries for the gopher items.
>Mosaic still is not a gopher+ client, and there are many items
>in this archive that can only be used by gopher+ clients.
>I still regard gopher and html/www as competitors, and feel
>that gopher in general is as good or better a protocol for
>network information services as html/http/www. But the pretty
>face of Mosaic has lured away many people from gopher use.
>As people find some of the hypertext linkages, and built-in
>graphics displays, useful for browsing & searching bioscience
>information, I plan to try adding some of that to my gopher client.
>I don't have the time and resources that NCSA/CERN have for building
>their systems, so my work won't be as fancy. However,
>it is pretty straight forward to get gopher to do hypertext type
>links, and graphic and rich text displays.
>If you have a view on gopher+ versus mosaic/http/html/www for use
>in biosciences information services, please feel free to comment here
>or by mail to me. I'd not like to spend time developing gopher further
>if every one moves away from it to the other side.
>Some of point which I see make gopher preferable to mosaic are these:
>gopher is a single protocol, www is an amalgam of all the internet
>protocols. The upshot of this is that any usable www client has to
>know a kitchen sink of network protocols, whereas gopher can be a
>simpler program. I can put a gopher client inside a more complex
>biosciences program; putting a Mosaic into another program would be
>a larger task.
I'll agree with you that truly integrating Mosaic into a program would
be difficult. However, a degree of linkage is easily accomplished (at
least on UNIX machines). Mosaic can be launched by another program, and
it is possible to use the remote control facility to maintain control of
Mosaic by the invoking program. I've used this for a few things.
For example, I have developed a Perl script to convert BLAST output
to HTML. I've now added it locally to the GDE menus, so that if you
run BLAST from GDE the results can come back in Mosaic. I've done
something similar for another personal project -- click on a screen region
region and an appropriate report pops up within Mosaic.
It's also possible to fetch HTML text off a server and
remove the HTML formatting (i.e. convert to a flat text suitable for
a gopher server). This can be done via Perl scripts or the CERN
line-mode browser. It's also possible to fetch the HTML and do other
things with it -- I've used this extensively for enhanced gateways and
such.
>mosaic/www rely on images and rich text heavily, which imposes much
>more demand on network and client computer resources. Gopher can
>work well over slow telephone lines and on simpler computers.
While WWW does use a lot of images, the non-linear nature of hypertext
allows documents to be broken into small chunks. Unfortunately, most
HTML writers don't seem to take advantage of this finer granularity,
but it is available. Most of the images on WWW documents are decor
or aids and don't really need to be viewed (though again, not all
HTML document writers write their documents to allow non-graphical
access).
>hypertext is not as important a way of organizing information as the
>simpler table-of-contents and index format that gopher uses. Though
>I agree there are cases where hypertext is useful, there are more cases
>where it is more confusing than is a more organized table-of-contents
>style of information. Macintosh users have had hypertext in the form
>of Hypercard for many years, and I've yet to see any significant use
>of the hypertext capabilities of Hypercard for biological information.
Tables of contents are indeed highly useful, and it is sad that more
aren't used in HTML land. However, one advantage of HTML over gopher
(at least as far as I know -- feel free to update me) is the
capability of hierarchecal TOCs.
>gopher presents a "file cabinet" view of network information, compared
>to mosaic's hypertext view. This is certainly a point of individual
>preference, but I think that the folders and files view thru gopher
>better fits the majority of network information than does hypertext views.
I really think (as noted below)
that hypertext does open _new_ ways of organizing information
which are intuitive and powerful to use. The world has thought in
terms of simple indices and files for so long because no other
scheme was practical; hypertext allows other such schemes to
be realized.
>It is my impression that www server administrators must put in much more
>effort creating a usable HTML view of their information than gopher
>server administrators need to put in organizing data for gopher
>presentation.
The key advantage of hypertext over flat-text (i.e. gopher) is when
you actually get to a data node. With flat-text, you are done. With
hypertext, you can eliminate such dead ends. This is particularly
useful with biological databases, as most contain lots of references
to other databases. For example, suppose I search FlyBase for a gene
and the listing for that gene contains a Prosite reference. If I fetched
the FlyBase entry from a Gopher server, then I must separately search
Prosite manually, but if the FlyBase entry were hypertexted I could go
directly. It is this sort of rich browsing that makes hypertext so
attractive.
Another useful dimension to hypertext is to create
tutorials documents, annotated bibliographies, and such. Again,
rather than creating static documents, one can create documents that
really do serve as gateways to other literature & data. After all,
no scientific document is a self-contained work -- they all rely
on outside references to supply important information. Hypertext
provides a means for actually making such links work easily, rather
than requiring additional effort on the part of the user.
Creating hypertext from well-formatted databases is almost
trivial -- it simply requires a little bit of parsing. The major
impediment is the limited number of network databases which have
fetch-by-stable-id interfaces. Such interfaces are rarely useful
to humans, but essential for hypertext creation (because then
stable id references in other documents can be converted cleanly
to hypertext references).
There is clearly a need to support low-bandwith folks who
wish to use on-line databases. Abandoning gopher would be a bad idea,
rather gopher-type interfaces could serve as parallel access trees to
hypertext databases. Lynx is a good tool (and now has forms), and it
is possible (at least on some platforms) to have gopher transfer control
to Lynx if it hits a hyperlink.
People interested in maintaining both gopher and WWW should
look into the GN server. It lets you create gopher menus with optional
hypertext, and can be accessed by either HTTP or Gopher protocols.
Keith Robison
Harvard University
Department of Cellular and Developmental Biology
Department of Genetics / HHMI
krobison at nucleus.harvard.edu
