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 e-mail: fswloke,
[email protected] August 1995
Abstract
tributed globally and display them locally, providing a hypertext interface to the WWW. HTML is a collection of markup tags that de ne 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 (URL2 ) 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 speci ed 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 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.
The semantics of a hyperlink click is xed a page is simply fetched and displayed. The page containing the clicked hyperlink and the page referenced have no say in the response to the dereferencing of the link. Moreover, relationships between pages are con ned to those established by hyperlinks.
A Web page cannot process queries more general than clicks on hyperlinks. These queries should be handled by the page itself and/or related pages.
There is currently no way for a page to reason
1 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 (HTML1 ) from information servers dis1 http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
2 http://www.w3.org/hypertext/WWW/Addressing/Addressing.html
1
about other pages by collecting and manipu- my id() and h text(), the lating data from them or itself. rst of which stores the URL of the page, and the second the HTML source of the page. This is suWe extend the Web page notion by augmenting cient to model ordinary Web pages. Besides these it with the logic programming (LP) paradigm ex- two facts, a Web page can contain other clauses tended with the structuring concepts of modularity that de ne the behaviour of the page and can be and object-orientation. We establish a correspon- used to process user queries. These extra clauses dence between structured logic programs and Web are termed live clauses. The module corresponding pages, which essentially maps a Web page to a LP to a Web page then consists of the two facts above module consisting of facts and rules. A Web page and live clauses. becomes a live information entity that can deter- The Web page as LP module notion can be exmine its own response to queries. Queries naturally tended so that a page can be viewed as an object map to goal evaluations. with state. However, we shall utilise the simpler We employ the well-established meta-level no- correspondence until x4. tions of LP [2, 3] to allow modules, and hence Web pages, to be treated as rst-class objects in programs. This enables a page to reason about itself 2.2 Programming with Web Pages and other pages, access and manipulate pages, and Live clauses may contain references to other Web de ne arbitrary relationships between pages. LP is well suited for specifying relationships be- pages. For example, a clause may contain the goal: tween objects, and comes with the advantages of m id()#>goal declarativeness, pattern matching via uni cation, and search via backtracking. The existing work on The above states that the goal goal is to be proven modularity and object-orientation in LP provides a in the module m id() (the module corregood starting point for nding a precise semantics sponding to the Web page with the URL ) for this model. rather than in the current module. Referencing the We term this amalgamation of the WWW with module via the #> operator results in the correLP LogicWeb. sponding Web page being implicitly fetched (if it This paper is organized as follows. x2 describes has not already been) and installed (in a sense that the modeling of the WWW by the structured LP will be made clear in the next section) before the paradigm. An overview of a prototype LogicWeb goal is executed in the module. In other words, system is given in x3. It is implemented us- transparent retrieval and loading of the module is ing NCSA Mosaic, the Common Client Interface carried out prior to goal evaluation. Another op(CCI3 ), and SWI-Prolog [20] extended with CCI- erator, :>, used in the same way as #>, fails if the related predicates. In x4, an example application is page is not already installed. presented. In relation to the example, the notion Web page URLs can appear in predicates in the of a Web page as an object with state is discussed. same way as any term. For instance, the predicate x5 discusses related work, and x6 concludes with rel(,) can be used to de ne relapossible directions for future work. tionships between pairs of pages. A code fragment illustrates the above ideas in an application that fetches images of a speci ed type. Image references are stored in part/3 facts such as:
2 The LP View of the WWW
2.1 Modeling Web Pages
part(cat,"animal", "
").
A Web page with the URL corresponds to a LP module whose name is the term m id(). The module contains at least the following facts, The URLs of the pages storing these part/3 de3 http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/tails are recorded in pic doc/1 facts. A Web page CCI/cci-spec.html animals.html contains the following live clauses: 2
Mosaic. This browser resolves URLs, accesses documents requested by LogicWeb, and displays documents generated during the execution of LogicWeb programs. Prolog. SWI-Prolog 2.0 provides the logic pics(Type) :engine, and has been extended with foreign setof(Id,pic_doc(Id),Ids), functions written in C using the Application get_images(Ids,Type,[],Images), Programmer's Interface (API) of CCI. These make_page(Images,Type,Page), functions enable the Prolog process to commudisplay_data(Page). nicate with Mosaic to fetch pages and to display them. There are also predicates to hanget_images([],_,Images,Images). dle in-coming goals, to build pages, to parse get_images([Id|Ids],Type,Is,Is2) :them (in order to collect data) and code for setof(Image, loading the live clauses of the pages. A metaLabel^(m_id(Id)#>part(Label,Type,Image)), interpreter, described further in x3.4, executes Images), the live clauses . append(Is,Images,Is1), get_images(Ids,Type,Is1,Is2). WWWmain. This C program handles input from Mosaic, such as hyperlink click noti ca.../* more code */... tion or entered goals, and sends goals to Prolog to be executed. A query to display all animal images is expressed as the goal pics("animal"). When applied to the The system consists of the above three commuanimal.html page, it causes URLs to be collected nicating processes. Both WWWmain and Prolog from the pic doc/1 facts. get images/4 then col- communicate with Mosaic via CCI (using socket lects animal images from the part/3 facts in the connections), while the communication between modules addressed by the URLs. make page/3 WWWmain and Prolog utilises pipes. WWWmain (de nition not given) constructs a HTML docu- and Prolog share a socket connection to Mosaic, ment from the image data. display data/1 dis- and the API of the CCI is slightly modi ed to cater plays the resulting HTML page using Mosaic. The for this. use of the operator #> to retrieve part/3 facts from Instead of embedding a logic engine within Modi erent Web pages should be noted. This example saic, CCI is used. This allows the capabilities of also demonstrates the LogicWeb ability to combine Mosaic to be extended without modifying Mosaic components of di erent pages into a new page. In internally. x4, we discuss other LogicWeb capabilities. The following sections describe the dynamics of the system in more detail.
pic_doc("http://www.cs.mu.oz.au/~swloke/pic1.html"). pic_doc("http://www.cs.mu.oz.au/~swloke/pic2.html").
3 System Overview
3.2 User Interaction and Visibility Control
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 e ects of a hyperlink click, goal execution, and the reference operator #>.
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 in x2 can be typed into the form displayed with the animal.html page, resulting in the execution of the corresponding Pro3.1 Architecture log code in the module. The system consists of three main components, as Borrowing visibility notions of modules similar depicted in Figure 1: to those in [14], we use visible/1 and export/1 3
declarations to provide access control to prediis added to the Prolog runtime environment. cates. Only goals declared with these two predLogicWeb looks for live clauses in a Web page icates can be executed via a form. For exambetween HTML
tags. The part of the ple, the animal.html module includes the facts HTML document within tags is sepvisible(pics( )) and export(pics( )). arated out and stored as Prolog code rather than as a part of the h text/1 fact. This mechanism restricts the goals that can be executed, in line with concepts of software engineering, the interface and information hiding. Predi- 3. The part of the page asserted in the h text/1 fact is displayed after a forms interface has cates declared with the export/1 fact, but not the been added to it. visible/1 fact, can be referenced (via the #> operator) but not called from a form. This allows a module with non-visible but exported predi- A click on a hyperlink can be viewed as cates to serve as a resources module for other mod- the goal, m id()#>display h text, where ules, but be protected from direct execution via the display h text/0 is a predicate which displays the contents of the h text/1 fact using Mosaic. forms interface.
A reference to a goal inside Prolog code. A call to m id()#>goal results in the following:
3.3 Execution Sequences
The operational meaning of user actions and the #> operator are presented below.
1. If the page associated with the URL has not already been installed, a request for the page is sent from Prolog to Mosaic.
Goal entry. A goal is processed using the following steps: 1. Since a form is used to input a query, a Common Gateway Interface (CGI4 ) 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 (ie. 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.
2. The Web page is fetched by Mosaic and installed by Prolog. 3. Prolog executes the goal in the page.
3.4 The Meta-interpreter
The syntax of live clauses has been kept as close as possible to that of ordinary Prolog. The metainterpreter, demo/2, is based on ideas introduced in [2, 3], 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()::()
A mouse-click on a hyperlink. The following Executing a goal in a module corresponds to the sequence of actions is triggered:
call demo(M,Goal), where M is a term of the form 1. The referenced page is fetched by Mosaic and m id(). The demo/2 clauses for the operators #> and :> sent to Prolog via WWWmain. are: 2. This page is installed in Prolog as a new module consisting of my id/1 and h text/1 facts demo(M,T#>G) :together with its live clauses. The module T=m_id(URL), web_load_doc(URL), demo(M,T:>G).
CGI is a standard for interfacing external applications with information servers. (http://www.w3.org/hypertext/WWW/CGI/Overview.html) 4
demo(M,T:>G) :chk_exported(M,T,G), demo(T,G).
4
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.
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 speci ed by . 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 de ned using related/2 facts. Each visited page is parsed for its link information, which is stored as facts of the form link(,). 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 e ecting breadth rst 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 shows how Web pages can be accessed and manipulated in the context of goal evaluation and how link traversal can be automated using the #> operator. Parsing a page for link information and subsequently storing the results as link/2 facts is an example of the ability to reason with Web pages. In general, more complex parsing can be carried out, and more complex link relations constructed. Each located at/2 fact establishes a relationship between the page containing it and the page whose URL is an argument of the fact. This indicates how LP can be used to enrich the relationship between pages. 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.
3.5 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.
4 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 o er search engines based on indexes built by robots (e.g. the WorldWide Web Worm, NorthStar, JumpStation and WebCrawler). Our application is di erent in that it searches for pages using LP rules to guide and constrain the search, and to de ne how `interesting' pages are related. The use of LP greatly simpli es the coding task due to the ease of de ning relationships between entities (Web pages in this case) and the ability to express complex information about pages (e.g. their `knowledge' about di erent 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. The format of the goal which invokes the application is: pgs search(,, )
The program selects Web pages of interest by examining located at/2 facts in pgssearch.html, of the form:
path_related(X,Y,VisitedNodes) :M:>related(X,Y), not(member(Y,VisitedNodes)).
located at(,)
The search follows the links to other pages in a breadth- rst manner, scoring each page based on its relevance to the keywords list. The program
path_related(X,Z,VisitedNodes) :M:>related(X,Y),
5
identi er is m id()) via the use of the same URL, but with a di erent functor, s p(). Clauses are added to the state in the form:
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 di erent module identi ers 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 sucient 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:
s p()::()
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 [7] views such operations as meta-level transformations of a given knowledge base into a new one.
build_head("Interesting URLs",Head)
causes Head to be instantiated to the string:
4.2 Comparison with Another Client-Based Search Tool
"\n Interesting URLs\n "
The LogicWeb page searcher is similar to a more comprehensive client-based stand-alone information retrieval tool, Fish-Search [8, 9]. Fish-Search carries out automated navigation, is implemented in C on top of XMosaic 2.4. It starts with a userentered URL, or with the user's hotlist, and follows links in a depth- rst 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 nding relevant nodes, the search stops going in that direction; (2) links in relevant documents are traversed rst before those of less relevant ones; (3) links to documents in di erent 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 bene ts. Firstly, it is straightforward to de ne 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.
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.
4.1 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 [7] 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 6
5 Related Work
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 de ned, 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) [19] 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 [17] 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 di erent from LogicWeb which associates a Web page with its own code, enabling the page to de ne its own responses to queries. LogicWeb also allows a page to determine the meaning of its hyperlinks. As suggested in [17], one use of the user context (if de ned 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.
5.1 `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 [18], 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 [12] are Tcl-scripts treated as a new MIME5 document type, and are executed by a version of Mosaic modi ed to include a Tclinterpreter. 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()#>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 modi ed. HotJava [16] is a Web browser that can process pages which include executable code. Embedded programs (called applets) are written in the objectoriented Java language. Our approach di ers 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 di ers from the way applets are processed.
5.2 Structured LP
The #> operator is similar to operators used in various extensions of LP with modularity [1, 5, 7, 14, 15]. 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 :>goal operation, for some module , corresponds to the context switch oper-
5 Multipurpose Internet Mail Extensions. (http://www.oac.uci.edu/indiv/ehood/MIME/1521/rfc1521ToC.html)
7
ation in Contextual Logic Programming [15]. The It will soon be possible to associate a goal with a goal is proved in the speci ed module regardless of hyperlink click, which will enable the current page the current module or context: to determine the outcome of each of its hyperlinks. For example, instead of simply having the entire ` goal page displayed as the link is followed, a summary
` :> goal of the fetched document could be generated and :>goal also corresponds to the operation []goal displayed, or the document could be modi ed before being displayed. Automatic redirection of URL in [1], where [] is a modal operator. dereferencing will be possible, using predicates that Work in [4, 6] on composition operators for logic associate alternative URLs with the chosen URL. theories suggests useful extensions to LogicWeb. The destination page will also be able to in uence For instance, an operator composing together two the links leading to it. For instance, the displayed Web pages, and . A goal could then be proven page may be the result of goals executed in both in the composition, rather than in the new module the source and destination pages connected by the alone: hyperlink.
` goal Another avenue for research is to examine how
` >goal Web pages may bene t from having their own in denotes the composition operator between mod- ference engines instead of a common one, as at ules, and *>, a new reference operator. Alterna- present. A Web page would then correspond to tively, viewing as a list of modules (the current the notion of a world [13]. context), could add the new module to the list, We plan to develop further LogicWeb applicain the spirit of [5, 15]. tions based on the literature concerning the Dexter Hypertext Reference Model [10], the Amsterdam Hypermedia Model [11] and `mobile code' systems like those detailed in x5.1. The prototype implementation presented in x3 provides a testbed for LogicWeb functionality. FurWe have presented LogicWeb, an amalgamation of ther work is needed in establishing libraries of WWW notions with structured LP. Existing appli- predicates for constructing, processing, and parscations demonstrate the key ideas of LogicWeb: ing pages. Installed Web pages are never reinstalled, which an integration of LP and WWW notions, raises the issue of how to update installed pages. thereby extending the Web page and link The cache developed for Fish-Search provides a mechanisms; starting point for research. We have not considered the issue of persistent the ability to de ne Web pages with local beinformation across browser sessions. In the curhaviour and state; rent implementation, installed modules persist only the ability to carry out meta-level reasoning within a session. upon pages, leading to the modi cation of We plan to investigate how context and composition operators can be used in LogicWeb. pages or the creation of new ones. We will be developing a semantics for our model. Mapping Web pages to LP objects (or modules) The extensive literature on modularity in logic proenables structured LP ideas to be used in program- gramming and the composition of logic theories, ming. For example, the page searcher application such as those mentioned in x5.2, will certainly help. 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 [1] M. Baldoni, L. Giordano, and A. Martelli. work is still required. A Multimodal Logic to De ne Modules in
6 Conclusions and Future Work
References
8
[2] [3]
[4] [5]
[6]
[7]
[8]
[9]
[10]
[11] L. Hardman, D.C.A. Bulterman, and G. van Rossum. The Amsterdam Hypermedia Model: Adding Time and Context to the Dexter Model. Communications of the ACM, 37(2):50 { 62, February 1994. [12] M.F. Kaashoek, T. Pinckney, and J.A. Tauber. 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. [13] H. Kau mann and A. Grumbach. MULTILOG: Multiple Worlds in Logic Programming. In B. Du Boulay, D. Hogg, and L. Steels, editors, Advances in Ariti cial Intelligence, pages 233 { 247. Elsevier Science, 1987. [14] P. Mello, A. Natali, and C. Ruggieri. Logic Programming in a Software Engineering Perspective. In E.L. Lusk and R.A. Overbeek, editors, Proceedings of the North American Conference on Logic Programming, pages 441 { 458. The MIT Press, 1989. [15] L. Monteiro and A. Porto. A Language for Contextual Logic Programming. In K.R. Apt, J.W. de Bakker, and J.J.M.M. Rutter, editors, Logic Programming Languages: Constraints, Functions and Objects, pages 115 { 147. MIT Press, 1993. [16] HotJava Home Page. http://java.sun.com/. [17] Shin-ya Sato. Dynamic Rewriting of HTML Documents. 1st International World-Wide Web Conference, http://www.elsevier.nl/cgibin/query/WWW94/FinalProgramme.html?sato. [18] General Magic's Web Site. http://www.genmagic.com/. [19] M. van Doorn and A. Eliens. Integrating Applications and the World-Wide Web. Computer Networks and ISDN Systems, pages 1105 { 1111, 1995. [20] J. Wielemaker. SWI-Prolog 2.0 Reference Manual. Technical report, University of Amsterdam, Department of Social Sciences Informatics(SWI), April 1995.
Logic Programming. In D. Miller, editor, Proceedings of the International Symposium on Logic Programming, pages 473 { 487. The MIT Press, 1993. K.A. Bowen. Meta-level Programming and Knowledge Representation. New Generation Computing, pages 359 { 383, 1985. K.A. Bowen and R.A. Kowalski. Amalgamating Language and Metalanguage in Logic Programming. In K.L. Clark and S.A. Tarnlund, editors, Logic Programming, pages 153 { 172. Academic Press, 1982. A. Brogi. Program Construction in Computational Logic. PhD thesis, Universita di PisaGenova-Udine, 1993. A. Brogi, E. Lamma, and P. Mello. A General Framework for Structuring Logic Programs. Technical report, Dipartimento di Matematica e Informatica, Universita'di Udine. C.N.R. Technical Report 04-90-RR, Maggio 1990. A. Brogi, P. Mancarella, D. Pedreschi, and F. Turini. Modular Logic Programming. ACM Transactions on Programming Languages and Systems, 16(4), July 1994. A. Brogi and F. Turini. A Metalogic for State Oriented Programming. In E. Lamma and P. Mello, editors, Extensions of Logic Programming, Lecture Notes in Arti cial Intelligence 660, pages 187 { 204. Springer-Verlag, 1993. P.M.E. De Bra and R.D.J. Post. 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. P.M.E. De Bra and R.D.J. Post. Information Retrieval in the World-Wide Web: Making client-based searching feasible. Computer Networks and ISDN Systems, pages 183{192, 1994. F. Halasz and M. Schwartz. The Dexter Hypertext Reference Model. Communications of the ACM, 37(2):30 { 39, February 1994. 9
