What is a Link Type &
How Many Are Enough

A USENET Discussion Compiled and Edited by Thomas Trickel

Abstract

This Web page is a compilation of a USENET discussion that resulted from a posting to alt.hypertext which raised the question how many link types where supported by different Hypertext systems. I've attempted to put a structure around the discussion that makes it both more readable and more accessible.

Summary

My question posting "So, can any of y'all out there comment on the number of link types that your [Hypertext] package supports and how many of those you use on a routine basis?" started the discussion. I expected rather simple answers that talked of using 10 to 20 link types. Link types that were of the nature of Image, Definition, Text Document, etc. The replies posted easily dispelled this simple view of link types.

The discussion split along two main threads: how many link types are sufficient and what is a link type. In the first thread, link type is interpreted to mean relationship between the two linked nodes. Given this definition of link type a Hypertext system that was designed to handle all conceivable information and to show all relationships of that information would require an infinite number of link types [Langston, Welch and Breeding on the number of link types required]. Such a system would be very difficult to construct. The solution to this is to create a set of link primitives [Breeding, Welch and Langston on link primitives] that can be easily modified by the user so that the user created link types will represent the information being presented.

The second thread questions what the term link type itself means. Two definitions are presented: what the link points to and how the information in the two or more nodes, that the link connects, are related [Langston, Breeding and Welch on Link Type]. The multiple definitions of a link type results from the poor choice of words used to describe links. By quoting Trigg's usage of "link type" I start the discussion off with this poor choice of words. A better and more descriptive choice of what I was asking about would be link properties. Rephrasing my original question in these terms results in "How many link properties does your hypertext system support and how many do you use on a regular basis?". Using this as a basis for defining a link I now understand that many link properties are desirable. Properties like what type of resource the link points to (picture, text or sound), where the resource is that the link points to, how the nodes connected by the link are related and the action the link causes in the Hypertext browser. (For a further discussion on this subject please refer to a paper I wrote on Link Properties)

Aside from the discussion of link type Mark Langston makes an important point that organization of the hypertext document is as important as the interface. This is true of any document but it is important to remember when creating Hypertext because without an underlying organization it is even easier for a user to get lost.

List of the Postings and Their Main Themes

The responses to my initial posting split into two threads that are later combined back into one thread. The first thread discusses whether infinite link types are necessary. The second thread discusses what a link type is. The two threads tie back together with a discussion on link type primitives.

Thomas Trickel's original posting "How many link types does your Hypertext system support".

Are Infinite Link Types Necessary?

What is a Link Type?

Link Primitives

Start of the Discussion

Thomas Trickel's Original Posting

I am reading an article from IEEE Sept. 1987 titled _Hypertext: An Introduction and Survey_ by Jeff Conklin. Pretty interesting so far but the reason for this posting is on pg 24 when the author is discussing Randall Trigg's PhD thesis and his Textnet system.

"Trigg describes over 80 such link types and argues that the disadvantage of having a limited set of link types is outwighed by the possibility of specialized processing on the hyperdocument afforded by a definite and fixed set of primitives."

My comment is: Wow! 80 link types hardly sounds like a disadvantage.

So, can any of y'all out there comment on the number of link types that your package supports and how many of those you use on a routine basis?

[Arun Welch's Reply on the number of link types supported by Notecards.]
[Kirtland H. Olson's comparison to Basic and question on what is a link type]

Reply From: welch@sacral.cis.ohio-state.edu (Arun Welch)

Trickel
So, can any of yall out there comment on the number of link types that your package supports and how many of those you use on a routine basis.

Not surprisingly, NoteCards supports an infinite number of link types [Mark Langston argues in favor of a small finite number of links]. You want a new type, you got it. It also supports an infinite number of card types, but you gotta work a little harder to define a new card type. It's pretty hard to define the number I use on a routine basis, it depends on what I'm doing. The NoteFile containing research stuff contains types of the sort "referenced-by" and "supports", and the poli-sci stuff contains types like "invaded" and "aggressor".

...arun
----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com

Reply From: graesserac@memstvx1.memst.edu

Trickel
So, can any of yall out there comment on the number of link types that your package supports and how many of those you use on a routine basis.

Welch
Not surprisingly, NoteCards supports an infinite number of link types. You want a new type, you got it. It also supports an infinite number of card types, but you gotta work a little harder to define a new card type. It's pretty hard to define the number I use on a routine basis, it depends on what I'm doing. The NoteFile containing research stuff contains types of the sort "referenced-by" and "supports", and the poli-sci stuff contains types like "invaded" and "aggressor".

A theoretical approach would get by just fine with a small finite number of link types. By efficiently organizing all info in the system around some theoretic knowledge-organization scheme (i.e. semantic network), one can easily limit and yet quickly and powerfully use a very small set of link types [Arun Welch refutes in favor of sufficiently general link type].

The power of hypertext does not rest in the interface alone; organization of the knowledge within the interface and the structure of the knowledge is just as important, if not moreso [Arun supports organization].

Mark C. Langston
Institute for Intelligent Systems
Psychology Dept.
Memphis State University
Memphis, TN 38152
(901) 678-2364 fugue@mindvox.phantom.com langston@memstvx1.memst.edu (inop for now) graesserac@memstvx1.memst.edu (I can receive mail here, just make sure you put "FOR MARK" in the subj line)

Reply From: welch@nervous.cis.ohio-state.edu (Arun Welch)

Langston
A theoretical approach would get by just fine with a small finite number of link types. By efficiently organizing all info in the system around some theoretic knowledge-organization scheme (i.e. semantic network), one can easily limit and yet quickly and powerfully use a very small set of link types.

I'm afraid I'd have to disagree on this one. With a sufficiently general link type mechanism the link types themselves can express the semantic net. There are losts of situations that can't be expressed easily with the typical 'is-a' and 'part-of' relations. Toulmin structures for example don't fit well into such a scheme.

Langston
The power of hypertext does not rest in the interface alone; organization of the knowledge within the interface and the structure of the knowledge is just as important, if not moreso.

This, on the other hand, I couldn't agree with more.

...arun
----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com

Reply From: olson@mydual.uucp (Kirtland H. Olson)

Trickel
I am reading an article from IEEE Sept. 1987 titled _Hypertext: An Introduction and Survey_ by Jeff Conklin. Pretty interesting so far but the reason for this posting is on pg 24 when the author is discussing Randall Trigg's PhD thesis and his Textnet system.

"Trigg describes over 80 such links types and argues that the disadvantage of having a limited set of link types is outwighed by the possibility of specialized processing on the hyperdocument afforded by a definite and fixed set of primitives."

Trickel
My comment is: Wow! 80 link types hardly sounds like a disadvantage.

Compare it to the BASIC language, which has about 80 commands. Some think it powerful, others think it limited. But the discussion only makes sense in the context of a structural limit that alters your ability to do something that you want to do. Are you enabled or disabled by the system choices? [Dave Breeding agrees]

>So, can any of yall out there comment on the number of link types that
>your package supports and how many of those you use on a routine basis.

I can't answer this question to my satisfaction. As a user of HyperRez and Hyplus (MaxThink products), I've not yet found a way to implement multiple independent threads that maintain an independent sense of next and previous along each thread. But I don't *know* if that's a link *type*. Rather than an answer, I find myself with a question.

What's a link type? [Mark Langston's or Dave Breeding's definition of a link type]

What constitutes the class "links" and what subdivides this class into mutually exclusive bins that completely cover this class?

In that regard, I'm disturbed by classifications that depend on the use of the link as opposed to an intrinsic property of the link. How does one tell hammers from screwdrivers and chisels if the actual use or abuse determines the classification?

To give a simple example,

"Trigg further proposes a specific taxonomy of link types *for use by collaborators and critics* in Textnet (see Table 1 [omitted]). The idea is that there are generally a specific set of types of comments, and that there is a link type for each comment. For example, there are "refutations" and "support" links, and, more specifically, there are links to say that a point is irrelevant ("Pt-irrelevant"), that data cited is inadequate ("D-inadequate"), or that the style is rambling ("S-rambling")...."

MCC Technical Report
Number STP-356-86 Rev. 2
Jeff Conklin
Page 15
*emphasis* added, [editorial comment]

Even using Conklin's criteria that the system must make use of the link property for it to be a link type, I think of these as some kind of macros that adapt one link type to several uses. And I assert that point, proof, and style do not qualify as mutually exclusive subdivisions of a single class since they are simultaneous properties of exposition.

None of this reduces the utility of Trigg's constructions, nor does it argue against the flexibility of Notecards's infinite number of user-definable constructions. But I think it does suggest that they are not taxonomies, and that some fundamental classification of links remains unexpressed. That is, we do not understand links as we may understand outlines and distinguish two fundamentally different types (Mills and Walter, _Technical Writing_, 4th Ed., 1978, ISBN 0-03-089905-2, and Franklin, _Writing for Story_, 1986, ISBN 0-689-11785-X).

Can anyone point to answers of this nature?

--
Kirtland H. Olson olson%mydual.uucp@alliant.com

Reply From: langston@memstvx1.memst.edu (Mark C. Langston)

Olson
What's a link type?

For all intents and purposes, consider a link to be a relationship that holds between two nodes (each node being a bit of information). Therefore, a link type is concerned with the type of relationship that holds between any two nodes [John De Vries and Arun Welch mention that it could me more than two nodes].

Olson

What constitutes the class "links" and what subdivides this class into mutually exclusive bins that completely cover this class?

This could readily depend on a) whether your system is link-heavy and link- dependent (as are most systems...the links determine the kind of information that will be connected via them), or b) whether your system is link-light and node-dependent (the information in any two (or more) nodes determines the link relationship...in a sense, a variable set size of links dependent upon the information your system contains)

Olson
In that regard, I'm disturbed by classifications that depend on the use of the link as opposed to an intrinsic property of the link. How does one tell hammers from screwdrivers and chisels if the actual use or abuse determines the classification?
[...exampled gone deletia way...]
Olson
Even using Conklin's criteria that the system must make use of the link property for it to be a link type, I think of these as some kind of macros that adapt one link type to several uses. And I assert that point, proof, and style do not qualify as mutually exclusive subdivisions of a single class since they are simultaneous properties of exposition.

Very true.

Olson
None of this reduces the utility of Trigg's constructions, nor does it argue against the flexibility of Notecards's infinite number of user-definable constructions. But I think it does suggest that they are not taxonomies, and that some fundamental classification of links remains unexpressed. That is, we do not understand links as we may understand outlines and distinguish two fundamentally different types (Mills and Walter, _Technical Writing_, 4th Ed., 1978, ISBN 0-03-089905-2, and Franklin, _Writing for Story_, 1986, ISBN 0-689-11785-X). Can anyone point to answers of this nature?

Well. Consider information as existing in space. This in-space (pun intended) has a certain topology. The topology should be determined _by_the_information_forming_it_, and not by any topological constraints. If there exists a taxonomic, spatial, procedural, causal, sensory, or definitional relationship between one bit of info and another, these two bits of info should form a certain landscape in the in-space, and should not be constrained to try to force themselves into existing/acceptpable relationships set forth by the landscaper.

Trying to write a ht by forcing relationships into set link types is like trying to put every piece of a jigsaw puzzle with the same (or nearly the same) shape into the exact same spatial location. Any two bits of not completely unrelated information share some type of relationship (often found in taxonomies of semantic nets...and I'm talking way beyond isa arcs...), and this relationship should be explored and exploited instead of subdued.

That's enough outta me for a few hours. Cheerios.

Mark C. Langston "Secrecy is the beginning of tyranny."
Psychology Dept. C A R P E "Always listen to experts. They'll tell you
Memphis State U. your own #@$% what can't be done, and why. Then do it."
"Pftph!" D I E M --- From the notebooks of Lazarus Long ---
Just to put a fly in the ointment, isn't this a tad restrictive? Like, couldn't the wording be "a link is a relationship that holds between two or more nodes..." ?

Relationships needn't always be binary, that is.

John deVries
jad@lanl.gov

Reply From: welch@sacral.cis.ohio-state.edu (Arun Welch)

Langston
For all intents and purposes, consider a link to be a relationship that holds between two nodes (each node being a bit of information).
Or more than two nodes. If memory serves, this was the main idea behind AquaNet, ie, to provide n-ary links.

...arun
----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com

Reply From: exudeb@exu.ericsson.se (Dave Breeding, xt-dGR,)

Disclaimer: I have not read any of the papers or books mentioned in this posting. I am simply responding to the contents specifically included. If I don't know what I'm talking about, please let me know. :-)

Trickel
My comment is: Wow! 80 link types hardly sounds like a disadvantage.

Olson
Compare it to the BASIC language, which has about 80 commands. Some think it powerful, others think it limited. But the discussion only makes sense in the context of a structural limit that alters your ability to do something that you want to do. Are you enabled or disabled by the system choices?

Good answer! Any predefined set of capabilities is going to be adequate for some applications, and inadequate for others. There will be a lot of difference between a set of primitives defined to support a specific kind of document, and a set defined to support any kind of hypertext document at all. The question for me is, what generic primitives (other than simple nodes and links) can we define?

Trickel
So, can any of yall out there comment on the number of link types that your package supports and how many of those you use on a routine basis.

Olson
I can't answer this question to my satisfaction. As a user of HyperRez and Hyplus (MaxThink products), I've not yet found a way to implement multiple independent threads that maintain an independent sense of next and previous along each thread. But I don't *know* if that's a link *type*. Rather than an answer, I find myself with a question.

What's a link type?

Good question! I suspect the answer has to do with the structure and behavior of the links. (see below) As an aside, I would add another potentially interesting question, "What's a node type?"

Olson
What constitutes the class "links" and what subdivides this class into mutually exclusive bins that completely cover this class?

Oops! I would go along with a requirement that each link in a document must have one and only one type; but not that the set of defined types must "partition" the class of all possible links.

Olson
In that regard, I'm disturbed by classifications that depend on the use of the link as opposed to an intrinsic property of the link. How does one tell hammers from screwdrivers and chisels if the actual use or abuse determines the classification?

Yeah, reality can be disturbing. ;-) In my opinion, the greatest discovery of the twentieth century has been that meaning is determined by usage (extrinsic), and not by anything intrinsic. The name "hammer" may indicate what the object was designed for (its intended use), but it does not limit what it is actually used for (its extended use).

Olson
To give a simple example,
"Trigg further proposes a specific taxonomy of link types *for use by collaborators and critics* in Textnet (see Table 1 [omitted]). The idea

Notice the specific "intended use."

Olson
Even using Conklin's criteria that the system must make use of the link property for it to be a link type, I think of these as some kind of macros that adapt one link type to several uses. And I assert that point, proof, and style do not qualify as mutually exclusive subdivisions of a single class since they are simultaneous properties of exposition.

There's that requirement again. ;-)

Olson
None of this reduces the utility of Trigg's constructions, nor does it argue against the flexibility of Notecards's infinite number of user-definable constructions. But I think it does suggest that they are not taxonomies, and that some fundamental classification of links remains unexpressed. That is, we do not understand links as we may understand outlines and distinguish two fundamentally different types (Mills and Walter, _Technical Writing_, 4th Ed., 1978, ISBN 0-03-089905-2, and Franklin, _Writing for Story_, 1986, ISBN 0-689-11785-X).

This seems to be comparing apples and oranges. An outline is a fairly high level and specifically defined structure; a link is a fairly low level and generically defined concept. In fact, you can probably think of several ways that an outline could be composed of nodes and links, even allowing for different definitions of "nodes" and "links."

Olson
Can anyone point to answers of this nature?

If we think of a node as representing an item of information (an idea, a topic), and a link as simply an association (for some purpose) between two (or more) nodes, then it is clear that there is no limit to the number of different "types" of links we might want. This means that we should allow a user to define the link "types" needed (by that user) for a particular document. The types defined would support the "intended uses" of the document, and if an additional potential use is identified, an additional link "type" can be defined.

As for the definition of new link "types", how about a set of structural (number of nodes, position (or "role") of each node) and behavioral (forward, backward, down, up, remember, gather, sort, etc.) primitives from which a user could define (and name) the set of link "types" to be used for a specific document.

Dave

Reply From: welch@nervous.cis.ohio-state.edu (Arun Welch)

Breeding
Disclaimer: I have not read any of the papers or books mentioned in this posting. I am simply responding to the contents specifically included. If I don't know what I'm talking about, please let me know. :-)

Hey, this is UseNet, we're equal-opportunity critics... :-)

Breeding
There will be a lot of difference between a set of primitives defined to support a specific kind of document, and a set defined to support any kind of hypertext document at all.

Right, and since the latter is a superset of the former, a general system is more useful.

Breeding
The question for me is, what generic primitives (other than simple nodes and links) can we define?

A rather interesting paper wandered across my desk recently. "Hypertext Case Study: An Object-Oriented Specification", but Andreas Ruping of Furschungszentrum Informatik an der Universitat Karlsruhe, technical report ProSt/92-2. I can't say I agree with all of it, but it's certainly a stab in the right direction.

Breeding
Oops! I would go along with a requirement that each link in a document must have one and only one type; but not that the set of defined types must "partition" the class of all possible links.

I've been thinking recently that links should be hierarchical, allowing mixins. NoteCards doesn't support this yet (well, it does, but it ain't easy to use), I'm still playing with the idea. This of course is coloured by my CLOS/LOOPS background, but it looks like there are some real advantages to this.

Breeding
If we think of a node as representing an item of information (an idea, a topic), and a link as simply an association (for some purpose) between two (or more) nodes, then it is clear that there is no limit to the number of different "types" of links we might want. This means that we should allow a user to define the link "types" needed (by that user) for a particular document. The types defined would support the "intended uses" of the document, and if an additional potential use is identified, an additional link "type" can be defined.

Couldn't have said it better myself.

Breeding
As for the definition of new link "types", how about a set of structural [...] and behavioral [...] primitives from which a user could define (and name) the set of link "types" to be used for a specific document.

This is where an OO aproach can be a real win, you can pick up the structural stuff from the instance and the behavioral stuff from the methods defined for that class (or instance, if you want a *really* specific instance type). The problem with this is that you need to provide enough existing behavior so that inserting a link is still a trivial operation. If building links is a major production then the system's gonna lose big.

...arun
----------------------------------------------------------------------------
Arun Welch send mail to get the
Senior Consultant, Venue NoteCards demo.
welch.mv@envos.xerox.com, or welch@anzus.com

Reply From: langston@memstvx1.memst.edu (Mark C. Langston)

Breeding
There will be a lot of difference between a set of primitives defined to support a specific kind of document, and a set defined to support any kind of hypertext document at all.

Welch
Right, and since the latter is a superset of the former, a general system is more useful.

Right on target.

Breeding
The question for me is, what generic primitives (other than simple nodes and links) can we define?

Welch
A rather interesting paper wandered across my desk recently. "Hypertext Case Study: An Object-Oriented Specification", but Andreas Ruping of Furschungszentrum Informatik an der Universitat Karlsruhe, technical report ProSt/92-2. I can't say I agree with all of it, but it's certainly a stab in the right direction.

Breeding
Oops! I would go along with a requirement that each link in a document must have one and only one type; but not that the set of defined types must "partition" the class of all possible links.

Welch
I've been thinking recently that links should be hierarchical, allowing mixins. NoteCards doesn't support this yet (well, it does, but it ain't easy to use), I'm still playing with the idea. This of course is coloured by my CLOS/LOOPS background, but it looks like there are some real advantages to this.

Also very true. However, do not design the link types such that they no longer reflect natural informational hierarchies.

Breeding
If we think of a node as representing an item of information (an idea, a topic), and a link as simply an association (for some purpose) between two (or more) nodes, then it is clear that there is no limit to the number of different "types" of links we might want. This means that we should allow a user to define the link "types" needed (by that user) for a particular document. The types defined would support the "intended uses" of the document, and if an additional potential use is identified, an additional link "type" can be defined.

Welch
Couldn't have said it better myself.

Then why would it be incorrect to devise a set of link types applicable to all information types (here I am discussing relational links, and not functional links), and allow the user to choose the subset of links that pertains to the particular document?

Breeding
As for the definition of new link "types", how about a set of structural [...] and behavioral [...] primitives from which a user could define (and name) the set of link "types" to be used for a specific document.

Welch
This is where an OO aproach can be a real win, you can pick up the structural stuff from the instance and the behavioral stuff from the methods defined for that class (or instance, if you want a *really* specific instance type). The problem with this is that you need to provide enough existing behavior so that inserting a link is still a trivial operation. If building links is a major production then the system's gonna lose big.

Pragmatically: good point. Theoretically: What will form the basis of these primitives? As I have stated before, the natural relationships existing between different types of information should suffice (such as those found in semantic networks.)

Just thought some of this meshed nicely with what I've tried to say before, and may clarify it for some people.

--
+--------8<------Cut Here------8<------Cut Here------8<------Cut Here---------+

  Mark C. Langston                 "Secrecy is the beginning of tyranny."
  Psychology Dept.    C A R P E    "Always listen to experts.  They'll tell you
  Memphis State U.  your own #@$%   what can't be done, and why.  Then do it." 
      "Pftph!"         D I E M      --- From the notebooks of Lazarus Long ---  

Reply From: welch@sacral.cis.ohio-state.edu (Arun Welch)

[Pardon me if I'm not entirely lucid, I'm battling off a wild virus of some sort. However, I did want to keep this discussion going.]

Welch
I've been thinking recently that links should be hierarchical, allowing mixins. NoteCards doesn't support this yet (well, it does, but it ain't easy to use), I'm still playing with the idea. This of course is coloured by my CLOS/LOOPS background, but it looks like there are some real advantages to this.

Langston
Also very true. However, do not design the link types such that they no longer reflect natural informational hierarchies.

I think what's happening here is name collision on the phrase "link type", almost certainly my fault. In NoteCards a link has a type which is set when the link is made. For example, when I make a link between a concept and the reference to it, I might make a "reference" link. Think of it as simply a descriptive slot, though it does have more functionality. These pretty naturally reflect the informational hierarchies, since they're put in at the time the document is made by the creator. There's no limit on these sort of types.

The other interpretation for "link types" is in their functionality, things like "this is a link from this point in this document to another point in the same document", "this is a link from this point in this document to another document", "this is a link from this point to those points", stuff like that. Sorry about this, I'll call these link functional types from now so we're at least using the same terminology.

I think this pretty much answers all the rest of the points you've made too.

ps. sometime next week I'm gonna move over to the welch@anzus.com address, as soon as I get news working over there. Still me, different address.

----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com

Comments appreciated. Reply to:

ttrickel@ronan.net
About the editor.