Department of Distributed Systems,
Computer Science Faculty, University of Ulm, Germany
email@example.com and firstname.lastname@example.org
Millions of people are browsing at the same time, sometimes thousands the same
Web site concurrently. But, people browsing the Web are unaware of others. Browsing the
Web is like shopping downtown without people on the street. There are not even sales
persons in the virtual shops. The Web appears lifeless and static. This actually is wrong.
There are many people (and robots) around. There is plenty of life, but it is
unfortunately hidden from users. Static neighbourhoods, communities, MUDs and chat systems
are used to provide places where people can meet. But all of these services are bound to
specific locations (URLs) on the Web. People go there to meet others. They can not meet on
any page, in any place of the Web.
The Web URLs and links constitutes the infrastructure and a major part of the content. Other objects are not visible via the Web's native mechanisms. An additional service the equivalent of night-vision goggles is necessary to make these hidden objects visible to users. This is the task of the dynamic neighbourhood service.
In the real world, the visible area is different from person to person. Everyone
sees a different subset of the objects in the neighbourhood, e.g. other people, things,
pictures, etc. Therefore every Web user needs an individual visible area, and a personal
set of objects within the visible area. The visible area must not only depend on the
surroundings the Web pages. It should also correlate to the user and its properties. The
dynamic neighbourhood, the visible area is computed for each user individually.
The most obvious property of a Web user is the location of Web pages visited. Like in the real world, the position of a person determines the visible area. But the surroundings are also influential. On the Web, the environment is given by Web pages and interconnections (hypertext references). As people move from page to page they carry their neighbourhood with them. The neighbourhood changes with every move. It moves with the user. In the simplest model the neighbourhood consists of the Web pages, which are close to the current page in terms of links. The user can see the neighbouring pages and all objects associated with these pages, i.e. other users. A moving user is presented with a changing set of visible objects. Other users may see the user in motion appearing in, and disappearing from their neighbourhood.
Web pages are locations of the virtual world. These virtual locations correspond to places in the real world like rooms, street corners, and stores. People are moving between virtual locations via hypertext references. On the Web links are only used as interconnections. We propose an additional distance-attribute to the anchor-tag of HTML to indicate the strength of the interconnection. Locations can be far apart in the virtual world even if they are linked with a hypertext reference. On the other hand 0-distance combines linked documents to a single virtual one. The distance-attribute defaults to 1 if absent. Values of the distance-attribute are numeric (0..1) or named (e.g. "near", "far"). Links are treated as symmetric to allow for symmetric visibility.
The virtual world contains more than just locations and links. Humans (and robots) are acting in the space constituted by URLs. We identified two important types of actions: movement through the virtual world, as it has been described above and communication. Persons and communication exist within the space created by the Web. The presence of persons is limited to a small fraction of the Web: their position and its surroundings. The strength of presence or visibility of persons depends on their visibility-function. The visibility-function is a function of the distance from the person's position. The distance is measured in a metric imposed on the underlying hyperspace, the Web. The obvious choice as a metric are the hypertext references as described above, but others such as document content overlap are imaginable. People see each other if the visibility overlaps
The current implementation covers 3 types of objects: locations, persons, and
communication. Objects are identified by type and name. Names are globally unique for each
object type. The name will usually be tailored to the object type for better readability
and to simplify addressing of external resources. Locations are the most important
resource external to the dynamic neighbourhood model. URLs are used as names of Location
Each object has instance variables to store individual information about the object. Part of the information such as the name is entered by users. Some information is extracted by various means and the third part is computed by the service at run-time. The most important variables of the persons are: visibility-function, icon, nickname, locations, and neighbours. Icon and nickname represent persons at the user interface level. Other variables control the computation of visible areas and the visibility-function. The "neighbours"-variable is computed by the service frequently. It contains the all-important list of visible persons in the vicinity. Location objects have the variables icon, links and persons. The icon is used to represent the page in an advanced user interface as a thumbnail image.
Objects and variables are accessed through a set of methods. Available methods
are GET and PUT to retrieve and set the content of a variable; SUBSCRIBE and UNSUBSCRIBE
for notifications of changes of a variable's content, and ASSOCIATE / DISSOCIATE. Most of
messages exchanged between components of the neighbourhood service manipulate or evaluate
instance variables. Variable manipulation commands consist of object type and name, the
variable name, the method, and optional data. ASSOCIATE and DISSOCIATE methods work on
objects. They are used to put objects into relation. The proposed neighbourhood model uses
directed 2-fold associations. Each association consists of 2 objects, the source- and the
target-object. For better readability we introduced aliases for associations between
LocationLocation: LINK and UNLINK mark hypertext references between documents.
PersonLocation: ENTER and LEAVE. These commands are generated on entry and exit of Web locations.
The exact times are to be determined by information gathering components.
PersonCommunication: JOIN and LEAVE let persons enter (and leave) communication channels.
Neighborhood servers provide the user dimension of the
virtual world. They serve neighbourhood clients in the same sense as Web servers serve Web
clients. A neighbourhood server is responsible for the user space of a part of the Web and
it will create the user space for this part. In this case each Web server is accompanied
or complemented by a neighbourhood server. But a neighbourhood server can also create the
user space for a group of Web servers. Neighborhood servers communicate to create
vicinities over border links between Web servers. The traffic generated by inter-server
communication is only a small fraction of the HTTP traffic between Web clients and Web
Neighborhood clients presents a dynamically changing view of the user space. They are using the protocol introduced above to retrieve information about the position of the user, the surroundings, other users and their properties. The protocol is encapsulated into (form-urlencoded) HTTP requests. This guarantees compatibility with components augmenting the Web such as proxies and firewalls. A Unix-select like mechanism is used to notify updates to objects and variables.
The server currently computes the neighbourhood for two WWW-sites: an example
site created to model a typical commercial scenario, the Virtual CarStore. Visitors can
look at cars and talk to a virtual sales representative. The second site is the
interactive model railroad (IMRR) (http://rr-vs.informatik.uni-ulm.de/rr/) with more than 1000
users per day . These users come to the IMRR to play and watch the trains go around the
tracks in slow-scan video. They can see others watching the scene and chat with them with
an ASCII-chat built into the user interface. A simple click on a person's icon
initiates an Internet phone connection, if such tools are available at the user's site.
The central components, the server computing the neighbourhood and the information gatherers are implemented in C. The client-based part of the system, the user interface is written in Java. The Cobrow system is currently available for Windows NT, 95, SunOS, Solaris and Linux from http://www.cobrow.com/ . This work has been performed in the EU Telematics Project Cobrow (RE1003).