Ontology-driven model for rule extraction

For dealing with maintenance issues, knowledge classes could group the related knowledge together to improve the maintenance of the rules. As for construction issues, ontology could still play an important role even though it is not easy to extract rules directly from the ontology. First, as described above, the ontology could be used as the common language between knowledge engineers and domain experts. Second, the ontology provides the hints of rules extraction to assist knowledge engineers in interviewing domain experts.

Knowledge Class Facts/Rules Loading Phase 1:

Ontology Construction

Attribute ordering table

Phase 2:

Knowledge class organization

Fig. 5.2: Ontology to DRAMA knowledge class

As shown in Fig. 5.2, we propose an ontology-driven model for rules extraction.

The whole process is described as follows:

„ Ontology construction phase

The first phase is ontology construction. Up till now, the ontology building process is still a craft rather than an engineering activity [HS+97]. Each development team usually follows its own set of principles, design criteria and phases on the ontology development process. In Chen et al. (2003), we proposed to construct ontology by using a hybrid method consisting of the brainstorming and use case modeling [Cockburn97]. Fig. 2.3 shows a snapshot of the DNS ontology. The DNS construction algorithm is summarized as follows:

Algorithm 5.1: DNS ontology constructing algorithm Input: Every kind of DNS cases.

Output: DNS Ontology.

Step1: Build the Skeleton DNS ontology (top-down) Step2: Initiate (or conduct) use case modeling

Step3: Conduct the attributes and relation extraction.

Step4: Merge the ontological components collected in Step1 and Step3 above.

Step5: Experts verify the ontology.

Step6: After experts’ verification, the DNS ontology is constructed to cover DNS domain knowledge.

„ Knowledge class organization phase

As described above, since the knowledge class of NORM knowledge model is based on the concepts, the transformation between the ontology concept class and the knowledge class could be very straightforward. However, generally speaking, the knowledge for specific domain is usually large and we need some directions to narrow down the scope. In other words, the major problem on “which concept classes need to be transferred” should be determined. The ontology relationships could give

67

us some hints during the transformation. For example, the DNS diagnosis application focuses on the DNS problems, so the knowledge engineer needs to explore the DNS related problems first. Therefore, we could transfer the major ontology concept classes about DNS diagnosis into the corresponding knowledge classes as described in Fig. 5.3.

Fig. 5.3: The knowledge class structure of diagnosis service

In the process of DNS construction, we should consider DNS issues including availability, performance and registration, etc. Fig. 5.3 shows the inference scheme of diagnostic examples about DNS-related mailing problems. The rectangles mean KC’es in NORM and the rounded rectangles mean cases of some particular KC’es. In addition, the solid lines indicate relations of the KC’es and their correlated cases.

As specified in Fig. 2.3, the “Rel” relationships in DNS ontology show the DNS-related issues during building a DNS server. We may need to decompose the concepts into smaller sub-concepts to help analyze the cases. In this thesis, a top-down approach is adopted to explore the knowledge; that is, we start from general concepts and then drill down to specific concepts. In addition, the relationships

between knowledge classes are constructed as well. For example, there exists an

“is_a” relationship between the DNS availability concept and the SPOF concept.

Therefore, when considering the DNS availability issue, we should take measures to avoid the SPOF problem. The whole process could be summarized as follows:

Algorithm 5.2: Ontology to knowledge class transformation algorithm Input: DNS ontology

Output: DNS Knowledge Classes and the relationships of Knowledge classes

Step1: Transfer the needed ontology concepts into knowledge classes: For each DNS ontology concept, we could transfer the concept into the knowledge class.

Step 2: Define or identify the relationships between the knowledge classes.

Step 2.1: If there is an “Is_a” relationship between concept Ontology_X and concept Ontology_Y, we could infer that concept Ontology_X inherits concept Ontology_Y and that introduces the “Extension-of” relationship between the knowledge classes KC_X and KC_Y.

Step 2.2: If there is a “Rel” relationship between concepts Ontology_X and Ontology_Y, we could infer that when we talk about Ontology_X, we may talk about Ontology_Y as well. Therefore, that introduces the “Acquire”

relationship between the knowledge classes KC_X and KC_Y.

Step 2.3: If there is a “Rel” relationship between concept Ontology_X and concept Ontology_Y, and “Case” relationship between concept Ontology_Y and concept Ontology_Z, then that means concept Ontology_X may reference Ontology_Z. So, that introduces the “Reference” relationship the knowledge classes KC_X and KC_Z.

Step 2.4: If there exists other relationship between any pair of concept Ontology_X

69

and concept Ontology_Y, KEs should contact the domain experts for further analyzing.

„ Facts/rules loading phase

As described above, the KC consists of rules, relations (with other KCs) and fact declarations. After the KC organization stage, the KCs hierarchy is built but the rules and facts of the KCs are still empty. Next, in the facts/rules-loading phase, we will load the facts and rules into the corresponding KCs. In this phase, we could further divide the stages into two sub-phases.

„ Cases Æ Attribute ordering table

As mentioned in [GS92], Personal Construct Psychology (PCP), developed by George Kelly in the early 1950s, has wide application in modeling human knowledge processes. PCP gives an account of how people experience the world and makes sense of that experience. The repertory grid was an instrument designed by Kelly to bypass cognitive defenses and give access to a person’s underlying construction system by asking the person to compare and contrast relevant examples. In this thesis, we make use of repertory grid like concept to help elicit knowledge. Table 5.1 shows the four cases resulting in SPOF. Knowledge Engineers construct the empty attribute ordering table first and then interview the domain experts to fill in the table with appropriate value. The value indicates whether the case relates to the attributes or not. Table 5.2 shows the ordering table of single server and single network.

Table 5.1: SPOF case description

Description DNS server is the infrastructure of the Internet, and if your DNS is unavailable at all times, the services depending on DNS (such as WWW, Email etc.) will fail as well.

Case NO. Case Name Description Actor

Case 1 Single DNS Server You have only one DNS server listed for your domain

DNS

Case 2 Improper DNS

configuration

Of the servers listed for your domain, only one of them is properly configured for your domain.

DNS

Case 3 The same physical position

All of the DNS servers that are both listed in your domain registration and properly configured for your domain reside on the same physical subnet, or in the same physical location, or otherwise rely on any one single piece of equipment.

DNS

Case 4 The same router All the DNS servers are behind the same router

DNS

Table 5.2: Attribute ordering table for single server/single server cases Single Server Single Network

NS Record 5 1

Table 5.3: Attributes and values of NS Records for Single Server

Attribute Value

The Number of NS Record < 2

71

The IP address of NS Records Master DNS and Slave DNS are not alive.

Table 5.4: Attributes and values of physical location for Single Network

Attribute Value

Table 5.5: SPOF pseudo rules

Case Name Rule

Single DNS Server If number of NS Record <2,

Then SPOF (Single Point Of Failure) Improper DNS

If master DNS Server and slave DNS server are in the same network location,

Then SPOF

The same router If the location of Master and Slave DNS servers are behind the same router,

Then SPOF

„ Attribute ordering table Æ Pseudo rules

After the generation of repertory grid, we need to analyze the higher relative attributes of the cases. For example, when we refer to NS record attribute, we will refer the number of NS record and the IP address of each NS record as well. That is, we would like to find out the attribute/value pair of the facts. As described above, ontology contains the attributes of the concepts. Therefore, KEs could conduct the ontology to construct the empty attribute table for the higher relative slot of repertory grid and then interview the domain experts to fill in the values of the attributes. Table 5.3 and Table 5.4 show the attribute/value pair tables for single network and single

server respectively. Finally, KEs could generate the pseudo rules, as shown in Table 5.5, based on the attribute/value pair.

In practice, while the KEs often do not have much knowledge about the problem domain, the domain experts usually do not have the programming concepts. Pseudo rules, viewed as the bridge between the domain experts and the KEs, are abstractions of the cases. They are understandable for the KEs and easier to be verified by the domain experts. If there is anything wrong, the domain experts could tell the KEs to modify the pseudo rules.

Algorithm 5.3: Knowledge class facts/rules loading algorithm Input: DNS ontology

Output: DNS Knowledge Class with facts and rules

Step 1: Find out the ontology concepts that contain “Case” relationship.

Step 2: Choose exemplary attributes that could characterize the domain.

Step 3: Interview domain experts to rate each case based on the attributes. The value of the slot ranges from 1 to 5, where 5 means highly related with the construct while 1 means lowly related.

Step 4: Find the highly related constructs and further analyze.

Step 4.1: Conduct the ontology to construct the attribute tables.

Step 4.2: Interview the domain experts to fill in the values of the attribute tables.

Step 5: Generate pseudo rules, where facts coming from the attributes/values pairs of step 4.1.

Step 6: Verify the pseudo rules by domain experts and ask the KEs to modify the pseudo rules if needed.

73