- 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>
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 software. | 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 performance. | - 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 http://crit.org/~ping/ht98.html Source code and other documentation is also available from http://crit.org/. !ping
Received on Monday, 15 March 1999 04:06:11 UTC