[Next] [Previous] [Up] [Top] [Contents] [Search]

1 - Introduction

1.1 - The Web as a Set of Infostructures


Currently more and more documents on the Web are part of an infostructure [1] - an information resource with a specifically designed structure. Automatic document converters such as WebMaker [2] (a Frame to HTML converter) and LaTeX2HTML [3] take a master, non-HTML document and produce a set of HTML pages from it.

This process can create large infostructures easily and effectively, due to the extra navigation information it can automatically generate. Web specific information may be included in the non-HTML master document by adding special mark-up to it that signals the converter to add information into the HTML documents that it generates. For WebLinker this information consists of links to external Web documents and labels signifying places that other documents can link to. Modifications of such infostructures requires only changes to the non-HTML master document and a repetition of the document generation process.

Updating a local infostructure presents two possible problems for remote documents that link to it:

  1. If it changes structure, a link into it may no longer point to the same place.

  2. If it changes location, all links pointing to it break.

The first may be solved by having the maintainer of the remote infostructure traverse the local infostructure using a browser, finding the new URL for the place he wants to link to, and replacing the broken link. The second is usually solved by the adding in a redirect rule at the local server.

Of course, both these problems apply to the local infostructure when a remote infostructure changes.

MOMSpider [4] presents a method to detect these problems in that it can check infostructures for broken or redirected links. It can then mail the maintainer signalling that there may be problems with the infostructure.

This approach means a maintainer of an infostructure must update his infostructure every time something changes in a remote infostructure that he links to. It is more efficient and logical for responsibility of the remote infostructure to reside with the maintainer of the remote infostructure. This is impossible with current methods.

Consider the two infostructures in Figure 1: a local infostructure called FARMING residing on machine www.agri.org, for which we are the maintainer, and a remote infostructure Games on the machine www.games.com into which there are hypertext links from our infostructure.

Figure 1: An example of two infostructures residing on different machines with hypertext links between them. Note that an infostructure maintainer may have no knowledge that another document links to his, such as link c.

Now, assume that we change our infostructure FARMING. In doing so, both links c & d would break. Now suppose we do not even know that people are linking to our infostructure. We have no way of notifying the maintainer of these remote documents that we have changed something: they will only discover the change when they next try to traverse that link.


WebLinker@ptsun00.cern.ch - 16 SEP 94
[Next] [Previous] [Up] [Top] [Contents] [Search]

Generated with WebMaker