Tag Archives: mathematical formalization

Associations between Classes

Posted on by
Reply

This far we have only considered UML classes where the attributes are primitive types rather than classes. Here we will consider UML classes that have classes as attributes. Assume we want to model projects. Assume a project must have one name, one sponsor that must be a manager and it must have a team of between 3 and 10 employees. In UML this can be stated using attributes (see Fig.1(a)) or associations (see Fig. 1(b)). For interest sake Wazlawick [1] suggests using attribute notation for data types and associations for classes. His motivation is that associations makes dependencies between classes more apparent. I usually follow this guideline myself.

Fig. 1

Fig. 1

The OWL representation for these 2 class diagrams is given in Fig. 2. The first thing to notice is that we use ObjectProperty instead of DataProperty to represent the sponsor attribute/association. Similar for the team attribute/association. Our property definitions also now have Domain and Range restrictions. When we say that Susan is the sponsor for ABC, we can infer that Susan is a manager and ABC is project. This information can be captured through Domain and Range restrictions. For the purpose of finding modeling errors in it is preferable to add Domain and Range restrictions.

Association between Classes Manchester

Fig. 2

To limit the number of employees on a team to between 3 and 10 employees we use the property cardinality restrictions team min 3 owl:Thing and team max 10 owl:Thing. It may seem strange that we use team max 10 owl:Thing rather than team max 10 Employee. Surely we want to restrict team members to employees? Well true, but that is achieved through our range restriction on the team object property. Here we restricting our team to 10 whatever classes and the range restriction will infer that the team must be of type Employee.

References

1. R. S. Wazlawick, Object-oriented Analysis and Design for Information Systems: Modeling with UML, OCL and IFML, Morgan Kaufmann, 2014.

 

Inheritance

Posted on by
Reply

In this post we will look at how different types of inheritance can be translated to OWL. We consider the case where Person is specialized by Employee and Client (Fig. 1). In a UML class diagram if inheritance is not annotated the default annotation {incomplete, disjoint} is assumed. incomplete means there are instances of Person which are neither of type Employee nor Client. disjoint means there is no instance of Person that is both of type Employee and of type Client. The set representation is given in Fig. 2 and the OWL translation in Fig. 3.

InheritanceDefault

Fig. 1

InheritanceDefaultSet

Fig. 2

InheritanceDefaultOWL

Fig. 3

The annotation {complete, disjoint} means every instance of Person is either a instance of Employee or an instance of Client(Fig. 4). The corresponding Venn diagram is  given in Fig. 5 and the OWL translation in Fig. 6.

InheritanceCompleteDisjoint

Fig. 4

InheritanceCompleteDisjointSet

Fig. 5

InheritanceCompleteDisjointOWL

Fig. 6

When overlapping is used rather than disjoint it means an instance of Person may be both of type Employee and of type Client.  Fig. 7 – 9 provides a UML class diagram, Venn diagram and OWL translation as example for the annotation {incomplete, overlapping}. Fig. 10 – 12 provides a UML class diagram, Venn diagram and OWL translation as example for the annotation {complete, overlapping}.

InheritanceIncompleteOverlapping

Fig. 7

InheritanceIncompleteOverlappingSet

Fig. 8

InheritanceIncompleteOverlappingOWL

Fig. 9

InheritanceCompleteOverlapping

Fig. 10

InheritanceCompleteOverlappingSet

Fig. 11

InheritanceCompleteOverlappingOWL

Fig. 12

What are Description Logics?

Posted on by
Reply

Description logics (DLs) are syntactic variants of first-order logic that are specifically designed for the conceptual representation of an application domain in terms of concepts and relationships between concepts [1].

 
Expressions in DLs are constructed from atomic concepts (unary predicates), atomic roles (binary predicates) and individuals (constants). Complex expressions can be built inductively from these atomic elements using concept constructors. Formally a concept represents a set of individuals and a role a binary relation between individuals [2].

 

Formally every DL ontology consists of a set of axioms that are based on finite sets of concepts, roles and individuals. Axioms in a DL ontology are divided into the TBox, the RBox and the ABox. A TBox is used to define concepts and relationships between concepts (that is the terminology or taxonomy) and an ABox is used to assert knowledge regarding the domain of interest (i.e. that an individual is a member of a concept). Depending on the expressivity of the DL used, an ontology may include an RBox. An RBox is used to define relations between roles as well as properties of roles [2].

 

A feature of DLs is that they have decidable reasoning procedures for standard reasoning tasks.  This means these reasoning procedures will give an answer, unlike undecidable reasoning procedures which may not terminate and thus may not give an answer.  A fundamental goal of DL research is to preserve decidability to the point that decidability is considered to be a precondition for claiming that a formalism is a DL. Standard DL reasoning algorithms are sound and complete and, even though the worst-case computational complexity of these algorithms is ExpTime and worse, in practical applications they are well-behaved [3].

 

Standard reasoning procedures for DLs are the following [2].

  • Satisfiability checking checks that every axiom in an ontology can be instantiated. Axioms that cannot be instantiated indicates that modelling errors exist within the ontology.
  • Consistency checking checks whether there are axioms that contradict each other, which again is indicative of modelling errors.
  • Subsumption checking checks whether an axiom subsumes another axiom, which is used for classifying axioms into a parent-child taxonomy.

 

Various DLs exist with different levels of expressivity and computational complexity. The most widely supported DL is SROIQ(D) which forms the mathematical basis of the W3C OWL 2 standard [4]. In OWL concepts are referred to as classes, roles are referred to as properties and individuals are still referred to as individuals.

 

In subsequent posts I will provide an intuitive understanding of OWL 2 and explain some of its uses. If you are using OWL or other semantic technologies, I will love to hear from you. Please leave a comment and feel free to explain the novel ways in which you use semantic technologies.

 

Bibliography

[1] D. Berardi, D. Calvanese and G. De Giacomo, “Reasoning on UML class diagrams,” Artificial Intelligence, vol. 168, no. 1-2, p. 70–118, 2005.

[2] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi and P. F. Patel-Schneider, The Description Logic Handbook: Theory, Implementation and Applications, Cambridge University Press, 2007.

[3] F. Baader, “What’s new in Description Logics,” Informatik-Spektrum, vol. 34, no. 5, p. 434–442, 2011.

[4] W3C, “OWL 2 Web Ontology Language – Document Overview (Second Edition),” W3C, 11 December 2012. [Online]. Available: https://www.w3.org/TR/owl2-overview/. [Accessed 9 September 2017].