2.3.1. Ontological engineering methodology

The process of developing an ontology consists of activities in three different areas. First, there are ontology development activities such as specification, implementation, and maintenance. Second, there are ontology management activities such as reusing existing ontologies and quality control. Third, there are ontology support activities such as knowledge acquisition and documentation (Gomez-Perez et al., Reference Gomez-Perez, Fernandez-Lopez and Corcho2005). An ontological engineering methodology specifies the relationships among the activities and when the activities should be performed.

A tool that supports an ontological engineering methodology or technique can expedite the ontological engineering process. Currently, there are few tools that directly support an ontological engineering methodology; some existing tools include OntoEdit, which supports On-To-Knowledge (Fensel et al., Reference Fensel, Harmelen, Ding, Klein, Akkermans, Broekstra, Kampman, van der Meer, Studer, Sure, Davies, Duke, Engels, Iosif, Kiryakov, Lau, Reimer and Horrocks2002); WebODE, which supports METHONTOLOGY (Gomez-Perez et al., Reference Gomez-Perez, Fernandez-Lopez and Corcho2003); and KMS, which supports IMT (Chan, Reference Chan2004).

On-To-Knowledge is an iterative methodology that consists of five steps: feasibility study, kickoff, refinement, evaluation, and maintenance (Gomez-Perezet et al., 2005). OntoEdit provides support for ontology implementation, which happens in the third step of refinement, and maintenance (Fensel et al., Reference Fensel, Harmelen, Ding, Klein, Akkermans, Broekstra, Kampman, van der Meer, Studer, Sure, Davies, Duke, Engels, Iosif, Kiryakov, Lau, Reimer and Horrocks2002).

METHONTOLOGY is based on the software development process and provides support for the entire process during the development life cycle of an ontology. WebODE's ontology editor consists of a number of services that enable it to support various activities in the ontology life cycle defined in METHONTOLOGY. WebODE's services include ontology implementation, documentation, reasoning, and evaluation (Gomez-Perez et al., Reference Gomez-Perez, Fernandez-Lopez and Corcho2005).

As discussed in Section 2.1, the IMT is a technique for developing a classification of the knowledge elements of a domain. KMS provides automated support for developing the static and dynamic knowledge elements of a domain, and the tool was developed based on the IMT (Chan, Reference Chan2004).

2.3.2. Ontology modeling

An ontological engineering tool enables developing a knowledge or ontological model of a problem domain. A brief survey of the different ontological engineering support tools reveal there are diverse methods employed. For example, the method used by Protégé (Gennari et al., Reference Gennari, Musen, Fergerson, Grosso, Crubezy, Eriksson, Noy and Tu2003), Ontolingua (McGuiness et al., Reference McGuiness, Fikes and Feigenbaum2003), and OntoBuilder (Gal et al., Reference Gal, Eyal, Roitman, Jamil, Anaby-Tavor, Modica and Enan2006) for modeling ontologies involves listing all the concepts in a hierarchical tree, and input fields are provided to capture characteristics of concepts. A graphical method of modeling ontologies is employed in tools such as KAON OI-Modeler (Gabel et al., Reference Gabel, Sure and Voelker2004) and Protégé OWLViz Plug-in (Horridge, Reference Horridge2005b), in which the representational method uses nodes to represent concepts and edges to represent relationships between concepts.

The Unified Modeling Language (UML) tools are commonly used for visual representation and communication of software design. Because of the similarities between ontologies and object-oriented design, UML class diagrams can be used for modeling ontology classes and their properties, and relationships between classes (Cranefield et al., Reference Cranefield, Pan, Purvis and Tamma2000). However, UML's expressiveness for modeling ontologies is limited; for example, standard UML cannot express more advanced ontologies that contain descriptive logic (Gasevic et al., Reference Gasevic, Djuric and Devedzic2005).

Because of the limitations of UML, there is ongoing research work that aims to develop a graphical notation for ontologies, called the Ontology Definition Metamodel (ODM; Gasevic et al., Reference Gasevic, Djuric and Devedzic2005).

Existing ontological engineering tools can model static knowledge to varying degrees. One issue is data type support. Not all tools are capable of supporting all data types (string, integer, float, etc.). The data types supported by the tool should be investigated before the modeling process begins.

Although most tools can support representation of static knowledge, there are significant difficulties when these tools are used for modeling dynamic knowledge. The general procedure to model dynamic knowledge in tools such as Protégé, KAON OI-Modeler, and KMS consists of the following three steps:

1. 1. Create classes to represent task and objective. These are the main structures that will be used for modeling dynamic domain knowledge. It should be noted that this step is not required in KMS, as it was designed for modeling dynamic domain knowledge and most of the necessary structures are built in.

2. 2. Model the static domain knowledge.

3. 3. Model the dynamic domain knowledge by instantiating the task and objective classes that were created in Step 1.

To better illustrate the problems encountered when modeling dynamic knowledge in existing tools, the above steps using Protégé are applied to model a small part of the petroleum contamination remediation selection ontology. Protégé uses a form-based user interface for inputting knowledge; there are windows containing text fields for inputting knowledge. The application of the above steps using Protégé is described as follows:

1. 1. Create classes to represent task and objective.

   1. a. Create a new Protégé project for containing the task and objective classes.

   2. b. Create a class for representing task knowledge with the following characteristics:

      • Class Name: Task

      • Super Class: owl:Thing

      • Properties:

        1. — name (single string)

        2. — behavior (single string)

        3. — inputs

        4. — objects

        5. — output (single)

        6. — subtasks (multiple Tasks)

      The Task class properties include behavior, associated objects, and a list of sub (or dependent) tasks. In task interactions, data can be exchanged. To capture this important information, two additional properties, inputs and output are added to the Task class. A tool that supports inputs and outputs facilitates the ontology author in considering the detailed interactions between tasks and objectives; hence, a more complete model is likely to be generated.

   3. c. Task priority is a type of strategic knowledge that is most likely to be found in an industrial domain, such as petroleum contamination remediation selection. For any particular objective, the task priority specifies which tasks are required and the order in which they are to be performed. Task priority can be embedded in a prioritized list of tasks inside the objective class. However, the existing ontology tools, including Protégé, lack support for specifying the order (or priority) of specific items. This problem can be solved with the addition of an intermediate class, called TaskPriority, to relate a task to a priority. The class for representing TaskPriority is shown as follows:

      • Class Name: TaskPriority

      • Super Class: owl:Thing

      • Properties:

        1. — priority (single int)

        2. — task (single Task)

      The TaskPriority class contains the properties task (an instance of a Task) and priority (an integer), thus enabling the association of a priority to a task.

   4. d. Create a class to represent an objective with the following characteristics:

      • Class Name: Objective

      • Super Class: owl:Thing

      • Properties:

        1. — taskPriorityList (multiple TaskPriority)

        The Objective class has a property for the taskPriorityList.

2. 2. Model the static domain knowledge.

   1. a. Create a new Protégé project for containing the static domain knowledge.

   2. b. Create classes, properties, and relations.

3. 3. Model the dynamic domain knowledge.

   1. a. Create a new Protégé project for containing the dynamic domain knowledge.

   2. b. Import both the Protégé project created in Step 1 (task, objective, and TaskPriority classes) and the Protégé project created in Step 2 (static domain knowledge) in the dynamic domain knowledge project.

   3. c. Choose an objective to model. In this example, the objective, Determine Contamination Level would be modeled. This is done by creating an instance of the objective class identified as DetermineContaminationLevel. The specification of task priority (strategic knowledge) is discussed later.

   4. d. This step describes how to create a task that is required to achieve the chosen objective. In this example, a task to Calculate Weighted Normalized Benzene Concentration will be created. To model this task, the Task class is instantiated and identified with the name CalculateWeightedNormalizedBenzeneConcentration. Next the task behavior and objects can be modeled. These characteristics are shown as follows:

      • Instance Name: CalculateWeightedNormalizedBenzeneConcentration

      • Instance of Class: Task

      • behavior:

        • soilSamplingExp.benzeneConcentration =

        • soilSamplingExp.benzeneConcentration /

        • skStandard.skBenzene * benzene.contaminationWeight

      • objects: skStandard, soilSamplingExp, benzene

      An observation drawn from examining some existing ontology tools, including Protégé, is that the structure for task behavior cannot be formally represented, which results in inconsistent syntax and grammar. Consequently, machine processing of the task behavior is impossible.

   5. e. This step describes how to specify task priority, which is a type of strategic knowledge. First, an instance of TaskPriority is created and identified as tp_CalculateWeightedNormalizedBenzeneConcentration. The “tp_” prefix is used because Protégé does not allow instances to have the same name. Task Priority consists of a task and a priority number. Below is the specification for this task priority:

      • Instance Name: tp_CalculateWeightedNormalized BenzeneConcentration

      • Instance of Class: TaskPriority

      • priority: 1

      • task:  CalculateWeightedNormalizedBenzeneConcentration

   6. f. After a task priority instance has been created, it can be added to an objective. The specification for the DeterminContaminationLevel objective is as follows:

      • Instance Name: DetermineContaminationLevel

      • Instance of Class: Objective

      • taskPriorityList: tp_CalculateWeightedNormalizedBenzeneConcentration

There are two problems with this process for modeling task priority. First, the software tool requirement that the user has to create a separate entity of TaskPriority to link tasks to objectives distracts the users from the real activity of specifying strategic knowledge. The second problem is related to the visualization of the task priority list in the objective. Figure 7 illustrates the problem.

In Figure 1, the task priorities for SetContaminationLevel and CalculateWeightedNormalizedTolueneConcentration have been added to the DetermineContaminationLevel objective. From looking at the taskPriorityList, one might think the tasks are in the following priority:

Fig. 1. Determining the contamination level objective with multiple task priorities. [A color version of this figure can be viewed online at journals.cambridge.org/aie]

1. 1. CalculateWeightedNormalizedBenzeneConcentration

2. 2. SetContaminationLevel

3. 3. CalculateWeightedNormalizedTolueneConcentration.

However, the actual priority of tasks is as follows:

1. 1. CalculateWeightedNormalizedBenzeneConcentration

2. 2. CalculateWeightedNormalizedTolueneConcentration

3. 3. SetContaminationLevel.

In a form-based user interface, which is the kind adopted in Protégé, task priorities are displayed in the order that they were added. In graph-based user interfaces, such as Protégé OWLViz or KAON OI-Modeler, there is no order to the display; the user must look at a separate window or screen for the priority. Again, this problem distracts the user for the real process of knowledge modeling.

To summarize in terms of modeling dynamic knowledge, existing ontology tools demonstrate three main weaknesses. First, their inability to enforce a consistent syntax for task behavior makes computer processing of the task behavior impossible. Second, the lack of support for input and output of tasks can result in specification of an incomplete model. Third, the visualization/input fields are not user friendly for enabling the user to easily specify/visualize priority among tasks. Our research work addresses all three weaknesses.

2.3.3. Ontology testing

For ontology tools, the third area in need of improvement is support for ontology testing. Software testing is an important part of the software development life cycle because it identifies defects and results in a more stable software application. It is considerably cheaper to fix defects early in the development process. Unit testing is a method of testing the structure of a program. Unit tests can be used as regression tests to ensure that the software continues to work as expected after modifications. Catching and fixing defects in the modeling stage is less expensive and easier than in the implementation stage.

Ontology testing can also help the knowledge engineer develop a more complete model of the domain. In the ontological engineering field, ontology testing is also called ontology evaluation. According to (Gomez-Perez et al., Reference Gomez-Perez, Fernandez-Lopez and Corcho2005), ontology evaluation should be performed on the following:

1. • every individual definition and axiom,

2. • collections of definitions and axioms stated explicitly in the ontology,

3. • definitions imported from other ontologies,

4. • definitions that can be inferred from other definitions.

Existing ontology testing systems such as the OWL unit test framework (Horridge, Reference Horridge2005a) and Chimaera's (McGuiness et al., Reference McGuiness, Fikes, Rice and Wilder2000) test suite, evaluate the correctness and completeness of ontologies. Chimaera performs tests in the following four areas: missing argument names, documentation, constraints, and so forth; syntactic analysis (occurrence of words, possible acronym expansion); taxonomic analysis (unnecessary super classes and types); and semantic evaluation (slot/type mismatch, class definition cycle, domain/range mismatch; McGuiness et al., Reference McGuiness, Fikes, Rice and Wilder2000). Such testing tools are sufficient for testing static knowledge, but are not suitable for testing the interactions between behavior and objects.

Our research work aims to contribute to the field of ontological evaluation by addressing the difficult issue of testing behavior or dynamic knowledge. Our approach attempts to combine unit testing techniques with the adoption of test cases in test-driven development (TDD; Janzen & Saiedian, Reference Janzen and Saiedian2005). This is a useful hybrid approach for addressing the complex interactions of task behavior and objects. The general intuition adopted from the TDD approach of testing is that it should be “done early and done often.” In TDD, a test case is written first and then the actual module is written. Writing test cases first can be beneficial because instead of thinking of test cases as “how do I break something,” writing test cases first make you consider “what do I want the program to do.” In other words, writing test cases first make you think about what functionality and objects are required. We believe ontology development could also benefit from this kind of approach.

2.3.4. Ontology management

The support for ontology management in ontology tools is the fourth area that needs improvement. Ontology development within the SW allows anyone to create, reuse, and/or extend concepts in a distributed, heterogeneous environment. Many different versions of an ontology may be created, resulting in problems of backward compatibility. To document, track, and distribute ontologies in such an environment, an ontology management system is needed. An ontology management system is analogous to a database management system. Weaknesses of existing ontology management systems include vulnerability to malicious ontology authors, no consideration for intellectual property rights, and lack of support for ontology versioning.

2.3.5. Specific research objectives

Our survey on existing ontology tools and the weaknesses noted inform our design of a proposed suite of ontology tools. Our design objective is to construct a suite of software tools for modeling and managing knowledge. The tools should have the following characteristics:

1. 1. Provide support for a knowledge modeling technique (we adopted for this purpose, the IMT).

2. 2. Provide support for ontology management.

3. 3. Provide support for testing of the developed knowledge model.

4. 4. Provide support for diverse types of knowledge required for developing an ontological model of an industrial domain.

For illustration purposes, we applied our tool for modeling, in this case, the petroleum contamination remediation selection domain. Next the application problem domain is described.

2.4.1. Overview of petroleum contamination remediation selection

Petroleum contamination of soil and groundwater is an important environment issue because it can adversely impact the health and well-being of a community and the surrounding natural environment. Petroleum contamination is often the result of leaks and spills from petroleum storage tanks and pipelines, as shown in Figure 2. From the gas tank, contaminants first leak into the top layer of soil, then eventually through the soil, into the lower, groundwater layer. The petroleum contaminants include chemicals such as benzene, toluene, ethyl benzene, xylene, and total petroleum hydrocarbon. These chemicals can potentially cause serious health problems to humans.

Fig. 2. An overview of the contamination problem caused by petroleum production activities according to Chen (Reference Chen2001).

The process of cleaning a petroleum-contaminated site is called petroleum contamination remediation. A variety of remediation methods/technologies are available. However, different contaminated sites have different characteristics depending on the pollutants' properties, hydrological conditions, and a variety of physical (e.g., mass transfer between different phases), chemical (e.g., oxidation and reduction), and biological processes (e.g., aerobic biodegradation). Thus, the methods selected for different sites vary significantly. The decision making process for selecting a suitable method at a given site often requires expertise on both the remediation technologies and site hydrological conditions. Because selection process is complex, an automated system for supporting decision making on site remediation techniques is useful. Development of such a decision support system (DSS) can benefit from the use of SW technology like ontology construction.

2.4.2. Details of petroleum contamination remediation selection

There are two categories of remediation techniques: in situ and ex situ. In situ remediation techniques use treatments on the soil or groundwater; some examples of in situ remediation include soil flushing, biostimulation, chemical treatment, and phytoremedizition (Chan et al., Reference Chan, Huang and Hu2002). Ex situ remediation techniques involve the removal of the contaminated soil by excavation. Some examples of ex situ remediation include land treatment, chemical extraction and excavation, air stripping, and carbon adsorption (Chan et al., Reference Chan, Huang and Hu2002).

The selection of a remediation technology involves the following five factors (Chen, Reference Chen2001):

1. 1. Contaminated media: The contaminated media (soil or groundwater) can be either unsaturated or saturated. Not all of the media require cleaning. There are three possible requirements for a remedy: only the unsaturated zone needs to be cleaned, only the saturated groundwater zone needs to be cleaned, or both the unsaturated and saturated zones need to be cleaned.

2. 2. Site hydraulic conditions: The hydraulic properties of a site include the following considerations: soil permeability, site heterogeneity, and isotropism. According to these properties, a site can be classified as simple or complex.

3. 3. Estimated plume size: If the contaminated site size is small, an ex situ remediation technique is preferred; otherwise, an in situ remediation technique is recommended.

4. 4. Current phase of the immiscible contaminants: If the immiscible contaminants are present in the free phase, then oil recovery has to be considered. If the immiscible contaminants are present in the residual phase, then more complex techniques like integrated remediation technology is needed.

5. 5. Concentration of the contaminants: The concentration of the contaminants can be grouped into the three ranges of low, medium, and high. Different concentration levels of the contamination require different remediation actions.

3.4.1. TBL and interpreter

A weakness of the KMS (Chan, Reference Chan2004) is that the system does not support a formal and systematic representation of task behavior. As a result, the representation of task behavior is not formal and involves inconsistent syntax and grammar, which renders machine processing of the task behavior impossible. Dyna solves this problem by using a strictly enforced, formalized and high-level language, called TBL, for representing task behavior.

TBL supports the following basic structures that are common to most programming languages:

1. • Types: integer, float, Boolean, string

2. • Mathematical operations: +, −, *, /, %

3. • Logical operators: and, or, not, xor

4. • Conditional operators: <, >, ==, <=, >=, !=

5. • Assignment operator: =

6. • If statement, While loop, Assert statement, Return statement, Print statement

7. • Class Object Instantiation

8. • Function definition and calling

9. • Comments: #

Dyna enforces the structure of the task behavior with an interpreter, which also enables the task behavior to be run. A high-level view of the architecture of the TBL interpreter is shown in Figure 5. The interpreter consists of a lexical analyzer and a parser, which were generated using JavaCC (https://javacc.dev.java.net/) a tool for generating compilers and interpreters. The lexical analyzer breaks the input task behavior into sequences of tokens. The parser then analyzes the sequences of tokens according to the TBL grammar and generates an abstract syntax tree (AST). If the input task behavior has errors, then the parser outputs an error message. The functionality of each language element was implemented in the AST nodes; and there is an AST node for each TBL language structure. Interpretation of TBL is achieved by performing a depth-first traversal of the AST. As the AST is traversed, encountered symbols or identifiers are stored in the symbol table, values are pushed/popped on/off the stack, and instances of classes in Protégé are modified.

Fig. 5. The design of the TBL interpreter.

Two questions that might be asked are “why create TBL?” and “why not use an existing language?” Any programming language that supports the basic structures (math operators, loops, conditions, etc.) could have been used for modeling the behavior component of dynamic knowledge. The grammar describing the language, for example C++, would have been processed with a tool similar to JavaCC resulting in a lexer and parser, from which a custom interpreter could be generated. Existing programming languages have many features and language attributes, many of which are not applicable for modeling dynamic knowledge. We believe processing these languages would involve significantly more work as the extra features would have to be navigated and dealt with in some manner. Hence, it would be easier and more efficient to create a simple language and interpreter built specifically for processing task behavior. In contrast, there are nonprogramming languages that could also have been used, for example, the SW Rule Language (SWRL; http://www.w3.org/Submission/SWRL/). SWRL is a combination of OWL and Horn-like rules. SWRL can be used to model processes (Happel & Stojanovic, 2006), so it may be possible to adapt SWRL to model tasks and objectives. SWRL would be a radically different approach to modeling task behavior than the approach adopted by KMS, the system on which Dyna is based. Because the objective of Dyna was to improve upon KMS, and not a different approach, Dyna adopted TBL, which is like a programming language, for modeling task behavior.

3.4.2. Task objects

Task behavior consists of calculations and operations on static knowledge. The Task Window enables the user to select a Class in Protégé to instantiate and specify a name for the resulting object. Operations and calculations can be performed on the object and its properties using TBL. For example, car.color = “red” where car is an instance of a Car class and its property color is set to “red.” When a test case is run through the interpreter, the defined operations and calculations on the object are actually performed.

3.4.3. Task dependencies

Tasks can have interactions with other tasks. When a task requires a second task to perform its behavior, this second task is considered to be a “dependency” of the first task. Task dependencies are represented in TBL by: DependentTaskName(). Calls to dependent tasks are similar to function calls found in common programming languages. Values can be passed to the dependent task via input parameters. An output value can also be returned from the dependent task. When a dependency is encountered by the interpreter, the dependency is first added to the task's list of dependencies, then the interpreter evaluates the behavior of the dependency.

3.6.1. XML

Dyna projects are stored in the XML file format, enabling them to be shared and reused by other systems. Most of the dynamic knowledge components and their properties are represented as a hierarchy of XML elements. The following is an excerpt from the XML representation of a task:

The class objects that have been instantiated in Dyna require a link to their definitions in Protégé. Protégé can save its data, including the class object definitions, to an OWL file. OWL is an XML-based SW technology. Another XML-based SW technology, RDF, has the ability to create links to data defined in other XML-based files. An example of using RDF to link an object in a Dyna XML file to its definition in an OWL file is as follows: where rdf:resource defines where the definition of this object can be found. The static knowledge is stored in the OWL file, petrol_rem_sel.owl on a hypothetical web server at http://example.com. Benzene_B, is the identifier of the object.

3.6.2. OWL

A weakness of Dyna XML is that it lacks semantics, making it difficult to use the dynamic knowledge in other systems. To achieve true interoperability with other systems, Dyna projects can be exported to OWL, which provides semantics to XML. In this way, it is possible for another system to know, for example, that a Task is an instance of a task in the dynamic knowledge model.

The modeling of the dynamic knowledge elements was done in Protégé-OWL. There are three types of OWL to choose from: OWL Lite, OWL DL, and OWL Full. OWL Lite is the simplest, but least expressive. OWL DL is more expressive than OWL Lite. OWL Full is the most expressive, but performing reasoning on it is very difficult. The type of OWL chosen for the project was OWL DL because it is sufficiently expressive, and the purpose of modeling the petroleum contamination remediation selection domain is to eventually create a DSS, which means automated reasoning is required. OWL DL proved to be indeed expressive enough, and every dynamic knowledge element in the remediation domain was represented. The final OWL dynamic knowledge model was verified as valid OWL DL by using the WonderWeb OWL Ontology Validator (http://phoebus.cs.man.ac.uk:9999/OWL/Validator). Because the model is in valid OWL DL, any other system that can read OWL DL, will be able to use this model.

The following is a sample of the OWL code used to model the dynamic knowledge components. The OWL in this example defines a class Task and states that it is a subclass of KnowledgeComponent. There is also a definition of the property name.

Dyna's projects are exported to OWL simply by traversing the internal knowledge model and outputting each element's OWL representation to a file. The following is a sample of the OWL code for representing a task; the sample task is for deciding the number of sampling points. dyn:Task defines an instance of the Task class, with the name property set to “DecideNumberOfSamplingPoints.”

Dyna's exported OWL projects have also been verified as valid OWL DL by the WonderWeb OWL Ontology Validator.