A Prolog Datamodel for State Chart XML

Total Page:16

File Type:pdf, Size:1020Kb

A Prolog Datamodel for State Chart XML A Prolog Datamodel for State Chart XML Stefan Radomski Dirk Schnelle-Walka Stephan Radeck-Arneth TU Darmstadt TU Darmstadt TU Darmstadt Telekooperation Group Telekooperation Group Telekooperation Group Hochschulstrasse 10 Hochschulstrasse 10 Hochschulstrasse 10 [email protected] [email protected] [email protected] .tu-darmstadt.de .tu-darmstadt.de .tu-darmstadt.de Abstract log control, such as error correction or even sensor fusion/fission. SCXML was proposed as one description As one proposed XML dialect for control doc- language for dialog control in the W3C uments, State Chart XML (SCXML) is given the Multimodal Architecture but lacks the fa- responsibility to model an applications dialog be- cilities required for grounding and rea- havior. SCXML as such is a markup language to soning. This prohibits the application of express Harel state charts (Harel and Politi, 1998) many dialog modeling techniques for mul- with nested and parallel machine configurations. timodal applications following this W3C The transitions between configurations are trig- standard. By extending SCXML with a gered by events delivered into the interpreter ei- Prolog datamodel and scripting language, ther from external components or raised by the we enable those techniques to be em- interpreter itself. Whenever an event arrives, the ployed again. Thereby bridging the gap SCXML interpreter can perform actions described between respective dialog modeling re- as executable content. This includes invoking or search and a standardized architecture to sending events to external components, processing access and coordinate modalities. data or updating the datamodel via an embedded scripting language. 1 Introduction SCXML has been proven to be suitable to de- Deploying multimodal applications has long been couple the control flow and presentation layer an activity of custom solutions, each with their in dialog management (Wilcock, 2007). It has own access to modalities, approaches to sensor fu- been used in several applications to express dialog sion and fission and techniques for dialog mod- states (Brusk et al., 2007) or to easily incorporate eling. With the advent of the W3C MMI archi- external information (Siguenza¨ Izquierdo et al., tecture (Bondell et al., 2012), the W3C proposed 2011). However, SCXML seems to be suited only a standardized approach to ensure interoperabil- to implement finite state or frame-based/form- ity among its constituting components (Schnelle- filling dialogue management approaches. Appli- Walka et al., 2013; Dahl, 2013). cations using theses dialog techniques are often- The architecture proposed by the W3C decom- times inflexible as they lack grounding and rea- poses a multimodal application into a nested struc- soning. In this regard, Fodor and Huerta (2006) ture of interaction managers for dialog control and demand that dialog managers should feature: (i) a modality components for in- and output. An ap- formal logic foundation, (ii) an interference en- plication is conceived as a set of control docu- gine, (iii) general purpose planners and (iv) knowl- ments expressed in SCXML (Barnett et al., 2012) edge representation and expressiveness. or CCXML (Auburn et al., 2011) for the interac- Most of these requirements are addressed by tion managers and a set of presentation documents employing Prolog. Embedding it as a scripting with modality-specific markup for the modality language into SCXML allows multimodal applica- components. A topmost root controller document tions in the W3C MMI Architecture to employ the describes the global dialog and instantiates modal- more elaborate dialog management techniques, re- ity components as required. Each modality com- sulting in more natural and flexible interaction. In ponent can, in turn, again be an interaction man- this paper we describe our integration of Prolog ager, handling more fine granular concerns of dia- as an embedded scripting language in an SCXML 127 Proceedings of the SIGDIAL 2013 Conference, pages 127–131, Metz, France, 22-24 August 2013. c 2013 Association for Computational Linguistics datamodel. All of the work described here is im- % element(child, plemented as part of our uSCXML interpreter1 by % [father=bob, name=jim], [])]). <data id="household"> embedding the SWI Prolog implementation. { name:"The Bobsons", members: [’bob’,’martha’,’jim’,’john’] 2 The Prolog Datamodel } </data> Datamodels in SCXML are more than simple % household({ % name:’The Bobsons’, repositories for storing data. With the exception % members:[bob, martha, jim, john]}). of the null datamodel, they provide access to Listing 1: Assignments and their results in Prolog. embedded scripting languages. The datamodels already specified by the SCXML draft are the If given, the id or location attribute iden- null, the xpath and the ecmascript data- tifies the predicate for which the content is to be model. Prolog itself is a declarative language for asserted as fact, otherwise the content is assumed logic programming in which facts and rules are to be a dot-separated list of prolog queries or ex- used to answer queries. The result of a query is pressions. The content might also be loaded per either a boolean value or the set of valid assign- URL in the element’s src attribute. In the con- ments for the queries variables. text of SCXML, it is important to support XML In the following sections, we will describe our and JSON data as shown in the last two examples. integration of Prolog as a datamodel in SCXML. Not only enables this an application developer to The structure of the description loosely follows the load data from existing XML and JSON files, it is existing descriptions for datamodels already found also important to support these representations for in the SCXML draft. incoming events as we will see in the next section. There is no standardized representation for 2.1 Assignments XML DOMs or JSON data in Prolog. We prag- In an SCXML document, there are two elements matically settled upon the structure returned by the which will assign values to variables in the data- SWI-Prolog SGML parser and the JSON converter model. These are <data> for initial assignments as de-facto standards respectively. and <assign> itself. In Prolog, variable assign- With the Prolog datamodel, having an id ment is only available in the scope of a query. To or location attribute at assignment elements realize variable assignment nevertheless, we in- seems superfluous. We do keep them as the troduce the variables as predicates, with their as- SCXML draft specifies these as required at- signed data as facts. Listing 1 exemplifies some tributes. assignments followed by their resulting Prolog facts. 2.2 Structure of Events <data id="father"> Whenever an event is received by the SCXML in- bob, jim. bob, john. terpreter, it has to be transformed into a suitable </data> % father(bob, jim). representation in order to operate on its various % father(bob, john). fields and content as defined by the SCXML draft. <data id=""> We choose to represent an event as the single pred- mother(martha, jim). mother(martha, john). icate event/1 with its facts as compound terms </data> reflecting the event’s fields as shown in listing 2. % mother(martha, jim). % mother(martha, john). event(name(’foo’)). event(type(’external’)). <assign location=""> event(sendid(’s1.bar’)). retract(father(bob, jim)). event(origin(’http://host/path/basichttp’)). assert(father(steve, jim)). event(origintype(’http://www.w3.org/TR/scxml </assign> /#BasicHTTPEventProcessor’)). % father(bob, john). event(invokeid(’’)). % father(steve, jim). event(data(...)). event(param(...)). <data id="childs"> event(raw(...)). <child name="john" father="bob" /> <child name="jim" father="bob" /> Listing 2: Example facts for event/1. </data> % childs([ % element(child, This representation enables access to the events % [father=bob, name=john], []), individual fields by simple queries such as 1https://github.com/tklab-tud/uscxml event(name(X)), which will resolve X to the 128 event’s name foo. Whenever the interpreter is Defining two predicates for ioprocessors is sim- about to process a new event, all old facts about ply a matter of convenience as their short names event/1 are retracted and reasserted with regard (e.g. basichttp or scxml) are suited as functors to the new event. for compound terms, where their canonic names The event’s data field may contain a space nor- are not. Therefore ioprocessors/1 will only malized string as an atomic term, an XML DOM contain the short names, and ioprocessors/2 or, optionally, data from a JSON structure. The contains both. This allows us to send events, e.g structure of JSON and XML DOMs is the same as with the basichttp ioprocessor via: with assignments in listing 1. <send type="basichttp" targetexpr="ioprocessors(basichttp( location(X)))" 2.3 Scripting event="foo"> The <script> element either contains Prolog Listing 4: Sending ourself an event via basichttp. expressions as they would be written in a Prolog file or references such a file directly via its src at- tribute. Together with <assign> and <data>, 2.5 Conditional Expressions this element is the third available to load Prolog Conditional expressions in SCXML are used files into the SCXML interpreter. This is some- to guard transitions and as part of <if> and what undesirable and we would propose to use <elseif> elements in executable content. They (i) <data> to establish initial a-priori knowledge consist of a single, datamodel specific expression as facts, (ii) <assign> for subsequent changes that ought to evaluate to a boolean value. In the and additions to facts and (iii) <script> to in- case of our Prolog datamodel, these expressions troduce new rules or load Prolog files containing can take the form of an arbitrary query (see list- primarily rules. ing 5). If there exists at least one solution to the It is important to note that we do provide a full query, the conditional expression will be evaluated ISO-Prolog implementation at runtime. This en- to true, and false otherwise. ables an application developer to load arbitrary % Is there someone who is not the father Prolog files with all their facts and rules.
Recommended publications
  • ALGORITHMS for ARTIFICIAL INTELLIGENCE in Apl2 By
    MAY 1986 REVISED Nov­ 1986 TR 03·281 ALGORITHMS FOR ARTIFICIAL INTELLIGENCE IN APl2 By DR­ JAMES A· BROWN ED EUSEBI JANICE COOK lEO H­ GRONER INTERNATIONAL BUSINESS MACHINES CORPORATION GENERAL PRODUCTS DIVISION SANTA TERESA LABORATORY SAN JOSE~ CALIFORNIA ABSTRACT Many great advances in science and mathematics were preceded by notational improvements. While a g1yen algorithm can be implemented in any general purpose programming language, discovery of algorithms is heavily influenced by the notation used to Lnve s t Lq a t.e them. APL2 c o nce p t.ua Lly applies f unc t Lons in parallel to arrays of data and so is a natural notation in which to investigate' parallel algorithins. No c LaLm is made that APL2 1s an advance in notation that will precede a breakthrough in Artificial Intelligence but it 1s a new notation that allows a new view of the pr-obl.ems in AI and their solutions. APL2 can be used ill problems tractitionally programmed in LISP, and is a possible implementation language for PROLOG-like languages. This paper introduces a subset of the APL2 notation and explores how it can be applied to Artificial Intelligence. 111 CONTENTS Introduction. • • • • • • • • • • 1 Part 1: Artificial Intelligence. • • • 2 Part 2: Logic... · • 8 Part 3: APL2 ..... · 22 Part 4: The Implementations . · .40 Part 5: Going Beyond the Fundamentals .. • 61 Summary. .74 Conclus i ons , . · .75 Acknowledgements. • • 76 References. · 77 Appendix 1 : Implementations of the Algorithms.. 79 Appendix 2 : Glossary. • • • • • • • • • • • • • • • • 89 Appendix 3 : A Summary of Predicate Calculus. · 95 Appendix 4 : Tautologies. · 97 Appendix 5 : The DPY Function.
    [Show full text]
  • Event Management for the Development of Multi-Agent Systems Using Logic Programming
    Event Management for the Development of Multi-agent Systems using Logic Programming Natalia L. Weinbachy Alejandro J. Garc´ıa [email protected] [email protected] Laboratorio de Investigacio´n y Desarrollo en Inteligencia Artificial (LIDIA) Departamento de Ciencias e Ingenier´ıa de la Computacio´n Universidad Nacional del Sur Av. Alem 1253, (8000) Bah´ıa Blanca, Argentina Tel: (0291) 459-5135 / Fax: (0291) 459-5136 Abstract In this paper we present an extension of logic programming including events. We will first describe our proposal for specifying events in a logic program, and then we will present an implementation that uses an interesting communication mechanism called \signals & slots". The idea is to provide the application programmer with a mechanism for handling events. In our design we consider how to define an event, how to indicate the occurrence of an event, and how to associate an event with a service predicate or handler. Keywords: Event Management. Event-Driven Programming. Multi-agent Systems. Logic Programming. 1 Introduction An event represents the occurrence of something interesting for a process. Events are useful in those applications where pieces of code can be executed automatically when some condition is true. Therefore, event management is helpful to develop agents that react to certain occurrences produced by changes in the environment or caused by another agents. Our aim is to support event management in logic programming. An event can be emitted as a result of the execution of certain predicates, and will result in the execution of the service predicate or handler. For example, when programming a robot behaviour, an event could be associated with the discovery of an obstacle in its trajectory; when this event occurs (generated by some robot sensor), the robot might be able to react to it executing some kind of evasive algorithm.
    [Show full text]
  • A View of the Fifth Generation and Its Impact
    AI Magazine Volume 3 Number 4 (1982) (© AAAI) Techniques and Methodology A View of the Fifth Generation And Its Impact David H. D. Warren SRI International Art$icial Intellagence Center Computer Scaence and Technology Davzsaon Menlo Park, Calafornia 94025 Abstract is partly secondhand. I apologise for any mistakes or misin- terpretations I may therefore have made. In October 1981, .Japan announced a national project to develop highly innovative computer systems for the 199Os, with the title “Fifth Genera- tion Computer Systems ” This paper is a personal view of that project, The fifth generation plan its significance, and reactions to it. In late 1978 the Japanese Ministry of International Trade THIS PAPER PRESENTS a personal view of the <Japanese and Industry (MITI) gave ETL the task of defining a project Fifth Generation Computer Systems project. My main to develop computer syst,ems for the 199Os, wit,h t,he title sources of information were the following: “Filth Generation.” The prqject should avoid competing with IBM head-on. In addition to the commercial aspects, The final proceedings of the Int,ernational Conference it should also enhance Japan’s international prestige. After on Fifth Generat,ion Computer Systems, held in Tokyo in October 1981, and the associated Fifth Generation various committees had deliberated, it was finally decided research reports distributed by the Japan Information to actually go ahead with a “Fifth Generation Computer Processing Development Center (JIPDEC); Systems” project in 1981. The project formally started in April, 1982. Presentations by Koichi Furukawa of Electrotechnical The general technical content of the plan seems to be Laboratory (ETL) at the Prolog Programming Environ- largely due to people at ETL and, in particular, to Kazuhiro ments Workshop, held in Linkoping, Sweden, in March 1982; Fuchi.
    [Show full text]
  • CSC384: Intro to Artificial Intelligence  Brief Introduction to Prolog
    CSC384: Intro to Artificial Intelligence Brief Introduction to Prolog Part 1/2: Basic material Part 2/2 : More advanced material 1 Hojjat Ghaderi and Fahiem Bacchus, University of Toronto CSC384: Intro to Artificial Intelligence Resources Check the course website for several online tutorials and examples. There is also a comprehensive textbook: Prolog Programming for Artificial Intelligence by Ivan Bratko. 2 Hojjat Ghaderi and Fahiem Bacchus, University of Toronto What‟s Prolog? Prolog is a language that is useful for doing symbolic and logic-based computation. It‟s declarative: very different from imperative style programming like Java, C++, Python,… A program is partly like a database but much more powerful since we can also have general rules to infer new facts! A Prolog interpreter can follow these facts/rules and answer queries by sophisticated search. Ready for a quick ride? Buckle up! 3 Hojjat Ghaderi and Fahiem Bacchus, University of Toronto What‟s Prolog? Let‟s do a test drive! Here is a simple Prolog program saved in a file named family.pl male(albert). %a fact stating albert is a male male(edward). female(alice). %a fact stating alice is a female female(victoria). parent(albert,edward). %a fact: albert is parent of edward parent(victoria,edward). father(X,Y) :- %a rule: X is father of Y if X if a male parent of Y parent(X,Y), male(X). %body of above rule, can be on same line. mother(X,Y) :- parent(X,Y), female(X). %a similar rule for X being mother of Y A fact/rule (statement) ends with “.” and white space ignored read :- after rule head as “if”.
    [Show full text]
  • An Architecture for Making Object-Oriented Systems Available from Prolog
    An Architecture for Making Object-Oriented Systems Available from Prolog Jan Wielemaker and Anjo Anjewierden Social Science Informatics (SWI), University of Amsterdam, Roetersstraat 15, 1018 WB Amsterdam, The Netherlands, {jan,anjo}@swi.psy.uva.nl August 2, 2002 Abstract It is next to impossible to develop real-life applications in just pure Prolog. With XPCE [5] we realised a mechanism for integrating Prolog with an external object-oriented system that turns this OO system into a natural extension to Prolog. We describe the design and how it can be applied to other external OO systems. 1 Introduction A wealth of functionality is available in object-oriented systems and libraries. This paper addresses the issue of how such libraries can be made available in Prolog, in particular libraries for creating user interfaces. Almost any modern Prolog system can call routines in C and be called from C (or other impera- tive languages). Also, most systems provide ready-to-use libraries to handle network communication. These primitives are used to build bridges between Prolog and external libraries for (graphical) user- interfacing (GUIs), connecting to databases, embedding in (web-)servers, etc. Some, especially most GUI systems, are object-oriented (OO). The rest of this paper concentrates on GUIs, though the argu- ments apply to other systems too. GUIs consist of a large set of entities such as windows and controls that define a large number of operations. These operations often involve destructive state changes and the behaviour of GUI components normally involves handling spontaneous input in the form of events. OO techniques are very well suited to handle this complexity.
    [Show full text]
  • Logic Programming Lecture 19 Tuesday, April 5, 2016 1 Logic Programming 2 Prolog
    Harvard School of Engineering and Applied Sciences — CS 152: Programming Languages Logic programming Lecture 19 Tuesday, April 5, 2016 1 Logic programming Logic programming has its roots in automated theorem proving. Logic programming differs from theorem proving in that logic programming uses the framework of a logic to specify and perform computation. Essentially, a logic program computes values, using mechanisms that are also useful for deduction. Logic programming typically restricts itself to well-behaved fragments of logic. We can think of logic programs as having two interpretations. In the declarative interpretation, a logic pro- gram declares what is being computed. In the procedural interpretation, a logic program program describes how a computation takes place. In the declarative interpretation, one can reason about the correctness of a program without needing to think about underlying computation mechanisms; this makes declarative programs easier to understand, and to develop. A lot of the time, once we have developed a declarative program using a logic programming language, we also have an executable specification, that is, a procedu- ral interpretation that tells us how to compute what we described. This is one of the appealing features of logic programming. (In practice, executable specifications obtained this way are often inefficient; an under- standing of the underlying computational mechanism is needed to make the execution of the declarative program efficient.) We’ll consider some of the concepts of logic programming by considering the programming language Prolog, which was developed in the early 70s, initially as a programming language for natural language processing. 2 Prolog We start by introducing some terminology and syntax.
    [Show full text]
  • Intro to Prolog Chapter 11 Prolog, Which Stands for Programming In
    Intro to Prolog Chapter 11 Prolog, which stands for PROgramming in LOGic, is the most widely available language in the logic programming paradigm using the mathematical notions of relations and logical inference. Prolog is a declarative language rather than procedural, meaning that rather than describing how to compute a solution, a program consists of a data base of facts and logical relationships (rules) that describes the relationships which hold for the given application. Rather then running a program to obtain a solution, the user asks a question. When asked a question, the run time system searches through the data base of facts and rules to determine (by logical deduction) the answer. Often there will be more than one way to deduce the answer or there will be more than one solution, in such cases the run time system may be asked to backtrack and find other solutions. Prolog is a weakly typed language with dynamic type checking and static scope rules. Prolog is typically used in artificial intelligence applications such as natural language interfaces, automated reasoning systems and expert systems. Expert systems usually consist of a data base of facts and rules and an inference engine, the run time system of Prolog provides much of the services of an inference engine. Basic Propositional Logic Propositional logic provides the foundation for programming in Prolog. A proposition is formed using the following rules: • true and false are propositions • variables p,q, r,… etc. that take on values true or false are propositions • Boolean operators ∧ ∨ ¬ ⇒ and = used to form more complex propositions Book uses ⊃ in place of ⇒ for implication, where p ⇒ r is equivalent to ¬p ∨ r.
    [Show full text]
  • Programming Language Use in US Academia and Industry
    Informatics in Education, 2015, Vol. 14, No. 2, 143–160 143 © 2015 Vilnius University DOI: 10.15388/infedu.2015.09 Programming Language Use in US Academia and Industry Latifa BEN ARFA RABAI1, Barry COHEN2, Ali MILI2 1 Institut Superieur de Gestion, Bardo, 2000, Tunisia 2 CCS, NJIT, Newark NJ 07102-1982 USA e-mail: [email protected], [email protected], [email protected] Received: July 2014 Abstract. In the same way that natural languages influence and shape the way we think, program- ming languages have a profound impact on the way a programmer analyzes a problem and formu- lates its solution in the form of a program. To the extent that a first programming course is likely to determine the student’s approach to program design, program analysis, and programming meth- odology, the choice of the programming language used in the first programming course is likely to be very important. In this paper, we report on a recent survey we conducted on programming language use in US academic institutions, and discuss the significance of our data by comparison with programming language use in industry. Keywords: programming language use, academic institution, academic trends, programming lan- guage evolution, programming language adoption. 1. Introduction: Programming Language Adoption The process by which organizations and individuals adopt technology trends is complex, as it involves many diverse factors; it is also paradoxical and counter-intuitive, hence difficult to model (Clements, 2006; Warren, 2006; John C, 2006; Leo and Rabkin, 2013; Geoffrey, 2002; Geoffrey, 2002a; Yi, Li and Mili, 2007; Stephen, 2006). This general observation applies to programming languages in particular, where many carefully de- signed languages that have superior technical attributes fail to be widely adopted, while languages that start with modest ambitions and limited scope go on to be widely used in industry and in academia.
    [Show full text]
  • An Introduction to Prolog
    Appendix A An Introduction to Prolog A.1 A Short Background Prolog was designed in the 1970s by Alain Colmerauer and a team of researchers with the idea – new at that time – that it was possible to use logic to represent knowledge and to write programs. More precisely, Prolog uses a subset of predicate logic and draws its structure from theoretical works of earlier logicians such as Herbrand (1930) and Robinson (1965) on the automation of theorem proving. Prolog was originally intended for the writing of natural language processing applications. Because of its conciseness and simplicity, it became popular well beyond this domain and now has adepts in areas such as: • Formal logic and associated forms of programming • Reasoning modeling • Database programming • Planning, and so on. This chapter is a short review of Prolog. In-depth tutorials include: in English, Bratko (2012), Clocksin and Mellish (2003), Covington et al. (1997), and Sterling and Shapiro (1994); in French, Giannesini et al. (1985); and in German, Baumann (1991). Boizumault (1988, 1993) contain a didactical implementation of Prolog in Lisp. Prolog foundations rest on first-order logic. Apt (1997), Burke and Foxley (1996), Delahaye (1986), and Lloyd (1987) examine theoretical links between this part of logic and Prolog. Colmerauer started his work at the University of Montréal, and a first version of the language was implemented at the University of Marseilles in 1972. Colmerauer and Roussel (1996) tell the story of the birth of Prolog, including their try-and-fail experimentation to select tractable algorithms from the mass of results provided by research in logic.
    [Show full text]
  • Appendix a LOGIC PROGRAMMING with PROLOG
    Appendix A LOGIC PROGRAMMING WITH PROLOG mperative programming languages reflect the architecture of the under- lying von Neumann stored program computer: Programs consist of I instructions stored in memory with a program counter determining which instruction to execute next. Programs perform their computations by updat- ing memory locations that correspond to variables. Programs are prescrip- tive—they dictate precisely how a result is to be computed by means of a sequence of commands to be performed by the computer. Assignment acts as the primary operation, updating memory locations to produce a result obtained by incremental changes to storage using iteration and selection commands. An alternative approach, logic programming, allows a programmer to de- scribe the logical structure of a problem rather than prescribe how a com- puter is to go about solving it. Based on their essential properties, languages for logic programming are sometimes called: 1. Descriptive or Declarative Languages : Programs are expressed as known facts and logical relationships about a problem that hypothesize the ex- istence of the desired result; a logic interpreter then constructs the de- sired result by making inferences to prove its existence. 2. Nonpr ocedural Languages : The programmer states only what is to be accomplished and leaves it to the interpreter to determine how it is to be proved. 3. Relational Languages : Desired results are expressed as relations or predi- cates instead of as functions; rather than define a function for calculat- ing the square of a number, the programmer defines a relation, say sqr(x,y), that is true exactly when y = x2. Imperative programming languages have a descriptive component, namely expressions: “3*p + 2*q” is a description of a value, not a sequence of com- puter operations; the compiler and the run-time system handle the details.
    [Show full text]
  • SWI-Prolog and the Web
    Under consideration for publication in Theory and Practice of Logic Programming 1 SWI-Prolog and the Web JAN WIELEMAKER Human-Computer Studies laboratory University of Amsterdam Matrix I Kruislaan 419 1098 VA, Amsterdam The Netherlands (e-mail: [email protected]) ZHISHENG HUANG, LOURENS VAN DER MEIJ Computer Science Department Vrije University Amsterdam De Boelelaan 1081a 1081 HV, Amsterdam The Netherlands (e-mail: huang,[email protected]) submitted 28 April 2006; revised 23 August 2007; accepted 18 October 2007 Abstract Prolog is an excellent tool for representing and manipulating data written in formal lan- guages as well as natural language. Its safe semantics and automatic memory management make it a prime candidate for programming robust Web services. Where Prolog is commonly seen as a component in a Web application that is either embedded or communicates using a proprietary protocol, we propose an architecture where Prolog communicates to other components in a Web application using the standard HTTP protocol. By avoiding embedding in external Web servers development and deployment become much easier. To support this architecture, in addition to the transfer protocol, we must also support parsing, representing and generating the key Web document types such as HTML, XML and RDF. This paper motivates the design decisions in the libraries and extensions to Prolog for arXiv:0711.0917v1 [cs.PL] 6 Nov 2007 handling Web documents and protocols. The design has been guided by the requirement to handle large documents efficiently. The described libraries support a wide range of Web applications ranging from HTML and XML documents to Semantic Web RDF processing.
    [Show full text]
  • Design and Implementation of the GNU Prolog System Abstract 1 Introduction
    Design and Implementation of the GNU Prolog System Daniel Diaz Philippe Codognet University of Paris 1 University of Paris 6 CRI, bureau C1407 LIP6, case 169 90, rue de Tolbiac 8, rue du Capitaine Scott 75013 Paris, FRANCE 75015 Paris, FRANCE and INRIA-Rocquencourt and INRIA-Rocquencourt [email protected] [email protected] Abstract In this paper we describe the design and the implementation of the GNU Pro- log system. This system draws on our previous experience of compiling Prolog to C in the wamcc system and of compiling finite domain constraints in the clp(FD) system. The compilation scheme has however been redesigned in or- der to overcome the drawbacks of compiling to C. In particular, GNU-Prolog is based on a low-level mini-assembly platform-independent language that makes it possible to avoid compiling C code, and thus drastically reduces compilation time. It also makes it possible to produce small stand-alone executable files as the result of the compilation process. Interestingly, GNU Prolog is now com- pliant to the ISO standard, includes several extensions (OS interface, sockets, global variables, etc) and integrates a powerful constraint solver over finite domains. The system is efficient and in terms of performance is comparable with commercial systems for both the Prolog and constraint aspects. 1 Introduction GNU Prolog is a free Prolog compiler supported by the GNU organization (http://www.gnu.org/software/prolog). It is a complete system which in- cludes: floating point numbers, streams, dynamic code, DCG, operating sys- tem interface, sockets, a Prolog debugger, a low-level WAM debugger, line editing facilities with completion on atoms, etc.
    [Show full text]