Links without write access

The ideas here often go under the name “annotations”, but I have not used that term here. Here is a link describing earlier work that I was unaware of when I wrote the stuff below. (See this for earlier stuff.)

Let me try to describe the features that we want. There is some slippery terminology here that I will attempt to nail down at least for the scope of these notes.

Augment links are special visible text embedded in a document and recognized by the viewer software. The link holds navigation instructions that leads the viewer to another point in another document. This was before Internet and it was presumed that the local file system could access the new document. These navigation instructions are otherwise much richer than html links. Augment documents have structures via which to navigate. The navigation instructions can include searching forward for text given within the link.

Viewing an Augment or html document does not reveal that someone has produced a link to the text that you are viewing.

We would like to view text and be aware of commentary that selected others have made on this particular text.
We would like to create commentary about selected text within new documents so that this commentary is itself in the form of documents and text that can be commented upon.
We would like to guard the integrity of the documents that we are commenting on and this seems to preclude modifying those documents by adding to those documents anchors at which to point. ‘<a name=here> Noteworthy text </a>’ is the sort of html construct that we cannot use for it requires write access to the document upon which we are commenting. The author may have many reasons to deny such access.

I think that this idea subsumes the idea of symmetric bilateral links and may be merely changing terminology. I would be glad to scrap this terminology if older adequate terminology exists.

It might be suggested that the commentator edit a copy of the document upon which he comments and then publish the copy with relevant anchors. This does not provide notification of comments nor provide indications of comments by multiple commentators. It is also tempting for the commentator to change the text which would likely go undetected.

This is a description of a system to accomplish the above. It is a rationalization of the section labeled “Scheme” below. There is a relational data base with two main tables. I describe here the meanings of those tables and the transactions on the data base.

When someone wants to comment on some document, called the subject here, and register the comment, he first runs an applet from the xa server. He provides to the applet, the URL of the subject and enough text from the subject to identify the text that he wants to comment on. The applet returns an html anchor that might look like:
<a href=http://xxa.com?3S34ff#3S34ff name=03S34ff> The value “3S34ff” is called the link ID. At this point the data base has no idea where, if anywhere, this link has been installed. The table entry will last for days at least.

What has happened is that the xa server has fetched the subject, found the text, computed a secure hash of the subject, and built a table entry consisting of

URL of subject,
Secure hash of subject,
Link ID (“3S34ff”, as in the anchor),
Offset of the text,
Length of the text,
Date of entry creation.

The link ID is new unless the server finds an extant table entry describing the same text. This table is indexed by link ID and URL of subject.

Alternatively the commentator could view the subject thru the xa server (see below) where he might find appropriate pointers that others have already established.

If a standard browser follows the link at this point then the xa server will be notified with a message containing the link ID. The data base is used to locate the original subject in which the interesting text is decorated such as: <a name=3S34ff> <font color=#ff0000> Interesting text </font></a> which yields “Interesting text” in its context.

This is cute but not the real purpose. The commentator may register his comments by submitting its URL to the xa server. He identifies himself, perhaps with a password. The server then passes over the commentary looking for special links that it might have handed out. It records such instances in a second table in the data base. The table entry would then hold:

3S34ff
Id of commentator
URL of commentary

We have seen two interactions a commentator can establish a new link to a subject document and a browser can follow such a link. The stage is set now for a browser to look at subject text and find, with help from xa, commentary by selected commentators. To do this the browser first starts an applet from the server thru which he can say which commentators he is interested in. Then the browser can specify an initial URL. The server delivers that URL with html decoration that indicates which portions have elicited commentary by the preferred commentators. There are design questions concerning these indications. If commentary on the subject is low density and non overlapping then simple to-and-from anchors are attractive. Otherwise fancier presentation ideas are needed.

There are advantages to this scheme beyond the desiderata given above. The xa function can be either centralized or distributed. Any machine running a browser can host an xa server. This cuts down on the cost of traffic between the server and browser. Casual users can use a centralized xa and not pay to install an xa server.

A further advantage is that, not being integrated with a browser, this functionality can be upgraded to new browser and server technologies with little or no effort. The rapid pace of html and browser evolution makes this attractive.

Scheme (obsoleted by stuff above)

Here is an obtuse scheme to do this. I don’t claim that it is feasible as it stands, but it is getting better.

Suppose that we use standard browsers, standard html and standard httpd servers, but that we have a special proxy, xa, that is html savvy. This proxy might have caching function. A caching proxy already intervenes in some of the right places. It is also OK if the proxy role is already filled for our new proxy can itself refer to the “real” proxy.

The commentator uses a standard browser to view the subject document that he wants to comment on. The subject is on a standard server machine. When the commentator wants to comment on the object he starts an applet in another window by invoking an URL to xa. He informs the applet of the subject (if necessary). Sometimes the commentator will be viewing the subject via xa as proxy and xa will probably be able to take advantage of this but I think there is no conceptual difference.

To indicate a target in the subject the commentator moves text with copy & paste from the subject window to the applet window. The text arrives to xa which finds the text and warns if the text is not unique. Xa returns to the applet window a legal html pointer to be included in the commentary.

There is magic in that link. It points to xa and delivers to xa information to locate the subject document and locate the interesting text within the subject. This might be because xa remembers the tagging or because the memory is in the link. (long link—many characters) In either case xa serves up the document and dynamically modifies it to include an anchor so that the reader’s browser can find the anchor. xa may also decorate the text so that the reader knows what text is referred to.

There are several alternatives for the nature of this “xa pointer”.

The xa pointer looks like:
<a href=http://xxa.com?www.foreign.edu/dir/xyz.html+13652+29#31>
This causes a browser that follows this link to contact the server xxa.com sending the string “www.foreign.edu/dir/xyz.html+13652+29” to the xa server xxa.com.
The xa pointer comprises an URL and a character offset. Xa can subsequently interpret this URL in its proxy role.
The xa pointer is merely a string of characters (in sgml format) that refer to an item in ax’s data base which, in turn, identifies the document together with information that xa can use to locate the same point in the document.

The first alternative allows a YML savvy browser to follow xa pointers while the second requires xa to follow those links. The second alternative hides the mechanism so as to allow transparent improvement of the mechanism.

Xa is in a position to be aware of version of the documents that it indexes. It might warn that a document has been changed since a comment about it was made. With the second alternative xa is in a position to follow pointers even to updated documents.

The reader advises xa which which commentators the reader is interested in. Commentary is merely a newer document with xa pointers to the subject document being displayed. A relational data base connects the two documents. The references are to portions of text in the older document.

A scheme such as this allows commentary on html documents stored on other computers where we cannot write them. I think that the commentary can be elsewhere as well.

I think that the only impediments to scaling are the data base. I think that data base practice solves this.

I think that this scheme can be made more rational and easier to explain.