In recent years, there has been a growing interest in the development and use of domain ontologies, strongly motivated by the Semantic Web initiative. However, the application of ontologies in the CSCW domain has been scarce. Therefore in this paper, it presents a novel architectural model to CSCW systems described by means of an ontology. This ontology defines the fundamental organization of a CSCW system, represented in its concepts, relations, axioms and instances.
In the last two decades, the enormous growth of Internet and the web have given rise
to an intercreativity cyberspace, in which groups of people can communicate,
collaborate and coordinate to carry out common tasks. Therefore, a great number of
groupware applications has been developed using different approaches, including
object-oriented, component-oriented, and agent-oriented ones. However, the
development of this kind of applications is very complex, because different elements
and aspects must be taken into account. Hence, these applications must be
simultaneously supported by models, methodologies, architectures and platforms to
be developed in keeping with current needs. In the groupware domain, one of the
models most used is the Unified Modelling Language (UML) [
There has recently been an increase in the use of ontologies in any domain to model applications. An ontology is presented as an organization resource and knowledge representation through an abstract model. This representation model provides a common vocabulary of a domain and defines the meaning of the terms and the relations amongst them. In the domain of groupware applications, the ontology provides a well-defined common and shared vocabulary, which supplies a set of concepts, relations and axioms to describe this domain in a formal way.
In this paper, two ontologies for the groupware domain are proposed. The first ontology determines who authorize the registration of users, how interaction is carried out among them, and how the turns for users participation are defined, among other aspects. Moreover, it allows supporting modifications in runtime, such as changing the user role, the rights/obligations of a role, the current policy, etc. The second ontology establishes the necessary SOA-based services to develop groupware applications in accordance with the existing papers in the literature about the development of this type of applications. In addition, these services are clustered in modules and layers with respect to the concern that they represent.
This paper is organized as follows. Section 2 gives an brief introduction to the ontologies. Section 3 describes the ontology-based modeling of the group organizational structure. Section 4 presents an ontological model, which allows us to specify an architectural model for the development of groupware applications. Finally, Section 5 outlines some conclusions and future work.
There are several definitions of ontology, which have different connotations
depending on the specific domain. In this paper, we will refer to Gruber’s well-know
definition [
Jasper and Ushold [
Ontology is specified using the following components: Classes: There is a set of classes, which represent concepts that belong to the ontology. Each class may contain individuals (or instances), other classes or a combination of both, with their corresponding attributes. Relations: These define interactions between two or several classes (object properties) or between a concept and a data type (data type properties). Axioms: These are used to impose constraints on the values of classes or instances. Axioms represent expressions (logical statement) in the ontology and are always true inside the ontology. Instances: These represent the objects, elements or individuals of an ontology.
These four components will be described for the two ontologies proposed in this paper.
In addition, ontologies require of a logical and formal language to be expressed. In Artificial Intelligence, different languages have been developed, like the First-Order Logic-based (which provide powerful primitive for modeling), the Frames-based (with more expressive power but less inference capacity), and the Description Logicsbased (which are more robust in the reasoning power) ones.
OWL (Web Ontology Language) [
In the groupware domain, ontologies have mainly been used to model task analysis
or sessions. Different concepts and terms, such as group, role, actor, task, etc. have
been used for the design of task analysis and sessions. Many of these terms are
considered in our conceptual model. Moreover, semiformal methods (e.g. UML class
diagrams, use cases, activity graphs, transition graphs, etc.) and formal ones (such as
algebraic expressions) have also been applied to model the sessions. There is also a
work [
In order to specify architectural model five concerns are identified: Data, Group, Cooperation, Application, and Adaptation. Consequently, five layers are considered. Four layers are composed by modules and services, while the fifth one, the Data Layer, contains repositories with the necessary information to carry out the group work. The services of the architectural model are defined by the concepts' ontology.
The architecture components are characterized through the concepts' ontology (shown in Figure 1), which will be briefly described below: Registration is the first action that a user must carry out to can participate in the group work using the collaborative application. Authentication validates the access to the group and depends on the organizational style defined in the same.
Group is who works in the session to perform work group.
Organizational_Style defines the organizational style that a group will use to carry out the group work.
Stage restricts user’s access to the application in accordance with the organizational style defined in it.
Session defines a shared workspace where a group carries out common tasks. Session_Management manages and controls one or more sessions.
Concurrency manages shared resources to avoid inconsistencies by using them. Shared_Resource is used by users to carry out basic activities.
Basic_Activity is an action that a user must perform to carry out a task (which can be made up by one or more basic activities).
Task is carried out by the group to achieve a common goal.
Notification notifies one or more users of all events that happen in a session. Group_Awareness gets the necessary information to supply group awareness to users that take part in a group.
Group_Memory is supplied by the application to facilitate a common context. Application is used by the users to carry out group work in established session. Configuration configures the application the first time that it is used and when it is necessary.
User_Interface shows users all the information about the application execution. Environment modifies the user interface to present the information in accordance with the device used by each user.
Adaptation is a process that allows adapting the collaborative application to the new needs of the group.
Detection monitors the execution environment to detect the events that determine the adaptation process.
Agreement decides whether an adaptation process must be carried out or not. Vote_Tool is used by users to perform the agreement.
Adaptation_Flow is a set of steps carried out to adapt the collaborative application in accordance with the selected event.
Repair is required when the adaptation process can not be performed.
AFA
AA performs is_determined
AE needs
AAA uses requieres is_adapted
MU MAV MIV CAE modifies presents
CMS TSP is_part_of ASI
APU is_used
IUP SRP manages has gives
CS administers GN supplies
NGM provides RUI AUI SPI COS SOS AOS
URA CF SU AS defines
organizes dependes establishes
CBL controls i acces works
Go1rgan SM governs
SCM obtains
NGA allows
AUG
The architecture relationship to each component and its environment are symbolized with the ontology relations (see Figure 1) listed below: allows (Registration, Authentication): Only registered users are allowed to authenticate to access to the collaborative application. access (Authentication, Group): Authentication allows users to access to group. depends (Registration, Organizational_Style): Users registration depends on the organizational style defined at a given stage. organizes (Organizational_Style, Group): An organizational style specifies the way in which the group is organized. defines (Stage, Organizational_Style): A stage defines an organizational style. works (Group, Session): A group needs to be connected to a session to work. governs (Session_Management, Session): The session management governs a session. controls (Concurrency, Session): The concurrency service controls the existing interaction in a session. manages (Concurrency, Shared_Resource): The concurrency service manages the shared resources to guarantee mutually exclusive usage of these. is_used (Shared_Resource, Basic_Activity): The shared resources are used by basic activities. is_part_of (Basic_Activity, Task): A basic activity is part of a task. administers (Session, Notification): The session administers the notification. provides (Notification, Group_Awareness): The notification process provides group awareness. obtains (Group, Group_Awareness): A group obtains group awareness to avoid inconsistencies in the collaborative application. supplies (Notification, Group_Memory): The notification process supplies group memory. gives (Application, Group_Memory): The application gives group memory. establishes (Application, Session): An application establishes a session. presents (Application, User_Interface): An application presents an user interface so that users can use the collaborative application. modifies (Environment, User_Interface): The environment modifies the user interface according to the device used by each user. has (Application, Configuration): Each application has a configuration process, which is carried out by users. is_adapted (Application, Adaptation): An application is adapted by the adaptation process. is_determined (Adaptation, Detection): The adaptation process is determined by the detection process. needs (Adaptation, Agreement): The adaptation process needs an agreement process to decide whether the adaptation is carried out or not. uses (Agreement, Vote_Tool): The agreement process uses a vote tool to carry out the agreement. performs (Adaptation, Adaptation_Flow): The adaptation process performs an adaptation flow to appropriately adjust the application. requires (Adaptation, Repair): When the adaptation process can not be performed, it is required to repair the application to avoid inconsistencies in it.
Finally, the principles governing design and evolution of the architectural model are represented by ontology axioms (see Figure 1): An authentication must have only one registration, i.e. an user is authenticated only if she/he is registered. A registration depends on an organizational style, i.e. an user is registered with accordance to organizational style established in the group work. An organizational style organizes at least one group. A group works at least in one session. An application establishes at least one session. A session administers at least one notification process. A group obtains group awareness. An application gives group memory. The concurrency service controls at least one session. The concurrency service manages at least one shared resource. A shared resource is used by at least one basic activity. A basic activity is part of at least one task. An application has at least one possible configuration. An application presents at least one user interface. An environment modifies at least one user interface. An application can be adapted by an adaptation process. An adaptation process is determined by at least one detection process. An agreement process is carried out only if there is an adaptation process in a non-hierarchical organizational style. An agreement process uses at least one vote tool. An adaptation process performs only one adaptation flow. An adaptation flow must verify at least one pre-condition and post-condition to carry out the adaptation.
An adaptation process can require a repair process, if this has not finished.
In order to show the architectural functionality, this section presents a set of instances (see Figure 1), derived from the definition of the application instance, which is a Conference Management System (CMS). A CMS is a web-based application that supports the organization of scientific conferences. It can be regarded as a domainspecific content management system. Nowadays, similar systems are used by editors of scientific journals.
This type of systems generally has four stages: submission, assignment, review, and acceptance/rejection of papers, and this paper adds the stage of application configuration. CMS supports three user groups: Authors (A), Program Committee Members (PCM) and Program Committee Chairs (PCC). The first user group (A) corresponds to people who can submit papers (at the submission stage) through the Internet, and who receive the review results and the final decision via an email (at the acceptance/rejection stage). It is the largest user group (its average number is normally between 100 and 400 people for most conferences). The second user group (PCM) is made up of people who must evaluate some of the submitted papers and send the result to the PC Chairs via the Internet (at the review stage). Its number is about 20–50 persons in average. People in the last user group (PCC) are in charge of allocating papers to reviewers (at the assignment stage) and making the final decision on papers, as well as a number of other operations. This is the least numerous group, being usual 1–3 PCC per conference. Therefore: Session instance is Session of the Conference Management (SCM). Session_Management instance is Session Management (SM). Stage instances are configuration (CF), and submission (SU), assignment (AS), review (RE) and acceptance/rejection (AC) of papers. Authentication instance is user authentication in the group (UAG). Registration instance is user registration in the application (URA). Users instances are U1, U3 and U4 as A, U3 as PCM, and U2 as PCC. User_Interface (UI) instances are Registration UI (RUI), Authentication UI (AUI), Submitting Paper UI (SPI), Configuration UI (CUI), etc. Environment instance is collaborative application environment (AE). Organizational_Style (OS) instances are Configuration OS (COS), Submission OS (SOS), Assignment OS (AOS), Review OS (ROS), and Acceptance/rejection OS (POS). In the ontology shown in Figure 3, SOS is the unique OS considered by simplicity reasons. Group instance is G1, which is made up of three users, U1, U3 and U4, because U2 does not participate at SOS. Concurrency instance is locks mechanism (LM). Shared_Resource (SR) instances are paper (SRP), and uploading paper (IUP). Basic Activity (BA) instances are submitting information (ASI), and uploading paper (AUP). Task instance is submitting paper (TSP). Notification instance is group notification (GN).
Configuration instance is configuration of the system (CS).
Adaptation instance is adaptation application (AA).
Detection instance is adaptation event (AE).
Agreement instance is adaptation agreement of the application (AAA). Vote Tool instances are majority vote (MV), maximum value (MAV) and minimum value (MIV).
Adaptation_Flow instance is adaptation flow of the application (AFA).
Repair instance is reparation of the adaptation (RA).
BPM [
This phase identifies the participating elements in a business process. Unlike other existent models, we use an ontology (shown in the Figure 1), to clearly specify the semantics of the tasks and the decisions in the process flow. Therefore, four layers of the architectural model, (see Figure 2), are composed of the services, which were defined as concepts, in the ontology. The Group Layer includes three modules, which are Access, Group and Session. The Access Module has two services: Registration and Authentication. The Group Module presents three services: Group, Organizational Style, and Stage. The Session Module contains two services: Session Management, and Session. The Cooperation Layer has the Context Module and Interaction Module. The former includes four services: Concurrency, Shared Resource, Activity Basic, and Task. The later encompasses the Group Awareness Service, the Group Memory Service, and the Notification Service. The Application Layer comprises only the Application Service, the Configuration Service, the User Interface Service, and the Environment Service. Finally, the Adaptation Layer involves the Pre-adaptation Module and the Adaptation Module. The former encompass the Detection Service, the Agreement Service, and the Vote Tool Service. The latter comprises the Adaptation Flow Service, and the Repair Service.
In this phase, the business process model is transformed into an executable process model, which can be deployed to a process engine for its execution. Figure 3 shows a sequence diagrams (that represents an executable process model), when the author submits papers to the CMS. In this figure, the CMS users are consumer services, invoking different services and only are considering some services of the architectural model by simplicity.
In the process execution phase, the process engine executes a process model by firstly creating a process instance and then navigating through the control flow of the process model. In order to ensure seamless interaction when navigating through the control flow of the process model, this phase provides mechanisms for the discovery, selection and invocation of services. The module dynamically discovers and selects the appropriate service of the architectural model basing on the task description, and invokes it on behalf of the process engine, which plays the role of a requester service when it invokes the service to perform a task. Moreover, this module carries out a process monitoring that provides relevant information about running process instances. If during the process execution a failure arises, such as network faults, server crashes, or application-related errors (e.g. unavailability of a requested service, errors in the composition or missing data, etc.), reconfiguration actions are carried out, such as duplication (or replication) or substitution of a faulty service. The first case involves addition of services representing similar functionalities; this aims at improving load balancing between services in order to achieve a better adaptation. The second case encompasses redirection between two services; applying this action means the first one is deactivated and replaced by the second one. 5
The current work has presented an ontology-based architectural model, which facilitates the development of collaborative applications. The ontology describes the components, their relationships to each other and the environment, and the principles governing architectural design and evolution. For that reason, we think that the ontology is a proper model to describe architectures. BPM is used to manage and control the interaction between the services that make up the architectural model. In addition, BPM also is based on the ontology proposed. These services are designed using SOA that together with BPM, facilitates the application's integration. The future work will consist on extending the existent reconfiguration actions of the servicebased collaborative applications.