gnu@hoptoad.UUCP (11/07/87)
[Apple's Hypercard has more to do with "hype" than with "hypertext". If you are looking for a hypertext system, look elsewhere. I think of hypercard as "shell scripts for the Mac".] Now to the real topic -- the Hypertexting of Usenet. People have been proposing various strange character conbinations to indicate hypertext content. This is pretty silly. (1) We haven't figured out what kinds of information we want to convey, so picking a representation is premature. (2) We already have a representation for the major thing we need -- document to document links. This is the <messageid@uniquehost> notation. Most proposed hypertext systems give the ability to link one piece of text with another one, down to the character or word level. Usenet currently only provides this at the article level, but for the next few years I think that's fine. Current literary references (citations, bibliographies, footnotes, etc) typically refer to the page or section level, which is about the same amount of text as a Usenet article. ----- A major problem with turning the Usenet into a hypertext system is the automated following of links. Let's say I have an article which references article <1234@hop.toad.com>. I don't have a copy of 1234. (Maybe it expired, maybe I didn't subscribe to it, maybe it got dropped by somebody 3 feeds away.) How do I get a copy? Currently this is all done manually. Though there are large archives kept at various places, automated retrieval, even if you know the unique message-ID of the article, is in an infant stage. Before we start considering how to build the user interfaces and such, I think we should shore up the infrastructures so that all the data which is *somewhere* accessible on the network can be gotten without human intervention. *Then* build mechanisms, beyond the current References: lines and such, for indexing this information so that you can go from a desire-for-info-on-widgets to a bunch of article-IDs to the actual articles. Ideally I'd like to see a distributed database, updated when any user does an "s" command to save a copy of an article (if that user & site are willing for other people to be able to get it from them), that would allow anybody else to locate and retrieve that article. Hugh Daniel and Jeff Anton and I sat down and designed a candidate database setup a month ago, and it may be doable with a year or two of work. ----- This is not to say that we should abandon user interface work on the Usenet; far from it! But the timbers under the net are pretty rotten for the kind of loads we will want to put on 'em, once we have better user interfaces. John
bzs@BU-CS.BU.EDU (Barry Shein) (11/07/87)
Re: John Gimore's note I think your note draws out excellent points but I do disagree with the rejection of establishing a generalized hook into the text early. The goal there was to provide one of the several critical things I believe people need to begin working on these systems. I suppose part of the difference in view is whether some-one- will just go away with the basic concept, come up with something that solves all the problems and post it to the net (and incorporate whatever solutions s/he has found and that will be that.) Although I believe some of this will occur I think we do need to speak as a community intellect about what we are willing to tolerate and what our goals are. Laying out a certain amount of this in public is a great way to avoid design errors. You propose that only article linking is necessary at this stage. I think it just opens the same can-o-worms. Do we allow multiple links? If we do can we have some way of distinguishing why these particular links exist, for example "HISTORY: <1234@hop.toad.com>" as one link and "LEGAL: <5678@bu-cs.bu.edu>" as another? I would claim that if that is found attractive it may as well have been dropped down to the textual level as all that engenders is re-encoding the information already in the text (although I could still see tagged links as desirable, I guess my point is information theoretic, there's no way to throw the bathwater out w/o the baby.) I agree strongly on your ideas about a distributed data base. Even on the site specifics it's also occurred to me that a user doing a 's'ave on an article should just somehow create a pointer and stop expire from reaping the article rather than saving the text in a personal file. In fact, analysis of such pointers could provide a lot more depth to the kind of statistics gathering that Brian Reid does about net behavior. It would provide the feedback that Ted Nelson talked about in his hypertext systems where somehow we know precisely who is being read and cherished (gather the pointers from 1000 sites, break them down by author, you've got some sort of popularity [not necessarily positive] indicator.) Anyhow, I await reactions. -Barry Shein
dan@WILMA.BBN.COM (11/10/87)
If we really want to have linking at the sub-article level, don't we need to specify the region covered by a link, rather than assuming that a link reference pertains to the last word/phrase/concept before the reference? There's a lot of ambiguity there; imagine a paragraph expressing an idea which ends in an example, followed by a reference. You really need some way to know whether the referenced article discusses the idea of the paragraph, or just describes the example. Personally, while I think it's great to try to nail down the format this way, I'd like to see the design more fully worked out first. Until then, I think article referencing would be a good way to prototype the system, since there are so many article cross-references floating around already that you can try out ideas with. Dan Franklin
tower@BU-IT.BU.EDU (Leonard H. Tower Jr.) (11/11/87)
Might I suggest a better way of implementing this?
No, not GNU's texinfo ;-} (though anyone serious about Hypertext
should have a glance - it is documented with working source code in
the GNU Emacs distribution {ask gnu@prep.ai.mit.edu if you don't know
how to get it}). [Note: texinfo is a successor to ITS' info: one of
the earlier documentation databases with Hypertext capabilities].
Inserting strange strings in the text (aka body) of a netnews article
is a bad idea. Just annoys people with the existing news readers.
Shouldn't rile the users unnecessarily.
Such Hypertalk pointers should be added to news articles as header
lines. Following RFC822:
X-Hyper-Pt: <syntax-and semantics-to-be-defined>
And maybe have as many in the header as there are references.
Could define several X-Hyper-Pt-*: fields, but that seems overkill,
particularly since we want it easy for non-Hyper-users to cause
non-display of X-Hyper-Pt: header lines.
Obviously, I am just suggesting how this information will be stored in
the news spool and in the transfer of articles between news spools.
It will be the duty of the Hyper-posters/readers to transfer both ways
between what's displayed on the screen and X-Hyper-Pt:'s. {And if I
hear anyone in this forum complain about the extra cycles ... ! ;-}
Might still want to adopt a screen syntax that is unlike any other to
save confusion, but this is really a Hyper-news-reader-poster
question, and might be best left to the different implementors. This
might also be an application for which we declare dead glass 24x80 tty
screens.
If you people are really serious, write up and submit an RFC, and make
sure it receives exposure on USENET. You might convince me to
-request a working group mailing list here at BU, and kibitz.
enjoy -len
PS: The discussion on >80 column lines happening over in news.all
mentions SGML as a new format for text/body of news articles. Both
the discussion and SGML might be worth a glance. The problems share
some attributes.
My preference is to leave the text/body clear of embeded commands, and
place the commands in the header.tms@iris.UUCP.UUCP (11/12/87)
In article <> you write: >If we really want to have linking at the sub-article level, >don't we need to specify the region covered by a link, rather >than assuming that a link reference pertains to the last >word/phrase/concept before the reference? There's a lot of >ambiguity there; imagine a paragraph expressing an idea which >ends in an example, followed by a reference. You really need >some way to know whether the referenced article discusses the >idea of the paragraph, or just describes the example. > I'm replying by e-mail rather than posting to the net because our net connection is a diode pointing at me. You may know that we at IRIS have been working with a hypermedia (including hypertext) system for some time now. We agree entirely with your above notion. The paradigm that we have implemented is that links begin and end on a "block". A block can be thought of as a persistent selection. It is defined using a point-press-drag-release gesture, as well as the normal range of click/double-click stuff. In Intermedia, you first create a selection, then perform a "start-link" menu pick. Sometime later you perform a "complete-link". Once created, links are indicated by marker icons laid onto the document image. These markers may be selected and "followed" (a menu pick), or they may be double-clicked, implying a select-and-follow operation. Lets hope that unix land does, in fact, actually design and think about this stuff before jumping into an implementation. Maybe folks will even read some of the papers that have been published since 1967 (now THERES a novel thought). There are lots of subtleties that really jump out and grab you if you're not VERY careful. I hope the unix hackers explore some of this before making the rest of us suffer through their learning curve. Thanks, Tom Stambaugh. ps: I've seen a few postings on this subject that propose the insertion of stuff in the text to indicate links. This is a profoundly BAD idea, particularly in this context, because it forces every link to be shared by every user. Our research indicates that a much better design principle is to treat the collection of links (we call such a collection a "web") as an external data structure layered on top of a read-only document. For text such as this, blocks can be indicated by an offset and extent. Now, each user can layer his/her own links onto a passively read news article. The user doesn't need write access and the article isn't cluttered up with other people's links. If the author of a posting wants to also post a suggested web for folks to share, that can be posted and handled separately; as I user, I can take it if I want or skip it if I want. Given that the news tools like find and expire use the touch date to decide when to throw away a posting, you can imagine the havoc that would result from a linking scheme that requires each new link to cause a write to the original article! The result would probably be to preclude readers from creating their own links, thus blowing away the primary reason to support links in the first place. Charlie Evett, from IRIS, has published a paper describing the scheme we use at IRIS for tracking blocks in text documents. I think that was distributed at this weekend's hypertext conference in North Carolina. Charlie is responsible for a good bit of the graphics machinery of Intermedia, and in particular came up with an elegant solution to several implementation issues that result from doing this stuff with text. I highly recommend his paper. If you think this ps is of interest to the net, feel free to post it for me. Someday I'll get our net support working.
daveb@geac.UUCP (11/16/87)
As my signature suggests, I think a literature survey might be of
some **slight** use here. Can you comment on the work by IRIS?
--dave
--
David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb
Geac Computers International Inc., | Computer Science loses its
350 Steelcase Road,Markham, Ontario, | memory (if not its mind)
CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.