Nine month progress report submitted for continuation towards a PhD
Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 9 ____________________________________________________________________________________________________________Very soon, important design challenges started to emerge when attempting to model some of the key concepts outlined in the stated publication. One of the concepts that generated the most modelling issues was, and still is, the concept of “fault”. Figures 1, 2 and 3 illustrate the taxonomy for the concept of “fault” that should ideally be captured by the ReSIST ontology. The background rationale of the figures in the context of dependable and secure computing can be further studied in (Avizienis et al., 2005). As Figure 1 shows, the first level of the tree diagram is referred to as the eight basic viewpoints that lead to the elementary fault classes presented in the second level of the tree. And as the paper also notes, from Figure 3 it could be inferred that if all combinations of these 8 elementary classes were possible, the total number of combined fault classes would be 256. However not all combination occur in reality and Figure 2 and 3 illustrate the 31 most likely combined fault classes as a tree and a matrix representation respectively. As can be seen the amount and complexity of overlapping information being conveyed by these figures goes beyond that found in simple taxonomies and here is where the ontology modelling challenges begin. Several design questions arose: - What concepts should be classes versus properties? - How many classes would be too many? - Should all the information conveyed by the charts be captured in the ontology model? According to (Noy and McGuinness, 2001) what determines if certain concepts should be modelled as classes or properties is how important those concepts are in the domain being modelled. To illustrate this guideline in terms of Figure 3, the Fault class could be modelled having 31 sub-classes, one for each type of combination of fault, or having a property “type-ofcombination-fault” that could be set to a value in the range {1, ..., 31}. In the case of ReSIST, from a domain point of view, all different types of faults are relevant. This fact would favour having every type of fault as a class. However, from an application point of view, it is not very likely that a person, a project, or a publication may describe its research interests in terms of Figure 3 as “Faults 5, 6 and 25” for example. Therefore, including all 31 types of faults in the model does not seem practical. Regarding how many classes would be too many, (Noy and McGuinness, 2001) concludes that the model should not include a separate class for each distinction of the concept being considered (faults in our case), but the goal should be striking a balance between creating new classes for the purpose of class organization and creating too many classes.