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.
"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]
TrickelNot 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".
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.
...arun
----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com
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.
WelchA 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].
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".
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)
LangstonI'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.
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.
LangstonThis, on the other hand, I couldn't agree with more.
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
----------------------------------------------------------------------------
Arun Welch
Senior Consultant, Venue
welch.mv@envos.xerox.com, or welch@anzus.com
TrickelCompare 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]
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.
>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")...."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.MCC Technical Report
Number STP-356-86 Rev. 2
Jeff Conklin
Page 15
*emphasis* added, [editorial comment]
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
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."Relationships needn't always be binary, that is.
John deVries
jad@lanl.gov
Reply From: welch@sacral.cis.ohio-state.edu (Arun Welch)
LangstonOr more than two nodes. If memory serves, this was the main idea behind AquaNet, ie, to provide n-ary links.
For all intents and purposes, consider a link to be a relationship that holds between two nodes (each node being a bit of information).
...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. :-)
TrickelGood 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?
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?
TrickelGood 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?"
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?
OlsonOops! 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.
What constitutes the class "links" and what subdivides this class into mutually exclusive bins that completely cover this class?
OlsonYeah, 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).
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?
OlsonNotice the specific "intended use."
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
OlsonThere's that requirement again. ;-)
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.
OlsonThis 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."
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).
OlsonIf 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.
Can anyone point to answers of this nature?
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)
BreedingHey, this is UseNet, we're equal-opportunity critics... :-)
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. :-)
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.
BreedingA 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.
The question for me is, what generic primitives (other than simple nodes and links) can we define?
BreedingI'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.
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.
BreedingCouldn't have said it better myself.
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.
BreedingThis 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.
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.
...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)
BreedingRight on target.
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.
BreedingAlso very true. However, do not design the link types such that they no longer reflect natural informational hierarchies.
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.
BreedingThen 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?
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.
BreedingPragmatically: 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.)
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.
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 ---
WelchI 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.
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.
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.