Logic Programming with the World-Wide Web

Seng Wai Loke and Andrew Davison
Department of Computer Science
The University of Melbourne
Parkville, Victoria 3052
Australia
Tel: +613 9344 {9170,9172}
E-mail: {swloke,ad}@cs.mu.oz.au

ABSTRACT

We introduce LogicWeb, an integration of structured logic programming and the World-Wide Web. We show how LogicWeb enables programmable behaviour and state to be incorporated into Web pages, allowing them to be viewed as modules or objects with state. LogicWeb renders a Web page as a live information entity, able to determine its own response to user queries, and modify the behaviour of hyperlinks. This amalgamation of logic and the Web makes it possible to reason with Web pages, state relationships between pages, and dynamically generate pages. A prototype system is described, which extends Mosaic with LogicWeb capabilities using the Common Client Interface. In addition, we outline a client-based search tool written with LogicWeb and compare it with an existing package.

Keywords:

World-Wide Web, structured logic programming, mobile code, Mosaic, Common Client Interface, Prolog

INTRODUCTION

The World-Wide Web (WWW), or `The Web', is a distributed network of information that is spreading over a growing number of Internet sites. The WWW is accessible via browser programs, such as Mosaic developed at the National Center for Supercomputing Applications (NCSA). Mosaic can fetch documents written in the Hypertext Markup Language (HTML) from information servers distributed globally and display them locally, providing a hypertext interface to the WWW. HTML is a collection of markup tags that define the various components of a Web document which may consist, for example, of in-line images and text in various type-styles. A hypertext document contains highlighted phrases called hyperlinks which are links to text in other documents or resources in the Web. Each link has a Uniform Resource Locator (URL) which is the unique address of the document being referenced.

One variation is a Web page with a HTML form which upon submission triggers the execution of a specified script on some server. However, the script is not part of the Web page, and the script and Web page are loosely coupled.

Web pages written in standard HTML do not have a notion of programmable behaviour, that is: We extend the Web page notion by augmenting it with the logic programming (LP) paradigm extended with the structuring concepts of modularity and object-orientation. We establish a correspondence between structured logic programs and Web pages, which essentially maps a Web page to a LP module consisting of facts and rules. A Web page becomes a live information entity that can determine its own response to queries. Queries naturally map to goal evaluations.

We employ the well-established meta-level notions of LP [3][4] to allow modules, and hence Web pages, to be treated as first-class objects in programs. This enables a page to reason about itself and other pages, access and manipulate pages, and define arbitrary relationships between pages.

LP is well suited for specifying relationships between objects, and comes with the advantages of declarativeness, pattern matching via unification, and search via backtracking. The existing work on modularity and object-orientation in LP provides a good starting point for finding a precise semantics for this model.

We term this amalgamation of the WWW with LP LogicWeb.

This paper is organized as follows. First, the modeling of the WWW by the structured LP paradigm is described. Then, an overview of a prototype LogicWeb system is given. It is implemented using NCSA Mosaic, the Common Client Interface (CCI), and SWI-Prolog [21] extended with CCI-related predicates. Thereafter, an example application is presented. In relation to the example, the notion of a Web page as an object with state is discussed. Following this, we discuss related work, and finally, we conclude with possible directions for future work.

THE LP VIEW OF THE WWW

Modeling Web Pages

A Web page with the URL <URL> corresponds to a LP module whose name is the term m_id(<URL>). The module contains at least the following facts, my_id(<URL>) and h_text(<HTML source>), the first of which stores the URL of the page, and the second the HTML source of the page. This is sufficient to model ordinary Web pages. Besides these two facts, a Web page can contain other clauses that define the behaviour of the page and can be used to process user queries. These extra clauses are termed live clauses. The module corresponding to a Web page then consists of the two facts above and live clauses.

The Web page as LP module notion can be extended so that a page can be viewed as an object with state. However, we shall utilise the simpler correspondence until the `Using the Notion of State' section.

Programming with Web Pages

Live clauses may contain references to other Web pages. For example, a clause may contain the goal:

m_id(<URL>)#>goal

This states that the goal goal is to be proven in the module m_id(<URL>) (the module corresponding to the Web page with the URL <URL>) rather than in the current module. Referencing the module via the #> operator results in the corresponding Web page being implicitly fetched (if it has not already been) and installed (in a sense that will be made clear in the next section) before the goal is executed in the module. In other words, transparent retrieval and loading of the module is carried out prior to goal evaluation. Another operator, :>, used in the same way as #>, fails if the page is not already installed.

Web page URLs can appear in predicates in the same way as any term. For instance, the following predicate can be used to define relationships between pairs of pages:

rel(<URL1>,<URL2>)

A code fragment illustrates the above ideas in an application that fetches images of a specified type. Image references are stored in part/3 facts such as:

part(cat,"animal","<img src=""http://www.cs.mu.oz.au/~swloke/dfg/pussi.gif"" alt="""">").

The URLs of the pages storing these part/3 details are recorded in pic_doc/1 facts. A Web page animals.html contains the following live clauses:


pic_doc("http://www.cs.mu.oz.au/~swloke/pic1.html").
pic_doc("http://www.cs.mu.oz.au/~swloke/pic2.html").

pics(Type) :-
setof(Id,pic_doc(Id),Ids),
get_images(Ids,Type,[],Images),
make_page(Images,Type,Page),
display_data(Page).

get_images([],_,Images,Images).
get_images([Id|Ids],Type,Is,Is2) :-
setof(Image,Label^(m_id(Id)#>part(Label,Type,Image)),Images),
append(Is,Images,Is1),
get_images(Ids,Type,Is1,Is2).

.../* more code */...
A query to display all animal images is expressed as the goal pics("animal"). When applied to the animals.html page, it causes URLs to be collected from the pic_doc/1 facts. get_images/4 then collects animal images from the part/3 facts in the modules addressed by the URLs. make_page/3 (definition not given) constructs a HTML document from the image data. display_data/1 displays the resulting HTML page using Mosaic. The use of the operator #> to retrieve part/3 facts from different Web pages should be noted. This example also demonstrates the LogicWeb ability to combine components of different pages into a new page.

SYSTEM OVERVIEW

In this section, we describe a prototype system supporting the ideas detailed above, and some others such as visibility control. An explanation of the behavioural aspects of LogicWeb pages is also given. In particular, the effects of a hyperlink click, goal execution, and the reference operator #>.

Architecture

The system consists of three main components, as depicted in Figure 1:


Figure 1: An overview of the system components and data-flows (arrows) between them.

The system consists of the above three communicating processes. Both WWWmain and Prolog communicate with Mosaic via CCI (using socket connections), while the communication between WWWmain and Prolog utilises pipes. WWWmain and Prolog share a socket connection to Mosaic, and the API of the CCI is slightly modified to cater for this.

Instead of embedding a logic engine within Mosaic, CCI is used. This allows the capabilities of Mosaic to be extended without modifying Mosaic internally.

The following sections describe the dynamics of the system in more detail.

User Interaction and Visibility Control

The user may interact with the Web page in two ways: either by clicking on a hyperlink, or by typing a goal into a form appended by the system to the page when it is displayed. For example, the goal pics("animal") of the example given earlier can be typed into the form displayed with the animals.html page, resulting in the execution of the corresponding Prolog code in the module.

Borrowing visibility notions of modules similar to those in [16], we use visible/1 and export/1 declarations to provide access control to predicates. Only goals declared with these two predicates can be executed via a form. For example, the animals.html module includes the facts visible(pics(_)) and export(pics(_)).

This mechanism restricts the goals that can be executed, in line with concepts of software engineering, the interface, and information hiding. Predicates declared with the export/1 fact, but not the visible/1 fact, can be referenced (via the #> operator) but not called from a form. This allows a module with non-visible but exported predicates to serve as a resources module for other modules, but be protected from direct execution via the forms interface.

Execution Sequences

The operational meaning of user actions and the #> operator are presented below.

Goal entry.

A goal is processed using the following steps:
  1. Since a form is used to input a query, a Common Gateway Interface (CGI) script receives the query and constructs a canonical goal. This consists of the user-entered goal and the URL of the module in which the goal is to be executed (i.e. the currently displayed Web page).
  2. The canonical goal is redirected (via Mosaic and WWWmain) to Prolog for execution.
Note that the CGI script does not determine the response to the goal in any way. Processing of goals by Prolog occurs entirely at the client-end, reducing the load on the server. This client-side processing is facilitated by the use of CCI.

A mouse-click on a hyperlink.

The following sequence of actions is triggered:
  1. The referenced page is fetched by Mosaic and sent to Prolog via WWWmain.
  2. This page is installed in Prolog as a new module consisting of my_id/1 and h_text/1 facts together with its live clauses. The module is added to the Prolog runtime environment. LogicWeb looks for live clauses in a Web page between HTML <code> tags. The part of the HTML document within <code> tags is separated out and stored as Prolog code rather than as a part of the h_text/1 fact.
  3. The part of the page asserted in the h_text/1 fact is displayed after a forms interface has been added to it.
A click on a hyperlink can be viewed as the goal:

m_id(<URL>)#>display_h_text

display_h_text/0 is a predicate which displays the contents of the h_text/1 fact using Mosaic.

A reference to a goal inside Prolog code.

This corresponds to the goal:

m_id(<URL>)#>goal

The result of the above call is as follows:
  1. If the page associated with the URL has not already been installed, a request for the page is sent from Prolog to Mosaic.
  2. The Web page is fetched by Mosaic and installed by Prolog.
  3. Prolog executes the goal in the page.

The Meta-interpreter

The syntax of live clauses has been kept as close as possible to that of ordinary Prolog. The meta-interpreter, demo/2, is based on ideas introduced in [3][4], but has been extended to handle setof/3, bagof/3 and not/1 involving goals in modules.

The clauses of a module are stored in the form:

m_id(<URL>)::(<clause>)

Executing a goal in a module corresponds to the call demo(M,Goal), where M is a term of the form m_id(<URL>). The demo/2 clauses for the operators #> and :> are:


demo(M,T#>G) :-
T=m_id(URL),
web_load_doc(URL),
demo(M,T:>G).

demo(M,T:>G) :-
chk_exported(M,T,G),
demo(T,G).

The predicate web_load_doc/1 fetches the Web page of the given URL and installs it, and the predicate
chk_exported(M,T,G) checks that the goal G has been declared with an export/1 fact in the module T or that M=T.

Security

Security is an issue when code is brought in from a foreign server and executed locally. Fortunately, the use of a meta-interpreter for executing LogicWeb code provides control over every goal that is executed. For instance, the permitted operating system related tasks are restricted.

A PAGE SEARCHER APPLICATION

In this section, an example application is discussed in some detail. We also introduce a notion of state for modules.

A large number of sites offer search engines based on indexes built by robots (e.g. the World-Wide Web Worm, NorthStar, JumpStation and WebCrawler). Our application is different in that it searches for pages using LP rules to guide and constrain the search, and to define how `interesting' pages are related. The use of LP greatly simplifies the coding task due to the ease of defining relationships between entities (Web pages in this case) and the ability to express complex information about pages (e.g. their `knowledge' about different topics) in a high-level fashion.

The algorithm is coded as live clauses in the Web page, pgssearch.html, which is shown in Figure 2.


Figure 2: pgssearch.html is shown. The form at the bottom of the page is appended by the system.

The format of the goal which invokes the application is:

pgs_search(<Keywordlist>,<PassScore>,<NumOfPgs>)

The program selects Web pages of interest by examining located_at/2 facts in pgssearch.html, of the form:

located_at(<keyword>,<URL>)

The search follows the links to other pages in a breadth-first manner, scoring each page based on its relevance to the keywords list. The program keeps track of the visited pages and never rescores any page. The result of the search is a display of the page title (with its URL tag) and its score which must be above the pass score. The maximum number of pages displayed is specified by <NumOfPgs>.

The relevance measure of a page is the number of mentions of the keywords from the initial list, or of keywords related to a keyword in the original list. This notion of `relatedness' is defined using related/2 facts.

Each visited page is parsed for its link information, which is stored as facts of the form link(<label>,<URL>). If the label of a link contains a keyword, the URL is added to the end of the list of Web pages to visit (thus effecting breadth-first search). Also, the located_at/2 facts of relevant pages are used as pointers to other pages to visit.

This example demonstrates a number of LogicWeb features: It is interesting to note that as the set of related/2 facts grows as new pages are found, previously unrelated keywords can become related. This behaviour is captured by the following predicate, path_related/3, which infers if two keywords are related.


path_related(X,Y,VisitedNodes) :-
M:>related(X,Y),
not(member(Y,VisitedNodes)).

path_related(X,Z,VisitedNodes) :-
M:>related(X,Y),
not(member(Y,VisitedNodes)),
path_related(Y,Z,[Y|VisitedNodes]).

The related/2 facts form a directed graph so that two keywords are related if there is a path between them. Note that M is instantiated to different module identifiers upon backtracking, allowing a search through all the existing related/2 facts. As the set of related/2 facts grow, a call to path_related/3 can succeed even if an earlier call with the same arguments failed.

After sufficient pages have been found, a page is constructed from the results and displayed. This makes use of predicates which can extract particular strings from a page (e.g. the title), and others which concatenate strings together. For instance, the predicates build_head/2, build_body/3 and build_whole/3 take strings as arguments and generate appropriate HTML code. For example:

build_head("Interesting URLs",Head)

causes Head to be instantiated to the string:

"HEAD\n<TITLE>Interesting URLs</TITLE>\n</HEAD>"

Figure 3 shows the result of the search with the goal:

pgs_search(["logic","programming"],3,10)

starting from the page:

http://www.comlab.ox.ac.uk/archive/logic-prog.html.


Figure 3: Result of the query pgs_search(["logic","programming"],3,10).

Using the Notion of State

Viewing a Web page as an object with state, rather than as a module, enables information associated with a Web page to be updated. We have adopted work by Brogi and Turini [8] on state in LP, to equate a Web page with an object consisting of two theories: the module (as before) and its state. The module represents non-mutable fetched information, while the state is a mutable theory, initially empty, that can be updated by asserts and retracts. The demo/2 predicate has been extended with clauses that handle clause insertions and deletions into the state, and clauses that attempt to prove goals using the state and the module. The state is associated with the module (whose identifier is m_id(<URL>)) via the use of the same URL, but with a different functor, s_p(<URL>). Clauses are added to the state in the form:

s_p(<URL>)::(<clause>)

In the searcher example, previous search results can be stored in the state associated with pgssearch.html, enabling later queries to make use of the information without having to regenerate it. For example, a document need not be reparsed for its link/2 facts when reused.

A drawback of extra-logical features such as assert/1 and retract/1 are their semantics. However, the operational semantics for state update operations in [8] views such operations as meta-level transformations of a given knowledge base into a new one.

Comparison with Another Client-Based Search Tool

The LogicWeb page searcher is similar to a more comprehensive client-based stand-alone information retrieval tool, Fish-Search [9][10]. Fish-Search carries out automated navigation, and is implemented in C on top of XMosaic 2.4. It starts with a user-entered URL, or with the user's hotlist, and follows links in a depth-first manner using search keywords or a regular expression as the search criteria.

Some of the heuristics used include: (1) after following a number of links in a given direction without finding relevant nodes, the search stops going in that direction; (2) links in relevant documents are traversed first before those of less relevant ones; (3) links to documents in different sites are preferred.

Our search algorithm is simpler than the one employed by Fish-Search, but the Fish-Search heuristics could be easily utilised. LogicWeb's use of LP has a number of benefits. Firstly, it is straightforward to define versatile search algorithms, due to the ease of specifying relationships between pages. It is similarly easy to add guiding knowledge to the search by specifying information about pages, such as located_at/2 and related/2 facts. This information can be dynamically updated during search and so modify the search accordingly.

RELATED WORK

`Mobile Code' Systems

A page fetched from a server using LogicWeb can be viewed as a program module imported across the network. Thus, it is similar to `mobile code' systems in which code is transmitted across the network and executed at its destination site.

An example is Telescript, in which complete programs called agents are transported across the network and interact with other agents representing services at their destination hosts. A feature of this approach, which distinguishes it from ours, is that agents are executed at the destination, not at the user's site.

The following systems are closer to our approach, in the sense that code is fetched from the server and executed on the client side.

Dynamic Documents [13] are Tcl-scripts treated as a new MIME document type, and are executed by a version of Mosaic modified to include a Tcl-interpreter. Execution of a dynamic document can result in the generation of a page for display, or the launching of an application (with its own interface window) at the client end. Clicking a hyperlink in LogicWeb is equivalent to executing the goal:

m_id(<URL>)#>display_h_text

which loads the module and displays the text. However, this behaviour can be generalized so that any program can be executed when a page is retrieved. Also, our approach does not require the source code of Mosaic to be modified.

HotJava is a Web browser that can process pages which include executable code. Embedded programs (called applets) are written in the object-oriented Java language.

Our approach differs from that of HotJava (where applets are components of a page) in that the entire Web page is treated as a program module.

In LogicWeb, accessing text and executing code are done in a simple and uniform way, via goal evaluation. In Java, HTML text is accessed using library procedures which differs from the way applets are processed.

LogicWeb uses goal evaluation to model the intent of a hyperlink click. In HotJava, the semantics of hyperlinks remain as in ordinary Web pages.

LogicWeb's use of LP allows arbitrary relationships between Web pages to be easily defined, and utilised. Moreover, the use of structured LP and meta-level notions provide a semantics for the access and manipulation of Web pages (as theories), not present with Java.

The Hush (Hyper Utility Shell) [20] environment provides a Web widget as part of applications. It also allows Tcl-scripts to be embedded in HTML pages providing capabilities similar to those of HotJava applets. Hence, LogicWeb can be compared with Hush in a similar way to with HotJava.

Sato [18] presents a way to dynamically modify the manner in which Web information is retrieved and presented. It involves encoding server's suggestions as LISP programs that generate HTML pages. The programs are evaluated in a user context which may contain representations of user knowledge and earlier server suggestions. Functionality that can be encoded include: inclusion of other pages, composition of HTML pages, determination of the presentation style of a document, and hints on pages to examine next.

Server suggestion programs are not part of the page and are treated as a separate kind of document. This is different from LogicWeb which associates a Web page with its own code, enabling the page to define its own responses to queries. LogicWeb also allows a page to determine the meaning of its hyperlinks.

As suggested in [18], one use of the user context (if defined as the set of visited pages) is as an aid for navigation in hyper-space. This notion is also present in LogicWeb, as the set of modules (pages) already installed into the Prolog environment.

Structured LP

The #> operator is similar to operators used in various extensions of LP with modularity [2][6][16][17]. However, these operators have a notion of a context attached to them, usually as a list of modules. When a new module is accessed, it is added to the context and the goal is proved using the new context.

The LogicWeb u:>goal operation, for some module u, corresponds to the context switch operation in Contextual Logic Programming [17]. The goal is proved in the specified module regardless of the current module or context:

u |- goal
-------------
v |- u:>goal

u:>goal also corresponds to the operation [u]goal in [2], where [u] is a modal operator.

Work in [5][7] on composition operators for logic theories suggests useful extensions to LogicWeb. For instance, an operator composing together two Web pages, v and u. A goal could then be proven in the composition, rather than in the new module alone:

v * u |- goal
-------------
v |- u*>goal

* denotes the composition operator between modules, and *>, a new reference operator. Alternatively, viewing v as a list of modules (the current context), * could add the new module to the list, in the spirit of [6][17].

Artificial Intelligence (AI) and Hypertext

The integration of structured entities (i.e. AI frames and semantic nets) and hypertext in [14][19] has been used for building knowledge-based systems. Hypertext nodes are represented by frames, and additional functionality, such as guided tours, is provided.

In [1], a hypermedia system architecture is described which uses knowledge about information contents to aid hypermedia presentation and navigation.

In both the above approaches, type hierarchies are defined for hypertext nodes and links, and link activation is compared to the object-oriented programming notion of message-passing. In other words, computation is associated with a link activation.

LogicWeb differs from this work in the following ways:

We have not employed the notion of types. Considering the variety and size of the Web, typing is an intriguing problem.

CONCLUSIONS AND FUTURE WORK

We have presented LogicWeb, an amalgamation of WWW notions with structured LP. Existing applications demonstrate the key ideas of LogicWeb:

Mapping Web pages to LP objects (or modules) enables structured LP ideas to be used in programming. For example, the page searcher application demonstrates LP techniques for representing search criteria, page relationships, and page content. In addition, algorithms can be expressed in a declarative manner and rapid prototyping is facilitated.

LogicWeb is still being developed, and much work is still required.

It will soon be possible to associate a goal with a hyperlink click, which will enable the current page to determine the outcome of each of its hyperlinks. For example, instead of simply having the entire page displayed as the link is followed, a summary of the fetched document could be generated and displayed, or the document could be modified before being displayed. Automatic redirection of URL dereferencing will be possible, using predicates that associate alternative URLs with the chosen URL. The destination page will also be able to influence the links leading to it. For instance, the displayed page may be the result of goals executed in both the source and destination pages connected by the hyperlink.

The page searcher application demonstrates the programming possibilities inherent in LogicWeb. However, a more effective search tool would combine LogicWeb with a conventional search engine, such as Lycos. LogicWeb would be used to specify high-level search and filtering strategies for Lycos. This approach is being investigated.

Guided tours are another application area under consideration. Guided tours can help reduce the navigation problems with hypertext, since the sequence of pages to be visited are suggested by the tour. A guided tour based on LogicWeb pages could be much more flexible since the choice points in the tour could be represented by alternative link/2-type facts in each page. LogicWeb could also record the path (or paths) explored by a user, and modify the paths yet to be followed.

We plan to develop further LogicWeb applications based on the literature concerning the Dexter Hypertext Reference Model [11], the Amsterdam Hypermedia Model [12] and `mobile code' systems like those detailed in the previous section.

Another avenue for research is to examine how Web pages may benefit from having their own inference engines instead of a common one, as at present. A Web page would then correspond to the notion of a world [15].

The prototype implementation presented provides a testbed for LogicWeb functionality. Further work is needed in establishing libraries of predicates for constructing, processing, and parsing pages.

Installed Web pages are never reinstalled, which raises the issue of how to update installed pages. The cache developed for Fish-Search provides a starting point for research.

We have not considered the issue of persistent information across browser sessions. In the current implementation, installed modules persist only within a session.

We plan to investigate how context and composition operators can be used in LogicWeb.

We will be developing a semantics for our model. The extensive literature on modularity in logic programming and the composition of logic theories, such as those mentioned in the previous sections, will certainly help.

REFERENCES

[1] Arents, H.C., and Bogaerts, W.F.L. Towards an Architecture for Third-Order Hypermedia Systems. Hypermedia 3, 2 (1991), 133-150.

[2] Baldoni, M., Giordano, L., and Martelli, A. A Multimodal Logic to Define Modules in Logic Programming. In Proceedings of the International Symposium on Logic Programming, D. Miller, Ed. MIT Press, 1993, pp. 473-487.

[3] Bowen, K. Meta-Level Programming and Knowledge Representation. New Generation Computing (1985), 359-383.

[4] Bowen, K., and Kowalski, R. Amalgamating Language and Metalanguage in Logic Programming. K. Clark and S. Tarnlund, Eds. Academic Press, 1982, pp. 153-172.

[5] Brogi, A. Program Construction in Computational Logic. PhD thesis, Universita di Pisa-Genova-Udine, 1993.

[6] Brogi, A., Lamma, E., and Mello, P. A General Framework for Structuring Logic Programs. Tech. Rep., Dipartimento di Matematica e Informatica, Universita di Udine. C.N.R., TR 04-90-RR, Maggie 1990.

[7] Brogi, A., Mancarella, P., Pedreschi, D., and Turini, F. Modular Logic Programming. ACM Transactions on Programming Languages and Systems 16, 4 (July 1994).

[8] Brogi, A., and Turini, F. A Metalogic for State Oriented Programming. In Extensions of Logic Programming, Lecture Notes in Artificial Intelligence 660, E. Lamma and P. Mello, Eds. Springer-Verlag,1993, pp. 187-204.

[9] De Bra, P., and Post, R. Searching for Arbitrary Information in the WWW: the Fish-Search for Mosaic. 2nd International World-Wide Web Conference, <http://www.ncsa.uiuc.edu/SDG/IT94/\\Proceedings/Searching/debra/article.html>.

[10] De Bra, P., and Post, R. Information Retrieval in the World-Wide Web: Making client-based searching feasible. Computer Networks and ISDN Systems (1994), 183-192.

[11] Halasz, F., and Schwartz, M. The Dexter Hypertext Reference Model. Communications of the ACM 37, 2 (February 1994), 30-39.

[12] Hardman, L., Bulterman, D., and Van Rossum, G. The Amsterdam Hypermedia Model: Adding Time and Context to the Dexter Model. Communications of the ACM 37, 2 (February 1994), 50-62.

[13] Kaashoek, M., Pinckney, T., and Tauber, J. Dynamic Documents: Extensibility and Adaptability in the World-Wide Web. 2nd International World-Wide Web Conference, <http://www.ncsa.uiuc.edu/SDG/IT94/\\Proceedings/DDay/pinckney/dd.html>.

[14] Kaindl, H., and Snaprud, M. Hypertext and Structured Object Representation: A Unifying View. In Proceedings of the 3rd. ACM Conference on Hypertext (Hypertext '91). ACM Press, 1991, pp. 345-358.

[15] Kauffmann, H., and Crumbach, A. MULTILOG: Multiple Worlds in Logic Programming. In Advances in Artificial Intelligence, B. D. Boulay, D. Hogg, and L. Steels, Eds. Elsevier Science, 1987, pp. 233-247.

[16] Mello, P., Natali, A., and Ruggieri, C. Logic Programming in a Software Engineering Perspective. In Proceedings of the North American Conference on Logic Programming, E. Lusk and R. Overbeek, Eds. MIT Press, 1989, pp. 441-458.

[17] Monteiro, L., and Porto, A. A Language for Contextual Logic Programming. In Logic Programming Languages: Constraints, Functions and Objects, K. Apt, J. de Baldoer, and J. Rutter, Eds. MIT Press, 1993, pp. 115-147.

[18] Sato, S. Dynamic Rewriting of HTML Documents. 1st International World-Wide Web Conference, <http://www.elsevier.nl/cgi-bin/query/\\WWW94/FinalProgramme.html?sato>.

[19] Snaprud, M., and Kaindl, H. Types and Inheritance in Hypertext. International Journal of Human-Computer Studies 41 (1994), 223-241.

[20] Van Doorn, M., and Eliens, A. Integrating Applications and the World-Wide Web. Computer Networks and ISDN Systems (1995), 1105-1111.

[21] Wielemaker, J. SWI-Prolog 2.0 Reference Manual. Tech. rep., University of Amsterdam, Department of Social Sciences Informatics(SWI), April 1995.

Footnotes

1. A frame consists of attributes (slots) and methods (procedures).

Converted with the help of latex2html on Tue May 14 12:00:26 EST 1996