reto's vision of a FutureWeb V1.0-01

despite - or because - of its tremendous growth, the World Wide Web suffers from one big problem: navigation in hyperspace.

in the current implementation of the Web with URLs as THE mechanism to link documents, the "lost in hyperspace" problem is inherit. there is no way to get information about document contents and links efficiently.

the only reasonable approach i have seen so far is Hyper-G. in Hyper-G, the link information is stored in a database and therefore is separated from the HTML document. but i would like to go one step further: the database should not only store information about the links, but also some metadata about the document itself (e.g. author, title, keywords and so on, as it is done in library retrieval systems). let me use the expression FutureWeb for such a system. it is mandatory that an editing tool would help to provide the information needed for each document. the whole system must not relay on manually feed databases.

FutureWeb broswers must be capable of querying such a database, so that users can find documents about particular subjects. as a next step, the databases of the various FutureWeb servers must be linked together. this would allow world wide queries regardless of where a document is actually stored.
because there are thousands of WWW servers around, it would be impossible to distribute each query to each server. therefore, i envision specialized FutureWeb hubs which continually collect information provided by FutureWeb servers and store it in their databases. there might be five to ten FutureWeb hubs world wide. each FutureWeb server sends its update information to at least one FutureWeb Hub. the FutureWeb hubs in turn update each other's database periodically.

FutureWeb clients would be configured to send their queries to a FutureWeb Hub. more precisely, each FutureWeb client should have a list of FutureWeb hubs where it can send queries to, a scheme very similar to the Domain Name Service (DNS). to reduce the load of the FutureWeb hubs and network traffic, it might be reasonable to introduce two scopes of queries, "local" and "world wide". "local" queries would be handled by a configurable list of FutureWeb servers, while only "world wide" queries would be answered by FutureWeb hubs.

back to WWW95 main document

vision_of_FutureWeb / 27-jan-1999 (ra) / reto ambühler
!!! Dieses Dokument stammt aus dem ETH Web-Archiv und wird nicht mehr gepflegt !!!
!!! This document is stored in the ETH Web archive and is no longer maintained !!!