Dependable Systems and Software Engineering Group(3)

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.

Nine month progress report submitted for continuation towards a PhD

Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 10 ____________________________________________________________________________________________________________Properties of the class Fault in the ontology model (facets)Values for the properties in the ontology model (tags)Figure 1 - The elementary fault classes.Figure 2 - Tree representation of the classes of combined faults.

Nine month progress report submitted for continuation towards a PhD

Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 11 ____________________________________________________________________________________________________________Faults is-a is-a is-aThis property value is a necessary and sufficient condition for all faults of type development fault This property value is a necessary condition for all faults of type development fault This property value is a necessary and sufficient condition for all faults of type physical fault This property value is a necessary and sufficient condition for all faults of type interaction fault This property value is a necessary condition for all faults of type interaction faultFigure 3 - Matrix representation of the classes of combined faults. For ReSIST, and again with application use in mind, it would seem unnecessary to create classes for all types of faults, provided that users of the knowledge base may never populate many of those classes with any instances, simply because they may not describe their research interest in those terms. For this reason, ontology use, together with the notion of building an ontology fit for purpose, it would not deem appropriate attempting to model all the information conveyed by Figures 1 to 3, in terms of one class for every type of fault, with the additional need to provide axioms, domain and range information for each class. This addresses the question of how much information to model. Selecting an adequate level of detail to model would

Nine month progress report submitted for continuation towards a PhD

Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 12 ____________________________________________________________________________________________________________prevent the need to prune or winnow the ontology later after deployment (Alani et al., 2006). An additional disadvantage of modelling all the information portrayed in Figures 1 to 3 is that if new types of faults appear over time, the ontology would not be up-to-date. This is true for any domain that is modelled by an ontology. If the reality of the target domain changes the ontology would have to change accordingly. This limitation in the validity of ontologies over time is one of the main arguments in (Shirky, 2005), who question the value of predetermined taxonomies in favour of more flexible and maintainable structures, based on user-created tags as the main mech …… 此处隐藏：8003字，全部文档内容请下载后查看。喜欢就下载吧 ……