Dependable Systems and Software Engineering Group(4)

Nine month progress report submitted for continuation towards a PhD

Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 14 ____________________________________________________________________________________________________________(facets) are modelled as OWL Datatype properties and each of the properties can be set to a single enumerated value (tag) from a mutually exclusive pair via “owl:oneOf”. To continue grounding the example of faults represented by column “1” in Figure 3 in the context of the ReSIST KB, below is an example of the SPARQL (Prudhommeaux and Seaborne, 2005) syntax that would be required to retrieve all instances of such fault type.PREFIX resist: </ontology/resist#> SELECT ?fault WHERE { ?fault resist:has-phase-of-creation “development” . ?fault resist:has-system-boundaries “internal” . ?fault resist:has-cause “human-made” . ?fault resist:has-dimension “software” . ?fault resist:has-objective “non-malicious” . ?fault resist:has-intent “non-deliberate” . ?fault resist:has-capability “accidental” . ?fault resist:has-persistence “permanent” . }The SPARQL language also allows joining multiple result-sets via the UNION operator. This means that the earlier example regarding “Logic Bombs” could also be rewritten in terms of a SPARQL query to retrieve the union of all instances of the fault represented by column “5” and column “6” from Figure 3 as follows:PREFIX resist: </ontology/resist#> SELECT ?fault WHERE { { ?fault resist:has-phase-of-creation “development” . ?fault resist:has-system-boundaries “internal” . ?fault resist:has-cause “human-made” . ?fault resist:has-dimension “software” . ?fault resist:has-objective “malicious” . ?fault resist:has-intent “deliberate” . ### ### no value for property ?fault resist:has-capability ### ?fault resist:has-persistence “permanent” . } UNION { ?fault resist:has-phase-of-creation “development” . ?fault resist:has-system-boundaries “internal” . ?fault resist:has-cause “human-made” . ?fault resist:has-dimension “hardware” . ?fault resist:has-objective “malicious” . ?fault resist:has-intent “deliberate” . ### ### no value for property ?fault resist:has-capability ### ?fault resist:has-persistence “permanent” . } }Using the same logic, a corresponding query could be constructed to retrieve any combination of fault types from Figure 3. However this approach introduces one caveat. The performance of the UNION operator in the current draft of the SPARQL definition is far from optimal when applied over large data repositories of RDF triples. In practical

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

Nine month progress report submitted for continuation towards a PhD

Toward a Canonical Method to Solve Patterns of Ontology Modelling Issues 16 ____________________________________________________________________________________________________________the hollow boxes indicate just “necessary” conditions for instances of those classes. Figure 5(a) and 5(b) respectively, shows the graphical representation of these conditions in the Protégé ontology editor. An overview of these two ontological concepts can be found in (Horridge et al. 2004). In conclusion, the technique described of using OWL Datatype property values as “tags”, avoids imposing a fault classification overly complicated and specialized onto the ontology application, shifting the focus from having to decide where in the highly coupled taxonomy a fault instance should be classified, into selecting the suitable property values for that instanc …… 此处隐藏：7621字，全部文档内容请下载后查看。喜欢就下载吧 ……