Talking Back to the WWW

annotation logo

Presented at: TERENA-NORDUnet Networking Conference 1999
Full name of authors:
Jacob Palme, professor
Organizational affiliation: Stockholm University and KTH
Address: Skeppargatan 73, SE-11530 Stockholm, Sweden
Phone: +46-8-664 77 48
URL in HTML format:
URL in PDF format:

Abstract: While e-mail and netnews support interaction between users, typical WWW communication is uni-directional -- from the web page creator to the reader, but with no facility for talkback from the reader to the creator or between readers. This paper discusses how talkback can be added to the WWW and presents how this is implemented in the KOM 2000 system.

Status of development.



Two or more people can exchange information in both directions. Note that this is people-to-people interaction, not human-computer-interaction.


Web page readers can reply to web pages, and discuss the web pages with other readers of the same web page. Note: The word "annotation" is often used for what in this paper is named "talkback".

Interaction in WWW, E-mail and Netnews

The three largest applications on the Internet are:

Application WWW E-mail Netnews
Main usage
  1. Publication of information
  2. General purpose application interface
  1. Interpersonal messaging
  2. Group communication through mailing lists
  1. Group communication through newsgroups
  2. Distribution of new documents
Talkback (Interactivity between people) Low except through special applications High High
Primary document format Mainly HTML Mainly plain text, HTML is coming Mainly plain text, HTML in some newsgroups
Ease of finding newly arriving documents (news control) Rudimentary through color changes of links Good Good
Major hyperlink structure Much Threads (conversations, links from messages to mailing lists Threads (conversations, links from articles to newsgroups
Public search and retrieval Good Sometimes (through mailing list archives) Somewhat
Data base Distributed through hyperlinks between web pages, one primary location for each web page, sometimes replication through caching for efficiency reasons Distributed, mainly stored in mailboxes for senders and recipients, sometimes also in mailing list archives, usually at one or a few places for each list Distributed through massive replication: Documents replicated to each server where users are allowed to retrieve them
Removal of old items Manual by creator Manually and separately for each user Automatic purging, certain manual removal also done by senders and cancelbots

The main difference between WWW on one side, and e-mail/netnews, on the other hand, is that WWW is mainly used for unidirectional publication of information, while e-mail and netnews are mainly used for interactions between users. E-mail and netnews has the following two primary functions which are not generally available on the WWW:


Send a message which comments on a previous message, written by someone else, often to all recipients of the previous message.


Many people can submit to the same group of recipients (mailing lists, newsgroups).

Attempts at Providing Talkback in the WWW

There have been many attempts at providing talkback in the WWW. Here are some methods:

WWW Interface to Talkback Applications

Since the HTTP/HTML protocols, combined with forms, can be used as a fairly general-purpose application interface, they can of course also be used to provide interface to applications which provide interactivity between people. Examples of this is forums (web-based, non-same-time conferencing systems), chat (same-time text interaction), web-based e-mail, like for example Hotmail and MUD (multi-user adventure games).

The talkback facility in these systems is limited to users of these special services. Usually, talkback is only possible between those users who connect to one single server. Talkback is thus not very well integrated in the normal WWW structure of a vast distributed data base of documents with hyperlinks not only within servers, but also between servers.

Talkback in Web Pages

A few experiments have been made in providing talkback directly in web pages. The most common method is to append, at the end of an ordinary web page, a talkback button, and lists or links to responses. A reader of such web pages can thus send in their responses, and have these responses added to the web page. Example:

An (almost) ordinary web page:

I think the moon is made of green cheese

For the following reasons, I think that the moon is made of green cheese ... ...

Response area at the bottom of the web page, with responses written by other people:


Mary Smith: No, I think it is made of blue cheese ... ...
John Clark: No, I think it is a blueberry pie ... ...
Area where a reader of the web page can enter additional responses:

Enter your own response:

Your name: Submit button

Another variant only puts a single Discussion button button at the bottom of a web page, which links to a place where this web page is discussed. This variant does not intrude on the primary contents of the web page as much as where the discussion is put inside the web page itself.

Implementation methods

Talkback facilities can be provided through two different methods:

Method Pros Cons
Local talkback service: Talkback facility provided together with the web page itself. Either the author of the web page has added a talkback facility to his web page, or a web server adds talkback facilities to all or many of its web pages. All or many readers of the page can see and access the talkback facility. Talkback is only provided in web pages where the creator has included a talkback facility.
Universal talkback services: A general-purpose talkback facility is provided for every web page in the entire WWW by some talkback service. Talkback possible on every web page in the entire world wide web. Talkback is only available for users who have enhanced their web browsers with a talkback facility, and if there are more than one talkback service, interaction is not possible between people using different talkback services. Users are thus split into different islands, with talkback only between users on a single island.

As is shown by the table above, there are serious problems with both methods. An ideal talkback facility should combine the following services:

Web page owners can insert talkback into their pages, this talkback is then available to everyone who reads this web page. This is similar to what is named Local talkback service in the table above.

Users interested in talkback can subscribe to a talkback service, and they will then be able to enter forums on any web page. This is similar to what is named Universal talkback services in the table above. But the talk back servers are interconnected, so that all readers of each web page share one single forum area for that web page.

These two services are combined, so that the forum area provided with a Local talkback service is the same as that provided by the Universal talkback services.

Sometimes, it might be suitable to have a joint forum area for a set of related web pages, instead of a separate forum area for each page.

Sometimes, an organization might want to have a Universal talkback service, but only available for members or employees of this organization.

A universal service is not easy to implement. Since a fundamental principle of the Internet is that nothing should rely on one single universal server, a distributed, standardized protocol is needed. This protocol should provide the following services:

Access for local talkback services, so that a web page owner can add talkback to his/her web pages.

Global access which can locate the talkback areas for one particular web page (or a set of related web pages). This requires some kind of directory data base, which given a web page URI, can locate the talkback area for that particular page.

The talkback areas might be stored in conjunction with the web page(s) they are connected with. But it is natural, in the WWW, to have the talkback areas distributed, so that every author of a talkback message can provide his talkback message as a web page on a local web server. A central area for each web page might then only store links to all talkback for this particular page. It might also store cached copies of the talkback pages.

Our implementation


In an earlier research project, Web4Groups, we implemented a simple service of this kind, but this system was experimental and never achieved production quality.

KOM 2000

We are working on a new implementation in the KOM 2000 system. KOM 2000 is a distributed service of interconnected KOM 2000-servers. Each KOM 2000 server stores the items submitted by its local users. Each server can also hold multiple forums, both those connected to ordinary web pages and those not connected to a particular web page. The forums can be of different kinds, such as open to everyone, closed for members only, open to members of another group; moderated or allowing every member to write in the area. A beta version of KOM 2000 is already available on the web.

Data base items

Items in the data base are of primarily three kinds:


Documents (pages, messages).

Forums (discussion areas).

Each item (user, document, forum) has

A URL associated with a file, just as for ordinary web pages. This is, like all URLs, a globally unique identification of this item.

A title, which is a user-friendly name, not limited by the limitations of the URL syntax. This name is not guaranteed to be globally unique.

With each user is associated a private area, an inbox and an outbox, and lists of forums to which this user is associated as member or as organizer.

With each forum is associated

a list of contributions in HTML format.

a list of members. Different members can have different roles, such as ordinary member and organizer of this forum.

a list of subactivities.

Example of data base structure within one server:

Distributed, WWW-like Data Base

The data base is distributed: Users submit their contributions to their localKOM 2000 server, but forums can be available to users at multiple servers. Each forum is located in one server. Every user has a home server, and accesses all information through his/her home server. This means that the actual URL seen by the user when accessing an object at the server from a user at the home server can be, where is the home server of this user, and is the identification of the object. The local server of this user will retrieve the object from its home server.

This, unfortunately, means that the URL to access the same forum differs for different members. However, IETF has standardized a facility called Uniform Resourch Names (URN). When web browser support URNs, look up of a web page is a two step process. First the URN is used in a URN server. This server will return a URL, where the actual document is placed. The intention with this service is that the URN need not change when a document is moved, and that the URN server can provide links to the nearest copy for each user, for documents which are mirrored on different sites. But URNs can probably be used to overcome the problem above. The URN server can be designed to give each user access to an object through his preferred groupware, which is exactly what we need. Another possible solution might be a plug-in to web browsers.

To reduce access times, a copy of every object is stored at every server, where there is a recipient to this object. These copies can be removed to save space. If a user needs a document which has been removed, it can be fetched from the master server for this document. One can compare with Usenet News, which also copies articles to all servers. But our design has two advantages, compared to Usenet News:

Copies are not sent to servers where there is no reader of them. Replication is set up automatically when a reader starts subscribing to a forum. Usenet News cannot do this, because it has no list of the subscribers of the newsgroups.

If an object has been purged to save space, it can be fetched from a master server. In Usenet News, there is no automatic way of getting a copy of a purged article.

A master copy is stored at the server of the creator of the object, a shadow copy at the server of the forum and the server of every member of the forum. Thus, for example, an object may have three locations:

I like them too
Master version stored at the server of the creator of the object.
I like them too
Shadow copy stored at the server of the forum to which this object was submitted.
I like them too
Shadow copy stored at the server of a member of this forum.

Groupware Protocol

The protocol between groupware servers contains operations like:

The protocol uses the ticket method for access control. This means that anyone who has a certain access right is given a ticket, which is a randomly generated key. For example, members of a forum have the ticket for that forum, and when they retrieve a list of the contributions to the forum, they get the tickets for each contribution, which they then can use to download the contribution.

The advantage with this method is that no central certificate server is needed. And setting up certificate servers has been a major stumbling block in getting security systems working. We may however add use of encryption methods for authentication, signatures and seals to increase the security.

Directory System for the Talkback Service

When this is written, we have not yet developed the directory system. We have agreed with a major search engine provider, that they will set up the directory. They will set up a directory, which given a web page, can find a discussion forum for that web page. The directory will not be limited to KOM 2000, it will be able to store discussions using other groupwares than KOM 2000 too.

There will be a protocol for the groupware servers to communicate with the directory system. Main operations in this protocol will be:

The format for these operations will be the same format which is used when a user fills in and submits a form on a web page. This means that also other groupware servers than KOM 2000 can report forums. Their owners can do this manually, by filling in a form on a web page, even if they have not implemented the protocol in their software.

The directory should of course also be distributed, based on an existing directory structure like LDAP or DNS, but our first implementation will employ a centralised directory only.

More information

More information about KOM 2000 is available at Info about status of the talback service, see


Alton-Scheidl, Roland and Schmutzer, Rupert 1997: Voting, Rating, Annotation, Shriftenreihe der Österrischen Computer Gesellschaft, R. Oldenburg Wien München 1997, ISBN 3-7029-0437-9.
Berners-Lee, Tim 1996: Multi-user considerations, Issues/Multiuser.html
Bieber, Michael et al 1997A: Annotations and public or private links,, part of Bieber 1997B.
Bieber, Michael et al 1997B: Fourth generation hypermedia: some missing links for the World Wide Web, Int. J. Human­Computer Studies (1997) 47, 31­65,
December, John 1995, 1998: Internet tools summary,
Jeon, Jonathan 1998: Collaboration Systems Discussion Board,
LaLiberte, Daniel and Braverman, Alan 1995: A Protocol for Scalable Group and Public Annotations,
MacArthur, Karen, 1995, 1998: Collaboration, Knowledge Representation and Automatability,
Oakes, Chris: Web Talk Getting Crowded. Wired News.
Palme, Jacob 1994: Superbrain,
Palme, Jacob 1996: Linking conferences to web pages,
Palme, Jacob 1998: KOM 2000 Non-Simultaneous Web-based Groupware,
Palme, Jacob 2000: How to Design a Successful Talkback Service.
Third Voice 1999: Agree to disagree. Add your voice to the web. Third Voice Inc.
Thomas, Jason Bryce 1997: iShare ~ Document Annotation and Version Control for the Internet,
Tscherteu, Gernot and Benzer, Sabine 1997: First European Conference on Voting, Rating, Annotation,

Woolley, David R., 1995, 1998:

Conferencing Software for the Web,