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 mechanism for metadata annotation. Such annotation paradigm has also been coined with the neologism “folksonomy”. A growing number of internet sites are adopting this increasingly popular tag or keyword based approach to provide certain level of semantic information to their contents. Two prominent examples of such sites are “http://www.77cn.com.cn”2 and “Flikr”3. 3.1.3. An Ontology Model for the Concept of Fault With all this information at hand, what follows is a proposed model for the concept of Fault in the context of the ReSIST KB that attempts to find a compromise between all the factors discussed. The proposal presents an ontology that initially is fairly simple, yet, it provides sufficient semantic expressivity to represent instances of any type of fault from Figures 1, 2, and 3. It is inspired by two different notions of viewing concepts in a particular domain. One of them is the previously cited “folksonomy” and the reasons behind it are founded in some of the conclusions of (Shirky, 2005). The second one is based on a facetted approach to building ontologies (Pietro-Diaz, 2003) which seemed very appropriate for the challenges in our design. The initial model is quite basic. It consists of the class “Fault” and it subsumes three other subclasses: “Development-Fault”, “Physical-Fault”, and “Interaction-Fault”. As can be seen from Figure 3, all 31 combined fault classes fall into one or two of these three subclasses. Therefore, so far it is a simple way of representing all faults that are being modelled. A closer look at the matrix representation in Figure 3 shows eight rows corresponding to the eight viewpoints (or “facets”) in the “Fault” taxonomy (Figure 1), in terms of a pair of mutually exclusive attribute values for each viewpoint, and 31 columns corresponding to the most likely combined fault classes. The definition of each type of fault (column) can be given by the 8-tuple of attribute values that apply to that particular fault.2 3http://www.77cn.com.cn/ http://www.77cn.com.cn/