3.1068 SGML and hypertext, cont. (126)

Willard McCarty (MCCARTY@vm.epas.utoronto.ca)
Fri, 16 Feb 90 22:48:03 EST

Humanist Discussion Group, Vol. 3, No. 1068. Friday, 16 Feb 1990.


(1) Date: Thu, 15 Feb 90 09:31:54 PST (35 lines)
From: cbf%faulhaber.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber)
Subject: hypetext and sgml

(2) Date: Wed, 14 Feb 1990 22:26:42 EST (78 lines)
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: Re: electronic critical editions (SGML vs. hypertext)

(1) --------------------------------------------------------------------
Date: Thu, 15 Feb 90 09:31:54 PST
From: cbf%faulhaber.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber)
Subject: hypetext and sgml

Thanks to Dominink, Michael, and Malcolm

The point I was trying to make is that I can mark up the text by coding
for certain features or I can link those features to some node outside of
the base text without marking it up. I will assume a sophisticated
editor which will allow me to do either one of these operations
relatively painlessly (remember, we're talking 21st century here). Are
there advantages or disadvantages, theoretical or practical, to doing it
one way or another? I can see clear advantages to hypertext for linking
up separate texts. What doesn't seem clear is what to do about making
connections WITHIN a text. I will also assume a sophisticated text
retrieval system so that verbal parallels of all sorts could be handled
on the fly, by the user, rather than having to be specifically prepared
by the editor. I quite agree with Michael that any hypertext system
which cannot import and export standard ASCII texts (or standard SGML
texts) would not be a suitable choice.

Charles Faulhaber
UC Berkeley


(2) --------------------------------------------------------------87----
Date: Wed, 14 Feb 1990 22:26:42 EST
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: Re: electronic critical editions (SGML vs. hypertext)

Charles Faulhaber writes:

I am currently struggling to figure out . . . the relative merits of
coding a particular feature via SGML or linking a region of text to
another node in the system.

In some hypertext systems, one can "block" selected text and use the
block as the bearer of attributes. Blocks can also function as end
points of links, but people are beginning to concede to them a primacy
over links. From one perspective, links depend on the existence of
blocks---no link can exist without two end points. But blocks can exist
even after the last link has been deleted. Furthermore, blocks can be
created without any links being created. Note that the trend is to
refer to blocks as "anchors", but the term "anchor" fails to capture the
independence of blocks from links.

I got excited about these issue some months ago when discussing a Milton
edition with Roy Flannagan (his). It seemed to me then that one might
create blocks to mark up the allusions, for example. Then, should the
text of the Iliad become available, one would link the blocks to the
referent. To generate the SGML version of the document (sans links),
one would insert the block information into the text in SGML format.
These seemed to me a very intuitive way to markup a document.
Unfortunately, blocks can overlap each other, but SGML entities cannot
normally overlap. More practically, we do not have a hypertext system
with such export capabilities. Also, specifying the mapping of block
explainers onto SGML tags might well be complicated.

Whoops, I think I forgot to mention that blocks have explainers. Also,
they should have keywords. Types do not seem to be needed along with
explainers. In addition, one would like to have a "rubber stamping"
facility or even keystroke macros to simplify the process of assigning
the same explainer or keyword to many blocks.

The advantage of such a system over an SGML editor might be the built-in
filtering capabilities as well as the ability to build on the markup to
link things together. There is some risk here of confusing a data model
with an interface practice or even with a particular implementation.
One could argue that an SGML markup scheme is semantically equivalent to
a hypertext interface and database, at least to the extent that both can
contain the same information, so it would be a little bit confused to
say that an SGML editor does not or would not provide the same abilities:

Give me a list of all blocks with the keyword allusion.
Give me a list of all blocks with the keyword allusion, that I own
and have modified in the last six months.
...

Well, an SGML editor could provide similar capabilities, although if it
did I think we would tend to call it an SGML/Hypertext system.

I suppose that I should raise one final, related concern. What can it
mean to compare SGML and hypertext? I don't have the answer to this.
SGML is a markup definition language and hypertext is a.... Well, Ted
Nelson says that we have been speaking hypertext all of our lives and
just did not know it. Others say things like non-sequential or
non-linear reading and writing. Others talk about things like networks
and cards, sometimes treating links as computed similarity measures. I
am working on a more precise characterization than I have seen so far,
but it will be very fuzzy compared to SGML.

In the end, it might be fairest to compare SGML editors with hypertext
editors. I think Charles is comparing hypertext editors (or systems)
with the use of a generalized editor to type in SGML tags. One
possibility would be to compare current SGML editors with current
hypertext systems. This might be a little fairer, given that the state
of the art in SGML is beyond the generalized editor and that most people
do not have access to either hypertext or SGML editors.

--Jim

Dr. James H. Coombs
Senior Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University, Box 1946
Providence, RI 02912
jazbo@brownvm.bitnet