W3C home > Mailing lists > Public > www-annotation@w3.org > January to June 1999

Re: Yawas : new Web annotation system

From: Ka-Ping Yee <ping@lfw.org>
Date: Mon, 15 Mar 1999 00:28:54 -0800 (PST)
To: Laurent Denoue <Laurent.Denoue@univ-savoie.fr>
cc: www <www-annotation@w3.org>, Critters Project List <critters@crit.org>
Message-ID: <Pine.LNX.3.93.990312080854.396A-100000@localhost>
On Mon, 1 Mar 1999, Laurent Denoue wrote:
> I wrote a presentation of a Web Annotation System, which I've called Yawas
> (Yet Another Web Annotation System).
> You can find the draft at :
> http://www.univ-savoie.fr/~syscoweb/Laurent.Denoue/HomePage.htm
> or directly at http://www.univ-savoie.fr/~syscoweb/Laurent.Denoue/yawas.doc

Thanks for your reference to this draft.

> Yawas is written in Java (no native code) and should work with any browser.

Well, i'm not sure how consistent these two statements are.  The
fact that it requires Java creates portability issues and immediately
excludes many browsers, including Lynx, for example.

> I would really like to get feedback on the ideas presented in this draft.

How about posting the paper on the web in HTML so we can provide
feedback by annotating it using Crit?

In the meantime, I thought i would submit some ideas about it here
since you solicited comments.  I will be comparing the features and
claims made to the features of Crit (http://crit.org/) since it is
the only annotation system i really know best; i hope that others on
this list can provide information about other related work also.

Excerpted from the paper:
| There is no explicit distinction between private, group, and public
| annotations: the status of an annotation changes with the place where
| it is published by its author ... To retrieve annotations, standard
| search engines could be used.

This is a sensible approach.  Giving authors control over where and how
to publish their annotations provides more flexibility.  (I chose a
similar approach for the development of the Crit annotation service.)

| the sender could highlight specific parts of a document, could also
| add a comment, and send the resulting URL.  The recipient would load
| the URL and immediately see the highlighted parts with the associated
| comments.

It seems to me you are solving a somewhat different problem here than
what i suspect many of the people on this list are familiar with.  The
annotation, in your model, lives only in the copies sent among
individuals, and is entirely contained in the URL, if i understand
correctly.  In effect, this is not very different from simply downloading
and editing the page, and then forwarding the result to a friend,
except of course that it is more convenient.

This is not the same as creating globally-published annotations that
are visible to all viewers of the annotated page.  I'm more interested
in solving that problem, and that is what Crit accomplishes, because
it seems to me that we achieve a very interesting multiplying power of
knowledge that way -- a new kind of network effect made possible by
backward links, akin to the kind of augmentation that happened when the
Web gave us forward links.

Of course, it could be the case that your problem turns out to be the
more useful one to solve.  We don't really know yet until we try it
out.  Is the software available so we can all try it?

| people should not change their current e-mail, bookmark, and
| publishing tools.

Indeed.  I agree that these are good principles to encourage the
adoption of any new technology.  Crit likewise uses and extends
the capabilities of existing browser, e-mail, and Web publishing

| All the data can be encoded in an extended URL.  For instance:
| http://www.yahoo.com?note=selected%20text&date=1999-02-25&
| author=laurent&type=ok&comment=you...

This syntax you have chosen appears to collide with the current
syntax for submitting form fields in a GET request.  Have you
considered the potential conflict that occurs when attempting to
annotate pages that are the result of a query?

| Hence adding an annotation does not affect the user model of
| his/her browsing activity.  This architecture is browser
| independent (the only requirement is JavaScript)

The latter statement contradicts itself.

| Each column can be sorted so as to ease the process of retrieval.
| Filters can be applied to each column.

This is a very important ability, one that Crit currently does
not have.

| Several Web annotation systems have been proposed (see Davis
| "Annotation Systems").  Like Yawas, many of them use the
| concept of intermediary or interceptor, explained in [Zalman
| 99] and [Vasudevan 99].

These references are predated by my introduction of the concept
of "mediator" in 1995 (http://www.lfw.org/ping/mediator.html).

| To be accepted and usable we think a Web annotation system
| should consider different problems:
| - platform and browser independence
| - respect of privacy: creation of private annotations, and
|   possibility to share
| - visualization: annotations are embedded at their original
|   place in thedocument or not
| - storage: where are stored the annotations?
|   Dedicated annotation servers have a big impact on
|   scalability, cost, access rights and privacy
| - speed of retrieval
| - how can we use annotations: sharing and publishing
| To our knowledge, no existing annotation system addresses
| all these points.

I think this statement is a bit too strong.  Crit certainly
addresses these points and has been available as a public
service for nearly two years.  To wit, respectively (in the
order of the above six points):

- Crit is entirely platform and browser independent.  Where
  features of JavaScript can enhance the user interface, they
  are used for client browsers that support them; yet blind
  users can read and publish annotations using Crit with Lynx
  perfectly well.

- Crit allows you to publish your annotations anywhere you
  like.  Since annotations are just HTML documents like any
  others, they can be password-protected or kept private in
  conventional ways.

- Crit visualizes annotations directly in-line on the target
  document.  In addition to marking up the exact text of the
  target phrase, the markers are colour-coded to indicate the
  disposition of the comment, as determined by its link type.

  A marker link also contains the author and title of the
  annotation in its TITLE attribute, for display by browsers
  that understand it; its ONMOUSEOVER attribute, for browsers
  too stupid to understand TITLE but which support JavaScript;
  and its ALT attribute, for browsers which abuse the ALT
  attribute to make tool-tips instead of using TITLE like
  they should.

- Crit allows you to store your annotations anywhere you like.

- Crit does limit the speed at which you can retrieve documents
  because you are receiving them through a mediator; however,
  effort has been made to address the speed issue by supporting
  HTTP/1.1 persistent connections and short-circuiting the
  mediator for non-annotatable binary content.

- As for sharing and publishing annotations, again, with Crit
  annotation documents are first-class, and can be published in
  the same way as any ordinary Web document.  This yields the
  additional advantage that annotations can themselves be
  annotated, which is important for open discussion.  Also, the
  annotations immediately augment the value of the original
  document because anyone visiting them with Crit sees the added
  information; the author does not have to send the annotation
  around to each person who wants to see it.

So i'm a little surprised that Crit was not referenced anywhere in
your paper, even though you indeed brought to light many of the
issues which i agree are important to an annotation system and
which were carefully considered in Crit's design.

In defense of mediators i must also respond to the following
statements made in the paper.

| [Zalman 99] has noted several limitations of proxy-based
| intermediaries.  Here we list them and add others:
| - They have poor GUI support: most of them add buttons in the
|   document so that creation of new annotations are possible.
|   The GUI is then dependent of the HTML language.  We think it
|   also tends to disturb the user which may not want to see
|   added information on the page.

The above complaints are completely irrelevant to the type of 
proxy or mediator being used.  These are choices made in the
user interface, which certainly deserves discussion, but the
issues do not belong here.  

| - They are contacted at each request of the browser: they need
|   to be efficient and may use a cache

Indeed, mediators limit browsing speed and need to be efficient.
Many mediators, such as Shodouka (http://www.shodouka.com/),
MINSE (http://www.lfw.org/math/), and probably the Anonymizer
(http://www.anonymizer.com/), do use a cache to improve their

| - Users may not want to see annotations on each page which is
|   time consuming: turning off the annotation system means
|   reconfiguring the browser to avoid the use of the proxy

For a mediator, this is not so, as the choice to activate or
deactivate the mediator is just a matter of using a different
URL.  A single button can make it easy to activate or deactivate
a mediator on a given page, in the same manner as the Bookmarklet
you use to activate Yawas.

I think your system has a few significant advantages over Crit:
it probably performs better because it runs on the local machine,
it is capable of filtering annotations, and it permits annotation
on local files (which Crit does not).  Its design indeed makes it
a good candidate, as you have proposed, for integration as a
feature of the browser software.  However, i hope you will see
Crit's other unique advantages as interesting enough to be worth
referencing in your paper.

An overview of Crit is available at


Source code and other documentation is also available from

Received on Monday, 15 March 1999 04:06:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:54 UTC