The application layer models a business view of the collaborating users and the relations between them. The business view is application-dependent, so it must be built by the designers of each collaborative system and instantiated at runtime by the system itself. It
contains the domain specific ontology in use during runtime of a collaborative environment. This domain ontology is an extension of the generic ontologies (GPO and GCO) with terms specific to an application category, such as business-specific concepts and relations. Any other services or components required by a specific domain could also exist in this layer.
3.4.1 Domain Collaboration Application
The collaborative privacy architecture shown in this thesis is intended to be domain independent. This independence means that the architecture is not concerned with what software application is used by the domain to create the CWE. This is important as different organizations often use different CWEs [66]. There are a number of commercial and open source products available which are able to create a CWE. Popular commercial products include BSCW [58], IBM Sametime [29], Kavi Workspace [34], and Microsoft SharePoint [47]. Available open source products include PHPGroupware [65] and Tiki Wiki CMS Groupware [76]. Any front end software that allows participation in a CWE can be compatible with the collaborative privacy architecture.
3.4.2 Domain Ontology
This ontology is an amalgamation of the GPO and GCO with domain specific elements. These domain specific elements are extensions on the general concepts provided by the generic ontologies. For example, the GPO contains an Information concept, which is the information to be protected by a privacy rule. This general Information concept can be extended for the specific types of information the domain requires. The complexity of the domain ontology is determined by the requirements of the domain.
The main generic elements that can be specialized are: Node, Group, Project, OrgRole and ProjectRole, Information, Purpose, Retention and hasSession. The concept Node can be specialized into sub-concepts specifying the type of communicating individual if required by the domain. Similarly, the Group concept can be specialized into sub- concepts if the domain requires different types of groupings. Similar to Group, the Project concept may be specialized into sub-concepts if different types of projects are required by the domain. OrgRole is specialized by defining all possible roles that can be assigned to each Node. The ProjectRole concept (and its sub-concepts) are customized by the Organization when the project is created. These project specific roles are designed to outline the functions required to complete projects. The Purpose concept is specialized depending on the domain, as the reasons for information collection within that domain can be specified. The Retention concept is specialized in order to allow for different lengths of time to be defined, depending on the requirements of the domain. The Information concept is also specialized depending on the domain, as the types of Information used within the domain are detailed. The relation hasSession has to be specialized in order to define the needed collaborative sessions for each group. Therefore the domain ontology contains hasSession sub-concepts that inherit rules from their parent concepts that indicate how nodes can communicate, within the specified sessions.
Instances of GCO concepts, GPO concepts, and those of the domain ontology are regrouped into the same instance in this model. This instance represents a business view of the collaborative activities with privacy in consideration. The GCO and GPO overlap in the concepts of Node, Role (OrgRole) and Group, and the Session concept is related to the Project concept similar to its relation to the Group concept.
At runtime, the domain ontology is instantiated when a change in the environment is detected by the domain collaboration application (such as the arrival or departure of a user, or role change of a user), thus providing a knowledge base containing explicit and implicit collaborative aspects about the collaborators, their roles, their groups, their projects, the needed communication sessions for each group and project, and which privacy policy rules are relevant to which members of the environment. This instantiation uses the Reasoning Layer to determine the privacy protection of the system, as well as the sessions required for collaborative communication between users. Rules trigger the instantiation of the generic ontology allowing a semantic-driven adaptation that enables managing spontaneous sessions and detecting implicit potential collaborative situations. An example of an implicit potential collaborative situation is as follows. An administrator adds a session to a group, followed by defining application rules based on the organization roles. In this example, the administrator defines the rule that OrgRole1 and OrgRole2 will communicate in this session. Once this is complete, any participants who have those roles of OrgRole1 and OrgRole2 will automatically join this newly created session. For another example in terms of privacy, an administrator assigns to a collaborator a NodeProjectRole belonging to an existing Project. The collaborator will automatically join the project, and be allowed to access to any information defined by privacy rules that cover that project, conditional on the reasons for the information use.
3.4.3 Domain Collaborative Privacy Manager
The Domain Collaborative Privacy Manager (DCPM) is a domain specific instance which runs in the form of a transparent service to provide information to the Users in order to assist with the protection of their privacy. The DCPM interacts with the Domain
Ontology in order to determine what rules and requirements a User may require. Multiple DCPM services can exist in the Application Layer through replication in order to meet demand if a large number of users are present or in case of different projects run simultaneously [49].
3.4.4 Conflict Engine
The Conflict Engine is utilized by the DCPM to check for conflicts between the privacy rules of privacy policies. As described in Section 3.2.3, there are a set of conflict engine rules that when executed, determine if any privacy rules are in conflict. The conflict engine is a semantic reasoning engine which is able to execute these semantic conflict rules. The conflict engine is able to generate a set of axioms which identify which rules are in conflict. These axioms are added to the domain ontology, where a PA can be alerted to the conflict and take appropriate action.