Aneta Poniszewska-Maranda
email: anetap@ics.p.lodz.pl

UML representation of extended role-based access control model with the use of usage control concept

This paper presents an extension of role-based access control model with the use of usage control concept together with its representation using the Unified Modeling Language (UML). The presented model is developed for role engineering in the security of information system. The presented implementation of URBAC (Usage Role-Based Access Control) model consists in creation of security profiles for the users of information system.

Introduction

Recently, rapid development in different technologies of information systems have caused the computerizing of many applications in various business areas. Data has become very important and critical resource in many organizations and therefore efficient access to data, sharing the data, extracting information from the data and making use of the information has become an important and urgent necessity.

Access control is a significant part of each information system. It is concerned with determining the allowed activities of system users and mediating every attempt by a user to access a resource in the system. The evident objective of access control is to protect the system resources from any undesired user accesses. Nowadays, the access control is connected with the great development of information technologies and methodologies that allow to create more complex, dynamic information systems.

Data protection against improper disclosure or modification in the information system is the important issue of each security policy realized in the institution. Access control policies, strategies or models should also be changed to manage the security requirements of modern information systems (e.g. to manage the dynamic aspects of access control), such as dispersion of data and resources, dynamic changes both in data proprieties and users' proprieties, responsibilities and abilities from the point of view of access control rules, dispersion of users, complex system organization with different users, rules and security principles that are sometimes mutually exclusive. On the other hand, distributed information systems or federation of information systems provide the access of many different users to huge amount of data, sometimes stored in different locations and secured by different strategies, security policies and models or inner enterprise rules. These users have different rights to the data according to their business or security profiles that depend on their organization positions, actual locations and many other conditions. The system data is transferred between the particular nodes of distributed system.

It is also important to protect the information against non-controlled utilization and control the usage and diffusion of the information. It gives the possibility to specify how it can be used and specify the utilization constraints. It seems, the new mechanisms of access control security should be defined to apply for distributed information systems.

Compared to the traditional models, URBAC approach assures the usage control in data accessing that is very important, especially in distributed information systems, and the organization of the access control strategies welldescribed in RBAC (Role-Based Access Control) model or its extensions. In the paper we propose the new access control approach for dynamic, complex information systems that additionally provides the common coherence of information system components on the global level of access control strategy.

This paper presents an extension of the role-based access control model with the use of usage control concept together with its representation using the Unified Modeling Language (UML). The presented model is developed for role engineering in the security of information system. The presented implementation of RBAC model consists in creation of security profiles for the users of information system. The entire procedure is performed in two stages: defining the permissions assigned to a function and providing the definitions of functions assigned to a particular role.

The paper is structured as follows: section 2 presents the related works on access control concepts, section 3 deals with security requirements of dynamic information systems and describes the extension of access control model for dynamic information systems. Section 4 shows the representation of URBAC approach using the UML concepts while section 5 describes the rules for production of roles based on URBAC approach.

Role concept and usage concept in access control

The development of access control policies and models has a long history. It is difficult to mention all the access control models that were specified in literature and this is not the objective of this paper. It is possibly to distinguish two main approaches. The first one represents the group of traditional access control models. Discretionary Access Control (DAC) model [START_REF] Castaro | Database Security[END_REF][START_REF] Dows | Issues in discretionary access control[END_REF], the first model in these group, manages the users access to information based on user identification and on the rules defined for each user (i.e. subject) and each object in the system using the access control matrix. However, the DAC model has the inherit weakness that information can be copied from one object to another and it is difficult for DAC to enforce the safety policy and protect the data against some security attacks.

In order to prevent the shortcomings of DAC model, the Mandatory Access Control (MAC) model was created to enforce the lattice-based policies [START_REF] Castaro | Database Security[END_REF]. In this model each subject has their own authorization level that permits them the access to objects starting from the classification level, which has lower or equal range. MAC does not consider the covert channels but they are expensive to eliminate. Next, Sandhu et al. proposed the Role-Based Access Control (RBAC) model [START_REF] Sandhu | Role-Based Access Control Models[END_REF][START_REF] Ferraiolo | Proposed NIST Role-Based Access control[END_REF] that has been considered as an alternative to DAC and MAC models. This model requires the identification of roles in a system. The RBAC model was a progress in access control but it is still centered around the access control matrix and has static character, particularly from the point of view of distributed information systems [START_REF] Sandhu | Role-Based Access Control Models[END_REF].

The second approach of access control models corresponds to the temporal models that introduce the temporal features into traditional access control. The temporal authorization model was proposed by Bertino and al. in [START_REF] Bertino | Temporal Access Control Mechanism for Database Systems[END_REF] that is based on the temporal intervals of validity for authorization and temporal dependencies among authorizations. Next, the Temporal-RBAC (TRBAC) model was proposed in [START_REF] Bertino | A Temporal Role-based Access Control Model[END_REF]. This model introduces the temporal dependencies among roles. Other model -Temporal Data Authorization model (TDAM) was presented in [START_REF] Gal | An Authorization Model for Temporal Data[END_REF] and extends the basic authorization model by temporal attributes associated to the data such as transition time or valid time. Recently, the TRBAC model was extended to Generalized Temporal RBAC (GTRBAC) model in [START_REF] James | A Generalized Temporal Role-Based Access Control Model[END_REF] to express the wider range of temporal constraints.

Currently, traditional access control models are not sufficient and adequate in many cases for information systems, especially modern, dynamic, distributed information systems, which connect different environments by the network. Some disadvantages of these models in security domain were found [START_REF] Goncalves | Role engineering: from design to evaluation of security schemas[END_REF]:

traditional access control models provide only the mechanisms for definition of authorizations but do not give the possibility to define the obligations or conditions in the access control, access rights can be only pre-defined by the developers or security administrators and granted to the subjects, decision about the access can be only made before the required access, not during the access, it is not possibly to define the mutable attributes for subjects and for objects.

These disadvantages and the needs of present information systems caused the creation of unified model that can encompass the use of traditional access control models and allow to define the rules for dynamic access control. Two access control concepts are chosen in our studies to develop the new approach for dynamic information systems: role concept and usage concept. The first one allows to represent the whole system organization in complete, precise way while the second one allows to describe the usage control with authorizations, obligations, conditions, continuity (ongoing control) and mutability attributes.

Role-Based Access Control (RBAC) [START_REF] Sandhu | Role-Based Access Control Models[END_REF][START_REF] Ferraiolo | Proposed NIST Role-Based Access control[END_REF] requires the identification of roles in a system. The role is properly viewed as a semantic structure around which the access control policy is formulated. In extended RBAC (eRBAC) model [START_REF] Poniszewska-Maranda | Representation of extended RBAC model using UML language[END_REF][START_REF] Poniszewska-Maranda | Access Control Coherence of Information Systems Based on Security Constraints[END_REF] each role realizes a specific task in the enterprise process and it contains many functions that the user can take. For each role it is possible to choose the necessary system functions. Thus, a role can be presented as a set of functions that this role can take and realize.

The Usage Control (UCON) [START_REF] Lazouski | Usage control in computer security: A survey[END_REF][START_REF] Pretschner | Distributed usage control[END_REF][START_REF] Zhang | Formal Model and Policy Specification of Usage Control[END_REF] is based on three sets of decision factors: authorizations, obligations and conditions that have to be evaluated for the usage decision. The obligations and conditions are added in the approach to resolve certain shortcomings characteristic for the traditional access control strategies.

Access control approach for dynamic information systems

Actual information systems can contain many different components, applications, located in different places in a city, in a country or on the globe. Each of such components can store the information, can make this information available to other components or to different users. The authorized users accessing the information can change this information, its status, role or other attributes at any time. These changes can cause the necessity of modifications in security properties of accessed data on access control level. Such modifications are dynamic and often should be realized ad hoc because other users from other locations can request the access to the information almost at the same time. Many different users from different locations can access information system. Sometimes, they need to have the direct and rapid access to actual information. However, the conditions of such access are very often dynamic, they can change for example because of actions of other users. It is necessary to ensure the ad hoc checking of current rights of an user basing on their current conditions that can change dynamically.

An example can be a health-care system that contains the sensitive information and should provide secure access to highly sensitive patient information over Internet. Patient records can be modified by a primary physician or by a specialist and almost at the same time can be used by the receptionist to schedule the consultation or special treatment. Some patient records, new or modified, can be sensitive and closed to other users. Decision to allow the access to these records or not should be taken ad hoc basing on new attributes or modified attributes related with information that can change dynamically depending on the accesses of authorized users and its operations and transaction of these data.

Therefore, there is the need to have the access control approach that will describe the organization that should be secured, their structure in proper and complete way, like RBAC model does, and on the other hand it will be appropriate and sufficient for dynamic information system, like usage control concept.

Usage Role-based Access Control approach

The proposed access control approach is based on two access control concepts: role concepts and usage concepts. It was named Usage Role-based Access Control (URBAC).

The core part of URBAC approach essentially represents the extended RBAC model (Fig. 1). We distinguished two types of users in URBAC: single user (User ) and group of users (Group). These two elements are represented by the element Subject that is the superclass of User and Group. Subjects can be regarded as individual human beings. They hold and execute indirectly certain rights on the objects [START_REF] Poniszewska-Maranda | Implementation of Access Control Model for Distributed Information Systems using Usage Control[END_REF]. Subject permits to formalize the assignment of users and groups to the roles. Subject can be viewed as the base type of all users and groups in a system. It can be presented as an abstract type, so it can not have direct instances -each subject is either a user or a group. A User is a human being, a person or a process in a system, so it represents the system entity, that can obtain some access rights in a system. Group represents a group of users that have the same rights. Subjects can be assigned to the groups by the aggregation relation SubjectGroup that represents an ordering relation in the set of all system subjects. Groups of users are often created in enterprise management information systems as PLM systems or ERP systems to provide the possibility to assemble a set of people in a group with the same obligations, responsibilities or privileges (e.g. persons that realize the same business project in an enterprise).

The Session element represents the period of time during which the user is logged in a system and can execute its access rights. In our model the Session is assigned directly to the Subject, i.e. an individual user or a user from a group is login into information system during a single session. On the other hand a session is connected with the roles and this association represents the roles that can be activated during one session.

A Role is a job function or a job title within the organization with some associated semantics regarding the authority and responsibility conferred on a member of the role. The role can represent a competency to do a specific task, and it can embody the authority and responsibility. The roles are created for various job functions in an organization.The users are assigned to the roles, based on their responsibilities and qualifications. The direct relation is established be-tween roles and subjects that represent the users or groups of users. The user can take different roles on different occasions and also several users (Group element) can play the same role. It is also possible to define the hierarchy of roles, represented by aggregation relation RoleHierarchy, which presents the inheritance relations between the roles. Hierarchy of roles represents also the inheritance relations between the roles. The role of the part end of the relation inherits all privileges of parent role. The association relation between the roles and subjects is described by the association class SubjectAttributes that represents the additional subject attributes (i.e. subject properties) as in usage control. Subject attributes provide additional properties, describing the subjects, that can be used for the usage decision process, for example an identity, enterprise role, credit, membership, security level.

Each role allows the realization of a specific task associated with an enterprise process. A role can contain many functions Function that a user can apply. Consequently, a role can be viewed as a set of functions that this role can take to realize a specific job. It is also possible to define the hierarchy of functions, represented by relation named FunctionHierarchy, which provides the hierarchical order of system functions. Hierarchy of functions, just like hierarchy of roles, represents also the inheritance relations between the functions. The function of the part end of the relation inherits all privileges of the parent function.

Each function can perform one or more operations, a function needs to be associated with a set of related permissions Permission. A function can be defined as a set or a sequence (depending on particular situation) of permissions.

To perform an operation one has the access to required object, so necessary permissions should be assigned to corresponding function. Therefore, all the tasks and required permissions are identified and they can be assigned to the users to give them the possibility to perform the responsibilities involved when they play a particular role. Due to the cardinality constraints, each permission must be assigned to at least one function to ensure the coherence of the whole access control schema [START_REF] Pretschner | Distributed usage control[END_REF].

The permission determines the execution right for a particular method on the particular object. In order to access the data, stored in an object, a message has to be sent to this object. This message causes an execution of particular method Method on this object Object. Very often the constraints have to be defined in assignment process of permissions to the objects. Such constraints are represented by the authorizations and also by the obligations and/or conditions.

Authorization (A) is a logical predicate attached to a permission that determines the permission validity depending on the access rules, object attributes and subject attributes. Obligation (B) is a functional predicate that verifies the mandatory requirements, i.e. a function that a user has to perform before or during an access. They are defined for the permissions but concerning also the subjects -Subject can be associated with the obligations which represent different access control predicates that describe the mandatory requirements performed by a subject before (pre) or during (ongoing) an access. Conditions (C) evaluate the current environmental or system status for the usage decision concerning the permission constraint. They are defined also for the permissions but they concern the session -Session can be connected with the set of conditions that represent the features of a system or application.

A constraint determines that some permission is valid only for a part of the object instances. Therefore, the permission can be presented as a function p(o, m, Cst) whereo is an object, m is a method which can be executed on this object and Cst is a set of constraints which determine this permission. Taking into consideration a concept of authorization, obligation and condition, the set of constraints can take the following form Cst = {A, B, C} and the permission can be presented as a function p(o, m, {A, B, C}). According to this, the permission is given to all instances of the object class except the contrary specification.

The objects are the entities that can be accessed or used by the users. The objects can be either privacy sensitive or privacy non-sensitive. The relation between objects and their permissions are additionally described by association class ObjectAttributes that represents the additional object attributes (i.e. object properties) that can not be specified in the object's class and they can be used for usage decision process. The examples of object attributes are security labels, ownerships or security classes. They can be also mutable or immutable as subject attributes do.

The constraints can be defined for each main element of the model presented above (i.e user, group, subject, session, role, function, permission, object and method), and also for the relationships among the elements. The concept of constraints was described widely in the literature [START_REF] Ahn | Role-based Authorization Constraints Specification[END_REF][START_REF] Park | Attribute Mutability in Usage Control[END_REF][START_REF] Poniszewska-Maranda | Conception Approach of Access Control in Heterogeneous Information Systems using UML[END_REF][START_REF] Strembeck | An Integrated Approach to Engineer and Enforce Context Constraints in RBAC Environments[END_REF][START_REF] Bertino | The Specification and Enforcement of Authorization Constraints in Workflow Management Systems[END_REF]. It is possible to distinguish different types of constraints, static and dynamic, that can be attached to different model elements.

The URBAC distinguishes the following general types of constraints:

-Authorizations -constraints defined for the permissions, basing on access rules defined by enterprise security policy but also basing on objects' attributes and subjects' attributes. The authorizations evaluate the subject attributes, object attributes and the requested permissions together with a set of authorization rules for the usage decision. Authorizations can be either pre-authorizations (decision is made before the access) or ongoingauthorizations (decision is made during the access). -Obligations -constraints defined for the permissions but concerning also the subjects -Subject can be associated with the obligations which represent different access control predicates that describe the mandatory requirements performed by a subject before (pre) or during (ongoing) an access. These requirements should be verified before or during an access realized by a user. They can represent the security constraints that are defined on the subjects (i.e. users or groups) and they can be static or dynamic. The obligations can be pre-obligations (utilize a history function to check if the certain activities have been fulfilled or not) or ongoing-obligations (have to be satisfied continuously or periodically while the allowed rights are during a usage). -Conditions -constraints defined also for the permissions but they concern the session -Session can be connected with the set of conditions that repre-sent the features of a system or application. They can describe the current environmental or system status and states during the user session that are used for the usage decision. There are two types of conditions: pre-condition (checked before a usage and on-condition (has to be satisfied while a usage). The example of conditions can include current time for accessible time period (e.g. business hours), current location of a user for accessible location data (e.g. enterprise area) or system security status (e.g. normal, alert, attack). The conditions mainly focus on evaluations of environmental, system-related restrictions that have no direct relationships with subjects, users and accessible data for the usage decision. The subject or object attributes can be used to select which condition requirements have to be used for a request. The evaluation of conditions cannot update any subject or object attributes. -Constraints on roles and on functions. The most popular type in this group of constraints are Separation of Duty (SoD) constraints [START_REF] Ahn | Role-based Authorization Constraints Specification[END_REF][START_REF] Poniszewska-Maranda | Access Control Coherence of Information Systems Based on Security Constraints[END_REF]. -Constraints on relationships between the model elements [START_REF] Ahn | Role-based Authorization Constraints Specification[END_REF][START_REF] Poniszewska-Maranda | Access Control Coherence of Information Systems Based on Security Constraints[END_REF][START_REF] Goncalves | Role engineering: from design to evaluation of security schemas[END_REF].

The detailed view of usage role-based access control approach with the set of all elements and relationships presented above is given on figure 2.

Representation of URBAC with the use of UML concepts

Currently, Unified Modeling Language (UML) is a standard language for analysis and design of information systems [START_REF] Booch | The Unified Modeling Language User Guide[END_REF][START_REF]OMG Unified Modeling Language (OMG UML): Superstructure[END_REF]. It is widely known and used in software engineering field to support the object oriented approach. UML gives the possibility to present the system using different models or points of view. It has a set of diagrams to represent the elements of whole information systems or one of its components. Some chosen features of UML can be used to implement URBAC approach, especially during the design of information system and its associated security schema based on URBAC.

Therefore, UML can be used in role engineering process to implement and realize URBAC approach. To accomplish this, the concepts of UML and URBAC should firstly be joined. Two types of UML diagrams have been chosen to provide the URBAC: use case diagram and interaction diagram. The use case diagram presents the system's functions from the user point of view. It define the system's behavior without functioning details. According to UML meta-model, each use case from use case diagram should be described by a scenario and in consequence by at least one interaction diagram (i.e. sequence diagram or communication diagram). The interaction diagram describes the behavior of one use case [START_REF] Booch | The Unified Modeling Language User Guide[END_REF][START_REF]OMG Unified Modeling Language (OMG UML): Superstructure[END_REF]. It represents the objects and messages exchanged during the use case processing.

The relationships between UML concepts and concepts of usage role-based access control are presented below (Fig. 3).

Elements of URBAC and corresponding UML concepts

UML describes the processes that occur in a system or application and such processes are use case oriented. Use case is the main concept of UML used in analysis and design of software. It is used for specifying required usages of a system, to capture the requirements of a system, describes what a system is supposed to do.

This approach is realized with the use of use case diagram that is one of two the most important diagrams in the design process. Use case diagram contains the concept of an actor that is very close to the role concept of RBAC model. UML defines an actor as a coherent set of roles playing by the users of an use case during the interaction with this use case or in general with a system. Therefore, a role from access control can be presented as an UML actor.

Each actor cooperates with one or more use cases representing the system's functions. Each use case specifies some behavior, possibly including variants, that the system can perform in collaboration with one or more actors. These behaviors, involving interactions between the actors and the system, may result in changes to the state of the system and communications with its environment. Thus, a function from URBAC can be represented by an UML use case. As it was presented in the previous section, a set of functions can be determined for each role. Similar situation exist in UML design -each actor can be in interaction with a set of use cases and these relations specify the relations of R-F type (between roles and functions).

In UML approach each use case from use case diagram should be described by scenario and in consequence by at least one interaction diagram (sequence diagram or communication diagram). Although, both the interaction diagrams return the similar results, the sequence diagrams gives more possibilities from version 2.0 of UML. The concept of sequence diagram has been chosen for this reason (it allows to represent the remaining elements of URBAC).

Sequence diagram represents an interaction of objects by means of a sequence of messages sent between these objects. In each sequence diagram there is one or more objects representing the actors who can in this way participate directly in the process of sending the messages between the objects. It is possible to distinguish different types of messages sent to objects in sequence diagram. One of them represents a method call. The methods executed in sequence diagram and also in other UML diagrams can represent the methods of URBAC. Similarly, the objects that occur in UML diagrams, e.g. sequence diagram, collaboration diagram, can be attached to the object concept of access control model.

Access to the object, that is the possibility of execution of method on an object, is controlled with respect to the right of the method execution possessed by a message sender (i.e. subject) over an object. The access model allows for each subject the specification of a list of methods that the subject can execute. Therefore, for each use case it is necessary to specify the permissions for method's execution and as it is shown above these permissions can be found examining the sequence diagram describing the particular use case (that represents the URBAC function). These permissions are assigned to the functions by the function-permission (F-P) relation.

The relations between the elements of URBAC can be found also by the examination of use case diagram and interaction diagram (in particular sequence diagram). A use case diagram offers four types of relations between its elements:

communication relation between an actor and a use case that represents the relation between a role and a function, i.e. R-F relation, generalization relation between actors, representing the inheritance relation between roles (R-R relation), two types of relations between use cases represent the inheritance relations between functions of URBAC, i.e. F-F relations: including relation (with stereotype include) corresponds to standard inheritance relation and extending relation (with stereotype extends) corresponds to inheritance relations with additional constraints that specify the conditions of these extensions.

The second important diagram of UML, besides the use case diagram, is class diagram. This type of UML diagrams is used to describe the types of objects in a system and their relationships. Set of attributes and set of operations can be defined for each class in class diagram.

Each actor specified in the use case diagram can be also defined in details in form of UML class on the class diagram. The system user (i.e. person) is one of actor's types, thus a user is an instance of actor class. The set of class attributes forms the attributes characteristic for this actor. Therefore, the subject attributes (e.g. user attributes) from URBAC can be represented by the set of attributes defined for an instance of actor class of UML.

According to UML meta-model, each system's object has to be of particular type, thus new objects in a systems can be created only for classes defined in class diagram. Each class has among other the set of attributes. Therefore, the concept of object attributes from URBAC can be attached to set of attributes defined for this object in its class specification.

Constraints of URBAC and corresponding UML concepts

The concept of constraints in URBAC approach corresponds directly to the constraint concept existing in UML. The security constraints of URBAC can be defined for different elements and for relations between these elements. These constraints can be presented on UML diagrams corresponding to types and locations of elements for which these constraints will be defined with the use of OCL (object Constraint Language) that is the part of UML approach.

Five types of security constraints were identified for URBAC approach (Section 3). The authorization is a constraint attached to a permission that determines the permission validity depending on defined access rules. It can be represented by the UML constraint defined for the method's execution in sequence diagram.

The obligation is a constraint defined on a permission but it concerns also the subject (e.g. a user) -subject should fulfill the obligation executing a function before or during an access. This type of constraints can be presented as UML constraint in sequence diagram (as pre-condition or an invariant), especially from version 2.0 of UML that provide the combinated fragments in sequence diagrams (e.g. "alt" or "opt") allowing the definition of constraint conditions.

The UML constraints representing the authorizations or obligations can be also supported by relations between the elements concerning these constraints.

The condition is a constraint also defined on a permission but it concerns the session element. It defines current environmental or system status and states during the user session that can be used for the usage decision. The conditions can be also represented by UML constraints defined in sequence diagrams (mainly as an invariants).

Remaining types of constraints represent the constraints defined for the roles, functions and their relations. Such constraints are represented by the UML constraints defined for actors, use cases and their relations on use case diagrams or sometimes on sequence diagrams.

Production of roles based on URBAC approach

Security policies of a system generally express the fundamental choices taken by an organization to protect the data. They define the principles on which access is granted or denied. Role-based access control models are highly effective models, especially in large companies that have high turnover rates due to the fact of allowance for the administrator to simply place the new employees into the roles instead of creating the new permissions for each new person who joins the company and needs to be included in the system.

However, on the other hand, access control mechanisms still demand clear definition of set of activities and operations for each system's user that he will be allowed to execute. Consequently, a set of permissions should be defined for the user. As it was shown above, a set of permissions composes indirectly the system's roles. Therefore, the production of roles using the URBAC approach consists in determination of permissions for the functions and next functions for the application/system role with the consideration of defined security constraints (e.g. authorizations, obligations, etc.).

The process of role production can be automatic or partially automatic and is based on the connections between UML and URBAC, described in section 4. This process is realized with the use of use case diagrams, where system roles and functions are defined and with the use of sequence diagrams, where permissions are assigned to the rights of execution of methods realized in each use case. These two types of diagrams should be examined to identify the roles of URBAC, the functions that are used by these roles to interact with the information system and the permissions needed to realize these functions. First of all the rules for creation of set of roles were defined.

Rules for creation of roles

Each subject (i.e. user or group of users) in an information system is assigned to a security profile (i.e. user profile) which is defined by the set of roles that can be played by him. A security profile is defined by a pair (s, listRoles(s)): s is a subject, listRoles(s) is a set of roles assigned to this subject. Taking into consideration the concept of user, such profile can be defined as follows: (u, listRoles(u)), where u is a user, listRoles(u).

It is possibly to give the rules of role creation and the assignments of these roles to users or groups of users:

1. A access control profile should be defined for each subject (i.e. user) who interact with the system s i ⊢ securityP rof ile si or in particular for an user:

u i ⊢ securityP rof ile ui 2.

Creation of user profiles

The creation process of user profiles, i.e. production of set of roles, in an information system with the use of UML diagrams contains two stages [START_REF] Goncalves | Role engineering: from design to evaluation of security schemas[END_REF]:

determination of a set of privileges (i.e. permissions) for a use case in order to define a function and determination of a set of use cases (i.e. functions) for an actor in order to define a role.

In order to define the security profiles for the system's users or groups of users, the set of roles should be assigned to the subject profiles (i.e. user profiles). This task is realized by the security administrator during the exploitation stage. Administrator has to take into consideration the security constraints defined on the global level and subject attributes defined for subjects (i.e. users or groups of users) that determine the access control rights of particular system's users.

Conclusion

The extended RBAC is used for managing secure organizations and their functions in information systems. On the other hand, usage control enables dynamic access control during the user access to the information systems by introducing obligations and conditions in access control model. Both role management and usage control are important aspects of access control for modern information systems governed by a certain organization.

Usage Role-based Access Control approach presented above allows to define the access control policy based on access request, as traditional access control models, and the access decision can be evaluated during the access to information to which we want to control the usage. The model takes into consideration the provisional aspects in access security. The components of URBAC can create the framework based on three criteria: functional decision predicates (i.e. authorizations, obligations and conditions), continuity feature (control decision can be taken before or during the access) and mutability feature (updates of subject or object attributes can be done at different time).

The aspects of presented approach are implemented on the software platform that provides to manage the logical security of company information system from the point of view of application developer and from the point of view of security administrator. The platform allows the realization of role engineering process based on URBAC and to allow the management of information system security on access control level.

Fig. 1 .

 1 Fig. 1. Elements of Usage Role-based Access Control

Fig. 2 .

 2 Fig. 2. Meta-model of URBAC model

Fig. 3 .

 3 Fig. 3. Relationships between concepts of URBAC and UML concepts

  This profile is defined by a set of roles which can be assigned to the subject (i.e. user) with the respect of subject attributes defined mainly on level of security administrator securityP rof ile si ⊢ setRoles si , subjectAtt si in particular for an user:securityP rof ile ui ⊢ setRoles ui , subjectAtt uiTo receive a significant profile, each subject (i.e. user) should be assigned at least to one role. 3. A role is defined by a set of functions assigned to this role with respect of potential security constraints defined for themr j ⊢ setF unctions rj , cst rjTo receive a significant role, each role should have at least one function assigned.In UML meta-model, each actor should be assigned at least to one use case in the use case diagram a j ⊢ setU seCases aj , setConstraints aj 4. A function is defined by a set of permissions necessary to perform such function in accordance with potential security constraints defined for such functions or security constraints defined on the permissions (i.e. authorizations, obligations, conditions)f k ⊢ setP ermissions f k , cst f k ,setP ermissionCst p where setP ermissionCst p l ⊢ A p l , B p l , C p l To receive a significant function, each function should have at least one permission assigned. In UML description, using the interaction diagram (in our case sequence diagram) each use case should be defined by detail description, i.e. represented by a set of methods executed on the objects uc k ⊢ setP rivileges uc k , setConstrains uc k


Andreas Holzinger
email: a.holzinger@hci4all.at

Evgenia Popova
email: e.popova@hci4all.at

Bernhard Peischl
email: bernhard.peischl@soft-net.at

Martina Ziefle
email: ziefle@humtec.rwth-aachen.de

On complexity reduction of user interfaces for safety-critical systems

Keywords: Complexity reduction, data visualization, process visualization, usability engineering, safety-critical systems, industrial design

Control and communication systems used at power plants or incineration facilities offer various graphical visualizations of the physical parts of the site; however, they rarely provide sufficient visualization of the signal data. There is the problem, that such facilities contain 10,000 or more data acquisition points; each of them continuously sending data updates to the control system (once in 20 ms or less). This huge load of data can be analyzed by a human expert only if appropriately visualized. Such a visualization tool is AutoDyn, developed by the company Technikgruppe, which allows processing and visualizing complex data and supports decision making. In order to configure this tool, a user interface is necessary, called TGtool. It was originally developed by following a system-centered approach, consequently it is difficult to use. Wrong configuration can lead to incorrect signal data visualization, which may lead to wrong decisions of the power plant personnel. An unintentional mistake could have dramatic consequences. The challenge was to re-design this tool, applying a user-centered approach. In this paper we describe the re-design of the configuration tool, following the hypothesis that a usercentered cognitive map structure helps to deal with the complexity without excessive training. The results of the evaluation support this hypothesis.

Introduction and Motivation for Research

Simplicity and complexity seem to be opposites. However, there is an interesting asymmetry in their opposition. It is as though absolute simplicity is the center point of an n-dimensional sphere, where absolute complexity is the surface. In other words, there are many ways of moving away from simplicity toward complexity. In the iterative process of design and behavioral observation, it is relatively difficult to move inward toward greater simplicity, while it is relatively easy to move along the surface of a sphere, resolving some types of complexity while simultaneously introducing others, and therefore increasing neither overall simplicity nor ease of use [START_REF] Thomas | Achieving psychological simplicity: Measures and methods to reduce cognitive complexity[END_REF].

Similarly, many dimensions are involved in Human-Computer Interaction (HCI). Each of them influences the overall complexity, consequently the usability of the graphical user interface (GUI).

System complexity should be hidden from end-users, so that they can concentrate on their tasks. Task complexity can also vary, e.g. mobile phone prototypes sending a message belongs to simple task and saving a schedule to complex tasks [START_REF] Ziefle | The influence of user expertise and phone complexity on performance, ease of use and learnability of different mobile phones[END_REF]. A GUI is supposed to support a user through the tasks; however, a useful GUI is not necessarily usable. A GUI is representing the system in front of a user, thus visual complexity should be adjusted.

System complexity, task complexity and visual complexity, contribute to the overall graphical user interface complexity. The elements of the GUI are perceived by the users, who immediately create a mental model (cognitive map) of the system; such mental models help users to interpret perceptions from the environment, in order to work out appropriate actions. Simplified, we can say that external visualizations are internalized as mental models [START_REF] Liu | Mental Models, Visual Reasoning and Interaction in Information Visualization: A Top-down Perspective[END_REF]. The complexity of such a model is referred to as cognitive complexity.

In this paper we are dealing with intelligent user-centred data visualization, in a safety-relevant area, including decision support within a control system of a power plant. Advantages of user-centred approaches will be demonstrated at the example of a configuration tool called TGtool developed by the company Technikgruppe Mess-, Steuer-und Regeltechnik GmbH. In order to describe what this tool is capable of and what it is responsible for, two other systems are described briefly:

Control system: Technikgruppe is working in the power plant branch. Each power plant has its own control system produced by various corporations including Siemens, ABB or OPC Foundation. A control system can be seen as an information system (IS) for the whole facility. The system keeps track of all the measuring points, their settings and the data. Each measuring point (sensor) sends regularly its measurement (signal value) to the control system. All this data is saved; however, there is no sufficient way to visualize signal data in a longitudinal way on the time axis.

Decision-support System AutoDyn: For the purpose of signal visualization Technikgruppe has developed a tool called AutoDyn (see Figure 1) which supports the decision-making process. AutoDyn allows visualization of signal values over time in order to analyse correlations and other dependencies between signals. It supports the expert end user in their decision-making processes, offering correct visualization of different situations. Inappropriate or incorrect visualisation may have severe consequences as the visualisation has a major impact of the decision-making process in operating the whole power plant.

Related Work

In the paper "How to measure cognitive complexity in HCI" [START_REF] Rauterberg | How to measure cognitive complexity in human-computer interaction[END_REF] transferred the broad definition of cognitive complexity into the context of HCI. Accordingly, "the complexity of the user's mental model of the dialog system is given by the number of known dialog contexts ("constructs") on one hand and by the number of known dialog operations ("relationships") on the other hand" [START_REF] Rauterberg | How to measure cognitive complexity in human-computer interaction[END_REF]. A GUI with a defined level of complexity will be perceived differently by expert and novice users. There is interesting research on this topic by [START_REF] Coskun | Impacts of User Interface Complexity on User Acceptance in Safety-Critical Systems[END_REF] [START_REF] Coskun | Impacts of User Interface Complexity on User Acceptance in Safety-Critical Systems[END_REF]: They compared complexity of original and improved versions of Navigation and Piloting Expert Systems (NPES). These are operational decision support systems (DSS) which provide intelligent decision support to Chevron oil tanker ship's masters, mates and pilots navigating the restricted waters of San Francisco Bay. Three users took part in the evaluation process. Two of them were experts in navigation and piloting with both theoretical and practical knowledge. The third participant was a senior student with theoretical knowledge but less practical experience. Users had to complete the same task scenarios in both NPES-1 and NPES-2 and afterwards to fill out a questionnaire and to take part in an interview.

The result showed that the users preferred the original version of NPES-1, which used a raster image digital chart, even though it provided less detailed information and was visually more complex. NPES-2 used a fully vectorized electronic chart, reduced visual complexity and offered more functionality. However, in order to get information in NPES-2 a user had to click several times and this was a disturbing factor for the participants. They preferred to have all available data short and concise at one glance without clicking around. The officers also felt annoyed using NPES-2, as its intelligent implementation analyzed the data and offered a ready solution (users only had to push the "Accept" button) without requiring users to think. Expert users would like NPES to play the role of helper and not a director telling them, what to do. The senior student was more loyal to NPES-2, as the lack of practical experience made him use programs suggestions more often.

This study demonstrated that user interface complexity can be perceived differently by users of different experience and knowledge levels. While novice or less experienced users need to be lead through the tasks, get recommendations and ready made decisions to accept, experts prefer to have the program under their control and be free to analyze and decide what to do themselves.

Afacan & Erbug (2009) [START_REF] Afacan | An interdisciplinary heuristic evaluation method for universal building design[END_REF] demonstrated how heuristic evaluation as a usability evaluation method (see [START_REF] Holzinger | Usability engineering methods for software developers[END_REF] for an overview) can contribute to building design practice to conform to universal design principles [START_REF] Shneiderman | Universal usability[END_REF]. They took seven universal design principles as a set of heuristics and applied an iterative sequence of heuristic evaluation in a shopping mall, aiming to achieve an efficient evaluation process. The evaluation was composed of three consecutive sessions: Five evaluators from different professions were interviewed regarding the construction drawings in terms of universal design principles; each evaluator was asked to perform predefined task scenarios; finally, the evaluators were asked to reanalyse the construction drawings. The results showed that heuristic evaluation can integrate universal usability into building design practice.

The most valuable result of the work of Afacan & Erbug is, that out of 53 usability problems identified by all five evaluators, 28 were identified as major problems and had already been identified during pre-interview on construction drawings.

This research has demonstrated that usability pre-evaluation of safety-critical systems allows detection and a significant decrease in the amount of serious usability problems, which might generate further major and minor problems.

Safety-critical systems are not always effectively testable in artificial conditions [START_REF] Bastide | A tool-supported design framework for safety critical interactive systems[END_REF]. An everyday example is the usability of driver information systems used in cars [START_REF] Heimgärtner | Towards Cross-Cultural Adaptive Driver Navigation Systems[END_REF]: a new, previously unknown road ahead is unpredictable and demands full attention for safe driving. [START_REF] Funk | Concept of Automatic Usability Evaluation of Safety-Critical Interactive Systems in the Field (Konzept der automatischen Bewertung der Gebrauchstauglichkeit sicherheitskritischer Systeme)[END_REF] [START_REF] Funk | Concept of Automatic Usability Evaluation of Safety-Critical Interactive Systems in the Field (Konzept der automatischen Bewertung der Gebrauchstauglichkeit sicherheitskritischer Systeme)[END_REF] demonstrated the successful application of automatic usability evaluation instruments in such car driver IS: They introduced a two-step approach; where an observation component is embedded into the driver IS and collects data during habitual use. This component is a D'PUIS framework (www.softreliability.org/dpuis): The collected data is put into a rule-based expert system REVISER (www.hamacher.eu/reviser), which reasons over the aggregated data and evaluates it according to integrated guidelines.

During automated testing of the driver information systems AUDI MMI and BMW iDrive (refer also to the work of [START_REF] Holzinger | Rapid Prototyping on the example of Software Development in the automotive industry: The Importance of their Provision for Software Projects at the Correct Time ICE-B 2011[END_REF]). REVISER identified numerous faults in both of them. The tool has also provided proposals and hints for improvement. Empirical evaluation confirmed almost all automatically identified faults. This experiment demonstrated that the use of automatic usability evaluation methods can speed up usability testing and make this process more valuable.

The branch of this research is quite specific and so is the configuration tool. It is fairly hard to use, evaluate or test without special background knowledge and training. This narrows the choice of possible test users and evaluators. Consequently, for this project only three persons could be involved as domain experts. Only they are able to carry out complex task, for example the process of go-live configurations.

Applied usability engineering and evaluation methods should take this limitation into account. For routine configurations (simple tasks) theoretically there is no limitation on possible attendances. As a policy, Technikgruppe allows participation by its own employees only.

In order to retrieve as much valuable information as possible from the three domain experts, the interviewing was chosen as a main inspection method, which was applied for the first phase of analysis and design as well as during iterative refinement of the new GUI. The general methodology for the research looks as follows:

 Define core and complementary functionality  Define requirements  Define problems of the TGtool  Produce interface ideas and create their low-fidelity prototypes  Pick the best idea and iteratively refine it  Implement the refined idea into a high-fidelity prototype  Process thinking aloud tests and improve the prototype  Evaluate the high-fidelity prototype performance compared to TGtool performance

The first three points were cleared during interview sessions with the domain experts. Afterwards, based on the results of the interviews several GUI ideas were produced, low-fidelity prototypes were sketched for promising ideas. The prototypes were discussed and evaluated during the second interview session and the best one was chosen and iteratively developed into the high-fidelity prototype. The development process had an iterative character, whereas domain experts provided their feedback, after completion of each development iteration.

Finally, several simple tasks (in our context "simple" means routine configurations) were created and a thinking aloud test was performed by the end users of the tool. Thus, usability problems, which were not detected during the interviews and the development process, were found. The thinking aloud test results enabled a final optimization of the tool.

Finally, in order to evaluate the result most adequately both an objective and a subjective method were applied. Given routine tasks, the amount of mouse clicks necessary for completion of each of the tasks in both configuration tools was calculated.

Heuristic evaluation was completed for both the old and the new GUIs, following some guidelines from the medical domain -which is a similar safety-critical application area [START_REF] Holzinger | Application of Rapid Prototyping to the User Interface Development for a Virtual Medical Campus[END_REF], [START_REF] Holzinger | Mobile computer Web-application design in medicine: some research based guidelines[END_REF], [START_REF] Holzinger | Seeing the System through the End Users' Eyes: Shadow Expert Technique for Evaluating the Consistency of a Learning Management System[END_REF], [START_REF] Holzinger | Design and Development of a Mobile Computer Application to Reengineer Workflows in the Hospital and the Methodology to evaluate its Effectiveness[END_REF].

Thinking Aloud Test

Out of the broad spectrum of Usability Engineering Methods one particular method is very beneficial: Thinking-aloud (aka TA). This "think out loud" originally derived from problem solving research [START_REF] Duncker | On problem-solving[END_REF] and allows to get insight into mental processes of people [START_REF] Nisbett | Telling More Than We Can Know: Verbal Reports on Mental Processes[END_REF], [START_REF] Holzinger | Lessons from Real-Life Usability Engineering in Hospital: From Software Usability to Total Workplace Usability[END_REF]. For our TA tests we prepared six tasks (see Table 1) as well as a test environment. The videos were recorded with a Canon Exilim 12.1 mega pixels camera and Debut Video Capture Software (http://debut-video-capture-software.softonic.de) was used for registering user's activity on the screen. In order to achieve more objectivity in TA results "fresh" test users were required, who had not seen the prototype before. Also due to the Technikgruppe's policy, only real end users of the tool could take part in the testing process, in particular the Technikgruppe employees, who are working as:  PLS (in German: ProcessLeitSystem) technicians,  commissioning (in German: Inbetriebnahme) technicians,  measurement (in German: Mess-und Regel-) technicians,  plant operators (in German: Anlagenbediener). These requirements decreased the amount of possible test users to three persons. Although for any usability test it is important to have a higher amount of test users, we were limited to these three persons. In order to get more out of this limitation, we decided to apply an iterative TA, so that after each TA session all critical issues were first analyzed and implemented, and only then the next TA session took place. This approach allowed us to concentrate on the finding of more usability problems instead of discovering the same problems again and again in each TA session.

Environment

The average profile of a test user according to a background questionnaire was a 39 years old male with education in electrical engineering, working as a commissioning technician with 26 years of PC experience, working around 40 hours per week with PC, predominantly on the Windows operating system. This average user needs to process different routine configurations in order to update decision supporting AutoDyn quite often in his professional life, however, in most cases he delegates this to the developers of the tool as he does not feel confident working with it and is afraid to make a mistake.

In the context of our research these three test users (one pilot and two test users) had to accomplish prepared tasks using the configuration tool prototype.

Process description

At the beginning of the test the user went through the orientation script, filled out a background questionnaire and signed the non-disclosure and consent form. Afterwards he trained to think aloud painting a house in Paint (Windows application). On completion the test person opened the prototype and performed six prepared tasks. Finally the user was interviewed and in the end he filled out the feedback questionnaire.

The test was performed iteratively. It means that the feedback of each user had been analyzed, GUI "debugging" was done and then the next user tested the prototype in a thinking aloud session. This approach (eliminating small and easy-to-fix problems after each TA session) was chosen in order to reduce the amount of already known minor problems and concentrate the users' attention on discovering more severe ones.

After the TA completion all the minor and major findings were analyzed and implemented during final optimization of the configuration tool.

Experimental Results and Lessons Learned

During the interviews, the participants ran into problems and had difficulties with obvious tasks of the tool. The request to demonstrate the whole functionality was too complexfor two out of three. Many problems of the current GUI were revealed very fast. The disadvantages of the TGtool were formulated by the interviewees as follows:

Outcome of the Thinking Aloud Test

In the first session with the pilot user (TP1) the highest amount of minor problems has been discovered. Already during the first look-around task five minor problems have been detected. For instance:  no last access data was displayed,  current language has been set to Russian, while the interface was in English  the maintenance user has been allowed to create users and associate access rights Other usability "bugs" have been discovered during the test, e.g. buttons not working, absence of a sandglass, when processing needs over one second, no explicit description of a filter field etc.

All these issues have been fixed before the next session. Interestingly, the second test user found more consistency problems in the titles and dock widget's usage. As well as the pilot user he also complained about the tool's speed and discovered more operations where the sand clock was missing. The absence of a sand clock seemed to be an important issue as some tasks took over five seconds for processing and the user was confused since no feedback was given.

In the third session some more usability problems were discovered, like the password field at the login page was to the right of the user field and not under it, as is commonly done. Several minor usability 'bugs" were detected as well.

In general users have successfully accomplished all the tasks without any training or help, relying only on their cognition and domain knowledge. The diagram below shows time curves, minutes per task for each test person TP; the task number 1 has not been taken in account as a looking around task cannot have a concrete definition of success. Thus some users took a long time (about 3 min) to explore the tool, others clicked over two menu options rapidly (30 sec) and said they are done;on the horizontal axis the task number and its complexity grade and on the vertical axis the time in minutes is shown. In TA sessions after the completion of all the tasks the users have had to fill out a feedback questionnaire. Figure 3 outlines the results.

The graph demonstrates the result of the iterative approach, whereas the TP1 has graded the prototype with the lowest points (average grade 3.1). The TP2's average grade is notably higher (4.5). And the last user TP3 demonstrates the highest satisfaction with the average of 4.8, however, only a small growth of 0.3 point can be observed as most problems have already been fixed after the first session. During the TA sessions the TP1 discovered a usability problem and TP3 a computational problem at a signal filter, whereas the TP2 did not. This explains their evaluation of the fourth feedback aspect "Local Search".

In order to eliminate the speed problem another hardware test environment with 4 GB RAM (see Table 4) was used for the last test. A monitor size of a test computer became bigger, which influenced slightly the test results, as the TP3 required more time for each task due to smaller items. This explains why TP1 and TP2 have graded the seventh feedback aspect "Speed" with 0 points while TP3 has given almost the maximum -6 points.

In general, the results of the feedback questionnaire follow a positive trend, as in evaluation of 9 aspects out of 12 every following TP gave it equal or more points.

Result of the Mouse click measurement

In order to see if users really require less clicks in order to successfully complete their task a mouse click measurement has been performed. The same tasks have been used in this experiment as in the TA. In Figure 5 it can be seen that at any task processing less clicks have to be done in prototype. It is remarkable that in the tasks 2 to 5 the prototype needs exactly 2 clicks less than the TGtool.

The reason is found in the nested menus of TGtool. As it has been demonstrated in the introduction of this work, the TGtool offers 6 menus to choose at the access point. Selecting one menu the user gets to the next page where again from 4 to 7 menus can be chosen. This is an inefficient clicking process where the user does not perform the actual task but navigates to the page, where the task can be performed. And this makes, according to this research, two more clicks than is actually necessary.

The final task where the user deletes both the signal group and the signal shows a difference of 6 clicks. As TGtool provides an individual page for signal configuration and another individual page for signal group configuration, each of them has to be navigated to in order to complete the task. Thus the amount of "navigation" clicks doubles and only 6 out of 10 clicks are efficient. Heuristic evaluation has been performed by two heuristic experts with domain knowledge. They have evaluated the TGtool and the prototype on the basis of ten heuristics from [START_REF] Nielsen | Usability Engineering[END_REF] [START_REF] Nielsen | Usability Engineering[END_REF]. The five-point rating scale from Pierotti [START_REF] Pierotti | Usability Techniques: Heuristic Evaluation Activities[END_REF], has been applied. In this scale, 1 point refers to cosmetic problems, and 5 to catastrophic ones. In the net-diagram (Figure 6) the results can be seen. The user-centered prototype is not yet perfect; however, its heuristic evaluation has demonstrated a strong improvement in comparison to TGtool. It can be seen clearly on the network diagram, that there is no aspect where the prototype would be evaluated worse than the TGtool.

Conclusion and Future Research

In this work a usability engineering approach was applied to the development of configuration tool prototype, in order to reduce complexity, or more specifically, to adapt visualization of a complex system to the end user's cognitive map. To achieve this, end users were actively integrated into the whole development process from the very beginning to the very end. A big amount of usability problems was detected during the TA session, even though all the decisions upon GUI design were made by the end users during the interview sessions. The research came up with interesting findings as TA was performed. In the TA test "fresh" end users participated, who did not see a prototype before and did not take part in interview sessions during development. These test persons detected 20 TGtool Prototype usability problems. However, all of the problems were classified as minor problems which were easy to fix. This finding confirms that the iterative user-centered GUI design and development minimizes the amount of major problems, because it iteratively adapts the GUI to the end users' cognitive map. All of the TA tasks were successfully completed by all of the users with the average trend of time required for a task decreasing. Therefore, the users succeeded to learn the tool on their own within a short time and all of them stated that they felt confident using the tool. Furthermore, they all shared the opinion that the prototype was hard to use only at the beginning but, as soon as the users got the hang of it, it became easy. Finally, objective and subjective inspections of the TGtool and the prototype confirmed the effectiveness of usability engineering and clearly pointed out the faults of the prototype to be improved, like the absence of help and documentation and weak recognition support. Mouse click measurement demonstrated the efficiency and minimalistic design of the prototype. The HE fully confirmed that result and TA participants were satisfied with a clear and consistent layout design.

Although TA was performed during the last phase of development and HE afterwards, their results correlate to a great extent. Almost all the heuristics from Nielsen (1993) were commented by the test users in a positive or a negative way. The heuristics like visibility of system status, match between system and the real world, consistency and recognition were heavily criticized in the TA sessions and thus have been improved in the last development phase before HE. The error prevention aspect as well as the aesthetic and minimalist design and help users recognize, diagnose, and recover from errors were evaluated positively. The other heuristics for user control, flexibility and help and documentation were not mentioned by the TPs. This basically implies that despite a significant intersection, HE uses a wider range of aspects which allows evaluating a GUI more thoroughly and objectively, whereas TA concentrates on the issues which have caught the users' attention, which is subjective. In this work the knowledge of visual complexity and its influence on the users' perception and cognition has been applied in development of safety-critical software. The aim was to reduce complexity of the configuration tool, more specifically, to design complexity of a tool in accordance to the users' cognitive map. For this purpose iterative usability engineering method was used, so that decisions on GUI design were made by the end users of the GUI. This approach ensured that structure and complexity of the prototype would match users' cognitive map structure. As the main development process was completed, thinking aloud test was applied for the refinement of the configuration tool prototype. Usability evaluation of both TGtool and the developed prototype was performed by means of mouse click measurement test and heuristics evaluation.

Neither heuristics evaluation test nor mouse click measurement could refute the hypothesis that an end user-centered cognitive map structure helps to deal with complexity without excessive training. On the contrary, the result of heuristics evaluation demonstrated clearly that there was no usability aspect where the usercentered prototype would be inferior to system-oriented TGtool. The mouse click measurement determined the prototype as more efficient than TGtool. Moreover, the thinking aloud test showed that the users could successfully deal with the complexity of the prototype without excessive training. This evidence supports the hypothesis of this works.

There are some limitations of this research.

The TA and the mouse click measurement were performed on the basis of the same six tasks. Thus the space of these tasks restricts the validity of their test results. The participants of TA were the Technikgruppe employees, who had at least some minimal knowledge of the system behind the software. Thus application of new configuration tool might require more training for the technicians from customers' side.

The other limitation is the absence of the stress factor. In real conditions of a safetycritical system users (commissioning technicians, plant operators) are stressed while working with the configuration tool, because they are aware of consequences which can be caused by wrong action. This stress factor influences users' emotional state, thus their perception and cognition.

Figure 1 .

 1 Figure 1. The user interface of the decision support system, called AutoDyn

Figure 2 -

 2 Figure 2 -Minutes per taskThough there is some deviation due to the users' individual cognition, the general trend is clear -after the completion of the first two tasks the time required for the tasks with the same complexity level (medium and difficult) decreases. The fact that the third TP required more time than first and second, can be hardly evaluated due to

Figure 3 -

 3 Figure 3 -Feedback questionnaire result

Figure 5 .

 5 Figure 5. Minimal amount of clicks per task

Figure 6 .

 6 Figure 6. Heuristic evaluation results

Table 1 -

 1 Tasks for TA

	Task #	Task description
	Task 1	Look around.
	Task 2	Create a new signal.
	Task 3	Edit signal's properties.
	Task 4	Create a new signal group.
	Task 5	Add this signal to the group.
	Task 6	Delete both the group and the signal.

Table 2 -

 2 Hard-and software environment

Table 3 -

 3 Pros and Contras of TGtool

	No.	Disadvantages			Details
	1	No configuration types distinction	between	two	GUI does not distinct between two types of configuration
	2	Inconsistent titles			Different terms used for the same object, some titles do not correspond with their functions
					Different categories offer the same web pages,
	3	Inconsistent links			different pages have the same functionality,
					some pages are broken
	4	Minimalistic functionality		Often at one page users can perform only one action
					Users do not see if an operation has been
	5	Status of the system is not visible		completed and whether it has been completed
					successfully
	6	No progress status on time-consuming operations	The text "This operation may take about several minutes" is usually provided
					Users have to press some 'secret' button,
	7	Tool does nothing when it should		obvious for the developer, but not for the users.
					Documentation does not point it out
	8	Unnatural to add elements from right to left	Users are used to adding elements into the list from left to right
	9	Absence of warning messages		Users would not be aware of a mistake until it affects the system
	10	Absence of error messages		If users get one, they would not be able to diagnose it
					No information on who has done changes. No
	11	No user management			opportunity to manage users, passwords and
					rights
	12	No language support			Only German is supported
	13	Poor documentation			The available documentation is not adequate

Table 4 -

 4 Hardware environment for the last TA

Acknowledgements

We are grateful for the industrial cooperation with the Technikgruppe, especially to Matthias Lukic. The work presented herein has been partially carried out within the competence network Softnet Austria II (www.soft-net.at, COMET K-Projekt) and funded by the Austrian Federal Ministry of Economy, Family and Youth (bmwfj), the province of Styria, the Steirische Wirtschaftsförderungsgesellschaft mbH (SFG), and the City of Vienna, in support of the Center for Innovation &Technology (ZIT).


Jesús M Almendros-Jiménez
email: jalmen@ual.es

Validation of XML Documents with SWRL

In this paper we describe how XML documents are mapped into an OWL ontology and how SWRL rules are used to validate the semantic content of XML documents. XML completion and data constraints are specified with SWRL. The semantic completion of the XML document can be mapped into a semantic completion of the corresponding ontology. Besides, SWRL serves for specifying and reasoning with data constraints. We will illustrate our approach with an example that shows that user intervention is vital to XML mapping and completion and SWRL helps to detect relevant data constraints. The approach has been tested with the well-known Protégé tool.

Introduction

In the database scientific community many efforts have been achieved to give semantic content to data sources. The entity-relationship (ER) model, functional dependences and integrity constraints are key elements of database design. ER model gives semantics to data relations and restrict cardinality of relations. Functional dependences establish data dependences and key values. Integrity constraints impose restrictions over data values in a certain domain.

The eXtensible Markup Language (XML) [W3C07] is equipped with data definition languages (DTD [W3C99] and XML Schema [W3C09c]) whose aim is to describe the syntactic structure of XML documents. Well-formed XML documents conform to the corresponding DTD and XML Schema. However, even when XML documents can be well-formed, the content can be redundant which can lead to inconsistency, as well as the content can violate imposed restrictions over data.

Most available XML resources lack in the description of semantic content. But it also happens for syntactic content: DTD and XML schemas might not available in Web resources. It makes that data exchange fails due to bad understanding of XML content. Nevertheless, XML records can follow the same pattern and the user could help to discover and recover the semantic content of XML resources. This task is not easy and should be supported by tools. Such tools should be able to analyze the semantic content of XML data revealing fails on interpretation.

In order to help tools in the interpretation, the user could provide the intended meaning of resources.

RDF(S) [START_REF] Klyne | Resource Description Framework (RDF): Concepts and Abstract Syntax[END_REF] and OWL [MPSP + 08] emerge as solutions for equipping Web data with semantic content. Unfortunately, most of database management systems do not offer exporting facilities to RDF(S) and OWL, although some efforts have been carried out (see [START_REF] Konstantinou | Ontology and database mapping: A survey of current implementations and future directions[END_REF] for a survey). XML has been usually adopted as database exchange format. For this reason, some authors have described how to map XML into RDF(S)/OWL and add semantic content to XML documents.

On one hand, most proposals focus on the mapping of the XML schema into RDF(S)/OWL. In some cases, the mapping is exploited for reasoning (conformance and completion, among others). On the other hand, in many cases, the mapping, when the XML schema is present, can be automatically accomplished. Nevertheless, some of them work when the XML schema is missing, requiring the user intervention, who specifies a set of mapping rules. Finally, most of cases tools have been developed with this end, based on XML transformation and query languages like XSLT and XPath.

In this paper we describe how XML documents are mapped into an OWL ontology and how SWRL rules are used to validate the semantic content of XML documents. SWRL rules enable to express constraints on XML data, and they can be triggered in order to validate the constraints. The approach has been tested with the well-known Protégé tool.

We can summarize the main contributions of our proposal as follows:

-XML into OWL mapping is carried out by specifying mappings from tags and attributes into concepts, roles and individuals of the ontology. Such mappings are defined with XPath. The ontology is created from the mapping, firstly, at instance level and, secondly, by adding ontology axioms with SWRL. -SWRL is used for two main tasks:

(a) to add new semantic information to the ontology instance generated from the XML document. Such information can be considered as a completion of the XML model. In particular, such rules can create additional classes and roles, and therefore extending the ontology initially created from the mapping with new axioms and instance relations. In other words, SWRL serves as ontology definition language in the phase of completion; and (b) to express data constraints on the XML document. SWRL can be used for expressing relations that the ontology instance has to satisfy. Therefore SWRL is a vehicle for reasoning with the semantic content and therefore for analyzing XML resources.

Our approach aims to provide a method for specifying a transformation rather than to consider automatic mapping from the XML Schema. XML completion and data constraints are specified with SWRL. The semantic completion of the XML document can be mapped into a semantic completion of the corresponding ontology. Besides, SWRL serves for specifying and reasoning with data constraints. We will illustrate our approach with an example that shows that user intervention is vital to XML mapping and completion and SWRL helps to detect relevant data constraints.

The drawbacks of our approach are the following. The kind of ontology we can handle is limited to SWRL expressivity. Since we create the target ontology with SWRL, OWL meta-data axioms are defined with SWRL rules. In other words, SWRL is taken as ontology definition language in the line of [START_REF] Krisnadhi | OWL and Rules. Reasoning Web. Semantic Technologies for the Web of Data[END_REF][START_REF] Krötzsch | Description Logic Rules[END_REF]. However, therefore there are some completions/data constraints that cannot be specified. In particular, those involving universally quantified constraints cannot be specified.

One feasible extension of our work is to move to SQWRL [START_REF] O'connor | SQWRL: a query language for OWL[END_REF], which extends SWRL to a more powerful query language. It is considered as future work. With regard to the choice of SWRL as ontology definition language, we could express completions/data constraints with a suitable OWL 2 fragment (for instance, EL, RL and QL) [W3C09a,W3C09b]. However, in such a case, we would also have a limited expressivity.

Related Work

XML Schema mapping into RDF(S)/OWL has been extensively studied.

In an early work [START_REF] Ferdinand | Lifting XML Schema to OWL[END_REF] XML Schema is mapped into RDF(S) meta-data and individuals. In [START_REF] Bohring | Mapping XML to OWL ontologies[END_REF], they propose an small set of mapping rules from XML Schema into OWL and define a transformation with XSLT. In [START_REF] Tsinaraki | XS2OWL: a formal model and a system for enabling XML schema applications to interoperate with OWL-DL domain knowledge and semantic web tools[END_REF], they also propose an XSLT based transformation from XML Schema to OWL that allows the inverse transformation, i.e. convert individuals from OWL to XML. The inverse transformation is usually called lowering, and the direct one is called lifting. Besides, in [START_REF] Xiao | Integrating and exchanging XML data using ontologies[END_REF], XML schemas are mapped into RDF(S) and they make use of the mapping for query processing in the context of data integration and interoperation. This is also the case of [BMPS + 11], in which the authors propose a set of patterns to automatically transform an XML schema to OWL. Such patterns are obtained from pattern recognition. Manual mapping has been considered in [START_REF] Thuy | Exploiting XML Schema for Interpreting XML Documents as RDF[END_REF], in which the authors translate XML schemas and data to RDF(S) with user intervention.

In some cases the target ontology has to be present, that is, the mapping from XML into OWL aims to populate the ontology with individuals. For instance, in the proposals [RRC08,AKKP08,RRC06,VDPM + 08], the authors transform XML resources to RDF(S) and OWL format, in the presence of an existing ontology and with user intervention. The mapping rules can be specified with Java (for instance, in [START_REF] Rodrigues | Moving from syntactic to semantic organizations using JXML2OWL[END_REF]), and with domain specific languages (for instance, with XSPARQL [START_REF] Akhtar | XSPARQL: Traveling between the XML and RDF worlds-and avoiding the XSLT pilgrimage[END_REF]).

Manual mappings are in many cases based on XPath expressions. In [START_REF] Ghawi | Building Ontologies from XML Data Sources[END_REF], they describe how to map XML documents into an ontology, using XPath for expressing the location in the XML document of OWL concepts and roles. In [START_REF] O'connor | Acquiring OWL ontologies from XML documents[END_REF] they employs XPath to map XML documents into OWL, extending the set of OWL constructors to represent XML resources. Besides XPath is used to describe mappings in the XSPARQL framework [START_REF] Akhtar | XSPARQL: Traveling between the XML and RDF worlds-and avoiding the XSLT pilgrimage[END_REF].

Finally, some authors have explored how to exploit the mapping for XML validation. For instance, in [START_REF] Wu | XML Schema Representation and Reasoning: A Description Logic Method[END_REF], they describe how to map the XML Schema into Description Logic (DL) and they make use of DL for model validation and completion and as query language. Besides, in [START_REF] Zhang | Knowledge representation and reasoning of XML with ontology[END_REF], they map XML into OWL (and DL) and they study how to reason about the XML schema, in the sense of that, to check conformance of XML documents, and to prove inclusion, equivalence and disjointness of XML schemas. SWRL has been employed in [LSD + 09] for data normalization, encoding schemas and functional dependences with DL.

Comparing our work with existent proposals we find some similarities with the work described in [START_REF] O'connor | Acquiring OWL ontologies from XML documents[END_REF] in which they employ XPath for manual mapping and a rich OWL fragment for describing concept and role relations.

Structure of the Paper

The structure of the paper is as follows. Section 2 will present a running example. Section 3 will describe how to map XML documents into OWL. Section 4 will focus on how to complete the semantic content of XML documents. Section 5 will show how to validate XML constraints and, finally, Section 6 will conclude and present future work.

Running example

Let us suppose that we have the XML resource of Figure 1. The document lists papers and researchers involved in a conference. Each paper and researcher has an identifier (represented by the attribute id), and has an associated set of labels: title and wordCount for papers and name for researchers. Furthermore, they have attributes: studentPaper for papers and isStudent, manuscript and referee for researchers. The meaning of the attributes manuscript and referee is that the given researcher has submitted the paper of number described by manuscript as well as (s)he has participated as reviewer of the paper of number given by referee.

It is worth observing that the document uses identifiers for cross references between papers and researches. It is just for simplifying the example, and it is not real restriction of our approach. It does not mean that interesting examples come from resources where cross references are given. Now, let us suppose that we would like to analyze the semantic content of the XML document. We would like to know whether some paper violates the restriction on the number of words of submissions. In order to do this we could execute the following XPath query: and it gives us the papers whose attribute wordCount is greater than 10000. This is a typical restriction that can be analyzed with XPath. 1" s t u d e n t P a p e r=" t r u e "> < t i t l e > XML Schemas </ t i t l e > <wordCount> 1200 </wordCount> </paper> <p a p e r i d ="2" s t u d e n t P a p e r=" f a l s e "> < t i t l e > XML and OWL </ t i t l e > <wordCount> 2800 </wordCount> </paper> <p a p e r i d ="3" s t u d e n t P a p e r=" t r u e "> < t i t l e > OWL and RDF </ t i t l e > <wordCount> 12000 </wordCount> </paper> </p a p e r s > <r e s e a r c h e r s > <r e s e a r c h e r i d ="a " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="1" r e f e r e e ="1"> <name>Smith </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="b" i s S t u d e n t =" t r u e " m a n u s c r i p t ="1" r e f e r e e ="2"> <name>D o u g l a s </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="c " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="2" r e f e r e e ="3"> <name>King </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="d" i s S t u d e n t =" t r u e " m a n u s c r i p t ="2" r e f e r e e ="1"> <name>Ben</name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="e " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="3" r e f e r e e ="3"> <name>W i l l i a m </name> </ r e s e a r c h e r > </ r e s e a r c h e r s > </ c o n f e r e n c e > However, we can complicate the situation when papers are classified as student and senior papers which have different restrictions of length. Fortunately, each paper has been labeled with this information, that is, with the attribute studentPaper. However, it is redundant in the document. That is, we have information about submitters and whether they are student or not. In the case papers are not labeled with the attribute studentPaper, the XPath query becomes more complex. In general, missing and redundant information in XML resources makes XPath based analysis more complex to make.

The goal of our approach is to be able to extract from the XML document the semantic content and validate the content. In particular, it involves to analyze cross references. Besides, the process of extraction is guided by the user who knows (or at least (s)he can suspect) the meaning of the given labels and attributes.

In XML Schema based translations, such semantic information could not be specified in the document therefore the user intervention is also required. Semantic validation of XML documents ranges from restrictions imposed over data such as "the attribute wordCount has to be smaller than 10000" to properly integrity constraints as "the reviewer of a paper cannot be the submitter". Assuming that senior papers cannot have students as authors, inconsistent information comes from senior papers having an student as author.

Validation can be improved by completing the XML model. Completion means to add new information that can be deduced from the original resource.

For instance, in the running example, we can add the author for each paper, which can be obtained as the inverse of the value of the manuscript attribute of each researcher. In the case the attribute studentPaper was not included, we can add this information from the information about researchers using the isStudent attribute. Besides, the semantic extraction can be more accurate. For instance, we can define the classes Student, Senior as subclasses of Researcher, and PaperofSenior and PaperofStudent as subclasses of Paper. PaperofSenior class is defined as the subclass of papers whose value studentPaper is false and Student can be defined as the subclass of researchers whose value isStudent is true. We can also define the Reviewed class as the subclass of papers which have at least one referee.

The definition of such ontology based completion facilitates the description of data constraints. For instance, authors of PaperofSenior cannot be Students. In order to express data constraints we have adopted a simple solution in our approach. We will define new ontology classes that represent data constraints. For instance, the class BadPaperCategory can be defined as the class of senior papers having an student as author, while the class NoSelfReview can be defined as the class of papers having a referee which is also the author of the paper. When the classes BadPaperCategory and NoSelfReview are not empty, the XML document violates the required constraints.

Our approach has in the spirit to provide a methodology for XML validation. Our proposal distinguishes three steps: mapping, completion and validation. The following sections will describe each one of these steps using the running example.

Mapping XML into OWL

The first step consists in the XML into OWL mapping with rules. Mapping rules establish a correspondence from XPath expressions to ontology concepts:

xp 1 → C 1 , . . . , xp n → C n
and from pairs of XPath expressions to ontology roles:

(xp 1 , xp 1 ) → r 1 . . . , (xp m , xp m ) → r m
Mapping works at the instance level, creating instances of concepts and roles from XML items. Concepts and roles belong to the target ontology.

For instance, let us suppose that the programmer wants to transform the running example. The programmer, firstly, has to define paths to access to individuals and property values:

( a ) doc ( ' p a p e r s . xml ' ) // p a p e r s / r e s e a r c h e r / @id ( b ) doc ( ' p a p e r s . xml ' ) // p a p e r s / r e s e a r c h e r /name ( c ) doc ( ' p a p e r s . xml ' ) // p a p e r s / r e s e a r c h e r / i s S t u d e n t ( d ) doc ( ' p a p e r s . xml ' ) // p a p e r s / r e s e a r c h e r / @ m a n u s c r i p t ( e ) doc ( ' p a p e r s . xml ' ) // p a p e r s / r e s e a r c h e r / @ r e f e r e e and, secondly, has to map them into ontology concepts and roles as follows: a → Researcher, (a, b) → name, (a, c) → isStudent, (a, d) → manuscript and (a, e) → referee. The same can be done from papers:

( f ) doc ( ' p a p e r s . xml ' ) // p a p e r s / p a p e r / @id ( g ) doc ( ' p a p e r s . xml ' ) // p a p e r s / p a p e r / t i t l e ( h ) doc ( ' p a p e r s . xml ' ) // p a p e r s / p a p e r / wordCount ( i ) doc ( ' p a p e r s . xml ' ) // p a p e r s / p a p e r / @ S t u d e n t P a p e r in which the mapping is as follows: f → Paper, (f, g) → title, (f, h) → wordCount and (f, i) → StudentPaper.

The mapping obtains and ontology for researchers (see Figure 2) and an ontology for papers (see Figure 3).

Semantic Completion

The second step consists in the XML completion using SWRL rules. The completion is defined in terms of the target OWL ontology.

SWRL rules are used to define new concepts and roles C 1 , . . . , C s , r 1 , . . . , r l from C 1 , . . . , C n and r 1 , . . . , r m . Completion aims to structure the semantic information and to infer new information.

SWRL allows to express "and" conditions by means of "∧", and OWL classes and properties can be used as atoms in the antecedent and the consequent: C(?x) means that ?x is an individual of the class C, and P (?x, ?y) means that the property P holds for ?x and ?y, where ?x and ?y are variables that in SWRL starts with "?". Moreover, SWRL admits the use of the built-ins "greaterThanOrEqual" and "lessThan" whose role is to restrict the numeric value of the variables.

For instance, let us suppose that the programmer wants to specify the completion of the running example by defining the concepts PaperofSenior, Paper-ofStudent and Reviewed as subclasses of the concept Paper: ? x ) R e v i e w e d ( ? x ) -> Paper ( ? x ) s t u d e n t P a p e r ( ? x , f a l s e ) -> P a p e r o f S e n i o r ( ? x ) s t u d e n t P a p e r ( ? x , t r u e ) -> P a p e r o f S t u d e n t ( ? x ) r e f e r e e ( ? x , ? y ) -> R e v i e w e d ( ? x ) Moreover, (s)he defines the inverse relations of manuscript and referee (defined as author and submission), and the classes Student and Senior as subclasses of Researcher as follows: m a n u s c r i p t ( ? x , ? y ) -> a u t h o r ( ? y , ? x ) r e f e r e e ( ? x , ? y ) -> s u b m i s s i o n ( ? y , ? x ) i s S t u d e n t ( ? x , t r u e ) -> S t u d e n t ( ? x ) i s S t u d e n t ( ? x , f a l s e ) -> S e n i o r ( ? x ) S t u d e n t ( ? x ) -> R e s e a r c h e r ( ? x ) S e n i o r ( ? x ) -> R e s e a r c h e r ( ? x ) However, we make use of SWRL as ontology definition language for expressing ontology relationships.

The semantic completion will obtain the ontologies of Figures 4 and5. We have classified researchers and papers as seniors and students, and papers as papers of students and seniors, and reviewed. In this paper we have studied how to validate XML documents from a mapping into OWL and the use of SWRL. We have described how to complete XML/OWL models and how to specify data constraints with SWRL.

As future work, we would like to extend our work in the following directions. Firstly, we could move to a more expressive language, SQWRL, in order to be able to express more complex data constraints. Secondly, we would like to study how to map XML into OWL by using the XML Schema. Finally, we would like to fully integrate our proposal with the Protégé tool. We have in mind the development of a Protégé plugin for the edition and execution of transformations in Protégé. The plugin would allow to validate XML documents in Protégé, and the use of OWL constructors/SWRL to specify completions/data constraints.

/

  c o n f e r e n c e / p a p e r s / p a p e r [ wordCount >10000]

Fig. 1 .

 1 Fig. 1. Running Example<?xml v e r s i o n = '1.0 '? > <c o n f e r e n c e > <p a p e r s > <p a p e r i d ="1" s t u d e n t P a p e r=" t r u e "> < t i t l e > XML Schemas </ t i t l e > <wordCount> 1200 </wordCount> </paper> <p a p e r i d ="2" s t u d e n t P a p e r=" f a l s e "> < t i t l e > XML and OWL </ t i t l e > <wordCount> 2800 </wordCount> </paper> <p a p e r i d ="3" s t u d e n t P a p e r=" t r u e "> < t i t l e > OWL and RDF </ t i t l e > <wordCount> 12000 </wordCount> </paper> </p a p e r s > <r e s e a r c h e r s > <r e s e a r c h e r i d ="a " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="1" r e f e r e e ="1"> <name>Smith </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="b" i s S t u d e n t =" t r u e " m a n u s c r i p t ="1" r e f e r e e ="2"> <name>D o u g l a s </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="c " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="2" r e f e r e e ="3"> <name>King </name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="d" i s S t u d e n t =" t r u e " m a n u s c r i p t ="2" r e f e r e e ="1"> <name>Ben</name> </ r e s e a r c h e r > <r e s e a r c h e r i d ="e " i s S t u d e n t =" f a l s e " m a n u s c r i p t ="3" r e f e r e e ="3"> <name>W i l l i a m </name> </ r e s e a r c h e r > </ r e s e a r c h e r s > </ c o n f e r e n c e >

<Fig. 2 .

 2 Fig. 2. Ontology for researchers

Fig. 3 .

 3 Fig. 3. Ontology for papers

Fig. 6 .

 6 Fig. 6. Visualization of Validation in Protegé

This work has been supported by the Spanish Ministry MICINN under grant TIN2008-06622-C03-03, Ingenieros Alborada IDI under grant TRA2009-0309, and the JUNTA de ANDALUCÍA (proyecto de excelencia) ref.

Validation

The last step consists in the definition of data constraints with SWRL. New concepts are defined from C 1 , . . . , C n , C 1 , . . . , C s , r 1 , . . . , r m and r 1 , . . . , r l , and individuals of such concepts violate data constraints. For instance, in the running example, the programmer can define the concepts PaperLength, NoSelfReview, NoStudentReview and BadPaperCategory with the following rules: wordCount ( ? x , ? y ) ^g r e a t e r T h a n O r E q u a l ( ? y , 1 0 0 0 0 ) -> P a p e r L e n g t h ( ? x ) m a n u s c r i p t ( ? x , ? y ) ^s u b m i s s i o n ( ? x , ? y ) -> N o S e l f R e v i e w ( ? x ) S t u d e n t ( ? x ) ^s u b m i s s i o n ( ? x , ? y ) -> N o S t u d e n t R e v i e w e r ( ? x ) m a n u s c r i p t ( ? x , ? y ) ^S t u d e n t ( ? x ) ^P a p e r o f S e n i o r ( ? y ) -> B a d P a p e r C a t e g o r y ( ? x )

Finally, they can be triggered, obtaining the following results: The result shows that the paper length is exceeded by paper #3, the authors of #a and #e have reviewed their own paper, #b and #d are students that review a paper, and finally the researcher #d is an student with a senior paper and #2 is a senior paper with an student as author.

We have tested our approach with the Protégé tool (version 4.1) using the Hermit reasoner (version 1.3.4). The Hermit reasoner has been used for triggering the completion rules and data constraints from the mapping of XML into OWL. Figure 6 shows an snapshot of the validation results obtained from Hermit and Protégé.