2.1. PSMs and their reuse

PSMs describe the principal reasoning processes of KBSs. For a useful summary of PSM-related research up to 1998, see Fensel and Motta (Reference Fensel and Motta1998). It was appreciated that considerable benefits would accrue from a PSM library, because the construction of KBSs using proven components should reduce development time and improve reliability. This area of research has been most notably investigated through the KADS/CommonKADS Expertise Modeling Library and also through the Protégé PSM Library. These are examined in more detail below. Part of the KADS project (1983–1994) involved the creation of a PSM library; by the mid-1990s, the CommonKADS library contained hundreds of PSMs (Breuker & Van de Velde, Reference Breuker and Van de Velde1994; Schreiber et al., Reference Schreiber, Wielinga, De Hoog, Van de Velde and Anjewierden1994).

A parallel development happened in the context of Stanford's Protégé-2000 system, which includes a widely used ontology editor. Here, the PSM Librarian and associated methodology provide an ontology-based KB development model that enables reuse of PSMs. There are three distinct ontologies: a domain ontology, a method ontology, and a mapping ontology. The domain ontology is self-explanatory. The method ontology is a domain-independent characterization of a PSM's inputs and outputs. The mapping ontology is a mediator that defines explicit relationships between a particular domain and a particular method without compromising the independence of these distinct components.

This journal has recently published a special issue on PSMs. In the editorial, Brown (Reference Brown2009) summarizes the developments in KBSs that led to the initial concept (namely, reusable procedural “building blocks”), asks whether the PSMs identified earlier are at the right level of granularity, and then discusses the potential roles for PSMs in the world of the semantic web. He also discusses the difficulties posed for engineers by the formal notation used in PSMs and pleads for “‘PSM light’ versions available as well, that is, versions using less intimidating languages.” We believe we have met this challenge by generating, from one PSM, code that is readable and editable for two further PSs.

The paper in the Special Issue on PSMs that is closest to our activity is that by O'Connor et al. (Reference O'Connor, Nyulas, Tu, Buckeridge, Okhmatovskaia and Musen2009). This paper discusses the (software engineering) challenges of implementing systems to process complex and diverse data sets that relate to the detection of outbreaks of infectious diseases. The first system described, BioSTORM-1, focuses on taking data from many data sources and storing it in a common data repository. The various PSMs or PSM-like agents that are then run over the data effectively extract the necessary data from the repository. That is, each PSM is associated with a mediator that converts the data in the repository to the format required by the individual PSM agent. In this system, the data transformation process is driven by an ontology that describes the data requirements of the particular PSM. The BioSTORM-1 approach has been further generalized by MAKTab (Corsar & Sleeman, Reference Corsar and Sleeman2007), which additionally acquires from the user, in a guided way, information needed by the target PS that is not available in the source KBS.

A major issue with both the CommonKADS library and the Protégé PSM Librarian is that neither supports the execution of a KBS. Having stated that CommonKADS has hundreds of PSMs, Fensel and Motta (Reference Fensel and Motta1998) state, “None of these methods is implemented.” A contemporary critique of CommonKADS (Menzies, Reference Menzies1998) makes a similar point about lack of “operationalization.” There is a similar issue with the Protégé-2000 PSM Library. The PSM librarian webpage (SMI, 2010) states: “The current version of the PSM Librarian tab does not support actual activation.” By contrast, progress has been made by a few groups in the constraint solving area, who have taken steps to generate working code from formal descriptions in Essence (Frisch et al., Reference Frisch, Harvey, Jefferson, Hernandez and Miguel2008) or Numberjack (Hebrard et al., Reference Hebrard, O'Mahony and O'Sullivan2010). However, their starting point is a piece of discrete mathematics, rather than a KBS.

In summary, successive enhancements of PSM libraries have led to a largely unused set of PSMs. This is disappointing because the central purpose of the exercise was to support reuse. Currently, PSM libraries state how to solve KB tasks in formal terms, but they do not help with the actual solution of such tasks.

2.2. The VT task

The VT domain is a complex configuration task involving a sizable number of components required to design a lift (elevator) system. These components are shown in Figure 1. The parameters, such as physical dimensions and weight, and also the choice of certain components, are regulated by physical constraints. The VT domain (Marcus et al., Reference Marcus, Stout and McDermott1988) was initially used to design lifts by the Westinghouse Elevator Company. This original VT domain knowledge was simplified by removing some antagonistic constraints (which we restored in our own studies; see Section 2.3.1) to form the knowledge acquisition Sisyphus-VT challenge. The Sisyphus version of the VT domain was created so that researchers would have a common KB for experimentation. It thus became a valuable benchmark (Schreiber & Birmingham, Reference Schreiber and Birmingham1996). It is the Protégé (v3.0) version of the VT system that has been the KB used in this project.Footnote ² This project has enabled us to test some constraint-solving PSMs (i.e., ECLIPSe) that were not available at the time of the Sisyphus challenge. We have also tackled a parametric design problem in configuration that is still a topic of industrial interest.

Fig. 1. Vertical transport system components.

2.3. The SISYPHUS-VT challenge

In many areas of computer science and artificial intelligence, benchmarks are set to evaluate the performance of a number of systems against a common set of tasks. The results of these tests are then used to identify the strengths and weaknesses of the several systems, and this in turn helps to set the future research agenda for the subfield. Therefore, the knowledge acquisition/modeling subfield set itself a number of challenges in the 1980s to 1990s that it called the Sisyphus challenges.

Seven papers were presented at the 1994 Knowledge Acquisition for Knowledge-Based Systems Workshop, each of which described a methodology for modeling and solving Sisyphus-VT; these were Soar/TAQL (Yost, Reference Yost1996), Protégé II (Rothenfluh et al., Reference Rothenfluh, Gennari, Eriksson, Puerta, Tu and Musen1996), VITAL (Motta et al., Reference Motta, Stutt, Zdráhal, O'Hara and Shadbolt1996), CommonKADS, Domain-Independent Design System, KARL/CRLM (Poeck et al., Reference Poeck, Fensel, Landes and Angele1996), and DESIRE (Brazier et al., Reference Brazier, Van Langen, Treur, Wijngaards and Willems1996). Of these seven papers, only the VITAL team reported multiple runs of their implementation (Motta et al., Reference Motta, Stutt, Zdráhal, O'Hara and Shadbolt1996). Further, Menzies (Reference Menzies1998), reviewing the above papers, emphasizes that little testing was conducted on the various methods beyond the one example, which we extended (Section 5.2).

2.4. An overview of constraint satisfaction techniques

Constraint satisfaction techniques (Van Hentenryck, Reference Van Hentenryck1989) attempt to find solutions to constrained combinatorial problems, and there are a number of efficient toolkits in a variety of programming languages. The definition of a constraint satisfaction problem (CSP) is

• • a set of variables, and for each variable X _i, a finite set D _i of possible values (its domain), and

• • a set of constraints C _j ⊆ D _j1 × D _j2 × ⋯ × D _jt, restricting the values that subsets of the variables can take simultaneously. These constraints are usually written as algebraic expressions over the variables, using the usual relational and arithmetic operators.

A solution to a CSP is a set of assignments to each of the variables in such a way that all constraints are satisfied. The main CSP solution technique is consistency enforcement, in which infeasible values are removed by reasoning about the constraints, using algorithms such as node consistency and arc consistency. CLP systems, such as ECLiPSe (see Section 2.4.1), borrow the syntax and some constructs (e.g., unification) from the logic language Prolog, but greatly improve on its performance; they do this by using CSP techniques to reorder goals dynamically within conjunctions.

Constraint propagation aims to remove early on those values that cannot participate in any solution to a CSP/CLP. It is usually activated (triggered) as soon as a new constraint is encountered, and this mechanism attempts to reduce the domains of all related variables (including domains that have been filtered by other constraints). If the domain becomes empty, then the entire subtree of potential solutions can be pruned. This is the real power of both CLP and CSP, as demonstrated by the classic eight-queens problem (Van Hentenryck, Reference Van Hentenryck1989). There is also a generalized constraint propagation technique (Le Provost & Wallace, Reference Le Provost and Wallace1991) for variables with values given in tabular form. This fits the VT problem well, because it uses such tables to describe components and their attributes (Section 4.1). It has been central to this study, but we believe that others have missed its utility, particularly when generating code as described in Section 4.

3.1. Ontological issues for knowledge extraction

The various knowledge components have to be extracted from the original KB. ExtrAKTor uses a well-designed generic ontology, developed at Stanford using Protégé (SMI, 2003). This is the “elvis” ontology that reflects the inherent structure of parametric design tasks, including P + R tasks being considered in this study. Specifically, it describes: the actual domain ontology, the data tables for component values, the domain constraints, and the fixes, (see Fig. 3). It represents this by four main classes: elvis-components, which lists the problem variable names used in the constraints (or as table column names), with their types and other metadata; elvis-constraints, which are subdivided into assign-constraints, range-constraints, and fix-constraints; elvis-fixes, which are actions to resolve constraint violations; and elvis-models for the tables, with elvis-model-slot for their slot metadata. Instance data from this ontology is shown in Section 4.2.2 and in Figure 3.

Fig. 3. Elvis: vertical transport (VT) domain ontology in Protégé.

The division of constraints into three types is interesting. An assign-constraint looks like an equality constraint between a variable and an algebraic expression, but it is simply used to calculate a value for the variable by evaluating the expression. The expression involves other variables, and thus expands into a directed acyclic graph showing variable dependency independent of the order of the constraints; a spreadsheet PS obviously computes this graph, as does a CLP PS. The range-constraints are vital to the workings of a CLP PS; they give numeric upper and lower bounds for integers and reals. The fix-constraints look like assign-constraints but are usually inequality constraints for which one or more fix actions are provided. Note that the CLP PS needs the fix-constraints, but our study shows that it does not need the fix actions (which are held for the P + R PS as elvis-fixes).

This ontology enables us to describe parametric design problems for various domains. Thus ExtrAKTor works without alteration with very different sets of variables, tables, and constraints. We have tested it with the U-HAUL vehicle assignment domain (Runcie, Reference Runcie2008). However, it does assume the KB is in the elvis constraint ontology.

Besides using elvis, the Protégé system used for the VT KB made extraction very easy, by providing alternative Tabs that behave like application programmer interfaces. We used the PrologTab to execute a small piece of Prolog code we had written to export knowledge from the Protégé environment into a knowledge interchange format (KIF) suitable for use in an external Prolog environment such as GNU Prolog. Thus ExtrAKTor assumes the abstract knowledge structures of elvis, and its inputs must be formatted as Prolog lists. Hence, in order to use a KB not in Protégé, one would need to implement a mediator to output the relevant parts of the KB in this KIF. Unfortunately, this is a well-known problem with KB reuse. The long-term solution is for constraint researchers to adopt a common ontology for their problems, which should be largely independent of the PSM/PS, as discussed in Section 6.

3.2. Extraction and creation of KBS for a spreadsheet solver

Initially we started with the Sisyphus-VT code for the P + R PSM, which consisted of 20,000 lines (421 pages) of CLIPS code, including both the domain KB and a version of the P + R algorithm. We found that this original KB covered only one VT test case and was very hard to change. Instead, we wanted a system that would check whether any changes to the configuration would still satisfy the constraints (or maybe updated ones). It was therefore decided to implement a constraint checker that would check constraints for various data sets. Microsoft Excel was the spreadsheet tool chosen because it is widely available and because it provides excellent interactive facilities for data presentation. Spreadsheets are a very widely used and industrially important PS, though not recognized as such.

The entire set of variables, their associated values, and constraints in the VT CLIPS code were extracted, and an Excel spreadsheet for the task was created (Sleeman et al., Reference Sleeman, Runcie and Gray2006). Initially this was done as an experiment, using various text editing tools. Later the process was automated, as an extension to ExtrAKTor, by taking data from a Protégé tab (as described above) and processing it with Excel macros. All the variables in the CLIPS code were assigned to cells in column 1, and the corresponding Excel formula was placed in the corresponding cell in column 2 (see Fig. 4). To make the formulae more readable, Excel's define name function was used to name the cells in column 1 with descriptive names such as “car.misc.weight,” instead of the usual “X99.” These names were also used in the formulae in the second column, for example,

$$= \hbox{door.operator.weight}+\lpar 4{\ast} \hbox{carguideshoes} \_ \hbox{weight}\rpar + \cdots$$

Fig. 4. The vertical transport (VT)-Excel emulator calculating dependent values (244 rows in spreadsheet).

Note that this has been transformed from CLIPS's prefix notation into the infix notation used by Excel. This was easily done with Excel macros. For further details see Runcie (Reference Runcie2008) and Sleeman et al. (Reference Sleeman, Runcie and Gray2006).

Tables such as Figure 5, containing component information in the original VT-Sisyphus code, were implemented as separate named Excel worksheets; these could be searched via the “LOOKUP” function. Note that the spreadsheet columns have to be named with the appropriate variable names (e.g., max.current), as discussed for the CLP version (Section 4.1.3).

Fig. 5. A component table accessed as an Excel worksheet.

The spreadsheet algorithm was then able to take the values of independent variables given to it, to use the formulae (in any order) to calculate all the other dependent variables, and also to check that the constraint formulae all evaluated to “True.” In the course of this, we discovered that there were comparatively few independent variables in the VT problem (only about 12 out of over 300). Note that Excel cannot find which independent variable values would lead to dependent variables satisfying the constraints (this is why we need ECLiPSe). Nevertheless (Section 2.2.1), a spreadsheet PSM is still a very useful way to investigate such dependencies, to check constraints, and to calculate and check aggregate values such as costs and other metrics. This shows the clear advantage of generating PSs for spreadsheets as well as CLP (Sleeman et al., Reference Sleeman, Runcie and Gray2006).

3.3. Code generation of a KB for use with ECLiPSe

Having shown that we could reuse the VT KB with a spreadsheet PS, we wanted to use a much more powerful PS based on the ECLiPSe solver (described in Section 2.4). Once again, we used the elvis ontology (Section 3.1), which describes the problem in terms of variables and various types of constraints. This fits well with the way problems are presented to CLP solvers (Section 2.4), and most important, makes our solution very general and not specific to VT. Therefore, we carried out an experiment to manually transform a subset of the VT KB into ECLiPSe syntax and to solve it with the ECLiPSe toolkit. This was very promising, so the next stage was to take the elvis data from the intermediate KIF file imported into ExtrAKTor and to transform it automatically into the ECLiPSe notation. We used GNU Prolog to do this, because it has very general pattern matching facilities and is excellent for transforming and generating program text.

A major advantage of ECLiPSe notation is that someone with an engineering training can read it and check that individual constraints are what is wanted. The person just needs familiarity with basic algebraic equations and Boolean expressions. This provides the vital reassurance that is often missing with large integrated packages. Remember that, without code generation, it is tedious to write out constraints and avoid errors, because the slightest error in a single variable name or an operator, among thousands, can render the constraint set insoluble. Our goal was to reassure anyone with an understanding of the domain ontology that they could use our tool to define a configuration problem precisely enough for a computer to generate good solutions; but he or she would NOT have to labor long and hard with unfamiliar mathematical notation. This is a crucial point, often overlooked by those devising PSMs, who forget how easily users are deterred by unfamiliar notation or concepts, so that the PSMs remain published but unused.

3.3.1. Example constraints

Our tool generates constraints that are syntactically well-formed formulae; they are algebraic expressions with the usual infix operators:

$$\eqalign {&\hbox{ic}\colon \lpar \hbox{Hoist}\_\hbox{cable}\_\hbox{traction\_ratio} \cr & \quad \gt \lpar \hbox{Groove}\_\hbox{multiplier} \,\ast\, \hbox{Machine}\_\hbox{angle}\_\hbox{of}\_\hbox{contact}\rpar \cr & \quad + \hbox{Groove}\_\hbox{offset}\rpar .}$$

The “ic:” indicates to ECLiPSe that a hybrid integer/real arithmetic constraint solver is to be used (Section 2.4.1). The identifiers have underscores as separators, as is normal in Prolog, instead of the dots used in CLIPS. More important, the names have been meaningfully constructed in this domain ontology. Table components start with a class name, such as Hoist_cable, which greatly aids readability.

Sometimes we need to generate a conditional constraint:

$$\eqalign{&\lpar \hbox{Compensation\_cable\_quantity} \gt 0 - \gt \cr & \quad \quad \quad\hbox{ic}\colon \lpar \hbox{Counterweight\_to\_platform\_rear} \gt = 1\rpar \semicolon \; \cr & \quad \quad \quad\hbox{ic}\colon \lpar \hbox{Counterweight\_to\_platform\_rear} \gt = 0.75 + 1.5\rpar \rpar .}$$

This is used as a kind of “case” construct to select a constraint. It should not be read as a kind of production rule. These are the most complicated expressions in the entire ECLiPSe KB, as can be seen in Section 4.2.1. Note that this KB is just a sequence of declarations in a simple grammar; thus, the usual text processing tools for finding names work very well for both searching and cross-checking.

The constraint information from the VT KB has been transformed, but this is not the usual syntax-directed translation done by many compiler packages; this transformation software understands the semantics of the constraint solver and reorders and restructures information to make good use of it. The major transformations involved 18 or so stored tables of component values that needed to be integrated with the constraint solver in an efficient fashion, as detailed in Section 4. Once this has been done, the KB is ready for the execution phase (Section 4.2.6 and Fig. 6).

Fig. 6. The ECLiPSe solution to the vertical transport (VT) problem with bounded reals (see Section 4.2.6).

4.1. Role of tables in the solving process

A significant innovation of our approach, as will become clear, is the use of the elvis-models component of the Protégé KB; these are structured tables of data values as in Figure 5. In a relational database, these are usually seen as tuples that group attribute values for a given entity or that represent relationships between linked entities. However, in constraint solving, they have another purpose, which is to propagate constraints. This is because the values in a column of the table implicitly define a restricted finite domain for one of the problem variables. In a simple one-column table, it does nothing else, but in a multicolumn table, there may be implicit restrictions on values in related columns that propagate to other problem variables. When the constraint solver makes good use of this information, it can speed up processing by an order of magnitude or more, which can save literally hours of processing time. The theory of this generalized constraint propagation technique was developed by Le Provost and Wallace (Reference Le Provost and Wallace1991), but without a sophisticated code generator to make use of it, in practice it seems to have been little used. We give below more details on its use than may be considered normal, but this is to enable others to repeat our experiments. This is partly because it is not described in the ECLiPSe reference book (Apt & Wallace, Reference Apt and Wallace2007) and there are very few examples online. In addition, one needs to understand the form of the declarations in order to see that they can easily be extracted from any KB using elvis, and code systematically generated.

4.1.1. Declarations referring to variables in tables

Consider the motor table below in Prolog notation corresponding to the Excel worksheet in Figure 5, which we shall use as a repeated example. It is one of 18 such tables in the VT KB. The rows contain data for the following descriptors: Motor\_model, Motor_max_power, Motor_weight, and Motor_max_current.

$$\eqalign{\hbox{motor}\lpar \hbox{``motor} \_10\hbox{HP''}\comma \; 10\comma \; 374\comma \; 150\rpar .\cr \hbox{motor}\lpar \hbox{``motor} \_ 15\hbox{HP''}\comma \; 15\comma \; 473\comma \; 250\rpar . \cr \hbox{motor}\lpar \hbox{``motor} \_ 20\hbox{HP''}\comma \; 20\comma \; 539\comma \; 250\rpar .}$$

The first column contains strings that are possible values of Motor_model, identifying a type of engine with a certain horsepower. We know this is a key or identifying attribute, and the other values in the same row refer to this specific engine type. However, the solver needs to be told this, as explained below.

The solver is told to associate each column with a particular Prolog variable (actually by an “infers most” statement, as in Section 4.1.3). Thus the variable “Motor_max_current” has to take one of the values in the fourth and last column, in this case 150 or 250. Now the solver can use this for constraint propagation in one of two ways. If it has found that the variable Motor_model has the value motor_20HP, then it knows that “Motor_max_current” depends on this and must take the value in the same row, namely, 250. However, suppose instead it has found that “Motor_max_current” has value 250, but doesn't know Motor_model. It can only deduce that its value is “motor_15HP” or “motor_20HP,” because they both have 250 in the fourth column. This fits very well with the finite domain reduction technique (an alternative value or range of values is carried forward and used to eliminate possibilities; for example, it may only match one item in a compatible column in another table, thus eliminating other alternatives). This style of reasoning is fairly easy to grasp, but it has been implemented remarkably well in ECLiPSe Propia library (ICPARC, 2003), leading to great practical benefit.

In the course of this analysis, we realized that tables need not just contain attributes of physical objects; they may instead contain numerical values for coefficients and constants used in a complex conditional formula. As long as the formula is a conjunction of repetitive disjunctions (or vice versa), the technique will work as shown in Section 4.2.5. Once again it leads to significant speedups.

4.1.2. Declaration for column types: Local domain

A local domain declaration for our motor table example looks like this:

$$\eqalign{&\hbox{\colon -local domain\lpar motor}\_\hbox{model\lpar ``motor}\_\hbox{10HP''}\comma \; \cr & \hbox{``motor}\_\hbox{15HP''}\comma \; \hbox{``motor}\_\hbox{20HP''}\rpar \rpar .}$$

This tells the solver that motor_model (the domain of the first column in the motor table) can only contain some or all of certain disjoint values, which can be strings or integers (but not a mixture).

One restriction is that different local domain sets cannot overlap, thus “motor_15HP” cannot also appear in another local domain declaration. In consequence, it is useful to specify all the anticipated values together, including some that are not currently being used, such as “motor_90HP”.

We can associate the same local domain with columns in other tables. In a relational database, these columns would usually be key columns that are then matched by a relational join operator, maybe in order to pick up values of extra attributes. It is clearly useful. We do this with the assignments:

$$\hbox{Motor\_model}\ \& \colon \colon\ \hbox{motor\_model}\comma\, \hbox{Motor\_modelA}\ \& \colon \colon\ \hbox{motor}\_\hbox{model}$$

Here Motor_model and Motor_modelA are two Prolog variables matched to separate columns in different tables that share the same local domain. Their names start with a capital letter to fit Prolog conventions.

4.1.3. Table declarations making use of propagation (Propia)

The generalized constraint propagation technique (Le Provost & Wallace, Reference Le Provost and Wallace1991) introduced the “infers most” declaration. In ECLiPSe it is implemented remarkably efficiently by the Propia library (ICPARC, 2003). As noted above, this important construct tells the solver which Prolog variables (each with a local domain) to associate with which column. In our motor example this would be

$$\eqalign{&\hbox{motor}\lpar\hbox{Motor}\_\hbox{model}\comma \; \hbox{Motor\_max\_Power}\comma \; \cr &\hbox{Motor\_weight}\comma \; \hbox{Motor\_max\_current}\rpar \;infers\, most.}$$

The variables are listed in the same order as the columns, and so where a column has no solver variable, one uses the nameless Prolog variable “_”. One infers most declaration is generated for each table, in a separate division following those for the local domains and their assignments.

The annotation infers most controls the extent of constraint propagation. An alternative with less propagation is infers unique. Technically (ICPARC, 2003), these turn any goal into a constraint. We only use it for a goal in the form of a term structure such as motor(,..,) where some of the variables have assigned local domains. Propia is told to extract the most information it can from the constraint before processing the Prolog goal. This information is then passed to the solver (by a kind of incremental compilation) so that it can explore alternative domain values efficiently in conjunction with other solver techniques without having to break off and do inefficient backtracking. The theory ensures that the new constraint accepts and rejects the same symbolic values as when using standard backtracking techniques, but with much faster processing (in our case, reducing hours to minutes).

An early use of this construct was in a previous project (Hui & Gray, Reference Hui and Gray2000) to instantiate variables in “data table functions” without backtracking. We hope our results will encourage others to appreciate its real value, especially when used in combination with code generation.

4.2. ExtrAKTor upgrade: Automatic generation

We now consider the details of the process for systematically generating ECLiPSe code and how we have been able to automate it almost completely, in a fashion that others can adapt or emulate.

4.2.2. The knowledge interchange format

ExtrAKTor works on files of objects, exported from the Protégé KB in KIF; this preserves in text form the complex directed graph connecting the objects in the KB. Sample extracts are given below for our motor system example. If one were using a KB not built with Protégé, then, in order to use ExtrAKTor, one would need to write a mediator to output the relevant parts of the KB in this KIF. (This implementation would be easy or hard depending on the differences in the knowledge representations involved.)

Below we provide an extract of an example data table from such a KIF. Basically, wherever there is an object class that is a subclass of elvis_models, with a slot name ending “_specs”, and that has one or more instances each of which has a value for the slot “model-name”, then these become a table of Prolog tuples named according to the class, with model-name values stored for convenience in the first column. Thus, the elvis ontology uses model_name as a kind of reserved word for a column of key values.

$$\eqalign{&\lpar \lsqb \hbox{elvis}\_\hbox{INSTANCE\_00059\rsqb\ of motor-system}\cr & \qquad \quad\;\lpar \hbox{has-fixconstraints} \ldots\rpar \, \lpar \hbox{has-rangeconstraints} \ldots\rpar \cr & \qquad \quad\;\lpar motor\hbox{-}specs \cr & \qquad \qquad \qquad \enspace\; \lsqb \hbox{elvis\_INSTANCE}\_{\it 00060}\rsqb \cr & \qquad \qquad \qquad \enspace\; \lsqb \hbox{elvis\_INSTANCE}\_{\it 00061}\rsqb \rpar \cr &\qquad \qquad \qquad \enspace\;\ldots\ldots \cr &\lpar \hbox{\lsqb elvis} \_\hbox{INSTANCE}\_{\it 00060}\rsqb \;\hbox{of }\, \underline{\hbox{motors}} \cr & \qquad \quad\;\lpar \hbox{max.current }150\rpar \;\lpar \hbox{weight} \;374.0\rpar \cr & \qquad \quad\;\lpar {\it model}\hbox{-}{\it name} \;\hbox{``motor\_10HP''}\rpar \cr & \qquad \quad\;\lpar \hbox{max}.\hbox{power} \;10\rpar \rpar \cr &\lpar \lsqb \hbox{elvis} \_\hbox{INSTANCE}\_{\it 00061}\rsqb \;\hbox{of} \, \underline{\hbox{motors}} \cr & \qquad \quad\;\lpar \hbox{max.current} \;250\rpar \;\lpar \hbox{weight} \;473.0\rpar \cr & \qquad \quad\;\lpar {\it model}\hbox{-}{\it name} \;\hbox{``motor\_15HP''}\rpar \cr & \qquad \quad\;\lpar \hbox{max}.\hbox{power} \;15\rpar \rpar }$$

These instances are generated as Prolog tuples (as in Section 4.1.1).

$$\eqalign{\hbox{motor}\lpar \hbox{``motor}\_10\hbox{HP''}\comma \; 10\comma \; 374\comma \; 150\rpar .\cr \hbox{motor}\lpar \hbox{``motor}\_15\hbox{HP''}\comma \; 15\comma \; 473\comma \; 250\rpar .}$$

For each table, we generate an infers most statement (Section 4.1.3) giving the variable names holding each column value; these are Motor_model, Motor_max_power, Motor_weight, and Motor_max_current. Note that the keyword model_name referred to above is mapped onto variable Motor_model, holding an instance identifier of the motor type. For each variable such as Motor_model, we generate (once only) a local_domain declaration (Section 4.1.2) and a domain assignment. In all, 18 tables were generated. Once again, Prolog pattern matching makes this very straightforward, working on the generic Prolog term structure output from Protégé’s Prolog tab.

4.2.4. Missing type information

Unfortunately, there are some situations where the elvis VT ontology does not store enough type information. For example, it may declare car.speed as type INTEGER, where we need exact values:

$$\hbox{Car\_speed} \;\colon \colon\; \lsqb 200\comma \; 250\comma \; 300\comma \; 350\comma \; 400\rsqb .$$

The values could be taken from the key column, but this needs confirmation from the designer or user.

A similar problem arises with a table relating pairs of objects for example, motormachine(“motor_10HP”, “machine_18”). Only one of the attributes can be called model name, but we need to associate models with both columns, as in “motormachine(Motor_model, Machine_model) infers most.” Unfortunately, the domain ontology just records the Machine column as “(type STRING)” without referencing its object class. Clearly, the Protégé elvis-models ontology needs to evolve to capture this additional type information; KB designers will also need to be aware of these subtleties.

4.2.5. Representing some constraints by extra tables

In a number of cases, we played the role of a skilled knowledge engineer by replacing a repetitive or awkward constraint expression by an extra table type (or by adding columns to an existing table).

Consider this long repetitive constraint expression relating to machine groove pressure:

$$\eqalign{&\lpar \hbox{or} \;\lpar \hbox{and}\; \lpar = \hbox{?car.speed}\ 200\rpar \lpar \hbox{eq ?machinegrooves-model-name} \cr &\quad\quad\hbox {machine.groove}\_\hbox{K}3269\rpar \cr &\lpar\! \gt \hbox{?machine.groove.pressure} \;\lpar ^{\ast}\, 264 \hbox{?hoistcables-diameter}\rpar \rpar \rpar \cr & \quad\quad\lpar \hbox{and} \;\lpar \!= \hbox{?car.speed}\ 400\rpar \lpar \hbox{eq ?machinegrooves-model-name} \cr &\quad\quad\hbox{machine.groove}\_\hbox{K}3269\rpar \cr & \lpar\! \gt \hbox{?machine.groove.pressure} \;\lpar ^{\ast} 194 \hbox{?hoistcables-diameter}\rpar \rpar \rpar \cr & \quad\quad\lpar \hbox{and} \;\lpar \!= \hbox{?car.speed}\ 200\rpar \lpar \hbox{eq ?machinegrooves-model-name} \cr &\quad\quad\hbox{machine.groove}\_\hbox{K}3140\rpar \cr & \lpar \!\gt \hbox{?machine.groove.pressure} \;\lpar^{\ast} 196\ \hbox{?hoistcables-diameter}\rpar \rpar \rpar \cr & \quad\quad\ldots {\it 14}\, more\, lines \,``\rpar }$$

We significantly improved upon this representation by replacing the expression with a single formula taking its parameters from the extra table as shown below.

$$\eqalign{&\hbox{machinegroovepressure}\lpar \hbox{Groove\_model}\comma \ \hbox{Car\_speed}\comma \cr& \quad\quad \quad\quad \quad\quad \quad\quad \quad\;\;\;\hbox{Groove\_pressure\_factor}\rpar \cr & \hbox{machinegroovepressure}\lpar \hbox{``machine\_groove\_K}3269\hbox{''}\comma \; 200\comma \; 264\rpar .\cr & \hbox{machinegroovepressure}\lpar \hbox{``machine\_groove\_K}3269\hbox{''}\comma \; 400\comma \; 194\rpar . \cr & \hbox{machinegroovepressure}\lpar \hbox{``machine\_groove\_K}3140\hbox{''}\comma \; 200\comma \; 196\rpar .}$$

Replacing such expressions speeds up the computation by putting it in a form that suits the ECLiPSe solver. This also makes it more readable, and some five tables were added in this way. The transformation can be applied where there is a disjunction of conjunctions of repeated expressions of the same type and form, differing only in the values of some constants that are then tabulated. However, the transformation does require the analyst to have some basic competence in both CLIPS and Prolog. In order to avoid this, one could either try to spot the repetitions by using pattern matching in Prolog or else query the end user through an elaborate visual interface. This is a direction for future work (Section 6.1).

4.2.6. Printing and returning results

The generated code is analogous to a collection of procedures to be called from a main program. Here, at the top level, the user may want to add certain extra goals as constraints. These might restrict an overall cost, number of cables, or some other important quantity. One could further restrict the design by giving a constant value to a variable, but within the range specified in the generated code.

Next one needs to call the special locate() predicate with a list of key bounded real variables to be solved for, together with the desired precision (see Section 2.4.2). Finally, one needs to specify the names of the output variables. An illustrative example of such a main program is

$$\eqalign{&\hbox{ic}\colon \lpar \hbox{Power\_min} = \lt 12\rpar \comma \; \hbox{locate}\lpar \lsqb \hbox{Car\_supplement\_weight}\rsqb \comma \; 0.01\rpar \comma \; \cr & \hbox{write}\lpar \hbox{``CSW is''}\rpar \comma \; \hbox{write}\lpar \hbox{Car\_supplement\_weight}\rpar \comma \; \hbox{nl}\comma \; \hbox{write} \cr & \quad \lpar \hbox{``Motor\_model is''} \rpar \comma \; \hbox{write}\lpar \hbox{Motor\_model}\rpar \comma \; \hbox{nl}.}$$

This would print the solution as a range of symbolic or numeric values as below:

$$\eqalign{&{\it CSW\ is}\ {\it 500.00}\_{\it 500.01} \cr & {\it Motor\_model \;is \;Motor\_model}\lcub \lsqb {\it motor}\_{\it 10HP}\comma \; {\it motor}\_{\it 15HP}\rsqb \rcub }$$

Note that, if a real variable cannot be precisely determined, a range will be reported, as for CSW above, and throughout the solver output, as shown in Figure 6. This is a major benefit, because it gives the user feedback about the precision of the solution; the user can then adjust parameters and rerun.

A tool in regular use would need the usual kind of graphic front end with pull-down menus giving lists of variables with hyperlinks to their descriptions and so on. Conveniently, the generated Prolog code can call out to such a graphic user interface (even to one written in C or Java).

Currently, we print the first solution that is found, but a future direction is to call a branch and bound package to explore a range of solutions, looking for a variable value below some desired bound. The ECLiPSe branch_and_bound library (Section 2.4.1) actually provides a predicate minimize(,) for doing this, which takes an expression for a utility function as a cost parameter. For example, one could replace the call to locate by

$$\eqalign{&\hbox{Utility} = \hbox{Car}\_\hbox{supplement}\_\hbox{weight}\comma \cr &\hbox{minimize}\lpar {\it locate}\lpar \lsqb \hbox{Utility}\rsqb \comma \; 0.01\rpar \comma \; \hbox{Utility}\rpar.}$$

5.1. Key parameters

A key parameter in the Sisyphus-VT KB is the car weight, because this affects the two most important values in the solution space, namely, machine groove pressure (MGP) and hoist cable traction ratio (HCTR), as described in the original paper (Marcus et al., Reference Marcus, Stout and McDermott1988) and in Section 2.3.1. Car weight is calculated as the sum of several variables, as described in the following equation:

$$\eqalign{&\hbox{Car\_weight = Car\_cab\_weight} + \hbox{Platform\_weight}\; +\; \cr & \quad \hbox{Sling\_weight} + \hbox{Safetybeam\_weight} + \hbox{Car\_fixture\_weight} \;+ \cr & \quad \hbox{Car\_supplement\_weight} + \hbox{Car\_misc\_weight}}$$

All these variables have dependencies, except Car_supplement_weight (CSW), which is defined in the Sisyphus-VT documentation as being either 0 or 500.

We decided to iterate CSW over a larger range of values, but our initial experiments did not show the expected relationship among CSW, MGP, and HCTR; this led to the discovery of a small but crucial error in a constraint stored in the elvis ontology. Constraint C-48 was initially generated as

$$\eqalign{& {\rm ic}\colon \;\lpar \hbox{Hoist\_cable\_traction\_ratio} \gt \lpar \hbox{Groove}\_\hbox{multiplier} \;\ast \cr & \quad \hbox{Machine\_angle\_of\_contact}\rpar + \hbox{Groove\_offset}\rpar }$$

However, on further investigation we found that the full Sisyphus-VT documentation states, “The HOIST CABLE TRACTION RATIO is constrained to be at most 0.007888 Q + 0.675 {where Q = machine angle of contact}.” This suggests that the “>” should be a “<=.” Once corrected, we then observed the expected behavior. We report this error because it shows that the modeler should never take information on trust, even if it is in an ontology and copied digitally. One needs to carry out experiments to see if the modeled behavior matches one's intuition and, if not, to explore why. This was also a practical test of the intelligibility and searchability of our generated code, when looking for constraints on variables such as HCTR and comparing them with a specification.

5.2. Comparison with published Sisyphus VT results

We provide a comparison of the experimental results of this study with the earlier results obtained by the Sisyphus-VT study reviewed in Section 2.3. We made the tasks harder by restoring the antagonistic constraints. Our results confirmed that the constant CSW was critical and had to be within certain bounds, which we determined more precisely. The speed of our system allowed us to search for solutions for a wide range of values of CSW, from 0 to 1000 in steps of 1, automatically running the KBS for each new value. Figure 7 shows the outcome of this test. We verified that, as in the original VT paper, when CSW increases, MGP increases and HCTR decreases. With steps of 50, both variables appear to change in linear fashion, but using steps of 1, we see that HCTR actually behaves in a sawtooth fashion.

Fig. 7. Vertical transport (VT) solutions for supplement weight car supplment weight (CSW) from 0 to 1000. Step 1: the decreasing sawtooth values are for the hoist cable traction ratio (HCTR), and the increasing straight line values are for the machine groove pressure (MGP).

Prior to this experiment, we did not know whether some vital information was contained in the fixes, without which the computation might not terminate. However, even after including antagonistic constraints, the computations all terminated. Even when some constraints disallowed all the solutions outside certain ranges of CSW, the system still terminated correctly, reporting there were no solutions.

On reflection, we realized that antagonistic fixes are an artifact of the P + R PSM and not inherent in the VT constraint problem. Modern constraint solvers have their own generic mechanism for deciding which goals to try, and in what sequence, and so they do not rely on ad hoc fixes from domain experts. Furthermore, they work by incrementally removing values from domains, which is a one-way process. They do not add and remove values for variables in the way that a fix can; the latter may lead to “thrashing.” The successive pruning of domains may get steadily slower (especially for bounded reals; see Section 6.1), but it will not create a loop. Hence, constraints that had antagonistic fixes gave us no special difficulties.

Note that there is always provision for a programmer to direct the solver's behavior by use of a “labeling()” predicate, which chooses the goals to try first and whether to try smaller variable values first (if values can be ordered). This does not alter what solutions are found, only the time to find them. We did not need to use this, which made generation simpler (Section 6).

We also repeated the tasks tried by VITAL (Section 2.3). These showed that for each of five given car speeds, we agreed on the value of car weight above which there were no solutions. However, VITAL could sometimes fail at lower weights when CLP did not. This showed the reliability of the CLP technique.

6.1. Future work

• • Interactive “sketch-and-refine” improvement process: This approach has been tried in the earlier stages of constraint-based design, in conjunction with an expert human designer (O'Sullivan, Reference O'Sullivan2002; Felfernig et al., Reference Felfernig, Stumptner and Tiihonen2011). Instead, we wish to use a branch-and-bound solver to improve on the initial solution values returned (Section 4.2.6). It needs a utility function to measure the improvement, and this could itself be adapted interactively by a designer, by changing weights or altering a readable formula. This very much suits the flexibility of our readable and editable code-generation approach.

• • Recognizing repetitive patterns in if-then-else rules: This would replace a group of if-then-else rules by a simpler parametrized rule that takes its values from a table (Section 4.2.5). It would enable the ECLiPSe solver to work much faster and also make the generated code more readable. In order to automate these transformations, one could try spotting the repetitions by sophisticated pattern matching in Prolog. However, it might be better to involve the end user more directly in designing the tables through a more elaborate visual interface, such as that used for capturing integrity rules for scientific databases (Gray & Kemp, Reference Gray and Kemp2006). This approach uses visual cues to generate a combination of AND and OR operators. Thus, the engineer would not have to compose Boolean expressions in a language such as CLIPS or Prolog.

• • A web service for ExtrAKTor: This would support the extraction of constraint knowledge from web sources. Tools like MUSKRAT (Graner & Sleeman, Reference Graner and Sleeman1993) would allow one to select knowledge sources that suit the preselected PS, in our case CLP. However, it still requires agreement on a common ontology and a KIF as discussed above, which would then make it possible to write mediators so that ExtrAKTor could extract knowledge from such KBs.

• • Issues with more complex search spaces: Because of its linear geometry and hence mostly linear constraints, VT is not a computationally “hard” problem. As described in Section 5, we deliberately made it harder by reintroducing antagonistic constraints and by exploring extreme ranges of the parameter CSW, but we met no obstacles. Nevertheless, other problems might include more complex nonlinear constraints, which could be generated by our code generator. This could well slow down finding solutions or even cause nontermination, because the CSP is NP-complete.

A related issue is the use of bounded reals (Section 2.4.2) to represent numerical values in ECLiPSe. Constraint propagation can be used to reduce these bounds as usual, but when precise values are sought (e.g., by the ECLiPSe locate function), the propagation mechanism can reduce the bounds for variables to large sets of subranges, which might fragment the search space and so become very slow to compute. One of the reviewers has suggested that “problem-specific fixes (or hints to the solver) derived from expert knowledge could be used to guide the search into areas of the space where solutions are expected, or they could be used to limit the search (and so sacrifice completeness in favor of efficiency).” These are challenges to CLP theorists and configuration problem researchers. Moreover, by making it possible for more engineers to use the CLP technique in a disciplined fashion, we hope that our approach will stimulate another set of benchmark problems like VT.