Nine month progress report submitted for continuation towards a PhD
Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 15 ____________________________________________________________________________________________________________terms, an alternative to avoid this limitation would be performing the necessary queries separately, and use additional software logic to combine the individual results. The processing time overhead of the software might still prove more efficient than using the UNION operator. Nonetheless, from an ontology modelling perspective, the underlying principle that is being put forward, is that the proposed approach to model the multidimensional concept of “Fault” is capable of representing and retrieving any individual fault type as well as any combination or clustering of them, allowing looking at the concept of “Fault” and its instances from any of its overlapping viewpoints or facets. There is another important characteristic found in the matrix representation of faults in Figure 3 that might be worth noting because it illustrates the ontological concepts of “necessary” and “necessary and sufficient” conditions and it ties together the selection of classes and properties described for the proposed ontology here.(b) Physical Faults (a) Development FaultsFigure 5 - Conditions in the ontology model for: development faults (a), physical faults (b) and interaction faults (c). (c) Interaction Faults Looking at the concept of “Physical Fault” in Figure 3 for example, it can be seen that all faults that belong to this category has in common that the value for the “Dimension” viewpoint is set to “Hardware Fault” and vice versa. If a fault is of type “Hardware Fault” for its “Dimension” facet then it belongs in the category “Physical Fault”. (Note in Figure 3 the solid blue round box along the row labelled “Hardware Faults”). This implication both ways represents a “necessary and sufficient” condition for all instances of the class “Physical-Fault” in our ontology with respect to the value of the property “hasdimension”, and its graphical representation in Protégé is shown in Figure 5(b). The same rationale applies to the concept of “Development Faults” and “Interaction Faults” in Figure 3. The solid boxes indicate “necessary and sufficient” conditions, while