We're trying to define relations between hypertext pages. Hypertext is
the informal knowledge representation format par excellence and it
would therefore be strange to straightjacket it into a formal
relational algebra.
In fact, since hypertext is read by human beings rather than machines,
the number of relations must be very small and must fit a simple model
of inter-document relations. Apart from the flat web of pages that we
have now, I can think of only one other model: a hierarchical
collection (cf. Hyper-G).
Of course, I don't want to forbid people from collecting pages with
the help of robots, but that can be easily achieved with either the
notion of a hierarchical collection (see below) or with proprietary
values for CLASS.
So, what remains of Murray's list? Not much. Sorry, Murray:-).
TOP, PARENT, CHILD
I would like to keep these, since they constitute a useful
enrichment of the currently rather flat web. They introduce the
concept of a hierarchical collection, something that, I think,
people have little trouble grasping. A browser could follow TOP or
PARENT links and show a tree diagram of CHILD links, to aid the
user in navigation. (cf. Hyper-G's `Harmony' browser, except that
the parent-child relations are now distributed over the documents
and not kept in a central database.)
The rest is not needed:
MADE
It is unfortunate that this value is already widely used, since it
doesn't link two documents, but provides meta-information. It
should have been a separate element or part of <META>.
HOME, BACK, FORWARD
A document has no business trying to link to these. There is no
way a document can assign a meaning to the document that the user
(or robot) just left. For an applet this would be a different
matter; one expects an applet to have access to most of the
functions of the browser.
BIBLIOGRAPHY,... NAVIGATE
No document is just a bibliography or just a table of
contents. Remember this is hypertext, not a database. The user can
be directed to these links with an informal description in
natuaral language.
BEGIN,... NEXT
These can again be handled informally. The BANNER area of HTML3
can help to keep the links in a non-scrolling region.
ARTWORK,... THESIS
A document can type itself (using CLASS on the BODY tag, for
example), but there is no need for a hyperlink to type its
target. In hypertext there are no books or journals, except that
some pages may have the character of such a thing. The type of
thing can be communicated to the user informally by the FIG or A
element.
ABSTRACT, BIBLIOENTRY, CITATION, DEFINITION
Can be done informally (btw. in Web, the biblioentry is simply a
URI, isn't it?)
FOOTNOTE
(Foot)notes are links to documents that are so short and specific
that they are better embedded in the main text itself. HTML3 has
the FN element for this.
INCLUDE
This is not a hyperlink at all, but a convenient syntactic
variant, to save typing and/or bandwidth. Whether we need this in
HTML is a separate discussion, but if we decide we do, then an
<INCLUDE SRC=...> element seems more appropriate. (Another
possibility is to support SGML entities.)
COPYRIGHT,... URC
Meta-info belongs in the META tag. If, on the other hand, the info
is meant for human consumption, then an ordinary, informal A tag
is good enough.
BANNER
Like INCLUDE, this is not a link. HTML3 has a BANNER element,
which can be used for this. The syntax can vary, maybe use INCLUDE
inside BANNER, or add a SRC attribute to BANNER.
STYLESHEET
Also not a link. The STYLE element can get a SRC attribute
instead.
NODE, PATH
The idea of guided tours is appealing, but the mechanisms proposed
so far don't seem to catch people's imagination. I understand how
NODE and PATH are supposed to work, but I find it difficult to
implement. Two other solutions might be: (1) define a new document
format "application/hypertour" consisting of a list of URLs; (2)
forget about tours and use a (shallow) hierarchical collection
instead (TOP, PARENT, CHILD, see above).
Bert
PS. Not even HyTime can type its links, except with a #FIXED attribute
in the DTD. Some people are currently trying to get #FIXED changed to
#REQUIRED, though.
--
Bert Bos Alfa-informatica
<bert@let.rug.nl> Rijksuniversiteit Groningen
<http://www.let.rug.nl/~bert/> Postbus 716, NL-9700 AS GRONINGEN