In this section we describe the architecture of the web based system we have designed and implemented to process RP-DeLP programs1 and which is available at http://arinf.udl.cat/rp-delp.
A web application is a software tool which is available through a net-work of computers, in most of the cases this software is being executed in a server and accessible by all the clients connected to the same network. That software provides a common interface which is supported by a web browser.
One of the main features of a web application is ubiquity, that means that the application is ready as long as there is access to the network. Another advantage is that the only software required at the client part is a web browser. A key reason for its popularity is the fact that the software can be updated and maintained without the necessity of installing or disturbing the clients. There are more advantages, such as the inherent cross-platform compatibility and the lack of high system requirements, because most of the processing tasks are executed in the server side.
However, there are also some inconveniences, as a web interface is not easily adaptable to other systems. To solve this drawback we designed a web system capable of solving both instances posted through a web interface and also instances received through HTTP requests. By using HTTP protocol, any client will be able to send a query without the necessity of filling a web interface.
Our system is allocated in a stand-alone server where all the required software is installed, including a web server to handle HTTP requests, the RP-DeLP algorithm to handle the user programs and the rest of the software required by the system, such as the ASP and SAT solvers. As said previ-ously, the user can access to the server using a web browser through the web interface or by posting an HTTP request. The RP-DeLP algorithm is im-plemented with Python. In Figure 5.5 we show the web interface structure of the system.
The web interface is divided into two main parts. The first part is devoted to choose the computation options. The Maximal Ideal radio button computes the maximal ideal output and the Multiple radio button computes the set of outputs. Remark that for RP-DeLP programs with a single output both options will compute the same output.
The SAT radio button encodes queries with SAT formulas and solves them with solver Minisat solver. The ASP radio button encodes queries
1We plan to deliver an open-source version as soon as we consider the system is suffi-ciently mature.
Figure 5.5: Web interface form for submitting RP-DeLP programs.
with ASP formulas and solves them with solver Clingo.
The second part of the web interface is devoted to define RP-DeLP programs. Each defeasible level is depicted by a text box. The strict part of the program is defined in the Strict Level text box. The defeasible part of the program can be defined using multiple levels of strength, starting from the highest level and going down from one level to the level below. The form is dynamically updated, so the user can add new levels by pressing the Add levelbutton. The Delete level erases the last added level and the Reset button deletes all levels except the strict part and the first defeasible level.
The Submit button starts the computation process.
Clauses are defined as follows:
All clauses must end with a dot.
A literal is an alphanumeric word starting with a letter.
Negation is denoted with symbol∼.
Implication symbol is written with :- and conjunction symbol is a comma. For instance, q ← p1∧ ∼p2 is written in our formalism as: q :- p1, ∼ p2.
Regarding the system architecture, represented in Figure 5.6, the com-putation process starts with the translation of the RP-DeLP program and
the set of computation options into an XML file. Then, appropriate Python structures are built from the XML file in order to be processed by the RP-DeLP algorithm. The RP-RP-DeLP algorithm uses the ASP or the SAT im-plementation depending on the computation options. When the RP-DeLP algorithm finishes, outputs are stored in an XML file which allow us to provide an HTTP response or an HTML page.
Figure 5.6: RP-DeLP web system architecture.
One of the main features of our system is that provides not only sets of warranted and blocked conclusions, but also information to further under-stand the reasons why conclusions are warranted or blocked.
In Table 5.1 we show the information that the system provides to the user for every output. This information is divided in two parts. The first part shows the total number of outputs, a label of the computing order of the output, the set of warranted conclusions of the output and the time expended computing the output. For each warranted conclusion there is a list of conclusions which support it and the strength of the conclusion.
The second part shows the set of blocked conclusions of the output and the set of conclusions which support them. For each blocked conclusion the system informs about the strength of the conclusion and the reason that leads to block it: a conflict or a cycle. For conflicts it shows the set of valid conclusions that minimally conflicts. For cycles it shows the set of valid conclusions of the cycle at some warrant dependency graph. Remark that a conclusion is blocked due to a cycle whenever we compute the maximal ideal output, otherwise conclusions are blocked due to conflicts.
Number of outputs # output Warranted conclusions Time
n i
P1 : {P1,1, . . . , P1,h} [αP1] tn
...
Pr : {Pr,1, . . . , Pr,u} [αPr]
# output Blocked conclusions Support of blocked conclusions i
Q1 : conf lict(Q1,1, . . . , Q1,j) [αQ1] Q1 : {P1,1, . . . , P1,k}
... ...
Qs : cycle(Qs,1, . . . , Qs,v) [αQs] Qx : {Px,1, . . . , Px,w}
Table 5.1: Information provided by the system for an RP-DeLP program.