A Prover Dealing with Nominals, Binders, Transitivity and Relation Hierarchies

Abstract

This work describes the Sibyl prover, an implementation of a tableau based proof procedure for multi-modal hybrid logic with the converse, graded and global modalities, and enriched with features largely used in description logics: transitivity and relation hierarchies. The proof procedure is provably terminating when the input problem belongs to an expressive decidable fragment of hybrid logic. After a description of the implemented proof procedure, the way how the implementation deals with the most delicate aspects of the calculus is explained. Some experimental results, run on sets of randomly generated problems as well as some hand-tailored ones, show only a moderate deterioration in the performances of the prover when the number of transitivity and inclusion axioms increase. Sibyl is compared with other provers (HTab, the hybrid logic prover whose expressive power is closer to Sibyl’s one, and the first-order prover SPASS). The obtained results show that Sibyl has reasonable performances.

Appendix: Architecture of the Sibyl Prover

This appendix is devoted to describe the main architecture of the prover and the modules and data types used to implement the techniques described in Sect. 5.

1.1 Main Architecture and System Dynamics

The architectural decomposition of the system is shown in Fig. 6. Here, the execution lifecycle is presented, showing the functionalities provided and the responsibilities assigned to the components of the system, as well as the interaction among them.

All the modules depend on a set of Utilities, containing modules that provide various kinds of services, and on the module Logic. The latter contains the definition of the data type representing formulae, as well as a collection of functions to manipulate them. In particular, it contains a function implementing formula preprocessing, as described in Sect. 3, and a test verifying whether the input formulae belong to the decidable fragment $\textsf {HL}{\setminus }\Box {\mathord \downarrow }\Box$. Before being fed to the tableau construction procedure, formulae are simplified and transformed into negation normal form. Such operations are also under the responsibility of the module Logic. Another important task carried out by the module is nominal substitution, implemented as described in Sect. 5.1.

The main System control is under the responsibility of a group of modules, arranging all the necessary operations for the startup and the lifecycle of the program. It handles all aspects of Sibyl’s simple command-line interface, it reads, if present, a configuration file defining rule application priorities, it initializes the computation environment and collaborates with the input/output handling modules. Moreover, it initializes all the data structures in memory that will be used in the computation. In particular, it builds the initial segment of the tableau and passes it to the main module handling tableau expansion, i.e. Search.

Tableau branches are expanded one at a time, in a depth-first manner, until either a contradiction is found (the branch closes) or the branch is complete. The Search module keeps a stack of the branches to be expanded, pops them out when the currently explored branch closes, and pushes new branches into the stack when the branching $\vee$-rule is applied. Its direct collaborators are the modules Branch and Rules: while the selected branch can be expanded, it is passed to the Branch module, which selects the correct rule instance to be fired and module Rules applies it. When a branch closes, Searchbackjumps and pops out another branch stored in the stack (the backjumping mechanism is described in Sect. A.4).

The core of the system is made up by the modules cooperating in branch expansion, that can be partitioned into two classes: the modules taking care of the Rule system and those constituting the Branch structure.

1.2 Rule System

In the Rule system, Premisses defines the type used to represent (sets of) tableau nodes [and assertions] constituting suitable premisses for a rule application,¹⁴ so each element of this type represents a possible rule application. The representation of an application of the $\textsf {A}$ rule, beyond its “main” premiss, contains the name of the focused nominal. Each rule is associated a priority (either the default one or the priority read from the configuration file), so that Premisses can compare two rule applications accordingly. A priority queue of possible rule applications is in fact part of the Branch structure, and Premisses helps Branch in its management.

The main responsibility of the module Rules is firing a selected rule application and modifying the current branch accordingly. When the current branch forks, Rules returns the two branches to Search, which stores them both into the stack and resumes the first one to be expanded further. If the application of the selected rule causes a clash, Rules informs Search, communicating also the dependency points of the clash, used by Search for backjumping (see Sect. A.4).

1.3 Branch Structure

The Branch structure groups modules containing all the elements constituting a tableau branch and the functions to handle its dynamics. Each module in this group defines an abstract data type, whose values will be referred to with the same name of the corresponding module.

The lowest-level module of this group is Node. A Node structure represents a tableau node and its main responsibility is to encapsulate its state. Node values play an important role by supporting other modules, and supplying them with the state information they need. A Node has a unique numeric identifier (identifiers reflect node order in the branch), and maintains the label of the node. Moreover, a set of fields supports operations taking into account the restrictions on the applicability of the expansion rules:

• flags signaling whether the node is directly blocked or a phantom;

• the node’s relatives according to the offspring relation;

• a list of nodes whose labels have the same structure of its own label, that are therefore potentially blockers for it; in other terms a node (n)F belongs to the list of potential blockers of (m)G whenever there exists a matching $\theta$ such that $\theta (F)=G$ (matchings are defined in Sect. 4.2).

• a flag frozen, that is set when the node cannot be added to the branch because of restriction R1 (but can possibly be resumed afterwards), and a list of nodes that are “frozen” by the current node for the same reason;

• a flag deferred, that is set whenever the node label has the form $a\mathord :\,\textsf {A}F$ and no minor premiss for its expansion currently exists (all the potential ones being phantoms); the node cannot therefore be expanded because of restriction R3 (but may be resumed afterwards).

Finally, an optimization support field stores the branching points (in the form of a list of branch identifiers) causing the presence of the node in the branch. They are the dependency points that will be used on backjumping, when a clash is detected involving the current node.

A Nominal structure represents a nominal occurring in the branch. It stores the nodes labeled by satisfaction statements where the nominal is the outermost one,¹⁵ as well as those where the nominal simply occurs, and the nodes labelled by relational formulae involving it. Moreover, a Nominal dynamically maintains its top/non-top status and caches a list of compatible nominals.

The functionalities of the module Nominal include clash detection, which is “internal” to nominals (a clash is caused by a pair of nodes of the form $a\mathord :\,p$ and $a\mathord :\,\lnot p$, or a node of the form $a\mathord :\,\lnot a$). Furthermore, since the module also maintains a list of all the nominals occurring in the branch, it can determine whether a matching $\{a_1\mapsto b_1,\ldots , a_n\mapsto b_n\}$ is a mapping for the branch.

Let us recall that a partial injective function $\theta =\{a_1\mapsto b_1,\ldots , a_n\mapsto b_n\}$ maps a formula F to G if:

• $\theta (F)=G$, i.e. F and G have the same structure;

• for all i, $a_i$ and $b_i$ are compatible non-top nominals.

The first property is structural and pertains to formulae while the second pertains to nominals. Accordingly, the responsibility of checking the existence of a mapping between two formulae is split between Logic and Nominal.

Branch defines the abstract data type of branches in a tableau. A Branch-typed value stores most of the current state of the computation. It maintains the list of its nodes and the nominals occurring in it, and is responsible for the rule expansion queue. A Branch is a complex structure whose main components are:

• a unique identifier used to implement backjumping.

• The set of all the Nodes constituting the branch. The set of nodes labelled by formulae of the form $a\mathord :\,\textsf {A}F$ is stored apart so that they can be easily retrieved when new nominals are added to the branch.

• The set of the directly or indirectly blocked Nodes, that have not been expanded but might be resumed afterwards.

• The set of Nominals occurring in the branch.

• A priority queue containing the applicable rules (Premisses-typed values), i.e. suitable, yet-to-be-processed rule premisses.

• The set of Nodes labelled by formulae of the form $a\mathord :\,\textsf {A}F$ presently lacking a minor premiss, whose application is deferred. The applicability of the $\textsf {A}$ rule to such nodes is checked again before terminating the branch construction.

• Structures devoted to help the branch in enforcing the restrictions on branch expansion: a Blocker, a Freezer and a Pairer. The corresponding modules are described below.

It is worth pointing out that, at first, a node is inserted in the expansion queue as if it were the premiss of a single premiss rule. Then, when, for instance, a node labelled by a relational formula is dequeued, all the possible tuples of companion premisses are looked for (by module Rules) and enqueued again. When a previously (directly or indirectly) blocked node is unblocked, it re-enters the queue, and this mechanisms deals with the dynamic applicability of all the expansion rules, except for the $\textsf {A}$ rule.

A Blocker, whose role and main functionalities are described in Sect. 5.2, is a hash table where keys are denominalized formulae, i.e. formulae where nominals are replaced by a special “dummy” one, so that a denominalized formula represents a formula structure. The values associated to each of such formula structures are lists of blockable nodes (in descending order, i.e. higher node identifiers first) whose labels have the structure determined by the key. Consequently, the labels of all the nodes in the same list have the same structure. Every node is potentially blocked by those that occur later in the list (i.e. before it in the branch), depending on whether a mapping actually exists. Nodes enter the data structure as soon as they are created.

A Freezer, whose role is described in Sect. 5.2, is concretely implemented by a hash table. The values of the table are pairs of lists $\langle \text {freezing}, \text {frozen}\rangle$. All freezing and frozen nodes in the same map entry share the exact same label; thus the pairs are indexed and retrieved by the labels of the nodes they store. A Freezer is updated as soon as the frozen status of a node may have changed, due to some freezing node becoming a phantom, as a consequence of an update of the corresponding Blocker.

Finally, a Pairer, the branch helper managing applications of the $\textsf {A}$ rule, is concretely implemented by a hash table of records, where the keys are the Node identifiers of $\textsf {A}$-nodes and each record contains, beyond the corresponding $\textsf {A}$-node, the information described in Sect. 5.3.

1.4 Backjumping

This section gives a brief description of the (standard) mechanism used to implement backjumping. As already seen, each Branch is identified by a unique, progressive number, called its identifier. Branching points are labelled by the identifier of the right branch (pushed into the stack by Search) and each Node has a dependency set, that contains the branching points on which it depends, determined according to the following rules: a node always inherits the dependency set(s) of the node(s) that have caused its addition to the branch; when the $\vee$ rule is applied and the branch splits, the identifier of the right branch is added to the dependency set of the node added to the left; finally, when the equality rule is applied to a node n, every node whose outermost nominal is affected by the substitution inherits the dependency set of n.

When a branch closes because a contradiction is detected, the dependency sets of the Nodes involved in the clash are merged in descending order; the first dependency point identifies the branch where the search will resume.