Domain knowledge acquisition

In order to develop a knowledge-based decision support system, it is crucial to understand the complex structure of domain knowledge before capturing it in the knowledge base. Accordingly, this section aims to provide an understanding of structural design domain and associated sustainability domain, including the key concepts, features and relationships. Due

134 to the limit time and resource of this research, it is difficult to explore all types of building structure. Therefore, a generic framework of knowledge model that covers essential structural concepts is built. Based on the framework, concrete structural design is illustrated in detail, with the intention to provide an applicable example for full range of structural design domain.

The domain knowledge acquisition is a preparation process for formal ontology development. CommonKADS knowledge engineering methodology previously introduced in Chapter 3 is adopted in this preparation process, which consists of three steps:

Step 1: Knowledge Identification

This step is used to conclude the problems in the domain, the purpose of the knowledge model, and the scope of the model. There are two key activities conducted in this step: domain familiarisation and identification of potential model component. Firstly. references of the targeting domain, including structural design codes, government standards and documents, sustainable design guidance, websites and peer-reviewed papers are reviewed and analysed. The main outcome of this activity is to understand the sustainable structural design domain, including the identification of its characteristics, current methods, barriers and potential solutions. Secondly, existing knowledge models or semantic sources are surveyed thoroughly. Some reusable ontology examples in construction domain are e-COGNOS ontology and ifcOWL ontology published by W3C community based on IFC4_ADD1. At the end of this step, the relevant domain concepts are elicited and a glossary of these terms is constructed. Elicited domain concepts consist of three categories:

1. Building structure concepts such as column, beam, slab, concrete and reinforcement are summarised from design codes or guides;

135 2. Concepts and parameters related to structural design principles; for example, strength class and other characteristics of concrete are extracted from BS 8500 Standard (British Standards Institution, 2015);

3. Sustainability data; for instance, the values of embodied energy and CO2e applied in

this study are chosen from ICE database (Jones, 2011) .

Step 2: Knowledge Specification

The main task in this step is to construct a specification for the knowledge model. It involves choosing a template and then building up a semi-formal modelling which can be executed using any modelling language such as the UML in this case (Kogut et al., 2002). The re-usable resources identified in the first step are also taken into consideration when construct the model. Figure 5.1 illustrates the specified knowledge model in an UML class diagram. The top-level concepts elicited from ifcOWL ontology constructs the generic framework of structural design knowledge model. Concepts related to the concrete structure such as cement, reinforcing bar and concrete are populated into the framework as sub-classes. The extracted concepts from structural design domain such as column, reinforcing bar and concrete are organised in a hierarchical structure, while the factors affecting sustainability include resource supplier, transport distance, material constituents are integrated into this hierarchy in different forms. In addition to the subsumption relations that exist between the top level classes and subclasses, the associations of UML including their multiplicities have been used to relate the top level concepts. For example, the multiplicity of 1. . .* on the association “isSupplierOf” that relates the “ResourceSupplier” and “MaterialDefinition” means one or more products are supplied by the resource supplier. Taking the UML diagram as a reference, OntoSCS knowledge model can be manually edited in Protégé-OWL environment following the Ontology Development 101 methodology.

136 Figure 5.1 UML class diagram of key concepts of OntoSCS ontology.

137 The challenge remains when transforming the OntoSCS UML model into Protégé-OWL ontology model. To overcome this challenge, there are two approaches available: the UML- OWL conversion tool and manual conversion approach. The initial attempt of using the UML- OWL conversion tool is not suitable due to the data loss issues. Thus, the manual conversion approach has been adopted in this study. Different elements in UML model are transformed into OWL ontology model by following conversion rules listed in Table 5.1.

Table 5.1 Conversion rules from UML to OWL.

UML OWL

Class Class

Generalisation of classes Superclass Association Object Property Attribute Data-type Property Multiplicity Functional Object Property

Step 3: Knowledge Refinement

This is the final step of knowledge modelling. Two main tasks are undertaken, knowledge model validation and refinement, where refinement is the completion of knowledge modelling. The entire process normally will be repeated several times and each step is also an iterative process. In addition, it is recommended to develop a prototype before the development of full version of knowledge model. In this case, knowledge refinement is carried out as ontology evaluation process presented in Section 5.3. The completion of the preparation tasks has accomplished a considerable portion of the formal ontology development; for example, the determination of domain scope, reuse of existing semantic resource, enumeration of terms, and arrangement of class hierarchy. However, since ontology development is an iterative process, some of the tasks that have been accomplished in preparation will be repeated in the formal development process presented in the ensuing section to refine the ontology.

138