Niels Olof Bouvin

University of AarhusNovember 2000

Ph.D. Thesis

Augmenting the Web through

Open Hypermedia

The Development of the Arakne Environment,

a Collaborative Open Hypermedia System for Web Augmentation

2

Contents

1 Foreword 71.1 Structure of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 The Arakne Environment . . . . . . . . . . . . . . . . . . . . . . . . 91.4 My Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Danish Summary 11

3 Introduction and Motivation 133.1 Working on the Web . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Lies Open Hypermedia Dead in the Wake of the Web? . . . . . . . . 143.3 The Vision of the Augmented Web . . . . . . . . . . . . . . . . . . . 153.4 Open Hypermedia Web Augmentation Tool: A Definition . . . . . . . 16

4 Hypermedia and the Web 174.1 A Brief History of Hypermedia . . . . . . . . . . . . . . . . . . . . . 174.2 The Classical Monolithic Hypermedia Systems . . . . . . . . . . . . 174.3 Open Hypermedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3.1 Sun’s Link Service . . . . . . . . . . . . . . . . . . . . . . . 204.3.2 Microcosm . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.3 Devise Hypermedia . . . . . . . . . . . . . . . . . . . . . . . 224.3.4 HyperDisco . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.5 HOSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.6 Chimera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.7 Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.8 Integrating Third-party Applications . . . . . . . . . . . . . . 264.3.9 Open Hypermedia on the Web . . . . . . . . . . . . . . . . . 27

4.4 Hypermedia Standardisation Efforts . . . . . . . . . . . . . . . . . . 294.4.1 The Dexter Hypertext Reference Model . . . . . . . . . . . . 304.4.2 Open Hypermedia Systems Working Group . . . . . . . . . . 31

4.5 CSCW and Collaborative Hypermedia . . . . . . . . . . . . . . . . . 324.6 Hypermedia: Concluding Remarks . . . . . . . . . . . . . . . . . . . 354.7 A Brief History of the Web . . . . . . . . . . . . . . . . . . . . . . . 35

4.7.1 Hyper-G . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7.2 The Semantic Web? . . . . . . . . . . . . . . . . . . . . . . 374.7.3 Collaboration on the Web . . . . . . . . . . . . . . . . . . . 384.7.4 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3

4 CONTENTS

4.8 WWW, or What is Wrong with the Web? . . . . . . . . . . . . . . . . 394.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Related Work 435.1 XLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Internet Explorer Add-ons . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.1 Flyswat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.2 iMarkup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.3 Third Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Contributions 476.1 [P1]: Unifying Strategies for Web Augmentation . . . . . . . . . . . 476.2 [P2]: Opening Temporal Media for Web Augmentation . . . . . . . . 486.3 [P3]: The Arakne Environment and the future of OHSWG . . . . . . 496.4 [P4]: The Collaborative Arakne Environment . . . . . . . . . . . . . 526.5 [P5]: The iScent Framework . . . . . . . . . . . . . . . . . . . . . . 526.6 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.6.1 DHM/WWW . . . . . . . . . . . . . . . . . . . . . . . . . . 556.6.2 Navette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.6.3 The Arakne Environment . . . . . . . . . . . . . . . . . . . . 56

6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Challenges for Web Augmentation 617.1 Working with Web Browsers . . . . . . . . . . . . . . . . . . . . . . 61

7.1.1 The Ideal Web Browser . . . . . . . . . . . . . . . . . . . . . 637.2 Experiences with Java . . . . . . . . . . . . . . . . . . . . . . . . . . 647.3 Hypermedia Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.3.1 Scalability through Interchange Files . . . . . . . . . . . . . 667.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8 Conclusion 698.1 Primary Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.2 Web Augmentation in the Future? . . . . . . . . . . . . . . . . . . . 70

8.2.1 Commercial future of Web augmentation . . . . . . . . . . . 718.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

8.3.1 Collaboration in the Arakne Environment . . . . . . . . . . . 728.3.2 Open Sourcing the Arakne Environment . . . . . . . . . . . . 72

A Use Studies 75A.1 Landbrugets Rådgivningscenter . . . . . . . . . . . . . . . . . . . . 75

A.1.1 The Information Series . . . . . . . . . . . . . . . . . . . . . 77A.1.2 Assembling a publication . . . . . . . . . . . . . . . . . . . . 77A.1.3 Handling law material . . . . . . . . . . . . . . . . . . . . . 77A.1.4 Moving from paper to the Web . . . . . . . . . . . . . . . . . 78A.1.5 Work with Landbrugets Rådgivningscenter . . . . . . . . . . 78A.1.6 Experiments at Landbrugets Rådgivningscenter . . . . . . . . 80

A.2 Guided Tours at Opasia . . . . . . . . . . . . . . . . . . . . . . . . . 80

CONTENTS 5

B Installing the Arakne Environment 83B.1 Systems Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 83B.2 Installing JIntegra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83B.3 Installing the Arakne Environment . . . . . . . . . . . . . . . . . . . 83B.4 Starting the Construct Servers . . . . . . . . . . . . . . . . . . . . . 84B.5 Starting the Arakne Environment . . . . . . . . . . . . . . . . . . . . 84

C Vocabulary 85

Bibliography 87

List of Figures

4.1 The Construct Process Architecture (from [52]) . . . . . . . . . . . . . . . . 264.2 The General Dexter Architecture (from [62]) . . . . . . . . . . . . . . . . . 304.3 The OHSWG Navigational Data Model . . . . . . . . . . . . . . . . . . . . 324.4 The Uniform Resource Locator . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 The General Web Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1 The iMarkup Application (fromhttp://www.imarkup.com/ ) . . . . . 45

6.1 The Arakne Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Mimicry playing the endpoint ’Endpoint 14’ . . . . . . . . . . . . . . . . . . 496.3 The Arakne Environment with Mimicry . . . . . . . . . . . . . . . . . . . . 506.4 The iScent Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.5 The DHM/WWW Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 556.6 The Navette Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.7 Early Arakne Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.8 The Arakne Environment: Two sessions, two views, and a Session Manager.

The ticker tape is visible at the bottom. The tabbed panes just above the tickertape is used to switch between joined sessions. . . . . . . . . . . . . . . . . . 59

A.1 The Organisation of Danish Agricultural Advisory Services . . . . . . . . . . 75A.2 Guided Tour at Opasia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

List of Tables

4.1 Components and entities in the Dexter model . . . . . . . . . . . . . . . . . 31

6

Chapter 1

Foreword

1.1 Structure of this Thesis

This report forms the first part of of my Ph.D. thesis titled “Augmenting the Webthrough Open Hypermedia”. This part summarises my work and relate it to the hyper-media and Web research fields. The second part is formed by the five papers describedbelow in Section 1.2, all dealing with augmenting the Web with open hypermedia orcollaboration. The third and final part of my Ph.D. is the Arakne Environment, a sys-tem for creating open hypermedia structures on top of Web pages, which availability isdescribed in Appendix B. It is also available on the CD delivered with this text.

Foreword This chapter

Danish Summary A summary of the thesis in Danish.

Introduction and Motivation The Web is briefly introduced, along with some sce-narios, highlighting some shortcomings of the Web. These scenarios are used tointroduce the term ’Web augmentation’, that is using open hypermedia technol-ogy to structure the Web.

Hypermedia and the Web My work is related to both open hypermedia research andthe Web community. This chapter gives an overview of both fields as well as abrief introduction to the relevant CSCW topics, with special focus on the areasdirectly related to my work.

Related work There are a growing number of commercial products aimed at Webaugmentation. This chapter introduces some of these systems along with a de-scription of XLink, a W3C XML standard for navigational hypermedia.

Contributions My contributions to the field based on the papers described in Sec-tion 1.2. I have mainly worked directly on Web augmentation and this is re-flected in the papers. My experiences with the Open Hypermedia Systems Work-ing Group compliant Construct servers are reported, as is work on extending andgeneralising the approach to shared awareness found in the Arakne Environment.

Challenges for Web Augmentation While Web augmentation is greatly eased by theaccessibility of Web standards, there are some lessons with Web browsers andJava accumulated through my work, that identifies some of the obstacles remain-ing.

7

8 CHAPTER 1. FOREWORD

Conclusion This chapter summaries the results, I have achieved, and sets the direc-tions of my future work. The Arakne Environment and its related technologieshave now reached a point where work can begin in earnest.

Use studiesTwo cases, one detailing the need for Web augmentation at LandbrugetsRådgivningscenter, another showing Web augmentation in the form of guidedtours used in practice at the Opasia Web portal (the largest Danish ISP).

Installing the Arakne Environment A short description detailing how to downloadand install the Arakne Environment.

Vocabulary Short definitions of various terms used throughout this text.

1.2 Papers

The core part of this thesis consists of the following papers, included with the thesis:

• N. O. Bouvin. Unifying strategies for Web augmentation. InProceedings ofthe10th ACM Hypertext Conference, pages 91–100, Darmstadt, Germany, Feb.1999. This paper introduces the term “Web augmentation”. Based on a studyof a number of Web augmentation tools, a general framework to model Webaugmentation, as well as an implementation using this framework is presented.Referred to in this text as [17] and then marked with [P1].

• N. O. Bouvin and R. Schade. Integrating temporal media and open hypermediaon the World Wide Web. InComputer Networks — The International Journal ofComputer and Telecommunications Networking, (31):1453–1465, 1999. Tradi-tionally, Web augmentation has concentrated on adding links to Web pages, thatis, HTML documents. This paper describes how temporal media, such as videoor audio clips, may be augmented with links on the Web. Referred to in this textas [20] and then marked with [P2].

• N. O. Bouvin. Experiences with OHP and issues for the future. inLecture Notesin Computer Science1903. Springer, 2000. Based on the work of porting theArakne Environment to the Open Hypermedia Protocol, this paper reflects onthe state of the standards developed by the Open Hypermedia Systems WorkingGroup, and discusses how this work can continue in the future. Referred to inthis text as [19] and then marked with [P3].

• N. O. Bouvin. Collaborative Web-based open hypermedia and mutual awareness.To be submitted for publication. This paper describes how collaborative workand shared awareness is supported in the Arakne Environment, with special focuson how collaboration can be seamlessly integrated into the interaction with thesystem. Referred to in this text as [15] and then marked with [P4].

• K. M. Anderson and N. O. Bouvin. Enabling project awareness and intersub-jectivity via hypermedia-enabled event trails. Submitted for publication. Thispaper introduces the iScent architecture, a system to support shared awarenessand intersubjectivity between co-workers. As such it is a continuation and gen-eralisation of the awareness tools already present in the Arakne Environment.Referred to in this text as [6] and then marked with [P5].

1.3. THE ARAKNE ENVIRONMENT 9

1.3 The Arakne Environment

The Arakne Environment is a tangible result of my Ph.D. It is a collaborative openhttp://www.bouvin.net/Arakne/hypermedia system aimed at Web augmentation. The basis of the system is an environ-

ment wherein an open set of hypermedia tools, known as “views”, exists and currentlyprovide the user with navigational, spatial, and guided tour structuring mechanisms forWeb pages. Details on how to obtain and install the system is found in Appendix B.

It had not reached its current state without the help of the following Coconut studentprogrammers, to whom I am grateful: René Thomsen, Michael Bang Nielsen, andHenning Jehøj Madsen.

1.4 My Background

It was 1993, and I was a summer student at the Department for Electronics and Comput-ing for Physics in Geneva CERN, when Tim Berners-Lee introduced me to the Web...http://www.cern.ch/

In thosedays, you could still find Web pages (at CERN and at NCSA) that listed thehttp://www.ncsa.edu/

whole of the Web... Since then things have changed considerably. In spring 1994 Idecided to attend a new class on Hypermedia, because I thought it sounded interesting(it was). Four concepts particularly caught my attention at that time — Bush’s trailblazer, Engelbart’s ambition to augment the human intellect, Nelson’s Docuverse, andthe elegance of NoteCards.

I received my Master’s Degree in late July 1996 (mastering in computer sciencewith a minor in mathematics) at the Department of Computer Science, University ofAarhus, Denmark. Together with Christina Nielsen and Christian Mulvad Sejersen Ihad been involved in an activity theoretical HCI evaluation of a research prototypecreated by EuroPARC Cambridge for the Esprit EuroCODE project, which we doc-umented in our Master’s thesis “Spirits in a Material World”, with Susanne Bødkeras our supervisor. Our contribution to the EuroCODE project was published in theEuroCODE Deliverable 1.4.2.

After graduation I accepted an offer to work at the Department of Computer Sci-ence, where I developed the DHM/WWW applet, the first application to offer client-side open hypermedia links in Web pages by integrating an ordinary Web browser. Theresults were published in [48], co-authored by Kaj Grønbæk, Lennert Sloth, and my-self. This paper later won the Engelbart Award for best paper at Hypertext 1997 inSouthampton, England.

This wetted my appetite for what I later would term “Web augmentation”, and inSeptember 1997 I was accepted as a Ph.D. student at Aarhus with Kaj Grønbæk asmy supervisor, with the topic of open hypermedia on the Web. I became a memberof the Coconut project, a project collaboration between the Department of ComputerScience and Tele-Danmark Internet (the largest Danish ISP). The aim of the Coconuthttp://www.opasia.dk/

project was twofold: to make new hypermedia research, and explore the possibilitiesfor collaborative component-based Web technology. The project ended by the end of1999, while my Ph.D. studies continued to the end of August 2000.

It has been exciting to work within Coconut — pure research coupled with theneeds of a corporate entity — and I wish to thank all the participants: Kaj Grøn-bæk, Ole Hedegård, Jesper Jühne (original co-developer of Ariadne), Henning JehøjMadsen, Michael Bang Nielsen, Peter J. Nürnberg, Lars Pind, Olav Reinert (originalco-developer of CAOS), René Schade (original developer of Mimicry), Jörg Schneider,Kristine Thomsen, René Thomsen, and Uffe Kock Wiil

10 CHAPTER 1. FOREWORD

I spent the first five months of 2000 at the University of Colorado, Boulder, visitingKenneth M. Anderson. The stay was very enjoyable and fruitful with good discus-sions and work on hypermedia and with the development of the iScent framework(Section 6.5) as the main result.

1.5 Acknowledgements

A very special thank you to the people, without whose comments and suggestions, thistext would look quite different: Kaj Grønbæk, Christina Nielsen, and Marianne GravesPetersen.

Chapter 2

Danish Summary

Jeg har i min Ph.D. beskæftiget mig med, hvorledes man udbygger funktionaliteten afWorld Wide Web ved hjælp af åben hypermedieteknologi. WWW er en stor success,men visse ting er fortsat vanskelige. Man kan således ikke lave links fra andre folkssider, da linking indebærer modifikation af den Web side, som man linker fra. Delinks, mankanskabe fra egne sider er simple unidirektionale links med ét endepunkt.Som struktureringsmekanisme er et så simpelt link begreb relativt begrænset. En andenbegrænsning af WWW er den ringe understøttelse for samarbejde.

Problemet med struktur på WWW vil ikke blive mindre med tiden, idet WWWfortsat vokser med stor hast. F.eks. gør en lang række danske statslige institutioneri stigende grad deres materiale tilgængeligt over WWW. Hertil kommer de dagligehttp://www.danmark.dk/

referencer til Web sider for uddybende information i medierne.Hypermedieforskningen har i løbet af de sidste 55 år produceret en mængde spæn-

dende systemer med struktureringsmekanismer af meget forskellig art. Fra traditioneltnavigationelt hypermedie (dvs. links og ankre), som også anvendes på WWW, til guid-ede ture, spatialt eller taksonomisk hypermedie. Hertil kommer, at hypermedie syste-mer allerede tidligt fokuserede på samarbejdsstøtte til specielt forfattervirksomhed afden ene eller anden art.

De klassiske hypermedie systemer var lukkede eller monolitiske. Dette vil sige,at de kun i ringe grad eller slet ikke var i stand til at håndtere dokumenter lavet medandre værktøjer. Såfremt man ønskede at benytte hypermedie, måtte man således for-lade sine eksisterende programmer, og forlade sig på de i hypermedie systemet tilgæn-gelige. Dette medførte en begrænset udbredelse af hypermedie teknologien. I 1989publicerede Meyrowitz sin artikel “The Missing Link: Why We All doing HypertextWrong” [78], hvor han identificerede den manglende støtte for almindeligt forekom-mende værktøjer (såsom tekstbehandlingsprogrammer eller regneark) som hypermedieforskningens største problem. Denne artikel afstedkom en fokusering på at integrerehypermediefunktionalitet ind i almindelige programmer. Dette område betegnes sæd-vanligvis som åbent hypermedie forskning. Området er i år 2000 elleve år gammelt(regnet efter den første publikation, der omhandlede et åbent hypermediesystem, Sun’sLink Service [86]), og i den periode er der blevet udviklet mange forskellige åbnehypermediesystemer, der har demonstreret, at det er muligt at tilbyde hypermediefunk-tionalitet i programmer, der ikke er specielt udviklede til formålet.

Et andet område, der også i år er elleve år gammelt er World Wide Web. Det blevoprindeligt skabt af Tim Berners-Lee på kerneforskningsinstituttet CERN i Geneva iSchweiz. WWW er reelt et monolitisk hypermediesystem, der primært fungerer ved

11

12 CHAPTER 2. DANISH SUMMARY

hjælp af dokument formatet HTML. Ironisk nok er WWW det eneste kendte eksempelpå et monolitisk hypermediesystem, der har formået at få endog stor udbredelse, ogsom oven i købet har evnet at få andre systemer til at tilpasse sig. Den store succes, somWWW har nydt, må hovedsageligt tilskrives den simple bagvedliggende arkitektur.Denne arkitektur har imidlertid også, som nævnt i indledningen, nogle begrænsninger.

Mit arbejde har taget udgangspunkt i den åbne hypermedieforskning med det for-mål at udvide hypermedie funktionaliteten af WWW. Dette mål kalder jeg “Web aug-mentation”, hvilket løseligt kan oversættes til “Web forbedring”. I forbindelse med mitarbejde har jeg dels udviklet en række prototyper, der demonstrerer åbnet hypermediekombineret med WWW, dels arbejdet med den generelle arkitektur for sådanne værk-tøjer, og endeligt beskæftiget mig med, hvorledes samarbejde kan understøttes bedrepå nettet.

Det foreløbige højdepunkt af mit arbejde er “the Arakne Environment” (kort Arakne).Arakne er en hypermedieomgivelse, der i øjeblikket understøtter navigationelt, guidettur og spatialt hypermedie på WWW. Ved hjælp af denne omgivelse kan en brugerskabe noter og tovejs mange til mange links på kryds og tværs af WWW, desuagtetom vedkommende har skriveadgang til de pågældende sider eller ej. Systemet gem-mer de skabte hypermediestrukturer i en hypermedie server, og først når en Web sidehentes af brugeren, indsættes de relevante links og noter, således at de fremstår på skær-men. Såfremt flere brugere er tilknyttet de samme hypermedieservere, kan de igennemArakne samarbejde omkring skabelsen af hypermediestrukturer. Hvis en bruger måtteønske det, er det også muligt at eksportere hypermediestrukturer til en XML fil, sombrugeren så kan sende til andre via elektronisk post, eller placere på sin Web side.Arakne er et Windows program og anvender Microsoft Internet Explorer som sin Webbrowser.

I forbindelse med udviklingen af Arakne og de systemer, der gik forud, har jegnaturligvis haft lejlighed til at høste en del erfaringer med kombinationen af åbne hy-permedie systemer og WWW. Disse erfaringer (såsom problemerne omkring at skulletilpasse en Web browser til denne anvendelse) er beskrevet i dette dokument.

Foruden selve udviklingen af diverse systemer, består min Ph.D. også af fem artik-ler, som er vedlagt dette dokument. Disse artikler beskriver udviklingsprocessen, derførte til Arakne, herunder det generelle Arakne Framework; arbejdet med at udvideArakne, således at man kan linke til og fra videofilm på WWW; tilpasningen af Araknetil Construct hypermedieserverne; samarbejdsstøtte i Arakne; og endeligt en generelarkitektur til at kunne understøtte intersubjektivitet på Internet skala.

Mit arbejde med “Web augmentation” har vist, dels teoretisk og praktisk, at WWWmed fordel kan udvides med mere avancerede hypermediefunktionalitet. Den ud-videlse har til formål at forbedre WWW, men ikke at erstatte det. WWW er i dagså stort, at en udskiftning er aldeles urealistisk. Hertil kommer, at WWW på mange an-dre områder end netop hypermediemodellen er et glimrende system, hvilket dets storeudbredelse også vidner om. Snarere er det interessant at se på de anvendelsesområder,hvor WWW har svagheder, og afhjælpe disse, og mit arbejde viser, at dette i høj grader muligt.

Chapter 3

Introduction and Motivation

The Web as it stands today is a tremendous success. It is the single largest collectionof information ever created, and it is readily available to everyone with access to aWeb browser. As hypermedia systems go, the Web is unfortunately lacking in somerespects, especially with regards to the hypermedia model and the support for collabo-rative work. I will in this introduction illustrate some of the shortcomings of the Webthrough some scenarios.

3.1 Working on the Web

John D. Hansen is an agricultural consultant, and he spends most ofhis time researching and writing up reports and articles for the farmingcommunity. His company has in the last couple of years started to focuson the Web and John is currently working on the Web version of his mostrecent article about herbicides. John is not quite satisfied with the contentsof the Web pages from one large herbicide manufacturer, and decides toput in a link on the manufacturer’s Web page to his own analysis. Later,when John publishes his article, users of his company’s site (and users oftheir proxy) can see a link to his report on the manufacturer’s Web site.While he is at it, John creates a guided tour juxtaposing some recent videoclips from national TV of sensationalistic claims with regards to the use ofthe herbicide “Ground up” with the actual test reports and results, addinghis own comments.

This scenario illustrates several important points, much of which cannot be realisedwith the Web, as it stands today. The Web is essentially (baring self publishing) aread-only media, where users may access all kinds of information, but are barred frommaking annotations, or modifying (their view of) documents. The study and develop-ment of techniques to accomplish this using open hypermedia has been the focus of myPh.D.

An area, where the Web and Web browsers so far have been severely lacking isthe support for critical reading. There may be a lot of information available, but usersare not free to annotate these pages as they can with a book [73]. A recurring themeon the topic of the Internet and the Web is the creation of special interest groups andNGOs (non-goverment organisations), that span geographical borders. Related is the

13

14 CHAPTER 3. INTRODUCTION AND MOTIVATION

proliferation of meta Web sites, that largely consists of references (with short introduc-tions) to pages on other Web sites. While still young, there is also such a thing as Webjournalism, where journalists review and comment on Web sites, or create overviewsof specific topics. Common to these cases is that the creators of comments are limited,when referring to other Web pages: they can either make whole page references, orcopy and paste relevant parts into their own documents and thus leave it as an exerciseto the reader to locate the quoted portion in the original Web page.

Consider another situation, this time within an organisation. Manyorganisations deploy intranet with Web servers accessible only from thecompany network. If several groups within a project depend on the sametechnical specification, a Web server is well suited for making these docu-ments easily accessible. However, the Web is not only documents, it is alsolinks. Consider therefore the situation, where several of the groups wish toinsert links into the technical specification. This can be accomplished inseveral ways using standard Web technologies. Either all links are placedin the same document, or identical copies of the specification are madefor each group. Both solutions are unsatisfactory. In the former case, allgroups will either have write-access to the specifications in order to addlinks, or possibly send their links to a single Web master. Both solutionshave both overhead and the possibility of accidently corrupting either thespecification or other groups’ links. In the latter case, each group has theirown copy. This too is unsatisfactory, if the specification at a later pointchanges, asn copies of the specification then must be updated. It couldalso be the case, that the specification is so important, that it may not bemodified at all to prevent accidental changes.

These examples highlight that some things are not feasible or easy on the currentWeb. It is at this point quite unrealistic to replace the Web, and there is certainlyno need, as the Web performs admirably for most purposes. However, it would beinteresting to be able to perform the tasks described above better. One approach — theone taken by me through the course of my Ph.D. — is to try to improve upon the Web byadding an additional layer and leaving the layers below unchanged. This improved Webis what I term the augmented Web, partly in remembrance of NLS/Augment [39, 40]— a system that sought to augment the human intellect. I am not that ambitious, but Iwish to augment the Web.

3.2 Lies Open Hypermedia Dead in the Wake of theWeb?

It is the nature of my work that I place myself between two research communities, thatof open hypermedia and that of the Web. Tim Berners-Lee never presented his WorldWide Web formally to the hypertext community (at that time known as SIGLINK),though he held a demonstration of the system at the hypertext conference. Since thenthings have changed — the Web is big, and SIGLINK is today known as SIGWEB. So,http://www.acm.org/sigweb/

has hypermedia research been rendered obsolete, maintained only by a few academicdiehards? This question was discussed by Nürnberg and Ashman in [82] presentingthe thesis that Web is the open hypermedia system of the future, and the antithesis thatthe Web is hardly a hypermedia system at all. These are extremist points of view, and

3.3. THE VISION OF THE AUGMENTED WEB 15

the paper ends by reconciling thesis and antithesis into a synthesis. Briefly the paperconcludes that there is room for both parties and that both can benefit from joiningforces and learning from each other rather than focusing on differences.

Obviously, I think that there is room for both open hypermedia and the Web. In-deed, I do not foresee any immediate doom for open hypermedia caused by the Web.On the contrary I would argue that this is anexcellenttime to be doing research in openhypermedia,preciselybecause we now have the Web. As a topic for open hyperme-dia research, the Web has very nice properties. Most of the involved file formats andprotocols are open (a relief for a community used to dealing with proprietary editorsand formats), and there is a decent global naming scheme for documents and resources.Given the size of the content available (much of it fairly poorly structured), this is thetime where the fruits of open hypermedia may be harvested. Hypermedia becomesfirst really interesting and useful with large collections [4, 5], because this is wheregood structuring tools really pay off. Not only is there a lot of stuff out there, thereis also a lot of people using it (according to some of the latest estimates∼ 300 mil-lion, though this is notoriously hard to calculate). Organisations are actively movingtheir documents on internal and external Web sites. The Web has provided open hy-permedia researchers with what we could scarcely dream of before — a unified fairlywell-behaved document space with many users.

So what can we do with it? I along with many others have for the last few yearsbeen engaged in what I term Web augmentation. It is an approach to Open HypermediaSystems development aimed at the Web, which seeks to combine the strengths of eachtechnology to build a better Web.

3.3 The Vision of the Augmented Web

Web augmentation allows users to create and use external hypermedia structures im-posed on Web pages (i.e. not previously present on the pages), that they themselvesnot necessarily have write-access to. This would empower users as they would be ableto use the Web in a more flexible way. Given Web augmentation tools, it becomespossible to annotate, link, and otherwise structure all Web pages. Proper tools wouldalso allow users to share their links with others, or professionals to publish their workto their colleagues, clients, or readers.

Revisiting the cases in Section 3.1, some things becomes possible or easier withWeb augmentation tools. The following scenarios are all possible today.

Web journalists can pinpoint their links to exactly what they want.They can add annotations to documents, highlighting inconsistencies orweaknesses in the text. They can create guided tours to help their readersget an overview of a topic. As time goes by, their hypermedia structurescan be updated to reflect new material. With tools like this, there is sud-denly room for trail blazers1 on the Web, rather than collectors of links toother pages.

Professionals relying on technical or legal documentation can now sud-denly all share the same documents. The documents are not changed bythe users, as they create the links and other structures they need in theirwork. Each collection of hypermedia structures can be viewed on its own,or combined with with other collections. They can be exported and mailed

1Trail blazers: In Bush’sAs We May Think[23], professional authors of hypermedia structures.

16 CHAPTER 3. INTRODUCTION AND MOTIVATION

to others. Using robust location specifiers [87] it becomes possible to havelinks meaningfully survive document revisions.

One concern that is often raised in this context is that of intellectual property (IP):is it OK to modify other people’s Web pages? In the Coconut project, this questionwas put to the legal department of Tele-Danmark Internet. According to them, it ispermissable under Danish law, as long it is clear that such modification is taking place.As Web augmentation generally requires users to install special software or to configuretheir computer in a special way, the users can be expected to be aware that modificationmay be taking place. IP laws vary from country to country, and this argument may nothold water everywhere. It should be noted though, that Web augmentation in techniqueif not in effect is apresentation— the original Web page is not modified, but thepresentation of it on the user’s machine is.

While not all problems of the Web can be addressed through Web hypermediaaugmentation (e.g. “Error 404: Page Not Found”), the lessons and techniques learnedin the open hypermedia community could very well benefit the users of the Web. Letus therefore consider, what Web hypermedia augmentation is.

3.4 Open Hypermedia Web Augmentation Tool: A Def-inition

A tool is a open hypermedia Web augmentation tool, if it through inte-gration with a Web browser, a HTTP proxy or a Web server adds contentor controls not contained within the Web pages themselves to the effectof allowing structure to be added to the Web page directly or indirectly,or to navigate such structure. The purpose of such a tool is to help usersorganise, associate, or structure information found on the Web using hy-permedia structuring mechanisms. This activity may be done by a singleuser or in collaboration with others.

Most Web augmentation tools operate solely on HTML, but as demonstrated byWebvise [56] and Mimicry [20] [P2], other media types can be hypermedia enabled,such as video (see Section 6.2 for further details on Mimicry). As the different me-dia handlers grow more advanced and exhibit richer APIs (Application ProgrammingInterface), it becomes possible to augment more of the Web.

Already, there exists not only research prototypes, that demonstrates the possibili-ties of Web augmentation, but also an increasing number of commercial products aimedat this area (some of which are described in more detail in Section 5.2). The field ofWeb augmentation is an intriguing one, that requires attention both to hypermedia re-search and the current state of the Web.

Chapter 4

Hypermedia and the Web

This chapter describes the foundation for the fields within which I have worked and mo-tivates my work by examining hypermedia with special focus on open and collaborativehypermedia, as well as the Web. An understanding of what constitutes hypermedia andopen hypermedia in particular is the necessary foundation of my work. Likewise, thehistory of the Web and its current state is needed to establish why augmenting it withopen hypermedia might be a good and feasible project.

4.1 A Brief History of Hypermedia

Hypertext as a term was introduced in the sixties by Ted Nelson. The classical under-standing of the word is a collection of documents (or “nodes”) interconnected by links,so that a user easily can go from one place to another, as well as create links betweendocuments. Today, hypertext (or hypermedia) is not just about links anymore, and itis perhaps better to redefine hypertext to reflect this. A modern but vague definition ofhypertext could be the combination of content and structuring of that content.

Some argue, that the first example of hypertext is the Torah with its rich tapestry ofinterlinked annotations. However, the first description of a device that through electricor mechanical means provided what we today understand as hypermedia functionalitywas the hypothetical Memex, invented by Vannevar Bush in his landmark article “AsWe May Think” [23] published in theAtlantic Monthlyin 1945. The Memex allowedthe reader to speedily transverse a vast corpus of literature, to annotate pages, and tostore the trails taken through this landscape of text. The Memex had near infinite stor-age capacity using microfilm, and new collections of texts and trails could easily beadded or shared with other Memex owners. Proficient Memex users would becometrail blazers, discovering new relations between texts and publishing them for otherreaders to use. This hypothetical machine formed one of the foundations for hyperme-dia research [68].

4.2 The Classical Monolithic Hypermedia Systems

The Memex was more than a glorified electric library, it was a machine designed tohelp people utilise associative thinking, to help people see new relationships wherenone had been apparent before. The idea to create a device to help people think better

17

18 CHAPTER 4. HYPERMEDIA AND THE WEB

is a radical one, and one that was taken up by two luminaries in the sixties. Douglas C.Engelbart and Theodor H. Nelson. Their work took two different directions: Engelbartas the innovator and creator, and Nelson as the visionary.

Engelbart’s NLS/Augment [39, 40] was the first real hypermedia system. Thisground breaking system provided its users with a collaborative, multi-window system(with video conferencing!), where everything could be linked to, and where the maininteraction with the system was done through a mouse, another Engelbart innovation.The expressed purpose of NLS/Augment was to augment human intellectual capabili-ties.

The system designed by Nelson were no less impressive — he coined the term “hy-pertext” and envisioned the Docuverse [80], whereall texts would be instantly avail-able. This was to be realised through Project Xanadu — an extremely ambitious infor-mation infrastructure/hypermedia system that would take care of editing, versioning,backup, micro payment, typed hypermedia structuring, copyright, distribution, pub-lishing, etc. — many issues still not solved satisfactorily today, nearly forty years later.The Xanadu system has yet to materialise though the implemented parts of it recentlywas released into open source. In some regards, the World Wide Web can be consid-ered the actual Docuverse, though it is primitive compared to what Xanadu might havebeen.

The seventies and eighties saw the creation of several important hypermedia sys-tems. KMS [1] became the first system to featurelarge hypertexts (used by the Amer-ican navy). Intermedia [106], developed at Brown University for educational purposeshad several interesting properties, and stands, at least in this author’s opinion, as thepinnacle of monolithic hypermedia systems. Among its many advanced features were:

• Multi-user access to documents and hypermedia structures

• Access rights to read/write/annotate.

• Full fledged WYSIWYG applications

• Extensive undo/redo functionality

• Collections of documents (“corpus”)

• Collections of (externally stored) hypermedia structures (“Webs”)

• Span to span bidirectional links

• Graphical link browsers

• A large, object-oriented application framework to facilitate extensibility

A quite different but also impressive system was NoteCards [61] developed at Xe-rox Palo Alto Parc. Based on a metaphor of3× 5 cards, NoteCards was designed to be“a general purpose idea processing environment” [61, p. 45], intended for individualrather than collaborative use (see [94] for a discussion on the work of making Note-Cards collaborative). One very nice feature of NoteCards was the Browser card, whichwas both a graphical representation of a link structure, an editor for said link structures,and an entity which could be linked to as any other card. NoteCard was developed inXerox Interlisp, and could thus easily be modified and extended by the Lisp savvy. Thisallowed for great flexibility and supported experimentation with new forms of hyper-media structuring mechanisms, enabled NoteCards as a hypermedia testbed for further

4.3. OPEN HYPERMEDIA 19

experiments such as support for collaboration [94]. The lessons learned in the devel-opment of NoteCards was crystallised in Halasz’ famous “seven issues” [60], where heidentified areas that should be covered by new hypermedia systems.

4.3 Open Hypermedia

While individually impressive, systems such as Intermedia or NoteCards suffered fromsome problems. To be useful, they had to provide their users not only with hyperme-dia functionality (at which they excelled), but also with good editors (such as wordprocessors, spreadsheets etc.). For specific purposes, such as an educational setting(Intermedia) or idea generation/structuring (NoteCards), they did very well, but stillthese hypermedia systems did not become widely used. One of the major obstacles towidespread acceptance was identified by Meyrowitz in [78] as the lack of support ofthe editors already in widespread use. Most organisations rely on standardised tools,such as word processors, databases, spreadsheets, CAD systems, etc., and unless thepayoff is high, they are understandably hesitant to migrate to other tools. The mono-lithic hypermedia systems could only provide hypermedia functionality to their owneditors and file formats, and thus required users to move exclusively to these editors.With the personal computer revolution came a lot of new applications, and the hyper-media developers could not keep up with the various new editors supported on the per-sonal computers. The end result was that the hypermedia applications did not becomeas widespread as they might. Meyrowitz realised this, and suggested that the correctcourse was to embrace the third-party applications and to offer hypermedia function-ality for them, ideally to the degree where hypermedia functionality was as ubiquitousas copy and paste. This became known as “open hypermedia”, the augmentation ofthird-party applications with hypermedia.

An added advantage of integrating third-party applications is that it allows peopleto create relationships between documents handled by different programs, that wouldotherwise be non-integrated. Thus, dissimilar applications are “knitted together” bythe open hypermedia system.

Some of the current open hypermedia systems are (listed alphabetically)

• Chimera [7] (University of Colorado, Boulder, USA)

• Construct [52, 53] (University of Aarhus and Aalborg University Esbjerg, bothDenmark)

• DHM [50], now Webvise [56] (University of Aarhus and Mjølner Informatics,http://www.mjolner.dk/

Denmark)

• HOSS [81] (Texas A&M University, USA)

• HyperDisco [103] (Aalborg University, Denmark)

• Microcosm [63] (Southampton University and Multicosm Ltd., UK) http://www.multicosm.com/

All of which are represented in the Open Hypermedia Systems Working Group(OHSWG). See Section 4.4.2 for more details on this initiative.

Open hypermedia systems (OHSs) have in general many traits in common, whichgiven their similar problem space is to be expected. Given the need to integrate third-party applications with different (often closed) document formats, it is in general im-possible to store links etc. inside documents, and so OHSs utilise externally stored hy-permedia structures. This necessitates some sort of storage of these structures, usually

20 CHAPTER 4. HYPERMEDIA AND THE WEB

handled by a hypermedia server. Likewise, a client is needed to retrieve the hyper-media structures, and display them somehow in conjunction with the document theyrefer to. Areas where the OHSs often differ are aspects such as approaches to distribu-tion, collaboration, link markup, and extensibility. The sections below describes a fewrepresentative OHSs based on the findings of the first open hypermedia system.

4.3.1 Sun’s Link Service

The first open hypermedia system was Sun’s Link Service by Pearl [86]. The LinkService consisted of a link server, and an API (Application Programming Interface) fordevelopers, so that they with small modifications of their applications could provideusers with bidirectional links. The Link Service was an integrated part of the operationsystem (SunOS) and the windowing system (OpenLook), and was as such available toall applications running on the platform. The system provided users with shared orprivate collections of links, and support automatic or explicit link garbage collection.

Sun’s Link Service failed to penetrate the marked, perhaps because the success ofthe system relied on third-party developers to actively modify their own applications(the reliance on OpenLook quite probably did not help, either), but in the above men-tioned paper, Pearl identified some interesting issues with the development of openhypermedia systems:

User Interface Per definition an open hypermedia system relies on third-party editorsto handle documents. There are two user interface aspects in this: firstly, theremust be an interface to interact with the linking service; secondly, there must besome “highlighting” identifying the linked objects.

Document control Another common theme in open hypermedia is the ultimate lackof control of documents and their whereabouts. Unless documents reside in adocument management system, they can be modified, deleted, or moved withoutthe hypermedia system’s notice.

Link consistency Related to document control, links may become inconsistent if oneof the constituent documents disappear, is moved or modified, or is otherwiseunavailable.

Locating endpoints Apart from the problem of disappearing or changing documents,it can in itself be a problem to locate an endpoint in a document type not designedfor such uses. Especially if (or rather when) the document is modified.

Distribution Traditional monolithic hypermedia systems typically functioned withina context ofone file system. An open hypermedia system may well containdocuments residing on other, possibly remote, file systems. This raises questionswith regards to document control and link consistency — should the link bemarked as invalid (or even deleted) if the connection to the server holding aconstituent document is down?

Collaboration It is natural to collaborate on the material held within a hypermediasystem, and this should of course be supported by the system. This raises ques-tions about sharing, permissions, locking, etc.

Versioning Both documents and hypermedia structures can be versioned. While hy-permedia versioning presumably would be under the hypermedia system’s con-trol, document versioning can be a problem. E.g. what should a link point to?

4.3. OPEN HYPERMEDIA 21

The version of the document it originally pointed to, or the latest version? Whatif the latest version does not contain the link’s endpoint?

It should be noted, how these issues relate to respectively the client and the hy-permedia server. User interface and the location of endpoints are clearly client sideproblems. Another more interesting case is link consistency. Most implementations ofopen hypermedia systems would have the client determine link deterioration, as this ismost often discovered upon link decoration. As long as the server is able to store lo-cation specifications of a sufficient general nature, the client should be able to attemptto regenerate the link by locating the lost anchor. Of course, if the location specifica-tion of the hypermedia model employed is very specific, such as byte offsets, this is notpossible. Link consistency problems related to lack of control of documents is howevera general systems characteristics.

I will revisit these issues, as I go through some of the open hypermedia systemsbelow, as they are still valid, and illustrate some different design decisions in thesehypermedia systems.

4.3.2 Microcosm

The Microcosm Link Service [33, 42] from Southampton University was the first openhypermedia system, that is still in development and use. It is an innovative and (in someways) unconventional hypermedia system. The hypermedia group at Southampton (andlater the company Multicosm) has excelled in the integration of many third-party ap-plications, a topic described in more detail in Section 4.3.8.

One of the innovations of this system wasgenericlinks — links with a destinationendpoint with a specific location, but with a source specifying only the content of asource endpoint, rather than its location. One of the problems with much hypermedialinking is that link authors have to authorall the links, so that if new documents areadded to the corpus, they are initially “unlinked”. By creating links that rely on e.g.keywords in text, it becomes possible to reuse existing links in new documents. A triv-ial example of the usability of generic links would be an electronic dictionary, allowingthe user to rapidly access definitions of words and terms.

The Microcosm approach called for an aggressive inclusion of third-party editors(“viewers”), many of which could not be made Microcosm “aware”. In order to sup-port these kinds of applications, some functionality such as automated highlighting ofanchors were eschewed. Anchors in a document could instead be found on demand ordisplayed in a separate window.

A particular feature of the Microcosm architecture is the filter model. Messagesfrom e.g. clients are processed by filters that can stop, process or in other ways modifythe message by e.g. adding the anchors present in a given document. These filters canbe added or rearranged by the user.

Returning to the issues raised by Pearl in Section 4.3.1, the design of Microcosmhas some interesting consequences. Interface-wise, the reliance on generic links meansthat there often is no markup of links. Indeed, the creators cite this as a strength ofthe system. On the other hand, it makes it much easier to integrate editors, and thusvastly expands the number of applications that hypermedia functionality can be addedto. Microcosm features a little hypermedia button added to all application, from wherethe user can follow links etc. This is for instance possible in Windows, and gives theuser immediate access to hypermedia functionality. Document control can handled bya document manager, which addresses some of the concerns with regards to document

22 CHAPTER 4. HYPERMEDIA AND THE WEB

control. However, if the documents can be retrieved outside of the system, the possibil-ity of corrupted documents (from the view point of the hypermedia system) remains.This is however less of a problem in the context of Microcosm (baring the removalof documents), given the focus on generic links. Link consistency is closely relatedto this. While a generic link will work in all documents, as long as there is a selec-tion matching the link, the destination document (or the specific location within thatdocument) may well be gone. Given the Microcosm approach, a problem such as lo-cating an endpoint is circumvented, as many endpoints (especially to unaware editors)are whole-component. With specific anchors, the default Microcosm approach is to usebyte offsets [32, p. 212] to locate anchors. Such an approach is quite fragile, and can besupplemented by “macro” (for applications, that support such) to locate the selection.With the work on Microcosm TNG (The Next Generation) [46], Microcosm can han-dle distributed document, link, and service location. TNG also incorporates a notionof sessions, wherein users can specify, share and collaborate on selected services andapplications, that is nodes and link collections. Versioning in Microcosm is describedin [76], as layers of applications. This arrangement allows user to freely access nodesand links from different versions, but does not support merging.

4.3.3 Devise Hypermedia

The Dexter Hypermedia Reference model (described in further details in Section 4.4.1)inspired the development of the Devise Hypermedia (DHM) at the University of Aarhus.DHM was originally developed for the Macintosh and Unix platforms using the object-oriented language, BETA. It saw much development during the EuroCODE project,where it was used in a large engineering setting [47, 49]. It has been used exten-sively as a research prototype, and has in its development history been a cross-platformhypermedia system, a collaborative hypermedia system [49, 50], a tailorable systemwith an embedded interpreter [51], hypermedia basis for an 3D collaboration system[22, 79] and in its current incarnation the Windows based Webvise hypermedia systemintegrating Microsoft Office and Internet Explorer [56].

While based on Dexter, the work involved with the implementation of DHM ne-cessitated clarifications, extensions, and departures from the original model: The Dex-ter model adamantly forbids dangling links, which DHM permits; composites containin Dexter their constituent components, where they in DHM may contain referencesinstead; anchors to whole components are not specificed in Dexter, which they arein DHM. By design Dexter left the within-component layer largely unspecified savethe anchoring interface as to concentrate on the core hypermedia functionality of themodel, but for an open hypermedia system the within-component or application layeris quite important. Dexter assumes that components are controlled by the hypermediasystem, but in open hypermedia documents etc. are usually owned by various otherapplications, and this had to be encompassed in DHM. It should be noted that Dexterin other aspects, such as anchoring and presentation specifications, was found to bewell suited for open hypermedia. One of the main focuses of the development of DHMhas been client integrations, as DHM has been used in various research projects wherecertain applications has been used by the participants. This has resulted in integrationswith Microsoft Office applications, as well as technical software, such as CAD sys-tems. The Webvise client was, to the author’s knowledge, pioneering in utilising theMicrosoft Internet Explorer’s COM (Component Object Model) interface to integratethe Web, an approach later also used by the Arakne Environment.

DHM is a conceptual three-layer hypermedia system. The storage layer has varied

4.3. OPEN HYPERMEDIA 23

through the history of the system, originally a object persistence store was used — thecurrent version utilises file based storage. At the structure level the system currentlysupportsn-ary, bidirectional links and guided tours. Client wise the system has it owndedicated client, the Webvise Client, but has also supported the DHM/WWW [48] andNavette [16] clients, as well the first version of the Arakne Environment [17] [P1].

As for Pearl’s issues, the DHM systems have always stressed the user interface,which has resulted in some highly integrated interfaces in especially Microsoft ap-plications, where the hypermedia functionality is made available through menus, andwhere anchors are highlighted in the various documents. Documents are outside of thesystem’s control, which leaves the possibility of link inconsistency, but depending onthe integrated application, Webvise has fairly robust anchor specifiers. While DHMhas at times been a collaborative, LAN (local area network) distributed hypermediasystem [50], the current incarnation, Webvise, is not aimed at collaboration, save byexchanging interchange files. The exchange of such files is quite well supported, asthey by the client can be stored on WebDAV compliant servers (see Section 4.7.4 formore information on WebDAV, and Section 7.3 for a discussion on how this may helpscalability), and their retrieval in a Web browser will on a computer with the Webviseclient installed automatically launch the client, and display the hypertext. DHM has noprovisions for versioning, though it can be used in conjunction with a system support-ing document versioning, as done by the High Road Demonstrator in the EuroCODEproject.

4.3.4 HyperDisco

HyperDisco comes from a family of hypermedia systems developed at Aalborg Uni-versity: Hyperbase 0–2 [100], Hyperform [101], the Emacs HyperText System (EHTS)[99], and HyperDisco [102, 103].

A characteristic of these systems is the architectural focus on distribution, collabo-ration, and hypermedia database systems. Few systems, save perhaps the hypermediasystems developed at Texas A&M University (see Section 4.3.5 for a description ofHOSS), has focused as much on hypermedia infrastructure. Indeed, HyperDisco maybe considered a “meta hypermedia” system, to wit:

The HyperDisco project is about design, development, deployment andassessment of OHSs. The overall goals of the project are to work towardsinnovative new OHSs and to try to influence the development of futuregenerations of OHSs for the Internet. [104, p. 296]

The HyperDisco hypermedia system has several interesting properties. It is es-sential a three-layered architecture with tools (integrated or native), tool integrators(usually one per user), and workspaces. A workspace embodies hyperbase and col-laborative functionality, and can be distributed over the Internet, and users can choosewhich to operate on, assuming they have the proper permissions. Returning to Pearl’sissues, HyperDisco addresses many of these concerns. HyperDisco integrated ten ap-plications by October 1999, most well-known of which is XEmacs, which is integratedhttp://www.xemacs.org/

with menus and markup. HyperDisco can handle documents stored outside of theworkspace, as well as within it, and certainly in the latter case can exert document con-trol. This also to a large degree answers the concern of link consistency. Certainly ifthe document is held in HyperDisco’s control, link consistency should be assured. AsHyperDisco anchors are extensible, the ability to regenerate broken anchors lies with

24 CHAPTER 4. HYPERMEDIA AND THE WEB

the various client. HyperDisco handles versioning at the data model level by provid-ing a Version Control class, that (through multiple inheritance) can be subclassed byany component. This is used mainly for versioning of nodes, while other components(such as links, composites, etc.) are not (at least at time of writing [102]) versioned.Distribution and collaboration are areas, where HyperDisco shines. As described aboveworkspaces can be distributed Internet-wide, and users of the system can freely collab-orate within these workspaces.

HyperDisco along with other systems (especially HOSS described in the follow-ing section) informed the creation of the Construct hypermedia architecture, describedbelow (Section 4.3.7).

4.3.5 HOSS

HOSS [81, 83, 84] grew out of a series of hyperbases and hypermedia systems de-veloped at Texas A&M University: PROXHY [67], HB1/SP1 [90], HB2/SP2 [91],http://www.csdl.tamu.edu/

and HB3/SP3 [71]. An interesting feature of HOSS is the focus on providing hyper-media functionality on the operating system level. Usually hypermedia systems areconsidered to belong to the application level, giving the user tools to interact with andstructure information. Another innovation of HOSS is the separation between data,structure, and behaviour. Separating data and structure is arguably what hypermediais all about, and this system takes it one step further by allowing behaviour to be de-fined separately. In contrast, most hypermedia systems have more or less fixed e.g.link transversal behaviour. By opening up behaviour, and relegating both structureand behaviour to the operating system level (where data has been all along), this ap-proach opens up some radical possibilities. A hypermedia operating system would bevery flexible, and would provide users with superior performance when working withstructures, as the system would be able to prefetch needed data or structure, cachebehaviours and structure, automatically handle structure etc.

A prototype of this approach has been implemented in the HOSS system. HOSSruns on SunOS, and provides services for handling data, structure, and behaviour. Thehttp://www.sun.com/

system offers an open set of behaviours (“Sprocs”), in the version described in [84]navigational and taxonomic hypermedia, as well as annotations. Applicationwise, thesystem integrates a spatial text editor [31], an animation tool, and a reviewing tool.In addition, HOSS also provides launch-only integration for non-integrated tools. Theintegrated tools use the object store provided by HOSS for storage. As the HOSSstorage layer offers versioning, this is also available for structures and the data storedwithin the storage service. A fairly unique (certainly the author is aware no othersystem providing this) client isHsh, the HOSS shell similar to Unix shells, but aimedat controlling the hypermedia system. HOSS is a hypermedia-in-the-large system, andcan thus handle distribution. From [83, 84], it is unclear how collaboration is supported.With regards to link consistency, by virtue of storing at least some documents withinits own object store, the system should be able to provide some consistency guarantees,though this is largely conjecture on the part of the author.

Apart from the idea of integrating hypermedia on the operating system level, avery interesting feature of HOSS is its development tool. HOSS’s designers stress theimportance of an open set of services and to that end provide the developer with thePDC. The Protocol Definition Compiler generates, based on an IDL like specification,C libraries to handle IPC (interprocess communication) between HOSS components.The speeds up development time, as programmers are freed from the tedious and errorprone work of developing such code. The work on hypermedia development tools has

4.3. OPEN HYPERMEDIA 25

been continued at Aalborg University Esbjerg in the form of CSC [105], a developmenttool for new Construct (Section 4.3.7) hypermedia services.

4.3.6 Chimera

Chimera [7, 8] is a hypermedia system developed at University of California, Irvine,and University of Colorado, Boulder. It has seen industrial use [5], and has as suchbeen the topic for scalability studies [3, 4, 5], as well as some initial studies on XLink[64]. From its beginning, the main focus of the Chimera system has been large softwaredevelopment projects, which has, among other things, informed the work on scalability.The Chimera architecture is three-layered with a relational database serving as storage.An interesting feature of Chimera is the ability to serve Java applets to users, so thatthey can access and manage the system without installing special software locally. Hy-permedia wise, a unique feature of Chimera is the concept of “view”. Open hypermediasystems in general handle viewers/editors as programs able to display a document, andare often able to launch the viewer associated with a media type. Anchors are in sucha model associated with the document, and are presented depending on the abilities ofthe viewer. Chimera has a different approach to this, as anchors are associated to views,that is the combination of a viewer and a document. The implication is that Chimeracan present the same document differently (with different anchors), depending on theviewer used. One example of this would be a spreadsheet presented either as a matrixor as a graph.

Returning to Pearl, the interface for managing hypermedia structures lies, depend-ing on the level of integration, in the Chimera Client or in the viewer. Chimera exertsno document control, and can therefore as most other hypermedia systems get in trou-ble with document and link consistency. As anchors are view specific, their appearanceand location depends naturally on the abilities of the viewer. Chimera supports collab-oration through and distribution of HyperWeb servers through HyperWeb managers,which (among other things) handles the location of HyperWeb servers. Versioning,while outlined in [97], has not been implemented.

4.3.7 Construct

Construct is one of the results of the Coconut project. It is the codebase descendantof HOSS [81, 83, 84], HyperDisco [102], and DHM [50], designed and developedby the people (among others!) behind these systems. It is compliant with existingOHSWG standards, along with several extensions, such as compositional and spatialhypermedia. It is also the backend of the Arakne Environment.

Design wise, it has inherited much from its ancestors. It has a clear three-layer de-sign with an open and extensible set of services. The architecture is highly symmetricwith regards to the three layers, which is illustrated by the overall process architectureseen in Figure 4.1. This process architecture is found at all layers — clients com-municate with a structure server through a virtual server, servers communicate withclients through virtual clients and so on. The core holds “actual” functionality — thusa navigational hypermedia client uses the Nav core to operate on navigational com-ponents. The architecture with virtual servers and clients provides multiplexing andleaves room for other transport layers — the current Construct uses XML over TCP/IPsockets, but this may well change in the future, as OHSWG moves forward, as outlinedin Section 6.3.

26 CHAPTER 4. HYPERMEDIA AND THE WEB

Hypermedia structure wise, the Construct architecture currently supports naviga-tional, compositional, and spatial hypermedia. Due to its extensible nature, this is how-ever not a closed set. With the advent of the CSC tools [105] from Aalborg UniversityEsbjerg, the development cost of new hypermedia services will be greatly diminished.As an example of the data model of Construct (and in this instance of OHSWG), seeFigure 4.3. The navigational data model is discussed in more details in Section 4.4.2.

Construct supports collaboration at the server level, mainly through the notion of“sessions”. What this collaboration support means at the client is described in Sec-tion 6.4. To address link consistency, the OHSWG navigational hypermedia model hasa flexible and extensible set of location specifiers. How this is utilised, depends on theclient. The current version of Construct does not support versioning.

virtualclient pool

virtualclient

sessionproxy core

virtualserver pool

virtualserver

connectionmanager

n..1

1..n

m..n

1..n

1..n

1..n

Figure 4.1: The Construct Process Architecture (from [52])

4.3.8 Integrating Third-party Applications

The defining characteristic of open hypermedia is the integration of third-party ap-plications. It is also one of its greatest problems, as it is often hard to accomplishsatisfactory integrations. The first to write about this was Daviset al in [34], and it haslater been covered by Whitehead in [95]. Application integrations differ in the degreewith which the hypermedia structures can be made visible and manipulated directlyin the application user interface. The most basic integration is “launch-only”, that isa situation where the hypermedia system launches an application to display a specificdocument, but has no further control over the application. In such a situation, onlywhole component (i.e. the entire document) references are possible. Fortunately, manyapplications support various levels of scripting and tailoring, and by such means it ispossible to create quite sophisticated integrations, where fine-grained addressing of theapplication’s document becomes possible, and where much of the hypermedia inter-face may reside in the application. Applications with sophisticated integrations include(X)Emacs, Microsoft Office, AutoCAD, MicroStation, Framemaker, and various Webbrowsers.

In the course of the author’s work, the applications to integrate have been Webbrowsers, and the experiences in this context can illustrate the various means, withwhich such an integration may be accomplished. This is described in the following

4.3. OPEN HYPERMEDIA 27

section, and considerably more detailed in Section 7.1.

4.3.9 Open Hypermedia on the Web

The open hypermedia community is in some ways uniquely well suited to take on theWeb with hypermedia. The community has extensive experience of supplying otherapplications with hypermedia functionality, and the Web has qualities (outlined in Sec-tion 3.2) making it an “easy target” for integration.

This section focuses on the various approaches taken to support hypermedia inte-gration with the Web, and will so in passing describe some of the systems that employsuch approaches. It should be noted that there are also open hypermedia systems, thatutilise the Web without actually performing Web augmentation. Chimera [7] activelyuses Web browsers, and Web-aware HyperWeb servers to provide users with hyper-media clients and maintenence tools. These tools are however used for controlling theChimera system, not for hypermedia augmentating Web pages, and in this sense theChimera system uses the Web more as a transport layer.

Given the general architecture of the Web (see Figure 4.5), it is fairly obvious thatthere are basically three “lines of attack”, when wanting to gain access to the Webpages displayed in a Web browser. It can be done at either the Web server where thepages reside, at an intermediary Web proxy, or in the Web browser. The possibilitiesand consequences are outlined below.

Server side

It is quite easy to add content to a Web page through a Web server. This content canbe dynamic (relative to more static Web pages) and easily be switched on and off bythe user through the use of cookies etc. Often this kind of augmentation is achievedthrough CGI (Common Gateway Interface) scripts, with Walden’s Paths [45], one ofthe classic guided tour tools for the Web, as a prototypical example. The guided tournavigation menu is dynamically added to the pages that constitute the contents of apath. There are however some drawbacks to this approach. If one wishes to augmentWeb pages from more than one Web server, these “foreign” pages must be modified insome way. One typical approach is to modify all links encountered to invocations ofCGI scripts with the original link as an argument. However, the use of e.g. frames orbookmarks in the Web browser defeats the modification of links, and thus all actionsby the user cannot be handled through this approach.

Similarly, the authoring of hypermedia structures becomes difficult, as there is nointerface, save the Web page. The common approach to this is either to have a separateauthoring tool (this is the case of Walden’s Paths), or to provide special Web pages withforms allowing the authoring of e.g. links, though the latter approach quickly becomescumbersome.

The two greatest advantages of the server side solution are that the user does nothave to modify browser configuration other than using a specific Web site, and that theservices can be accessed from any Web browser.

Proxy side

To maintain the Web augmentation system’s access to the Web pages displayed in theuser’s Web browser, the most obvious approach is to use a proxy. Proxies are widely

28 CHAPTER 4. HYPERMEDIA AND THE WEB

used for caching purposes1, but can also be used to modify Web pages. The prototyp-ical example of this is the Microcosm Distributed Link Service (DLS) system [25]. Inthese cases the proxy acts as a hypermedia client, retrieving links etc. from link basesand inserting them into the Web pages. The great advantage is that the system is, oncethe Web browser has been configured properly, always available. This is ironicallyalso one of the greatest drawbacks — it is quite plausible that the user does not wishto constantly use the proxy, as the querying of link bases inevitable will slow downthe process of browsing. Indeed, this drawback (among others) later led the Micro-cosm group to create the AgentDLS system [24], where links were displayed alongsidethe primary Web page in a periodically refreshed Web page rather than being inlined,boosting performance considerably. This approach raises the question of whether thiskind of interface results in too many focus shifts, as users try to correlate a Web pagewith the “links page”.

Another hypermedia proxy is the DHMProxy [56] created by the Coconut project,using the DHM and Construct servers. An interesting feature of the DHMProxy wasthe method of link decoration (i.e. the act of inserting links etc. into the Web page), as itwas, for Web browsers that supported it, like that of Webvise or the current Arakne En-vironment. Based on the information retrieved from the hypermedia server, the proxyinserted into the Web page Javascript code, which upon arrival was executed and per-formed the link decoration. This was done to circumvent the problem described belowwith dynamic Web pages.

The reservations with regards to hypermedia authoring noted above also hold forproxy solutions, e.g. DLS used a separate Web page for link authoring. Of course,one can opt to have a client running on the user’s computer. The early versions ofthe Arakne Environment provided authoring, but employed the DHMProxy for linkdecoration. In order to use a proxy solution, the user has to setup the Web browser touse that particular proxy. This has some problems: The user may not want (or may notbe able) to make this configuration change; the use of a special proxy may collide withthe use of another proxy2; and the user will feel the performance hit of the hypermediaproxy, whether the current Web page has any extra hypermedia content or not.

Client side

It is also possible to modify Web contents at the client. The first system to do so wasthe DHM/WWW system [48], and the client-side approach has also been taken by itsdescendants, Navette [16], and finally the Arakne Environment [17] [P1], as well asWebvise [56].

Historically, there have been two approaches: Pre- and post-render page modifica-tion, that is before and after the Web browser has displayed the page. DHM/WWW,Navette, and the earliest incarnation of Arakne all utilised a pre-render approach,DHM/WWW by retrieving the page, modifying it, and generating Javascript to out-put it to the Web browser; and Navette by acting as a local proxy. Both instances canthus be argued to be quasi-proxy solutions, both with the great disadvantage of havingto compute links, etc. before rendering the Web page. In contrast, both Webvise and thecurrent Arakne Environment use post-rendering page modification. There are severaladvantages to this approach. The first advantage is that of performance, as pages aredisplayed in the Web browser as fast as they would without the hypermedia application.The second advantage is the ability to more robustly handle “difficult” HTML. Many

1Indeed, ISPs often use proxies transparent to their users.2The Coconut proxy addressed this by allowing users to specify a proxy for the Coconut proxy to use.

4.4. HYPERMEDIA STANDARDISATION EFFORTS 29

Web pages are today highly dynamic in the sense, that they contain a lot of Javascriptwhich upon arrival is executed and modifies the page. This is very difficult to catchefficiently pre-render, but easy after the Web browser has rendered the page.

The great advantage of a client side solution is that authoring becomes very easyto support. Client side necessitates a hypermedia application running along the Webbrowser3, and this application can of course also accommodate authoring. On the flipside, it forces the user to shift focus between two application during authoring as wellas hypermedia applications other than simple link traversal.

The great disadvantage of client side integration is that, given the current generationof Web browsers, the choice of Web browser (and hence operating system and com-puting platform) becomes quite limited. Currently the post-render approach can onlybe supported by the Microsoft Internet Explorer under Windows. This is highly unfor-tunate as it locks many users out. Until other suitable Web browsers (such as Mozilla)appear, the situation is unlikely to change. See Section 7.1 for further discussion on thetopic of Web browsers.

4.4 Hypermedia Standardisation Efforts

Throughout the history of hypermedia, there have been several attempts to standardisehypermedia, both on a conceptual level and on an interchange and interoperabilitylevel. This is important work for several reasons. Firstly, by clearly agreeing on whathypermedia is, it becomes easier to focus and compare research efforts. Secondly, thevarious hypermedia systems gain, if it is possible to either interchange documents, orperhaps even get different hypermedia systems to work together. Thirdly, if there existsa standard supported by several hypermedia systems, this standard becomes attractivefor other developers to support, thus spreading general hypermedia support to moreapplications, and thus reinforcing development, as described by Whitehead [96].

Standardisation efforts are, however, not without pitfalls. Make a standard too bigand complicated, and it is unlikely to catch on, as the investment to become standardcompliant is too big. An example of such a standard is SGML, which while certainlyused in large organisations, was not seeing as widespread use as it might. This waslargely due to the very high development cost of producing tools compliant with thevery comprehensive standard. Few tools were developed, and these tools were quiteexpensive. With the introduction of XML, a simpler version of SGML, the cost ofadopting was lessened dramatically to the extend, where parsers and other tools can beobtained freely and open source. Today, XML is one of the new powerful paradigmsof Internet distributed computing, and is being used extensively in many areas.

In the context of open hypermedia, a standard should either be simple conceptually,or modular, so that the hopeful standard adopters can incrementally implement whatthey need. As there in open hypermedia are several well established systems, a stan-dard that closes one out by specifications that cannot be met by this system is likelyto be met with resistance. Again, a modular standard is preferable, so that areas ofcontention — such as composites or collaborative support — can be adopted by thosesystems that can support them, while still allowing other systems to use other less con-tentious modules of the standard. Furthermore, this would allow others to “pick and

3Systems may integrate directly into the Web browser, as the Internet Explorer add-ons (see Section 5.2),but they are still separate processes. The Webvise client has experimentally been integrated with the InternetExplorer in this fashion.

30 CHAPTER 4. HYPERMEDIA AND THE WEB

choose” from the standard, solving their problem space without having to implementunnecessary or unwanted functionality.

4.4.1 The Dexter Hypertext Reference Model

The Dexter Hypertext Reference model [62] introduced a common framework for hy-permedia systems. Its contributions were manifold. Among the more crucial were ageneral hypermedia architecture, the generalisation of the link from binary to arbitraryarity (i.e.n-ary or multiheaded links), the realisation that nodes, links, and compositesare separate first-class components, the generalisation of the composite, and the clearspecification of what the responsibilities of a hypermedia system is.

Presentation of the hypertext;user interaction; dynamics

Storage Layera 'database' containing a

network of nodes and links

the content/structureinside the nodes

Presentation Specification

Anchoring

Run-time Layer

Within-Component Layer

Focus of the Dexter Model

Figure 4.2: The General Dexter Architecture (from [62])

The Dexter architecture is summarised in Figure 4.2. The focus of the Dexter modelwas mainly on the storage layer and the entities stored within it. The objects stored inthe storage layer are summarised in Table 4.1. The hypermedia model of Dexter isquite simple and elegant, and a novel aspect of it is that links and composites just asatomic components can be the target for links. The composite is used to contain othercomponents, including other composites (though not itself).

The Dexter model does not concern itself with the applications wherein the atomiccomponents should be displayed. This is all a part of the within-component layer. Thefocus is on the storage layer and the interplay between the run-time layer, containinga running hypermedia system used by a user, and the storage layer, containing thedatabases serving components to the hypermedia system.

Much is left out of the Dexter model — there is no collaboration; editors areopaque; as are presentation specifications and anchor values. This is however one of themodel’s strengths: It does not get bogged down in implementation specifics. Thus, itwas able to inspire and provoke a lot of thinking [71] and (especially at Aarhus) devel-opment of new hypermedia systems. See Section 4.3.3 for a more detailed discussionof the Dexter based hypermedia systems developed at Aarhus.

One of the goals of the Dexter model was to facilitate interchange between hyper-media systems, and some work has been published on that topic of KMS to Intermedia[69]. The problem of interchanging files between too different hypermedia systems isthat there invariably will be “hacks” in order to accommodate hypermedia structuresnot supported by both systems — a simple example is the translation of a one-to-many

4.4. HYPERMEDIA STANDARDISATION EFFORTS 31

Components All components have a globally unique identifier(GUID), a list of anchor indexing into the component,a presentation specification, and a list of attribute/valuepairs.

Atom The “nodes” of the Dexter model. Known in other hyper-media systems as cards, frames, documents, etc. A Webpage is a node. Opaque in the Dexter model.

Link A link contains a list of specifiersComposite A composite contains components, including other com-

posites.Entities stored incomponent infoSpecifier A specifier contains an identity unique within the link, a

specification of a component (often the GUID), an anchorid, a direction, and a presentation specification.

Anchor An anchor contains an identity unique within the compo-nent, and an anchor value. The anchor value (opaque tothe Dexter model) identifies a part of a component.

Presentation specifi-cation

The presentation specification determines how a compo-nent should be presented to the user. This is opaque tothe Dexter model.

Table 4.1: Components and entities in the Dexter model

link into a system supporting only binary links. With such intermediary translations,it becomes difficult to have “robust” interchange, that is, a situation where a hypertextremains the same after being translated to another system and back. If this is not pos-sible, the usefulness of interchange files are diminished, as they then serve more as anmigration path than as a possibility of working together across different hypermediasystems. Section 7.3 deals with other uses for interchange formats.

4.4.2 Open Hypermedia Systems Working Group

The Open Hypermedia Systems Working Group [35] (OHSWG) was founded in 1994http://www.ohswg.org/

by the different parties involved in the development of open hypermedia systems.Among the original goals of the OHSWG was to collaborate on third-party applicationintegrations, as this has always been the great challenge to open hypermedia develop-ment and an area, where code sharing could be mutually beneficiary. Apart from thisutilitarian goal, OHSWG also wished to identify what constituted open hypermediaand to devise a common standard, so that open hypermedia systems could interoperate.

The work of OHSWG has over the years evolved into the Open Hypermedia Proto-col (OHP), a data model and protocol for collaborative, open hypermedia. Today, OHPencompasses a growing number of protocols that covers hypermedia, such as navi-gational, compositional, and spatial, collaboration support, subscriptions, naming andlocation of hypermedia services, caching, and document retrieval. The scope of thistext does not permit a comprehensive study of the entire standard, but the navigationaldata model can be seen in Figure 4.3.

Some aspects of the OHP navigational model are interesting in the sense that they

32 CHAPTER 4. HYPERMEDIA AND THE WEB

Object

AbstractObjectIDNameTypeDescriptionsCharacteristicSet

ContentSpec

equals

URIContentMimeType

LocSpecVersionReferenceSelectionSelectionContextSelectionTypeequals

SessionStateNameCouplingModeVirtualClientsDocsOpenSubscriptions

SessionRecordMembersDocIDsJoinPolicy

LocationRecordAddressAddrType

SubscriptionPatternFlagsTempExpireDateCompId

HMObjectComputationPSpec

NaLocSpec

AxisLocAxisListRevAxisListOverrun

ContextMembers

LinkEndpointIds

EndpointLinkIdDirectionAnchorId

AnchorParentIdLocSpec

NodeContentSpec

Computation

Execute

InParamOutParamContentSpec

PSpecSpec

Figure 4.3: The OHSWG Navigational Data Model

are very general and allow for many kinds of extensions and innovative future uses. Forinstance all HMObjects has presentation specifiers, as well as computations and arbi-trary key/value pairs (“characteristics”). A Context is the container for other HMOb-jects’ IDs — including other Contexts. The parentId of the Anchor is the identity ofthe object containing it — this is usually a Node, but could just as well beany otherHMObject (as HMObjects all have IDs). Thus, a link can point to any other HMOb-jects.

Aside from diverse hypermedia structuring mechanisms, OHP also supports col-laboration through the notion of sessions. A group of people working together onhypermedia structures on a set of documents using various hypermedia tools embodiesthe session. A session is defined by a set of users, documents, and tools, and has acoupling mode (ranging from uncoupled to tightly coupled) and a joining police (e.g. apublic or private session) associated with it. Through the session, each collaborator isvisible to the other collaborators, as are his or her actions, depending on the couplingmode. If a collaborator so desires, special subscriptions can be set, so that specifiedactions taken by certain users result in notifications. The session is persistent, so that agroup at a later point can resume work where it was left.

Collaboration in hypermedia was not introduced by the OHSWG. It is a fairly oldfield within hypermedia research, and is described in the following section.

4.5 CSCW and Collaborative Hypermedia

The fields of computer supported collaborative work (CSCW) and hypermedia shareroots, as some of the first papers published on collaboration using computers were pio-neer hypermedia papers “As We May Think” by Bush [23] and “A Conceptual Frame-work for the Augmentation of Man’s Intellect” by Engelbart [39], published in respec-tively 1945 and 1963. Bush and Engelbart both wished to improve work — Bush indevising better ways to cope with a rapidly growing scientific literature, and Engelbartin helping knowledge workers to handle difficult problems better.

4.5. CSCW AND COLLABORATIVE HYPERMEDIA 33

Work is rarely done by exclusively the individual; there is usually a social contextwithin an organisation, that determines why work is done, what work is done andhow it is carried out. This social context demands cooperation between workers, beit on the same level of the organisation or between levels. The purpose of computersupported cooperative work (CSCW) is to investigate and understand this cooperation,and to support it with computers. Bannon and Schmidt have written one of the betterdefinitions of CSCW:

an endeavour to understand the nature and requirements of coopera-tive work with the objective of designing computer-based technologies forcooperative work arrangements. [11][p. 11]

The CSCW field is characterised by its diversity, and it attracts people from manydisciplines. As noted in [10], the term CSCW itself is contested. Whatis cooperativework? Schmidt and Bannon use the social science tradition (reaching back beyondMarx and onwards) to define cooperative work as the activity people engage in whenthey work together and are mutually dependent in the sense that one cannot finish thework without the contribution of the other. This interdependence requires planning,coordination, allocation, scheduling, commitment etc. from the people engaged in thework. These activities necessary for cooperative work are under one referred to asarticulation work. The different settings and conditions under which cooperation isfound may vary tremendously, but articulation is always needed to make the coopera-tion work. By focusing on articulation, Bannon and Schmidt are able to come up witha general understanding of what cooperative work is, and how it may be supported bycomputers. They avoid a common pitfall of CSCW: focussing on the group. A goodexample of the predominant group focus is the term “groupware”. Cooperative workis not limited to the group: people work together across boundaries — an example isnetworking between within and without organisations.

CSCW is a large field and the scope of this text does not permit a general overview.One area especially pertinent to my work (papers [15] [P4] (Section 6.4) and [6] [P5](Section 6.5)) is the study and support of shared awareness. As described by Heathand Luff [65] in their analysis of work done by traffic controllers in the London Un-derground, maintaining shared awareness between co-workers can be crucial. Manysystems has endeavoured to support this. The GroupDesk system [44], the NESSIEsystem [88], the Elvin system [41], the AREA system [43], and the BABBLE system[21] to mention a few. These systems try to support shared awareness through meanssuch as messaging, chat, and event notification. Some of the awareness support requireexplicit actions by the users, such as sending a message to another user, others are im-plicit. The latter form is for instance the action of updating a file in a CVS repository,which gets broadcast to all users of the Elvin system, or joining a topic in BABBLE,which shows others users, that you are active. Some systems, notably AREA andElvin, attempt to integrate with other applications, so that actions in these applicationsare broadcast to other users.

These tools are not only found within academia: a commercial and very widelyused system (reportedly 3 million users) is ICQ, a “buddy list” program, where usershttp://www.icq.com/

may see when their friends are online and engage in asynchronous message exchangeand synchronous chat.

In the context of shared or peripheral awareness tools, the topic of privacy becomesimportant. Not all actions taken by a user belongs in the public, and the user will(often rightly) fear a system facilitating “Big Brother”. When people work together,

34 CHAPTER 4. HYPERMEDIA AND THE WEB

they normally share an understanding of what is acceptable to the participants andwhat is not. If not the boundaries between people are respected in the system, trust iseliminated and that can prove disastrous to continued cooperation. Clement gives in[29] a great deal of thought to the privacy issue in the context of media spaces (such asPortholes [38]), but his conclusions and warnings are applicable to the entire CSCWfield. To return to Bannon and Schmidt:

visibility must be bounded[...] Deprive workers of that capability, andthey will exercise it covertly [11][p. 35]

Hypermedia is per definition used to structure information. This can of course bevery usable for the individual user, but already the earliest (hypothetical) hypermediasystem, the Memex, featured in addition to support for personal trails, the ability toshare trails among other Memex users. Apart from making trails/structures upon ex-isting information, hypermedia systems have also found use in assisting the process ofwriting new material, where the hypermedia system is for instance used to gather andstructure information, that is subsequently organised into a linear text (one exampleof such a system would be NoteCards [61]). From these systems, the step to supportmultiple authors seems natural.

NLS/Augment [40] was also in this aspect a groundbreaking system, where userscould co-author material and participate in video conferences complete with cursorsharing in 1968. Later systems, such as KMS [1], also supported collaboration. In thecase of KMS, collaboration was partly supported by the system itself through optimisticconcurrency control, where the system would ensure that modified frames were notaccidently overwritten, partly through the use culture of KMS, where most frames canbe modified (or at least annotated) by the users of the system. Services such as lockingor notifications were however deemed too impractical, especially considering the strictperformance goals set for the KMS system.

In Intermedia [77] the notion of Webs, that is collections of links, became a use-ful tool for collaboration. Just as the ability to share and access the same informationas in KMS is important for collaboration, the ability to work privately or in groupson a Web and then later publish it for others to see, helps to focus collaboration. In-termedia handled multiple users with different permissions, so that one person couldcreate documents, available only for reading and linking by others. Another of theclassic monolithic hypermedia systems, NoteCards, has also been extended to supportcollaborative authoring [94].

SEPIA [58, 59, 93] is an ambitious collaborative hypermedia system from GMDIPSI, Germany. Based on a cognitive model of the authoring process, SEPIA supportscollaborative authoring. Collaboration is handled through different coupling modesranging from uncoupled (a single author working on a document) to loosely (authorscollaborating) and tightly coupled (authors seeing each others’ updates as they aremade) modes. Coupling modes for documents are changed automatically as more orless authors work on a document. An extension to SEPIA, DOLPHIN [72, 92] was cre-ated to support activities around (possibly distributed) meetings, such as pre-meetingplanning, submittal of material to be a part of the meeting, as well as discussions, brainstorming, and decision making. Collaboration could take place distributed, or local,using technologies such as LiveBoards (large touch sensitive displays) as whiteboards.

Among the open hypermedia systems, the collaborative aspects of HyperDisco hasbeen described above (Section 4.3.4). Also the Devise Hypermedia has, in some of itsincarnations [49, 50], supported collaboration. Webvise is also used in the Manufaktur

4.6. HYPERMEDIA: CONCLUDING REMARKS 35

system [22, 79], a collaborative system which uses a spatial metaphor for arrangingand organising documents and other computer artefacts in 3D.

Some aspects of collaboration are more easily accommodated by monolithic hyper-media systems. Most collaborative hypermedia systems have centred around authoring,not only of hypermedia structures (the Arakne Environment handles for instance onlythis kind of collaboration), but also documents. In monolithic systems, the documentsare under the complete control of the hypermedia system, thus facilitating easier moni-toring of changes, and enabling the possibility of locking parts of documents. The mainapproach to collaboration in the Arakne Environment, apart from sessions and sharedawareness (described more fully in [15] [P4] (Section 6.4)), is the notion of collaborat-ing through the annotation and structuring of shared artefacts, in this case Web pages.By such an approach, users can build a shared understanding of a problem area, just asthey built an understanding by constructing a 3D world of documents in Manufaktur.

4.6 Hypermedia: Concluding Remarks

The field of hypermedia research encompasses much more that has been covered in theprevious sections. The purpose has been to show the shift from monolithic hyperme-dia systems to open hypermedia systems, to discuss some of the systems and activitiesundertaken by people in the open hypermedia field, and finally to touch upon the col-laborative aspects of hypermedia. Hypermedia research, in one form or another, is verymuch alive today, as witnessed by the solid participation in the Hypertext conferences.There is much interesting work being done, however in this chapter I have only beenable to touch upon that which has had direct relevance upon my work.

The field of CSCW is likewise an active field. While my work has concentratedpredominantly on hypermedia; some CSCW aspects, especially shared awareness, hascontributed to my work.

Open hypermedia as such has been my tool of choice throughout my work. Thearea where I have employed this tool is the Web, and therefore a description of the Webas well as some related areas is in order.

4.7 A Brief History of the Web

The Web emerged in the beginning of the nineties [14]. It was developed by TimBerners-Lee at the European centre for high energy physics CERN in Geneva. It wasconceived as a technology that would allow visiting physicists to remain “connected” tothe experiments in which they had participated at CERN, usingoneprogram rather thanmany heterogeneous programs (telnet , gopher , ftp , etc.). Arguably the maininnovation was the Uniform Resource Locator (URL), which elegantly combined thevarious Internet protocols with machine names and the hierarchical Unix file system4

as seen in Figure 4.4. By using URLs it became possible to uniquely identify anythingaccessible on the Internet.

Another, not as innovative but still essential, part of the WWW was the HyperTextMarkup Language (HTML). HTML allowed users to markup their documents to somedegree and to insert URL links into these HTML pages. Finally, the WWW needed a

4The last part of the URL is usually based on a file system, but may in fact be any string to uniquelyidentify a resource.

36 CHAPTER 4. HYPERMEDIA AND THE WEB

protocol︷︸︸︷ftp ://

machine︷ ︸︸ ︷ftp.daimi.au.dk /

file︷ ︸︸ ︷∼bouvin/Arakne/readme.txt

Figure 4.4: The Uniform Resource Locator

transfer protocol, i.e. the HyperText Transfer Protocol (HTTP), which at the time5 wasa simple stateless file transfer protocol. HTTP was created as the overhead involved inestablishing a FTP connection was too great, especially as most Web use need manyconnections created and destroyed over ordinary browsing.

The Web was originally conceived as collaborative, and the first graphical Webbrowser developed by Berners-Lee for the NeXT was a browser/editor [13]. Thisbrowser however never gained popularity and was soon overtaken by the NCSA Mo-saic browse-only browser, which since has morphed into the Netscape and Microsoftbrowsers.

The Mosaic browser was easy to use, ran on many platforms (the author used Mo-saic extensively for the first time in CERN in 1993), and was free. “The Internet”,which until then had been the realm of academics and specialists, suddenly becameusable for most people and it also became easier to publish material on what now was“the Web”. This effect snowballed as few things have snowballed before, and leavesus today less than a decade later with millions of Web users with access to approxi-mately one billion Web pages, and where the average Westerner daily is bombardedwith URLs for additional information and commercials. The Internet is no longer therealm of the professional — it has become a truly global information space.

What constitutes the success of the Web, that it has succeeded where other publicinformation systems failed? Some of the more important factors contributing to theWeb’s success were:

• Simplicity

• Freely available standards and software

• Decentralised architecture

• Scalability

• “Real” documents6

These are in essence the characteristics and strengths of the Internet itself, and byleveraging these strengths, and by admittedly having the right technology at the righttime, the Web became huge.

4.7.1 Hyper-G

The Web did not rise to sovereignty unchallenged. Inspired by the early Web, the re-searchers at Graz University in Austria created the Hyper-G (later HyperWave ) systemhttp://www.hyperwave.com/

[9, 75]. Though very similar in some aspects (both used e.g. tagged ASCII almost com-patible document formats), the Hyper-G system also provided some advanced func-tionality of its own. These included hierarchical navigational structures, and built-inmultiple language support.

5It has since become much more complicated — the current specification is∼150 pages long.6As opposed to Teletext or Gopher.

4.7. A BRIEF HISTORY OF THE WEB 37

Web Client

Web Proxy

Web Server

request

request

response

response

Figure 4.5: The General Web Architecture

In many ways Hyper-G was technologically superior to the Web. Hyper-G offered(automatically) indexed document collections, that could be shared and combined arbi-trarily. The collections could be distributed and replicated automatically. Using the ap-propriate clients, users could create bidirectional point-to-point links, that were storedoutside of the linked documents. Hyper-G was multi-protocol, as it could interface toGopher and Web clients. And yet, it did not replace the Web.

Several reasons for this can be found. One of the selling arguments of Hyper-Gwas that it made Web sites easier to administer, as the system handled documents, andupdated links etc. if documents were moved. This is certainly a valuable service, anda necessity as Web sites grow large. However, when faced with this problem, the com-mon solution (and by far the most widespread today on the Web) was to use “real”databases to form the backend of the system. This is not a dedicated hypermedia sys-tem, but offers most of the advantages with regards to ease of administration, and hasbeen shown to scale well. Another problem with Hyper-G was the need for proprietaryclients. While Hyper-G offered a Web interface, the full benefits of the system couldonly be reaped through the Hyper-G clients. At the point of introduction (1995), theNetscape Navigator was the dominant browser with more (visual) bells and whistlesthan the Hyper-G clients. In essence, the history of Hyper-G illustrates one of thelessons of open hypermedia — that is hard to get people to cross over and abandontheir favourite tools.

4.7.2 The Semantic Web?

A much heralded theme of recent Web conferences has been the “Semantic Web”, afuture where meta-data of various sorts will optimise the way, humans use the Web byallowing us to find what we want faster by having machines infer relationships betweendocuments. Technologies to support this include RDF (Resource Description Frame-work) [70], a XML based meta data format. A RDF document basically consists ofstatements in the form of three-tupels, consisting of a resource (identified with a URI),a property type (an attribute of the resource, such as ’author’), and a value (such as’John Doe’). A statement can itself be a resource for another statement, such that state-ments become nested. RDF is a relatively new standard and is yet to see widespreaduse. While not yet implemented, the RDF interest group states querying and searchingas future work. To support different meta data standards, RDF supports XML NameSpaces, so that e.g. the Dublin Core can be represented in RDF. http://purl.oclc.org/dc

The vision of meta data and specifically RDF on the Web is that the future Web

38 CHAPTER 4. HYPERMEDIA AND THE WEB

would consist of not only Web sites with ordinary Web pages, but also collections ofmeta data making statements about these Web pages. This presumably rich meta datacould then be used for queries and inference. A basic problem with this scenario, aproblem shared with hypermedia in general, is that this meta data must be generatedby someone. Some discussions have involved automatically generating meta data fromWeb pages, but such meta data would not contain more information than the originatingWeb pages. Not only must meaningful meta data be created, a difficult task in itself,but if it is to be used for machine inference, the specification schemes must be fol-lowed fairly accurately. Taking the current Web’s relaxed relationship to, say, HTMLstandards, this seems a bit optimistic. There can be no question that meta data worksexcellent in e.g. library settings, where index cards etc. are produced by trusted pro-fessionals in an established fashion, but as Web search engines research shows, peoplein general cannot be trusted to describe their Web sites truthfully7.

The problem of getting someone to author the meta data is, as mentioned above,also shared by hypermedia. Someone has to author the links. However, links (or otherhypermedia structures) in general arehumanassociations accessed by other humans,not building blocks to be used by computers, and humans are generally better to siftinformation out of even questionable associations.

The general semantic Web seems at this point unlikely, if nothing else, just becauseit expects the authors of the Web to adhere to shared encoding standards in the descrip-tion of their pages. Data warehousing is the difficult field of combining the informationsystems used by a large company into one system. This turns out to be a very difficultproblem in practice, even within just one company, given the different focus of differ-ent communities of use within the organisation. Data warehousing the meta data of theWeb will be much, much worse.

4.7.3 Collaboration on the Web

Due to its pliable architecture, the Web forms the infrastructure for many kinds ofapplications, not least the support for collaboration. Collaboration on the Web takesmany forms — from classical CSCW applications such as BSCW [12] to link recom-mendation and discussion forums such as Slashdot . The former is a system to supporthttp://slashdot.org/

document sharing and authoring, as well as discussions. The latter has become quitesuccessful and has spawned many similar sites, as the software driving the site is opensource. The readers of the site contribute links to interesting articles or other newswor-thy items on the Web; the editors of the site publish some of these link on the frontpage of the site, and the news item then forms the starting point for an (at times) ani-mated discussion between the readers. To help improve the quality of the discussion,the postings by readers are scored by moderators. Moderators are not editors per se— they are ordinary readers that have previously posted good material on the boards(and have thus received a high score from other moderators). To keep the moderationfair, the rest of the readers can rate the moderation itself, thus directing the work of themoderators (of which there are several thousands). There are two advantages to thesekinds of sites, that greatly increases the usability of the Web. The sites are usuallyfairly specialised in scope, and given the large readership (and hence the large numberof contributions), a site summarises most of the interesting events within a particular

7Panel on search engines at Digital Libraries 1998 in Pittsburgh, USA. HTML already supports meta datain the<head> tag, but this is, according to the panel, largely ignored by search engines. The problem is thatthis meta data is often used for “keyword spamming”, where the meta data field is filled by words unrelatedto the page itself in the hope of getting a higher ranking in (perhaps quite unrelated) search results.

4.8. WWW, OR WHAT IS WRONG WITH THE WEB? 39

field. Furthermore the discussions following the news item will often provide insightsand pointers otherwise difficult to obtain. In short, these sites allow the individual userto benefit from the collective knowledge, Web browsing, and standards of the commu-nity. Some sites, such as kuro5hin have even done away with the editor concept, sohttp://www.kuro5hin.org/

that the selection of newsworthy items among the contributions is carried out by thereaders. By the readers, and for the readers.

These kinds of Web sites highlight what is possible with the pliable architectureof the Web. While well suited for discussions, they do not address other collaborativeefforts, such as authoring.

4.7.4 WebDAV

Another example of support for collaborative work (and one closer related to the CSCWfield) is Web Distributed Authoring and Versioning, WebDAV [98]. As mentioned inhttp://www.webdav.org/

section 4.7, the Web was originally by Tim Berners-Lee conceived as a read/writeenvironment, where the interaction with the Web took place in a browser-editor. Tosupport this functionality, the HTTP protocol has long provided theput operation.Unfortunately, this has not found widespread use — the author is aware of but oneeditor-browser, Amaya, which uses it, and hence Web server support is also scarce.http://www.w3.org/Amaya/

One problem withput is that there is no provisions against overwrites, as documentscannot be locked, and given the arbitrary large size of Web pages, an optimistic con-currency approach as in KMS [1] seems overly optimistic. WebDAV addresses this byextending the HTTP protocol, and introducing locks on Web resources. Furthermore itis also possible to store information about resources (or more precisely, about URIs).Versioning is not (yet) a part of the WebDAV standard, but the∆V [36] group is ex-pected to finish their work in year 2000. Compared to more ambitious collaborativeauthoring systems, the WebDAV standard is somewhat modest, as it is only possible tolock whole resources, not parts of a resource. Rather than a weakness, this can actuallybe seen as a strength — WebDAV is format agnostic, and can thus be much simpler toimplement than a system that has to be able to handle the internals of diverse documentformats, and presumably be updated as new document formats are released.

Apart from direct collaborative authoring of documents, WebDAV enabled Webservers opens some interesting possibilities as remote repositories. The Webvise client[54] is able to export hypermedia structures into interchange files and store these onWebDAV enabled Web servers. These files can then easily be accessed by anybodywith Web access.

4.8 WWW, or What is Wrong with the Web?

The Web is hugely successful and must clearly be doing something right, as has beendescribed in Section 4.7. However the Web could be more than it has become, and thissection outlines some of the shortcomings of the current Web.

The greatest immediate shortcoming of the Web from a hypermedia standpoint isthe linking model. Links on the Web have a number of constraining characteristics:

• Inline

• Author only linking

• Unidirectional

40 CHAPTER 4. HYPERMEDIA AND THE WEB

• one-ary

• Untyped

• One set of links per document

• URLs are physical adresses, rather than symbolic names

The main problem is that links are inlined in HTML documents, and this is thecause of most of the other problems. The Web link is in essence little more than a gotoor a jump instruction to the Web browser to retrieve and display a new document (andin this sense quite similar to KMS [1]). The owner of a Web page is the only one whocan create links or named regions in a page. As links are unidirectional, there is no wayof telling whether there are links pointing to a given page or resource8. It is not possibleto have more than one destination per link, nor can one distinguish between differentkinds of links9, such as annotations, references, etc. With thetarget attribute in the<a tag, it became possible to signify some link behaviour as the destination documentcan be displayed in an existing frame or in a new window, but it is e.g. not possible tolet a link be replaced by the document that it points to. Some of these points are minor,but the perhaps most serious consequence of the inline linking model is that there canbe only one set of links per document. This is a drawback as it limits the possible usesof a Web page. If it was possible to have multiple sets of links to a given page, thispage could be reused in other contexts without any modifications to the page. It woulde.g. be possible to publish a technical specification, the specification with annotations,the specification with links to source code implementing it, etc., without changing thespecification document into multiple (slightly different) copies. Ignoring for a momenttemporarily unavailable Web servers, link rot is a reoccuring annoyance on the Web.This often happens when authors or maintainers of Web pages decide to reorganiseor move their Web pages. This will break links relying on the previous organisation.Partly, this problem also can be blamed on the inline link (it certainly does not lessenthe problem). Maintainers of Web pages have no way of knowing or anticipating theuse that others put their pages to. Thus, maintainers cannot know if moving a documentwill have an impact on other Web pages. The arbitrary reorganisation of Web pageswould be a smaller problem, if URLs were not used aslocationspecifiers — the URLhas been likened to finding a book in a large library with directions like “twentiethbook on the third shelf on the seventh row on the first floor”. If the books are movedaround, the desired book can no longer be located. Similarly, if a file is moved to a newdirectory, a URL previously pointing to it becomes useless.

The Web is a monolithic hypermedia system, and could therefore be expected tobe criticised for the problems associated with other monolithic hypermedia systems,such as closedness, the lack of third-party application etc. In the case of the Web, thiscritique does not have much merit, as the Web has succeed, where the other systemsdid not. The computing world has become Web enabled, and many program are ableto work with the Web one way or another.

It should be made clear, that while the Web has a problematic linking model, thissimple model is also what has made the huge scale of the Web possible. While certainlynot perfect, it works surprisingly well, but as previous sections has outlined, there arescenarios where more elaborate structuring mechanisms become desirable. Thus, formany purposes, the Web suffices, and for the rest Web augmentation can play a part.

8Save by using a brute force method such as indexingall Web pages.9It should be noted that the current HTML specification actually allows for some limited link typing, but

it is under specified and has not, to the author’s knowledge, been implemented in any Web browser.

4.9. SUMMARY 41

4.9 Summary

This chapter has provided a non-exhaustive overview of the fields, I have based mywork on. Largely, my project of Web augmentation can be seen as extending the expe-riences of open hypermedia to the Web. The hypermedia research community has in itsmore than fifty years long history developed many exciting and useful ideas, systemsand structuring mechanisms, and it would be a pity if this was not made available forthe Web. The Web itself is a fascinating entity with its simple and immensely flexiblearchitecture and the many different related technologies, many of which are still emerg-ing. Apart from the systems already described, there are other systems, described inthe following chapter, that seek to augment the functionality of the Web.

42 CHAPTER 4. HYPERMEDIA AND THE WEB

Chapter 5

Related Work

In [17] [P1], I described many Web augmentation tools. In the interim some new toolsand technologies have emerged or matured, and this chapter describes some of them.Broadly, they can be divided into two groups: XLink (and related technologies) andpersonal tools aimed squarely at the Internet Explorer.

5.1 XLink

XLink1 [37] is a W3C initiative to extend the linking capabilities of the Web. XLink isa general XML format to describe navigational hypermedia, and to allow expressionsof navigational hypermedia to be inserted into XML documents. While the main appli-cation of XLink is expected to be linking within XML documents, the standard itselfis not limited to address solely XML locations, provided that appropriate locators havebeen defined. XLink can support the linking currently found on the Web (e.g. unidirec-tional one-ary untyped links), as well as bi-directionaln-ary typed links. Links can bestored externally (“out-of-line”) of the documents, they address, or they can be in-line(as with HTML documents). Traversal of a link may result in replacing the documentcurrently viewed (as is the standard behaviour in the context of HTML), or by insertingthe target for the link in the viewed document. The traversal may be initiated by theuser (e.g. by clicking on a link), or at the time of document retrieval.

XPointer [30] is used to identify regions of interest in XML documents. XPointerallows for selection based on ids, hierarchical structure (from XPath [27]), or an ar-bitrary user selection (e.g. selecting a string in the rendered XML document). Thisis a quite sophisticated addressing scheme that should cover most uses. XPointer canaddress arbitrary XML documents, but the explicit support for XPointer can also beadded to a DTD. A given region may be identified using several locators, which im-proves reliability, as one locator might fail after a document has been edited.

XLink holds great potential. At this point it is still too early to discern whether itwill hold, but if it does, it holds interesting prospects for the future of the Web. In arealised XLink future, complex linking structures are routinely stored outside of Webresources, immediately available for the users of the Web. In such a scenario, therewill of course still be open hypermedia research (operating system research did notcease because of Microsoft Windows). Indeed, just as the Web made “hypermedia”

1Parts of this section is taken from my contribution to [55].

43

44 CHAPTER 5. RELATED WORK

a widely understood term, XLink may have the same result on externally stored hy-permedia structures. XLink is a very new technology, and so far there are only a fewsystems providing XLink functionality. Presumably this can be expected to change. Asit currently stands, XLink is predominately biased towards navigational hypermedia2,and while much hypermedia can be modelled in terms of links it has long since beenestablished at least in the OHSWG community that this is unnecessarily cumbersomefor hypermedia constructs such as guided tours, compositional, taxonomic, or spatialhypermedia. Still, XLink is a good starting point. Currently XLink is mainly an inter-change format — there are no standards for interaction between XLink applications orXLink queries. Through XPointer and XPath, XLink is supremely well suited for link-ing XML documents. It is however completely feasible to write locator (or LocSpec inOHSWG parlance) specifications for non XML documents, e.g. images [64].

5.2 Internet Explorer Add-ons

A new form of Web augmentation tools has emerged since [17] [P1] — the specialisedInternet Explorer add-ons. The Internet Explorer lends itself supremely well to thiskind of integration, as it is a COM (Component Object Model) component and has anexcellent interface3 for accessing the Document Object Model of the displayed doc-ument. Functionally most of these new tools integrate themselves directly into theInternet Explorer interface by added a new tool bar or menu.

The tools described in this section are commercial, and as such have to generaterevenue for their companies. The approaches taken by their respective owners are in-teresting and in some ways similar. Flyswat and Third Voice both generate what areessential generic links by highlighting key phrases in the displayed document. Theselinks will typically contain links to sites related to the phrase and, noteworthy in thiscontext, commercial ventures — e.g. the phrase “Pokémon” or “Pikachu” will havelinks to sites where this merchandise may be purchased. Flyswat directly offers part-nerships with companies, so that they can make their services directly available to usersthrough the Flyswat service. Both the Flyswat and the Third Voice clients are free,and presumably generate their revenue from the “product placement” partnerships. Incontrast, iMarkup, which seems to have a different marketing plan, currently chargesmoney for their clients and their servers.

This is perhaps not exactly what Bush had in mind, when he wrote of trail blazers.It seems, at least to the hopeful author, that there may be room for both kinds of activityon the Web. The in some circles much lamented commercialisation of the Internet hasin retrospect had many benefits, as it by the economy of scale has made the Internetavailable to the “non-technical” population. Just as the Web made hypermedia acces-sible to everybody4, these kind of tools can perpetrate the idea of adding another layerof information on top of existing Web pages. iMarkup is in this context interesting astheir aim, apart from the individual markup of pages for personal use, is to providegroups and organisations with shared annotations. This is an daring endeavour, andwhether their business plan will translate in profitability remains to be seen. As such

2It should be noted however that according to Steve DeRose and Lloyd Rutledge (both participants in theXLink authoring process) that the term “link” in the XLink standard document should be read as “relation-ship” (private communication).

3This interface is also the reason why the Arakne Environment at an early date changed from the NetscapeCommunicator to the Microsoft Internet Explorer. The difference in interface richness is dramatic.

4In the so called Western World, that is. The “digital divide” between the Western World and the rest ofthe Earth remains very much in place.

5.2. INTERNET EXPLORER ADD-ONS 45

these companies’ fate can be quite crucial as their products are not too dissimilar from“real” open hypermedia systems integrating the Web, or indeed open hypermedia ingeneral. If they succeed, so may we. One item of concern is that iMarkup and Fly-swat both announce on their Web sites that they have secured or are in the process ofsecuring patents on their respective “key technologies”, though exactly what entails re-mains unclear. Whether this will have implications for hypermedia research is an openquestion.

5.2.1 Flyswat

Flyswat is an ActiveX component integrated with the Windows operating system.http://www.flyswat.com/

When enabled, it highlights keywords on Web pages displayed in the Internet Explorer,so that a click on the keywords can lead to a definition of the word, the Web site as-sociated with the term, or a page where the item may be purchased. The Flyswatfunctionality is not limited to the Internet Explorer (though markup is found only inthe Internet Explorer) — a Alt-Click on any word in a Windows application will resultin a lookup. The effectiveness of Flyswat greatly depends on whether a given subjectis covered by the Flyswat company or any of the associated partners. There does notseem to be any possibility of submitting links or keywords to the service, outside ofbecoming an associated partner with Flyswat.

Figure 5.1: The iMarkup Application (fromhttp://www.imarkup.com/ )

46 CHAPTER 5. RELATED WORK

5.2.2 iMarkup

iMarkup is another add-on to the Microsoft Internet Explorer. It provides the userhttp://www.imarkup.com/

with the ability to interactively markup Web pages with highlighting, annotations, andfreehand drawings. The marked up pages are stored locally, but can be sent to othersusing email or ICQ (a popular Internet instant messaging service). iMarkup is closelyintegrated into the Internet Explorer’s interface, as seen in Figure 5.1, where iMarkupresides in the leftside of the window.

The iMarkup is now also available distributed. By adding an iMarkup Group serverto a Microsoft IIS Web server, groups can access shared annotations. The server is acommercial product and the license fee depends on the number of users.

Given its proprietary nature, it is unclear from the company’s documentation, howthe markup is achieved and how markup is localised in conjunction with the rest ofa Web page. According to the company’s Web site, iMarkup employs patent pendingtechniques. However, it is most likely that the system utilises the same techniquesas Webvise and Arakne Environment, that is accessing and manipulating the DOM(Document Object Model, a hierarchal model of a Web page) of a Web pages to addnew content.

5.2.3 Third Voice

Third Voice is an add-on to the Microsoft Internet Explorer. Originally, Third Voicehttp://www.thirdvoice.com/

offered users the ability to annotate Web pages with “sticky notes”, very much likeiMarkup. However in the latest version, this has changed radically. Third Voice nowoffers services similar to Flyswat, including the partnership model. Additionally usersof the service can discuss Web pages or topics in boards provided by Third Voice.

5.3 Summary

The different directions taken by the above described systems are interesting. XLinkis an attempt to provide good general navigational hypermedia for especially but notonly XML documents. It takes its outset in defining open standards, which develop-ers are free to adopt. Once the different standards have settled, implementations willhopefully follow. At the other side of the spectrum, we find commercial tools, whichoffer services today, but does so with closed, indeed sometimes “patent pending”, stan-dards. I can only wish these companies luck in their bold ventures, but from an openhypermedia standpoint, I hope that open technologies such as XLink will prevail, orthat these companies eventually will make their systems open for others.

Chapter 6

Contributions

This chapter presents the main results of my Ph.D. project. My method of work hasbeen that of experimental computer science, where theories and concepts are validatedthrough implementation of prototypes. My starting point has been the concept of Webaugmentation, and through theory building of conceptual frameworks and the imple-mentation of prototypes I have examined this topic. This work is reflected in the fol-lowing papers.

6.1 [P1]: Unifying Strategies for Web Augmentation

Web augmentation tools has been a recurring theme of this text. Such tools are availablein many different forms, and the Arakne Framework seen in Figure 6.1 is an attempt tounify the various approaches taken by these tools. This has been documented in [17][P1], presented at Hypertext 1999 in Darmstadt, Germany.

Structure layer

StructureServer

HyperStore

Operations

Navlet Bean 1 Navlet Bean 2

Proxy

Web Server

HTTP

WebBrowser

HyperstructureStore

Browser

HTTP

OHP

Service layer

Content layer

Arakne

StructureServer

HyperStore

Figure 6.1: The Arakne Framework

47

48 CHAPTER 6. CONTRIBUTIONS

One of the basic problems of Web augmentation is to maintain control over theWeb pages and the Web browser as described in Section 4.3.9. In general Web aug-mentation tool developers wish their tool be remain active and relevant to what the useris doing with the Web. Thus, the system must be kept aware of what Web page is beingdisplayed, and may also need some way of modifying the contents of the current Webpage. These seemingly simple requirements have not been without some difficultiesduring the progression of the Web and the dominant Web browsers.

The Arakne Framework can be seen in Figure 6.1. It was based on the analysis ofmany, quite different, Web augmentation tools, and models such tools by identifyingthe necessary constituent components and their interactions. A Web augmentation toolneeds an interface so the user can interact with it; it must know which Web page is beingdisplayed; it needs to retrieve the information pertinent to the Web page in question;and if such information exists, it may need to modify the Web page. These tasks arereflected in the Arakne Framework. The Arakne Framework can be used to modelarbitrary Web augmentation tools, and some examples of this are given in the paper.

The Arakne Environment, presented for the first time in [17] [P1], followed theArakne Framework. One of the purposes of the Arakne Environment has been to imple-ment the components used by Web augmentation tools, so that prospective developerscan concentrate on the more interesting task of developing their tool’s core function-ality. As such, the Arakne Environment supports an open set of Web augmentationtools. The development leading to the current version of the Arakne Environment isdescribed in more detail in Section 6.6.3 and Chapter 7.

6.2 [P2]: Opening Temporal Media for Web Augmen-tation

The Web is more than HTML pages. As the common Internet connection becomesfaster, other media types, such as audio or video, become more widespread. In order todemonstrate that the open hypermedia Web augmentation approach could be extendedto more than HTML, the Coconut project set out to create a hypermedia integrationof video files with Arakne. This work has been documented in [20] [P2], presented atWWW9 in Toronto, Canada.

At the time of development, we were faced with the recurring problem of open hy-permedia: Content handlers that could not be sufficiently integrated for our purposes.We could do “launch only” integrations, but this is also possible with ordinary Weblinks, and would thus be a rather pointless exercise. We therefore resolved to createour own media player, which was to mimic the media player used by the Web browser,hence the name Mimicry. While not trivial, the task of creating this media player wasgreatly helped by the Java Media Framework, which is able to handle a rich set of time-http://java.sun.com/

products/java-media/jmf/ based media types. At the point of creation, the Arakne Environment did not do its ownlink decoration, as we had yet to implement the full Internet Explorer integration. Webpage modifications were handled by the DHMProxy [56], which in this case identifiedembedded media clips (identified by<embed> or <object> tags) of the types han-dled by Mimicry, and rewrote these to<applet> tags, invoking the Mimicry applet toplay the media file, as well as specifying the anchors, if any, in the media clip. Throughthis technique, the normal media players or plug-ins were circumvented, and we had amedia player with a much richer programming interface. Through integration with thenavigational view Navette in the Arakne Environment, it was thus possible for users to

6.3. [P3]: THE ARAKNE ENVIRONMENT AND THE FUTURE OF OHSWG 49

author links with anchors in ordinary HTML pages as well as in media clips as seenin Figure 6.2. The general architecture of the Arakne Environment at this time can beseen in Figure 6.3.

Begin Anchor

Play

Play Anchor

Follow Link

Create Anchor

End Anchor

Figure 6.2: Mimicry playing the endpoint ’Endpoint 14’

Mimicry was largely an experiment, and has not received much development since.At the point of development, the Java Media Framework did not support streamingmedia. This has been corrected in later releases. Today, the situation is however slightlydifferent, as at least the Microsoft Media Player has a sufficient interface to supportopen hypermedia needs (and has e.g. been integrated with Webvise), so the need forour own media player may no longer exist. A problem of the temporal media typesis that they often rely on proprietary formats and players, which makes an integrationmore difficult. This is of course nothing new in the context of open hypermedia.

Apart from illustrating that Web augmentation is not limited to HTML pages, themain contribution of the paper is the identification of the problematic closed nature ofplug-ins and other media handlers. Not only does this make life more difficult for openhypermedia people (admittedly a minor concern for the developers of these programs),it also makes it more difficult for “normal” Web authors to utilise such media in creativeways.

6.3 [P3]: The Arakne Environment and the future ofOHSWG

The experience of porting Arakne to Construct, or more generally to OHP is docu-mented in [19] [P3].

The Arakne Environment originally relied on the DHM hypermedia servers. As theCoconut project progressed, and the Construct servers matured, it was a natural step to

50 CHAPTER 6. CONTRIBUTIONS

Browser

Structurelayer

Operations

Navette Ariadne

DHMProxy

Web Server

HTTP

Hyperstructure Store

HTTP

OHP

Servicelayer

Contentlayer

Arakne Environment

Structure Server

Structure Server

HyperStore DBMS

Mimicry Controller

Mimicry Controller

Web Browser

OHP

Figure 6.3: The Arakne Environment with Mimicry

move from DHM to Construct. This would provide Construct with a client for testingpurposes, and provide the Arakne Environment with the richer functionality, especiallywith regards to collaboration, of Construct.

The move to Construct was accomplished in two steps. Version 2.0 of Arakne wasthe first to utilise Construct, and did so by essentially wrapping Construct. This wasdone for two main reasons: Firstly to make a speedy transition, and secondly to isolatethe views from the changes made in the backend.

At the time of this first step, the Arakne Environment was organised as seen in Fig-ure 6.3. While the Internet Explorer could be controlled from the Arakne Environment(for purposes such as reloading pages), link decoration was still handled by the DHM-Proxy. The views in the Arakne Environment provided the GUI for creation of linksand guided tours, and interfaced to the “Hyperstructure Store”1 for the required func-tionality to create these structures at the hypermedia server. As one of the priorities ofthe first transition was not to break existing views, the interface from the Hyperstruc-ture Store to the views was retained. To fit within Construct, the Hyperstructure Storeand its associated data model was drastically changed. The data model was changed,so that each class (such as Link or Anchor) became wrapper classes for the matchingConstruct classes. While tedious work, this was fairly simple, especially as Constructlike Arakne is written in Java. While this first integration made the creation of links andguided tours possible, the more advanced features of Construct, such as collaborationsupport through sessions was still not available. We therefore resolved to make Araknea native Construct client. This required a more elaborate redesign to accommodate theConstruct data model and to handle sessions correctly. This new architecture, which isthe current one, is described in more detail in Section 6.6.3.

Having ported Arakne to OHP, it was time to take a step back, and consider OHP.It has many good points, and is a very advanced hypermedia architecture. It is also anopen standard, yet there has to this date been zero migration to it outside of OHSWG.This led to some considerations about OHSWG and the nature of standardisation.

1Note: Store as in “convenience store”, not as in “storage”.

6.3. [P3]: THE ARAKNE ENVIRONMENT AND THE FUTURE OF OHSWG 51

Over the years, OHSWG has held demos at the Hypertext conferences to demon-strate the advances made by the group with regards to interoperation and collaborationsupport. Up to these events the participating parties has more often than not beenfeverishly working to correlate their almost but not quite compatible implementationsof OHP. Thus, even within OHSWG itself, the OHP standard is not clear. OHP iscurrently defined de rigueur if not de facto by the “Darmstadt DTD”, which specifiesthe protocol and data model in an XML DTD (Document Type Definition). DTDs aresuited for specifying syntax, but not semantics. Thus, a lot of the specification is notin the DTD, but is essential left to the implementor. Currently the only complete im-plementation of OHP is Construct, and there has invariably during the implementationof this architecture been made deviations from the OHP standard. This is to be ex-pected, as implementation is one of the better ways to evaluate standards. However,for future purposes and for the cause of OHSWG, one implementation of OHP is notenough. It is unlikely that Construct can cater to all needs and it is more than likely thatidiosyncracies of the Construct will remain undetected unless they are verified againstan independent implementation. So, if the goal is to make OHP more widely acceptedand employed, we must consider the means.

One obvious lack of OHP today is that it is underspecified. One DTD does nota standard make, and given that Construct demonstrates that OHP can survive imple-mentation, the time has come to create a more substantial standards documentation. Tothis end, a DTD is unsuitable, because it is too unclear on semantics, while being toolow level. A good specification should not tie itself to one transport protocol, such asXML over sockets. I participated in decision to recommended that XML should beused over sockets for the entry-level implementations, while CORBA should be usedfor more ambitious implementations. This decision was perhaps in retrospect suspect,but it made sense at the time. XML was widely supported on many language platforms,it was easy to debug, as it was human readable, and it would lend itself readily to e.g.an interchange format. A major consideration was also the decision not to bind our-selves to one particular platform (language or otherwise), such as DCOM which eventoday is predominantly a Microsoft platform, or CORBA, which at the time was notfreely available. The downside to XML became clearer as the various implementationsprogressed, as there were no tools to unambiguously generate skeleton source codefrom a specification, as is possible with e.g. IDL (Interface Description Language).This led to the problems with interoperability described above. Today the situation haschanged. CORBA is now more widely supported, and another interesting developmentis the CSC tools developed at Aalborg University Esbjerg [105]. Based on an IDL orUML (Unified Modelling Language) specification, these tools generate skeleton codefor Construct services. The transport layer is independent of the IDL specification,which rightfully becomes the main focus. These tools are a step in the right direc-tion. Future work for the OHSWG will be to create a proper standards based on higherlevel transport agnostic specifications of both data model and semantics with a clearmapping from specification to implementation. CSC provides one such mapping, andI have volunteered to coordinate the writing of an OHP standard — a task I expect tocommence this autumn.

The contributions of this paper are firstly an discussion of how a hypermedia clientcan be ported from one hypermedia system to another with special focus on the trade-offs involved. Secondly, it also contributes to the on-going discussion within theOHSWG to further the state of open hypermedia.

52 CHAPTER 6. CONTRIBUTIONS

6.4 [P4]: The Collaborative Arakne Environment

Support for collaborative hypermedia authoring became a priority in Arakne Environ-ment with the introduction of the Construct servers. The work to support collaborativework in Arakne is documented in [18], presented at Hypertext 2000 in San Antonio,USA and in the yet unpublished [15] [P4].

For a more general discussion of CSCW, see Section 4.5. The basic notion of col-laboration in the Arakne Environment was present before the move to the Constructservers (see Section 4.3.7), which supports collaboration explicitly. The previous ver-sions still allowed people collaborate implicitly through the annotation of Web pageswith notes or links. With the move to the Construct servers, it became possible to takethis collaboration to Arakne itself, and how this was accomplished is the topic of thispaper.

OHP and thus Construct handles collaboration through sessions. A session is de-fined by a coupling mode, a set of users, a set of tools, and a set of documents. Of thesethe coupling mode is the most interesting. The coupling mode defines the visibilityof each users’ actions. The current version of the Arakne Environment supports threecoupling modes: Uncoupled, loosely, and tightly. The difference between these cou-pling modes lies in the frequency with which updates are broadcast to other membersof the session. In the uncoupled mode, there is no broadcast at all, and in the tightlycoupled mode, all changes are broadcast.

To supplement the coupling modes, OHP also supports subscriptions on OHP events.This allows a user to for instance be alerted, when John creates a link, but not whenJim does.

To accommodate this new functionality without disrupting the existing user inter-face too much, an attempt was taken to make it possible to collaborate without having tofocus on the collaborative parts of the interface, such as the Session Manager. This wasaccomplished to a degree, where a user need only use the Session Manager for creatingor deleting sessions, but where the switch between active sessions or the awareness ofother users online has been integrated into the user interface. The main interface forkeeping users aware of each others’ actions is a ticker tape, located at the bottom ofthe Arakne Environment (visible in Figure 6.8). This ticker tape displays items suchas the subscriptions described above, as well as monitors users logging in or out of thesystem. It should be noted, that at the time this paper was written (Spring 2000), theArakne Environment had an Internet Relay Chat view, which allowed participants ina session to chat together. Due to problems with the IRC protocol supported by thelibraries used by this view, it is currently not available, though it can be expected to bereinstated, once these bugs have been fixed. Given the automatic upgrade functionalityof the Arakne Environment, such a change will be seamless to the users.

The contributions of this paper is a discussion of how the abovementioned goalsmay be achieved, and how one may use a collaborative framework as the one found inConstruct to facilitate shared awareness.

6.5 [P5]: The iScent Framework

As it stands today, the Arakne Environment sports a nucleus of message notificationthrough the use of a ticker tape. However, much is still lacking before such a messagenotification system can be regarded as truly useful. Firstly, the range of the Arakneticker tape is limited to events taking place within connected OHP compliant clients

6.5. [P5]: THE ISCENT FRAMEWORK 53

— typically other Arakne Environments. Secondly, the information provided in themessages is not very detailed. Thirdly, if a user misses a message as it scrolls by, it islost for good (the object the message was about might still be present, but how wouldthe user know?). Fourthly, while compact and easy to handle, the ticker tape as a toolis fairly limited in what it can actually do (despite the successes of Elvin [41] tickertape).

The original goal of the Arakne ticker tape was to help users stay aware of eachothers’ actions, that is to maintain a shared awareness (for a further description ofsystems supporting shared awareness, see Section 4.5). To further shared awareness2,to address the concerns raised in the previous paragraph, and to design a versatilearchitecture using a message notification system as infrastructure, Kenneth Andersonand I have devised the iScent framework. This work is to be published in [6] [P5].

There are numerous message notification systems available today, both commer-cially and described in the literature (e.g. NSTP [85]). The beauty of these systems arethe publish/subscribe model, where parties can subscribe to message matching certaincriteria, without having to specifying the origin of the desired data. Similarly, otherparties can publish information on the system, knowing that interested parties will getthe data, but without having to establish direct connections with these parties. All rout-ing of messages back and forth between parties is handled by the transport layer, thatis the message notification system.

The iScent framework does not attempt to replace existing message notificationsystems. Rather, it utilises a message notification system (currently Siena [26]) asinfrastructure or backbone. The purpose of the iScent (intersubjectivecollaborativeevent environment) framework is to help people increase intersubjectivity and to aug-ment their (collective) memory through the use of high fidelity persistent events. Inthe extreme case all tools used by a user would be iScent enabled, and then all actionstaken by the user with the computer would generate iScent events. These events wouldbe stored by sinks, and could later be queried and retrieved by the user. The generalarchitecture of iScent can be seen in Figure 6.4. The two kinds of arrows to the ArakneEnvironment illustrates that it is both an iScent aware application (i.e. generates events)and contains the Trail Viewer for visualising trails of events.

The iScent framework is still a work in progress. While the general architectureand protocols are by now stable, the greatest challenge and greatest benefit will be thedevelopment of a powerful client (the “Trail Viewer”), able to allow users to visualiseand structure events, as they see fit.

A novel part of the iScent framework is the introduction of sinks. Rather thanletting events and messages be fleeting things, the sinks storeall iScent events. Sinkscan through subscriptions be setup to store specific events (such that a working groupwould utilise a local sink rather than relying on one further away). At a later point, asink can be queried to return matching iScent events. Off hand, this sounds like theultimate Big Brother scenario. Why is this useful? There are several scenarios, wheresuch a system comes in handy:

Augmented memory Jane recalls she was using a really good resource, when shewas working on the Epsilon project, but where was it? Looking in her calendarto pinpoint when she was involved in the Epsilon project, Jane queries “Docu-mentOpened” events in this interval in the Trail Viewer, and quickly locates therelevant document.

2Or rather reflected awareness (also known asintersubjectivity)

54 CHAPTER 6. CONTRIBUTIONS

Watchdog

Kennel

Sink

Sink

iScent AwareApplication

Trail Viewer

(iScent Aware Application)The Arakne Environment

SinkiScent AwareApplication

EventsSocket

Figure 6.4: The iScent Framework

Discovering relations John is working on the database part of the Phi project, andwhile reading some online Oracle documentation, queries the Trail Viewer tosee who else has read that particular page. Apparently Jane read the same pagesome months previously, and John sends Jane a technical question in an email.

Intersubjectivity Jane is writing some documentation, and would like some feedbackfrom John. After finishing the page, she sticks a watchdog on it, so that she willbe alerted, whenever John reads the page. She then emails John to tell him aboutthe page. Later John gets around to reading the page, and by doing so sets offthe watchdog. He is himself alerted to this, as is Jane. Jane now knows that Johnhas read the page (and John knows he can expect a call from Jane), and can thuscall him to hear his opinion.

With regards to privacy concerns, it is of course crucial that the individual cancontrol what and when to publish events, and this can easily be accommodated in theclient interfaces. As described, the iScent framework could lend itself to abuse by beingused for monitoring, and a model of use, where events belonged to and were controlledby the originator, will have to be implemented. It should be noted that while someactions may be judged private, such as Web browsing, others such as committing a fileinto a CVS repository are public actions. As mentioned in Section 8.3.1, one approachto ensure privacy would be to encrypt all events at the originating machine using theuser’s personal key or keys belonging to projects, in which the user participate.

The main contribution of this paper is the concept of supporting intersubjectivitythrough persistent events and triggers. This is a work still in progress, but the generalarchitecture of iScent seems sound, and could be used in many settings.

6.6. PROTOTYPES 55

6.6 Prototypes

Throughout my Ph.D. I have designed and developed several Web augmentation pro-totypes. This chapter will describe them in turn, briefly beginning with DHM/WWW3,with a special focus on their design, and how the experiences from one design itera-tion helped create the next versions. As is the fate of prototypes, these systems havebeen abandoned as new versions were created, so only the latest version, the ArakneEnvironment 2.1 is publicly available at the author’s Web site . http://www.bouvin.net/

Arakne/The experiences gained and difficulties encountered during development with re-gards to Web browsers and Java are described in Section 7.1 and Section 7.2. Thissection concentrates on the functionality of the prototypes, and the rationale behind thedesign.

Figure 6.5: The DHM/WWW Prototype

6.6.1 DHM/WWW

DHM/WWW [48], shown in Figure 6.5, was a prototype to showcase the possibilitiesof applying open hypermedia to the Web. Functionally, it was a Java applet, and assuch quite easy for the user to start — this only required the user to retrieve a Webpage containing the applet. Once the applet had started, the user could then proceed tobrowse Web pages as before, provided that the user constrained the browsing activitiesto the Web server whence the applet came, did not use bookmarks, and avoided pages

3Strictly speaking, this system is prior to my Ph.D., but it set the course for my work, so I decided toinclude it.

56 CHAPTER 6. CONTRIBUTIONS

with frames. Under these restrictions, the user could create bi-directionaln-ary links,as well as browse existing links. Link creation involved copying and pasting a contextaround the desired endpoint into the selection area and then selecting the endpoint.There was only one collection or hyperspace of links, and no notion of different users.Link decoration was pre-render, and thus fairly slow. The applet ran on all platformssupported by the Netscape Navigator, and used CGI-scripts to communicate with theDHM hypermedia server.

6.6.2 Navette

Navette [16], shown in Figure 6.6, was the first prototype, I created during my Ph.D.It was, just as DHM/WWW, a Java applet. Where DHM/WWW had been in separatewindow, Navette was placed in a frame in the Web browser, as the small DHM/WWWwindow tended to disappear under other windows. To address the limitations of the“Java Sandbox”, Navette was digitally signed, allowing it to access arbitrary Web andhypermedia servers. To increase performance, communication with the hypermediaserver was handled directly through TCP/IP. Link decoration was handled through aproxy thread, as the Netscape browser supported dynamic proxy configuration changesthrough digitally signed Javascript. The newly introduced event model reduced thecomplexity of Web page modification considerably by eliminating the need to modifyevery link, and this coupled with the proxy made link decoration considerably swifter,if not as swift as hoped for. Navette supported multiple users (through not collabo-ration as such) and collections of links. While the event of a user clicking on a link(“onClick ”) could be detected across frame boundaries, and hence by Navette, theact of selecting text (“onSelection ”) could not, regardless of digital signing, solink creation was still a two-step process. Interface wise, the GUI had been brokenup into tabbed panes to maximise the space allotted to its frame. While more robustthan DHM/WWW, Navette was still susceptible to Web pages with frame sets (becausethese frame sets could overwrite the frame Navette resided in, thus terminating theapplet), and the use of bookmarks.

6.6.3 The Arakne Environment

Arakne was my third Web augmentation prototype. Arakne was originally createdto accommodate the two different Java Web augmentation tools developed by the Co-conut project members, Ariadne [66] and Navette. Rather than adding the functionalityof one to the other, it seemed more promising to create a system wherein the tools couldco-exist. There were shared functionality between Ariadne and Navette: Both neededto communicate with a DHM hypermedia server, and both required some control overa Web browser, so this functionality was factored out. The earliest known screen shotof Arakne is seen in Figure 6.7. The screen shot is unique in the sense, that Arakneevidently at this point still was an applet. Soon after, the applet idea was abandoned,and Arakne became an application. There were several reasons for this. Firstly, ap-plications do not have any of the security restrictions imposed on applets; secondly,applications are not as fragile as applets, i.e. applications do not cease to exist, justbecause the user retrieves a new Web page; thirdly, the work on the local proxy hadceased, and instead Arakne employed the DHMProxy [56] for link decoration, remov-ing the link decoration need to tightly manipulate the Web browser. At this point, weswitched from the Netscape Communicator to the Microsoft Internet Explorer. At thispoint, the Internet Explorer had become the dominant Web browser, and it had a rich

6.6. PROTOTYPES 57

Figure 6.6: The Navette Prototype

interface for controlling the browser and manipulating the displayed Web page. Arakneran on Microsoft Java, which supported easy COM communication for control of theWeb browser.

The early versions of Arakne supported navigational hypermedia as before, as wellas guided tours through Ariadne. The DHM hypermedia server supported multipleusers, but had no special provisions for collaboration. As all link decoration was han-dled through the DHMProxy, the task of the Arakne hypermedia tools were limited tohandle authoring and link/guided tour browsing. Communication with the DHMProxywas handled through overloading URLs with instructions to change hyperspace etc.Interface wise, Arakne operated (and still operates) with the MDI (Multiple DocumentInterface) idiom — where the hypermedia tools (“views”) are contained as windowswithin a larger window. As described above it was the experience that small win-dows tended to become hidden behind other windows on the desktop, and the moveof all (small) hypermedia tools into one larger window eliminated this phenomena.The downside was (and still is) that Arakne was fairly large, which could be annoyingon smaller screen. This however is less of a problem that it would have been with aNetscape browser, as the Microsoft Internet Explorer supports the addition of tools inthe context (i.e. right click) menu. By adding the most common operations (such as“Create Link”, “Add Endpoint”, etc.) to this menu, user only need to switch to Araknefor link browsing or other more advanced tasks.

The design of Arakne was based on the Arakne Framework (described in Sec-tion 6.1) with an almost one-to-one mapping to classes. One of the aims of this designwas to create a modular system, where single components (such as the Browser classresponsible for controlling a Web browser) could be replaced without affecting the restof the system. By implementing event listening interfaces, components (e.g. a view)could subscribe to events, such as browsing events.

Since the initial Arakne prototype, the system has seen two major revisions, both

58 CHAPTER 6. CONTRIBUTIONS

Figure 6.7: Early Arakne Version

involving the move from DHM to OHP hypermedia servers. The experiences withthe move to OHP, described in Section 6.3, showed that this was the case to a certaindegree, as it was indeed possible to move to Construct without greatly affecting the in-terfaces to the views. This convenience however happened at some considerable cost,codewise. The component identified as “Operations” in the Arakne Framework (Fig-ure 6.1) was dealing with Construct servers, and thus used the Construct data modeland the associated classes. The top layers, that is the views and the interface to the Hy-perstructure Store used the data model inherited from the previous version of Arakne.This older data model had some advantages over the Construct model. It was, froma navlet developer’s point of view, less cumbersome to work with, and fitted moredirectly into the Java idiom. It natively supported the model/view paradigm, so that hy-permedia objects alerted their viewers or associated objects of changes made to them.Thus, a developer could create a few event listeners and be alerted to any changesthat took place within the data model. This, while very nice when developing views,proved to a debugging and maintenance nightmare, as well as imbuing a considerableoverhead to the system. All elements in the Construct data model has to be duplicatedin the Arakne data model by wrapper classes that maintained the original functionality.Clearly, there was need for some innovation. It also became clear that there was stillroom for considerable improvement in the design to facilitate greater flexibility withregards to future expansion. The early Arakne Environments relied on the “Hyperstruc-ture Store”, one class consisting of convenience methods for all navlets. We wanted tomaintain a convenience layer, as it eases development, but having this functionality inone class was clearly a problem. This class was ever growing in size and in complexity,and a modular approach was in order.

The new design had to fulfil certain requirements:

• New functionality (such as new structuring mechanisms) should not influenceexisting code

6.6. PROTOTYPES 59

• Modular and dynamic architecture — no large monolithic classes, and no in-stances of unneeded classes

• “Plug and play” functionality — updates and new releases of views or servicesshould be automatically integrated into the system

• Conceptually simple for the view programmer

• As much code reuse from Construct as possible — no duplicated efforts

Figure 6.8: The Arakne Environment: Two sessions, two views, and a Session Man-ager. The ticker tape is visible at the bottom. The tabbed panes just above the tickertape is used to switch between joined sessions.

The end result of this redesign is the current version of the Arakne Environment,seen in Figure 6.8. When Arakne starts, it checks whether its constituent classes, lo-cated in JAR (Java Archive) files, are up to date by checking a distribution Web site. Ifa new version has been released, the new JAR file is retrieved and made available forthe system. Through introspection, the Arakne Environment determines which viewsand services are available, and updates its user interface accordingly. If a user launchesa view, the necessary service (or core) is instantiated and made available for the view.

60 CHAPTER 6. CONTRIBUTIONS

New views and matching cores as well as central Arakne classes can be added to thedistribution Web sites, and seamlessly integrated into the existing system.

This functionality is facilitated by two new central classes: TheJarLoader andtheDynamicEntity . The former is responsible for retrieving updates from the dis-tribution Web site. The latter handles the instantiantion of the views and their services.Neither of these classes require any modification for the addition of new services orviews. There is still a convenience layer in Arakne, but now it has been delegated tothe individual services, and the structure of these convenience classes has been stream-lined considerably to the point, where they eventually can (and in all likelihood will)be auto-generated to a large degree.

In some ways the convenience layer is “thinner” than it was before — the viewdeveloper is closer to the core functionality. However, this cost is offset by the lowerdevelopment cost of the services due to a simpler design, which should also reflect inthe number of bugs encountered in the code.

Some steps are still missing, before the Arakne Environment can be considered re-ally easy to develop for. One thing is developing new views for existing services, suchas a replacement for the navigational hypermedia tool, Navette. In such a case, the ex-isting services are readily available. However, a system should also support the additionof genuinely new functionality, such as a new structuring mechanism (e.g. taxonomichypermedia). In some aspects, the Arakne Environment supports such extensions verywell, as it will automatically update and reconfigure itself for new services and views.In the development phase however, specialised development tools, like CSC [105],would allow more rapid prototyping of new services. Such tools can certainly not takethe hard work out of making hypermedia applications, but it can address some of thedrudgery.

6.7 Summary

I have in this chapter detailed the work I have done during my Ph.D. During that pe-riod I have with DHM/WWW as a starting point developed increasingly sophisticatedWeb augmentation tools leaving me today with the Arakne Environment, a general ar-chitecture for Web augmentation tools based on the OHP compliant Construct servers.The Arakne Environment supports not only a number of hypermedia structuring mech-anisms, but also session based collaboration. My latest work, the iScent framework,seeks to develop a scalable architecture to support shared awareness and intersubjec-tivity. This fits within the Arakne Environment, but can also be used in many othersettings, where tools can be integrated to generate events, reporting the user’s activi-ties.

Chapter 7

Challenges for WebAugmentation

Throughout the development of prototypes, some lessons about Web augmentation arelearned. This chapter sums up the experiences not directly related to Web augmentationper se, but still important. A dominant theme in my work has been the challenge ofworking with standard technology and existing standards. In open hypermedia wedo not have the luxury of writing everything from the bottom, we have to adapt oursystems to existing systems. In many ways, the experiences learned with integratingwith Web browsers over these past years are prototypical for open hypermedia. Anotherchallenge for Web augmentation is that of scalability. The foremost quality of the Webis its scalable nature. Apart from the added functionality of Web augmentation, italso becomes important that users should not feel hampered performance wise, whenusing Web augmentation. Likewise, it should be possible to design Web augmentationsystems able to withstand the load of many concurrent users. Some advances made inthis area through the active use of interchange files are presented.

7.1 Working with Web Browsers

One inescapable consequence of my client-side approach to Web augmentation is thenecessity of integrating existing Web browsers. Open hypermedia is based on the tenetthat hypermedia must be integrated with the applications, users are already using1.An important part of developing Web augmentation hypermedia systems has thus beenworking with Web browsers. This section describes my experiences with Web browser,going into details on how the Web browsers over time has influenced (or hampered) mywork.

The work on Web augmentation at the Department of Computer Science at Univer-sity of Aarhus started in 1996, at a time where the dominant Web browser was the pre-3.0 Netscape Navigator. Java applets in Web browsers was a fairly new phenomenon,and the new Navigator 3.0 had just introduced the integration between Javascript andJava. This integration made the early browser integrations possible. The DHM/WWWJava applet (Figure 6.5) retrieved Web pages, as well as links and anchors, merged the

1Interestingly, the Web is an exception from this. The Web is a monolithic hypermedia system, yet hasmanaged to conquer the rest of the world, regardless of platform and operation system. No other system (andcertainly no hypermedia system) has, to the author’s knowledge, ever achieved this feat.

61

62 CHAPTER 7. CHALLENGES FOR WEB AUGMENTATION

twain, and displayed the result in a Netscape window by generated Javascript code thatwrote the actual pages. This approach was quite slow, regardless of whether the Webpages in question contained any external anchors. Furthermore, the Netscape brow-ser did not allow selections to be detected, nor the Java applet to access the displayeddocument in any way — this resulted in a rather cumbersome arrangement, where theJava applet would cache an unmodified copy of the displayed document for referencepurposes. Link creation consisted of copying a context for the desired anchor to theJava applet, and selecting the text to be the anchor in this copied context (this two stepapproach was taken to improve probability of correct anchor identification). The Javaapplet would then proceed to find the context and the anchor within the cached copyof the original document. It should be noted that due to the so called “sandbox” se-curity constraints imposed on Java applets, the DHM/WWW applet was restricted toretrieving Web pages exclusively from the Web server, wherefrom it originated. Whilethe document displayed in the Netscape browser as such was closed to the Java ap-plet, the converse was not true, as it was possible to call the Java applet through theuse of Javascript. Under ordinary circumstances, the act of following a link wouldrender a Java applet impotent to influence the Netscape browser. To avoid this, theDHM/WWW applet replaced all occurrences of ordinary<a href links with linksthat through Javascript called the DHM/WWW applet. Thus, the applet was able toretain control under normal browsing. Of course, as soon as the user entered a URLinto the Netscape browser rather than the DHM/WWW applet or used a bookmark, thiscontrol was irretrievably lost.

These circumstances all lead to an inefficient, cumbersome, and fragile prototype.The only advantage of the DHM/WWW applet over the systems I have later designedand developed was that of platform independence. DHM/WWW worked on all plat-forms supported by the Netscape browser.

Basic features, such as selection detection, was not available, and the coming of thenext version of the Netscape browser was eagerly awaited, as improvements had beenannounced. The next version of Netscape, version 4.x, opened up new possibilities forJava applet based Web augmentation. Recognising that the Java “sandbox” was too re-strictive, the notion of digitally signed Java applets were introduced2, allowing trustedJava applets to gain a wider access to the Internet, the local file system, or, especiallyrelevant to our cause, the Netscape browser itself. This version of the Netscape brow-ser supported an event system, where actions such asmouseOver , mouseClick ,onSelection , etc. could be captured through Javascript. This finally made it pos-sible to determine selections on a Web page for elegant link creation, and to captureattempted link following without modifying every link on a Web page, as was neces-sary with DHM/WWW. Unfortunately, even with digital signing, the Netscape brow-ser did not permit capture ofonSelection events across frame boundaries, and linkcreation was thus still a two-step process. Through improved, the Netscape browserdid not allow post-render modification of Web pages. To accommodate the pre-rendermodification of pages while trying to avoid the high performance hit of generatingJavascript to generate the entire page, a trick, possible only on the Netscape brow-ser was employed. It is through digitally signed Javascript possible to change proxy-settings dynamically. Thus, upon start, Navette (Figure 6.6) would launch a small localproxy, and setup the browser to use this proxy. If the browser already were config-ured to employ a proxy, this proxy was in turn used by the Navette proxy. While a

2It should be noted that at this point, there were three different signing standards for Java applets: Sun,Netscape, and Microsoft. This situation has not improved, and digitally signed Web browser independentJava applets are thus impossible.

7.1. WORKING WITH WEB BROWSERS 63

marked improvement over the approach taken by DHM/WWW, this approach was stillfairly slow, as it (discussed in Section 4.3.9) invariably slowed the retrieval of all pages,regardless of the amount of hypermedia content.

At this time, the Webvise client was being integrated with the Microsoft InternetExplorer. This browser featured a COM interface which not only made it possible tocontrol the browser itself, but also access and modify the Web page currently displayed.This allowed the Webvise client (as the first open hypermedia client to the author’sknowledge) to perform post-render link decoration on a standard Web browser. Thiswas much faster, and considerably more elegant, and clearly the way to proceed. Thus,the Netscape browsers, who did not feature such interfaces, were abandoned in lieu ofthe Microsoft Internet Explorer.

This move had of course some consequences. The Netscape browser supportedmore computing platforms that the Microsoft Internet Explorer, and these platformswere lost in the move. Furthermore, the integration with the Internet Explorer reliedon using a COM interface, which required us to use the proprietary Microsoft versionof Java, which explicitly supported this. Thus, even the platform independence of Javawere lost in the move. Yet, some of these losses were acceptable. At this, the socalled “Browser War” was nearing its end with Microsoft as the victor. By switchingto the Internet Explorer, we were supporting the most widely used Web browser. Theloss of platform independence was regrettable, but at least we were supporting themost widespread operating system, Windows. It should be noted, that not all platformindependence was lost, as only the Web browser integration code relied on the COMinterface. Thus, only this platform specific code need rewriting, if we at a later timeshould target a new Web browser on a different platform.

The first iterations of the Arakne prototype relied on Microsoft Java for COM in-tegration. Unfortunately, as tensions heated between Microsoft and Sun, the formerstopped releasing new version of their Java tools. This locked the Arakne prototypeinto Java version 1.1 for quite a while, and thus making the user interface and otherimprovements made in Java 2 (version 1.2) unavailable. At this point, the move to Con-struct was well underway, and as Construct relies on the collections classes found inJava 2, the Construct used in Arakne had to be rewritten to accommodate Java 1.1. Thiswas an unacceptable development overhead, and the decision to move to abandon Mi-crosoft Java was taken. This was possible only because of a commercial Java/DCOMintegration, JIntegra, which we started to use. This leaves the Arakne Environmentwhere it is today. The prototypes which started out as platform independent if browserdependent applets have today evolved into an application supporting only one browserand one operating system.

7.1.1 The Ideal Web Browser

What would, from a Web augmentation standpoint, constitute the ideal Web browser?As described in the previous section, most of my Web augmentation work has beenhindered as much as helped by the available Web browsers. Especially the developmentutilising the Netscape browsers were frustrating. Clearly, there must be a better way.

As describing in Section 7.2, I have throughout development used Java. As the firstWeb augmentation tools were Java applets, this was a natural choice. Today, this de-velopment however leaves an application, that cannot reap the platform independencebenefits of Java, but must suffer under the Java platform’s weaknesses, such as (rela-tively) slow user interfaces, relatively large memory requirements, and difficulties withintegrating native tools.

64 CHAPTER 7. CHALLENGES FOR WEB AUGMENTATION

In many ways, the current Internet Explorer is a good candidate to what a Webbrowser should provide for prospective Web augmentation developers. It is modular,and can be integrated into other applications, and other applications can be integratedinto it (as done by the tools described in Section 5.2). It has a rich interface, bothfor control of the browser, and for manipulating the Web pages displayed by it. Onthe flip side, it is predominantly Windows oriented, and requires COM for integration.The newest version of the Internet Explorer (version 5.5) purports to support editing ofHTML files. We have only recently begun conducting experiments in this regard, butthe prospect is quite interesting.

The ideal future batch of Web browsers would support the functionality of the In-ternet Explorer, but doing so by relying on a general cross-platform and -browser in-dependent API, accessible regardless of programming language. This would simplifythe development of Web augmentation tools, and hence make the development of suchtools much more attractive. This could be accomplished either over a process to pro-cess communication protocol (such as COM, Corba, or RMI), or by some scriptinglanguage (i.e. accessing the internals of the browser through e.g. Javascript).

As such, the Mozilla browser holds some promise with its XPCOM componenthttp://www.mozilla.org/

model. It is still too early in the browser’s development process to see whether it willbe able to compete with Internet Explorer. Given the open source nature of the project,it should be possible to create an API for Web augmentation tools. This however isfuture work.

7.2 Experiences with Java

All the Web augmentation systems developed prior and during my Ph.D. has beenimplemented in Java. The first prototype (pre Ph.D.) was DHM/WWW and was imple-mented in 1996. During the course of these four years, the Java language has maturedconsiderably and this section will reflect on the experiences with Java development.

By far the greatest drawback of using Java has been the problematic support ofCOM. The Internet Explorer is handled through COM, and thus the ability to han-dle COM is crucial. Over the last few years, Sun and Microsoft has been engaged ina lengthy legal dispute, with COM support as one of the casualties. Thus, the cur-rent incarnation of the Arakne Environment relies on a commercial third-party DCOMintegration, JIntegra. This makes distributing Arakne problematic, as the license forhttp://www.linar.com/

JIntegra is quite expensive.In hindsight, it is fair to question the decision to stay with Java throughout the de-

velopment process. Certainly, the Internet Explorer integration would be much easier,if the Arakne Environment was written inC++. On the other hand, the last two versionsof the Arakne Environment has reused much code from the Construct effort — codewe would have been forced to reimplemente, had we not used Java. Clearly, there arepros and cons to this question. Apart from the Construct code, we have also benefittedfrom the extensive standard libraries found in Java. There are things, that could bebetter in Java (such as the lack of templates), but it is a very accommodating languageto develop in.

If I was starting from scratch today, given the current Web browser situation, I thinkthe wisest course had been to use C++. This would have allowed a much closer integra-tion with the Internet Explorer. One problem that remains is that this would effectivelylock us with the Internet Explorer. Currently, there are no real challengers to this Webbrowser, but this may change in the future — once the Netscape browser was com-

7.3. HYPERMEDIA SCALABILITY 65

pletely dominant. If the Arakne Environment in the future should continue with Webaugmentation (it might also extend to other types of applications), the system shouldnot be tied to one browser. If a new browser was to emerge today, and if it providedin one way or another an interface similar to the one found in the Internet Explorer,porting the Arakne Environment to support this browser would require rewrite of a fewclasses, but it would not affect the rest of the system.

My work has been on the client side of open hypermedia, and I have done rel-atively limited development on the server side. On the server, the benefits of Javaare much clearer. The ability to run servers anywhere (or at least where Java is sup-ported) should not be underestimated. Likewise, the platform independence, most Javaprograms should exhibit eases code sharing between different system considerably.Currently, both the Construct and the Chimera backends are implemented in Java. Per-formancewise, the penalty of Java is not so great as on the client. Much of the heavycalculations should in most modern hypermedia servers be relegated to the databasebackend.

Javasoft has recently announced that they in the next quarters are going to focus onhttp://www.javasoft.com/

the client-side of Java. The last few versions of Java has shown considerable progress,and it is to be hoped that further progress will be made. The most essential, at least frommy point of view, is the ease with which COM communication can take place. Priorto the move to JIntegra, we conducted some experiments with the Javasoft Java/COMBridge. At that point, it did not meet our requirements, and this is clearly an area,where Javasoft could, to our benefit, focus its resources.

7.3 Hypermedia Scalability

One of the classic problems with any hypermedia system relying on externally storedhypermedia structures is that this impacts scalability. Rather than just retrieving anddisplaying a document, a hypermedia system also has to query its hypermedia serversfor relevant structures, retrieve these structures and display them in conjunction withthe document. Evidently, this is more computational and time intensive than just re-trieving a Web page, and scalability is indeed one of the Web’s strong points. Webaugmentation will invariably be compared to what can be achieved with ordinary Webtechnology, and as such scalability becomes a great concern for the Web augmentationfield, if it is ever to see widespread use.

In the context of this discussion I would like to approach scalability from two differ-ent angles: Scalability in the sense of concurrently serving many users, and scalabilityin sense of serving massive hypertexts. While both are highly desirable, they put dif-ferent stresses on the overall system. The imperative of a myriad-user system is lowlatency, that is completing single operations quickly. This is, where the Web shines.

The problem of supporting massive hypertexts is slightly different, and more com-plex. Anderson has done a lot of work on achieving this form of scalability with theChimera system [3]. The hypermedia system must both on the server and the client sidebe able to handle large structures. On the server, this implies large scale storage, whichin practice translates into using a solid database, in the case of Chimera, PostGreSQL.Clients are usually built using standard GUI widgets, and these do often not scale well,when confronted with tens of thousands links etc. One thing is the scalability of GUIwidgets, another question is if standards GUI widgets such as lists, trees, and tables re-main an effective interface for managing many items. One approach taken by Andersonwas to implement filtering, so that users were only presented with the links of imme-

66 CHAPTER 7. CHALLENGES FOR WEB AUGMENTATION

diate interest. Given that the client and the server is able to handle massive hypertexts,the protocol between them must be considered. For instance a protocol, where eachlink is retrieved one at a time imbues an enormous overhead on the system, in com-parison with a protocol where links are retrieved en masse. When replies to queriescan be large, it becomes relevant to modify the protocol, so that for instance the sizeof the reply is reported before the entire reply is returned. This would allow the clientto inform the user of the retrieval in progress. Likewise, a client should be able handlereplies as they are being received, thus improving the apparent responsiveness of thesystem. An interesting topic in this area is the visualisation of massive hypertexts. Ifstandard GUI widgets break down both with regards to both performance and usability,new forms of interacting with such large collections must be devised. This is a difficultproblem, and one I for the Arakne Environment has relegated to future work.

The Coconut project has also been working with scalability issues, and we haveinvestigated two approaches. Firstly, one could build an infrastructure based on asolid database such as Oracle, and by utilising the industrial strength of these systemsachieve solid performance. Secondly, one could try to do away with the hypermediaserver altogether. The Construct servers were originally based on a relational databasebackend, and for large scale usage this still seems to be the proper course, given the pos-sibilities of backup and security that these databases offer. However, the performanceof the Construct database never became satisfactory, and it was thus abandoned in lieuof a simpler, but faster, file-based solution. Future work on the Construct servers wouldcertainly benefit from more work and optimisation on a database backend, so that theadvanced features of these systems, such as transactions and rollback could be used toprovide greater fault tolerance. The developers of the Chimera system [2, 5, 7, 8] atUniversity of Colorado, Boulder, has had good experiences with database backends, soit can be done satisfactorily.

7.3.1 Scalability through Interchange Files

Another approach to attain scalability is to eliminate the bottleneck of the hypermediaserver, or (more correctly) to minimise the strain on the hypermedia servers. This canbe accomplished through the use of hypermedia interchange files. When an author ofhypermedia structures has finished working on a particular set of structures (typicallya context), it is saved into an interchange file, which can then be freely distributed. Anexample of such an interchange format is the Open Hypermedia Interchange Format(OHIF) [55], another is link base files in XLink [37].

The Open Hypermedia Interchange Format is strongly influenced by the data modelunderlying the Open Hypermedia Protocol. Currently, OHIF supports navigational hy-permedia and guided tours, but the format has been designed to easily accommodatefuture expansions. Compared to XLink, there are some similarities, as both are XMLbased, and both offern-ary, bi-directional links. Both XLink and OHIF can throughlocators respectively locspecs address selections in arbitrary document types3. Whilenavigational hypermedia still is the mainstay of hypermedia, there are many other struc-turing mechanisms, that cannot easily (or at all) be modelled by links, such as compo-sitional, spatial, taxonomic, or issue-based hypermedia. As OHIF can be extended tohandle such structures, it is, in this aspect, a stronger interchange format than XLink.Currently, OHIF is supported by Webvise and the Arakne Environment.

3Currently, XLink seems to be largely dependent on XPointer, which only addresses XML documents.The standard is however open for other specifications.

7.4. SUMMARY 67

That interchange files contributes to scalability can be illustrated by the deploymentof Ariadne [66] at Opasia, discussed in Section A.2. The approach in this instance wasmore extreme than the one taken by Webvise and Arakne, as the latter two still employa hypermedia server to handle the interchange file, whereas Ariadne has no serverinteraction apart from downloading the interchange file (a retrieval handled by a Webserver). It should be noted though, that the Ariadne deployed at Opasia was a read-only version, stripped of the ability to author guided tours. Thus, there is no need for ahypermedia server.

This approach solves only some scalability issues. It certainly allows many users to(read-only) access the same hypertext, and it provides collaborators with an easy wayof turn taking on hypertext authoring. It does however not address the larger problemsof simultaneous authoring access for many users or massive hypertexts.

7.4 Summary

I have in the preceeding sections detailed some of the obstacles to Web augmentation,that I through my work have encountered. These are not an exhaustive list, but shouldbe fairly representative. Being a subfield within open hypermedia, Web augmenta-tion shares many traits with the larger field, such as third-party application integration.Web augmentation is not very interesting, lest it provides the user with a full hyperme-dia integration (otherwise the improvement compared to unaugmented Web would beslight), and as such integrations are a top priority. Partly due to the “Browser War”,Web browsers over the last four years have seen tremendous development. The posi-tive aspect of this in conjunction with my work was that if a feature was not present ina Web browser, it probably would be in the next release a quarter later. The negativeaspect was that these newly implemented features (especially in the case of Netscape)were often poorly thought out or implemented. With the move to the Microsoft Inter-net Explorer, some stability has been achieved, but at the cost of tying Webvise andthe Arakne Environment to one Web browser and one platform. Interoperability be-tween different platforms is always tricky, as has certainly been the case with Java andWindows. Whether this situation will improve remains to be seen.

One sensible requirement of Web augmentation is that it should work well withthe user’s Web browser, another is that it should not degrade the overall Web experi-ence by for instance slowing retrieval of Web pages down. On the client, this has beenaddressed through post-rendering link decoration. The question of designing Web scal-able open hypermedia systems still remains open, though it in the context of Web aug-mentation partly has been addressed through the use of interchange files stored on Webservers. Interchange files are well suited for publishing hypertexts, or for turn takingco-authoring. Future scenarios of many users actively and simultaneously co-authoringhypertexts on the Web cannot be handled through interchange files, and thus there aregood prospects for future work in this area.

68 CHAPTER 7. CHALLENGES FOR WEB AUGMENTATION

Chapter 8

Conclusion

I have in the preceeding chapters described my work on Web augmentation duringthe course of my Ph.D. I have developed several prototypes, published papers aboutthem and their underlying models, as well as worked on OHSWG standards and futuresystems for intersubjectivity support. My experience is that the realm of the Web isdefinitely open to open hypermedia.

This chapter sums up my experiences and outlines my plans for the immediatefuture, as well as some (hopefully educated) guesses on the long term prospects ofWeb augmentation as a subfield of open hypermedia and the World Wide Web.

8.1 Primary Results

Throughout my Ph.D., I have designed conceptual models for Web augmentation, andsubsequently implemented a number of increasingly ambitious Web augmentation sys-tems. These systems have demonstrated the viability of Web augmentation as a tech-nology. As the Web stands today, there is still ample room for improvements withregards to the structural and collaborative mechanisms available.

The Arakne Environment embodies an approach to Web augmentation that if itdoes not attempt to do all things Web augmentation, at least accommodates the pos-sibility through its modular design. Especially the integration with Construct withits potential limitless amount of new hypermedia structuring mechanisms [105] holdsgreat promise. The Arakne Environment is not architecturally bound to one platformor Web browser, and should thus prove adaptable to future developments.

Web augmentation allows users to structure their Web experience and to share thiswith other users of the Web. As a tool it can find use in both professional settings as aknowledge management and structuring tool, as well provide Web surfers or Web jour-nalists with more powerful tools. The last few years have seen a proliferation of metaWeb sites, that largely reports on occurrences on other Web sites. Web augmentationfits nicely within that niche.

The Web is not rendered obsolete by Web augmentation, quite the contrary. Webaugmentation strengthens the Web by extending the possibilities of interacting andusing the Web. Ultimately, Web augmentation is a question of liberating the link,and allowing users to participate in a free, Web-wide discourse by linking, associating,annotating, and restructuring the existing Web to fit their need and vision. An importanttask for the future is to devise an architecture able to withstand such large scale use.

69

70 CHAPTER 8. CONCLUSION

Some steps has been taken in this direction with the work on the Open HypermediaInterchange Format.

I doubt that the Web will on a large scale be succeed by new technology anytimesoon. The Web is easily “good enough” to satisfy current and many future needs with-out warranting replacement. The Internet, propelled by the Web, was a revolutionarychange in the general availability and use of computers as tools of communication.When the Web emerged, or rather erupted, it filled a previously unfilled niche. Nowthat the Web reigns supreme, future changes will in all likelihood be gradual ratherthan sudden. Web augmentation is one such gradual change, improving the Web with-out replacing it. Future changes to the Web will take place within a Web context, notwithout it. This is also witnessed by the growing proliferation of Web technologies inother contexts, such as the spread of XML. The Web and the Internet are increasinglybecoming infrastructures — the substrate upon which computing is built. One technol-ogy thatmaybe challenged in the years to come is the client/server model underpin-ning the Web in the sense that the distinction between clients and servers will becomeblurred. There will be many more behemoth servers serving increasingly sophisticatedcontent, but simultaneously the common household computer will be connected per-manently to the Internet. The permanence of connections coupled with the generousstorage and processing capabilities of modern computers enables a more widespreaduse of peer-to-peer networking. This has already been convincingly demonstrated byfile sharing tools such Napster or Gnutella. While these tools predominantly has beenhttp://www.napster.com/

used for software and content piracy, the very model of clients connecting to clients isviable. An interesting project is this context is the Freenet Project [28], which seeks tohttp://www.freenetproject.

org/ create a global docuverse, with all content encrypted to the degree that a maintainer ofa Freenet node cannot determine what is stored on that node.

Web augmentation as a technology is open hypermedia, which in its eleven yearold history has demonstrated its wide applicability. Web augmentation as such is lim-ited to the Web, but as has been demonstrated by e.g. Webvise [56] and Mimicry [20][P2], Web augmentation does not end with HTML. The unique advantage of Web aug-mentation as a subfield of open hypermedia, is that the Web in general works with openformats and standards. While proprietary differences in implementations exist and mayhamper work, the principle of openness still holds. Compared to the general work ofopen hypermedia dealing with applications with often closely held proprietary docu-ment formats, the subfield of Web augmentation has it much easier. The possibilitiesinherent in the Web architecture (such as creating specialised hypermedia proxies), orthe combination of dynamic HTML with scripting and stylesheets are many indeed,and I am certain we have only begun to scratch the surface of what can be done.

8.2 Web Augmentation in the Future?

A work such as mine, aimed as it is to better the current state of affairs, should also beconsidered in the longer term. Apart from technical concerns, such as the availabilityof a certain Web browser or or a specific programming language, the long term viabilityof Web augmentation as such must be considered.

The most probable successor to HTML is the XML based XHTML.If the Webevolves into a space of XML documents1, initiatives such as XLink (see Section 5.1)can come into play. In such a context, where XLink has been adopted by the leading

1This is not given — the inertia of the existing approximately1× 1012 Web pages, much of which doesnot conform to any known HTML standard whatsoever, is considerable.

8.2. WEB AUGMENTATION IN THE FUTURE? 71

Web browsers, some of what the Arakne Environment can accomplish today will bedirectly supported in the Web browser. In such a best-case scenario, the Web wouldhave evolved into a “proper” hypermedia system [82], allowing arbitrary linking andannotations to take place. Furthermore, a XML future could also entail that otherdocument types, such as word processing files or spreadsheets, would migrate to XML,and would then also be subject for easy linking. What would be the role of the ArakneEnvironment or indeed any Web augmentation tool in such a context?

My immediate reaction to such a scenario is very positive. The purpose of my workhas been to investigate the possibilities of Web augmentation, not to developtheWebaugmentation system of the future. I wish Web augmentation and the possibilities itgives people to become widespread, so any technology that can bring that about is fineby me.

While base functionality such as authoring of navigational hypermedia would re-side in the Web browser, the hypermedia research community has developed so manyother exciting hypermedia structuring mechanisms, that there would still be ampleroom for Web augmentation research. While the basic ability to author links is anessential part of most hypermedia systems, another problem with the Web also war-rants our interest, namely that “getting lost in hyperspace” with a corpus as large andas unstructured as the Web is a common phenomena. Some technologies, such as spa-tial hypermedia [74, 89] or advanced structure visualisation, hold some promise to helpus navigate this jungle of information. In this regard, the community driven meta Websites mentioned in Section 4.7.3 are interesting. They demonstrate the viability of thou-sands of Web surfers scourging the Web for interesting stories and reporting the creamof the crop in a common forum. If this could be moved into a large, ever evolving hy-pertext with many authors and moderators, such a system might be the tool to handlethe complexities of the Web.

Another possible future is that of the heterogeneous Web — while there will be amove to XML, this will not be nearly complete, and thus essentially leaving us with aWeb not too different with what we have today. Additionally, the future Web will mostlikely be accessed not only from more or less comparable (and increasingly powerful)personal computers, but also from a growing number of appliances2, such as PDAs,mobile phones, etc. Such devices have fairly limited displays, and the work to providegood hypermedia functionality on such devices will be interesting.

8.2.1 Commercial future of Web augmentation

As described in Section 5.2, there are several commercial ventures into Web augmen-tation. Whether these will survive, or suffer the fate of many dot coms remains to beseen. My earliest fascination, when introduced to the hypermedia research litterature,was that of the trail blazer, the professional creator of associations. The question is:Can you sell links on the Web? The described companies seem to focus on makingpartnerships with other companies, e.g. essentially advertising. One business modelthat might work is the combination of an informative Web site, which in addition to itsgeneral services could offer its subscribers an “enriched Web” through Web augmenta-tion. This was the vision at Landbrugets Rådgivningscenter (described in more detailin Appendix A.1). Another possibility would be use Web augmentation to attract moreusers to a Web site, as done by Opasia with Ariadne (see Appendix A.2). The current

2According to several keynotes at WWW9, the number of such devices connected to the Internet willsurpass that of personal computers in a few years.

72 CHAPTER 8. CONCLUSION

Web is largely financed on an advertisement basis, and whether this model holds forWeb augmentation remains to be seen. The advert of micro payment (to the author’sknowledge still a technology under development) may very well change that, thoughit of course is a question whether it will meet with general approval from the Web’susers.

8.3 Future Work

In many ways my Ph.D. has been mainly establishing a base for future work. The realapplicability of Web augmentation can only be tested in a setting with mature tools,and only recently has the Arakne Environment reached a sufficient level of usability.As such there still remains much to be done.

8.3.1 Collaboration in the Arakne Environment

The Arakne Environment provides the collaboration support found in the OHP compli-ant Construct servers. This functionality of one of the newest additions to the system,and quite likely also still a source for bugs. Collaboration support is notoriously diffi-cult, and it will not suffice that Arakne Environment performs as expected, if this is notthe functionality needed in a given work setting. The Arakne Environment has neverseen use in other organisations, and until such testing has taken place, it is too earlyto evaluate the Arakne Environment as a collaborative environment. While prototypesand mock-ups certainly has their place in the design process, I believe that applicationscan onlyreally be tested, when they offer full functionality. One of the hard lessons ofmy Ph.D. is the time it takes to get to that point.

I am quite excited about the iScent framework. As planned, the system offers to bean externalised memory for the individual user as well the projects, the user participatesin. One part is the collection of events documenting a user’s actions, another (and muchmore interesting in my opinion) is the user’s retrieval, analysis, and use of these events.The client to handle this, the Trail Viewer, is quite prototypical at the moment, butwe (Ken Anderson and I) hope to develop it into an application supporting advancedstructuring of events. This will (of course) take place within the Arakne Environment.One area, where I plan to extend the iScent framework is the protection of privacy.The current design suggests that users decide which kind of events they wish to bepublished. While this certainly protects them from “prying eyes”, it also limits theirown use of the iScent tools, as they themselves of course cannot retrieve non-publishedevents. An alternative solution would be to introduce encryption of all events at theuser level, presumably with some events being private and thus encrypted with thepersonal key, and with others encrypted with project keys. Thus, only the keeper of thematching keys would be able to retrieve the encrypted events. In such a scenario, userscould then, if they so wished, establish “communities of trust” within which the userswould be able to see each others’ events.

8.3.2 Open Sourcing the Arakne Environment

It is the aim of the author, that the Arakne Environment along with Construct should beopen sourced, so that it may benefit more. This decision is reached for the followingreasons: Firstly, it seems only proper that computer scientists along with their pub-lished results should publish the source code with which they created their results (lest

8.3. FUTURE WORK 73

we become a science of irreproducible results). Secondly, the emphasis especially inthe later versions of the Arakne Environment on dynamically extendible hypermediaservices and nice coding environments for hypermedia developers would be an exercisein futility, unless it was given a test in the real world.

The main obstacle to open sourcing Arakne is the current reliance on JIntegra forCOM integration. JIntegra is a commercial product, and Arakne must thus in the fu-ture handle its own COM integration, before it makes any sense as an open sourceproject. This autumn will hopefully bring that about, as well as maturing the code basesufficiently for general release.

74 CHAPTER 8. CONCLUSION

Appendix A

Use Studies

Web augmentation has potentially quite wide appeal. In this appendix, I focus on twouse studies — one that I have done myself, and another done by other members ofthe Coconut project. The first case, Landbrugets Rådgivningscenter, illustrates howknowledge workers may use Web augmentation to supply their customers (agriculturalconsultants) with better services and more in-depth information. The second case,Opasia, shows that Web augmentation can also have wide appeal, in this case Websurfers following guided tours written by Web journalists.

A.1 Landbrugets Rådgivningscenter

Landbrugets Rådgivningscenter is the central Danish agricultural advisory centre. Theorganisation is controlled jointly by the Danish Farmers’ Unions and the Danish FamilyFarmers’ Association. Landbrugets Rådgivningscenter provides service and expertisefor the local advisory centres’ advisors, who in turn advise the farmers. There are 85local centres throughout the country. Landbrugets Rådgivningscenter does not gener-ally work directly with farmers. The organisations and their relationship can be seen inFigure A.1.

Danish Farmers'Union

Unions

Danish FamilyFarmers' Association

LandbrugetsRådgivningscenter

Local DFU advisorycentres

Farmers

Local DFFA advisorycentres

Figure A.1: The Organisation of Danish Agricultural Advisory Services

Landbrugets Rådgivningscenter is organised into the following departments

75

76 APPENDIX A. USE STUDIES

• The National Department of Plant Production

• The National Department of Cattle Husbandry

• The National Department of Pig Production

• The National Department of Horse Breeding

• The National Department of Farm Buildings and Machinery

• The National Department of Education

• The National Department of Farm Accounting and Management of the DanishFarmers’ Union

• The National Department of Farm Accounting and Management of the DanishFamily Farmers’ Association

• The National Department of Poultry Production

• The Department of Agricultural Law

• International Department

• Section of Ecology

With a very few exceptions (such as pig production, which is predominantly han-dled by Danske Slagterier (Danish Bacon & Meat Council) Landsudvalget for Svin(Danish Meat Research Institute)), these departments are main source of informationrelated to agriculture in Denmark. The activities include

• Special advice

• Distribution of know-how

• Development

• Experiments and studies

• Education and in-service training

• Maintenance and service tasks

In our work with Landbrugets Rådgivningscenter we have concentrated on the twofirst areas, this will therefore be described in more detail. The essential task of Land-brugets Rådgivningscenter is to keep the local advisors updated and to be “the experts’experts”. The advisors at Landbrugets Rådgivningscenter keep themselves updatedwith regards to the latest literature and law development and are thus able to answerquestions from the local advisors, who may not the time available for this. Further-more the advisors at Landbrugets Rådgivningscenter keep a close contact to the localadvisors, keeping them aware of the needs of their customers.

A.1. LANDBRUGETS RÅDGIVNINGSCENTER 77

A.1.1 The Information Series

The distribution of information from Landbrugets Rådgivningscenter to the local cen-tres is primarily done through the information series - publications sent out on a regularbasis from the departments. Every department will typically produce several informa-tion series catering to specific needs in their field. The information series are copiedand distributed by mail on a massive scale (approximately 15 mill. copies/year).

Each publication will typically consist of several articles written by various advi-sors in the department. Every article is given a unique number to ease archival andreference. The indexing scheme varies from department to department, there is nogeneral pattern. Apart from the individual articles, a few pages of abstracts, brieflydescribing every article usually accompany every publication. These abstracts are justintended to give the local advisors an immediate overview over the publication, but areoften archived at the local centres.

A.1.2 Assembling a publication

Our main case study was at the department of plant production and the description ofthe process of assembling a publication will therefore be based on this department.We had the process described during meetings with representative from both the plantproduction and the agricultural law departments. The representatives indicated thatthe process throughout Landbrugets Rådgivningscenter is comparable to that of thedepartment of plant production.

The advisors at the department of plant production have well-defined fields of ex-pertise, and according to what is happening in their individual field will write articlesfor publication. Occasionally their supervisor will request an advisor to write a topicalarticle or decide that two advisors who have been writing on related material shouldwork together. The articles will often be inspired by journal articles, new laws, or news,and will as such usually contain quotes from, references to, or abstracts of material notwritten at Landbrugets Rådgivningscenter. The supervisor maintains an understandingof what the individual advisor is working on — a blackboard outside his office supportsthis, as advisors write the title of their current work in progress (this also ensures thatdouble work is not done). It is the task of the supervisor and his secretary to ensurethat each article is given a unique number. Whenever an advisor finishes an article, hesends the WordPerfect file to the supervisor, who reviews it. If the article is accepted, itis added to the current publication in progress. At the department of plant production,the deadline is early Wednesday. Given this week’s worth of articles, the supervisorand the secretary compile the abstracts, check the numbering of the articles and shipthe publication to the printing department.

A.1.3 Handling law material

Our initial contact with Landbrugets Rådgivningscenter was with the department ofagricultural law. They are mainly occupied with laws and revisions of laws. All Danishlaws are accessible on the Web , and the department was investigating, how the Webhttp://www.retsinfo.dk/

should affect their work, and how to improve their service to the local advisory centres.While laws are never changed (and thus are a nice stable environment for electronicmaintenance) they are often revised. Keeping track of these changes is no trivial task,and it can be quite complicated (at least for a lay person) to establish what is currentlaw, as this requires reading through many revisions. It was therefore one of our early

78 APPENDIX A. USE STUDIES

common goals that this process of consolidating the law texts into one document shouldbe supported by our tools. Later the department of agricultural law decided (wisely inour opinion) that maintaining a law Web site was better handled by outsourcing, ratherthan using their own advisors to keep track of changes.

A.1.4 Moving from paper to the Web

Landbrugets Rådgivningscenter is currently in a transitional phase, as more and morematerial is made available on the Web. It is the ultimate goal to make the Web the mainpublishing method. Currently it is the task of the supervisor and his secretary to createthe HTML documents. All word-processing at Landbrugets Rådgivningscenter is donewith Corel WordPerfect 8.0, and while special macros have been written to ease thetranslation, it is still no trivial task. The job is complicated by the typographical limita-tions of HTML, especially with regards to tables. One solution would be to create onlyPDF-files, which would solve all typographical issues, but PDF is not as searchable oraccessible as HTML, so for now the supervisor keeps fighting with HTML. The workof preparing the articles for the Web will eventually move down from the supervisor tothe individual advisors, but for now the work is centralised.

Landbrugets Rådgivningscenter is not the only one moving onto the Web. Many ofstate departments, and private companies and organisations that Landbrugets Rådgivn-ingscenter regularly quote or base their work on, are moving their material onto theWWW. Most noticeable is Pl@nteinfo , which provides the farmers and local advisorshttp://www.planteinfo.dk/

with exhaustive information during the growth season.

A.1.5 Work with Landbrugets Rådgivningscenter

Meetings between Landbrugets Rådgivningscenter and the Coconut project started inNovember 1997. The first meetings were exploratory in nature, where both parties weretrying to establish whether collaboration would be mutual beneficial. Later meetingsfocused on the departments of agricultural law and of plant production and their needswith document handling on the Web. These meetings were also used to showcasevarious forms for Coconut technology. Eventually a collaborative effort between thedepartment of plant production and Coconut project member resulted in a first Webmock-up of just how the future Landbrugets Rådgivningscenter Web site might appear.The first mock-up was a pure technological showcase but was used as input in thedevelopment of the second mock-up. This time the basis of the mock-up was a week’sworth of articles from the department of plant production and the possibilities thatshould be explored were decided on during two meetings. Based on this mock-up itwas decided that there were good reasons to continue the collaboration. Over the nextmonths, the systems that were to be tested at Landbrugets Rådgivningscenter werefurther developed.

The meetings with Landbrugets Rådgivningscenter resulted in a wish-list of fea-tures and functionality that would be desirable in a future setting. The advisors shouldin general be able to create links to and from whatever resource they may come acrosson the Web. These links come in various types, all which should not require the authorof the links to have write permission over the relevant Web pages. Based on their input,we created the following scenarios.

The anchor texts that John D. added were mainly to help readers nav-igate, and John D. realises that a short comment on the entire law would

A.1. LANDBRUGETS RÅDGIVNINGSCENTER 79

be nice. Using Webvise he composes a short paragraph and inserts thecomment in the beginning of the page, so that readers who do not readhis article still can benefit from his summary. The summary is marked bya comment icon in the beginning of the page (clicking on the icon willexpand the comment), so that readers are not required to read John D.’ssummary.

The topic of §25 is the amount of manure allowed per area adjusted bysoil type and amount of rain. While the soil type is constant for a particularpart of the country, the amount of rain is not, and John D. would like to add“live” data on the amount of rain to his article. John D. turns to the Website of the Danish Meteorological Institute, who has a nice, daily updated http://www.dmi.dk/

table of the accumulated downpour in the regions. The rest of the DMIpage is not relevant to the issue at hand, and John D. decides to transcludethe table using Webvise. The procedure of create the transclusion is similarto linking, and the effect is that the (always current) DMI table appears apart of the article.

Some of terms used in the manual are fairly unusual and to ensure thatall advisors out in the country understand, John D. decides to add theseterms to the “dictionary”. As the other advisors at the department, John D.has permission to modify the shared dictionary of Landbrugets Rådgivn-ingscenter. John D. creates new entries for the terms by creating a newWeb page for each term, as this is company policy (an alternative wouldbe to have one large file, but it was felt that this would be cumbersome,as it eventually would be quite large). Having placed his entries at the ap-propriate place on the Web site, John D. creates a global link from the first http://www.lr.dk/

occurrences of the terms he encounters in the manual to his definitions.Henceforth any of the terms (in all old, new or future documents) can usedto look up the definition.

Based on these scenarios, we have so far identified the following needs:

• Anchor-basedn-ary bi-directional links

• Creation of notes and comments to parts of documents. It should be possible tohide these comments from view.

• Transclusions: displaying data from one document in another, so that if the datais modified in the original document, the change is reflected in the other docu-ment.

• Creation of links with only a string rather than a document, a position, and astring as starting point. This can be used to create online dictionaries, e.g. anyoccurrence of the word “camomile” would be the starting point of a link thatwould end in a Web-page with pictures and descriptions of the plant.

• The ability to create links from and into PDF documents. While Web links canbe predefined in a PDF document, no technique exists today to create these linksdynamically1.

• Frame sets are notorious for making linking to a specific set of frames difficult:either you link to the starting frame set or you link to the specific page (and then

1According to the Adobe Acrobat Reader license agreement such a tool would violate the agreement.

80 APPENDIX A. USE STUDIES

loose the context of the other frames). Both solutions are unsatisfactory, and abetter approach is clearly needed.

• Rather than linking into a piece of text, it should be possible to create an anchorthat would appear before or after the relevant section. This anchor would thenhave anchor text defined at the time of creation, which would be displayed alongwith the link, when the Web page was displayed.

• The presentation of the external structures above should be very customisable.

• There should different sets of contexts to accommodate different needs (e.g. aplant advisor might be interested in less detail than a law advisor, when readinga law text)

• Exception handling: the change, move or removal of a Web page should behandled gracefully by the system.

• All these features should be present in a reader’s only solution, so that advisorsand farmers could have the advantages of these sophisticated structures withoutactually installing any special software.

A.1.6 Experiments at Landbrugets Rådgivningscenter

In late autumn 1998, user testing began at Landbrugets Rådgivningscenter. One user,the supervisor of one department, was elected to be the first adopter, and I was involvedin the preliminary testing of Webvise and DHMProxy at Landbrugets Rådgivningscen-ter.

In February 1999, this lead to a more comprehensive study, where a weeks worthof Web publications were done using Webvise and published through DHMProxy. Se-lected customers were then to evaluate the system and report back on their experiences.Unfortunately, noone reported back. At the same time, both parties (Landbrugets Råd-givningscenter and the Coconut project) became very occupied with other work, andthe experiments ended at this time. This leaves the question, why the customers didnot report back. While pure conjecture on my part, I would suspect two reasons: Thatchanging the proxy configuration was too much hassle, and that they did not have time.Clearly, this calls for another attempt.

A.2 Guided Tours at Opasia

Tele-Danmark Internet was the commercial partner in the Coconut project. One of thedirect results of the Coconut project was the deployment of a read-only version of theAriadne guided tour tool on the Tele-Danmark Internet portal, Opasia . I have not beenhttp://www.opasia.dk/

linkguide/guidedeture/ involved with this deployment, but have gracefully been given access the logs of someof the early deployments of Ariadne.

The guided tours were deployed in December 1999, and by early January 2000,more than 15000 users had browsed guided tours on the Opasia Web site. A link tothese tours is featured on the Web site’s frontpage , and the service reportedly still ishttp://www.opasia.dk/

widely used. An example of a guided tour, in this case on the topic of the OlympicGames, can be seen in Figure A.2.

The guided tours are written by Opasia’s Web journalists using a stand-alone ver-sion of Ariadne. Upon completion, the tour is saved in a XML file, and placed on the

A.2. GUIDED TOURS AT OPASIA 81

Figure A.2: Guided Tour at Opasia

Web portal. Users can then follow a link, which opens a read-only Ariadne with theguided tour in a separate windows. Topics for guided tours have varied from geneal-ogy to the Euro referendum. There are currently (October 14th 2000) nine guided toursavailable.

The greatest difficulty encountered in the development of this tool was to slim downthe original Ariadne to a small applet, that could run as many different Web browsersas possible. Users may for instance not have the latest version of Java installed, and ittherefore necessary to develop for the lowest common denominator.

82 APPENDIX A. USE STUDIES

Appendix B

Installing the ArakneEnvironment

An important result of my Ph.D. (and a recurring theme in this text) is the ArakneEnvironment. It can be retrieved from the author’s Web site. The text below can alsohttp://www.bouvin.net/

Arakne/be found at this Web site, complete with links to the necessary components.

B.1 Systems Requirements

The Arakne Environment currently supports only Windows NT 4.0 and Windows 2000,as it relies on DCOM for the Internet Explorer integration, and this is only found inthese operating systems. The system has been tested with the Internet Explorer 4.0–5.5.

The integration with the Internet Explorer is handled through JIntegra, which mustbe installed. Additionally, the Java Runtime System (version 1.2 or 1.3) must also beinstalled.

B.2 Installing JIntegra

JIntegra can be retrieved as an evaluation version from Linar Ltd. . Whenjinte- http://www.linar.com/

gra.zip has been downloaded, proceed as follows:

1. Unzip thejintegra.zip file into a directory (e.g.c: \Program Files \JIntegra ).

2. Add JIntegra to thePATHenvironment variable (in this example, addc: \ProgramFiles \JIntegra \bin ).

B.3 Installing the Arakne Environment

Assuming that JIntegra and the Java Runtime System has been installed, the ArakneEnvironment can be installed using the Arakne Installer. This program is available atthe Web site mentioned above:

1. Download theinstall.jar to a directory (e.g. c:\temp)

83

84 APPENDIX B. INSTALLING THE ARAKNE ENVIRONMENT

2. In a DOS shell, move to this directory, and issue the commandjava -jarinstall.jar

3. Follow the instructions in the Installer

4. Copy the filejintegra.jar found inc: \Program Files \JIntegra \LIBto c: \arakne \Jars \

B.4 Starting the Construct Servers

In thec: \arakne directory, there are three batch filesstartNameLoc.bat , startM-SIS.bat , andstartHsHm.bat . Start these batch files in this order, and wait forthe servers to be ready.

B.5 Starting the Arakne Environment

The Arakne Environment can then be started using therunme.bat file found in thec: \arakne directory. It will upon launch check whether its JAR files are current, andif not, automatically retrieve and install them.

Appendix C

Vocabulary

API Application Programming Interface. A set of interfaces allowing programs tointeract with a system.

Arakne (English: Arachne) Mythological Greek princess turned into the first spiderby the vengeful Pallas Athena.

CGI Common Gateway Interface. A standard for communicating with programs run-ning on a Web server through a Web browser.

Construct The OHSWG compliant server family developed at University of Aarhusand Aalborg University Esbjerg.

Context A set of hypermedia structure entities, such as links, anchors, endpoints, com-posites, etc. A context is in the OHSWG standard defined as a set of GUIDs. Acontext can contain other contexts, ´ But not directly or indirectly itself. Knownin other hypermedia systems as hyperspace (DHM, Hypervise), hyperWeb (Chi-mera), link base (DLS, XLink), Web (Intermedia) and so on.

Editor A program able to display and modify some media type, e.g. text, video, Worddocuments, Web pages, etc.

GUID Globally Unique Identifier.

Hypermedia The combination of contents (e.g. a set of documents of any media type)and structure (e.g. a set of links) that establish relationships between parts ofthe content. The traditional hypermedia model has been navigational, i.e. linksand anchors, but hypermedia is not no longer limited to that kind of structuringmechanism.

Intersubjectivity Reflective shared awareness. I know that you know that I know.

IPC Interprocess Communication.

Java Sandbox Security restrictions put upon Java applets. Java applets cannot contactforeign (i.e. different from their originating Web server) servers, foreign Javaapplets, other processes, or access the local file system.

Link A relation between endpoints. The classic hypermedia link consisted of twoendpoints, a beginning and an end, but this was with Dexter [62] generalisedinto a set of endpoints.

85

86 APPENDIX C. VOCABULARY

Link decoration Inserting links, annotations, etc. into a Web page.

LocSpec Location Specifier. A value that specifies a selection in a document of somemedia type. A LocSpec may contain redundancy to support link recovery. Intro-duced by Grønbæk and Trigg in [57].

Monolithic Hypermedia Hypermedia systems that rely on specially developed edi-tors, rather than integrating third-party editors. Often, but not always, relianton proprietary file formats. Examples: KMS, Intermedia, the World Wide Web.Structures such as links may be stored externally of documents.

Navigational Hypermedia Hypermedia structuring with links, anchors, and endpoints.Traditionally, this has denoted what hypermedia is, and characterises many tra-ditional systems, such as KMS or the World Wide Web. Hypermedia today alsocovers other structuring mechanisms, such as guided tours, spatial or taxonomichypermedia.

Navlet See View.

OHP Open Hypermedia Protocol. The hypermedia architecture designed by the OHSWG.Supported by the Construct servers and the Arakne Environment.

OHSWG Open Hypermedia Systems Working Group. A group composed of the cur-rently active open hypermedia research groups. The main purpose of OHSWGis to design a shared open hypermedia standard (OHP) allowing all open hyper-media systems to interoperate.

Open Hypermedia Hypermedia systems, that exclusively or largely integrate third-party editors. This generally implies externally stored hypermedia structures, as“foreign” file formats often not will have provisions for linking etc. Examples:Microcosm, HyperDisco, Webvise, the Arakne Environment.

View A tool running in the Arakne Environment (previously known as “Navlets”).Views can for instance be hypermedia tools such as Ariadne, CAOS, and Navette.

Viewer A read-only editor — most Web browsers and image viewers are good exam-ples of viewers.

Bibliography

[1] R. M. Akscyn, D. L. McCracken, and E. A. Yoder. KMS: A distributed hyper-media system for managing knowledge in organizations.Communications of theACM, 31(7):820–835, July 1988.

[2] K. M. Anderson. Integrating open hypermedia systems with the World WideWeb. In M. Bernstein, L. Carr, and K. Østerbye, editors,Proceedings of the 8th

ACM Hypertext Conference, pages 157–166, Southampton, UK, Apr. 1997.

[3] K. M. Anderson. Issues of data scalability in open hypermedia systems.TheNew Review of Hypermedia and Multimedia, 5:151–178, 1999.

[4] K. M. Anderson. Scalability in open hypermedia systems. InProceedings ofthe 10th ACM Hypertext Conference, pages 27–36, Darmstadt, Germany, Feb.1999.

[5] K. M. Anderson. Supporting industrial hyperwebs: Lessons in scalability. InProceedings of the 21st International Conference on Software Engineering,pages 573–582, Los Angeles, CA, USA, May 1999.

[6] K. M. Anderson and N. O. Bouvin. Enabling project awareness and intersubjec-tivity via hypermedia-enabled event trails. Submitted for publication.

[7] K. M. Anderson, R. N. Taylor, , and E. J. Whitehead, Jr. Chimera: Hypermediafor heterogeneous software development environments.ACM Transactions onInformation Systems, 18(3), July 2000.

[8] K. M. Anderson, R. N. Taylor, and E. J. Whitehead Jr. Chimera: Hypertext forheterogeneous software environments. InProceedings of the European Con-ference on Hypermedia Technology (ECHT 1994), pages 97–107, Edinburgh,Scotland, Sept. 1994.

[9] K. Andrews, F. Kappe, and H. Maurer. Serving information to the Web withHyper-G.Computer Networks and ISDN Systems, 27(6), 1995.

[10] L. Bannon and K. Schmidt. CSCW: Four characters in search of a context.In J. M. Bowers and S. D. Benford, editors,Studies in Computer SupportedCooperative Work. Elsevier Science Publishers B. V. (North-Holland), 1991.

[11] L. Bannon and K. Schmidt. Taking CSCW seriously.CSCW Journal, 1(1–2),1992.

87

88 BIBLIOGRAPHY

[12] R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor,and G. Wötzel. Basic support for co-operative work on the World Wide Web.International Journal of Human Computer Studies, 1997.

[13] T. Berners-Lee. The World Wide Web — past, present and future.Journalof Digital information, 1(1), 1997. http://jodi.ecs.soton.ac.uk/Articles/v01/i01/BernersLee/ .

[14] T. Berners-Lee, R. Cailliau, J.-F. Groff, and B. Pollerman. World-Wide Web:The information universe.Electronic Networking: Research, Applications andPolicy, 1(2), 1992.

[15] N. O. Bouvin. Collaborative Web-based open hypermedia and mutual aware-ness. Submitted for publication.

[16] N. O. Bouvin. Designing open hypermedia applets: Experiences and prospects.In Proceedings of the 9th ACM Hypertext Conference, pages 281–282, Pitts-burgh, USA, 1998.

[17] N. O. Bouvin. Unifying strategies for Web augmentation. InProceedings ofthe 10th ACM Hypertext Conference, pages 91–100, Darmstadt, Germany, Feb.1999.

[18] N. O. Bouvin. Designing user interfaces for collaborative Web-based open hy-permedia. InProceedings of the 11th ACM Hypertext Conference, pages 230–231, San Antonio, USA, May 2000.

[19] N. O. Bouvin. Experiences with OHP and issues for the future. InProceedingsof the Open Hypermedia Systems Workshop 6.0 Hypertext 2000, number 1903in Lecture Notes in Computer Science. Springer, 2000.

[20] N. O. Bouvin and R. Schade. Integrating temporal media and open hypermediaon the World Wide Web.Computer Networks — The International Journal ofComputer and Telecommunications Networking, (31):1453–1465, 1999.

[21] E. Bradner, W. A. Kellogg, and T. Erickson. The adoption and use of ’BABBLE:A field study of chat in the workplace. In S. Bødker, M. Kyng, and K. Schmidt,editors,Proceedings of the 6th European Conference on Computer SupportedCooperative Work, pages 139–158, Copenhagen, Denmark, Sept. 1999. KluwerAcademic Publishers.

[22] M. Büscher, P. Mogensen, D. Shapiro, and I. Wagner. The Manufaktur: Sup-porting work practice in (landscape) architecture. In S. Bødker, M. Kyng, andK. Schmidt, editors,Proceedings of the 6th European Conference on ComputerSupported Cooperative Work, pages 21–40, Copenhagen, Denmark, Sept. 1999.Kluwer Academic Publishers.

[23] V. Bush. As we may think.The Atlantic Monthly, pages 101–108, July 1945.

[24] L. A. Carr, W. Hall, and S. Hitchcock. Link services or link agents? InProceed-ings of the 9th ACM Hypertext Conference, pages 113–122, Pittsburgh, USA,1998.

BIBLIOGRAPHY 89

[25] L. A. Carr, D. D. Roure, W. Hall, and G. Hill. The distributed link service: Atool for publishers, authors and readers. InProceedings of the 4th InternationalWorld Wide Web Conference, Boston, USA, 1995. W3C.

[26] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. Achieving scalability andexpressiveness in an Internet-scale event notification service. InProceedings ofthe 19th ACM Symposium on Principles of Distributed Computing, July 2000.

[27] J. Clark and S. DeRose (editors). XML Path language (XPath) version 1.0. W3CRecommendation 16 November 1999, W3C, Nov. 1999.http://www.w3.org/TR/xpath .

[28] I. Clarke. A distributed decentralised information storage and retrieval sys-tem. Technical report, Division of Informatics, University of Edinburgh, 1999.http://www.freenetproject.org/freenet.pdf .

[29] A. Clement. Considering privacy in the development of multi-media communi-cations.CSCW Journal, 2(1–2), 1994.

[30] R. Daniel, S. DeRose, and E. Maler (editors). XML Pointer Language(XPointer). W3C Working Draft 6 December 1999, W3C, Dec. 1999.http://www.w3.org/TR/xptr .

[31] C. X. D’Arlach and J. J. Leggett. HyperEd: a spatial hypertext editor. Techni-cal Report TAMU-HRL-94-005, Department of Computer Science, Texas A&MUniversity, 1994.

[32] H. C. Davis. Referential integrity of links in open hypermedia systems. InProceedings of the 9th ACM Hypertext Conference, pages 207–216, Pittsburgh,USA, 1998.

[33] H. C. Davis, W. Hall, I. Heath, G. Hill, and R. Wilkins. Towards an integratedinformation environment with open hypermedia systems. In D. Lucarella, J. Na-nard, M. Nanard, and P. Paolini, editors,Proceedings of the ACM Hypertext 1992Conference, pages 181–190, Milan, Italy, Nov. 1992.

[34] H. C. Davis, S. Knight, and W. Hall. Light hypermedia link services: A study ofthird party integration. InProceedings of the European Conference on Hyper-media Technology (ECHT 1994), pages 41–50, Edinburgh, UK, Sept. 1994.

[35] H. C. Davis, D. E. Millard, S. Reich, N. O. Bouvin, K. Grønbæk, K. M. Ander-son, U. K. Wiil, P. J. Nürnberg, and L. Sloth. Interoperability between hyperme-dia systems: The standardisation work of the OHSWG. InProceedings of the10th ACM Hypertext Conference, pages 201–202, Darmstadt, Germany, 1999.

[36] Delta-V Working Group.http://www.webdav.org/wg/#dv .

[37] S. DeRose, E. Maler, D. Orchard, and B. Trafford (editors). XML LinkingLanguage (XLink). W3C Working Draft 21 February 2000, W3C, Feb. 2000.http://www.w3.org/TR/xlink/ .

[38] P. Dourish and S. Bly. Portholes: Supporting awareness in a distributed workgroup. InProceedings of the ACM Conference on Human Factors in ComputingSystems, pages 541–547, May 1992.

90 BIBLIOGRAPHY

[39] D. Engelbart. A conceptual framework for the augmentation of man’s intellect.In P. Howerton, editor,Vistas in Information Handling, volume 1, pages 1–29.Spartan Books, Washington DC, USA, 1963.

[40] D. Engelbart. Authorship provisions in Augment. InProceedings of the IEEECompcon Conference, San Francisco, USA, 1984. IEEE.

[41] G. Fitzpatrick, T. Mansfield, S. Kaplan, D. Arnold, T. Phelps, and B. Segall.Augmenting the workaday world with Elvin. In S. Bødker, M. Kyng, andK. Schmidt, editors,Proceedings of the 6th European Conference on ComputerSupported Cooperative Work, pages 431–450, Copenhagen, Denmark, Sept.1999. Kluwer Academic Publishers.

[42] A. M. Fountain, W. Hall, I. Heath, and H. C. Davis. Microcosm: An openmodel for hypermedia with dynamic linking. In A. Rizk, N. Streiz, and J. An-drè, editors,Proceedings of the European Conference on Hypertext, CambridgeUniversity Press, U.K., 1990.

[43] L. Fuchs. AREA: A cross-application notification service for groupware. InS. Bødker, M. Kyng, and K. Schmidt, editors,Proceedings of the 6th EuropeanConference on Computer Supported Copperative Work, pages 61–80. KluwerAcademic Publishers, Sept. 1999.

[44] L. Fuchs, U. Pankoke-Babatz, and W. Prinz. Supporting cooperative awarenesswith local event mechanisms: The GroupDesk system. InProceedings of the 4th

European Conference on Computer Supported Cooperative Work, pages 247–262, Stockholm, Sweden, 1995.

[45] R. Furuta, F. M. Shipman III, C. C. Marshall, D. D. Brenner, and H.-W. Hsieh.Hypertext paths and the World-Wide Web: Experiences with Walden’s Paths. InM. Bernstein, L. Carr, and K. Østerbye, editors,Proceedings of the 8th ACMHypertext Conference, pages 167–176, Southampton, UK, Apr. 1997.

[46] S. Goose, J. Dale, W. Hall, and D. D. Roure. Microcosm TNG: a distributed ar-chitecture to support reflexive hypermedia applications. In M. Bernstein, L. Carr,and K. Østerbye, editors,Proceedings of the 8th ACM Hypertext Conference,pages 226–227, Southampton, UK, Apr. 1997.

[47] K. Grønbæk. Eurocode workpackage wp2 task t2.2 report: Object orientedmodel for the distributed hypermedia toolkit. Technical Report CODE-AU-93-10, Aarhus University, Denmark, July 1993.

[48] K. Grønbæk, N. O. Bouvin, and L. Sloth. Designing Dexter-based hyperme-dia services for the World Wide Web. In M. Bernstein, L. Carr, and K. Øster-bye, editors,Proceedings of the 8th ACM Hypertext Conference, pages 146–156,Southampton, UK, Apr. 1997.

[49] K. Grønbæk, J. A. Hem, O. L. Madsen, and L. Sloth. Designing Dexter-basedcooperative hypermedia systems. InProceedings of the 5th ACM HypertextConference, pages 25–38, Seattle, USA, Nov. 1993.

[50] K. Grønbæk, J. A. Hem, O. L. Madsen, and L. Sloth. Cooperative hypermediasystems: A Dexter-based architecture.Communications of the ACM, 37(2):64–74, Feb. 1994.

BIBLIOGRAPHY 91

[51] K. Grønbæk and J. Malhotra. Building tailorable hypermedia systems: theembedded-interpreter approach. InProceedings of the 9th conference on ObjectOriented Programming Systems, Language, and Applications (OOPSLA 1994),pages 85–101. ACM, 1994.

[52] K. Grønbæk and P. J. Nürnberg. Technical documentation for the COCONUThypermedia services and infrastructure (Part 1). IM working papers 3, Interme-dia, University of Aarhus, Denmark, 1999.

[53] K. Grønbæk and P. J. Nürnberg. Technical documentation for the COCONUThypermedia services and infrastructure (Part 2). IM working papers 3, Interme-dia, University of Aarhus, Denmark, 1999.

[54] K. Grønbæk, L. Sloth, and N. O. Bouvin. Open hypermedia as user controlledmeta data for the Web. InProceeding of the 9th World Wide Web Conference,pages 553–566, Amsterdam, Holland, May 2000. W3C.

[55] K. Grønbæk, L. Sloth, and N. O. Bouvin. Open hypermedia as user controlledmeta data for the Web.Computer Networks, (33):553–566, 2000.

[56] K. Grønbæk, L. Sloth, and P. Ørbæk. Webvise: browser and proxy supportfor open hypermedia structuring mechanisms of the World Wide Web. InPro-ceedings of the 8th International World Wide Web Conference, pages 253–267,Toronto, Canada, 1999. W3C.

[57] K. Grønbæk and R. H. Trigg. Toward a Dexter-based model for open hyperme-dia: Unifying embedded references and link objects. InProceedings of the 7th

ACM Hypertext Conference, pages 149–160, Washington DC, USA, 1996.

[58] J. M. Haake, T. Knopik, and N. Streitz. The SEPIA hypermedia system as partof the POLIKOM telecooperation scenario. InProceedings of the 5th ACMHypertext Conference, pages 235–237, Seattle, USA, Nov. 1993.

[59] J. M. Haake and B. Wilson. Supporting collaborative writing of hyperdocu-ments in SEPIA. InConference proceedings on Computer-supported coopera-tive work, pages 138–146, Toronto, Canada, Nov. 1992.

[60] F. G. Halasz. Reflections on NoteCards: Seven issues for the next generation ofhypermedia systems.Communications of the ACM, 31(7):836–852, 1988.

[61] F. G. Halasz, T. P. Moran, and R. H. Trigg. NoteCards in a nutshell. InProceed-ings of ACM Conference on Human Factors in Computing Systems and GraphicsInterface, pages 45–52, Toronto, Canada, Apr. 1987.

[62] F. G. Halasz and M. Schwartz. The Dexter hypertext reference model.Commu-nications of the ACM, 37(2):30–39, Feb. 1994.

[63] W. Hall, H. C. Davis, and G. Hutchings.Rethinking Hypermedia: The Micro-Cosm Approach. Kluwer Academic Publishers, Norwell, USA, 1996.

[64] B. Halsey and K. M. Anderson. XLink and open hypermedia systems: A pre-liminary investigation. InProceedings of the 11th ACM Hypertext Conference,pages 212–213, San Antonio, USA, May 2000.

92 BIBLIOGRAPHY

[65] C. Heath and P. Luff. Collaboration and control: Crisis management and multi-media technology in London Underground line control rooms.CSCW Journal,1(1–2):69–94, 1992.

[66] J. Jühne, A. T. Jensen, and K. Grønbæk. Ariadne: A Java-based guided toursystem for the World Wide Web. InProceedings of the 7th International WorldWide Web Conference, Brisbane, Australia, 1998. W3C.

[67] C. J. Kacmar and J. J. Leggett. PROXHY: A process-oriented extensible hyper-text architecture.ACM Transactions of Information Systems, 9(4):399–419, Oct.1991.

[68] P. Kahn, J. M. Nyce, T. Oren, G. Crane, L. C. Smith, R. Trigg, and N. Meyrowitz.From Memex to hypertext: understanding the influence of Vannevar Bush. InProceedings of the 3rd ACM Conference on Hypertext, page 361, San Antonio,USA, Dec. 1991.

[69] R. Killough and J. J. Leggett. Hypertext interchange with the Dexter model:Intermedia to KMS. TAMU-HRL 90-002, Hypertext Research Lab, Texas A&MUniversity, Aug. 1990.

[70] O. Lassila and R. R. Swick (editors). Resource Description Framework (RDF)model and syntax specification. W3C Recommendation 22 February 1999,W3C, Feb. 1999.http://www.w3.org/TR/REC-rdf-syntax/ .

[71] J. J. Leggett and J. L. Schnase. Viewing Dexter with open eyes.Communicationsof the ACM, 37(2):77–86, Feb. 1994.

[72] G. Mark, N. A. Streiz, and J. M. Haake. Hypermedia use in group work: Chang-ing the product, process, and strategy.Computer Supported Cooperative Work:The Journal of Collaborative Computing, (6):327–368, 1997.

[73] C. C. Marshall. Toward an ecology of hypertext annotation. InProceedings ofthe 9th ACM Hypertext Conference, pages 40–49, Pittsburgh, USA, 1998. ACM.

[74] C. C. Marshall and F. M. Shipman III. Spatial hypertext: Designing for change.Communications of the ACM, 38(8):88–97, 1995.

[75] H. Maurer.Hyperwave — The Next Generation Web Solution. Addison Wesley,1996.

[76] M. Melly and W. Hall. Version control in Microcosm. In D. Hicks, A. Haake,D. Durand, and F. Vitali, editors,Proceedings of the ECSCW’95: Workshopon the Role of Version Control in CSCW Applications, number 289 in GMD-Studien, GMD-IPSI, Darmstadt, Germany, Apr. 1996.

[77] N. K. Meyrowitz. Intermedia: The architecture and construction of an object-oriented hypermedia system and applications framework. InProceedings ofACM conference on Object Oriented Programming Systems, Languages and Ap-plications (OOPSLA 86), 1986.

[78] N. K. Meyrowitz. The missing link: Why we’re all doing hypertext wrong. InE. Barrett, editor,The society of text: Hypertext, hypermedia and the social con-struction of information, pages 107–114. MIT Press, Cambridge, USA, 1989.

BIBLIOGRAPHY 93

[79] P. Mogensen and K. Grønbæk. Hypermedia in the virtual project room – towardopen 3d spatial hypermedia. In F. M. Shipman, III, editor,Proceedings of the11th ACM Hypertext Conference, pages 113–122. ACM, May 2000.

[80] T. H. Nelson. Replacing the printed word.Information Processing, pages 1013–1023, 1980.

[81] P. J. Nürnberg.HOSS: An Environment to Support Structural Computing. PhDthesis, Department of Computer Science, Texas A&M University, College Sta-tion, Texas, USA, 1997.

[82] P. J. Nürnberg and H. Ashman. What was the question? reconciling open hyper-media and world wide web research. InProceedings of the 10th ACM HypertextConference, pages 83–90, Darmstadt, Germany, 1999.

[83] P. J. Nürnberg, J. J. Leggett, E. R. Schneider, and J. L. Schnase. Hypermediaoperating systems: A new paradigm for computing. InProceedings of the 7th

ACM Hypertext Conference, pages 194–202, Washington DC, USA, Mar. 1996.

[84] P. J. Nürnberg, E. R. Schneider, and J. J. Leggett. Designing digital libraries forthe hyperliterate age.Journal of Universal Computer Science, 2(9):610–622,1996.

[85] J. F. Patterson, M. Day, and J. Kucan. Notification servers for synchronousgroupware. InProceedings of the Conference of Computer Supported Coopera-tive Work, pages 122–129, Boston, USA, 1996.

[86] A. Pearl. Sun’s link service: A protocol for open linking. InProceedings ofthe 2nd ACM Conference on Hypertext, pages 137–146, Pittsburgh, USA, Nov.1989.

[87] T. A. Phelps and R. Wilensky. Robust intra-document locations. InProceedingof the 9th World Wide Web Conference, pages 105–118, Amsterdam, Holland,May 2000. W3C.

[88] W. Prinz. NESSIE: An awareness environment for cooperative settings. InS. Bødker, M. Kyng, and K. Schmidt, editors,Proceedings of the 6th EuropeanConference on Computer Supported Copperative Work, pages 391–410. KluwerAcademic Publishers, Sept. 1999.

[89] O. Reinert, D. Bucka-Lassen, C. A. Pedersen, and P. J. Nürnberg. CAOS: A col-laborative and open spatial structure service component with incremental spatialparsing. InProceedings of the 10th ACM Hypertext Conference, pages 49–50,Darmstadt, Germany, 1999.

[90] J. L. Schnase, J. J. Leggett, D. L. Hicks, P. J. Nürnberg, and J. A. Sánchez. De-sign and implementation of the hb1 hyperbase management system.ElectronicPublishing — Origination, Dissemination and Design, 6(1):125–150, 1993.

[91] J. L. Schnase, J. J. Leggett, D. L. Hicks, P. J. Nürnberg, and J. A. Sánchez.Open architectures for integrated, hypermedia-based information systems. InProceedings of the 27th Hawaii International Conference of Systems Sciences,Maui, Hawaii, USA, Jan. 1994.

94 BIBLIOGRAPHY

[92] N. A. Streitz, J. Geißler, J. M. Haake, and J. Hol. Dolphin: integrated meet-ing support across local and remote desktop environments and liveboards. InProceedings of the conference on Computer supported cooperative work, pages345–358, Chapel Hill, USA, Oct. 1994.

[93] N. A. Streiz, J. M. Haake, J. Hannemann, A. Lemke, W. Schuler, H. Schütt,and M. Thüring. SEPIA: A cooperative hypermedia authoring environment. InProceedings of the European Conference on Hypermedia Technology (ECHT1992), pages 11–22, Milan, Italy, 1992.

[94] R. H. Trigg, L. A. Suchman, and F. G. Halasz. Supporting collaboration in Note-Cards. InProceedings of the Conference on Computer-Supported CooperativeWork, pages 153–162, 1986.

[95] E. J. Whitehead Jr. An architectural model for application integration in openhypermedia environments. In M. Bernstein, L. Carr, and K. Østerbye, editors,Proceedings of the 8th ACM Hypertext Conference, pages 1–12, Southampton,UK, Apr. 1997.

[96] E. J. Whitehead Jr. Control choices and network effects in hypertext systems. InProceedings of the 10th ACM Hypertext Conference, pages 75–82, Darmstadt,Germany, Feb. 1999.

[97] E. J. Whitehead, Jr., K. M. Anderson, and R. N. Taylor. A proposal for ver-sioning support for the chimera system. InProceeedings of the Workshop onVersioning in Hypertext Systems. Held in connection with ECHT ’94, pages 45–54, Edinburgh, Scotland, Sept. 1994.

[98] E. J. Whitehead Jr. and Y. Y. Goland. WebDAV: A network protocol for remotecollaborative authoring on the Web. In S. Bødker, M. Kyng, and K. Schmidt,editors,Proceedings of the 6th European Conference on Computer SupportedCooperative Work, pages 291–310, Copenhagen, Danmark, 1999. Kluwer Aca-demic Publishers.

[99] U. K. Wiil. Issues in the design of EHTS: A multiuser hypertext system for col-laboration. InProceedings of the 25th IEEE Hawaii International Conferenceon System Sciences, volume 2, pages 629–639, 1992.

[100] U. K. Wiil. Experiences with HyperBase: A multiuser hypertext database.ACMSIGMOD RECORD, 22(4):19–25, Dec. 1993.

[101] U. K. Wiil. Hyperform: Rapid prototyping of hypermedia services.Communi-cations of the ACM, 38(8):109–111, 1995.

[102] U. K. Wiil and J. J. Leggett. The HyperDisco approach to open hypermediasystems. InProceedings of the 7th ACM Hypertext Conference, pages 140–148,Washington DC, USA, Mar. 1996.

[103] U. K. Wiil and J. J. Leggett. Workspaces: The HyperDisco approach to Internetdistribution. In M. Bernstein, L. Carr, and K. Østerbye, editors,Proceedings ofthe 8th ACM Hypertext Conference, pages 13–23, Southampton, UK, Apr. 1997.

BIBLIOGRAPHY 95

[104] U. K. Wiil and P. J. Nürnberg. Implications of open hypermedia systems re-search for the World Wide Web. InProceedings of the 3rd IASTED Interna-tional Conference on Internet and Multimedia Systems and Applications (IMSA’99), pages 296–304, Nassau, Bahamas, Oct. 1999.

[105] U. K. Wiil, P. J. Nürnberg, D. Hicks, and S. Reich. A development environmentfor building component-based open hypermedia systems. In F. M. Shipman,III, editor, Proceedings of the 11th ACM Hypertext Conference, pages 266–267.ACM, May 2000.

[106] N. Yankelovich, B. J. Haan, N. K. Meyrowitz, and S. M. Drucker. Interme-dia: the concept and the construction of a seamless information environment.Computer, pages 81–96, Jan. 1988.

Unifying Strategies for Web Augmentation Niels Olof Bouvin

Aarhus University, Department of Computer Science,

Aabogade 34A, DK8200 Aarhus N, Denmark bouvin@daimi.aau.dk

ABSTRACT Since the beginning of the WWW, tools have been devel- oped to augment the functionality of the Web. This paper provides an investigation of hypermedia tools and systems integrating the World Wide Web with focus on functionality and the techniques used to achieve this functionality. Simi- larities are found and based on this, a new framework, the Arakne framework, for developing and thinking about Web augmentation is presented. The Arakne framework is flexi- ble and supports most kinds of Web augmentation. Finally an implementation of the Arakne framework is described and discussed.

KEYWORDS Web Integration, Open Hypermedia Systems, Open Hyper- media Protocol, Collaboration on the Web, Unifying inter- faces, Common Reference Architecture for open hyperme- dia systems, Java

INTRODUCTION The World Wide Web has in an amazing short time span become the hitherto largest hypertext and is pervasive in everyday life as few things before. This success has in part been attributed to the simple architecture behind the Web: A stateless file transfer protocol (HTTP), an universal Internet naming scheme (URL) and an easily understood document format (HTML). These standards have (largely) been ad- hered to, and this has enabled the creation of a large amount of software, be it Web servers or browsers to work together to the benefit of all.

The success of this simple and hugely scaleable architecture has come, from the standpoint of the hypermedia research community, at some costs, as the Web itself is lacking in the ways of more advanced (but ironically often far older) hy- permedia systems. Web links are unidirectional jump links, embedded in the HTML documents, severely diminishing the flexibility of use. There is yet no widespread support for collaborative ‘authoring, though an initiative such as WebDAV [ 131) holds great promise.

An important development in the hypermedia community in the nineties has been the focus on and development of open

Permission to makt: digital or hard copi,, of all or part ~tfthis work for per~mal or class~~on~ US IS ganted without fee prwiided that copies arc not rrude or tlistrlbutcd Ihr prvlil or commercial advnnlapc and that topics bear this notlcc and the tillI citation on ~hc first page. TO COP>

&w-wise. to republish, to post on xrw!~‘s or to redistribute to lists. rquirzs prior sprcific pumission ar&or il fee. Hypertext 99 Darmstndt Germany Copyright ACM 1999 l-58113-064-3/99/2...$5.00

hypermedia systems integrating third-party applications. Significant work has been done in systems such as Micro- Cosm [9][20], HyperDisco [44][45], HOSS [32], DHM [ 14][ 151, and Chimera [ 11. These systems have all addressed the problem of augmenting third-party applications, and the lessons learned are important guidelines for future work of Web augmentation. Based on these experiences,, taxono- mies and studies have been developed, by Whitehead [43], Granbaek & Wiil [17], and Wiil & asterbye [46][48], to help researchers and developers discuss and reason about the open hypermedia field and how to utilise hypermedia in third-party applications. Given this experience of integration it should come as no surprise that the open hypermedia community was quick to develop open hypermedia Web integrations, e.g. DLS [7], DHM/WWW [16], and Chimera [2]. This article will investigate how they and others achieved their goals of Web augmentation.

Adhering to standards has a large part of the success of the Web and the very size of the Web has enormous inertia, so an attempt to replace the Web with something perhaps more advanced in certain aspects is, if not doomed, then up against tremendous odds. Clearly this is not the way to im- prove the Web. An approach that retains the benefits of the Web as well as adding new desired functionality is the de- velopment of systems that operate within Web standards, be it HTTP, HTML, browsers, or servers. This is in spirit with Meyrowitz’ call for hypermedia integration in third-party applications [27], and the amount and quality of work done using this approach would suggest that it is at the very least possible.

AN OVERVIEW OF WEB AUGMENTATION STRATEGIES As the scope of this article is to study the techniques used in Web augmentation tools, an overview of augmentation approaches is in order. This overview will work at two lev- els of abstraction: first a broad grouping based on the func- tionality of the tools and later a more specific characterisa- tion of the individual tool. This characterisation will be based on the chosen approach to common problems, such as storage, Web browser integration, level of support for col- laboration, and so forth. The former level of abstraction will let us discuss and compare related tools, while the latter will allow us to recognise reoccurring themes in the approaches taken.

A tool shall be considered a Web hypermedia augmentation tool, if it through integration with a Web browser, a HTTP proxy or a Web server adds content or controls not con- tained within the Web pages themselves to the effect of allowing structure to be added to the Web page directly or indirectly, or to navigate such structure. The purpose of such

91

a tool is help users organise, associate, or structure informa- tion found on the Web. This activity may be done by a sin- gle user or in collaboration with others.

Following this definition, the purpose of the Web augmen- tations reviewed for this article is to help users structuralise their Web work. Either by adding structure and displaying it, or by extracting structure already present and making it more visible. The displayed structure may be malleable, allowing the user to modify it. The Web augmentation tools reviewed for this article have been divided into four catego- ries:

+ Annotations/Discussion support + Link creation and transversal + Guided tours l Structuring/Spatial

We claim no universality to this categorisation, but have found it handy when discussing the Web augmentation tools and their use.

A Web augmentation tool can be classified by the schema summarised in Table 1. Thus a tool can either be a part of a Web browser; it can be an closely integrated tool loaded on runtime; it can reside temporarily within the browser as an applet or an ActiveX control; it can be an application run- ning the user’s computer; or it can be located elsewhere (in that case more often than not as a H’X”TP server or proxy).

The Web augmentation tool can either have no storage re- quirements; it can store it data locally on the host computer, or remotely on a server.

Many of these Web augmentation tools modify Web pages, either to insert interfaces of their own or to add structure (e.g. links) to the Web page. This modification can take place at the Web server (perhaps a Web server translating a proprietary data format into HTML), by calling CGI-scripts that return modified pages, by using a special proxy, or by modifying the Web pages as or after they are displayed in the Web browser.

As for the collaborative aspect, a Web augmentation tool can either be strictly personal, i.e. relevant to a single user only; the created data or structures can be shared (e.g. send to another user or placed on a Web site); the structures can browsed or edited by turn-taking (asynchronously); or users can collaborale through the structures in real time (synchro- nously).

WEB AUGMENTATION TOOLS In this section we will describe various Web augmentation tools focusing on the elements introduced by Table 1. The scope of this article does not allow for a comprehensive study nor a general survey, so only a subset of the existing Web augmentation tools is presented.

Annotations/Discussion support Bush envisioned marginalia in the Memex [5], and the inter- est in annotations and how they should be supported by hypermedia has not diminished over the years, as witnessed

by the investigation done by Marshall 1251.

The first widely successful Web browser, NCSA Mosaic [30], gave the user the opportunity to create annotations to Web pages. The annotations were personal and stored lo- cally. Later, this feature fell out of favour with Web browser developers.

Recognising that annotations whilst useful for the individual are even more beneficial for a community, several collabo- rative annotation tools have been created. Rascheisen et al.[35][36] have developed ComMentor, which have used for several purposes, including content rating and annota- tions. The system employs a Mosaic [30] browser, modified to provide an interface to the annotation server, which con- sists of a collection of CGI-scripts. The user has alongside with the browser a merge library, which inserts comments and links to comments into the Web pages. Annotations are stored in sets, of which the user may activate an arbitrary

Method of integration A part of the browser Browser add-ons Within the browser (plug-ins, applets and JavaScript) Without the browser, local Without the browser, remote Within the proxy Within the Web server Location of storage No storage Local storage Remote storage Web page modification No modification At the Web server CGI-scripts at a Web server At the proxy In the browser Level of collaboration supported Personal Shareable Asynchronous collaborative

, Synchronous collaborative

Table I - A classification scheme of Web augmentation tools

number. Collaborative annotation is supported through di- viding users into groups that may share sets of annotations. A set of annotations can be set to be private, available to a group, or publicly available. Annotations are displayed using in-place markers (small pictures) indicating either the nature of the annotation or the author’s identity. An annota- tion while write-protected may also be annotated.

Another system is CritLink Mediator, part of CritSuite [lo], which is specialised to provide support for ‘critical discus- sions’. CritLink employs predefined typed links (support, issue, comment, query) akin to many hypermedia systems, such as IBIS [34] and TEXTNET [40]. The comments are created by a mix of CGI-scripts, Web forms, and JavaScript and stored either on a designated server or in the user’s own Web space as ordinary Web pages. Links to the comments

92

are inserted into Web pages by use of a Web server effec- tively acting as a proxy server. The pages are also modified to include a tool bar used for navigation, annotation, and the launch of CritMap [39], a tool that generates maps of neigh- bourhood Web pages. Links in pages presented by the server are modified to go through the server. As comments are Web pages in their own right, they can also be commented on. There are only one set of annotations and no notion of groups, though the individual user is identified.

Creating links As noted in the introduction, quite a few research projects have addressed the issue of adding external structures to Web pages. An excellent investigation of the various ap- proaches taken by the open hypermedia community can be found in [2]. There are two main approaches: links (or other kinds of structural information) are either displayed along- side the Web page or inserted into the Web page. The for- mer case requires either a program to display this structure or a browser window where the structure has been converted to HTML. The latter case involves modifying HTML pages on the fly, which can be done at three places: at the origin, in transit or at arrival, i.e. the Web server, the HTTP proxy, or the Web browser.

Chimera [1][2] is an example of a system, where experi- ments with either displaying structure information in a sepa- rate program (an applet) or making the structure server ac- cessible through HTTP have been carried out. By modifying a Web server to interpret HTTP requests as requests to a Chimera server to which the Web server is hooked up and in turn translating the Chimera structures to HTML, a user is able to browse the hypermedia structure using an ordinary Web browser. This experiment was extended upon by the creation of a Java applet capable of displaying Chimera hypermedia structures. By the combination of a special Web server, CGI-scripts and cookies, this applet was inserted into all pages displayed in the Web browser, giving the user immediate access to Chimera services.

Hyper-G [26] is a more specialised system, as it to achieve full functionality relies on a special document format (HTF - Hypertext Format), a special server, and a custom browser. It is however possible to interface to the system using an ordinary Web browser using a special WWW- gateway, that will translates HTF document and hypermedia structure to HTML. The hypermedia system offers strong support for hierarchical structures and searching, and allows users without a special browser to create links using forms. In recent versions HyperWave [22] (as the system is now known) offers an advanced interface utilising Java-applets and JavaScript inserted into Web pages by the HyperWave server.

DLS [6] (Distributed Link Service) is based on the Micro- Cosm hypermedia system [7][9][20]. The first DLS systems used a wrapper to attach a link service menu to a browser (this integration being dependent on whether an integration existed for the user’s browser), thus creating a (in the termi- nology of Whitehead in [43]) shim integration with a third party application. Links were followed by selection of text and selecting ‘Follow Link’ in the attached menu. This

93

would cause the wrapper to contact the link server with an URL encoding the request, resulting in a Web page of the matching links. To address the problem of having to install special software and to make links more visible, an inter- faceless version was developed that used a link server proxy to insert links in Web pages as requested by the user. The user used a form to configure which link bases to use and how the link should be presented in the document (to make the distinction between links belonging in the document and inserted links clear). Due to performance issues (beyond ‘conventional’ links, Microcosm offers computation inten- sive links, such as keyword links, person links and citation links) and copyright and authors’ rights concerns about adding content to Web pages, a new design was introduced with the AgentDLS [8]. Rather than offering synchronous links (presented together and simultaneously with the docu- ment), links are now displayed in a separate window. This improves the performance of browsing considerably, as the users’ primary window of interest does not have to wait for links to be resolved. The linking service thus takes on a more advisory nature. This system is implemented by using a proxy that (as seen by the Web browser) acts as a normal proxy but also sends the displayed document to a link server agent that resolves the links relevant to the document. The display of these links is handled by having the AgentDLS browser window request a page from the link server agent with regular intervals.

The Devise Hypermedia group, of which the author is a member, has also made various Web integrations with its Dexter-based hypermedia system [ 14][ 1.51. The first attempt was DHM/WWW [ 161. The architecture consisted of a Java- applet communicating through a CGI-script to a DHM server. When the user requested a document by typing its URL in the applet, the applet would retrieve the document while querying the DHM server for endpoints in the docu- ment. The endpoints retrieved was inserted into the Web page as it was being downloaded and displayed in a Web browser window using JavaScript. All links in the Web page were modified so that a click on a link would result in the applet being invoked, allowing it repeat the above described process. The links and endpoints from the DHM server could also be inspected and browsed within the applet. This version had several shortcomings: it was dependent on the user not using bookmarks or entering URLs in the Web browser itself, as such actions would cause the applet to be terminated as its own page would be unloaded. Furthermore it was unable to handle frames (as the loading of a new ‘top’ frame set would also cause the unloading of the applet) and was limited by the ‘sandbox’ imposed for security reasons on Java appletsl. While supported by the DHM server, the DHMiWWW applet could only handle one context (that is one set of hypermedia structures) and had no user concept. A second version, Navette [3], was developed to address some of these issues. Navette was a signed Java applet, allowing the system to use Web pages from arbitrary Web

1 The Java ‘sandbox’ security limits a Java applet in vari- ous ways. Most crucial to DHM/WWW was the restriction of network contact exclusively server, thus making DHM/WWW pages from other web servers.

to the originating web unable to work with web

servers. To speed up communication with the DHM server, TCP/IP and optimistic caching of hypermedia structures (e.g. retrieving a whole context rather than only resolving one link) were used. This version also handled multiple contexts and users. The frame problem remained, and Web pages were still displayed using JavaScript, which made for noticeable degraded performance when browsing with Navette. Simultaneously with Navette, the Webvise client [18], a custom integration with the Microsoft Internet Ex- plorer [28] was being developed. Operating as an applica- tion rather an applet removed the limitations put on DHM/WWW and Navette, and using the Microsoft Internet Explorer [28] rather than the Netscape Communicator [31] allowed Webvise to insert links after the browser had dis- played the document, thus improving performance consid- erably. This is done through DOM [11] and the COM- interface available through the Internet Explorer. A second version of Navette has been developed addressing the prob- lems of prior releases using the Arakne framework, which will described below.

Guided tours Guided tours and trails have been a part of hypermedia from the very beginning [.5], when Bush introduced the concept of the trail linking related documents together. Trigg did more recent groundbreaking work in [41]. Several existing sys- tems try to exploit this idea with Web documents.

Walden’s Paths [12][37] is a system designed mainly to be used in an educational setting, where a teacher composes trails for students to follow. The teacher uses either the Path Authoring Tool (a Java application) or VIKI [38] combined with a browser as an authoring tool. Trails are stored on a Path Server, which through the use of CGI scripts acts as a proxy while modifying the pages to provide an interface to the path. The interface consists of blocks in the top and the bottom of the page. This block is a graphical representation of (a part of) the path plus additional annotations written by the path author. As all documents go through the Path Serv- ers (links in the documents are modified to achieve this), students can go ‘off path’ and still return to the path by pressing a button in the interface block. State is communi- cated by adding arguments into the URL given to the Path Server’s CGI-scripts. The Walden’s Paths has been ex- tended with regards to collaborative aspects, allowing stu- dents to author and share paths of their own. Additionally work has been done to extend upon the linear path by adding conditional blanches. The logic to support this is handled by the Path Server, thus still making all functionality accessible from a standard Web browser.

Another Web-based guided tour system is Ariadne [23], which is a Java-based applet. Ariadne operates in an exter- nal window to the browser and controls the browser through JavaScript. A guided tour in Ariadne is a directed graph, as opposed to the linear (with branches) path of Walden’s Paths. The Ariadne user interface supports both browsing and editing of guided tours. The tours are stored as compos- ites on the Dexter-based DHM [ 151 server. Leaving the Web pages untouched has several advantages to the Walden’s Path approach, as 1) it reduces overhead and complexity as Web documents do not have go through an extra server, and

2) entering URLs or using bookmarks does not pose a problem. On the other hand users are required to use a Java- enabled Web browser rather than any Web browser, though that currentIy is not a strong requirement. The Ariadne sys- tem has recently been adapted to work within the Arakne framework, which will be described in more detail below.

Structuring/Spatial Spatial hypermedia as described by Marshall & Shipman [24] and as implemented in VIKI [37] is a new kind of hy- permedia application, where link structures are no longer explicit but rather implicit based on the spatial relationship between objects. This has become a very powerful tool for organising and structuring, and few hypermedia systems are in more need of organisation and structure than the Web.

Web Squirrel [42] is a URL management system, that uses a spatial metaphor to help users organise their URLs into ‘information farms’. The user creates Neighbourhoods onto which URLs are dragged and dropped. The Neighbourhoods and the URLs are arranged spatial as the user wishes, and are analysed by software agents that can create links be- tween URLs according to user’s rating of the Web sites and maintain link integrity. The user can create new agents using a scripting language. The information farms are stored lo- cally, but can be distributed to other users of Web Squirrel, exported as HTML, or converted to the Hot Sauce MCF format.

Hot Sauce 1211 is a spatial hypermedia plug-in created by Apple. Hot Sauce displays a zoomable 2D representation of a collection of collections and documents. This structure is stored using the XML [47] based Meta Content Format [ 191, a general format to describe meta content (MCF has thus much wider application than its use in Hot Sauce). Links and collections of links are arranged spatial and the user can zoom in and out, move about, and open collections within the collection. If the user double-clicks on a link, the docu- ment is retrieved in a separate window, allowing the user to continue to navigate using Hot Sauce. The Hot Sauce is a media viewer and as such retrieves its MCF file from a Web server.

SUMMARY OF STRATEGIES FOR WEB AUGMENTA- TION The tools and systems described above have addressed many problems pertaining to the current Web, and have utilised a lot of different techniques to attempt to solve these problems. The Web augmentation strategies are, using the schema introduced in Table 1, summarised in Table 2. We will below outline some general trends and describe some of the aspects of writing Web augmentation tools that make developing them hard.

Some patterns become apparent. All of the tools reviewed are responsive and need to be aware of the user’s actions, be it to record the URL of the current Web page or to perform link and endpoint computations. All need to provide the user with a user interface (though it might be very discreet at most times, as in the ‘interfaceless’ DLS). Most of the tools need to store data somewhere and most choose to do this on a remote server, thus raising the need to able to communi-

94

cate over network. The communication is often handled by CGI-scripts, which is problematic, as the tool only gets data when it requests it - the server cannot notify the tool of changes. Many of the tools modify Web pages, and most of the implementations of this functionality would have a hard time interoperating with each other, as they in turn would modify pages and links, quite possibly corrupting each other’s data. Most of the Web page modifications are not robust to things such as frames and JavaScript, and many have a problem with forms. The tools relying on modifying link with CGI-scripts rather than using a proxy are fragile to the use of bookmarks or directly entered URLs. The tools

mentation.

The Arakne framework is an object-oriented, component- based, three-layered model aimed at providing Web aug- mentation tools a unified access to structure servers, proxies, and Web browsers. It is an instantiation of the Common Reference Architecture (CoReArc) for open hypermedia systems, as described by Granbaek & Wiil [17]. CoReArc divides the architecture of hypermedia systems into three layers: The content layer (displaying and handling docu- ments, displaying structure), the service layer (handling navigation, integration, collaboration etc.), and the structure

Tool Method of Integration Storage Web page modification Collaboration support ComMentor Part of browser, CGI-scripts Remote Local proxy Asynchronous CritLink Mediator Within browser, JavaScript, forms; CGI-scripts Remote CGI-scripts Asynchronous Chimera Web server Remote No Asynchronous Chimera Within browser, apple& Web server; cookies, Remote Web server Asynchronous

CGI-scripts Hyper-G Part of browser/Within browser, forms; web- Remote Web server Asynchronous

server; HyperWave Within browser, applet, JavaScript, forms; Remote Web server Asynchronous

web-server DLS Without browser, local; within browser, forms Remote No Asynchronous DLS Within browser, forms; proxy Remote Proxy Asynchronous AgentDLS Within browser, separate window; proxy Remote No Asynchronous DHM/WWW Within browser, applet, JavaScript, CGI-scripts Remote Web browser Shared Navette Within browser, applet, JavaScript Remote Web browser Asynchronous Webvise Without browser, local Remote Web browser Asynchronous Walden’s Paths Within browser, JavaScript, forms; CGI-scripts Remote CGI-scripts Shareable Ariadne Within browser, applet, JavaScript Remote No Asynchronous Web Squirrel Without browser, local Local No Shareable Hot Sauce Within browser, plug-in Remote No Shareable

Table 2 - Summary of Web augmentation strategies

that modify Web pages through a proxy are hard to use with other tools that rely on proxies to be informed of the user’s actions, unless either of the proxies can it be modified to use the other as a proxy. Furthermore the use of proxies requires the user to modify the Web browser configuration which can be unwieldy if the user does not wish to continually use the tool relying on the proxy. These problems to which there generally are no easy solutions, make it difficult for the developer to create Web augmentation tools.

TOWARDS A COMMON FRAMEWORK We are aware pf no single “silver bullet”, or all encompass- ing solution, that will solve all the problems described above. However, the similarities between the described Web augmentation tools would suggest that it should be possible to describe and model their functionality in a common framework. This could provide workers in the field with a tool for future conceptual and practical development. Trying to create such a tool, we have come up with the Arakne framework.

The Arakne framework is a conceptual model, which has been implemented as an environment for Web augmentation tools. The implementation is just one implementation of a general framework. The practical issues raised by the sum- mary above will be dealt in the description of the imple-

layer (storage and retrieval of structure).

The Arakne framework is aimed at modelling Web aug- mentation tools, and the elements contained in the model should now be familiar.

A diagram of the framework can be seen in Figure 1. The framework may support any number of Web augmentation tools. These tools (known as ‘navlets’) are dependent on four core components of the Arakne framework: the Opera- tions, the Hyperstructure Store, the Browser, and the Proxy. The navlet is the domain specific part of a Web augmenta- tion tool. It provides a user interface as well as special logic to handle the specific domain. This may include deciding which links to display in a Web page based on information retrieved from the Hyperstructure Store component, or inter- facing to the Proxy component for analysis of documents. Depending on the situation the computation and analysis may be carried out by the navlet or by another component.

The Operations component models the communication with the structure server layer. This component will thus typically support the same services as the structure server(s). This is where on the wire issues, such as network communication, marshalling, and multiplexing, are handled.

95

Content layer

Service layer

Structure layer

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Arakne : . : : Web : Navlet Bean 1 Navlet Bean 2 : l-4 l3r,....,..T. . : A : t

,; : : . . : : : : : : I Web Server .

Structure Server

L . I

Figure I - The Arakne Framework

The Hyperstructure Store is the interface between the nav- lets and the Operations. The Hyperstructure Store provides convenience functions for the navlets, as well as caching the results of the queries retrieved with Operations. The Hyper- structure Store will also alert navlets to changes in the structures they subscribe to.

Arakne framework. We will in this section argue for the genera1 applicability of the Arakne framework in each of the general Web augmentation categories introduced earlier, and specify the mapping of one representative from each cate- gory to the Arakne framework.

The Proxy component models the modification and analysis of Web content. Depending on their domain, navlets may require the Proxy to modify Web pages, and these requests for modifications are collected by the Proxy and used to modify the Web page. Other navlets may require access to the content of a Web page and the Proxy also handles this.

The Browser component models the user’s Web browser. Through the Browser navlets can retrieve and modify the state of the Web browser such as which URL is currently displayed; the structure of the current frame set; whether a selection has been made in a frame and if so, what and where.

Annotation tools are in their functional requirements similar to link creation tools and will dealt with as one, Both need to retrieve hypermedia structures stored on a server, which are handled by the Operations and the Hyperstructure Store components. Many of these tools need to modify Web pages in order to insert links or annotations, which is handled through the Proxy component. Support for collaboration is handled at different levels. The Hyperstructure Store com- ponent is able to handle sets of structures as well multiple users. Notifications from the structure servers are handled by the Operations component and forwarded to the Hyper- structure Store component, which notifies navlets, depend- ing on what events they subscribe to.

The situation depicted in Figure 1 is a situation of two nav- lets, where Navlet Bean 1 is a link creation tool, and thus needs access to the Proxy in order to insert links into Web pages. Navlet Bean 2 is a guided tour tool and does not modify Web pages; and is not connected to the Proxy. Both however need to be able to tell and set the state of the cur- rently displayed documents, as well as retrieving data from the structure server through the Hyperstructure Store.

The ComMentor system, described in [35], has three main elements apart from the structure servers and the Web serv- ers; namely the merge library, the interactive renderer, and the user context control application. The merge library han- dles the tasks of the Operations, Hyperstructure Store, and Proxy components. The modifications made to the Mosaic browser combined with the code handling it in the user context control application makes up the Browser compo- nent.

Mapping Web Augmentation Tools to Arakne The AgcntDLS 1x1 architecture consists of a link server If we review the models of the Web augmentation tools agent, that analyses Web pages sent to it by a HTTP proxy described in this paper, most can be mapped to the abstract and based on this uses link resolvers and link bases to con-

96

pile a list of relevant links. The role of the proxy is a simple case of the Proxy component with the twist that documents are sent to two parties. The link server agent acts as a com- bined Operations and Hyperstructure Store component. The analysis performed by link resolvers also would seem to belong to this component, depending on the set-up of the navlet. The Browser component’s responsibility - letting the system set or get the state of the Web browser - is handled at two levels: in the Proxy component (what document is displayed now?) and in the AgentDLS window, where users can directly influence, what URL to display in their Web browser.

Guided tour tools require a structure server for storage of the tours as well as the ability to communicate with this server. This can be modelled through the Operations and Hyper- structure Store components. To keep track of where the reader is on the trail (and to put the reader back on track, if need be), it must be possible to set and read the state of a Web browser, which is modelled through the Browser com- ponent. Some guided tour tools, e.g. Walden’s Paths, modify the Web pages to add comments and interface. While it may not be necessary for interface reasons in the Arakne frame- work (this could be handled by a navlet), it certainly can be done through the use of the Proxy component.

Could the current implementation of Walden’s Path be fitted within the Arakne model? In this case, some of the Arakne components collapse into one. The Path Server acts as the Proxy, Hyperstructure Store, and Operations components, by handling both external structures (guided tours) and Web page modification. The Browser component aspect is han- dled by the modification of links that keeps the system (i.e. the Path Server) aware of the state of the Web browser. The interface aspects of the navlet are the header and footer of the displayed Web pages that give the user a possibility to interact with the system.

Spatial and structuring Web augmentation tools certainly need structure servers and information about the currently display Web page just as the rest of the above described tools. However, the main focus of the spatial/structure tools described in this paper has been on the user interface and the ability to analyse and process structure and relationships using user written scripts. The user interface is handled by the navlet itself. While the navlet of course would serve as the front-end, the scripting capability fits best within the Hyperstructure Store component, where all structure is stored during run-time and where the Operations component can be directly accessed.

AN IMPLEMENTATION OF THE ARAKNE FRAMEWORK A system called the Arakne applet has been developed as a part of the Coconut project. The immediate goal of the im- plementation was to try out the soundness of the Arakne framework by integrating the guided tour tool Ariadne and the link creation tool Navette. The system has undergone some development and has proven robust to the interchange of components.

The system was originally developed as a Java applet run- ning in Netscape Communicator [3 11. The components

within the dotted line in Figure 1 were a part of this particu- lar implementation. This was an implementation choice; as can be seen from the previous section, the framework itself posits no such requirements on the location of the individual components.

The components in Figure 1 correspond to Java classes in the Arakne applet. The interfaces between components are handled in the MVC (Model View Control) idiom, where the ‘view’ (e.g. a graph displaying a guided tour) is loosely coupled through events to the actual data, the ‘model’. Modifications of data is handled as requests through the ‘controller’ and if granted notified to the view through the use of events.

The Hyperstructure Store class caches structure retrieved through the Operations class and is the only interface to the structure servers given to the navlet beans. This is done to improve performance (by not retrieving the same informa- tion twice) and to ensure data integrity between the Hyper- structure Store and the structure servers. The Hyperstructure Store provides the navlet beans with a rich set of conven- ience methods, which are translated into queries to the structure servers by the Operations class.

The Browser class encapsulates the needed functionality to communicate with a Web browser, in the original case the Netscape Communicator. The interface is relatively simple and can be adapted to another browser.

The Proxy class is a small proxy running as a thread in the applet. The Netscape Communicator can via JavaScript be set up to use a proxy on the fly, and when the Arakne applet is running, the Proxy class acts as a proxy for the browser. The Proxy class uses whatever proxy the browser was con- figured to use, and when the Arakne applet is terminated, everything is returned to normal. The Proxy handles re- quests for Web page modifications and the correct display of frames (thus allowing user to link into frame sets).

All of the classes visible to the navlet beans, the Hyper- structure Store class, the Proxy class, and the Browser class generate events that the navlet beans may subscribe to. The navlet beans are currently restricted to being Java beans and to follow some design guidelines. The current implementa- tion supports only compile time integration of navlet beans giving the user a fixed number of available navlet beans, but future versions of the Arakne applet should be able to load navlet beans on runtime so that the user can retrieve navlet beans from different servers.

The current version of Netscape Communicator2 has a very limited API for browser integration as well as a faulty Java socket implementation. This lead to the abandonment of the Communicator as the supported Web browser at a time where most components as well as two navlets were finished or nearing completion. The Microsoft Internet Explorer was chosen as the new supported Web browser. This choice has brought some costs, as the Arakne applet is now not only browser-dependent (which was also the case before), but

2 Version 4.5

97

now also platform dependent, as Java is not supported in the Microsoft Internet Explorer on anything but the Windows platform.

The migration to the Internet Explorer also served as a (un- intended) test of how much code needed to be rewritten to accommodate the change. This code rewrite has been light. The Browser class has been redone, as the Internet Explorer is controlled not through JavaScript, but through a COM interface. Furthermore some unique features such as the ability to operate on selected text in a browser window through the use of right-click menus have been exploited in some changes in user interface, e.g. link creation.

The Internet Explorer does not allow proxy configuration through JavaScript or other means, which has led to some major changes in the Proxy component. The current version relies on the DHMProxy [ 181 for Web page modification. This is expected to change as the DOM model [l l] gives excellent possibilities for Web page analysis and modifica- tion, after the Web page has been rendered by the Web browser. This work is expected to be heavily dependent on the experiences from the Webvise application [ 181.

The current version uses the Devise Hypermedia server as a structure server. This is changing rapidly however, as a new Hyperstructure Store class is being developed to use a new Operations component that utilises the Open Hypermedia Protocol [33]. This has numerous advantages. The OHP is a powerful protocol with a good and general data model. Among the interesting features of OHP is the support for sessions, so that e.g. link following happens simultaneously on several machines as demonstrated at the demo at Hyper- text 98. Finally the open hypermedia community supports the OHP and the data model, so that the Arakne applet may communicate with other structure servers such as OHP compliant Microcosm or HyperDisco servers.

The synchronous collaborative aspects of the Arakne applet have been put on hold until the OHP is fully integrated, though the system as it is supports asynchronous collabora- tion.

Currently the Arakne applet supports the Ariadne and Navette navlet beans. The user is thus able to create links in documents while creating guided tours, which was not pos- sible before. Each of the navlet beans occupies an internal window in the Arakne applet. The Arakne applet provides the interface for logging on to structure servers and the se- lection of contexts.

The Navette navlet has recently been extended to support linking to and from segments in video and audio clips through the Mimicry system [4]. Most temporal media plug- ins do not have APIs well suited for the needs of open hy- permedia, which has led to the development of the Mimicry player. The Mimicry player is a Java applet capable of han- dling most video and audio formats, and it provides a rich API for open hypermedia integration.

Future Plans Future plans for the Arakne applet include more navlet

beans. Currently a spatial navlet bean is under development. The navlets currently supported are not aware of each other, but future versions of Arakne will support inter-navlet communication. The Microsoft Internet Explorer is not expected to be the only Web browser supported by future Arakne applets. The upcoming Mozilla 5.0 holds great promise in this regard. Another area of interest to the devel- opers is the implications of XLink and XPointer.

Experiences of the Development of the Arakne Applet How does the current Arakne applet compare to the prob- lems raised in the summary of strategies for Web augmenta- tion? Network communication is handled through sockets by the Operations Component, and the client maintains a socket connection, so that the structure servers may contact it. The Arakne applet has so far only supported navlets or- thogonal to each other, so there is currently no experiences with regards to two navlets trying to modify the same Web page. However the architecture has only one component, the Proxy component, allowed to modify Web pages, so it should be possible to contain and perhaps avoid most prob- lems. The Arakne applet is currently dependent on a proxy with the usual advantages (all browsing activities are ‘cap- tured’ by the system) and disadvantages (the user needs to configure the Web browser to use the proxy). The proxy can use other proxies without problems, though the use of two Web page modifying proxies certainly would lead to unde- fined results. The proxy handles frame sets and inserts links through the use of JavaScript and DOM, so that Web pages are (visibly) modified on arrival rather than in transit, which solves many problem regarding dynamically created docu- ments and frame sets. The Arakne applet is a Java applet with the limitations imposed on Java applets. The security restrictions are handled through digital signing. The Arakne applet is fairly secure from being unloaded by mistake, as it runs in a separate non-resizable browser window with dis- abled menus and toolbars. A consequence of the integration with the Microsoft Internet Explorer is that a user can not just download and use the Arakne applet. Certain files have to be installed by the user to provide the Arakne applet with right-click menus. This process can however be largely automated.

Some of the solutions found in the Arakne applet are strictly browser and platform dependent. This is very unfortunate, and the only thing that can remedy the situation is a new standard Java API for Web browsers. This API should at least provide functionality similar to that of the API of the Microsoft Internet Explorer, but do so in a browser inde- pendent way. Given the current Web browser situation, we think that such an API is unlikely to appear anytime soon, SO

the next best solution would be a Web browser that provided a platform independent API. Whether or not Mozilla 5.0 will provide such an API remains to be seen.

CONCLUSION Web augmentation tools will in all probability remain a part of the Web, as researchers and users will continue to explore the boundaries of what hypermedia is and what it can be used to. An understanding of the strategies employed in Web augmentation is needed to make the next generation of Web augmentation tools easier to envision, develop and use.

98

We have investigated the recurring themes and techniques found in current Web augmentation tools. Based on this, we have developed and described the Arakne framework, and shown that the Arakne framework accommodates existing Web augmentation tasks, and that most tools can be mod- elled using the framework. A shared framework for these tools could benefit analysis and communication as well as development, and it is hoped that the Arakne framework is a step in the direction of the creation of such a framework.

The interesting and challenging part of creating a Web aug- mentation tool is not the nitty-gritty of interfacing to a Web browser or writing a proxy. The interesting part, at least in the author’s experience, is to create tools that can help users structure their work and their browsing, and by implement- ing the Arakne applet some of the work needed to provide a full infrastructure for Web augmentation tools have been developed.

The Web has succeeded through (more or less) strict adher- ence to open standards that have been jointly developed by the interested parties. This has led to the development of standard tools usable for all. The continuation of this trend is crucial to the future development of the Web. The Open Hypermedia System initiative if supported by the hyperme- dia community can be become a shared standard from which the entire hypermedia community will benefit.

ACKNOWLEDGEMENTS The author is a member of the Coconut project (hltn://www.cit.dklcoconut/), a joint research project consisting of Department of Computer Science, Aarhus University and Tele-Danmark Internet. The Danish National Centre for IT- Research (hm:Nwww.cit.dkl) supports the Coconut project.

The author wishes to thank Jesper Jiihne for valuable discus- sion of Arakne, RenC Thomsen for adding to the code, Kaj Gr@nbzk for valuable advice, and the anonymous reviewers for good suggestions to structure this paper.

REFERENCES [II

PI

[31

[41

[51

Anderson, K. M., Taylor, R. N., and Whitehead JR., E. J. (1994). Chimera: Hypertext for heterogeneous soft- ware environments. In Proceedings of ECHT 94 Con- ference, pp. 97-107, Edinburgh, Scotland.

Anderson, K. M. (1997) Integrating Open Hypermedia Systems ,with the World Wide Web. In Proceedings of the ACM Hypertext 97 Conference, pp. 157-166, Southampton, England.

Bouvin, N. 0. (1998). Designing Open Hypermedia Applets: Experiences and Prospects. In Proceedings of the ACM Hypertext 98 Conference, pp. 28 l-282, Pitts- burgh, USA.

Bouvin, N. O., and Schade, R. (1999). Integrating tem- poral media with open hypermedia on the WWW. Submitted for publication.

Bush, V. (1945). As we may think. In The Atlantic Monthly 176, 1 (July 1945), pp. 101-108.

[61

[71

@I

[91

Carr, L. A., De Roure, D., Hall, W., and Hill, G. (1995). The distributed link service: A tool for publishers, authors and readers. In Proceedings of the 4” Interna- tional World Wide Web 95 Conference, Boston, USA.

Carr, L. A., Hill, G., De Roure, D., Hall, W., and Davis, H. (1996). Open information services. In Computer Networks and ISDN Systems, 28, pp 1027-1036, 1996.

Carr, L. A., Hall, W., and Hitchcock, S. (1998). Link services or link agents? . In Proceedings of the ACM Hypertext 98 Conference, pp. 113-l 22, Pittsburgh, USA.

Davis, H., Hall, W., Heath, I., Hill, G., and Wilkins, R. (1992). Towards an integrated information environment wiih open hypermedia systems. In Proceedings of the ACM Hypertext 92 Conference, pp. 18 l- 190, Milan, It- aly.

[IO] CritSuite. htte://crit.or!z/htto://crit.orp/index.html

[ 1 I] Document Object Model. htto:Nwww.w3c.ore/TWREC- DOM-Level-l/

[ 121 Furuta, R., Shipman III, F. M., Marshall, C. C., Bren- ner, D., and Hsieh, H-W. (1997). Hypertext Paths and the World-Wide Web: Experiences with Walden’s Paths. In Proceedings of the ACM Hypertext 97 Confer- ence, pp. 167-176, Southampton, England.

[ 131 Goland, Y., Whitehead, J., Faizi, A., Carter, S., Jensen, D. (1998). Extensions for Distributed Authoring on the World Wide Web - WebDAV. httD://\vww.ics.uci.edu/-eiw/authoring/orotocol/draft-ietf- webdav-Drotocol-08.Ddf

[ 141 Gr@nb=k, K., and Trigg, R. H. ( 1994). Design issues for a Dexter-based hypermedia system. In Communica- tions of the ACM, 37 (2) February, pp. 40-49, 1994.

[ 151 Grenbek, K., and Trigg, R. H. (1996). Toward a Dex- ter-based model for open hypermedia: Unifying em- bedded references and link objects. In Proceedings of the ACM Hypertext 96 Conference, pp.149-160, Washington DC, USA.

[ 161 Gr@nbaek, K., Bouvin, N. O., and Sloth, L. (1997). Designing Dexter-based hypermedia services for the World Wide Web. In Proceedings of the ACM Hyper- text 97 Conference, pp. 146-156, Southampton, Eng- land.

[ 171 Gronbzk, K., and Will, U. K. (1997). Towards a com- mon reference architecture for open hypermedia. In JoDI, Journal of Digital Information, l(2), 1997. htto://iodi.ecs.soton.ac.uk/Articles/vOl/i02/GronbaW

[ 18]Gr@nbzk, K., Sloth, L., and 0rbak, P. (1999). Webvise: Browser and proxy support for open hyper- media structuring mechanisms on the WWW. Submit- ted for publication.

99

[ 191 Guha, R. V., and Bray, T. (Eds.). Meta content frame- work using XML. t~ttr,://w\vw.textualitv.com/mcf/NOTE- MCF-XML.html

[20] Hall, W., David, H., and Hutchings, G. ( 1996). Re- thinking Hypermedia: The Microcosm Approach. Klu- wer Academic Publishers, Norwell, USA.

[21] Hot Sauce. http://www.xspace.net/download/index.html

[22] HyperWave. http://www.hynerwave.com/

[23] Jiihne, J., Jensen, A. T., and Granbzk, K. (1998). Ari- adne: A Java-based guided tour system for the World Wide Web. In Proceedings of the 7”’ International World Wide Web 98 Conference, Brisbane, Australia.

[24] Marshall, C. C., and Shipman III, F. M. (1995). Spatial hypertext: Designing for change. In Communications of the ACM, 38 (8) August, pp. 88-97, 1995.

[25] Marshall, C. C. (1998). Toward an ecology of hypertext annotation. . In Proceedings of the ACM Hypertext 98 Conference, pp. 40-49, Pittsburgh, USA.

[26] Maurer, H. (Ed.) (1996). Hyper-G now, HyperWave: The next generation web solution, Addison-Wesley, Harlow. 1996.

[27] Meyrowitz, N. (1989). The missing link: Why we’re all doing hypertext wrong. In Barrett, E. (ed.). The society of text: Hypertext, hypermedia and the social construc- tion of information, pp. 107- 114, MIT Press, Cam- bridge, Massachusetts., USA, 1989.

[28] Microsoft Internet Explorer. htto://www.microsoft.com/ie/

[29] Mozilla. http://www.moziIla.org/

[30] NCSA Mosaic. httn://www.ncsa.uiuc.edu/SDC;/Sol’tware/Tvlosaic/

[3 l] Netscape Communicator. httn:Nhome.netscane.com/download/index.httnl?cu=diude~a~~

[32] Niirnberg, P. J., Leggett J. J., Schneider, E., and Schnase, J. L. (1996) Hypermedia operating systems: A new paradigm for computing. In Proceedings of the ACM Hypertext 96 Conference, pp.l94-202, Washing- ton DC, USA.

[33] The Open Hypermedia Systems Work Group. httn:Nwww.ohswg.ord

[34] Rittel, H. and Webber, M. (1973). Dilemmas in general theory of planning. In Policy Sciences, Vol. 4, 1973.

[35] Riischeisen, M., Mogensen, C., and Winograd, T. (1995) Beyond browsing: Shared comments, SOAPS, trails, and on-line communities. In Proceedings of the 3”’ International World Wide Web 95 Conference, Darmstadt, Germany.

[36] Riischeisen, M., Winograd, T., and Paepcke, A. (1995). Content ratings and other third-party value-added in- formation: Defining an enabling platform. In D-Lib Magazine, August 1995, httn://www.dlib.or~dlib/aupust9S/stan~or~~~r~~sc~~eisen.html

[37] Shipman III, F. M., Furuta, R., Brenner, D., Chung, C- C., and Hsieh, H-W. (1998). Using paths in the class- room: Experiences and adaptations. In Proceedings of the ACM Hypertext 98 Conference, pp. 267-276, Pitts- burgh, USA.

[38] Shipman III, F. M., Furuta, R., and Marshall, C. C. (1997). Generating web-based presentations in spatial hypertext. In Proceedings of the 1997 International Conference on International User Inteeaces, pp. 7 l- 78, Orlando, USA.

[39] Stanley, T. (1998). Contextures: Focus + context + texture. In Proceedings of the ACM Hypertext 98 Con- ference, pp. 295-296, Pittsburgh, USA.

[40] Trigg, R. H. and Weiser, M. (1986). TEXTNET: A network-based approach to text handling. In ACM Trans. OfJice Information. Systems 4, 1 (Jan 1986), pp l-23.

[41] Trigg, R. H. (1988). Guided tours and tabletop: tools for communicating in a hypertext environment. In ACM Trans. Ofice Information. Systems 6,4, pp 398-414, 1988.

[42] Web Squirrel. httn://www.eastgate.corn/suuirrel/Welcome.html

[43] Whitehead Jr., E. J. (1997). An architectural model for application integration in open hypermedia environ- ments. In Proceedings of the ACM Hypertext 97 Con- ference, pp. 1-12, Southampton, England. .

[44] Wiil, U. K. and Leggett, J. J. (1996). The HyperDisco approach to open hypermedia systems. In Proceedings of the ACM Hypertext 96 Conference, pp. 140-148, Washington DC, USA.

[45] Wiil, U. K. and Leggett, J. J. (1997). HyperDisco: col- laborative authoring and Internet distribution. In Pro- ceedings of the ACM Hypertext 97 Conference, pp. 13- 23, Southampton, England.

[46] Wiil, U. K., and asterbye, K. (1998). Using the Flag taxonomy to study hypermedia system interoperability. In Proceedings of the ACM Hypertext 98 Conference, pp. 188-197, Pittsburgh, USA.

[47] XML - Extensible Markup Language. htt~:llwww.w3c.or~XMLl

[48] asterbye, K., and Wiil, U. K. (1996). The Flag taxon- omy of open hypermedia systems. In Proceedings of the ACM Hypertext 96 Conference, pp. 129-139, Washing- ton DC, USA.

100

Integrating Temporal Media and Open Hypermedia onthe World Wide Web

Niels Olof Bouvin* & René Schade**

*Department of Computer Science,University of Aarhus,

Aabogade 34A, DK8200 Aarhus N, Denmark

**Tele Danmark InternetOlof Palmes Allé 36

DK8200 Aarhus N, Denmark

1 ABSTRACTThe World Wide Web has since its beginning provided linking to and from text documents encodedin HTML. The Web has evolved and most Web browsers now support a rich set of media types ei-ther by default or by the use of specialised content handlers, known as plug-ins. The limitations ofthe Web linking model are well known and they also extend into the realm of the other media typescurrently supported by Web browsers. This paper introduces the Mimicry system that allows authorsand readers to link to and from temporal media (video and audio) on the Web. The system is inte-grated with the Arakne Environment, an open hypermedia integration aimed at Web augmentation.The links created are stored externally, allowing for links to and from resources not owned by the(link) author. Based on the experiences a critique is raised of the limited APIs supported by plug-ins.

2 KEYWORDSTemporal media, open hypermedia, plug-ins, Web augmentation

3 INTRODUCTIONThe World Wide Web has since its beginning steadily embraced more and more types of media. To-day the average Web user will be exposed to pictures, video clips, sound recordings, music, and willinteract with programs or 3D worlds residing on Web pages. These types of media are either handledby the Web browser itself or handled by specialised programs, ‘viewers’ or ‘plug-ins’. Most mediatypes are however supported/handled in the sense that it is possible to link to the entire media clip orto include it on a Web page, but not link from the media clip itself or to a segment of the media clip.Pictures are the exception, using image maps, to provide starting points for navigation. However allmedia types (HTML and otherwise) share the limitations of inline unidirectional links1; links cannotoriginate from documents not owned by the hopeful link creator, and the destinations of a link into aHTML document are limited to the named regions in the target document. These deficiencies arebeing addressed by integrating open hypermedia systems and the Web, allowing link structures to bestored externally of documents. This approach also allows for links to and from media types lessamenable to modification than HTML, provided that suitable plug-ins or viewers are used.

This paper describes an open hypermedia integration to provide linking facilities to and from tempo-ral media (such as video and audio clips). A search for an appropriate plug-in to provide the neces-sary functionality left the authors empty-handed. This resulted in the implementation of the Mimicryplayer which substitutes for a plug-in. Through the Mimicry controller, the system interacts with theArakne Environment [4], allowing users to create multiheaded bi-directional links to and from tem-poral media clips, embedded or otherwise, as well as to and from HTML documents.

The results achieved by the Mimicry system (and the relative ease of implementing the ideas behindit) raise the question, why plug-in developers do not yet provide the functionality to support such asystem. It would substantially ease the work of Web page designers, as media clips or parts thereof

1 With the possible exception of image maps, which may have links defined externally.

could be reused, as well as supporting new (on the Web) technologies such as linking to and fromtemporal media.

The paper begins by introducing related work in the field of open hypermedia and on the Web. Themerits of emerging standards such as SMIL, HTML+TIME, and XLink/XPointer are discussed. TheArakne Environment wherein the Mimicry system runs is introduced and described. The Mimicrysystem (player and controller) is described in detail and an example of Mimicry usage is given.Based on the experiences with the Mimicry system, the current state of plug-ins is discussed in thecontext of hypermedia systems. Finally directions for future work are discussed and a conclusion isreached.

4 RELATED WORKThis section will introduce the notion of externally stored link structures, open hypermedia systems,Web augmentation, and the work done with integration of temporal media and hypermedia systems.

Inline unidirectional links Anchor-based bidirectional links

link

Figure 1 - Inline and anchor-based linking

4.1 Separating document and structureThe linking model found in the World Wide Web is based on inline unidirectional links. While sim-ple and scaleable, this linking model is in some contexts inadequate in comparison with the linkingmodel found in most modern hypermedia systems. Inline links are hard to maintain2; it is impossibleto determine which links point to a page3; there can be only one set of links in a document; a linkmay point to only one destination rather than many; and this destination is limited to either a wholedocument or a named region therein. The problems with this approach can be illustrated by the fol-lowing example: consider a situation, where a company decides on a Web based Intranet solution toallow easy access to their technical documentation. The Web, given the URL naming scheme, is verywell suited for document distribution. The technical documents are crucial to several independentgroups in the company and they all wish to put links into the technical document. Current Web tech-nology yields two scenarios: either give each group access to copies modifiable by the respectivegroup, or incorporate all links into one central document. The former makes updating the technicaldocumentation difficult, and the latter will clutter the technical document with links interesting toone group, but irrelevant to the rest. Both cases leave the technical document open to undesirablemodification. A safer and more maintainable solution would be to have one copy of the documenta-tion available and then have each group use their own set of links into the documentation. This cannot be done with the existing Web linking model.

2 In the sense that links may point to documents that do no longer exist or have been moved.3 Save a brute force approach using search engines, which is computational expensive and not nec-essarily accurate.

A way to achieve this kind of flexibility is through the use of anchor-based hypermedia, which sepa-rates the anchor (or endpoint) and the link from the document. An anchor specifies a span in a docu-ment (up to the entire document), an area in a picture, a segment of a video clip and so forth. Linksspecify relationships between anchors, as seen in Figure 1. Anchors and links are stored outside thedocuments. A hypermedia application used by a user inserts links into documents as they are re-trieved (e.g. not at the server, but at the client). The user can through the hypermedia applicationdecide which sets of links to use, and the company described above would thus be able to maintainseveral sets of links to the same technical documentation.

There are pros and cons of this approach. As links and anchors are now separate they can be main-tained separately and can be checked and updated independently of the documents they link. Linkscan be bi-directional, multiheaded and link into documents without modifying them. However, theinsertion of links into the document on the fly carries some additional overhead, and does generallynot scale as well as the simpler inline link model.

A great benefit of the anchor-based linking approach is that of opaque anchors, that is, the generalsystem is not concerned with how an anchor addresses a selection in a media type. The generalmodel need not be modified if a new anchor type is introduced to support a new media type, as longas the new anchor type adheres to the general anchor specification. The anchoring code (such as theability to display an anchor into the media type) must of course still be written, but storage, link fol-lowing, etc. is unaffected. This allows for complex anchoring constructs, and allows the developersto support new applications and media types without sacrificing existing work.

Anchors are created to match their media type. They must carry enough information to be able toidentify the selection that the user had in mind when the anchor was created. In the case of text an-chors, this information often consists of a selection and a context around the selection, so that it maybe uniquely identified. An image anchor could (depending on its use) be as simple as two co-ordinate pairs to identify a rectangular selection, or be complex enough to identify arbitrary shapesas destinations. In the context of temporal media, it is natural to use time as unit in the system of co-ordinate. Frames are another possibility but the frame rate of a media clip may vary accordingly tothe bandwidth of the user’s connection. Furthermore some temporal media types, such as audio maynot have frames at all.

4.2 Open Hypermedia and the WebOpen hypermedia systems are characterised by a focus on integration with third-party software.Historically, hypermedia systems have often been closed and monolithic, requiring other programs tocomply to the standards of the hypermedia system in order to provide hypermedia functionality. Thisis problematic as it closes the door on existing non-compliant applications, and expects developers tochange their programs – an unlikely proposition at best. Recognising that most people are not willingto throw away their applications in order to utilise a hypermedia system has led the open hypermediacommunity to integrate existing applications into their hypermedia systems instead. The level ofwhich this is possible varies accordingly to the applications, ranging from the simple (show docu-ment) to the advanced (a full integration). Whitehead handles the implications of integrating third-party applications with open hypermedia integration in [21].

A natural consequence of the open hypermedia approach is the interest of integrating the Web intoopen hypermedia systems. Several groups in the field have created Web integration tools, and a non-exhaustive list includes DLS [5][6], DHM/WWW [8], Webvise [9], Navette [3], Chimera [1], andHyperWave [18].

A common approach to open hypermedia Web integration is to modify Web pages while en route tothe Web browser. This modification usually consists of the addition of links or other kinds of struc-ture. These links are stored on a structure server and are inserted into the pages using CGI-scripts,proxies, or programs controlling the Web browser. The interface presented to the user varies, rangingfrom no interface at all to full authoring applications allowing the users to modify and extend uponthe existing collections of links and anchors. Most however allow the user to create links to and fromwhatever pages the user may desire, thus alleviating one of the major limitations of the existing Webarchitecture mentioned above. For a fuller discussion on the techniques of open hypermedia Webintegration and Web augmentation in general, see [4].

The main target of these integrations has been Web pages rather than other kinds of Web-distributedmedia, as HTML is easily analysed and modified by use of proxies or other means. Other kinds ofmedia that could be interesting include graphics and temporal media, streaming or otherwise. Thesedata types are less readily modified, come in great variation, and requires viewers or plug-ins thatmay be difficult to integrate with an open hypermedia system.

4.3 Hypermedia and Temporal MediaSeveral hypermedia systems have been extended or devised specifically to handle temporal media.The most influential hypermedia model to incorporate the notion of temporal data is HyTime [7],which allows for multidimensional anchors (including the temporal dimension). HyTime is a generalstandard aimed at interchange and does as such not specify the interaction between hypermedia ap-plication and multimedia applications. While many systems have integrated temporal media one wayor another, some systems go further, such as AEDI [2], which tries to ease work with large amountsof temporal data with structured indexing. Some systems try to facilitate automatic tracking and lo-cation of anchors in media clips; two well-known examples are Himotoki [10] and MAVIS [15].While the possibility of selecting an object in one frame, and have the system automatically track theobject in the rest of the video clip certainly is alluring, it is also quite computational expensive, andprobably unlikely in a Web setting.

The ambitions of the authors are far more modest. We are merely interested in being able to createlinks to and from segments of temporal media. Future version may include anchors that cover anarea of a video clip for some duration, but the area is not expected to move.

4.4 Temporal Media on the WebThe use of temporal media on the Web has steadily increased. It is today commonplace for newssites to bring either video clips or to provide access to whole TV shows online. Likewise the researchcommunity (notably the linguistic) has taken to making animations or sound recordings available.This opens for a hitherto unseen availability of valuable research material (such as historic film clipsor language recordings), and therefore also an increasing demand to be able to interact with thesemedia clips in new and innovative ways.

An example of an organisation beginning to put large amounts of temporal data on the Web is theDanish national library, Statsbiblioteket. In order to facilitate research, the library has made an in-creasing amount of historically interesting Danish sound files available on the Web [20].

4.5 Emerging standardsSome of the new emerging W3C standards are of special interest to the subject of this paper. Thissection will briefly describe these and discuss the implications for temporal media on the Web. Itshould be noted however that these are still evolving standards, and can be expected to undergosome transformation before being finalised.

SMIL [19] (Synchronised Multimedia Integration Language) is a recent Recommendation fromW3C. It is an effort to support the layout and synchronisation of multimedia clips, e.g. synchronisinga video clip with animations or a slide show with audio narrative and HTML documents. The stan-dard is presentation oriented, and as such requires an authoring tool to modify.

HTML+TIME [12] (Timed Interactive Multimedia Extensions for HTML) is a proposed standardinspired by SMIL, and is concerned with the implementation of SMIL concepts in HTML. It thusadds a concept of timing to HTML and allows any HTML element to appear for a defined duration.Of special interest in this context is the timed hyperlink, and the integration of media players, whichcan be addressed and timed. Not only can the players be set to begin playing at a predetermined time,it is also possible to address inside the media clip and thus play a segment of a media clip, using theclip-begin and clip-end attributes. As HTML elements (in particular links) can be synchro-nised with other elements’ timing events, it would be simple to create links that would synch withsegments of a media clip, e.g. links appearing during a segment of a video clip and disappearing afterthe segment had been played.

As such HTML+TIME has certain requirements of content handlers that fit nicely with the require-ments of links to and from temporal media. Specifically media players should be able to synch withevents, as well allow the showing of segments. This is however a very new (proposed) standard andso far no Web browsers or media players the authors are aware of meet the HTML+TIME require-ments.

A general problem with SMIL and HTML+TIME from the standpoint of the authors is that thesestandards address authoring of presentations and thus is in principle (though admittedly far moreadvanced) no different than the existing HTML authoring tools. The basic problem of links beingcreated exclusively by the author of the document remains. These standards also address a somewhatdifferent problem than linking to and from temporal media, as a key point of SMIL andHTML+TIME is synchronisation and presentation.

Both standards are, as noted above, still in development and may very well change in the future.

XML defines a way to describe structured data and documents. XPointer and XLink (XML LinkingLanguage) are the accompanying resource location and linking standards. As of this writing, neitheris in ‘Recommended’ state from W3C, but this is expected to happen sometime in 1999.

XPointer [17] is designed to specify locations in XML and other well-structured documents. Thesyntax is based on the Text Encoding Initiative ‘extended pointer’. This is a rather compact and tree-oriented notation, which might take the following form: LG�IRR��FKLOG���6(&��FKLOG���/,67�. This expres-sion would start at the entity identified as ‘foo’, continue at this entity’s third child of the type ‘SEC’,and end with that child’s fourth child of the type ‘LIST’. This format is not XML, which might comeas a surprise, but it has the advantage that it can be used in URLs.

XLink [16] is the language that ties XPointers together in links. XLink are not limited to XPointers –while endpoints in XML documents typically will be described with XPointers, XLink links canhave any Web resource as a destination. Links may be in-line (as in HTML) or out-of-line, that isresiding outside the linked documents. XLink supports bi-directional multiheaded links. Out-of-linelinks may be stored in simple text files or handled by link bases. XLink does not offer any protocolfor such link servers.

XLink and XPointer are, from a Web augmentation standpoint, mainly interesting, if XML becomeswidespread on the Web. While the linking constructs are quite powerful in XML documents, the

standards are not aimed at improving the state of the art with respect to HTML, that is not well-formed, nor does it address the intricacies of other media types, such as video or audio.

5 THE ARAKNE ENVIRONMENTThe Arakne Environment, shown in Figure 2, is a runtime environment aimed at supporting Webaugmentation tools. The environment is primarily but not exclusively aimed at providing advancedhypermedia functionality to the Web. The environment is based on the Arakne framework [4], whichis a general Web augmentation model, and was designed to be open and extensible. It currently sup-ports a navigational hypermedia tool, Navette, and a guided tour tool, Ariadne [14].

Structure layer

Operations

Navette Ariadne

Proxy

Web Server

HTTP

Hyperstructure Store

Browser

HTTP

OHP

Service layer

Content layer

Arakne Environment

Structure Server

Structure Server

HyperStore DBMS

Mimicry Controller

Mimicry Controller

Web Browser

Figure 2 - The Arakne Environment

The framework may support any number of Web augmentation tools. These tools (known as ‘nav-lets’) are dependent on four core components of the Arakne framework: the Operations, the Hyper-structure Store, the Browser, and the Proxy. The navlet is the domain specific part of a Web aug-mentation tool. It provides a user interface as well as special logic to handle the specific domain.This may include deciding which links to display in a Web page based on information retrieved fromthe Hyperstructure Store component, or interfacing to the Proxy component for analysis of docu-ments or to modify documents. Depending on the situation the computation and analysis may becarried out by the navlet or by another component.

The Operations component models the communication with the structure server layer. This compo-nent will thus typically support the same services as the structure server(s). This is where on the wireissues, such as network communication, marshalling, and multiplexing, are handled.

The Hyperstructure Store is the interface between the navlets and the Operations. The HyperstructureStore provides convenience functions for the navlets, as well as caching the results of the queriesretrieved with Operations. The Hyperstructure Store will also alert navlets to changes in the struc-tures they subscribe to.

The Proxy component models the modification and analysis of Web content. Depending on theirdomain, navlets may require the Proxy to modify Web pages, and these requests for modificationsare collected by the Proxy and used to modify the Web page. Other navlets may require access to thecontent of a Web page, which is also handled by the Proxy.

The Browser component models the user’s Web browser. Through the Browser navlets can retrieveand modify the state of the Web browser such as which URL is currently displayed; the structure ofthe current frame set; whether a selection has been made in a frame and if so, what and where.Communication with plug-ins and applets running in the Web browser is also handled through theBrowser component.

The situation depicted in Figure 2 is a situation of two navlets running in the Arakne Environment:Navette is a link creation tool, and thus needs access to the Proxy in order to insert links into Webpages. Ariadne is a guided tour tool and does not modify Web pages; and is thus not connected to theProxy. Both however need to be able to tell and set the state of the currently displayed documentsand to interact with the Web browser in other ways, as well as retrieving data from the structureserver through the Hyperstructure Store.

By providing the components described above and by having an open architecture, the Arakne Envi-ronment aims to provide developers with an environment that allows for easy implementation ofWeb augmentation tools. The Arakne Environment is written in Java (but is not an applet), and cur-rently integrates with the Microsoft Internet Explorer. The current version uses the DHMProxy [9] toinsert links and other structures into Web pages. The relative ease of development has made the envi-ronment well suited for experiments such as the Mimicry system described herein.

6 THE MIMICRY PLAYERThe Coconut project has developed the Mimicry player to support linking to and from temporal me-dia in the Arakne Environment. Realising that if we wanted to integrate temporal media into our hy-permedia system, we would have to do it ourselves, as no existing plug-in seemed to offer an ade-quate API, we started looking for the easiest way to support temporal media.

The Java Media Framework [13] developed by JavaSoft, Intel, and Silicon Graphics is aimed at sup-porting temporal media in Java. The framework supports a wide range of video and audio formats4,and more CODECs can be added. The Mimicry player is a Java Bean encapsulating the Java MediaFramework player. It is basically interfaceless, but implements a rich API and event interface thatcan be utilised by other components.

The Mimicry controller is, referring back to Figure 2, an applet that communicates with the Navettetool through the Browser component; it thus acts as an intermediary between the Arakne Environ-ment and the Mimicry player. The Mimicry controller provides the interface to the Mimicry playeras well as to Navette. The Mimicry controller acts as the interface of the Mimicry player to the user.The controller has a control panel for the browsing and creation of anchors, which can be displayedby right clicking on the player window.

4 Supported formats include AIFF, WAV, AVI, MIDI, MPEG-1, and QuickTime.

6.1 Web Page Modification by the DHMProxyMultimedia files are normally presented in a Web browser using the appropriate plug-ins, accordingto the MIME type of the file. This is done either by using a direct link to the file or by embedding itinto a Web page using <EMBED> or <OBJECT> tags. The Mimicry player is designed to mimic plug-ins, and will appear (to the user) as an ordinary plug-in on a Web page.

Rather than depending on Web page designers to adopt the Mimicry player as the standard viewerapplet, the system utilises the DHMProxy [9] to modify Web pages, so that the Mimicry player isused instead of plug-ins.

The DHMProxy is aware of the formats supported by the Mimicry player and changes the Webpages accordingly. If a Web page embeds temporal media using <EMBED> or <OBJECT> tags, thesetags are replaced with a corresponding <APPLET> tag with the same layout dimensions. If a Webpage has a direct link to a temporal media file, the DHMProxy returns a Web page containing the<APPLET> tag in the body of the page. Using this approach it is possible to translate plug-in invoca-tions into applet invocations, without changing the layout of the Web pages.

The DHMProxy also takes care of inserting anchors from the chosen link collections on the structureserver into the Mimicry controllers. All the anchors residing in a media clip are passed on to theapplet in parameter tags consisting of name, id, and time span. When the Web page is loaded in theWeb browser and the Mimicry controller applet is launched, it is thus aware of the anchors in themedia clip. This modification or decoration is basically similar to the ordinary text decoration (thatis, insertion of links) done by the DHMProxy.

6.2 Mimicry in ActionIn order to present Mimicry in action, we have started the Arakne Environment, which launches theWeb browser5, as presented in Figure 3. The Web browser has been configured to use theDHMProxy. As we want to create links into Web pages and media files, we have started Navette inthe Arakne Environment.

The situation in Figure 3 is as following: another user has earlier created a link with the name ‘Link10’ in the link collection ‘Hyperspace1’, which contains three anchors. The first anchor ‘HarrisonFord’ originates in a Web page containing a description of the actor Harrison Ford. The second an-chor ‘Quote’ originates in a Web page containing famous movie quotes, referring a specific quote.The third anchor ‘Endpoint 14’ originates in a movie clip embedded in a Web page, referring to a 59seconds long segment of the 2:02 minutes long clip, that features the quote.

Browsing the Web using the Arakne Environment, we encounter the Web page containing the moviequotes. Since we have ‘Hyperspace1’ opened, the DHMProxy has decorated the page with the‘Quote’ anchor. The anchor is presented, so that we can follow ‘Link 10’ either to the media segment‘Endpoint 14’ or to the Web page containing the anchor ‘Harrison Ford’. We decide to follow thelink to the media anchor and the Web page containing the video clip is loaded, as shown in Figure 3.

The DHMProxy decorates the Web page by substituting the plug-in tag with an applet tag and an-chors from the structure server. When the Mimicry controller applet is launched it retrieves its an-chors from the parameter tags, alerts the Arakne Environment to its existence and asks the Mimicryplayer to start downloading the media file. In Navette ‘Link 10’ is opened and the ‘Endpoint 14’ an-chor is in focus.

5 The current version is integrated with the Microsoft Internet Explorer

Begin Anchor

Play

Play Anchor

Follow Link

Create Anchor

End Anchor

Figure 3 - Playing the anchor endpoint "Endpoint 14"

Clicking on the Mimicry control applet, the 59 seconds segment ‘Endpoint 14’ will be played, start-ing at 25.7 seconds and ending at 1:34.7. Interested in the movie clip we right-click on the applet anda popup menu appear. In the popup menu it is possible to select other anchors in the clip or to openthe control panel. We choose “open control panel”, and the control panel, on top of the Web browserand the Arakne Environment in Figure 3, is presented. The control panel consists of a slider, indi-cating the length and current position of the media clip, buttons for creating/editing anchors and adropdown menu containing all the anchors in the media clip. The current anchor is drawn on theslider.

Dragging the slider to the start position and pressing the “Play” button causes the Mimicry player tostart playing from the beginning. While watching the media clip, we notice the actor Gary Oldman,and decide to find more information about him. In the dropdown menu containing all the anchors inthe media clip, we find another media anchor named ‘Endpoint 11’. Selecting ‘Endpoint 11’ andplaying it, we realise the anchor is covering the part of the clip depicting Gary Oldman. Wondering ifthe link is about the actor, we click the “Follow Link” button on the control panel. The browser loadsanother URL, which is a direct link to another movie clip, resulting in the situation shown in Figure4.

Another Mimicry controller is launched and Navette has changed its focus to ‘Endpoint 12’ in ‘Link5’. Clicking the Mimicry controller, the segment ranging from 1:04.8 to 1:33.7 of the movie file isplayed. The ‘Endpoint 12’ segment does indeed refer to Gary Oldman appearing in another movietrailer.

Watching the movie trailer from the beginning, we find yet another actor, Matt LeBlanc. Since wehave had the pleasure of following links created by others, we would like to add an additional link tothe current link collection. We know where to find further information about Matt LeBlanc and de-

cide to create this relation. In Navette we deselect the current link. In the control panel, we create anew media anchor using the “Begin Anchor” and “End Anchor” buttons, editing a few times, re-viewing the new anchor several times with “Play Anchor” and finally end up with exactly the portionof the clip concerning Matt LeBlanc. We press “Create Anchor” in the control panel, and as no linksare selected in Navette, a new link ‘Link 25’ is created, initially containing the anchor ‘Endpoint 15’.The Arakne Environment stores the new link and anchor on the structure server. We browse the Webto a Web page containing more information about the actor as shown in Figure 5.

Figure 4 – Playing the anchor ‘Endpoint 12’

When the Web page is retrieved, we highlight the text ‘Matt LeBlanc’ in the Web browser, rightclick and select “Add Anchor” in the popup menu6. This information is sent to Navette, which reactsby creating the endpoint “Matt LeBlanc”. Pressing the refresh button in the Web browser forces theDHMProxy to decorate the Web page with the newly created anchor. In the Web browser, the newanchor is presented as a link in ‘[*]’ next to the Matt LeBlanc text. To test the link, we click it, andthe media clip from Figure 4 is loaded, ready to play ‘Endpoint 15’. If we open the control panel andpress the “Follow Link” button the Web page from Figure 4 is loaded. We have now created a link inthe link collection ‘Hyperspace1’. Next time another user is browsing the Web using the ArakneEnvironment and the ‘Hyperspace1’ link collection, he or she will be able to see and follow theselinks.

6 The essential commands for link creation with Navette are available through the use of right-clickmenus on highlighted text in the Microsoft Internet Explorer.

Figure 5 – Creating a HTML anchor using Navette

We have now described how to follow a link to a media clip using Mimicry, how to follow linksbetween two media clips, and how to create anchors and links. In Figure 3 the Mimicry is used asembedded on an HTML page, and in Figure 4 Mimicry is used standalone as a direct link to a mediaclip.

7 DISCUSSIONThe following will discuss the implication of the results in the context of plug-in developers.

7.1 The Problem with Current Plug-insPlug-ins are used to handle media types not supported natively by the Web browser. Plug-ins can becontrolled at runtime through LiveConnect [11] using JavaScript. In order to support linking in andout of temporal media, we need to continuously be able to get and set the state of the plug-in. Thedegree of openness to this kind of control varies tremendously. The most extreme example of anopen plug-in handling temporal media that the authors have been able to locate is the Beatnik plug-inpublished by Headspace. Beatnik is a plug-in targeted at sound and music files, and has a very richAPI. The APIs supported by some popular plug-ins are shown in Table 1. Beatnik is sound only, andis as such only used as a comparison to the other media players, as well as Microsoft Media Playerwhich cannot be controlled through JavaScript.

Apart from Beatnik, no plug-in allows for the playing of a designated but not in the media predefinedsegment. This ability is fundamental to link following in temporal media, and it is thus not possibleto create a hypermedia system supporting links to and from media clips with these plug-ins. The richauthoring environments of some media tools, especially QuickTime7, make the lack of support formodifications at run-time more grating. The author should certainly have a very rich authoring tool

7 However, QuickTime offers another approach as mentioned in section 8.

at his or her disposal, but that does not eliminate the need to be able to dynamically alter the play-back of a media clip, as it is shown on a Web page.

Plug-in/Content Handler Methods1 Callback Methods1

Real RealPlayer SetSourceDoPlayPauseDoNextItem2

DoPrevItem2

onClipOpenedonGoToURL

Apple QuickTime 3 3

HeadSpace Beatnik getPlayLengthgetPositionsetPositionsetStartTimesetEndTime

onLoadonReadyonStop

Microsoft Media Player4 GetCurrentPositionSetCurrentPositionGetSelectionStartSetSelectionStartGetSelectionEndSetSelectionEnd

1 This is not a comprehensive list, but merely methods relevant to linking. 2 These methods require that

the items are defined by the author of the media clip. 3 QuickTime does only support arguments to the

<embed> tag. 4 The methods described are through the COM-interface, not JavaScript.

Table 1 - Supported APIs of various plug-ins

Integration with plug-ins requires some degree of openness on part of the plug-in API. In order tosupport linking (and other kinds of integration) it must at least be possible to designate a segment ofa recording and to allow that segment to be played. Specifically we would suggest that the methodsoutlined in Table 2 could the basic API of any plug-ins handling temporal media.

Methods Callback MethodsgetSourceURLsetBeginClipgetBeginClipsetEndClipgetEndClipgetDurationgetCurrentTimeplayPauseplayClip

onLoadcallbackWhen

Table 2 - Basic API requirements for temporal media plug-ins

A plug-in would thus be able to play a designated clip or segment of a media clip and would reportits progress through the media clip. This API would allow a developer to support the kinds of inter-actions supported by the Mimicry player through the use of JavaScript and LiveConnect [11]. ThisAPI is simple and should be easy to implement for plug-in developers. The Beatnik plug-in clearlydemonstrates that this is indeed achievable.

Another solution investigated by the Coconut project is to make a specific integration with a mediaplayer, in this case the Microsoft Media Player that through its COM-interface supports a rich API.External applications would register events from the Media Player and through the COM-interfacecontrol it. Being a COM-component the Media Player can be integrated into a user interface sup-porting anchor and link creation. This approach does have some limitations. It is platform dependent,and unless a proxy is used to modify the Web pages as described below, the supporting software is

forced to change content handler while the Web page containing the media clip is being displayed.This is possible, but it is neither elegant nor seamless.

8 FUTURE DEVELOPMENTUnless a media player emerges that satisfies the needs of temporal media linking, the authors willcontinue to work on the Mimicry player. Some current development holds promise with regards tofuture versions. Future versions of the Java Media Framework will support more media formats andsport additional improvements. An interesting development would be Java Media Framework sup-port for streaming, which is currently offered by Real Networks, but this version is so far limited toNetscape Communicator.

As media players and Web browsers supporting SMIL and HTML+TIME become available, we willinvestigate the possibilities of linking into the new structures supported by these standards, as well asusing the new generation of plug-ins and viewers supporting these formats.

Apple has created QuickTime for Java, featuring an API similar to the Java Media Framework, beingable to playback formats supported by the QuickTime plug-in 2.0 in an applet. This may be an areaworthy of future investigation.

The current Mimicry player is a Java applet, and a clear future direction would be to convert theplayer into a plug-in. This would probably eliminate much of the need for the intervention byDHMProxy, as the Mimicry plug-in would automatically launch on its registered MIME types.

9 CONCLUSIONWe have described a system allowing users to dynamically create links to and from temporal mediaon the Web regardless of the users’ ownership of the Web pages or media clips involved. The systemhas not been created to compete with existing media players, but merely to allow for experimentationand to highlight the lack of support for dynamic uses of temporal media currently found in mostplug-ins. As such it has been successful.

The future of temporal media on the Web is a bright one. Bandwidth will continue to rise andemerging standards such as SMIL and HTML+TIME will support the use of temporal media in newways. Whether these standards will converge to support only presentation, or open for more dynamicuses remains to be seen.

10 ACKNOWLEDGEMENTThe authors are members of the Coconut project (http://www.cit.dk/coconut/), a joint research proj-ect consisting of Department of Computer Science, Aarhus University and Tele Danmark Internet.The Coconut project is supported by the Danish National Centre for IT-Research(http://www.cit.dk/).

The authors wish to thank Niels Husted and René Thomsen for adding to the code, Peter Ørbæk forcreating the DHMProxy, and the anonymous reviewers for good suggestions.

11 REFERENCES[1] Anderson, K. M. (1997). Integrating Open Hypermedia Systems with the World Wide Web. In

Proceedings of the ACM Hypertext 97 Conference, pp. 157–166, Southampton, England.

[2] Auffret, G., Carrive, J., Chevet, O., Dechilly, T., Ronfard, R., and Bachimont, B. (1999). Audio-visual-based hypermedia authoring: using structured representations for the efficient manipula-tion, of AV documents. In Proceedings of the ACM Hypertext 99 Conference, pp. 169–178,Darmstadt, Germany.

[3] Bouvin, N. O. (1998). Designing Open Hypermedia Applets: Experiences and Prospects. In Pro-ceedings of the ACM Hypertext 98 Conference, pp. 281–282, Pittsburgh, USA.

[4] Bouvin, N. O. (1999). Unifying Strategies of Web Augmentation. In Proceedings of the ACMHypertext 99 Conference, pp. 91–100, Darmstadt, Germany.

[5] Carr, L. A., De Roure, D., Hall, W., and Hill, G. (1995). The distributed link service: A tool forpublishers, authors and readers. In Proceedings of the 4th International World Wide Web 95Conference, Boston, USA.

[6] Carr, L. A., Hall, W., and Hitchcock, S. (1998). Link services or link agents? . In Proceedings ofthe ACM Hypertext 98 Conference, pp.113–122, Pittsburgh, USA.

[7] DeRose, S. J., and Durand, D. G. (1994). Making HyTime Work. Kluwer Academic Publishers,1994.

[8] Grønbæk, K., Bouvin, N. O., and Sloth, L. (1997). Designing Dexter-based hypermedia servicesfor the World Wide Web. In Proceedings of the ACM Hypertext 97 Conference, pp. 146–156,Southampton, England.

[9] Grønbæk, K., Sloth, L., and Ørbæk, P. (1999). Webvise: Browser and Proxy Support for OpenHypermedia Structuring Mechanisms on the WWW. In Proceedings of the 8th InternationalConference on the World Wide Web, Toronto, Canada.

[10] Hirata, K., Hara, Y., Takano, H., and Kawasaki, S. (1996). Content-oriented Integration in Hy-permedia Systems. In Proceedings of the ACM Hypertext 96 Conference, pp. 11–21, Washing-ton D.C., USA.

[11] Hoque, R. Java, JavaScript and Plug-In Interaction Using Client-Side LiveConnect.http://developer.netscape.com/docs/technote/javascript/liveconnect/liveconnect_rh.html

[12] HTML+TIME. http://www.w3.org/TR/NOTE-HTMLplusTIME

[13] Java Media Framework. http://www.javasoft.com/products/java-media/jmf/index.html

[14] Jühne, J., Jensen, A. T., and Grønbæk, K. (1998). Ariadne: A Java-based guided tour system forthe World Wide Web. In Proceedings of the 7th International World Wide Web 98 Conference,Brisbane, Australia.

[15] Lewis, P. H., Davis, H. C., Griffiths, S. R., Hall, W., and Wilkins, R. J. (1996). Media-basedNavigation with Generic Links. In Proceedings of the ACM Hypertext 96 Conference, pp 215–223, Washington D.C., USA.

[16] Maler, E., and DeRose, S.J. (Eds.). (1998). XML Linking Language (XLink) Design Principles.http://www.w3.org/TR/NOTE-xlink-principles

[17] Maler, E., and DeRose, S.J. (Eds.). (1998). XML Pointer Language (XPointer).http://www.w3.org/TR/WD-xptr

[18] Maurer, H. (Ed.) (1996). Hyper-G now, HyperWave: The next generation Web solution,Addison-Wesley, Harlow, 1996.

[19] SMIL. http://www.w3.org/AudioVideo/

[20] Statsbiblioteket. Dansk Lydhistorie. http://www.sb.aau.dk/dlh/

[21] Whitehead Jr., E. J. (1997). An architectural model for application integration in open hyperme-dia environments. In Proceedings of the ACM Hypertext 97 Conference, pp. 1–12, Southampton,England.

12 VITAE

Niels Olof Bouvin is a Ph.D. student in Computer Science at University ofAarhus, Denmark. His research interests include open hypermedia sys-tems, Web augmentation, structural computing, and collaboration on theWeb. He is currently involved in the Coconut project, a co-project be-tween the Department of Computer Science and Tele Danmark Internet.Niels Olof Bouvin received his master’s degree in 1996 from Departmentof Computer Science, University of Aarhus, Denmark.

René Schade is a system developer at Tele Danmark Internet, Denmark.He is currently working at the Coconut project, a co-project with the De-partment of Computer Science, University of Aarhus, Denmark. He fin-ished his master degree in 1997 from the Department of Computer Sci-ence, University of Aarhus. His research interests are: World Wide Web;Hypermedia and Multimedia and Dynamic Programming Environments�

Experiences with OHP and Issues for the future

Niels Olof Bouvin

Department of Computer Science, University of Aarhus,Aabogade 34, 8200 Arhus N, Denmark

n.o.bouvin@daimi.aau.dk

Abstract. The OHSWG has by now moved from specifications to run-ning code. This is an important step, not only because this is the only wayof maturing the specifications, but also because it strengthens the credi-bility of the OHSWG. Showing that the ideas expressed by the OHSWGcan be implemented is however not enough, at least not if we desire awider audience than ourselves. Concomitantly the XLink standard hasbegun to take shape, metadata on the Web seems to be on the rise, andinterconnectedness is sharply rising with various small devices (such asWAP phones and PDAs) gaining access to the Internet. We are living ininteresting times. Based on the experiences of developing the Arakne En-vironment, the author attempts to point out some worthwhile directionsfor future work within the OHSWG.

1 Introduction

The original goal of the Open Hypermedia Systems Working Group was to iden-tify what constituted open hypermedia and to devise a common standard, sothat open hypermedia systems could interoperate, and possibly share accessto integrated third-party applications. Some of these goals have now been met.There is a common standard, and the Group has now several times at Hypertextconferences demonstrated heterogeneous hypermedia systems working togetherthrough the Open Hypermedia Protocol (OHP).

Existence has thus been established, and yet we do not find the world break-ing our door down in order to get hold of this amazing technology. The authorhas over the last few years designed and developed an open component-based hy-permedia system, the Arakne Environment, which is now based on the OHSWGcompliant Construct servers. The experiences with converting to OHP are re-lated in this position paper with some pointers for future concern are raised,especially with regards to future standardization work.

2 The Arakne Environment

The Arakne Environment has been described in ([2], [4], [3]), and for the pur-poses of this paper there is no need to go into great detail. Arakne is a frameworkfor open hypermedia programs, and currently supports navigational, temporal,guided tour, and spatial hypermedia on the Web. The system has gone through

several iterations and now uses the OHSWG compliant Construct servers asstructure servers. The original design idea was to create a system where func-tionality could be easily added without affecting the rest of the system — ahypermedia plug and play system. Over the design and development iterationsthis ideal has come closer.

3 Experiences with the development of the ArakneEnvironment

This section will describe the process of converting the Arakne Environmentto a native OHP application. As Arakne started out as a Ph.D. project therewas never existing legacy applications, allowing for radical redesigns (such asreplacing the hypermedia protocol used in the original version with OHP).

3.1 The transition to OHP

The Arakne Environment did not start out using OHP. The original version reliedon the Devise Hypermedia servers, but as the Construct servers were completedwithin the same project as Arakne, the transition to OHP began. One advantagein the context of this conversion was the code sharing between server and client,as both are written in Java. As OHP is language independent, the transitionwould under all circumstances have been possible albeit admittedly more timeconsuming. The open source nature of Construct does not limit the advantageof code reuse to the developers associated with Construct.

The first version of Arakne to utilize OHP was version 2.0. This was not acomplete transition, as only the components that communicated with the struc-ture servers were changed — the rest were (virtually) unchanged. This was arelatively simple operation as the original data model was based on DHM [12](and thus Dexter [13]), and the gap to the OHSWG data model was relativelyminor. The components communicating with the Construct servers would thentransparently convert between the Arakne and the OHSWG data models, e.g.folding OHSWG anchors and endpoints into Arakne endpoints and vice versa.This ’hack’ allowed us to get up to speed relatively rapidly, so that we couldcommence testing of the structure servers forthwith.

Given the nature of hypermedia conversion [15], this first step did not usethe full functionality of the Construct servers. The features not supported bythe hypermedia applications (known as ’NavLets’ or ’views’) could naturally notbe utilized on the structure servers. The most important missing feature wasthe support for sessions, which is a key component in the OHSWG support forcollaborative work.

This, and extensibility concerns, led to a complete redesign of the Araknearchitecture and a full adoption of the OHSWG data model, resulting in thecurrent version 2.1. This was a considerably more involved task as all existingcomponents in the framework were either modified or completely rewritten andnew components handling sessions and collaboration had to be added.

The current architecture allows users to be engaged in an arbitrary numberof sessions using any number of hypermedia views. Each session has its own datamodel, coupling mode, and views, independently of other sessions. This has beenaccomplished without major changes in the views, while still allowing them roomto extend support for collaboration between users as the view developers see fit.

The author would like to see more hypermedia systems support OHP, andthere are some lessons that can be learned from the experience of convertingArakne to OHP.

The first lesson is that the system actually works! OHP can be used for morethan once a year Hypertext Conference demonstrations. Arakne along with theConstruct servers are thus among the growing number of validations of the ba-sic design of the OHP. One of the original goals of OHP was to allow dissimilarhypermedia systems to interoperate and to share third party application inte-grations. In this context the Arakne Environment is probably special, as it doesno longer have a hypermedia protocol of its own — it has fully embraced OHP.

The second lesson is it is not necessary to natively1 support OHP. Using anextra component to convert from one data model to another is close in principleto the shim of [6], though the conversion is from a protocol to an API rather thanfrom protocol to protocol. It should be noted that the task of converting Arakneto OHP was considerably smaller than e.g. establishing interoperability betweenChimera and HyperDisco [19], where the target was true interoperability (we justwished to move Arakne from DHM to OHP), and where there were significantdissimilarities between the systems, including features, programming language,and protocol format. DHM and OHP are fairly close — both utilize XML (or atleast tagged ASCII) for transport, the data model are similar, and the transitionto OHP was made easier by the existence of available Construct Java libraries.The method used to integrate Chimera and OHP (under development as thisis written) is in principle similar to the one used by the version 2.0 Arakne.Existing Construct libraries are plugged into Chimera with additional code tohandle the conversion back and forth. This is a more ambitious and excitingintegration, as Chimera (as opposed to Arakne 2.0) natively supports sessions.

3.2 Adding new functionality — “Embrace and Extend”

One of the original design goals of the Arakne framework was to provide ageneral framework for all Web augmentation hypermedia tools. In practice thefirst version integrated Navette (a navigational hypermedia tool and a successorto DHM/WWW [9]) and Ariadne [14] (a guided tour tool not originally de-veloped for Arakne). The latest hypermedia tool to be integrated with Arakneis CAOS [17] (a spatial hypermedia tool), which also originally was not devel-oped for Arakne. By having an open architecture, Arakne has thus been ableto “embrace and extend” already existing hypermedia tools. As support for col-laborative work is now an integrated part of Arakne, this functionality is madeavailable for the new views.1 i.e. abandon the existing data model etc. in lieu of OHP

3.3 New protocols

New structural domains (such as spatial hypermedia [16]) are emerging and areswiftly becoming one of the most dynamic and interesting areas in hypermedia(as witnessed by popularity of the Structural Computing workshops). Hyperme-dia is no longer “just” navigational links and anchors.

OHP handles navigation and collaboration through sessions. The Constructservers have been extended to provide additional services through the OHP-Comp (composites) and OHP-Space (spatial hypermedia). New services can beadded to the Construct servers and Arakne, as they become available. Indeed,with the development of the Esbjerg CSC tools [18], adding new services hasbecome even easier.

The new structural domains are areas where the OHSWG can contributetremendously to the hypermedia community at large by providing solid proto-cols and structure servers. We have the knowhow and the robust servers, andshould be able to help other workers in the hypermedia community. The activediscussions following the presentation of CSC by Wiil and Nurnberg at HT2000were witness to that this is an idea whose time has come.

3.4 The evolution of OHP

It should be noted that the OHP of the Construct servers does not fully follow theDarmstadt DTD. This is not so much of a problem as it might first seem, for stan-dards must necessarily be validated through implementation. Some changes andclarifications became necessary and were subsequently implemented. It shouldhowever be clear that the changes made to OHP must be documented and pub-lished, in order to support further discussion and development of the OHP. Theissue of proper protocol documentation will be dealt with in section 4.

4 The need for further standardization

A basic requirement of any standard is a precise and unambiguous definition.Unfortunately, the current OHSWG OHP specification is lacking in this respect.This leads to problems with interoperability between different implementations,exactly what OHSWG was supposed to solve! This section will describe theproblem and propose possible solutions.

4.1 The problem with XML

One result of the OHSWG 4.5 meeting was creation of the On the Wire group,who was given the task to determine what transport layer the Open HypermediaProtocol should utilize. The author was a member of this group, and the eventualrecommendation was to use XML documents over sockets as the basic entrypoint, with CORBA support left for more advanced servers.

The rationale behind choosing XML was fairly solid: XML is easy to parsewith free XML parsers available for most programming languages; it is human

readable which eases debugging considerably; and using validating XML parserguarantees adherence to a given grammar. All this combines to make the entryinto OHP relative easy and painless. Furthermore one should not be blind tonecessity of being “buzzword-compliant” in this wired world, and XML certainlyfulfills that purpose.

One problem that has emerged over time with XML is the level of detailexpressible with the DTD grammar. DTD is well suited for general syntacticdeclarations, but cannot express semantics nor more fine-grained syntactic as-pects such as data types or ranges. This is witnessed by the proliferation of#CDATA (i.e. unspecified character data) in most DTDs. Thus the specificationis not enough by itself. It must be accompanied by either exhaustive documen-tation or code implementing the standard, if not the implementation will beleft to guesswork by the developer. Data and code are closely integrated in thissetting, and this has several disadvantages. XML was originally set out (thoughadmittedly like much Internet technology, it was over hyped at the time of itsintroduction) to ease data interchange by creating solid specifications to separatecode and data. The reality is that while this goal has been partly accomplished,the devil (as always) is in the details and this is where XML is still lacking.

The lack of detailed specification has also hurt OHP. The Darmstadt DTDthat forms the (excellent) basis for OHP contains many instances of #CDATAwhere the details are left to the implementation. While this is just a set ofdecisions to be made when dealing with one implementation of OHP (such asConstruct), it becomes a problem when interoperability — one of the purposesof OHSWG — is the goal. As mentioned in section 3.4, the development ofConstruct led to a number of choices with regards to what OHP is. Anotherimplementor of OHP can however not be relied on making the same choices —the hectic work leading up to last year’s OHSWG demonstration showed theproblems with this approach, as there were several areas where the different im-plementations had to be modified to accommodate the differences. One solutionto this is to adopt an existing implementation; this is the case of the currentOHP/Chimera integration (mentioned in section 3.1), but this requires a certaincompatibility between the systems with regards to e.g. programming languages.

It was suggested by Peter J. Nurnberg at OHSWG 5.5 that the time hascome for OHSWG to adopt a reference OHP implementation. The author agreeswith this notion, but would like to see it extended. One of the requirementsof a proposed standard submitted to the W3C is that there should be a clearspecification and at least two independent and compatible implementations ofthe specification. This is a very important point, as it lessens the probabilityof idiosyncrasies in one implementation determining the specification and fortacit, unspecified details to make it into the final standard. If we are to moveforward to make OHP a “proper” standard (at standard bodies such as IETFor W3C), as discussed in 5, we must address this issue. As long as we maintaincompatibility OHSWG can only benefit from such a move. One benefit would bethat is unlikely that “one size fits all” when it comes to server implementations,e.g. a structure server using a file-based storage suited for a small work group or

an individual user, would not be applicable in the context of a large organizationwith more demanding performance and stringent backup requirements.

This still leaves the issue of clear and detailed specification. In the author’sopinion XML continue to have much going for it — all the original advantagesare still valid. OHSWG are however not the only party that has discovered thatDTDs are insufficient for detailed specification. Currently several standards areunder development to extend XML with a precise specification language. XMLSchema [8] is an ambitious W3C standard currently in Draft state. XML Schemawill allow the precise specification of data types and attributes as well as thedefinition of new data types. As such, it can form an excellent specificationlanguage for future versions of OHP.

It would better still, if we for future work could leave the highly detailedworld of XML behind, and work with higher level specifications. The EsbjergCSC tools [18] promises to be such a tool. Using IDL as a specification language,allows developers to work with a more natural level of detail, while developingnew services or implementing existing ones. As CSC will have the ability toexport DTDs (and conceivably this could be extended to XML Schemas), thelow cost entry point of XML is maintained if a developer should desire to useXML on the wire. Furthermore by distinguishing between specification (IDL)and actual protocol, it is possible to support new protocols, such as CORBA,by implementing the changes in the CSC tools.

A modest proposal for future standards submitted to the OHSWG would beto accompany all specifications with open source code, so that other membersrapidly could use the new standards, if they should so desire. Indeed, the opensource nature of Construct, CSC, and to come, Arakne, are steps in such adirection.

4.2 The existing data model

The OHP data model has been designed to be extensible. Through the use ofkey/value attributes, it is possible to customize the existing data types to mostapplications. Again this is something that works well within one implementationof OHP, but makes it difficult to export e.g. the LocSpecs of one OHP implemen-tation to another, as the exact content of the LocSpec is left to the individualimplementation. The OHSWG spans a wide field of hypermedia usage and mediatypes and it is probably not realistic to expect a complete standardization on thecontent of e.g. LocSpecs. However, establishing shared standards for LocSpecs incommon media types such as Web pages, XML documents, and bitmap imageswould facilitate one of the original goals of the OHSWG, namely the sharing ofthird-party application integrations. In this area we should also not hesitate toadopt standards such as XPointer [5] as we see fit.

4.3 An OHP interchange format

The author suspects that most of the hypermedia systems created by the mem-bers of OHSWG have an interchange format in one form or another — it is

certainly the case for Webvise [11], Arakne, and Chimera [1]. There has previ-ously been a call for an OHP interchange format [10], and at Aarhus we havedeveloped and used an interchange format based on OHP (essential followingDarmstadt minus the operations). This format has since been extended and isdocumented as the Open Hypermedia Interchange Format (OHIF) in [11]. Ashared OHP interchange format would benefit us with regards to interchange,but it would also make an essential part of a future IETF/W3C OHP standard.

Interchange formats have also other uses. As a part of Coconut project ofwhich the author is a member, a guided tour tool (Ariadne, which also is a partof Arakne) were changed into an applet and deployed on a Danish high-profileInternet portal http://www.opasia.dk/. The purpose was to give ordinary Websurfers access to guided tours authored by the editorial staff at the portal. Oneof the major concerns when designing this applet was scalability and a solutionbased on a structure server was ruled out partly because of scale, partly becauseof firewall concerns, and partly because of the Java applet sand box limitations.The generated guided tours were instead exported into a XML interchange for-mat, which then could be easily downloaded from the portal. The system receivedwide use (at least 15.000 users had by January 2000 downloaded and used theapplet). This is an illustration of a case where the interchange format is actuallythe main target and not some intermediary file.

5 The way to proper standardization

It will avail us naught that we create an excellent open hypermedia standardif no one notices or uses it. At least not if we desire more than publicationopportunities. Furthermore a standard based “only” on the collaboration of abunch of academics is not likely to gather much steam in the IT industry.

As suggested by E. James Whitehead Jr. at the OHSWG 5.5 meeting thetime has indeed come for us to disseminate OHP outside OHSWG by creatinga “proper” standard.

That there is room for open hypermedia standard is supported by the emer-gence of XLink [7] — a standard for (largely) navigational hypermedia in (mainly)XML documents. The XLink community has in the context of XML been work-ing with many problems familiar to the OHSWG. At this point the membersof the OHSWG have an established infrastructure, we support more than navi-gational hypermedia, we have integrated numerous third-party applications, wehave the know-how to integrate more, and we are not limited to the Web. Ifwe can make our varied and sophisticated hypermedia applications interoperatethrough OHP, and provide others with the technology to do the same, we willhave a strong demonstration of what OHP is capable of.

The first step to a proper standard will however be to establish somethingthat we can present to the world, possibly using the tools described in section 4.Given that, it should be relatively painless to create a RFC. Such a standardshould consist of at least an interchange format (see section 4.3), as well a spec-ification of the operations that can performed on the hypermedia structures. In

other words, an extended version of Darmstadt. We are already close to thistarget, and it would be a pity not to go further. The worst-case scenario wouldbe that our proposed standard is ignored by the rest of the world, but then atleast we will ourselves have benefited from the clarification of pinning down thestandard.

Beyond RFC, we must consider which standard body our standard belongsto — obvious choices are IETF or W3C, but the discussion of that should bedeferred to the time we have created an actual RFC.

6 Conclusion

One of the purposes of this position paper has been to document the feasibil-ity of adopting OHP, and the advantages that it gives. In order to stop OHPfrom becoming just yet another hypermedia protocol, it is important that themomentum is kept and that other hypermedia systems either convert or inter-face to the OHP. In that process we must further specify and standardize OHP.This will benefit us double: it will allow systems and users to interoperate andinteract (and thus realizing the original goal of sharing third-party applicationintegrations), and it is a showcase for the validity of the work of the Open Hy-permedia Working Group. We must practice what we preach, if we are to betaken seriously.

7 Post Scriptum

As a result of OHSWG 6.0, the author has committed to lead in the creation ofan OHP RFC. The creation and discussion of this important document can beexpected to form a major part of the the OHSWG 6.5 meeting. As of this writingthe contents of the RFC can be expected to contain at least the following:

– The navigational data model (preferably also composite and spatial)– OHP-Nav (ditto OHP-Comp and OHP-Space)– Session data model– OHP-Session– A mapping to protocols (XML, CORBA) based on the Esbjerg CSC work

[18]– An interchange format (presumably an extension and generalization of OHIF

[11].

Acknowledgments

The author is a member of the Coconut project (http://www.cit.dk/coconut/),a joint research project consisting of Department of Computer Science, AarhusUniversity and Tele-Danmark Internet. The Danish National Center for IT-Research (http://www.cit.dk/) supports the Coconut project. The authorwishes to thank Rene Thomsen, Michael Bang Nielsen, and Henning Jehøj Mad-sen for their work on Arakne, and Kenneth M. Anderson for valuable discussions.

References

1. K. M. Anderson. Integrating open hypermedia systems with the World Wide Web.In M. Bernstein, L. Carr, and K. Østerbye, editors, Proceedings of the 8th ACMHypertext Conference, pages 157–166, Southampton, UK, Apr. 1997.

2. N. O. Bouvin. Unifying strategies for Web augmentation. In Proceedings of the10th ACM Hypertext Conference, pages 91–100, Darmstadt, Germany, Feb. 1999.

3. N. O. Bouvin. Designing user interfaces for collaborative Web-based open hyper-media. In Proceedings of the 11th ACM Hypertext Conference, pages 230–231, SanAntonio, USA, May 2000.

4. N. O. Bouvin and R. Schade. Integrating temporal media and open hypermediaon the World Wide Web. In Proceedings of the 8th International World Wide WebConference, pages 375–387, Toronto, Canada, May 1999. W3C.

5. R. Daniel, S. DeRose, and E. Maler (editors). XML Pointer Language(XPointer). W3C Working Draft 6 December 1999, W3C, Dec. 1999.http://www.w3.org/TR/xptr.

6. H. C. Davis, A. Lewis, and A. Rizk. OHP: A draft proposal for a standard openhypermedia protocol. In Proceedings of the 2nd Workshop on Open HypermediaSystems, number 96-10 in UCI-ICS Technical Report, pages 27–53, University ofCalifornia, Irvine, USA, 1996.

7. S. DeRose, E. Maler, D. Orchard, and B. Trafford (editors). XML LinkingLanguage (XLink). W3C Working Draft 21 February 2000, W3C, Feb. 2000.http://www.w3.org/TR/xlink/.

8. D. C. Fallside (editor). XML Schema part 0: Primer. W3c working draft, W3C,Feb. 2000. http://www.w3.org/TR/xmlschema-0/.

9. K. Grønbæk, N. O. Bouvin, and L. Sloth. Designing Dexter-based hypermedia ser-vices for the World Wide Web. In M. Bernstein, L. Carr, and K. Østerbye, editors,Proceedings of the 8th ACM Hypertext Conference, pages 146–156, Southampton,UK, Apr. 1997.

10. K. Grønbæk and L. Sloth. Supporting interchange of open hypermedia structuresand contents. In U. K. Wiil, editor, Proceedings of the 5th Workshop on OpenHypermedia Systems, number CS-99-01 in Technical Report, pages 34–37. AalborgUniversity Esbjerg, Denmark, Feb. 1999.

11. K. Grønbæk, L. Sloth, and N. O. Bouvin. Open hypermedia as user controlledmeta data for the Web. In Proceeding of the 9th World Wide Web Conference,pages 553–566, Amsterdam, Holland, May 2000. W3C.

12. K. Grønbæk and R. H. Trigg. Toward a Dexter-based model for open hypermedia:Unifying embedded references and link objects. In Proceedings of the 7th ACMHypertext Conference, pages 149–160, Washington DC, USA, 1996.

13. F. G. Halasz and M. Schwartz. The Dexter hypertext reference model. Commu-nications of the ACM, 37(2):30–39, Feb. 1994.

14. J. Juhne, A. T. Jensen, and K. Grønbæk. Ariadne: A Java-based guided toursystem for the World Wide Web. In Proceedings of the 7th International WorldWide Web Conference, Brisbane, Australia, 1998. W3C.

15. R. Killough and J. J. Leggett. Hypertext interchange with the Dexter model:Intermedia to KMS. TAMU-HRL 90-002, Hypertext Research Lab, Texas A&MUniversity, Aug. 1990.

16. C. C. Marshall and F. M. Shipman III. Spatial hypertext: Designing for change.Communications of the ACM, 38(8):88–97, 1995.

17. O. Reinert, D. Bucka-Lassen, C. A. Pedersen, and P. J. Nurnberg. CAOS: Acollaborative and open spatial structure service component with incremental spa-tial parsing. In Proceedings of the 10th ACM Hypertext Conference, pages 49–50,Darmstadt, Germany, 1999.

18. U. K. Wiil, P. J. Nurnberg, D. Hicks, and S. Reich. A development environmentfor building component-based open hypermedia systems. In F. M. Shipman, III,editor, Proceedings of the 11th ACM Hypertext Conference, pages 266–267. ACM,May 2000.

19. U. K. Wiil and E. J. Whitehead Jr. Interoperability and open hypermedia sys-tems. In U. K. Wiil, editor, Proceedings of the 3rd Workshop on Open HypermediaSystems, number SR-97-01 in CIT Scientific Reports, pages 137–145, Apr. 1997.

Enabling Project Awareness and Intersubjectivity viaHypermedia-Enabled Event Trails

Kenneth M. AndersonDepartment of Computer Science,University of Colorado, BoulderECOT 717, Campus Box 430,Boulder CO 80309-0430, USAE-mail: kena@cs.colorado.edu

Niels Olof BouvinDepartment of Computer Science,

Aarhus UniversityAabogade 34, DK8200Arhus N,

DenmarkE-mail: n.o.bouvin@daimi.aau.dk

ABSTRACTSupporting project awareness in the context of large-scalesoftware development is difficult. One key problem is iden-tifying appropriate abstractions and techniques for the in-sertion of project awareness mechanisms into a softwaredevelopment environment with minimal impact. An ad-ditional problem is scaling project awareness mechanismsto handle the demands of large-scale software developmentprojects. We present a framework to support awareness andintersubjectivity among software team members through theuse of automatically collected, hypermedia-enabled eventtrails. Event notification and open hypermedia concepts,techniques, and tools are used to support the framework inaddressing the two problems identified above. A distinctionof the framework is the presence of mechanisms that explic-itly support intersubjectivity among team members, enablinga high degree of quality to the project awareness in the team.

Keywordsintersubjectivity, event trails, project awareness, hypermedia,large-scale software engineering

1 IntroductionSoftware engineers in modern software developmentprojects are challenged by overwhelming information man-agement tasks. These tasks include, but are not limited to: re-quirements traceability, consistency management in the faceof change, and maintaining project awareness between teammembers who may be distributed across both time and space.This paper reports on work designed to address the thirdtask—project awareness—especially within the context oflarge-scale software development. Project awareness per-tains keeping individual team members informed of the over-all project progress, and aware of teammates’ actions. AsDourish and Bellotti state “... awareness is anunderstand-ing of the activities of others, which provides acontext foryour own activity[13].” Awareness thus touches on issues ofsharing information between team members such that they

can effectively coordinate the activities of their group.

To gain insight into the scope of information managementtasks faced by large software development projects, considerrecent work in supporting requirements traceability tasks ata major aerospace corporation [2]. In this instance, open hy-permedia techniques [27] were applied to just two subsys-tems of an avionics software package. These two subsys-tems consisted of approximately 34,000 pages of documen-tation used to document various aspects of their hundreds ofthousands of lines of code. For the requirements traceabil-ity tasks, the aerospace engineers were interested in just sixdifferent types of relationships, but on a system of this size,over 500,000 instances of these relationships needed to becreated and managed by the open hypermedia system!

More relevant to the domain of this paper, consider the num-ber of personnel that can be assigned to large-scale soft-ware development projects. InThe Mythical Man-Month,Fred Brooks states that, at one point, over one thousand em-ployees were assigned to his project to develop the OS/360operating system [9]. Modern projects addressing morecomplex problem domains will, of course, have similar orgreater staffing levels but with different characteristics interms of distribution. All one thousand members of Brooks’team were co-located at the same facility, whereas modernprojects are much more likely to be distributed across severalphysical sites of the same organization or across multiple or-ganizations (as is typical in the aerospace domain).

We therefore are concerned with two issues with respectto project management. First, how can project awarenessmechanisms be inserted into the development environmentof large software organizations? What infrastructure is re-quired and what techniques (and their associated tools) areenabled by the infrastructure? Second, how can projectawareness mechanisms be scaled such that they can provideutility in large-scale software development contexts?

With respect to the first issue, we develop a framework thatmakes use of techniques from the fields of open hypermediaand event-based messaging systems to achieveintersubjec-tivity between team members. We call this frameworkiScent(intersubjective collaborative event environment). Intersub-jectivity can best be defined by the phrase “I know that you

know that I know.” It is difficult to communicate withoutintersubjectivity, since humans typically need to know thatthey are being understood before proceeding with a conver-sation. In our framework, we view the actions performed bysoftware engineers as elements of a conversation. We pro-vide concepts and mechanisms to enable intersubjectivity tobe achieved in that conversation, thus supporting awareness.With respect to the second issue, we employ a variety oftechniques and strategies to construct a scalable implemen-tation of our proposed framework.

The rest of this paper is organized as follows. In the next sec-tion, we discuss related work. We then describe our uniqueapproach to the problem of project awareness in Section 3.Section 4 describes our initial attempt to implement ourframework. Section 5 describes our future research plans.We then conclude the paper with a summary of our contribu-tions in Section 6.

2 Related WorkIn this section, we cover related work from several disci-plines including open hypermedia, event notification sys-tems, process-centered environments, awareness support,and document management systems.

Open HypermediaIn open hypermedia systems, issues of collaboration havebeen addressed along a variety of dimensions including thecollaborative creation of hypermedia structures [18], concur-rency control in collaborative hypermedia systems [34], hy-permedia services in shared workspaces [35], and the sup-port for collaboration in Web augmentation systems [7, 8].Typically, support for awareness is derived from event noti-fication facilities contained in collaborative hypermedia sys-tems. These facilities notify all clients of the actions of thehypermedia system’s users. Thus, two users in a collabo-rative session will be notified whenever either user createsa link, deletes an anchor, etc. The Arakne environment, asystem for Web augmentation, [7] provides support over andabove simple event notification for its users by adding the no-tion of coupling modes [12] within a collaborative session.While these services in collaborative hypermedia systemshelp to provide awareness with respect to the hypermedia-related actions of members of a software team, they providelittle insight into other aspects of the team’s work. In con-trast, the iScent framework is designed to support the captureof multiple types of events covering a wide range of workactivities. We are currently in the process of integrating ourhypermedia systems, Arakne [7] and Chimera [3] into theiScent framework such that we can capture the hypermedia-related activities of software teams within iScent trails.

Event Notification SystemsThe iScent framework builds on top of the services providedby event notification systems (See Section 3 for details). Infact, as will be explained in Section 3, the iScent frameworkis independent of any particular event notification system,

such that an implementation can make use of any servicethat meets the requirements specified in Section 3. Eventnotification systems were first employed to support tool in-tegration in software development environments. One of thefirst systems to employ this approach in a local-area networksetting was Field [29]. Tool integration via events was alsoa part of Hewlett Packard’s SoftBench environment [10]. Inrecent years, event notification systems have been extendedto explore issues related to events across wide-area networks[11] and enabling project awareness [15, 16, 28].

With respect to the latter, each of these systems adopt a sim-ilar approach to iScent in which an event notification serviceserves as infrastructure to a higher level set of services. Forinstance, NESSIE [28] and Elvin [15] each use events gen-erated by applications (and sensors in the case of NESSIE)to provide project awareness through mechanisms such asa ticker tape application in which event notifications scrollacross the bottom of a user’s screen. The iScent frameworkdiffers slightly from these approaches in that it provides aunifying abstraction around which project awareness is con-veyed (event trails) and it provides additional mechanisms(as explained in Section 3) to enable intersubjectivity. Forinstance, with a ticker tape application, a user knows thathis events are being broadcast to other users in his or herworkgroup. However, they do not know if the users have ac-tually seen these events scroll by, perhaps because they wereaway from their desk at the time or the ticker tape applica-tion’s display was covered by some other application win-dow. In iScent, several mechanisms combine to achieve the“I know that you know that I know” quality of intersubjectiv-ity: namely that a user’s event has been delivered, its recipi-ent has seen it, and the recipient knows that the sender knowsthat he or she has seen it. These explicit mechanisms insurethat intersubjectivity has been achieved and thus raises thequality and fidelity of the project awareness among iScentusers.

Process-Centered Software EnvironmentsProcess-centered software development environments [1]provide techniques and tools for making the steps of a soft-ware life cycle more explicit and visible to the developersparticipating in a software development project. Recently,we performed an analysis of these environments, using ac-tivity theory [25], to examine their support for computer-supported cooperative work [5]. Our analysis, in part, in-spected the interaction paradigms employed by process-centered environments. This aspect is relevant to projectawareness, since it is through these paradigms that the stateof a software life cycle is conveyed to developers. There arethree interaction paradigms used in these environments:

• Task-oriented: This interaction style involves the useof agendas. Agendas manage lists of relevant tasks foreach user, as e.g. in SPADE-1 [4].

• Document-oriented: Interaction is achieved in these

2

systems via documents and document services. In Mer-lin [21], for instance, awork contextgraphically dis-plays the relevant documents available to and associatedwith each user role.

• Goal-oriented: Interaction in this paradigm is centeredaround a list of goals to be accomplished. In Marvel,for instance, these goals represent currently active rulesthat can be applied to the state of the process [22].

Each paradigm enables a limited form of project awarenessbut without the full range of support for intersubjectivity thatthe iScent framework provides. For instance, few of thesesystems allow users to specify events such as “notify mewhen Jane has viewed document A.” In addition, the pro-cess formalism being applied constrains the type of aware-ness that can be achieved among team members. At best,they are aware of their process. In contrast, the iScent frame-work’s use of trails of events allow the awareness of multipleaspects of a work environment to be captured, whether or notan event is associated with a particular software life cycle.

Awareness SupportSupport for awareness has a rich history of research. Forinstance, Dourish and Bellotti examined how shared feed-back mechanisms can contribute to project awareness amonggroups organized around a shared workspace [13]. Sharedfeedback involves the automated collection and distributionof information that is then presented as background informa-tion to the participants of a shared workspace. The iScentframework is an example of a shared feedback mechanismin which events are automatically collected and distributedin the background as team members perform work. Theseevents are then presented to users as hypermedia-enabledtrails of events. The trails of events can be organized alongmany intersecting dimensions. For instance, the trail “allevents opening document A” can lead to the trail “what didJane do after she opened document A”. Each event in a trailis “hypermedia-enabled,” which means that there is enoughinformation associated with an event to allow an open hyper-media system to link the event with its associated applicationand/or artifacts. In this way, the shared workspace is definedby the event trails themselves; any application or artifact thatcan be reached from an event is part of the workspace. Thisallows workspaces to fluidly expand or contract based onthe activities of the software team. And, because trails arepersistent, it is possible to “travel back in time” and see thestructure of a workspace at any point.

One large class of project awareness research involves theuse of video to enable project awareness among the mem-bers of an organization. Example work in this area includesPortholes [14] and Montage [32]. iScent represents an or-thogonal approach to project awareness from these video-based systems; however an interesting intersection betweenthe two domains would be to integrate a video-based aware-ness system into an event-based framework like iScent such

that the video interactions of team members became a part ofthe project awareness captured by iScent.

A second class of project awareness research involves devel-oping frameworks for adding awareness mechanisms to col-laborative applications. Representative samples of this workinclude [17, 19, 24, 31]. As discussed below in more detail,our approach to supporting awareness does not involve theintegration of awareness mechanisms into tools directly. In-stead, the iScent framework makes use of event notificationsystems to transparently capture and distribute event infor-mation generated by applications. The iScent infrastructurecan then assemble these events into trails. As such, integrat-ing applications into an event notification system remains anissue. However, this task involves significantly less effortthan integrating awareness mechanisms directly into an ap-plication, since it avoids issues of modifying an application’suser-interface. It can even be achieved when an application’ssource code is not available by the use of wrappers, as longas the application provides some form of external interface.

A third class of project awareness research involves cre-ating high-level frameworks for supporting awareness or,more generally, collaborative functionality in applications.The goal here is to specify a conceptual framework that ap-plications can adhere to, backed by an implementation ofthe framework that will automatically enable collaborationthrough the application’s use of the framework. Examplework in this area includes [6, 20, 26, 30]. Again, iScentplaces no restrictions on its participating applications otherthan the requirement that they be integrated with an eventnotification system. However, conceptually, iScent is ableto address issues present in other conceptual frameworks.For instance, Hayashi et al., present a framework designed tosupport the sharing of knowledge between people, projects,and places [20]. They represent an activity as a chronolog-ical thread of snapshots of the information in a workspace.iScent event trails are not restricted to capturing activitiesalong a temporal dimension only. Events are stored persis-tently and can be assembled into trails along a variety of di-mensions. For instance, a user can request to see Jane’s trailof events for the work she did last Wednesday, however theycan also request to see those same events organized by theprojects she was working on, or by the applications that sheused that day, or any other axis that can be represented by thevalue of an event’s fields. In addition, the concepts of people,projects, and places can all be inferred from standard eventfields such as the user who generated an event (e.g. “John”),their work location at the time (e.g. “John’s laptop”), and theproject they were working on (e.g. “iScent documentation”).

Document ManagementLaMarca et al., take an innovative approach for support-ing document-centered collaboration in thePlaceless Doc-umentsproject [23]. Here, coordination and collaborativefunctionality is associated with documents rather than appli-cations. This is enabled by associatingactive codewith all

3

operations that can occur on documents, including reading,writing, deleting, etc. When an operation occurs, the ac-tive code can maintain coordination and collaborative con-straints by posting event notifications, performing additionaloperations, and even denying the original operation in thefirst place for example. LaMarca et al., use this frameworkto describe an application,Shamus, that supports softwareengineers with implementation activities such as checkingcode in and out of a configuration management system andautomatically compiling code and documentation whenevercode is changed. They argue that the placeless documentsarchitecture enables a finer granularity of awareness to beachieved than is normal in software development. For in-stance, Shamus is able to inform developers working on thesame piece of code where exactly each developer is work-ing within a file. Previously, developers could only know, atbest, that more than one person is working on the same fileat once.

In a similar fashion, the iScent framework is an attempt toincrease the granularity of awareness that can be achievedvia the use of hypermedia-enabled trails of events. Aswill be discussed in detail in Section 3, an event can be atany level of granularity ranging from key press events todocument events to process level events, depending on theamount of detail provided by its source application. WhileiScent has made a tradeoff because it depends on applica-tion integration—a restriction that is not encountered in thePlaceless Documents approach—it then has the ability tocapture a wide range of events, including those that are notassociated with documents. In addition, by making use ofopen hypermedia, we allow users to quickly traverse from(a visualization of) an event to its related application and/ordocuments. This latter feature allows users to access doc-uments in a uniform way as part of a collaborative processenabled and managed by the event trails themselves. Thus,the iScent framework can be seen as another point in the de-sign space first mapped by the Placeless Documents project,because it also does not attempt to place coordination andcollaboration functionality into applications. It instead asso-ciates this functionality with event trails as a new abstractionfor project awareness.

3 ApproachWe now present the iScent framework. Since the transportlayer of iScent is an event notification system, we begin ourpresentation with a brief review of the capabilities and char-acteristics of these system. We then present the architectureof the iScent framework and describe in detail its constituentparts. The utility of the iScent framework is illustrated viaa scenario which includes a step by step explanation of howiScent enables intersubjectivity. We then conclude this sec-tion by briefly addressing privacy concerns raised by theiScent approach.

Event Notification SystemsiScent uses an event notification system as a transport layer.

These systems are, in general, based on the concepts ofevents, producers/consumers of events, and event subscrip-tions/notifications. Typically, an event is a set of key/valuepairs. Producers publish events to an event server whichroutes these events to consumers based on their subscrip-tions. One benefit of this arrangement is that producers arecompletely unaware of the location of interested consumers(and are thus not dependent on these consumers in any way).Likewise consumers are unaware (and not dependent on)producers. This arrangement can lead to significant benefits.For instance, the C2 architectural style makes use of thesecharacteristics to provide substrate independence in softwarearchitectures [33]. Other advantages include:

• Producers and consumers focus only on events mean-ingful to them. They have no need to understand theentire event space being managed by the event system.They are, thus, straightforward to create and configure.

• Event systems make efficient use of a network. Whenan event is produced, only those consumers who sub-scribed to the event are notified.

• If several event servers are used (which is, for instance,possible with the Siena system [11]), the routing ofevents can be further optimized (e.g. an event is onlysent to an event server if it has clients that are interestedin that event). This facilitates the use of an event notifi-cation system across a wide-area network.

• The publish/subscribe model enables dynamic servicediscovery. For instance, a consumer can publish anevent requesting a specific service. If there is a pro-ducer that provides the service, it will notify the con-sumer, and the consumer can subscribe to it.

By making use of an event notification system, the iScentframework provides these same advantages and characteris-tics to its users.

The Architecture of the iScent FrameworkThe architecture of the iScent framework is presented in fig-ure 1. The components of the framework are:

iScent Client Applications iScent applications produceiScent events.

Sink A sink consumes all iScent events. It is responsiblefor making events persistent and provides an interfacethat allows other components to issue queries over thestored events.

Trail Viewer A trail viewer specializes in the visualizationand structuring of collections (“trails”) of iScent events.A trail viewer provides hypermedia capabilities over itstrails such that software engineers can traverse from an

4

Watchdog

Kennel

EventsSocket

iScent AwareApplication

Sink

Sink

iScent AwareApplication

Trail Viewer

Sink

Figure 1: The Architecture of the iScent Framework

event to the event’s associated information. These hy-permedia capabilities are provided via integration withan open hypermedia system [27].

Watchdog A watchdog is a persistent trigger than can gen-erate iScent events when a specified condition is met.Watchdogs are used to support awareness since theyplay a key role in achieving intersubjectivity (as de-scribed below).

Kennel A kennel is a collection of watchdogs. A kennelwill often be associated with a sink, however they canalso exist independently.

Communication between iScent components is primarilyhandled by iScent’s integrated event notification system.Communication via events is symbolized in figure 1 by solidarrows, i.e. no point to point network connections exist be-tween components connected by solid arrows. Dashed ar-rows signify point-to-point socket connections, which areused when large packets of information must be transferredbetween components. Event systems typically limit thesize of events to ensure adequate performance. Therefore,queries with large result sets must be transferred outside theevent system.

A typical iScent configuration consists of one or more iScentapplications deployed on a set of user machines, and a set ofsinks and kennels distributed across a set of server machines.Note, however, that a user can install a sink on his or herlocal machine. The main benefit of this configuration is theability to use iScent “unplugged,” i.e. without contact withother sinks or event servers. Once a machine is plugged intothe network, the local sink can offer its stored events to othersinks for replication and distribution to other team members.

The configuration of iScent components involves linking

each component to a local event server and, in the case ofsinks, specifying the types of iScent events to store. An eventserver will likely be coupled with other event servers whichare in turn connected to other sinks and iScent applications.It is thus possible to create highly-distributed large-scale net-works of iScent components.

An iScent ScenarioThe utility of the iScent framework is now demonstrated viaa scenario. While the iScent framework is general enough tobe applied in many work settings, our first target setting isthe task of software development.

Jane, a system developer, has just returned from va-cation. She begins her first day of work by starting a trailviewer. While she has been away, many events match-ing her criteria have been generated. The trail viewerretrieves these events, and presents them in juxtaposedtrails sorted according to topic and time of occurrence.There is too much information to digest, so Jane engagesa set of filters that she has previously defined, whichsimplifies the view considerably by folding matchingpatterns of events into meta events. Jane sees in the CVStrail that several new files have been checked into a CVSrepository. Checking her e-mail, she notices a messagefrom John telling her about one of the new files and ask-ing her to take a look at its associated design rationale inthe documentation. She clicks on the event representingthe check-in of the file to see further details, and no-tices a link to the file’s documentation. She follows thelink which loads the documentation into a Web browser.While reading, she notices that John has put a watchdogon the documentation, and five minutes later, John callsto hear her opinion of the design rationale.

This scenario illustrates key aspects of iScent’s functional-ity. Since iScent events are persistent, it is easy for Jane tocome up to speed with what has happened while she was onvacation. Jane need not worry about specifying where eventsshould be retrieved; this is handled automatically by iScent(while she was away, the entire structure of sinks could havebeen reorganized without her noticing or caring). Ratherthan presenting a single, large list of events, the presenta-tion of events is structured, and can be further manipulated.To provide further structuring mechanisms, it is possible tocreate links to and from the events stored in the sinks. Be-cause Jane’s Web browser is iScent aware, her viewing of thedocumentation creates an iScent event, which can trigger awatchdog. This allows John to wait until Jane has actuallydiscovered and viewed his changes, before contacting her.

Enabling IntersubjectivityWe now parse the scenario into single iScent actions to il-lustrate how the iScent framework enables intersubjectivityamong software developers.

When John checked in a new file, an iScent event represent-ing his action was created and stored in a project-related

5

sink. The creation of the code’s documentation also gen-erated iScent events, and according to good practice, Johncreated a link from the check-in event to the documentationusing his trail viewer. Because he knew that Jane had ex-pertise on the topic of the new file, he sought her opinion ofthe design through e-mail. Wanting to be told when she hadread the documentation, John used his trail viewer to createa watchdog, set to trigger when Jane retrieved the documen-tation with her Web browser. This watchdog was stored at aproject-related kennel, and the kennel issued a subscriptionmatching the criteria of the watchdog. By posting the watch-dog, John automatically created a subscription matching theevent that the watchdog would send if triggered. To use theiScent vocabulary, John wanted to be alerted if his and Jane’strails of actions intersected at the point of the documentation.Having done this, John was free to work on other things,knowing that he would be notified when to contact Jane.

When Jane started her trail viewer, the trail viewer issued aseries of query events on the topics she had configured it tofollow (essentially the subscriptions she had created earlier).In this case, Jane was interested in iScent events of the types“CVS” and “Documentation.” These query events were con-sumed by a project-related sink which then confirmed that itcould answer her query. The confirmation events held infor-mation (a network address and a port number) for the trailviewer to retrieve the trails generated by the sink based onthe queries. The trail viewer proceeded to contact the sinkand retrieve the trails.

Once retrieved, the trail viewer displayed the trails, and Janecould begin to manipulate them to gain an overview of thechanges made while she was on vacation. In this situation,the trails were arranged by type (“CVS” and “Documenta-tion”) along a time axis. When Jane read the e-mail fromJohn, she found the matching event, and followed a link fromit to the documentation. Following the link caused the doc-umentation to be loaded into Jane’s Web browser. Since theWeb browser was iScent-aware, it generated an iScent eventthat recorded the action of loading the documentation. At theproject kennel, John’s watchdog was triggered by this event.The watchdog, in turn, generated an event containing its IDand the information about the person, who had triggered it.Because a trail viewer by default subscribes to events thatcontains a “triggered by” field matching its user, the eventwas received by Jane’s trail viewer, alerting her to the exis-tence of a watchdog and to the identity of its creator. Simul-taneously, the same event was received by John, and he nowknew that he could contact Jane, in the near future, to discussthe design rationale.

By reading the email, Jane knew that John wanted her to readthe documentation. When she actually read the documenta-tion, John was alerted, so that “he now knew that she knew”.Conversely, Jane knew by being alerted by a watchdog, that“John knew that she now knew” about the design rationale.Thus, Jane was aware of the context for John’s call because

intersubjectivity had been achieved.

TrailsTrails are a cornerstone of the iScent framework. Throughthe use of iScent applications, a user generates a trail ofiScent events (a “scent trail”). These are stored by sinks, andcan later be retrieved through queries. A trail is defined as aset of iScent events. Thus, the actions of a user can be cap-tured by a trail of iScent events matching the user over time.Another trail could be the events matching a certain tool overtime, or following the history of a document. These trails in-tersect, for instance, when a user makes use of a certain tool,or modifies a certain document. Since trails are modeled assets of events, trails support the normal set operations: join,intersection, and difference. These operations match on se-lected common fields among the constituent events, and canbe performed by a trail viewer or by expressing a query toreflect the desired operations.

The user manipulates trails in a trail viewer. Trails can beplotted along axes defined by the user. Returning to the sce-nario, Jane plotted two trails consisting of CVS events anddocumentation events respectively along a time axis in orderto see the correlation between code produced and documen-tation written. When plotting a trail, one field common toall the constituent events is used to order the events alongan axis. As a time stamp is common among all iScent events(see Table 1 for the default iScent fields), a common orderingis time based, though other orderings can be used.

As a set of events, a trail can be arbitrarily large. One of thedesign goals of iScent is to produce highly detailed events.However in some circumstances too much detail can be a lia-bility, since a user can easily lose his or her sense of the “bigpicture” behind the events. To address this, without aban-doning high fidelity events, trails can be filtered. A filter isessentially pattern matching on events, such that matchingevents are replaced in a trail viewer with a meta event (ora “folded” event). One could for instance define a patternto replace a sequence of CVS events relating to a single filewith a single event representing all actions pertaining to thefile. The user can of course unfold a folded event to inspectthe constituent events. Once defined, filters are stored in atrail viewer and can be applied as the user desires. Foldedevents are iScent events and can, as such, also be subjectedto filtering.

Trails of events can be transient, e.g. existing only on a user’sscreen, or they can be stored — either as a specification ofthe queries and filters that produce the trail, or as a sequenceof event ids (all iScent events have unique ids, as described inSection 4). Finally, it is possible to export (or import) trailsas XML files for external use. The export format is identicalto the format used by sinks to send trails to trail viewers.

Privacy ConcernsNot all actions taken by an iScent user is necessarily relevantfor other users. Sometimes it makes sense to track all ac-

6

tions, such as a user’s CVS operations, and sometimes it doesnot, such as what Web pages a user visited. User can andshould therefore be able to configure filters that designate thetypes of events they want to publish. In the context of a Webbrowser, one could, for instance, publish all events regardingtechnical documentation. This not only addresses privacyconcerns, but also improves the overall signal-to-noise ratioin the trails stored by sinks.

4 ImplementationWe have constructed a prototype implementation of theiScent framework, including initial implementations of thefollowing components: sinks, watchdogs, and kennels.These components are sufficient to test the creation and stor-age of iScent events and to validate the iScent type systemand query facility. Our work on a trail viewer is prelimi-nary and has involved the design of its user interface and theconstruction of a tool that can query and retrieve event trailsfrom sinks. Our initial prototypes have been stress testedthrough the use of batch tools that generate tens of thousandsof events and then issue queries that validate the operation ofthe sinks, watchdogs, and kennels. These initial efforts rep-resent a proof-of-concept of the iScent framework; our futurework will involve fleshing out the trail viewer and integrat-ing client applications. Below, we discuss the various issuesthat our initial implementation has raised.

Requirements of the Event Transport LayerThe iScent architecture relies on an event notification systemto provide the transport layer for iScent events. The require-ments on the transport layer are:

• Events must consist of key/value pairs

• Values can be arbitrary strings

• Subscriptions to events must be supported

• Subscriptions to events should be specific key/valuepairs (e.g. “name equals John Smith” or “age greaterthan 24”)

These requirements are met by most event notification sys-tems. Therefore, the iScent framework is independent of anyparticular event system. The current version of iScent uti-lizes the Siena event notification system [11], which easilysatisfies the above requirements.

Scalability of iScentiScent’s scalability is dependent on the scalability of its as-sociated event notification system. Our implementation ofiScent therefore depends on the scalability of Siena, whichhas been characterized by Carzanigaet al. in [11]. One ofthe main benefits of Siena is that Siena servers can be cou-pled together in a network. Given a situation where manyiScent components and Siena servers are in use, Siena auto-matically provides optimal routing of events from producerto consumer to maximize performance and minimize latency.

Multiple SinksiScent can be configured with any number of sinks. This hasseveral advantages over a single store:

• Sinks can be local to a workgroup, and run on a localmachine. This provides improved performance as thesink only stores events produced by its workgroup.

• While maintaining local sinks, the addition of largersinks collecting all events generated by, e.g. a depart-ment, provides additional benefits. Data is automati-cally replicated between sinks for greater data security,and if one sink is down or slow due to high load, othersinks can provide access to the desired events.

• These configurations are achieved by installing more orless specialized subscriptions into sinks that determinethe set of events they store and share. A configurationis flexibly manipulated since a sink can be added orremovedat run-timesimply by changing its subscrip-tions.

Querying for EventsSinks provide for the persistence of events and handle allqueries. Queries are sent to sinks via Siena. This allowsqueries to be handled in an efficient and scalable manner.

A query is an iScent event that specifies the type of de-sired events and (ranges of) values in these events. A sinksubscribes to the query events matching what it stores, andqueries are thus automatically routed (by the underlyingtransport layer) to the sinks that can provide answers. Whenan iScent component issues a query event, it also subscribesto confirmation events matching the query. If there are sinksthat are able to fulfill the query, they will issue confirmationevents which are then received by the querying party. Whilemost event notification systems can efficiently route events,they are in general not optimized for very large events (Sienafor instance has an upper limit of 64 K). Query results canbe arbitrarily large, and rather than returning the query resultitself in an event, the confirmation event contains contact in-formation for the answering sink. Upon retrieval of the con-firmation events, the querying party establishes direct socketconnections to the sinks and retrieves the events (it can alsochoose to select only one of the sinks for retrieval). Thislessens the load on the event transport layer considerably. Tolessen the network load further, the queries are compressedand decompressed automatically. The retrieval of query re-sults is the only time where an iScent component makes adirect point to point connection to a sink — at all other timesit generates iScent events that are automatically propagatedby the event transport layer.

The query and confirmation events are themselves iScentevents, and are, as such, stored by the sinks. Apart fromthe awareness possibilities in these events, it also allows asystem administrator to monitor how the sinks are used, and

7

exploit this information to move sink data and subscriptionsto improve network performance.

A sink uses an SQL database for storage, and automaticallygenerates a new table, when an iScent event of a new type(see below for information on types) is received. This fa-cilitates rapid query resolution. The current query interfacehas been designed to make the most of the SQL database.Queries can be combined using logical operators, and is ableto create very precise queries.

iScent EventsAn iScent event is the atom of the iScent framework. Anevent is composed of key/value pairs (or “fields”). All eventshave a default set of key/value pairs, shown in Table 1.

Key Example ValueUser John Smith<john@comp.com>

Producer org.iscent.app.iScentAppHost 138.128.34.10

Timestamp 956809312389id 9KjxG3iBMCvHALTrOe=6xW

Types type1 type4

Table 1: The default iScent key/value pairs

Thus, an event can provide information about its user, howit was created, where it was created, and when. The id is a128 bit integer (here presented inbase64 form), created asa MD5 hash signature of the rest of the event. The use ofMD5 ensures both a unique id and data integrity (since theMD5 signature is recomputed at arrival and compared withthe existing one). In addition, most events use the Types fieldto declare their type(s), i.e. specifying which other fields theevent contains.

The iScent Type SystemiScent events are typed, and are checked upon creation andarrival. The type system is component based and extensible.Types are defined through iScent type declaration events andare stored by sinks. A type declaration consists of a (globallyunique) type name, one or more fields with key names uniquewithin the type, and a definition of the types of these fields.

All values in an event (with the exception of the default val-ues listed in Table 1) are encoded in XML. The field defini-tion is a DTD specifying the format of legal values for thatfield. The DTDs are stored by sinks and are used by them tovalidate the events they consume.

The basis of the iScent type system is the declaration of sin-gle types, but iScent events can have more than one type.When an event declares several types, it guarantees that itcontains valid values for all the fields defined in all of thetypes. The names of keys are a combination of their originaliScent type name and their own field name, which eliminatesname collisions between types. Combining types can be very

useful; a class of iScent applications can, for instance, sharea common “header” type, plus their own specialized types.As the number of iScent applications grows, so do the typesdefined. These types then provide building blocks that canbe used by other iScent developers when constructing newiScent applications.

Watchdogs and KennelsA crucial part of supporting intersubjectivity is the watch-dog. The watchdog is used to detect the occurrence of certainiScent events (for instance, opening a document), and alertsthe creator of the watchdog when the condition has been met.

Currently a watchdog consists of two parts: criteria that mustbe met, and an event to send when triggered. Watchdogscan be set to trigger only once, and then disappear, or tocontinue to trigger when conditions are met. If a watchdogreported only to its creator, it would increase the creator’sproject awareness but it would not provide intersubjectivity,since the people triggering the watchdog would be unawareof its existence. To enable intersubjectivity the watchdogalso reports to the person who has triggered it. Trail view-ers automatically subscribe to watchdogs events triggered bytheir user, and will alert its user when such an event is re-ceived. Likewise, by creating a watchdog, a user automati-cally subscribes to responses from it. These responses willbe received and displayed by a user’s trail viewer.

To ensure the persistence and vigilance of watchdogs, theyreside in kennels. A kennel is a server that registers the con-ditions of its watchdogs and creates matching subscriptions.When an iScent event is received, it is checked against theconditions and, if a match is found, triggers the creation ofan event specified by the appropriate watchdog.

The triggering mechanism is currently a simple if-thenmechanism. Future work will involve the creation of moresophisticated watchdogs. The most likely approach for im-provement will be the creation of watchdog Java classes, thatcan be uploaded into a kennel. These Java watchdogs canmaintain state between triggering events, so they can, for in-stance, be used to detect patterns of events and generate anevent only after a pattern has been detected. Another topicfor future work is the migration of watchdogs. Currentlywatchdogs are sent to the nearest kennel (or rather the ken-nel that first accepts the watchdog event). To optimize per-formance and minimize the network load, it would be betterif watchdogs could migrate to a kennel close to the producersof events that match the watchdog’s criteria.

5 Future WorkThere are many avenues for future work in further devel-oping the iScent framework and its associated implementa-tion. Chief among them is the need for evaluating the iScentframework’s ability to address the project awareness needs ofmodern software development projects. We plan to performthis type of evaluation with two very different methods. Thefirst method is to conduct laboratory-based usability studies

8

on the user interface of the trail viewer and the kennel. Weneed to determine if the conceptual model presented by theiScent framework provides utility to software engineers andif the user interface is effective in delivering the functionalityof the iScent framework into the hands of its end users. Thesecond method is to conduct field studies of the iScent frame-work in use at an industrial site. The key problem here isidentifying industrial partners and obtaining a commitmentto participate in industrial collaboration. We have successfultrack records in university/industry interchange [2] and arebeginning the process of obtaining industrial collaboratorsto support this line of research. The goal of the field studieswill be to increase our understanding of the work practicescurrently used in industry and how the iScent framework ei-ther hinders or enhances these procedures.

Secondary plans for future work on the iScent frameworkinvolve exploring techniques to increase the fidelity of eventtrails from integrated iScent applications. Application eventsof high fidelity leads to better “conversations” between engi-neers and increases the intersubjectivity that can be achievedby the iScent framework. However, it must not be difficultto integrate applications into the iScent framework and thustechniques are needed to reduce the effort required to inte-grate an application into the framework. Again, such effortswill enhance the project awareness that can be achieved bythe iScent framework by giving it more sources of events andthus increasing the percentage of project work it captures.In addition, we will be exploring new trail visualizations,new query mechanisms over trails, more flexible support forwatchdog behaviors, and better tool support for managingiScent networks.

6 ConclusionsWe have presented a framework designed to support projectawareness in large-scale software development contexts thattakes a unique approach to the problem. Leveraging alreadyexisting open hypermedia and event messaging infrastruc-tures, the iScent framework combines the use of hypermediatrails with event publish/subscribe techniques to enable in-tersubjectivity between software engineers and thus promotewide-spread project awareness throughout a software devel-opment team. We have described the conceptual layout ofthe framework and provided insight into an experimental im-plementation of it. The implementation employed aggressivereuse of fielded infrastructure, database technology, and dis-tributed system techniques in order to scale the implemen-tation to a level where it becomes feasible to conduct fieldstudies of the new technology in industrial settings. Havingmet these initial scalability concerns, our attention now turnsto evaluating the utility of our formalisms and the effective-ness of our prototypes.

REFERENCES

[1] V. Ambriola, R. Conradi, and A. Fuggetta. Assessingprocess-centered software engineering environments.

ACM Transactions on Software Engineering, 6(3):283–328, 1997.

[2] K. M. Anderson. Supporting industrial hyperwebs:Lessons in scalability. InProc. of the 21st InternationalConference on Software Engineering, pages 573–582,Los Angeles, CA, USA, May 1999.

[3] K. M. Anderson, R. N. Taylor, and E. J. WhiteheadJr. Chimera: Hypertext for heterogeneous software en-vironments. InProc. of the European Conference onHypermedia Technology (ECHT 1994), pages 97–107,Edinburgh, Scotland, 1994.

[4] S. Bandinelli, E. Di Nitto, and A. Fuggetta. Support-ing cooperation in the SPADE-1 environment.IEEETransactions on Software Engineering, 22(12), 1996.

[5] P. Barthelmess and K. M. Anderson. A view of soft-ware development environments based on activity the-ory. Computer Supported Cooperative Work, To appearin the Special Issue on Activity Theory, 2000.

[6] M. Beaudouin-Lafon and A. Karsenty. Collaborationawareness in support of collaboration transparency:Requirements for the next generation of shared windowsystems. InProc. of the ACM Symposium on User In-terface Software and Technology, pages 171–180, Nov.1992.

[7] N. O. Bouvin. Unifying strategies for Web augmenta-tion. In Proc. of the 10th ACM Hypertext Conference,pages 91–100, Darmstadt, Germany, Feb. 1999.

[8] N. O. Bouvin. Designing user interfaces for collabora-tive Web-based open hypermedia. InProc. of the 11th

ACM Hypertext Conference, San Antonio, USA, May2000.

[9] F. P. Brooks Jr.The Mythical Man-Month. Addison-Wesley, 20th anniversary edition, 1995.

[10] M. R. Cagan. The HP SoftBench environment: Anarchitecture for a new generation of software tools.Hewlett-Packard Journal, 41(3):36–47, June 1990.

[11] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf.Achieving scalability and expressiveness in an Internet-scale event notification service. InProc. of the 19th

ACM Symposium on Principles of Distributed Comput-ing, July 2000.

[12] P. Dewan and R. Choudhary. Coupling the user-interfaces of a multiuser program.ACM Transactionson Computer-Human Interaction, 2(1):1–39, 1995.

[13] P. Dourish and V. Bellotti. Awareness and coordi-nation in shared workspaces. InProc. of the ACM1992 Conference on Computer-Supported CooperativeWork, pages 107–114, Toronto, Canada, Oct. 1992.

9

[14] P. Dourish and S. Bly. Portholes: Supporting aware-ness in a distributed work group. InProc. of the ACMConference on Human Factors in Computing Systems,pages 541–547, May 1992.

[15] G. Fitzpatrick, T. Mansfield, S. Kaplan, D. Arnold,T. Phelps, and B. Segall. Augmenting the workadayworld with Elvin. In Proc. of the 6th European Confer-ence on Computer Supported Cooperative Work, pages431–450, Copenhagen, Denmark, 1999.

[16] L. Fuchs. AREA: A cross-application notification ser-vice for groupware. InProc. of the6th EuropeanConference on Computer Supported Cooperative Work,pages 61–80, Sept. 1999.

[17] L. Fuchs, U. Pankoke-Babatz, and W. Prinz. Sup-porting cooperative awareness with local event mech-anisms: The GroupDesk system. InProc. of the4th

European Conference on Computer Supported Coop-erative Work, pages 247–262, 1995.

[18] K. Grønbæk, J. Hem, O. L. Madsen, and L. Sloth. De-signing Dexter-based cooperative hypermedia systems.In Proc. of the5th ACM conference on Hypertext, Nov.1993.

[19] C. Gutwin and S. Greenberg. Design for individu-als, design for groups: Tradeoffs between power andworkspace awareness. InProc. of the ACM Conferenceon Computer Supported Cooperative Work, pages 207–216, Nov. 1998.

[20] K. Hayashi, T. Hazama, T. Nomura, T. Yamada, andS. Gudmundson. Activity awareness: Framework forsharing knowledge of people, projects, and places. InProc. of the6th European Conference on ComputerSupported Cooperative Work, pages 99–118, Sept.1999.

[21] G. Junkerman, B. Peuschel, W. Schafer, and S. Wolf.MERLIN: Supporting cooperation in software devel-opment through a knowledge-based environment. InA. Finkelstein, J. Kramer, and B. Nuseibeh, editors,Software Process Modelling and Technology, pages103–130. Research Studies Press Ldt, 1994.

[22] G. E. Kaiser, N. S. Barghouti, and M. H. Sokolsky. Pre-liminary experience with process modeling in the Mar-vel software development environment. InProc. of the23rd Annual Hawaii International Conference on Sys-tem Sciences, volume Vol. II — Software Track, pages131–140, 1990.

[23] A. LaMarca, K. Edwards, P. Dourish, J. Lamping,I. Smith, and J. Thornton. Taking the work out ofworkflow: Mechanisms for document-centered collab-oration. InProc. of the6th European Conference onComputer Supported Cooperative Work, pages 1–20,Sept. 1999.

[24] J. C. Lauwers and K. A. Lantz. Collaboration aware-ness in support of collaboration transparency: Require-ments for the next generation of shared window sys-tems. InProc. of the ACM Conference on Human Fac-tors in Computing Systems, pages 303–312, Apr. 1990.

[25] A. Leontjev. Activity, Consciousness, and Personality.Prentice Hall, 1978.

[26] D. Li and R. R. Muntz. COCA: Collaborative objectscoordination architecture. InProc. of the ACM Confer-ence on Computer Supported Cooperative Work, pages179–188, Nov. 1998.

[27] K. Østerbye and U. K. Wiil. The Flag taxonomy ofopen hypermedia systems. InProc. of the 7th ACM Hy-pertext Conference, pages 129–139, Washington DC,USA, 1996.

[28] W. Prinz. NESSIE: An awareness environment for co-operative settings. InProc. of the6th European Confer-ence on Computer Supported Cooperative Work, pages391–410, Sept. 1999.

[29] S. P. Reiss. Connecting tools using message passingin the field environment.IEEE Software, 7(4):57–66,1990.

[30] M. Roseman and S. Greenberg. Building real-time groupware with GroupKit, a groupware toolkit.ACM Transactions on Computer-Human Interaction,3(1):66–106, 1996.

[31] M. Sohlenkamp. Integrating communication, cooper-ation and awareness: The DIVA virtual office envi-ronment. InProc. of the ACM Conference on Com-puter Supported Cooperative Work, pages 331–344,Oct. 1994.

[32] J. C. Tang, E. A. Isaacs, and M. Rua. Supporting dis-tributed groups with a montage of lightweight interac-tions. In Proc. of the ACM Conference on ComputerSupported Cooperative Work, pages 23–34, Oct. 1994.

[33] R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J.Whitehead Jr., J. E. Robbins, K. A. Nies, P. Oreizy, andD. L. Dubrow. A component- and message-based ar-chitectural style for GUI software.IEEE Transactionson Software Engineering, 22(6):390–406, June 1996.

[34] U. K. Wiil and J. J. Leggett. Concurrency controlin collaborative hypertext systems. InProc. of the5th ACM Conference on Hypertext, pages 14–24, Nov.1993.

[35] U. K. Wiil and J. J. Leggett. HyperDisco: Collabora-tive authoring and Internet distribution. InProc. of the8th ACM Conference on Hypertext, pages 13–23, Apr.1997.

10

Collaborative Web-based Open Hypermedia and Mutual AwarenessNiels Olof Bouvin

Department of Computer Science, Aarhus UniversityAabogade 34A, DK8200 Aarhus N, Denmark

E-mail: n.o.bouvin@daimi.aau.dk

AbstractThis paper addresses some issues in collaborative hyperme-dia and how hypermedia can be augmented with recent ad-vances in awareness technologies, especially event notifica-tion systems. The work done in the Open Hypermedia Sys-tems Working Group with special focus on collaboration ispresented, along with the Arakne Environment, a hyperme-dia system based on the Open Hypermedia Protocol. Thesesystems are discussed in the context of the collaboration is-sues raised.

KeywordsCollaborative hypermedia, open hypermedia, event notifica-tion, peripheral awareness, World Wide Web.

1 IntroductionA basic form of collaboration in large document spaces iscollaborative structuring and annotation. By structuring adocument space, we begin to make sense out of it. Fromits beginning with Bush’s Memex [10], the hypermedia re-search community has worked with the structuring of docu-ment spaces. The Memex was intended to make it possiblefor knowledge workers to handle the in 1945 rapidly grow-ing scientific literature efficiently by supporting associativethinking. Users of the system would create trails connectingrelated documents, and these trails could later be shared withother Memex users.

Today, we face the largest document space ever created: theWorld Wide Web [6]. The Web owes much of its successto its simple architecture, yet this architecture has some lim-itations, especially with regards to structuring and collabo-ration. Users cannot create links from Web pages they donot own, nor can they create annotations or other hyperme-dia structures. Whereas the users of the (admittedly hypo-thetical) Memex could share trails, the modern Web user islimited to the exchange of URLs. To address this, open hy-permedia systems have been extended to provide users withsophisticated hypermedia functionality on the Web. Thus,the basic collaborative act of structuring can be supported.

Another aspect of collaboration is keeping track of co-workers’ actions inasmuch as they relate to one’s own ac-tivities. Collaboration takes place within a shared under-standing of the task at hand, and this shared understanding

or awareness may be supported by computers. Shared aware-ness tools range from video systems such as Portholes [15]to messaging systems such as Elvin [18].

On one side, we have hypermedia tools suited for structuringlarge document spaces, and on the other we have awarenesstools suited for helping people collaborate. In the middle, wehave the Web.

Based on this context of collaborative hypermedia andshared awareness tools, this paper presents a hypermediasystem to augment the Web, both structural and collabora-tive.

The paper is structured as follows: Section 2 introduces themain inspirations and foundations for this paper. Section 3discusses collaboration in hypermedia and how this collabo-ration may be achieved. Section 4 introduces the Open Hy-permedia Systems Working Group (OHSWG), and describesthe work done by the group with special focus on collab-oration. Section 5 introduces the Arakne Environment, ahypermedia system based on OHSWG technologies. Sec-tion 6 discusses collaboration in the Arakne Environment inthe context of the issues raised in Section 3. Section 7 de-scribes directions for future work, and the paper concludesin Section 8.

2 Related WorkCSCW and hypermedia share common roots. Some of theearliest papers on both hypermedia and collaboration sup-port were Bush’s Memex [10, 32] and Engelbart’s Augment[16, 17]. These tools sought to improve work by helpingknowledge workers to better structure their data and thusbetter understand their problem area. Memex would al-low readers to share trails tying documents together, andNLS/Augment was a distributed, collaborative hypermediaand authoring system, even featuring video conferencing.

Being able to annotate and structure information can be seenas a collaborative activity. While personal annotations cer-tainly are beneficial to the original annotater, they are alsovaluable to others, even when these annotations were notoriginally written with the express purpose of publication,as described by Marshall in [33]. By hypermedia structur-ing, we impose order, we assert relationships where nonewere before, we admit a text into a larger context. These are

1

basic characteristics of hypermedia, and characteristics thatcan only be fully realised in a system where users are free tolink, annotate, and structure as they see fit.

The Web is no such hypermedia system. Barring self-publishing, the Web is a read-only medium. Users cannotlink from pages, they do not own, and there are no provisionsfor annotations. The Web is not unique in this aspect. Thefield of open hypermedia has since 1989 [35, 37] worked onproviding users with advanced hypermedia functionality byintegrating third-party applications. By hypermedia enablingthe tools commonly used, the users gain the advantages ofhypermedia structuring without having to abandon their toolsof choice. Notable open hypermedia systems include Micro-cosm [29], HyperDisco [43], DHM [24], Chimera [3], andHOSS [36]. These system extend existing applications sothat users can create links and other hypermedia structuresbetween e.g. word-processing documents and spreadsheets.Given this extension of existing systems, it should come asno surprise, that the open hypermedia community has alsodeveloped systems to extend the hypermedia functionality ofthe Web. Systems, such as DLS [12, 11], DHM/WWW [21],Webvise [23], and the Arakne Environment [7], all provideusers with the ability to create hypermedia structures on topof arbitrary Web pages. This is accomplished without modi-fying the original Web pages, and does thus not rely on hav-ing write access.

As mentioned in the beginning of this section, some of theearliest hypermedia systems were collaborative in nature.Later systems, such as KMS [1], Intermedia [34], DHM [22],HyperDisco [44], and SEPIA [27, 28, 40] have provided theirusers with collaboration support for hypermedia authoring.

As described by Heath and Luff [30] in their analysis ofwork done by traffic controllers in the London Underground,maintaining shared awareness between co-workers can becrucial. Many systems has endeavoured to support this. TheGroupDesk system [20], the NESSIE system [38], the Elvinsystem [18], the AREA system [19], and the BABBLE sys-tem [9] to mention a few. These systems try to support sharedawareness through means such as messaging, chat, and eventnotification. On the Internet, commercial “buddy list” pro-grams, such as ICQ or AIM, provide their users with similarfunctionality.

The Web is increasingly becoming the infrastructure of com-puting, and as such it becomes natural to collaborate over theWeb. An example of a system supporting this is BSCW [5].To enable collaborative authoring on the Web, the HTTP pro-tocol has been extended by the WebDAV (Web DistributedAuthoring and Versioning) working group [41]. WebDAVcompliant Web servers provide users with document lock-ing and versioning. With advances such as these, the Web isslowly becoming suited for collaboration.

3 Collaboration in HypermediaWiil and Leggett [42] discuss the requirements of a collabo-

rative hypermedia system. Their six requirements are:

1. Event notification

2. Fine-grained notification

3. User-controlled locking

4. Shared locking

5. Fine-grained locking

6. Persistent collaboration information

This section discusses these requirements as well as othertechniques that might advance collaboration in hypermediasystems.

Event notificationShared awareness is a crucial part of collaborative working.Indeed, shared awareness and mutual understanding formsthe foundation without which communication and thus work-ing is rendered highly problematic. They form the basis ofarticulation work [4], i.e. the process of co-ordinating work.One technique to support shared or peripheral awareness isevent notification services. Users generate, either implicitly(e.g. by using an application integrated with the notificationsystem that generate events automatically) or explicitly (e.g.by messaging), events through the use of computer artifacts.Other users can subscribe to these events and are thus keptaware.

Event notification is only as valuable as the information con-tained within the notification events. Furthermore, the valueof an event notification system does not necessarily increasewith the amount of information, i.e. received notifications.Many of the actions taken by co-workers are not directly rel-evant to the task at hand, but some may be crucial. Likewise,there may be only a few notifications that are really impor-tant to a user, and if many events are generated and received,the important ones are likely to be overlooked, disappearingin the “noise” of the other events. This problem is usuallyaddressed through a subscription model, where users beforehand signify which kind of notifications they are interestedin. Depending on the sophistication of the system, a sub-scription can be simply to an entire class of events, or mayspecify conditions only a few events will match. Subscrip-tions cannot solve the whole problem, as a user may createa too restrictive subscription and loosing important events,or create a too inclusive subscription resulting in the sig-nal/noise problem described above. Many of these concernscan be addressed by employing “human filtering” throughmessaging functionality, so co-workers can alert each otherdirectly. In practice, this is often accomplished through ordi-nary communication or email.

An interface for notifications championed by the Elvin sys-tem [18] is the ticker tape. The ticker tape is a non-intrusive

interface, where notifications scroll by as they are received.The ticker tape is updated over time, as new notifications re-place old ones. A user can focus on the ticker tape, when theuser wishes without being interrupted in the continuing workand without having to open new windows or use a special in-terface. A weakness of the Elvin model (also found in othernotification services) is that once a notification has scrolledby or has timed out, it is lost, as notifications generated arenot stored (they are not “mailbox” notifications in the termsof Wiil and Legget). It is thus most suited to support aware-ness as work progresses, and cannot be used to catch up withthe activities of others.

Collaborative authoring systems as well as collaborative hy-permedia systems often uses “live updates”, e.g. as oneworker makes updates, these updates are propagated to otherusers working on the same artifacts. This keeps the focusof the main tool used, rather than having the user consultwith other tools to see what others are doing. An example ofa system using this approach is SEPIA [27, 28, 40], wherechanges to documents can be broadcast, as they are made.

The live update approach works well with notification ser-vices, as users can see that changes have taken place, andsee in the notification interface who caused the change, orsee comments regarding the changes. A related technologyis the use of chat systems or discussion boards used in con-junction with the ongoing work (exemplified by the Babblesystem[9]). This allows users to engage in conversations andco-ordination over time and location, and, depending on thesystem, users can refer back to discussions past.

LockingOne of the basic co-ordination technologies found in mostcollaborative authoring systems is the possibility of lockingresources, so that only one person may modify it at a time.A prime example of a general document locking technol-ogy that becoming increasingly more widespread is the Web-DAV system, described by Whitehead and Goland [41]. Byrelying on (WebDAV complicant) Web servers for storage,users can issue time-based locks on Web resources, whichallows geographical dispersed users to work together on aset of documents without accidently overwriting each oth-ers’ changes. Locking requires that it is possible to identifythe resource to be locked. In the case of WebDAV the atomresource is a single document. This is fairly coarse-grainedcompared to other systems, where locking can take placeon e.g. one paragraph of text. The advantage of the Web-DAV system is that it does not require the system to knowthe semantics of resources stored within it and it can thus bemuch simpler and is not vulnerable to changes in the inter-nal format of the stored resources. Systems providing finer-grained locking will in general have to use a special applica-tion for editing which probably has contributed to the lack ofwide-spread use of fine-grained locking, as users are under-standably hesitant to abandoning e.g. their word processorof choice “just” to gain fine-grained locking.

In the context of hypermedia systems, locking is also con-cerned with locking of hypermedia structures such as linksand anchors. The need for locking of such resources arehowever less pressing than the need to be able lock entiredocuments. One of the classic collaborative hypermediasystems, KMS [1] used optimistic concurrency control offrames. There were no locking mechanisms for frames asit was unlikely that two persons would be editing the sameframe simultanously given the large number of frames. Thepoint can also argued from the point of long versus shortterm exclusive use of a resource. Documents are often large,so users can be expected to spend a relatively long time mak-ing modifications, and in that case it makes very good senseto lock document to avoid overwrites. However, when the re-source in question is small and it takes a short time to modifyit, the need for locking decreases, especially if updates to aresources are propagated to the relevant users, so no one isunaware of the changes made. This is the case of most hyper-media structuring mechanisms. Links and anchors are smallentities and the changes to them can be readily distributed.

Persistent collaboration informationCollaboration may but is unlikely to be over in one worksetting. Works continues the next day, as does the need forco-ordination and awareness between workers. Collabora-tive systems should and often do reflect this, so that usersneed not start from scratch each morning.

Persistent information about collaboration can include infor-mation such opened documents, tools used, subscriptions tonotifications, and so on. Thus, work can continue from thepoint where it was left earlier. Another benefit of persis-tent collaboration information is that it allows the user be en-gaged in several collaborations at time (or to alternate differ-ent collaborations), each collaboration with its own “space”of documents, locks, tools, events, etc.

Modes of CollaborationDepending on the work situation, it can make sense to dif-fer between modes of collaboration. One situation mightdictate that the worked upon resources should be updatedacross the participants’ computers as soon as the changes aremade. Some situations may go further with the need for e.g.shared cursors, so that all using the system see the same. Onthe other hand, a user might want to be temporarily isolatedfrom the actions and updates of others, allowing the user toconcentrate at the task at hand without interruptions or dis-tractions. This can be supported in the collaborative applica-tion by employing set “policy” as when and how to distributechanges. In the context of notification services, it might bepossible to grade events, so that all or only the most impor-tant notifications are displaying (thus returning to subscrip-tions, but in this case with a defined set of subscriptions). Itis also possible that the user might want to be engaged inone live session with immediate updates, and still continueworking in other contexts with less frequent updates. Thus,working with one task, but being updated from time to time

on the progress on other tasks.

The SEPIA system handles modes of collaboration throughdifferent “coupling modes” ranging from uncoupled (a sin-gle author working on a document) over loosely (authors col-laborating) and tightly coupled (authors seeing each others’updates as they are made) modes. Coupling modes for doc-uments are changed automatically as more or less authorswork on a document.

4 The Open Hypermedia Systems Working GroupThis section briefly introduces the Open Hypermedia Sys-tems Working Group (OHSWG)1, and the current state of itswork with regards to collaborative hypermedia.

OHSWG is a working group, now in its sixth year, consist-ing of open hypermedia researchers. One of the goals of thegroup has been to develop a shared understanding of openhypermedia and to support interoperability between open hy-permedia systems. The current result of this effort is theOpen Hypermedia Protocol (OHP) [13]. OHP specifies theinteraction between hypermedia clients and servers, and hasa general and extensible hypermedia data model. OHP hasbeen adopted by the Construct hypermedia servers [45], de-veloped at Aarhus University and Aalborg University Esb-jerg, Denmark. In addition to navigational hypermedia, Con-struct also support compositional and spatial hypermedia

OHP supports collaboration through the notion of sessions.A group of people working together on hypermedia struc-tures on a set of documents using various hypermedia toolsembodies the session. A session is defined by a set of users,documents, and tools, and has a coupling mode (rangingfrom uncoupled to tightly coupled) and a joining police (e.g.a public or private session) associated with it. Through thesession, each collaborator is visible to the other collabora-tors, as are his or her actions, depending on the couplingmode. The visibility of others’ actions depends on the cou-pling mode, as does the degree of latency in updates of thelocal runtime hypermedia structures. Members of a sessionare engaged in the same coupling mode and are thus equallyvisible to each other. Typical coupling modes include:

Uncoupled mode Updates on the structure server are notbroadcast to clients. Users save changes explicitly.

Loosely coupled modeChanges on the structure server arebroadcast to clients. Changes are stored automatically.

Tightly coupled mode Changed on the structure server arebroadcast to clients. Changes on the controlling clientare broadcast to other clients, keeping the hypermediaviews involved in sync.

If a collaborator so desires, special subscriptions can be set,so that specific actions taken by certain users result in noti-fications. The session is persistent and users can engage and

1http://www.ohswg.org/

disengage at any point, so that a group at a later point canresume work where it was left.

To support collaboration a session keeps a session record anda session state, which consists of key/value pairs. The pur-pose is to record an extensible set of information regardingthe session. Both can in principle been persistent, but cur-rently the session record is used for persistent information,such as the members of a session and what tools they areusing, whereas the session state is transient and is used topass information of a more fleeting nature (e.g. the positionof a window) between the participating clients. This is es-pecially used in the tightly coupled session mode, where thetools used by the particpants closely resembles each other.This is quite useful for (among other things) shared naviga-tion through the Web.

Using the session as the central vehicle for collaboration,OHP handles the basic interactions between collaborators.The addition of arbitrary key/value pairs in the session stateallows for future extensions. As the session state is broad-cast to all collaborators in a session (depending on couplingmode), OHP thus offers finely grained event notification.

One area currently not covered by the OHP is the locking andversioning of documents. The session state could certainlybe extended to this purpose, but this would only work withinone session. Locking must be handled on higher level tofunctional appropriately. Another approach would be to addan additional protocol to OHP to handle the locking and ver-sioning of resources. This area has previously been handledin hypermedia systems, and OHP could be extended like-wise. As mentioned in Section 3, the need for locking de-pends on the number and size of the resources to be locked.If resources are small and numerous, the likelihood of colli-sions is smaller.

The Construct ArchitectureHaving introduced the Open Hypermedia Protocol, we willnow turn to an implementation of the standard. The Con-struct architecture is a hypermedia server architecture basedon the principles of OHSWG. It can be seen in Figure 1. Theapplication layer is in this figure illustrated by the ArakneEnvironment [7]. The general three-layered architecturecompares with the Core Architecture of [25] and many oth-ers. The responsibilities of the three layers are:

Application layer The programs that the user interacts withreside here. The application layer is responsible for thepresentation of hypermedia structures and the integra-tion with third-party applications, as well as allowingusers to interact with others through sessions. The hy-permedia structure manipulation is handled by exten-sible set of hypermedia tools (known as ‘HypermediaViews) through a likewise extensible set of services thataddress specific kinds of hypermedia, such as naviga-tional or spatial hypermedia.

Figure 1: The OHSWG based Construct architecture. Thehypermedia tools (or “Views”) manipulate the runtime andstorage data model through the interaction with the servicesprovided by the Arakne Environment. Through a communi-cation layer the messages from these services are sent to theStructure Server, where the appropriate core processes them,resulting in queries to the Hyperstore Server. Every sessionhas instances of Views as well as services, communicationlayers, etc. Thus, in a situation withn sessions, the abovepicture would haven session boxes within the Applicationlayer andn session boxes within the Structure Server.

Structure layer The services above communicate usingOpen Hypermedia Protocol with the cores found in theStructure Server. These cores are responsible for theactual structural computations (such as in the case ofnavigational hypermedia ‘Follow Link). The cores arealso responsible for converting hypermedia structuresinto generic structures called ‘units, which are storedby the storage layer. At this layer we also find the MetaSession Information Server (MSIS), which handles ses-sions.

Storage layer The Hyperstore stores all hypermedia struc-tures once they have been transformed into units at thestructure layer. The current implementation supportstwo kinds of storage: file-based and an Oracle database.

When comparing this architecture to OHSWG, it should benoted that the OHSWG standard currently only describes thecommunication between the application layer and the struc-ture layer. Furthermore, this communication is currently lim-ited to navigational hypermedia. The Construct architectureis based on OHSWG and implementation of navigational hy-permedia complies with the standard. However, the systemhas also been extended with support for composites and spa-tial hypermedia using protocols closely based on the OpenHypermedia Protocol.

The broadcast of messages is, in the Construct implementa-

tion, accomplished by giving each session a set of hyperme-dia cores and communication layers in the structure server.Symmetrically all active sessions at the application layerhave their own hypermedia views, hypermedia services, andcommunication layer.

5 Augmenting the Web with Open HypermediaAs described in the introduction, the Web is currently unableto handle arbitrary linking and structuring. Several open hy-permedia systems have been built to address this, and theArakne Environment is one such system.

The Arakne Environment is a general environment for anopen set of hypermedia tools. Through integration with theMicrosoft Internet Explorer, the system currently providesits users with navigational hypermedia with bi-directionalmulti-headed links in Web pages and in temporal mediathrough Navette [8], as well as the guided tour tool Ariadne[31], and the spatial hypermedia tool CAOS [39].

Using the Arakne Environment and the tools within it, it ispossible to create complex structures on top of Web pages.Links and annotations created by the hypermedia views areadded, when a Web page is displayed in the user’s Webbrowser, so that it becomes possible to make for instancelinks to and from pages without modifying the pages them-selves (which would require ownership of the pages). Forstructuring purposes other than navigation, users can createguided tours with Web pages as nodes in the tour, or organisemany Web pages using spatial hypermedia. The tools can beemployed concurrently, e.g. a user could create links on aWeb page that was a part of a guided tour.

Through its support for hypermedia structuring, the ArakneEnvironment allows users collaborate in the sense, that theycan annotate and structure a shared document space. In addi-tion to this basic functionality, the Arakne Environment hasbeen extended to utilise the collaborative aspects of OHP,and how this reflects on functionality as well as user inter-face is described in the following section.

Handling Collaboration in the Arakne EnvironmentThe current version of the Arakne Environment has been de-signed to support the collaborative aspects of the Constructserver, and thus of the OHSWG standard. This section de-scribes how this manifests itself in practice.

All user interactions with a hypermedia view take placewithin a session. The user begins by default in a privatesession, and can then decide to either launch a hyperme-dia view in that session, create a new session, or to join anexisting session. Each session has a runtime data model,shared among the hypermedia views active in the session.Thus, with several active sessions, several runtime data mod-els representing perhaps the same hypermedia structures arepresent in the Arakne Environment. Rather than a waste ofresources, this conforms to the behaviour expected from cou-pling modes. As described in Section 3, coupling modes dif-

fer in how often updates take place. So, if a user is engagedin two sessions in two different coupling modes, a uncoupledand a tightly coupled session, there should be no ‘spill-overbetween the sessions, as this would violate the semantics ofthe coupling modes.

Session states are used to communicate the changes withinone user’s hypermedia view to that of other users. A hyper-media view can, depending on its abilities, generate eventsmatching changes in its own state (such as the display of anendpoint, or the movement of a node in a guided tour), andcan symmetrically receive such events and update its ownstate accordingly. The session state consists of key/valuepairs and uses a systematic name space to route the updatesreceived to the right hypermedia view.

The foundation for collaboration in the Arakne Environmentis the session, and Figure 2 shows a screenshot, where auser is engaged in two sessions. The user is currently work-ing within the session “OHS Session, using the hypermediaviews Navette and Ariadne. The Session Manager (shownto the right) is the main interface to interact with sessionsand other users. Using the Session Manager users can see,who else is using the system, what views they are using, cre-ate new sessions, see what sessions are available, and join(or leave) existing sessions. When a user joins a session, itbecomes active, and the user can switch between active ses-sions through the tabs at the bottom of the Arakne Environ-ment.

The bottom line of the Arakne Environment is the tickertape. Events and messages can be routed here, if the userso desires. Events scroll by in the ticker tape gradually grey-ing out, as to show their age. Event subscription is handledthrough the Subscription preferences, seen in Figure 3. Thebasic event system in the Arakne Environment is based onthe messages sent by OHP as well as session state changes.In the figure, the user has selected to be alerted in the tickertape, whenever the user ’bouvin’ creates or deletes links ornodes in the ’Web research’ session, as well as subscribingto four session state changes. This interface is dynamicallycreated based on the backend’s and the hypermedia view’scapabilities. Depending on the view’s capabilities, it is pos-sible to route notifications directly to the view. The view canthen highlight the change reflected by the notification.

6 Collaboration and the Arakne EnvironmentIn this section we will return to the issues raised in Sec-tion 3, and investigate Arakne in this context. One of thedesign goals of the Arakne Environment interface is to sup-port the seamless transition between single-user and collabo-rative work, and how this is supported will also be discussed.

Event notificationIn the Arakne Environment the awareness of others actionsare supported in two ways: firstly through the use of ses-sions, where the awareness is explicit, depending on the cou-pling mode used, and secondly through event notification.

Figure 2: The Arakne Environment. This is is picture ofa situation with two active sessions (as seen by the sessiontabs at the bottom), and two hypermedia views. The SessionManager is shown in the upper right corner

Figure 3: The Subscription interface. Allows a user to sub-scribe to notifications, and to designate where such notifica-tions should appear. A line signifies the ticker tape, a box inthe hypermedia view, and a combination both.

As described above, The Arakne Environment sports a tickertape at the bottom of the window. The ticker tape is used todisplay information that can help users stay aware of whatother people are doing. Such information includes the cre-ation or modification of hypermedia structures, other actionstaken by other users (e.g. link transversal), or users leav-ing or joining sessions. The messages displayed in the tickertape is repeated for a set time, determined by the user, andfades during this time, so that a quick glance allows the userto distinguish recent messages from older ones. Messagescan have associated actions to them, depending on their type,and the user can select between these actions by clicking ona message. This results in a popup menu with the appropriateactions.

Filtering can be done on the type of event, on the issuer ofthe event, and on the session the event occurs within. Thus, auser might continue working in session, but setting the sub-scription such that when another user returned to his or herdesk and started working with the Arakne Environment inanother session, it would generate a notification in the tickertape.

The ticker tape provides an relatively non-intrusive mecha-nism for keeping users peripheral aware of each others’ ac-tions. Still the default subscription is no subscriptions at all(apart from being told when other users leave or join the ses-sion), so if a user desires no intrusion at all, the system willnot force such an intrusion.

It should at this point be noted, that the Arakne Environmentuntil recently did not use a separate channel or protocol forevent notification. The notifications received and sent are allbased on either OHP or the Session State changes. As de-scribed in Section 7, the Arakne Environment is currentlybeing integrated into the iScent event system [2]. The tran-sition to iScent is quite simple (it is undergoing testing as ofthis writing), and it will enable people not using Arakne tosee what is being done, as well as giving the Arakne users aninterface to a much more general event notification service.

To provide users with a more informal interface for inter-action, the Arakne Environment sports an Internet RelayChat client. This functionality was originally added to facil-itate the logging of debugging information from distributedclients, but it has been trivial to extend this to allow the usersto chat with each other. By relying on the IRC standard, itis also possible for users at a computer without the ArakneEnvironment to interact with the other users by using a stan-dard IRC client. The workplace value of chat tools has beeninvestigated by the BABBLE system [9]. The team behindthe development of the Arakne Environment (a distributedteam of four people) has used messaging extensively as co-ordination tool with good results.

LockingLocking is currently not supported by OHSWG, and thus notby the Arakne Environment. This is a weakness and more

work needs to be done in this area. The problem domain ofthe Arakne Environment is the annotation and structuring ofexisting Web pages, and the main problem is then the lock-ing of the hypermedia structures themselves. As mentionedin Section 6, this is not necessarily a major problem, espe-cially as users (depending on the coupling mode) are updatedcontinually.

In the context of locking Web documents, Arakne supportsWebDAV [41], which is mainly used for publishing annota-tion as Web pages, but it can also be used to lock other Webdocuments. As WebDAV becomes widely adopted this func-tionality will in actual use probably be superseded by theWebDAV locking found in the Web page editors employedby the users.

Persistent collaboration informationAs noted above the OHSWG standard provides persistentsessions, so users can resume work within sessions withother users at a later point. User can also resume work intheir private sessions, where the state of the views will berestored as they left it. From the standpoint of the interface,a session is just another page with some hypermedia viewsrunning in it. It is easy to change between sessions, and itis obvious which sessions are active. The coupling mode isan important part of how session work, and the users can dy-namically change the coupling mode of a session, withoutany other changes in the interface. This allows the users togo smoothly from non-collaborative to collaborative or viceversa.

VersioningVersioning is a important component of a collaborative hy-permedia system, where documents and structures evolveover time. Currently versioning is not a part of the OHSWGspecification, and this important functionality is thus missingfrom the Arakne Environment. The Delta-V working group[14] under the WebDAV project is expected to provide theversioning functionality for documents some time this year,which however still leaves the (harder?) problem of struc-ture versioning. This is further complicated by the extensi-ble nature of the Construct model, which can accommodatemany structuring mechanisms. Versioning for navigationalhypermedia cannot be expected to be the same as for spa-tial hypermedia. One solution would be to apply versioningat Hyperstore level, where all structure has been turned intounits, but much semantic knowledge might be lost that way.

7 Future WorkThrough the development history of the Arakne Environ-ment, it has undergone several informal user testings, mainlyinvolving other team members (not directly developing onthe Arakne Environment). This has greatly informed the de-sign, and has led to numerous significant changes. Formaluser testings have however not been done yet, but are ex-pected to take place over the summer.

To support more sophisticated event notification mecha-

nisms, the Arakne Environment is currently undergoing aconversion to the iScent event service. iScent (intersubjec-tive collaborative event environment) is designed for gen-eral event notification, and has as an explicit goal to sup-port intersubjectivity, e.g. reflected knowledge between co-workers (“I know that you know that I know”). A specialfeature of the iScent system is the storage of all generatedevents, which then later can be used to catch up with whathas passed. The inclusion of this system is expected to enrichthe value of the notification mechanism already present inthe Arakne Environment, as the notifications displayed willno longer be limited to “merely” OHP events. In extension ofthis, the Arakne Environment will be extended with the TrailViewer, a tool for visualising and manipulating previous ac-tions taken by a user. As all generated events are stored inthe iScent system, it becomes an automatic memory exten-sion for the user. Given the number of the events generated,the need for effective structuring and visualisation becomesnecessary, and the development of this tools promises to beinteresting.

8 ConclusionCollaborative hypermedia is an exciting field, as is theOHSWG standardisation effort. The session combined withcoupling modes offers a strong tool for support for collabora-tive work, but there still remains much work to be addressedby the OHSWG in this aspect. Most obvious is the currentlack of locking and versioning. However, the OHSWG isstill a work in progress, and these fields can be expected toreceive more attention in the future. The promise of inter-operability between heterogeneous hypermedia systems, andcollaboration between these systems is grand.

So far the use of awareness tools and notification mecha-nisms in the context of hypermedia seems promising. Sup-port for collaborative work, while being available, should notintrude or require unnecessary attention or effort to be used,or it will not be used, as argued by Grudin [26]

A simpler and much more widespread system is the Web.While progress is being made with locking and versioning,the hypermedia model underpinning the Web remains fun-damentally unsuited for shared structuring and annotation.The combination of open hypermedia and the Web as exem-plified in the Arakne Environment enables users to structurethe Web in new ways. The Web is supremely well suitedfor this kind of extension, as it is based on open and wellunderstood document and protocol formats.

With the combination of the open hypermedia structuringand collaboration support, the Arakne Environment enablesusers to work closely together in the structuring of the Web.The Web is large and not terribly well structured, and theWeb augmentation approach allows users to leverage the in-formation found on the Web in new ways.

AcknowledgementsThe author would like to thank Rene Thomsen and Michael

Bang Nielsen for their work on version 2.1. Kenneth M.Anderson has been a valuable discussion partner. The au-thor is a member of the Coconut projecthttp://www.cit.dk/coconut/ , a joint research project consistingof Department of Computer Science, Aarhus Universityand Tele-Danmark Internet. The Danish National Centrefor IT-Research<http://www.cit.dk/> supports the Coconutproject.

REFERENCES

[1] R. M. Akscyn, D. L. McCracken, and E. A. Yoder.KMS: A distributed hypermedia system for managingknowledge in organizations.Communications of theACM, 31(7):820–835, July 1988.

[2] K. M. Anderson and N. O. Bouvin. Enabling projectawareness and intersubjectivity via hypermedia-enabled event trails. Submitted for publication.

[3] K. M. Anderson, R. N. Taylor, , and E. J. Whitehead,Jr. Chimera: Hypermedia for heterogeneous softwaredevelopment environments.ACM Transactions on In-formation Systems, 18(3), July 2000.

[4] L. Bannon and K. Schmidt. Taking CSCW seriously.CSCW Journal, 1(1–2), 1992.

[5] R. Bentley, W. Appelt, U. Busbach, E. Hinrichs,D. Kerr, K. Sikkel, J. Trevor, and G. Wotzel. Basic sup-port for co-operative work on the World Wide Web.In-ternational Journal of Human Computer Studies, 1997.

[6] T. Berners-Lee, R. Cailliau, J.-F. Groff, and B. Poller-man. World-Wide Web: The information universe.Electronic Networking: Research, Applications andPolicy, 1(2), 1992.

[7] N. O. Bouvin. Unifying strategies for Web augmen-tation. In Proceedings of the 10th ACM HypertextConference, pages 91–100, Darmstadt, Germany, Feb.1999.

[8] N. O. Bouvin and R. Schade. Integrating temporal me-dia and open hypermedia on the World Wide Web. InProceedings of the 8th International World Wide WebConference, pages 375–387, Toronto, Canada, May1999. W3C.

[9] E. Bradner, W. A. Kellogg, and T. Erickson. The adop-tion and use of BABBLE: A field study of chat in theworkplace. In S. Bødker, M. Kyng, and K. Schmidt,editors,Proceedings of the 6th European Conferenceon Computer Supported Cooperative Work, pages 139–158, Copenhagen, Denmark, Sept. 1999. Kluwer Aca-demic Publishers.

[10] V. Bush. As we may think.The Atlantic Monthly, pages101–108, July 1945.

[11] L. A. Carr, W. Hall, and S. Hitchcock. Link services orlink agents? InProceedings of the 9th ACM HypertextConference, pages 113–122, Pittsburgh, USA, 1998.

[12] L. A. Carr, D. D. Roure, W. Hall, and G. Hill. The dis-tributed link service: A tool for publishers, authors andreaders. InProceedings of the 4th International WorldWide Web Conference, Boston, USA, 1995. W3C.

[13] H. C. Davis, D. E. Millard, S. Reich, N. O. Bou-vin, K. Grønbæk, K. M. Anderson, U. K. Wiil, P. J.Nurnberg, and L. Sloth. Interoperability between hy-permedia systems: The standardisation work of theOHSWG. In Proceedings of the 10th ACM Hyper-text Conference, pages 201–202, Darmstadt, Germany,1999.

[14] Delta-V Working Group. http://www.webdav.org/wg/#dv .

[15] P. Dourish and S. Bly. Portholes: Supporting awarenessin a distributed work group. InProceedings of the ACMConference on Human Factors in Computing Systems,pages 541–547, May 1992.

[16] D. Engelbart. A conceptual framework for the augmen-tation of man’s intellect. In P. Howerton, editor,Vistasin Information Handling, volume 1, pages 1–29. Spar-tan Books, Washington DC, USA, 1963.

[17] D. Engelbart. Authorship provisions in Augment. InProceedings of the IEEE Compcon Conference, SanFrancisco, USA, 1984. IEEE.

[18] G. Fitzpatrick, T. Mansfield, S. Kaplan, D. Arnold,T. Phelps, and B. Segall. Augmenting the worka-day world with Elvin. In S. Bødker, M. Kyng, andK. Schmidt, editors,Proceedings of the 6th EuropeanConference on Computer Supported Cooperative Work,pages 431–450, Copenhagen, Denmark, Sept. 1999.Kluwer Academic Publishers.

[19] L. Fuchs. AREA: A cross-application notification ser-vice for groupware. In S. Bødker, M. Kyng, andK. Schmidt, editors,Proceedings of the 6th EuropeanConference on Computer Supported Copperative Work,pages 61–80. Kluwer Academic Publishers, Sept. 1999.

[20] L. Fuchs, U. Pankoke-Babatz, and W. Prinz. Sup-porting cooperative awareness with local event mech-anisms: The GroupDesk system. InProceedings of the4th European Conference on Computer Supported Co-operative Work, pages 247–262, Stockholm, Sweden,1995.

[21] K. Grønbæk, N. O. Bouvin, and L. Sloth. DesigningDexter-based hypermedia services for the World WideWeb. In M. Bernstein, L. Carr, and K. Østerbye, ed-itors, Proceedings of the 8th ACM Hypertext Confer-ence, pages 146–156, Southampton, UK, Apr. 1997.

[22] K. Grønbæk, J. A. Hem, O. L. Madsen, and L. Sloth.Cooperative hypermedia systems: A Dexter-based ar-chitecture.Communications of the ACM, 37(2):64–74,Feb. 1994.

[23] K. Grønbæk, L. Sloth, and P. Ørbæk. Webvise: browserand proxy support for open hypermedia structuringmechanisms of the World Wide Web. InProceedingsof the 8th International World Wide Web Conference,pages 253–267, Toronto, Canada, 1999. W3C.

[24] K. Grønbæk and R. H. Trigg. Design issues for aDexter-based hypermedia system.Communications ofthe ACM, 37(2):40–49, Feb. 1994.

[25] K. Grønbæk and U. K. Will. Towards a com-mon reference architecture for open hyperme-dia. JoDI, Journal of Digital Information, 1(2),1997. http://jodi.ecs.soton.ac.uk/Articles/v01/i02/Gronbak/ .

[26] J. Grudin. Two analyses of CSCW and groupware.Technical Report 323, Department of Computer Sci-ence, University of Aarhus, Denmark, July 1990.

[27] J. M. Haake, T. Knopik, and N. Streitz. The SEPIA hy-permedia system as part of the POLIKOM telecoopera-tion scenario. InProceedings of the 5th ACM HypertextConference, pages 235–237, Seattle, USA, Nov. 1993.

[28] J. M. Haake and B. Wilson. Supporting collaborativewriting of hyperdocuments in SEPIA. InConferenceproceedings on Computer-supported cooperative work,pages 138–146, Toronto, Canada, Nov. 1992.

[29] W. Hall, H. C. Davis, and G. Hutchings.RethinkingHypermedia: The MicroCosm Approach. Kluwer Aca-demic Publishers, Norwell, USA, 1996.

[30] C. Heath and P. Luff. Collaboration and control: Cri-sis management and multimedia technology in LondonUnderground line control rooms.CSCW Journal, 1(1–2):69–94, 1992.

[31] J. Juhne, A. T. Jensen, and K. Grønbæk. Ariadne:A Java-based guided tour system for the World WideWeb. In Proceedings of the 7th International WorldWide Web Conference, Brisbane, Australia, 1998.W3C.

[32] P. Kahn, J. M. Nyce, T. Oren, G. Crane, L. C. Smith,R. Trigg, and N. Meyrowitz. From Memex to hyper-text: understanding the influence of Vannevar Bush. InProceedings of the 3rd ACM Conference on Hypertext,page 361, San Antonio, USA, Dec. 1991.

[33] C. C. Marshall. Toward an ecology of hypertext anno-tation. InProceedings of the 9th ACM Hypertext Con-ference, pages 40–49, Pittsburgh, USA, 1998. ACM.

[34] N. K. Meyrowitz. Intermedia: The architecture andconstruction of an object-oriented hypermedia systemand applications framework. InProceedings of ACMconference on Object Oriented Programming Systems,Languages and Applications (OOPSLA 86), 1986.

[35] N. K. Meyrowitz. The missing link: Why we’re all do-ing hypertext wrong. In E. Barrett, editor,The societyof text: Hypertext, hypermedia and the social construc-tion of information, pages 107–114. MIT Press, Cam-bridge, USA, 1989.

[36] P. J. Nurnberg, E. R. Schneider, and J. J. Leggett.Designing digital libraries for the hyperliterate age.Journal of Universal Computer Science, 2(9):610–622,1996.

[37] A. Pearl. Sun’s link service: A protocol for open link-ing. InProceedings of the 2nd ACM Conference on Hy-pertext, pages 137–146, Pittsburgh, USA, Nov. 1989.

[38] W. Prinz. NESSIE: An awareness environment forcooperative settings. In S. Bødker, M. Kyng, andK. Schmidt, editors,Proceedings of the 6th EuropeanConference on Computer Supported Copperative Work,pages 391–410. Kluwer Academic Publishers, Sept.1999.

[39] O. Reinert, D. Bucka-Lassen, C. A. Pedersen, and P. J.Nurnberg. CAOS: A collaborative and open spatialstructure service component with incremental spatialparsing. InProceedings of the 10th ACM HypertextConference, pages 49–50, Darmstadt, Germany, 1999.

[40] N. A. Streiz, J. M. Haake, J. Hannemann, A. Lemke,W. Schuler, H. Schutt, and M. Thuring. SEPIA: A co-operative hypermedia authoring environment. InPro-ceedings of the European Conference on HypermediaTechnology (ECHT 1992), pages 11–22, Milan, Italy,1992.

[41] E. J. Whitehead Jr. and Y. Y. Goland. WebDAV: Anetwork protocol for remote collaborative authoring onthe Web. In S. Bødker, M. Kyng, and K. Schmidt,editors,Proceedings of the 6th European Conferenceon Computer Supported Cooperative Work, pages 291–310, Copenhagen, Danmark, 1999. Kluwer AcademicPublishers.

[42] U. K. Wiil and J. J. Leggett. Concurrency control incollaborative hypertext systems. InProceedings of theACM Hypertext 1993 Conference, pages 14–24, Nov.1993.

[43] U. K. Wiil and J. J. Leggett. The HyperDisco approachto open hypermedia systems. InProceedings of the 7th

ACM Hypertext Conference, pages 140–148, Washing-ton DC, USA, Mar. 1996.

[44] U. K. Wiil and J. J. Leggett. Workspaces: The Hyper-Disco approach to Internet distribution. In M. Bern-stein, L. Carr, and K. Østerbye, editors,Proceedingsof the 8th ACM Hypertext Conference, pages 13–23,Southampton, UK, Apr. 1997.

[45] U. K. Wiil and J. J. Nurnberg. Evolving hypermediamiddleware services: Lessons and observations. InProceedings of the 1999 ACM symposium on Appliedcomputing, pages 427–436, San Antonio, USA, Feb.1999.