A Reference Architecture for Multi-Author World-Wide Web Servers

Louis Perrochon, Institut für Informationssysteme, ETH Zürich, Switzerland.
perrochon@acm.org

Abstract
Designing publicly accessible and distributed information structures and coordinating distributed authors is a major challenge for most organizations. This paper presents a scaleable reference architecture for multi-author World-Wide Web (W3) servers, one important type of a distributed and publicly accessible information system. We introduce the paradigm of "lean production of information" and discuss some problems of data quality regarding W3-servers. Experiences made with a departmental W3-server designed and maintained according to the principles presented are appended as a case study.
Keywords:
Reference Architecture, Organizational Computing, Information System, Lean Production of Information, Data Quality, World-Wide Web (W3).

1. Introduction

The World-Wide Web (W3) [Berners-Lee 94] is a rapidly growing, highly distributed information system. The number of W3-users is already beyond any human imagination. It is no longer possible to keep a clear overview. Unfortunately for the users, it is still hard to find any useful information on the W3. W3 indexing systems like CMU Lycos [Maudin et al. 95] or WebCrawler [Pinkerton 94] and virtual libraries like Yahoo [Yahoo] are approaches to solve this problem.

But not only the user's view is chaotic, also the underlying structure. As it is very easy to provide information on the Web, many W3-users are also W3-authors and -providers. Many of them even run their own W3-server. We believe that we are facing a change of paradigm. We are moving away from the "information warehouse", an intermediary storage, that gets data from providers, stores it for some time and delivers it upon request to customers. The new paradigm is "lean production of information", where information is delivered from the producer to the consumer exactly when the consumer requests it and in the most current state.

The growing customer demand for up-to-date multimedia online information requires all kind of organizations to join the W3 in a hurry. As a consequence, computer technicians install W3-servers ad hoc. This may be acceptable for academic research prototypes. However, implementing a useful W3-server is a project by itself and requires traditional project management and software engineering methods. For the initial installation and maintenance of the data, new methods have to be found.

In section 2 we introduce the paradigm of "lean production of information". In section 3, we give a short reminder on how W3-server should be designed and implemented. Section 4 shows some related work. Section 5 deals with the reference architecture for multi-author W3-servers. Section 6 contains some thoughts on data quality control. Section 5 and 6 are based on the experiences made with various public information systems (Videotex, VT100-based interactive services, Gopher, and W3). We describe the most important one in section 7. Section 8 summarizes and proposes directions for further work and discussion.

2. Lean Production of Information

The last decade brought a change of paradigm about where computation takes place. Client-server computing introduced the idea of decentralized computing power. Centralized Servers still store data, but decentralized desktop computers process it locally. This idea is not yet perfect: having a central "information warehouse" still requires the producer to bring his information to the central warehouse. There it will be stored until it is demanded. In many applications the central "information warehouse" is no longer necessary. The consumer now fetches the required information directly from the producer. The central warehouses are replaced by mediators.

We call this paradigm "Lean production of information" (LPI), in analogy to lean production of goods. Information is delivered to the customer at exactly the moment he requires it and in the most current state possible.

LPI means that information is stored right where it is created, on distributed sites. Information is authored by many different authors and it cannot be controlled or edited centrally. In practice, even if a server has only one webmaster, most servers have many persons responsible for the contents. Organizations that used to rely on a central publishing agency, which edited everything before publication, will have to change the structure, as it is no longer feasible for the W3. With the W3 every unit of an organization has to maintain its own information structure and bear responsibility for it.

Another problem is indexing and searching. The best search systems for the W3, like CMU Lycos and WebCrawler, put the emphasis on finding information, not on powerful indexing of the found information. They put so much effort in searching the W3 for information, that they forget to present the results in a sophisticated way.

LPI requires the right computing and organizational environment. The W3 gives us a possibility to implement LPI. However, the W3 does not support cooperative authoring very well. Moreover the existing means for searching and billing for information are not yet sufficient.

The reference architecture discussed in this paper supports LPI. Every member of an organization can put his own information in an organizational framework, with the desired individuality and the required uniformity.

3. Project Management Aspects

It is very important that W3-servers are designed and implemented like any other information system. There exist many publications and much experience is available concerning project management. It is not clear, why so few organizations use this knowledge for W3-server installations.

In our projects we used a simple waterfall model for project-organization, with analysis and design phases before the actual implementation:

Analysis

Points that have to be cleared in the analysis phase are the intended use (e.g. user support, advertisement), availability (both temporal and geographical), intended users (staff, visitors, customers, everybody), amount of data provided, update-frequencies, etc. The only difference compared to setting up any other public information system is the number of potential users, which can be very large for W3-servers.

Design

Writing a clear specification for the W3-server is necessary. The specification should include a detailed list of essential, less important and nice-to-have features. Otherwise, the programmers add too many time-consuming gadgets (e.g. all those nifty in-line images instead of simple enumeration bullets). The W3 can be very dangerous because it is developing continuously: new features and flavors appear every other day. The restriction to the essentials helps to finish on schedule and simplifies the maintenance later.

Implementation and Data provision

The implementation phase consists of some configuration work and the provision of data. The server configuration is quite simple, straight forward and well documented (e.g. [CERN], [NCSA]). Providing high quality data is crucial but not so easy. A W3-server is an electronic brochure (e-brochure) of an organization. Thousands of W3-users access it. Existing internal rules and procedures for publications have to be followed closely. If an organization has a marketing, a public relations or a library department, these people should be consulted frequently, even if they do not have much experience with electronic publications and online systems.

Maintenance

Judging from existing W3-servers, it seems as if some providers do not care about maintenance. Incorrect and out-dated information can be more annoying than missing information. We learned the hard way with earlier information systems. After the first excitement was over, the information was no longer maintained. These systems were all built as "information warehouses" and the producers just forgot to update new information because it was so "far away". Section 6 gives some introduction in maintenance tasks.

This paper covers only design and maintenance aspects.

4. Related Work

The online documentation for information providers includes helpful style guides for authors (e.g. [Berners-Lee], [Richmond]) and many technical details [W3Tools]. However, there is not much information available on how to set up a W3-server from the organizational point of view. Tim Berners-Lee, one of the developers of the W3, only states:

The web has spread from the grass roots, without a central authority, and this has worked very well. This has been due in part to the creativity of information providers, and the freedom they have to express their information as directly and vividly as they can. Readers appreciate the variety this gives. However, in a large web they also enjoy a certain consistency. If you are a person responsible for managing the information provided by your organization, you have to balance the advantages of a "house style" with the advantages of giving each group or author free rein. If you end up with decisions in this area, it is as well to write them down (not to mention put them on the web)
[Berners-Lee]

The webmasters of the German National Research Center for Computer Science (GMD) did so. They have developed a system to allow many authors to add documents to their W3-server [Baker et al. 94]. Their paper also covers some issues of quality control. Concerning the importance of carefully designed public information systems, Ake Grönlund comes to the conclusion that "the employment of public computer systems is a strategic issue" because it affects the relation between the organization and its customers [Grönlund 94]. On the other hand, some authors seem to have an aversion against a carefully controlled introduction of the W3 into an organization [Sherwood 94]. In my opinion, taking matters too easy can become quite expensive. However, most authors find the biggest challenges not in the technical, but in the organizational problems.

The Hyper-G system [Kappe 93] has inbuilt support for most of the architecture described below. However, to fully exploit its capabilities both Hyper-G servers and clients have to be used. Unfortunately, Hyper-G is very restrictive. This and the fact, that the server code is not freely available are probably the main reasons that Hyper-G is not very widely used. Only some 100 servers are running, most of them experimental.

5. A Reference Architecture for Multi-Author W3-Servers

Structure Overview, Figures 1a and 1b

Fig. 1. Structure of the organization and a possible structure for a W3-server

In this section we define a reference architecture for W3-servers. It can be implemented in several ways, including other systems like Gopher [Gopher] or Hyper-G. It is basically only a method of allocating distributed responsibilities.

For our reference architecture we use a typical scenario of a multi-author W3-server for a university department (see also section 7) divided into institutes, each of which consists of research groups. This server architecture can easily be transformed to any similar hierarchical structure.

A server administrator (or webmaster) is responsible for the server as a whole. His task includes responsibility for the content of the central pages, building and maintaining the main information structure (or infostructure) of the server. He defines the "house style" (i.e. customized author guidelines), coordinates all authors and gives education and continuing support to users and authors. Webauthors are designated members of the staff, each one responsible for a subpart of the overall infostructure. The webmaster and the webauthors, who mainly do the technical work, are assigned to superiors approving the contents of their pages. Finally, every member of the staff has the possibility to set up personal pages (we suppose that the use of company equipment for personal pages is allowed). The system operator, who has no responsibility at all for the actual content or quality of the data, just keeps the machine and the software running properly. Often the webmaster and the system operator are the same person.

In the organization depicted in Fig. 1, the webmaster and the system operator are assigned to the head of the department. Research group 1 and institute 2 have both designated a webauthor for their pages.

5.1 The CSAP-Classification

In the design phase the webmaster classifies all the pages in the infostructure. Classification can be based on indended users, the importance of a page or the responsible webauthor. Primarily, all pages can be separated into those for external users and those for internal users. If this separation is made, there should be only links from the internal pages to the external pages and not vice versa [Baker et al. 94]. The following classification, based on author and importance, can be combined orthogonally with the one based on intended users. We suggest four classes of pages.


CSAP-classific Central Pages    Subsidiary       Additional       Personal Pages    
ation                           Pages            Pages                              

Author            Webmaster       Webmaster or      Webauthor     individual staff  
                                   Webauthor                           members      

Contents          Important        Important        Additional     Information on   
                 information      information      information       individual     
               about the whole   about subparts   about subparts       persons      
                 organization                                                       

Type             official and     official and     official and    unofficial and   
                  mandatory        mandatory       facultative       facultative    

House Style       mandatory        mandatory         strongly         strongly      
                                                    suggested         suggested     

Has Links to         C, S         C, S, (A, P)      C, S, A, P       C, S, A, P     

Physical        On the central     central or       central or       central or     
location            server        distributed      distributed       distributed    



Table 1. Summary of the CSAP-classification

Class C: Central Pages (C-Pages)

Central pages make sure, that minimal information about the organization is available online. These pages build the "cover sheet", the "abstract" and the table of contents of the e-brochure and often include an index. Most users will see these pages, no matter in which subpart of the whole infostructure he is interested in. Central pages are official pages and only set up and maintained by the webmaster. The content and layout of these pages are considered very important and are approved by the head of the department. Of course these pages must confirm to the house style. C-pages can not be altered by subparts of the organization. C-pages always stay on the central W3-server of the organization. The home (or entry) page of the organization and the first level of the infostructure should always be classified as class C (See Fig. 1b, boxes with "C"). To give the user some guideance, all the other pages should directly refer to the most important C-page, the homepage.

Class S: Subsidiary Pages (S-Pages)

Subsidiary pages make sure, that minimal information about the subparts of the organization is available online, no matter if the subparts themselves are willing and able to maintain their own subsidiary information structure. S-pages are by default set up and maintained by the webmaster but only the existence of these pages is considered important and guaranteed by the webmaster. S-pages neither have to be maintained by the webmaster nor approved by the central management. On request and with the designation of a webauthor, every subpart of the department gets the permissions to alter its own S-pages. In this case the head of the subpart is responsible for the content. These pages must confirm to the house style. (See Fig. 1b, boxes with "S".)

Class A: Additional Pages (A-Pages)

Additional pages provide additional information about subparts of the organization and without relevance for the organization as such. A-pages are set up and maintained by the webauthors. While these pages are still considered official, they are not important for the organization as a whole. On request and with the designation of a webauthor, every subpart of the department gets the permissions to add A-pages. To have A-pages linked into the overall infostructure, the S-pages have to be altered. Thus the subpart has to maintain its own S-pages to be able to include links to the newly created A-pages. In Fig. 1, the research group 2 cannot have A-pages, as their S-page is still maintained by the webmaster. A-pages should still confirm to the house style. (See Fig. 1b, boxes with "A".)

Class P: Personal Pages (P-Pages)

Personal pages are set up and maintained by individual staff members. These pages are not considered official, but of course they still have to follow existing company guidelines. On request every member of the organization gets the permission to set up personal pages. To have personal pages linked into the overall infostructure the S- or A-pages have to be altered by the responsible webauthor. Thus the subpart has to maintain its own S- or A-pages. In Fig. 1, the members of research group 2 cannot have P-pages, as their S-page is still maintained by the webmaster. The staff members must be encouraged to adopt the house style. Note that the personal "homepage", a page describing an individual, sometimes is classified as official, i.e. class A or even S. In these cases, the individual staff member has no possibility to alter its own official "home-page", but may still be allowed to have other homepages. (See Fig. 1b, boxes with "P".)

Classes C and S are the core of the infostructure. These pages always exist (mandatory). The webmaster as author of the C- and some of the S-pages should only include links to other C- and S-pages to be sure that the core part remains consistent. Links to A- or even P-pages are only included in S-pages if this S-page is maintained by a designated webauthor (see Fig. 1, Research Group 1 and Institute 2). It is the responsibility of the webauthor to maintain consistency in his own subsidiary infostructure. Links between different subsidiary infostructures are dangerous and should be avoided.

Links between different subsidiary infostructures are a prime cause of dangling links and frustration. There is no way to tell all the people with links to a page, that this certain page has been removed.

Structure Overview, Figure 2

Fig. 2. Central Server with one subsidiary and one special purpose server.

5.2 Separate Subsidiary, Special Purpose and the Central Server

The CSAP-classification presented above only affects the conceptual level. The physical distribution of pages is discussed in this section. One solution is to store the whole infostructure on one central W3-server. However, this is not always feasible. The two main reasons for additional servers are discussed in the following (Fig. 2):

Enhanced Flexibility Requires Subsidiary Servers

Sometimes the central server lacks the flexibility required by subparts of the department, e.g. if the used server software is not able to perform special tasks. In this case, the subpart sets up its own, subsidiary server. Of course the respective subpart has to maintain this server. In this scenario, the central server represents a service provided by the organization and offered to its subparts. These subparts can decide to take advantage of it or to perform the job themselves.

Another remark on distribution: C-pages and S-pages maintained by the webmaster should always remain on the central server. However, pages "on the central server" do not have to be stored on a disk physically near the server. Mounting remote file systems (e.g. Network File System (NFS) or Andrew File System (AFS)) is also possible. This is especially useful for personal pages.

Unrelated Information Requires Special Purpose Servers

Often individuals or subparts of the organization want to offer additional services, that do not fit into the overall infostructure. Examples are a caching proxy-server, a temporary server for a conference, or a server for a special user group. Some users are setting up "recreational services" (e.g. for scuba-diving in the Antarctica, etc.) on their personal pages. All of these additional services can severely influence the overall stability of a company W3-server. Instead of denying requests for additional services or forbidding such activities, special purpose servers can be installed. These severs are not subsidiary to the central server, but fully independent and have to be separated from the company W3-server, if possible both technically and organizationally.

6. Establishing Constant Quality Control

The webmaster is responsible for the overall infostructure and the definition of a house style, i.e. customized author guidelines. For both it is wise to base on other's experiences. All the local webauthors should be included in the process of defining the house style. Basic elements can be found in many of the guidelines for authors: signing and dating of every page, including the same (small) menu on top of each page, etc. [Berners-Lee], [Richmond]. The best way to ensure conformity with the house style is information and support. Most authors are more than happy, if the webmaster installs templates for pages, writes down and distributes the house style and tells them, if they offend against it.

The issue of quality control is very important. Due to the distributed responsibility for the contents, the webmaster cannot control the contents of all the pages. However, there are things the webmaster can and should do. One possibility is to periodically check all the links in the whole infostructure. There are tools available, that do this automatically (e.g. MOMSpider [Fielding 94]). The webmaster should also provide tools for syntactical checks of the pages or check all the pages automatically ([W3Tools]). Of course the webmaster should clearly define these activities and the webauthors and staff with personal pages must accept them.

A useful activity (and very appreciated by the webauthors) is the collection and statistical analysis of log files. This helps to detect errors, to concentrate on the essential pages and to get rid of pages never requested. Unfortunately today's analysis tools (see [Hughes 94, Beckett 95]) are not yet very useful to determine the access patterns of single users because the stateless Hypertext Transfer Protocol [HTTP] used by the W3 does not easily allow to match follow-up requests from the same user.

7. DINIS: A Case Study

The Department of Computer Science of the Swiss Federal Institute of Technology, Zürich, Switzerland (Eidgenössiche Technische Hochschule, ETH) started the first project in the new vogue of Internet based information systems with a Gopher-server in 1993. In May 1994, the Department of Computer Science decided to change from Gopher to the World-Wide Web. As a project work, four students designed and implemented DINIS (Departement Informatik Informationssystem) in the following weeks.

One of the project goals was to implement the experiences from other systems and design not only a server but also an organizational structure behind it:

The ETH has a department with four institutes, 19 professors and some 130 members of staff. The totally different needs of research groups make it impossible to impose a uniform format on the departmental information system. Having only vague guidelines (house style), clearly defined interfaces between various parts were vital for a useful information system.

DINIS consists now (May1995) of a core part (C-pages) of about 20 pages managed by students in the same status as teaching assistants and the webmaster as coordinator of the efforts. These pages describe the department, its history, its service groups and major publications (e.g. dissertations). We also have links to other important servers, like our FTP-server, an electronic telephone- and address-directory and similar things.

For our four institutes and several service groups, we initially have installed around 45 S-pages with core information about the different research groups. The catalogue of the courses taught by our staff accounts for another 175 S-pages. Eight research groups and two institutes decided to set up their own subsidiary infostructure and manage their own S-pages. Together, these groups maintain about half of the S-pages, some 150 A-pages and a growing number of P-pages. This distinction is not clear, as one research group defines personal homepages as A-pages. For technical reasons only a part of the staff can install their P-pages on their own. The others currently have to rely on a webauthor or the webmaster. Overall, this qualifies for a relatively small information structure, but it fulfills exactly our needs.

Three of the research groups have their own subservers running. The other five research groups managing their own pages have accounts on the DINIS-computer. They have their own directories, but the files are served by the same W3-server-daemon. With this solution, they can fully concentrate on the contents and do not have to bother with the software.

On the core part, we currently have some 500 requests per week-day, around 100 are coming from some 25 sites outside Switzerland. The real number is probably a little higher, as we do not include accesses to the three subsidiary-servers or the special purpose servers.

7.1 Special Purpose Servers

Along with the central and the subsidiary servers, we have currently three special purpose servers in our department.

The Computational Biology Server offers access to an interactive tool for peptide and nucleotide sequence analysis [Benner et al. 94]. This server had been on-line when DINIS officially started and is totally separated from DINIS.

We host the server of the Swiss Federation of Information Processing Societies (SVI). This is an example of support for non profit organizations in Switzerland. This server is totally separated from DINIS.

We also host some 100 entries for the profession computer scientist/consultant of the distributed hyper-biographical database Who's On-line [WHO's Online]. This projects aims to set up a database of personal homepages containing biographical information. This is an example for personal research interests of the webmaster and has nothing to do with the department as such. This service still runs on the main DINIS server and accounts for additional 100 requests per week-day.

7.2 Language

When leaving the English speaking countries, the problem of the language arises. In Switzerland we have four national languages. On our server most pages are in English, the main Internet language. Additionally, we have a German version of the home-page and the first level pages, as we are situated in the German speaking part of Switzerland. Links to pages in another language are normally marked (explicitly or implicitly with a German anchor-word).

7.3 Quality Control

The CSAP-classification of pages and the clear separation of responsibilities help us to maintain a highly consistent server with minimal effort. Twice a year we have a meeting of all involved and interested people, where problems and future expansions are discussed. On the technical side, we perform a MOMSpider check [Fielding 94] of all our links every few weeks. The results are always good. Only occasionally broken links are detected. They mostly stem from removed or renamed documents on other servers, where we have no influence. In addition all the changes in the central pages (C-pages) are manually controlled by a second person. We further plan to perform automatic syntax-checking soon.

7.4 Results

Although DINIS has been running for a year only, some results can be stated already.

We have a well maintained and clearly structured W3-server with a scaleable reference architecture and can react easily to growing demands from the different parts of our department. The two students maintaining the server have more than enough capacity left to gradually enhance our server. They spent almost no time in user support and much less than we initially expected for configuration of clients, assistance with authoring, etc.

We met practically no opposition against our scheme. The reference architecture is so flexible, that all the requirements of different research groups could be fulfilled. Some people were surprised, how easy and fast publishing on our W3-server is. They did not realize that they are guided all the time.

The data on our server is well maintained. This proves that "lean production of information" (LPI) can simplify the maintenance task. Because the information is stored very "close" to the author, he updates it as necessary. Still, on our server, the most important pages (C-pages) must be stored centrally to guarantee that they are always available. However, we do not have to update C-pages very often.

The coordination of electronic publications and the contact between members of different research groups have clearly improved. Now all electronic publications (including all new dissertation and technical reports) of the department are collected in a single directory of the FTP-server with central indexes, which are automatically converted to W3-pages. Some of the technical reports are no longer published on paper.

We managed to bring existing information systems and the differing ideas, opinions and goals of the several research groups and institutes under one roof. In the initial organigram, webauthors were placed only on the institute level (Fig. 1, Institute 2). The experienced showed that this restriction was not adequate. Now we have webauthors both on the institute as well as on the research group level. The house style allows coexistence of different ideas of electronic representation of one's research work. The openness of the W3 also allows everybody to join DINIS, independent of the underling hardware or software.

DINIS provides a distribution channel for information in the educational sector too. Our students can gain information on courses, opportunities for personal project work and get easier insight on the research done in our department.

There are only few hints that DINIS changed the daily work of our own staff members. Without doubt many people use W3-browsers daily to collect information needed for their work, but the use of personal communication or e-mail in our department will hardly be reduced by DINIS. The most interesting page for our own staff is probably the agenda of the department. However, there is an ever growing interest in our server from abroad.

7.5 PubDINIS

Having a stable running electronic information system for people connected to the Internet, we are now improving access for other people (who still are a majority of the tax-payers in Switzerland, our prime founders). We have a text based client (Lynx) accessible for everyone with a computer and a modem since the first days of DINIS. We set up a publicly accessible W3-client (PUBDINIS, an "electronic kiosk") in our building. First experiments are very promising [Perrochon et al. 95b]. The goal is to set up such a system without changes in the overall infostructure.

8. Summary and Future Work

The CSAP-classification is one aspect of a successful design of multi-author W3-servers. We discussed the separation of special purpose services from central W3-servers and means to maintain data quality. Quality issues play a crucial role when building successful and useful W3-servers. We presented DINIS, the information system of the Department of Computer Science of ETH Zürich.

We also mentioned some areas, where further work has to be done. Due to the nature of Internet, there is almost no statistical data available about Internet users. Unfortunately, the W3-protocol [HTTP] does not yet support the analysis of user access patterns very well. One solution is the development of better log-file analysis tools, that collect information about the access patterns of single users. Another weak point of the W3 is the integration of existing interactive services. There is some work done right now in this direction, e.g. [Ford et al. 94], [Perrochon et al. 95b], [Ronchetti 95], but no general results have been presented so far.

It will also be interesting, how far "lean production of information" will go. Wireless telecommunication may lead to a network of interconnected computers, where information is exclusively transfered "on demand".

9. References

[Baker et al. 94]
Baker, T., Brüning, I., Klein, L., Lenz, M. Starting a Web site: issues of quality control. Network Service Conference (NSC'94), November 28-30, 1994, London. Published in Computer Network and ISDN Systems 26 (Suppl. 2 double issue) (1994) S55-S61.

[Beckett 95]
Beckett, D. Combined log system. The Third International World-Wide Web Conference 1995 (WWW'95), Darmstadt, April 1995. Computer Networks and ISDN Systems 27 (1995) 1089-1096. See <http://www.hensa.ac.uk/tools/www/logtools/>.

[Berners-Lee]
Berners-Lee, T. The W3 Style Guide. See <http://info.cern.ch/hypertext/WWW/Provider/Style/Overview.html>.

[Berners-Lee et al. 94]
Berners-Lee, T. Cailliau, R., Luotonen, A., Nielsen, H. F., Secret, A. The World-Wide Web. Communication of the ACM. Volume 37, Number 8 - August 1994.

[CERN]
The World-Wide Web home. See <http://info.cern.ch/>.

[CSotD]
Davis, G. Cool Site of the Day. See <http://www.infi.net/cool.html>.

[Benner et al 91]
Gaston H. Gonnet and Steven A. Benner. Computational biochemistry research at ETH. Technical Report 154, Institute for Scientific Computing, ETH Zürich, Switzerland, March 1991. See also <http://cbrg.inf.ethz.ch/>.

[Fielding 94]
Fielding, Roy T. Maintaining distibuted hypertext infostructures: Welcom to MOMspider's Web. First International Conference on the World-Wide Web, May 1994, CERN, Geneva. Published in Computer Network and ISDN Systems 27 (1994) 193-204.

[Ford et al. 94]
Ford, S. G., Stern, R. C. OmniPort: Integrating Legacy Data into the WWW. Second International Conference on the World-Wide Web, 1994, Chicago. See <http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/CorInfSys/stern/stern-ford.html>.

[Gopher]
Another distributed information system. See <gopher://boombox.micro.umn.edu:70/11/gopher>.

[Grönlund 94]
Grönlund, A. Public computer systems - A challenge for organizational learning. Network Service Conference (NSC'94), November 28-30, 1994, London. Published in Computer Network and ISDN Systems 26 (Suppl. 2 double issue) (1994) S119-S128.

[Hughes 94]
Hughes, K. Getstats. Processes Gopher and W3 server log files. See <http://www.eit.com/software/getstats/getstats.html>.

[HTTP]
The Hypertext Transfer Protocol. See <http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html>.

[Kappe 93]
Kappe, F. Hyper-G: A Distributed Hypermedia System. Proceedings of INET '93, San Francisco, California. See <http://www.iicm.tu-graz.ac.at/>.

[Mauldin et al. 94]
Mauldin, M. L., Leavit, J. R. R. Web-Agent Related Research at the CMT. Proceedings of the ACM Special Interest Group on Networked Information Discovery and Retrieval (SIGNIDR-94). August 1994. See <http://lycos.cs.cmu.edu/>.

[NCSA]
National Center for Supercomputing Applications. The NCSAMosaic Homepage. See <http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html>.

[Perrochon et al. 95a]
Perrochon, L., Fischer R. IDLE: Unified W3-Access to Interactive Servers. The Third International World-Wide Web Conference 1995 (WWW'95), Darmstadt, April 1995. Computer Networks and ISDN Systems 27 (1995) 927-938. See <http://www.inf.ethz.ch/department/IS/ea/tsp/>.

[Perrochon et al. 95b]
Perrochon, L., Büchel, M. M. Building a W3-Kiosk with Existing Products. Workshop World-Wide Web Based Online Kiosk Systems of the Third International Conference on the World-Wide Web (WWW'95), Darmstadt, April 1995.

[Pinkerton 94]
Pinkerton, B. Finding What People Want: Experiences with the WebCrawler. Second International Conference on the World-Wide Web, 1994, Chicago. See <http://webcrawler.cs.washington.edu/WebCrawler/WebQuery.html>.

[Richmond]
Richmond, A. CyberWeb's Authoring Style Guide. See <http://www.charm.net/~web/Style/>.

[Ronchetti 95]
Ronchetti, M. Face Lift: using WWW technology for an external reengineering of old applications .Poster at the Third International World-Wide Web Conference 1995 (WWW'95), Darmstadt, April 1995. See <http://www.inf.unitn.it/~ronchet/CBT>.

[Sherwood 94]
Sherwood, K. D. Technical and Sociological Aspects of Developping Campus-Wide Webs: UIUC College of Engineering. Second International Conference on the World-Wide Web, 1994, Chicago. See <http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Campus.Infosys/sherwood/sherwood.html>.

[Tilton 94]
Tilton, J. What is an Infostructure? See <http://www.willamette.edu:80/~jtilton/info-p.html>.

[W3Tools]
Tools for W3 provider. See <http://info.cern.ch/hypertext/WWW/Tools/Overview.html>.

[WHO's Online]
A collective experiment towards a non-commercial, decentralized HYPERbiographical database of people on the Internet. See <http://www.ictp.trieste.it/Canessa/whoiswho.html>.

[Yahoo]
A virtual library. See <http://www.yahoo.com/>.