Collaboration Patterns Ontology

for Human-Machine Decision Support

Alexander Smirnov

and Tatiana Levashova

St. Petersburg Federal Research Center of the Russian Academy of Sciences, 39, 14

line, St. Petersburg, 199178, Russia

Keywords: Human-Machine Decision Support, Collaboration Pattern, Collaboration Patterns Ontology.

Abstract: Collaboration of humans and machines when they complement capabilities of each other is becoming

increasingly relevant. Recurring problems often arise in the collaboration process. Collaboration patterns that

provide reusable efficient and proven solutions for recurring problems is a means to facilitate organization of

joint activities for specific collaboration goals such as decision support. Existing studies on collaboration

patterns make it clear that collaboration faces problems of diverse classes. The paper proposes a holistic view

on human-machine collaboration relatively to the decision support domain where a human-machine

environment processes a task that the user deals with as a decision support problem. During task processing,

humans and machines use collaboration patterns when they intend to achieve goals for which the patterns

propose solutions. A collaboration patterns ontology supports the choice of a kind of pattern that the

collaborators can use to accomplish a specific goal. The present research provides models for organization of

pattern-based collaboration and contributes to the problem of human-machine decision support suggesting a

pattern-based decision support process.

1 INTRODUCTION

Nowadays, role of machines (software intelligent

agents, smart devices, robots, etc.) as a collaborative

partner of humans has become pivotal. Collaborating,

humans and machines complement capabilities of

each other and produce better results. This

partnership enhances human decision-making. When

humans work in collaboration with machines, they

harness the power of the machine’s capabilities to

enhance their decision-making and problem-solving

processes (IABAC, 2023).

Collaboration, like other forms of work, often

faces problems that can occur repeatedly. Christopher

Alexander (Alexander et al., 1977) mentioned this

fact in the 70s with relation to problems recurring in

architecture. He introduced a concept of design

pattern as a description of a problem, which occurs

over and over again, and a proposal for a reusable

solution for this problem. In architecture, the design

patterns have not found a widespread usage, but the

idea behind these patterns has attracted attention of

other domains including collaborative design,

0000-0001-8364-073X

0000-0002-1962-7044

collaborative software development, collaborative

decision-making, and others.

Motivation to address to collaboration patterns in

the context of human-machine decision support is that

the patterns propose efficient and proven solutions

and therefore pattern-based decision support help

make better decisions.

Multiple studies on collaboration patterns

describe patterns developed for specific collaboration

problems from different domains. The problems vary

from organization of collaboration environment to

collaborative solving particular tasks. This makes it

clear that collaboration faces problems of diverse

classes. The present research proposes a holistic view

on human-machine collaboration. It integrates

various kinds of existing collaboration patterns into a

human-machine decision support environment to

solve recurring problems occurring in collaboration

processes. An ontology of collaboration patterns

serves as a means for context-aware choice of a

specific pattern to solve a particular collaboration

problem.

Smirnov, A. and Levashova, T.

Collaboration Patterns Ontology for Human-Machine Decision Support.

DOI: 10.5220/0013057300003838

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 16th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2024) - Volume 2: KEOD, pages 83-94

ISBN: 978-989-758-716-0; ISSN: 2184-3228

The purpose of the present research is to provide

a perspective how a human-machine decision support

based on collaboration patterns can be organized. To

achieve the research purpose, collaboration patterns

found in various domains are categorized and a

conceptual model of human-machine collaboration

pattern is built. This model forms the basis of a

middle-level ontology for human-machine

collaboration patterns. The ontology is specialized in

respect to human-machine collaboration in decision

support. It enables a context-aware choice of

collaboration patterns aimed at accomplishment of

goals occurred during the collaboration. A sample

process of solving a task that the user formulates, as

a decision support problem by a human-machine

environment is proposed and a use case model is

considered.

The rest of the paper is as follows. Section 2

introduces kinds of collaboration patterns, the

conceptual pattern model, and the ontology of

collaboration patterns. Then, in Section 3, the

conceptual model of human-machine decision

support based on collaboration patterns is outlined,

task processing in accordance with this model is

presented, and a use case is considered. Conclusion

summarises the main research results.

2 ONTOLOGY OF

COLLABORATION PATTERNS

An analysis of research on collaboration patterns

underlies the development of the collaboration

patterns ontology. Patterns identified in multiple

domains in relation to human-machine collaboration,

human collaboration and collaboration of machines

are analysed. The analysis exposed five kinds of

collaboration patterns. The ontology integrates these

kinds of patterns based on a conceptual model

representing components common for most of the

pattern representations. This model provides concepts

and relationships for the high level of the ontology.

Further, this level is specialized in respect to human-

machine collaboration in decision support.

2.1 Kinds of Collaboration Patterns

The Section describes collaboration patterns

identified from the pattern descriptions found in

various domains. The patterns can be divided into

patterns that solve the problem of organizing

collaboration, and patterns that offer a solution to a

problem that arises in the collaboration process. In the

former case, collaborators do not necessarily have to

be involved in the collaboration activities but the

patterns are referred to as collaboration ones because

they provide with results that support such activities.

Organization patterns, cognitive patterns, and

interaction patterns represent this group of patterns.

In the latter case, collaborators use patterns to solve

jointly the problem they are dealing with. This set of

patterns comprises process patterns and collaborative

engineering patterns.

2.1.1 Organization Patterns

Organization patterns (Eoyang, 2018; Schmeil &

Eppler, 2010) refer to collaboration process as

collaborators’ activities in accordance with principles

and structure of collaborative environment. The aim

of these patterns is proposing an environment for

collaboration. They describe a problem solution in

terms of objects, actions, rules, and steps for

collaborators with roles who meet at a location to

collaborate on a common goal in a given context.

A collaborative environment is organized in

accordance with collaboration types, which

determined by characteristics of the collaboration.

Such characteristics include collaboration goal, kinds

of activities, structures of partner interactions, and

others (e.g., term of collaboration (long-term, short-

term, others); expected use of the results from the

collaboration (internal usage, transfer from one

partner to the other, transfer to third parties, etc.);

others). Solution proposed by the organization

patterns is architecture of a collaborative

environment. Elements of this architecture are

collaborators, roles they fulfil, collaborators’

activities according to their roles, tools supporting the

activities, and other elements of information systems

architectures (interface, infrastructure, etc.).

Additionally, the architecture describes relationships

between the architectural elements and specifies

collaboration rules.

2.1.2 Cognitive Patterns

Cognitive patterns (Deokar et al., 2008; Toniolo et al.,

2023; Vreede et al., 2006) describe the thinking and

reasoning processes of experts. Collaboration process

from the viewpoint of the cognitive patterns is putting

forward ideas, proposals, hypotheses and their

agreeing. The patterns’ objective is to shape a

scenario for the collaboration process. A solution that

the patterns propose is a configuration of various

cognitive patterns or pattern modelling components

to organize such a scenario with respect to a specific

intellectual task.

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development

The patterns support the following semantics.

Collaborators solve an intellectual task. Human

collaborators fulfil the role of experts. They

undertake intelligent activities. Agents provides

automated support to humans, when needed. In the

collaboration process, the experts can use multiple

tools that afford one or more capabilities (e.g., tools

supporting communications or content visualisation,

etc.) Undertaking of an ordered set of intelligent

activities leads to a solution of the intellectual task.

Preconditions determine which kind of intelligent

activity it is advisable to choose at a particular stage

of task processing. The collaboration scenario

represents collaborators, roles they fulfil, a sequence

of collaborators’ activities according to their roles,

and tools supporting the activities.

2.1.3 Interaction Patterns

Interaction patterns (Barchetti et al., 2011; de Moor,

2006; Dorn et al., 2012) describe a problem solution

in terms of components of communication and data

management processes. These patterns consider

collaboration process as exchanging and editing

information, and performing procedures and tasks

initiated by information messages. The objective of

the interaction patterns is to compose a scenario for

the collaboration process. They offer a solution in the

form of a composite information pattern or pattern

modelling components to organize such a scenario

with respect to some collaborators’ activity.

The semantics behind the interaction patterns is as

follows. Collaborators interact to achieve a specific

goal that arises in the process of their joint activities.

Collaborators with the role of initiator send messages

to the collaborators with the role of executor. The

executors respond to the initiators of undertake the

requested activity. An executor can forward the

message to other collaborators to initiate their actions.

In this case, the role of executor changes to the

initiator. The goal determines the content of the

messages and is contained in the content. The

collaboration scenario represents collaborators, roles

they fulfil, a sequence of collaborators’ interactions

according to their roles, and communication tools

supporting the interactions.

2.1.4 Process Patterns

Process patterns (Papageorgiou et al., 2009; van

Diggelen & Johnson, 2019; Verginadis et al., 2009;

Vo et al., 2015) describe a problem solution in terms

of activities, actions, and work tasks that the

collaborators must take or accomplish to come to this

solution as well as tools they can use. Collaboration

process is considered as taking actions by

collaborators leading to problem solution or goal

achievement. The patterns aim at building a

collaboration process. A solution offered is a

configuration of several process patterns or a

sequence of actions, which shape the workflow.

In the process patterns, collaborators take activity

to achieve a goal or solve a problem. Activities and

actions of the collaborators constitute the workflow.

It specifies collaborators, roles they fulfil, a sequence

of collaborators’ activities according to their roles,

and tools supporting the activities.

2.1.5 Collaborative Engineering Patterns

The collaborative engineering patterns (Barchetti et

al., 2011; Gottesdiener, 2001) describe a problem

solution in terms of rules for collaborative decision-

making. Here, collaboration process is a decision-

making process. The patterns’ objective is proposing

a procedure for establishing collaborative decision-

making rules. A solution proposed is the procedure

for choosing a decision-making rule by the

collaborators.

According to the patterns’ semantics,

collaborators undertake activities to establish a

decision-making rule. For this, they follow the

procedure offered by the collaborative engineering

pattern, in accordance with their roles and use

communication tools if necessary.

2.2 Conceptual Pattern Model

The semantics behind the kinds of the collaboration

patterns discussed above provide with ideas about a

conceptual model of human-machine collaboration

pattern (Figure 1). The concepts of this model are

defined in the following way.

Pattern is a description of a reusable solution for

a recurring problem arising in human-machine

collaboration processes.

Goal is a solution intended to be found for the

problem arose in the collaboration process.

Collaborator is an individual engaged in

collaboration.

Human is a collaborator of human nature.

Machine is a software entity engaged in

collaboration.

Activity is behavior of collaborators necessary to

achieve the goal.

Role is a position of a collaborator specifying

activities that the collaborator can and must be

capable to undertake.

Tool is a means that supports an activity.

Collaboration Patterns Ontology for Human-Machine Decision Support

Figure 1: Conceptual model of human-machine

collaboration pattern.

Pre-condition is a condition when a pattern can be

applied.

Post-condition is a solution that the pattern

proposes.

The conceptual model of human-machine

collaboration pattern supports the following

semantics. A pattern proposes a (reusable) solution

for a goal achievement. A set of pre-conditions

determines the possibility of pattern usage.

Collaborators represented by humans and software

entities (machines) participate in the goal

achievement. They undertake activities necessary to

achieve it, act in accordance with the roles that they

fulfil, and, if necessary, use tools supporting certain

activities. The activities produce outcomes some of

that constitute a set of post-conditions of the pattern

application. The pre-conditions do not include

conditions necessary to undertake activities because

these conditions do not coincide with the pattern

application pre-conditions. The post-conditions

represent only the activities outcomes that provide

solutions (indicate the goal achievement).

2.3 Ontology

Figure 2 proposes an OWL-ontology of human-

machine collaboration patterns developed based on

the conceptual model (Figure 1). The ontology is

implemented in the Protégé ontology editor (Musen,

2015). The part given in Figure 2 shows middle-level

classes (Cabrera et al., 2015) representing relatively

generic concepts and relationships relevant to the

domain of collaboration pattern modelling. In this

figure, the unsigned relationships coming from the

class Thing specify the property of has subclass.

The ontology (Figure 3) is a specialization of the

middle-level in respect to human-machine

collaboration in decision support. It integrates the five

kinds of the collaboration patterns and represents

decision support activities according to the Simon’s

decision-making model (Simon, 1960, 1979). The

ontology has not been fully completed yet. It does not

provide complete sets of subclasses and limited to

sample concepts sufficient to the discussion of the

paper topic. Actually, the classification of activities,

roles, and tools can be much more extensive.

Definitions of ontology concepts not given in

Section 2.2 are provided below. The ontology

hierarchy shows classes alphabetically. In some

places, class definitions given do not follow this order

to give first definitions for classes that subsequent

definitions use.

Status is a stage of processing a decision support

problem (a problem that the decision maker is dealing

with). It can take values new, projected, planned,

assigned, in progress, and completed. Status values

serve as preconditions for using patterns.

Character is a nature of an activity. Character if

specified by the function f(intellectual)  {true,

false}. “True” means that an activity is of the

intellectual nature; “false” reports that the activity’s

character is not specified, that is it can be both

intellectual and non-intellectual.

Cognitive is a pattern providing a set of activities

to design a process of solving an intellectual task by

collaborators. The pre-conditions for pattern

application are 1) the status is in progress and 2) in

the collaboration plan (the collaboration plan is a

post-condition of process plan application), the

character of an activity is specified as intellectual. A

Figure 2: Middle-level of ontology for human-machine collaboration patterns.

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development

Figure 3: Ontology of human-machine collaboration

patterns: asserted class hierarchy.

post-condition of pattern application is a plan for

solving the intellectual task. Such a plan is a sequence

of intelligent activities (e.g., generating ideas,

assuring that the collaborators agree on the meaning

of each other's statements, etc.) undertaking of which

leads to a solution of the task.

Collaborative engineering is a pattern offering a

procedure for establishing a collaborative decision-

making rule. The pre-conditions for use of the pattern

are 1) the status is in progress and 2) there is a request

from one or several collaborators to make a decision.

A post-condition of pattern application is a

collaborative decision-making rule.

Interaction is a pattern providing tools and

components of communicative acts to shape a

scenario of interactions between the collaborators

while their undertaking activities. The pre-conditions

for use of the pattern are 1) the status is in progress

and 2) there is a request from one or several

collaborators to communicate or take activities. A

post-condition of pattern application is an interaction

scenario.

Organization is a pattern providing a set of

architectural components to arrange a collaborative

environment. The pre-condition for use of the pattern

is the status has the value of projected. Post-

conditions of pattern application are 1) architecture of

collaborative environment and 2) the task status

changes to planned.

Process is a pattern providing a workflow model

for planning a goal achievement process. A pre-

condition for pattern application is the status has the

value of planned. Post-conditions of pattern

application are 1) a workflow plan and 2) the task

status changes to assigned. A workflow plan is a

sequence of activities necessary to achieve the goal,

roles responsible for their undertaking, collaborators

fulfilling these roles, and tools needed to complete the

planned activities.

Build consensus is an activity to move from

having fewer to having more collaborators who are

willing to commit to a proposal.

Clarify is an activity aiming at movement from

having less to having more shared understanding of

concepts and of the words and phrases used to express

them.

Decision-making is an activity that entails

identifying and choosing from alternatives an

alternative that is a problem solution.

Evaluate is an activity aiming at movement from

less to more understanding of the relative value of the

concepts under consideration.

Generate is an activity to move from having fewer

to having more concepts in the pool of concepts

shared by the collaborators.

Identification is an activity on realizing a problem

needs to be solved.

Intelligence analysis is an activity to make sense

of information (often conflicting or incomplete) to

explain an observed situation by weighing up

competing hypotheses.

Interact is an activity that entails communications

between collaborators or undertaking an activity by a

collaborator in response to a communicative message.

Collaboration Patterns Ontology for Human-Machine Decision Support

Organize is an activity to movement from less to

more understanding of the relationships among

concepts the collaborators are considering.

Reduce is an activity aiming at movement from

having many concepts to a focus on fewer concepts

that the collaborators deem worthy of further

attention.

Statement is a communication that expresses

some meaning.

Hypothesis is a statement intended to explain

certain facts or observations.

Idea is a statement describing a thought or

suggestion as to a possible approach to problem

solving or goal achievement.

Proposal is a statement putting forward

something for consideration or discussion.

Alternative is an alternative from the set of

alternatives (Set) presented by a statement.

Set is a set of alternatives as a post-condition of

the “generate” activity.

Decision is an alternative chosen from the set of

alternatives as a post-condition of the “decision-

making” activity.

Architecture is architecture of collaborative

environment as a post-condition of the organization

pattern application.

DM Rule is a collaborative decision-making rule

as a post-condition of the application of the

collaborative engineering pattern.

Intellectual process is a plan for solving the

intellectual task as a post-condition of the cognitive

pattern application.

Interaction scenario is a specific scenario for

interactions between collaborators as a post-condition

of the interaction pattern application.

Workflow is a plan for goal achievement as a post-

condition of the process pattern application.

Communication tool is a software and

applications that facilitate information exchange

between collaborators.

Facility is a tool affording some capabilities

needed to complete an activity.

Agent is a role specifying activities that software

agents undertake.

Analyst is a role entailing activities on analytical

research and system analysis to solve problems,

explain observations, make forecasts, and develop

recommendations.

Assistant is a role entailing activities on providing

an expert with services.

Collaboration engineer is a role entailing

activities on designing a process of solving an

intellectual task.

Decision maker is a role entailing decision-

making activities.

Executor is a role of a message recipient, which

entails activities on sending replying messages and

undertaking activities initiated by a message.

Expert is a role specifying activities that humans

undertake.

Initiator is a role constraining activities with the

activity on sending messages to initiate interactions.

3 DECISION SUPPORT

A human-machine environment uses the

collaboration patterns to recommend decisions to the

user. This environment operates according to a

conceptual model of human-machine decision

support based on collaboration patterns (Smirnov &

Levashova, 2024). It processes a task that the user

formulates as a decision support problem. During

task-processing, humans and intellectual agents use

collaboration patterns when they intend to achieve

goals for which the patterns propose solutions.

3.1 Conceptual Model of

Human-Machine Decision Support

Based on Collaboration Patterns

The conceptual model of human-machine decision

support based on collaboration patterns (Figure 4)

includes concepts introduced in the collaboration

pattern ontology and concepts of Context, Problem,

Resource, and Task. In the conceptual model, the

concept of Goal has a narrower meaning.

Problem is a solution/accomplishment that needs

to be found/achieved for a task/goal arose in the

collaboration process.

Task is a problem to be solved as a decision

support problem.

Goal is a problem arose in the course of the task

processing.

Resource is an available source of aid or support

that may be drawn upon when needed. Collaborator

and Tool are kinds of resources.

Context is information characterising the situation

of the task processing. The contextual information

reports on the task processing activities, the goal of

these activities, the resources involved, the roles that

the collaborators fulfil, and the statuses of the task.

According to the conceptual model discussed

humans and agents that are components of a human-

machine environment collaborate to process jointly a

task as a decision support problem. Collaboration

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development

Figure 4: Conceptual model of decision support based on human-machine collaboration patterns.

patterns propose solutions for recurring goals arising

during the task processing. Context provides

information needed to choose and instantiate patterns.

The task status and the objectives of the undertaken

activities determine the current goal of the task

processing. If this goal matches with a pattern goal

then this pattern can be used in the given context.

During the task processing, the contextual

information is updated.

Kinds of activities that collaborators can

undertake determine the decision support scope of the

conceptual model. These activities are decision

support ones and activities included in the

specifications of problem solutions that the patterns

propose. The Activity class of the collaboration

pattern ontology (Figure 3) represents them.

3.2 Task Processing Using

Collaboration Patterns

The human-machine environment processes the task

formulated by the user. When the environment

receives a task, the status of this task is assigned to

new. This status means that the current goal is

definition of kinds of activities necessary to solve the

task. According to the conceptual model (Sec. 3.1),

some of these activities are predefined. They are

activities supposed by the Simon’s decision-making

model (Simon, 1960, 1979): problem identification,

the development of alternatives, evaluation of the

alternatives, and choice of an alternative from the

alternatives set (making a decision). The goal of the

problem identification activity entails activities on

task formalization and acquiring information needed

to solve it. This goal as well as the goal of definition

of kinds of activities are out of the consideration in

the present research because no patterns offering

solutions for them have been found.

After the set of activities needed is defined, the

task status changes to projected. Further activities

aimed at the task processing are supported by the

human-machine collaboration patterns (Figure 5).

Table 1 presents the pre-conditions when a specific

pattern can be applied. In the table, task with no

attribute is the task that the user formulates (task as

defined in the conceptual model of decision support);

intellectual task refers to any activity of the

intellectual nature.

The task status of projected supposes that the

current goal is organization of a collaborative

environment, that is definition of a set of architectural

components necessary to complete activities on the

task processing. The organization pattern proposes a

solution for this goal. The outcome of the pattern

execution is architecture of the collaborative

environment. As a post-condition of the pattern

application, the task status changes to planned.

The task status of planned suggests that the goal

of designing a plan for the task processing appears.

For this goal, the process pattern offers a solution.

The outcome of pattern application is a task-

processing plan that the collaborators develop based

on the view of the environment architecture.

Table 2 proposes an example of such a plan. In

this table, no. means the activity number in the

sequence of the activities planned. The interaction

activity does not have any number because

collaborators can need to interact when undertaking

any activities. The tool of HMCIE refers to Human-

Machine Collective Intelligence Environment

(Smirnov et al., 2022), which affords a technological

backing by supporting interactions between

Collaboration Patterns Ontology for Human-Machine Decision Support

Figure 5: Task-processing based on human-machine collaboration patterns.

Table 1: Pre- and post-conditions of collaboration pattern applications.

Pre-conditions

Pattern Post-conditions

Goal Task status value and others

Organizing a collaborative

environment

Task status is projected Organization

• Collaborative environment

architecture;

• Task status is

lanned

Designing a task-processing

plan

Task status is planned Process

• Task-processing plan;

• Task status is assi

ned

Carrying out an activity

aimed at accomplishment of

a not-recurring

goal

• Task status is in progress;

• f(intellectual)  false

Not defined Outcome from the carried out

activity

Designing a plan for

solving an intellectual task

• Task status is in progress;

•

(intellectual)  true

Cognitive Scenario for solving an intellectual

task

Establishing a decision-

making rule

• Task status is in progress;

• Re

uest on makin

a decision

Collaborative

engineering

A collaborative decision-making

rule

Shaping a scenario for

collaborator interactions

• Task status is in progress;

• Request on communication

or undertaking activities

Interaction Collaborators interaction scenario

Table 2: Task-processing plan (example).

no. Activit

Nature Role Collaborato

Tool

1 Develo

ment of alternatives Uns

ecifie

Anal

st A

ent HMCIE

2 Evaluation of alternatives Intellectual Collaboration engineer Human HMCIE

Decision make

Human

3 Choice of an alternative Uns

ecifie

Decision make

Human HMCIE

– Interaction Unspecified Initiato

Agent, Human HMCIE

Executo

Agent, Human HMCIE

collaborators, enabling collaborators interoperability,

providing mechanisms for self-organization, and

offering computational services that agents can use.

As a post-condition of process pattern application, the

task status changes to assigned.

When the collaborators start executing the plan,

the task status changes to in progress.

The presence in the plan of some activities

specified as intellectual (e.g., the activity on

evaluations of alternatives in Table 2) means

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development

existence of the goal for solving an intellectual task.

The cognitive pattern proposes a solution for this

goal. For instance, to solve the evaluation task an

expert fulfilling the role of collaboration engineer

defines the sequence of activities as organize, clarify,

reduce, clarify, and evaluate. Experts fulfilling the

role of decision maker are responsible for undertaking

the scheduled activities. The outcome from these

activities is a set of alternatives agreed with all the

experts and evaluated relative to one or more criteria.

The final activity of choice of an alternative in the

task-processing plan stipulates an appearance of the

decision-making goal. The collaborative engineering

pattern is responsible for a solution for this goal. The

collaborators follow the procedure for establishing a

decision-making rule proposed in the pattern. This

procedure offers a sequence of rules following which

the collaborators can make a choice on a collaborative

decision-making rule that they agree to use in the

current circumstances. Examples of decision-making

rules are majority vote, delegation, negotiation,

spontaneous agreement, arbitrary, decision leader

decides without discussion, decision leader decides

after discussion, consensus (Gottesdiener, 2001). The

result of going through the procedure proposed in the

collaborative engineering pattern is a collaborative

decision-making rule that the collaborators agree to

use when choosing an alternative. The alternative

chosen is considered the decision recommended by

the human-machine environment. The delivery of this

decision to the user completes the task processing

process. The task status changes to completed.

A decision-making goal may appear not only

while choosing alternatives. Any activities may need

local decisions. Such a necessity is a precondition to

use the collaborative engineering pattern.

Collaborators during undertaking the activities

(intellectual and others) can need interactions. The

interaction pattern proposes a solution how to achieve

an interaction goal. This pattern offers a set of

components to create an interaction scenario. The

scenario describes an order of communicative acts,

content of these acts, roles of the participants of the

interactions, and tools supporting the interactions.

3.3 Use Case

The use case is devoted to the developing

recommendations aimed at release and prevention of

traffic accidents. As part of the regular inspections,

the user of the human-machine environment initiates

the task of developing recommendations and provides

to the environment information necessary to task

processing. The task status receives the value of new.

The list of activities necessary to solve the task as

a decision support problem comprises the

development of a set of recommendations for release

and prevention of traffic accidents at the given site,

evaluation of the recommendations from the set

regarding the criteria used in the environment, and

choice of a recommendation for offering the user

(making a decision). Getting the list of activities

changes the task status to projected.

The status of projected means that a collaboration

environment is supposed to be organized and the

ontology infers that the organization pattern is

indented to accomplish this goal (Figure 6). This

pattern is chosen to show an example of the

axiomatization. Axioms for other patterns are not

provided because of the space limit.

A post-condition of the organization pattern is a

set of concepts and relationships that describe

collaboration environment architecture. The pattern

does not impose a role responsible for the

instantiation of the architectural components. In the

use case, the user configures the architecture. It

describes:

• a set of functions:

 activities as they are defined in the list of

activities above;

 interactions;

 providing information;

• a set of resources:

 a group of intelligent agents comprising:

Figure 6: Axioms for organization pattern.

Collaboration Patterns Ontology for Human-Machine Decision Support

Table 3: Specialization of task processing plan.

no. Activit

Activit

nature Role Collaborato

Tool

1 Collecting relevant information

regarding the task

Not specified Analyst Accident anal

st HMCIE

Signs analyst

2 Development of a set of

recommendations for release

and prevention of traffic

accidents

Not specified Analyst Recommender HMCIE

3 Evaluation of the

recommendations

Intellectual Collaboration engineer User HMCIE

Assistant Accident anal

ns anal

Decision make

Any expert

4 Decision making Not specifie

Decision make

All HMCIE

– Interactions Not specified Initiato

All HMCIE

Executo

All

o accident analyst (an agent that provides

information about the traffic accident site

and analyses the accident reporting cards);

o signs analyst (an agent that provides

information about the road signs installed at

the traffic accident site);

o recommender (an agent that proposes

criteria for evaluation of alternatives,

coordinates the procedure of establishing

decision-making rules, and provides

recommendations for release and prevention

of traffic accidents);

 a group of experts comprising:

o decision maker;

o FRA – a representative of the Federal Road

Agency;

o Municipal administration – a representative

of the Administration;

o Police inspector – a representative of the

traffic police department;

 HMCIE tool;

 interface REST API;

• a set of roles: agent; expert; decision maker;

analyst; collaboration engineer; assistant;

initiator; executor.

Organization of the collaboration environment

completes with the assignment of the value of

planned to the task status. This status means that a

task processing plan should be designed.

Since the recommendations are developed within

a regular inspection, a plan (the example in

Table

designed previously to solve similar tasks in the

HMCIE is used.

Table 3

shows the specialization of

this plan to the architecture created.

The plan developed leads to changing the task

status to assigned. The collaborators start putting the

plan into actions and the task status changes to in

progress.

At the stage of collecting relevant information

regarding the task, the accident analyst provides the

collaborators with the date and time of the inspection,

the coordinates of the accident site, the period for

which the inspection is carried out, and the reference

to a collaborative meeting service. The signs analyst

notifies that that at the considered location the sign

“turn right” is installed at the minor road entering the

major one and the signs “Bend to left” and “No

overtaking” are installed at the major road (Figure 7).

The accident analyst reports that the accidents of the

types of rear-end or side-impact collisions are fixed at

the accident site due to non-compliance of drivers

with road signs. When drivers leave the minor road

they violate the sign “turn right”, turn to the left and

due to the major road turns sharply, the view of

vehicles moving on the right is difficult, which leads

to collisions.

Based on the information that the analysts

provided, the recommender starts activities on the

development of recommendations. This agent uses

the Guidelines for the release and prevention of traffic

accidents (further, the Guidelines) to make

recommendations. With reference to the Guidelines,

it recommends to install lane delineators at the

accident site.

The recommendations development activity is

followed by the recommendations evaluation activity.

The plan specifies the evaluation activity as

intellectual. It means that a collaborator fulfilling the

Figure 7: Accident site.

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development

role of collaboration engineer should shape a scenario

of recommendation evaluation. In the use case, the

user fulfils the role of the collaboration engineer.

HMCIE supports the user with the cognitive pattern

and with a set of possible evaluation criteria. The user

specifies the evaluation scenario through a sequence

of intellectual activities as Generate, Reduce and

Build consensus (the ontology of human-machine

collaboration patterns defines these activities). As an

evaluation criterion, the user choses the criterion of

advisability.

The recommendation to install lane delineators is

submitted to the expert group for evaluation (the

experts start their activity with Reduce because the

activity of Generate was performed by the

recommender). The police inspector believes that the

proposed recommendation is not advisable, because

if lane delineators are installed then a left turn from

the major road to the minor one will be impossible,

but this turn is not dangerous and is currently allowed.

The others joint the inspector’s opinion. Thus, the

expert group rejects the recommendation proposed by

the recommender.

According to the evaluation scenario, the experts

generate some more alternatives. They can also ask

agents for assistance (for complex calculations,

searching information, etc.) The police inspector

starts the activity of alternatives generation and

proposes the agent group to consider which measures

can be provided for if the sigh “turn right” is removed.

The recommender submits to the expert group a list

of nine measures that the Guidelines provide for the

collisions of the considered types on the turned

sharply roads.

The experts evaluate the measures from the list

(the number of the measures is reducing). As a result

of the evaluation, the experts find none of the

measures advisable.

The experts start developing alternatives again.

The municipal administration believes that the most

appropriate to equip the given crossroad with a smart

crossroad system (the Guidelines do not provide for

this measure). Such systems are adaptive road traffic

controller used to switch traffic lights on a single

(local) crossroad. The other experts support the

proposal of the municipal administration. A smart

crossroad system is the recommendation of the

human-machine environment submitted to the user.

The use case leaves out of consideration the

patterns of collaborative engineering and interaction.

Collaborators apply the interaction pattern at any

communications and interactions. When an

interaction takes place HMCIE instantiates content of

the communicative act and collaborators fulfilling the

roles of initiator and executor. As well, HMCIE is the

tool supporting the interactions. The collaborative

engineering pattern is applied when collaborators are

not aware which rule to use to make a decision. In the

use case, the user provides such a rule (consensus) in

the alternatives evaluation scenario.

4 CONCLUSIONS

Patterns provide reusable efficient and proven

solutions for recurring problems. Pattern-based

human-machine collaborative decision support is the

aim of the present research. The human-machine

environment uses a collaboration patterns ontology to

choose an appropriate pattern when collaborators face

a specific problem during their joint activities. The

ontology integrates five kinds of collaboration

patterns. These patterns provide solutions for

recurring problems of organizing a collaborative

environment, designing collaboration plans and plans

for collaborative solving intellectual tasks,

establishing decision-making rules, and shaping

scenarios for collaborators’ interactions. Humans and

software agents (machines) process a task that the

user formulates to the human-machine environment

as a decision support problem and apply collaboration

patterns to accomplish decision support goals.

The research contributes to the problem of

human-machine decision support suggesting a

pattern-based decision support process. An important

consequence of using collaboration patterns is that

they allow collaborative decision support

environments to improve their performance and make

better decisions by using solutions that the patterns

offer.

The shortcomings and limitations of the research

concern the ontology completeness and its validity.

The use case presented in the paper is very simple. It

does not allow to judge about the ontology generality.

As well, the potential of the ontology inference has

not been fully studied. So far, it is limited to pattern

offering.

The limitations shape a foundation for future

research. The ontology is planned to be revised and

validated using a set of application scenarios. These

scenarios are expected to help to assert the ontology

correctness, to identify points for possible ontology

extension and provide ideas what kind of inference it

should support.

Collaboration Patterns Ontology for Human-Machine Decision Support

ACKNOWLEDGEMENTS

The paper is due to the State Research Project

no. FFZF-2022-0005.

REFERENCES

Alexander, C., Ishikawa, S., & Silverstein, M. (1977). A

pattern language. Oxford University Press.

Barchetti, U., Antonio, C., Guido, A. L., & Mainetti, L.

(2011). Modelling collaboration processes through

design patterns. Computing and Informatics, 30(1),

113–135.

Cabrera, O., Franch, X., & Marco, J. (2015). A middle-level

ontology for context modelling. In P. Johannesson,

M. Lee, S. Liddle, A. Opdahl, & Ó. Pastor López

(Eds.), Conceptual Modeling (LNCS, Vol. 9381, pp.

148–156). Springer. doi:10.1007/978-3-319-25264-

3_11.

de Moor, A. (2006). Community memory activation with

collaboration patterns. In L. Stillman & G. Johanson

(Eds.), Proceedings of the 3rd Prato International

Community Informatics Conference (CIRN 2006)

(1 CD, File: 2006\prato2006\demoorfinal.zip.). Centre

for Community Networking Research.

Deokar, A. V., Kolfschoten, G. L., & de Vreede, G.-J.

(2008). Prescriptive workflow design for collaboration-

intensive processes using the collaboration engineering

approach. Global Journal of Flexible Systems

Management, 9(4), 11–20. doi:10.1007/BF03396547.

Dorn, C., Edwards, G., & Medvidovic, N. (2012).

Analyzing design tradeoffs in large-scale socio-

technical systems through simulation of dynamic

collaboration patterns. In R. Meersman, H. Panetto, T.

Dillon, S. Rinderle-Ma, P. Dadam, X. Zhou, S. Pearson,

A. Ferscha, S. Bergamaschi, & I. F. Cruz (Eds.), On the

Move to Meaningful Internet Systems: OTM 2012.

(LNCS, Vol. 7565, pp. 362–379). Springer.

doi:10.1007/978-3-642-33606-5_22.

Eoyang, G. (2018). Patterns of collaboration.

Human Systems Dynamics Institute.

https://www.hsdinstitute.org/resources/patterns-of-

collaboration.html. Accessed: 4.10.2024.

Gottesdiener, E. (2001). Decide how to decide. Software

Development Magazine, 1.

https://www.ebgconsulting.com/Pubs/Articles/Decide

HowToDecide-Gottesdiener.pdf. Accessed: 4.10.2024.

IABAC. (2023). Human-machine collaboration in the age

of AI. Trending Blogs; The International Association of

Business Analytics Certification (IABAC).

https://iabac.org/blog/human-machine-collaboration-

in-the-age-of-ai. Accessed: 4.10.2024.

Musen, M. A. (2015). The protégé project. AI Matters, 1(4),

4–12. doi:10.1145/2757001.2757003.

Papageorgiou, N., Verginadis, Y., Apostolou, D., &

Mentzas, G. (2009). A collaboration pattern model for

virtual organisations. In L. M. Camarinha-Matos, I.

Paraskakis, & H. Afsarmanesh (Eds.), Leveraging

Knowledge for Innovation in Collaborative Networks.

PRO-VE 2009 (IFIP Advances in Information and

Communication Technology, Vol. 307, pp. 61–68).

Springer. doi:10.1007/978-3-642-04568-4_7.

Schmeil, A., & Eppler, M. J. (2010). Formalizing and

promoting collaboration in 3D virtual environments –

A Blueprint for the Creation of Group Interaction

Patterns. In F. Lehmann-Grube & J. Sablatnig (Eds.),

Facets of Virtual Environments. FaVE 2009 (Lecture

Notes of the Institute for Computer Sciences, Social

Informatics and Telecommunications Engineering,

Vol. 33, pp. 121–134). Springer. doi:10.1007/978-3-

642-11743-5_10.

Simon, H. (1960). The new science of decision-making.

Harper and Row.

Simon, H. (1979). Rational decision making in business

organizations. American Economic Association, 69(4),

493–513.

Smirnov, A., & Levashova, T. (2024). Decision support

based on human-machine collaboration patterns:

conceptual model and scenario. 2024 35th Conference

of Open Innovations Association (FRUCT), 1, 715–724.

doi:10.23919/FRUCT61870.2024.10516361.

Smirnov, A., Ponomarev, A., Levashova, T., & Shilov, N.

(2022). Conceptual framework of a human-machine

collective intelligence environment for decision

support. Proceedings of the Bulgarian Academy of

Sciences, 75(1), 102–109. doi:10.7546/CRABS.

2022.01.12.

Toniolo, A., Cerutti, F., Norman, T. J., Oren, N., Allen, J.

A., Srivastava, M., & Sullivan, P. (2023). Human-

machine collaboration in intelligence analysis: An

expert evaluation. Intelligent Systems with

Applications, 17, 200151. doi:10.1016/j.iswa.

2022.200151.

van Diggelen, J., & Johnson, M. (2019). Team design

patterns. Proceedings of the 7th International

Conference on Human-Agent Interaction, 118–126.

doi:10.1145/3349537.3351892.

Verginadis, Y., Apostolou, D., Papageorgiou, N., &

Mentzas, G. (2009). An architecture for collaboration

patterns in agile event-driven environments. 2009 18th

IEEE International Workshops on Enabling

Technologies: Infrastructures for Collaborative

Enterprises, 227–230. doi:10.1109/WETICE.2009.12.

Vo, T. T., Coulette, B., Tran, H. N., & Lbath, R. (2015).

Defining and using collaboration patterns for software

process development. Proceedings of the 3rd

International Conference on Model-Driven

Engineering and Software Development

(MODELSWARD 2015) - CMDD, 557–564. doi:10.

5220/0005338705570564.

Vreede, G. J. De, Kolfschoten, G. L., & Briggs, R. O.

(2006). ThinkLets: a collaboration engineering pattern

language. International Journal of Computer

Applications in Technology, 25(2/3), 140–154.

doi:10.1504/IJCAT.2006.009064.

KEOD 2024 - 16th International Conference on Knowledge Engineering and Ontology Development