OWL Upper Ontology for RAL
The classes and relations of the meta model on which RAL is based, must be mapped into elements of an OWL ontology. Specifically, both classes and relations of the meta model are included in the TBox of the ontology, the former being classes (or concepts) of the ontology, and the latter being properties (also called roles) in OWL 2. We can take the names of the classes and relations of the meta model and use them for the OWL classes and properties. The hierarchies that appear in the meta model are configured in the ontology using the subclassOf axiom OWL provides. This mapping is, hence, quite straightforward because the elements used in both domains are quite similar. However, it is a little different for the part of the meta model corresponding to the organization and that related to the business process.
- As far as the organizational part is concerned, we have created one OWL class for each class of the organizational meta model. Furthermore, Position, Role and OrganizationalUnit are set as disjoint.
- Regarding the elements related to the business processes, included to be able to store run-time information for the history-aware RAL expressions, we have added one OWL class for some of the classes related to business processes, specifically for Activity, and BusinessProcess. Class RALExpression can be considered equivalent to current class Person, because a RAL expression represents a sub-set of the members of an organization. Therefore, it is not inserted as a new OWL class in the upper ontology, using Person for the same purpose. In addition, although class ActivityInstance has been added to the meta model to show the real link between the organizational meta model and the BP meta model, it actually represents an instance of an activity, so it is not part of the upper ontology, either. However, we have had to add some extra information required to deal with the negation form (i.e. operator NOT) of the history-aware RAL expressions. Specifically, class History has been created to represent the overall history of the executions of the BPs of the organization.
The relations between classes translated into OWL classes (e.g, hasCapability, occupies, canDelegateWorkTo, reportsTo, hasActivity)
are mapped into OWL properties of the TBox together with their corresponding cardinality restrictions. We have created inverse properties for most of the properties to make it easier the formulation of some RAL expressions, e.g. the inverse property of occupies is isOccupiedBy.
Properties corresponding to "reports to" relationship have been treated in a special way. Specifically, the ontology property "reportsTo" is functional, which means that "positions can report to zero or one position". However, its inverse property, "isReportedBy", is not, since a position can be reported by several positions. Furthermore, a super-property "extReportsTo" has been created to express the transitivity of this relationship, meaning that "reports to" can be propagated from position to position of an organization, with the aim of enabling stating resource assignments such as "activity A can only be done by a person who occupies the position to which reports the position to which reports a PhDStudent". So, "reportsTo" is used for direct reports (i.e., one level), and "extReportsTo" for indirect ones.
On the other hand, property "canDelegateWorkTo" is transitive because of the same reason, but there is not a functional variant of this property because the corresponding relationship in the organizational meta model has cardinality N:M.
Besides, class Activity has a data property called wasCompleted of standard type xsd:dateTime, to save the completion date of the activity.
